開発フェーズごとの開発生産性の指標・ゴールとその理由
開発組織の生産性と一言で言っても、「次のステップでどうしたらいいのかわからない」「自社にとっての開発生産性とは何かの定義からスタート」という方も多いのではないでしょうか。
Offers MGRで顧客と話す中で得られた、各社が抱えている「指標・ゴール設定における課題とその解決策」についてご紹介します。
誰向けの記事か
- これから開発生産性指標を定めていこうとしている方
- 開発生産性指標についてインプットしている方
- 開発に関するマネジメントをインプットしている方
伝えたいこと
- 指標を設定する前に何を目指すか・ゴールを設定する
- 各指標の意味を理解して、設定することが大事
- 指標ごとのメリデメ
各指標をチーム、組織全員で理解し、「開発生産性を向上させることでの顧客・ユーザーへの提供価値が上がり、事業成長に貢献する開発組織」であること を皆で追いかけていけるようにしましょう。
自社・チームに合わせた生産性の指標を決めて、開発生産性可視化に取り組むきっかけ・参考になれば幸いです。
開発生産性とは
開発生産性とは、弊社では「開発組織が持続的に顧客に価値提供ができ、より効率的に売上・利益に転化していくための尺度（基準）」、だと考えています。
「開発組織が持続的に顧客に価値提供ができ、より効率的に売上・利益に転化していくための尺度（基準）」
効率
開発生産性は、時間とリソースをどれだけ効率的に使って成果を出せるかについての評価です。例えば、同じ時間とリソースを使って、チームAがプロダクトを2つ作り上げた一方で、チームBが1つしか作り上げられなかった場合、チームAの方が生産性が高いと言えます。
品質
ただ早くリリース、業務を終わらせるだけでは生産性が高いとは言えません。プロダクトの品質も重要な要素です。バグが多い、ユーザー体験が悪い、または保守が難しいソフトウェアを速く作るよりも、少し時間がかかっても品質の高いソフトウェアを作る方が、長期的に見れば生産性が高くなる可能性があります。
持続可能性
開発生産性は一時的なものではなく、持続可能であるべきです。チームが過労で燃え尽き症候群（バーンアウト）を起こさずに、一貫して高いパフォーマンスを維持できるかどうかも、生産性を評価する重要な要素です。
では、これらを満たすための指標やゴールはどう決めていくのがいいのか考えます。
弊社CTOがSPACEなどに関しての連載をおこなっております。
ゴール設定・事前に決めること
前提、指標を何のために設定するのか、決定するまでのフローにはどういう思考プロセスがあるのかを整理します。
指標を決める上での5つのポイント
- パフォーマンスの可視化: 生産性指標は、開発プロセスやチームパフォーマンスを可視化し、理解するための効果的なツールです。これにより、組織全体がチームの状況を客観的に把握し、適切な意思決定を行うことができます。
- 改善をモニタリング: 特定の開発プロセスやアプローチの改善をモニタリングできる、評価することができる。新しいツールの導入、新しい開発プロセスの試行、トレーニングプログラムの効果など、組織の改善施策の結果を評価するために重要です。
- 目標設定: 開発チームが達成すべき具体的な目標を設定することは、動機づけと成果の追求を促します。生産性指標を設定することで、これらの目標を明確にし、達成に向けた進行状況を追えます。
- リソース管理: 限られたリソースを最も効果的に使用するためには、生産性指標が不可欠です。これにより、リソースが必要とされているエリアや、最大の効果を得るためにリソースを再配分すべきエリアを特定することができます。
- 透明性と信頼性の向上: 透明な生産性指標を共有することは、開発組織に関わるステークホルダーや他の組織との信頼性を向上させます。全体的なコミュニケーションと協力が組織の改善と円滑な情報共有を促し、チームを全体で向上させていくことに役立ちます。
指標の決定の流れ
開発組織も事業・プロダクトKPIを伸ばすことが大事であり、そのために、
開発・デザインのスループット
モニタリングのためにFour Keys、d/d/d（deploy/a day/a developer）、PRリリース数、デザインの作成件数などを指標とする
プロダクト品質
モニタリングのためにFour Keysを指標とする
プロダクトディスカバリー
の大まかに3点が重要です。プロダクトディスカバリーはプロダクトマネジメントの話なので、今回は開発生産性の話とは切り分けて考えます。
開発組織のゴール設定は、複雑な指標にしても追いきれないので、シンプルにする。とはいえ、細かすぎると目標設定時などに個人が関連する目標を設定しづらいので調整は必要です。
開発組織の指標の選択と何をなぜどう見るのか
PRリリース数・マージ数
理由
事業・プロダクトのアーリーフェーズでは市場・顧客に受け入れられるためにまずはリリース量、機能改善速度が重要である。とはいえ、分けることが難しい機能もあるのでバランスを見て判断する
何を見るか
Offers MGRではピープルサマリでGitHubのPRマージを見る
どう見るか
- 一人当たりのPRマージ数が伸びているか（d/d/d（deploy/a day/a developer））
- 月次あたりのPRマージ推移が伸びているか
- 伸びてなければFour Keys、サイクルタイムのリードタイムを見る
Four Keys
理由
プロダクト開発組織が5-10名以上になると、多くのチームが複数チームに分割となる。その際にデプロイ、リードタイム、障害のバランスをみてプロダクト・開発組織の総合的なポイントを把握する
何を・どう見る
- Four Keysの4指標を見て、プロダクトが開発初期段階（0-1, PMF前）ではデプロイ頻度が優先される
- パフォーマンスレベルがHigh以上ではない場合
- 変更のリードタイム、変更障害率等、他の指標のレベルを確認しリリースが行われるまでの間に、ボトルネックが存在してないかを確認する
- Four Keysだけでなくサイクルタイム分析など、他分析機能・数値を確認しDevOpsに改善余地がないかを確認する
- ビックバンリリースが行われている場合、小さくリリースをできるよう開発フローの見直し、改善を行う
- CanaryReleaseやFeatureFlagsなど分割リリースができるサービス構成も合わせて検討する
- 一定の顧客がおり、プロダクトを安定的に提供したい場合、変更障害率・修復時間も合わせてみる
- 変更障害率・修復時間のパフォーマンスレベルがMiddle以下である場合
- 機能リリース前のQA体制を強化するなど、品質管理体制の強化を行う
Four Keysのそれぞれの基本を知りたい方はこちら。
サイクルタイム
理由
- Four Keysのデプロイ頻度・変更のリードタイムを合わせてみる
- デプロイ頻度・変更のリードタイムと影響があるから
何を・どうみる
- 開発プロセスの中でどこが課題なのか確認する
- プロセスごとにより施策が異なる
- 個々人で課題の傾向があるかを確認する
- 1on1などでフィードバック
Four Keysとサイクルタイム分析を合わせて確認することで、プロダクト開発組織を複合的に可視化・把握することができる。開発組織の状態を言語化し、前進させるためにチームの権限移譲・チーム内での自律駆動性を養う意味で重要である。
コミュニケーション分析
理由
- 生産性を向上させる上で、開発プロセスの中での仕事の進め方は重要である
- 個人への負荷の偏り、特定個人のリーダーシップで成立しているケースがある
何を・どうみる
- チーム平均、同規模企業平均を見て、平均以上になっているひとの仕事の進め方を確認
- 業務プロセス、業務効率化ができそうかアイデアを探す
- 負荷の高い人のポジションでの採用を進める
- 平均以下の人が多く、生産性に影響がある場合
- 負荷を分散できるように、権限移譲する。
- そのために個人のビジョン、ミッションをヒアリングし、マネジメントに興味がある人・やってみたい人を増やす
- マネジメント人材の採用を行う
最後に
開発組織の課題がわからないから課題を発見したい、開発組織の生産性を上げたい という場合に前提としてなぜ上げたいのか・課題発見したいのかを言語化しておくことをお勧めします。
課題発見して、売り上げを上げるのか・組織の生産性を上げるためのアクションを整理したいのかなど何をすべきかが変わってきます。
🤞告知コーナー
副業・転職なら
開発者、マネージャー向けのイベントを定期的に開催しています。ぜひ、グループへの登録をお願いします。
一緒に開発をやりましょう!
Discussion