「開発チームの生産性が上がっているのか、それとも停滞しているのかが分からない」——プロダクトの開発責任者から、よく聞く悩みです。生産性を感覚で語ると、改善の打ち手も感覚的になり、効果が検証できません。まず必要なのは、生産性を指標で捉える（計測する）ことです。

とはいえ、いきなり複雑な計測基盤を作る必要はありません。この記事では、開発生産性の代表的な指標である Four Keys を起点に、何を測り、どう改善につなげるかを手順で解説します。生産性は体制づくりと不可分なので、開発を内製化する進め方やコードレビュー体制の作り方もあわせて読むと、改善の打ち手が具体化します。

なお筆者・馬込は、開発体制の再構築やリリース頻度の改善に携わり、指標を見ながら開発プロセスを整えてきた経験があります。本記事はその実務目線でまとめています。

結論：まずFour Keysで「今の状態」を可視化する

生産性の議論は、共通のものさしがないと噛み合いません。まずは広く使われる Four Keys で現状を可視化し、そこから改善の的を絞ります。①指標を決める → ②今の値を測る → ③ボトルネックを1つ改善する、という順で進めます。

手順1：測る指標をFour Keysから決める

Four Keys は、開発チームのパフォーマンスを捉えるために広く参照される4つの指標です。まずはこれを共通のものさしにします。

指標 何を表すか
デプロイ頻度 どれくらいの頻度で本番リリースできているか
変更のリードタイム コードを書いてから本番に届くまでの時間
変更失敗率 リリースが障害・切り戻しにつながる割合
復旧までの時間 障害から回復するまでにかかる時間

最初の2つ（デプロイ頻度・リードタイム）は「速さ」、後の2つ（失敗率・復旧時間）は「安定性」を表します。速さと安定性の両面を見るのがポイントで、片方だけを追うと、速いが壊れやすい／安定だが遅い、という偏りに気づけません。

手順2：まず「今の値」をざっくり測る

指標を決めたら、完璧な計測基盤を待たず、まず今の値を粗くでも把握します。目的は精密な数値ではなく、改善の出発点（ベースライン）を持つことです。

  • デプロイ頻度・リードタイムは、リリース履歴やプルリクエストの記録から概算できる
  • 最初は手集計でよい。傾向が見えれば十分
  • 「速いつもりだったが実はリードタイムが長い」といった思い込みとのズレを発見する

ここで大切なのは、指標を個人の評価に使わないことです。評価に使うと、数字を良く見せる操作が始まり、計測が機能しなくなります。あくまでチームの改善のために測ります。

手順3：ボトルネックを1つ選んで改善する

ベースラインが取れたら、一度にすべてを良くしようとせず、最も詰まっている一点を選んで改善します。

  • リードタイムが長いなら、その内訳（レビュー待ち・テスト・デプロイ作業）を分解して原因を特定する
  • レビュー待ちが長ければ、プルリクエストを小さくする・レビュアーを増やすなどで手を打つ
  • 改善後にもう一度測り、効果が出たかを確認する

この「測る→一点を直す→また測る」のループが回り始めると、生産性の改善が感覚ではなくデータに基づくものになります。

手順4：測った数字をチームでどう扱うか決める

指標を導入するとき、技術的な仕組みより難しいのが**「その数字をチームでどう扱うか」**です。ここを決めずに測り始めると、計測そのものが敵視され、続きません。

最初に明言すべきは、この数字は個人の評価には使わないということです。評価に使われると分かった瞬間、人は数字を良く見せる行動を取ります。デプロイ頻度を上げるために意味のない小さなリリースを刻む、変更失敗率を下げるためにリスクのある改善を避ける——指標が目的化すると、本来良くしたかったものが悪化します。

扱い方 結果
チームの改善のために使う ボトルネックが見え、素直に議論できる
個人・チームの評価に使う 数字合わせが始まり、計測が形骸化する

そのうえで、数字は「議論の出発点」であって「結論」ではないと共有しておきます。リードタイムが長いという事実は、誰かが怠けている証拠ではなく、どこかの工程が詰まっているサインです。数字を見て人を責めるのではなく、工程を責める。この姿勢が共有されていると、チーム自身が「ここが詰まっている」と言い出せるようになり、改善が自走し始めます。

よくある落とし穴

  • 指標を個人評価に使う：数字を良く見せる操作が始まり、計測が形骸化します。チームの改善のために使います。
  • 完璧な計測基盤から作ろうとする：着手が遅れます。まず手集計でベースラインを取ります。
  • 速さだけを追う：安定性を見ないと、速いが壊れやすい状態に陥ります。両面を見ます。
  • 一度に全部を改善しようとする：焦点がぼやけます。最も詰まった一点から。
  • 短期の数字で結論を出す：改善が数字に表れるには時間差があります。1〜2週間ではなく、数か月の傾向で判断します。

よくある質問

Q. Four Keys以外にも測るべき指標はありますか？ A. あります。ただし最初から多くの指標を追うと運用が破綻します。まずはFour Keysで速さと安定性を捉え、必要に応じてレビュー時間やテスト自動化率などを足すのが現実的です。指標は「改善の打ち手につながるか」で選びます。

Q. 小さいチームでも生産性の計測は意味がありますか？ A. あります。むしろ小さいチームほど、ボトルネックが一点に集中しやすく、計測で見つけやすいです。手集計でもベースラインを取れば、改善の効果が実感でき、次の打ち手を判断できます。

Q. 計測を始めても、数字が改善しません。何が問題ですか？ A. 指標を見ているだけで、ボトルネックへの具体的な打ち手に落とせていないことが多いです。リードタイムなら内訳を分解し、どの工程が長いかまで特定します。原因まで下りて初めて、改善の手が打てます。また、改善しても数字に表れるまでには時間差があります。1〜2週間で結論を出さず、数か月の傾向で見るほうが、実態を正しく捉えられます。

開発生産性は、①Four Keysで指標を決める ②今の値をざっくり測る ③ボトルネックを1つ改善する、という手順で、感覚から抜け出して改善できます。大がかりな基盤より、まず粗くても測り、一点を直すループを回すことが出発点です。

開発プロセスの改善や体制づくりの相談は、開発支援について相談するからお問い合わせください。