カテゴリ

開発生産性可視化の意義とPR TIMESの事例 発表資料

チーム体制 開発 勉強会
金子 達哉
  • URLをコピーしました！

こちらのエントリーは一人一人が意識する開発生産性 – 組織の当たり前基準と顧客価値を上げるために – connpassの発表資料です。

目次

自己紹介

数年前のPR TIMES

  • デプロイは1週間に1度あるかどうかという頻度
  • リリース時のメンテナンスにより、大きな変更をリリース
  • PHPのバージョンが非常に古く、ソースコードにも問題があり機能追加が困難で開発効率が低い
  • フロントエンドもほぼすべて古いjQueryベースで作られており、バグ修正すらできていない

⇒開発速度向上のために、すべて変えたのでざっくり紹介

デプロイ頻度を上げる

  • 小さいPRをどんどんmergeしていく開発スタイルへ
    • 最初はバックエンドにFeature Flagを導入
    • 現在ではフロントエンドにも導入済み
  • デプロイ高速化のためにフルスクラッチでデプロイの仕組みを作り直し
    • デプロイサーバー上でcomposer installなどの必要な処理を実行後に、結果をrsyncし、rsync先のディレクトリを参照するようにシンボリックリンクを切り替えることで反映
    • デプロイ時にPHPのsyntax checkをするなど、事故防止の仕組みも導入
    • デプロイが遅かったり面倒だと、デプロイ回数を減らす方向にincentiveが働く
      • revertにも時間がかかるので恐くて変更できない
      • デプロイに時間がかかる→改善を進めたくない、という状況に陥っていたので優先度高めで対応
        • デプロイの仕組み自体にも改善が入れられない状況だった
  • マルチステージング環境導入
    • ステージング環境が1つしかなかったので、開発した変更の確認が気軽にできない状況だった
    • ApacheのVirtualDocumentRootを利用して、追加のリソースなしで複数のドメインで確認できるように
    • フロントエンドでも同様のことができる仕組みを導入
      • 1つのS3バケットでファイルをブランチ名のディレクトリの中に保存し、Cookie経由でURLをブランチ名を含むものに変更する仕組み
  • Jira導入
    • それまではGitHub issue上のコメントで行っていた
    • Jiraで開発中・QA待ちなどのステータスを管理することで、開発・QA・プロダクトのコミュニケーションに齟齬が出ないように
      • ガントチャートも活用し、スケジュール・開発遅れなどの可視化
    • デイリーで都度タスク確認や相談を行い、開発遅れなどにすぐ気付けるように
      • 開発が遅れたから責めるという文化ではなく、遅れているから周りがフォローする、タスクを調整するなどのコミュニケーションを取れるように
  • CI導入
    • PR TIMESのソースコードには元々Unit Testは存在していなかったので、Unit Testを書くようにするところから
    • GitHubにpushしたらテストが自動で実行されるようにすることで気軽に変更可能に
    • テスト整備はまだ途上の状況

バックエンドの開発方針

  • バックエンドはPHPのバージョンアップ開始
  • デッドコード削除などを進めるために月に1度のリファクタリングデー開始
    • デプロイ改善完了後に導入することで、revertやデプロイの心理コストを下げた状態で実施
      • 実は以前のデプロイの仕組みではrsyncの—deleteオプションが付いていなかったためソースコードを削除してもサーバー上から消えなかったという事情もあった
      • こういった問題をデプロイスクリプトが改善できない状況で放置していたので、フルスクラッチで作り直す必要があった
    • まずはデッドコード削除から始めて、少しずつできることを増やしていく
    • 現在ではライブラリのバージョンアップ、ソースコードの構成変更など様々なリリースが行われる日に
  • 学生インターン受け入れ
    • 目的としては業界内で活躍するエンジニアをインターンを通して輩出したい、社員だけでは手が回らない改善系のタスクを進めるの2点
    • 学生の成長・活躍を目の当たりにした社員のモチベーションアップも狙う
  • テンプレートエンジンのSmarty+jQueryの構成から、JSON APIベースのシステムにreplace
    • コードベースは1から構築した設計で既存のものは破棄前提
    • replaceが完了して利用しなくなった古いコードはリファクタリングデーで削除

フロントエンドの開発方針

当たり前の基準を上げていく

  • 変更ができなくて当たり前→バグ修正できて当たり前→replaceできて当たり前→機能追加ができて当たり前→開発効率改善ができて当たり前、のように「当たり前」の基準を上げていく
  • 「できない理由ではなく、解決する方法を探す」というマインドで解決策を考える
  • マインドばかりがクローズアップされがちだが、技術力が最も試される部分で、技術力が無ければ当たり前基準は上がっていかない
    • こうして解決した事例は開発者ブログで発信、カンファレンスでの登壇にも一部繋がっていくので社員のモチベーションアップにも繋がる
  • 一度組織内で上がった「当たり前基準」は下がらない
    • 社員（開発以外も含む）は全員その「当たり前基準」を覚えている

開発生産性可視化前の課題

  • こういった取り組みで開発は進むようになってきていたが、開発速度の変化はエンジニア以外には伝わりづらい
    • 特に最初の1年程度はプロダクトに大きな変化は起こらないので、プロダクトの変化から実感できない
    • エンジニア以外の人はエンジニア側の「開発が進んでいる」という言葉を信じるしかない
  • エンジニア側は開発が進んでいる実感はあったものの、客観的に見てどうなのかが分かっていなかった
    • この点を開発生産性の可視化で解決できないか模索

開発生産性と可視化について

  • 目的は開発速度を向上させることで、開発生産性を上げることではない
  • しかし開発速度を向上させようとすると、開発生産性の数値は勝手に上がるはず
    • そもそも開発生産性の数値が上がっていないなら、やり方を間違えている可能性が高い
    • 自分たちのやっていることが正しいかどうかを知る上で可視化は重要
  • 開発生産性が高い組織はできることが増え、社員のやる気も増加する
    • 単純にグラフが上がっているとモチベーションが上がるというのもあるので、その意味でも可視化はするとうれしい
  • 開発生産性の可視化はエンジニア以外、特に経営層への説明を雰囲気ではなく、事実で説明しやすくできる
    • 開発者ブログでも年末の振り返りで公開することで、社外の人からも開発チームの状況が分かるようにできる
    • 2023年のグラフは既に公開済み

開発生産性の可視化事例

開発生産性の数値との付き合い方

  • 数値の向上を組織目標にはしない
    • 組織の目標として持つとハックするincentiveが働いてしまうので組織目標にはしていない
      • 例：休日前にPRを作成しないなどPRを作成するタイミングを調整する、QAを適当にしてmergeを急ぐ、分けるべきでないPRを分割するなど
      • これらの行動は本質的ではないが、数値目標として持つとやりたくなってしまうし、実際簡単にできてしまう
    • チーム目標や個人目標で持つことは問題ないし、振り返りで使うことも推奨
      • 開発効率を上げるために活用することは推奨
  • 数値を追うのではなく、振り返りで結果だけを見る
    • 例：結果として1 PRのサイズが大きいものが多かった、レビュー速度が遅かったなど
  • 技術的に誤った方向で努力しても無駄なので、技術的に誤った方向に行っていないかの方が重要
    • 長期のプロジェクトはDesign Docを書いて方向性をそろえておく
    • 技術的に問題ないか全員でレビューを行う
  • 会社の事情もあるので、必要以上に追いすぎない
    • 詳細は次で

PR TIMESの事情

  • 休日前はデプロイ不可、長期休暇前はコードフリーズ期間などが存在
    • 多くの会社にあると思います
  • 平日は16時以降のみデプロイ可
    • 午前中はプレスリリース配信が多く、上場企業は東証が閉まる15時以降にプレスリリースを公開することも多いため、16時までは原則デプロイ不可
  • デプロイ前のQA必須
    • QAチームのリソースだけでは足りないため、開発メンバーのQAも実施
  • 学生インターンが多い
    • 現在過去最大で10人程度所属
    • フルタイムではないため、デプロイタイミング的にmergeまで時間がかかる傾向あり
  • これらの事情から一定以上は数値が改善しない
    • チームにもよるが、既にPR TIMESの開発組織のボトルネックはこの辺りの事情に移ってきており、数値改善に重きをおいていない

可視化して実際に分かった実例

  • PRのサイズが大きいプロジェクトチームが判明
    • 会話したところ1つのJiraのチケットに対して1つのPRを作るルールだと勘違いしているメンバーがいたことが分かった
  • 2月にPR作成数などが落ち込む
    • 旧正月のタイミングで帰国するベトナム国籍の社員が多いため
  • レビューが特定の人に偏りがち
    • 気付いていたことが可視化された
    • 現時点では改善予定はないが、今後何かする可能性はある

最後に

  • 開発生産性の可視化で色々なことが分かったし、説明もしやすくなった
    • モチベーション増加にも繋がっている
  • ただ最も重要なのは「プロダクトを技術的に正しい方向でよりよくできたか」
    • それができていれば開発生産性は勝手に上がるはずだし、できていなければ開発生産性は上がらない
    • 開発生産性の数値だけは改善しているのに、プロダクトが良くなっていなければ意味は無いし、技術的に正しい方向でなければ必ず行き詰まる
    • 開発生産性との適切な付き合い方を各社考えるとよいと思います！
チーム体制 開発 勉強会
  • URLをコピーしました！

この記事を書いた人

金子 達哉のアバター 金子 達哉 CTO

株式会社PR TIMESでCTOをやっています。がんばります。

この著者の記事一覧へ

関連記事

目次