本記事は50社以上の成長支援を手がけるKPIコンサル・岩田圭弘が解説します。
開発チームは動いている。エンジニアも忙しそうにしている。それなのに「機能が世に出るのが遅い」「障害が減らない」——多くの経営者がこの違和感を抱えている。原因は、開発組織のKPIが「ベロシティ（消化ポイント）」や「コミット数」といった活動量で止まっているからだ。活動量は事業成果と連動しない。本記事では、Four Keysを軸に開発生産性を「事業に効く数字」へ変える3層フレーム、主要KPIのベンチマーク、そして今日から動かせる先行指標の作り方までを整理する。
開発組織のKPIが形骸化する3つの原因
開発KPIが機能しない失敗パターンは、ほぼ次の3つに集約される。
1. 「活動量」を成果と勘違いしている
コミット数、消化ストーリーポイント、稼働時間——これらは「頑張った量」であって「価値が届いた量」ではない。ベロシティを追い始めると、チームは見積もりを水増しして数字を作る。KPIが行動を歪める典型だ。
2. 品質と速度を分けて測っている
「速く出す」ことだけを追うと障害が増え、「品質を守る」ことだけを追うとリリースが止まる。速度と安定性はトレードオフではなく両立指標として一組で見なければ、どちらかが必ず犠牲になる。
3. 現場が「自分では動かせない数字」を渡されている
「リードタイムを短くしろ」と言われても、何を変えれば縮むのかが見えなければ現場は動けない。遅行指標だけを掲げ、その手前の行動指標を設計していないKPIは、掛け声で終わる。
3層フレームで設計する：KGI→遅行KPI→先行KPI
開発KPIは「事業のゴール（KGI）」から「今日の行動（先行KPI）」まで一本の線でつなぐ。Four Keysは主に中間（遅行）KPIに位置づけ、その手前に現場が動かせる先行KPIを置くのが要点だ。
| 層 | 問い | 指標の例 |
|---|---|---|
| KGI（最終成果） | 事業にどう効いたか | リリース起点の売上・解約率・NPS／開発ROI |
| 中間KPI（遅行） | デリバリーは速く・安定しているか | デプロイ頻度／変更リードタイム／変更失敗率／MTTR |
| 先行KPI（行動） | 今日、何を変えるか | PRサイズ／レビュー待ち時間／WIP数／CI成功率／デプロイ自動化率 |
ポイントは、Four Keys自体をゴールにしないこと。デプロイ頻度が上がっても事業価値が届かなければ意味がない。あくまでKGI（事業成果）への先行指標としてFour Keysを置き、さらにその先行指標として現場の行動KPIを設計する。
主要KPIとベンチマーク目安
開発組織で押さえるべき指標と、DORA（DevOps Research and Assessment）の調査などから導かれる実務目安をまとめる。種別（先行／遅行）を必ず意識して使い分けたい。
| KPI | 種別 | 定義 | ベンチマーク目安 |
|---|---|---|---|
| デプロイ頻度 | 遅行（成果） | 本番リリースの回数 | 週1回以上（理想は1日複数回） |
| 変更リードタイム | 遅行 | コミットから本番稼働まで | 1週間以内（上位は1日未満） |
| 変更失敗率 | 遅行 | 障害・ロールバックを招いた変更の割合 | 15%以下 |
| 平均復旧時間（MTTR） | 遅行 | 障害発生から復旧まで | 1日未満（上位は1時間未満） |
| PR（変更）サイズ | 先行 | 1PRあたりの変更行数 | 200〜400行以下 |
| レビュー待ち時間 | 先行 | PR作成〜初回レビュー着手まで | 数時間以内 |
| WIP（仕掛り数） | 先行 | 1人が同時進行するタスク数 | 1〜2件 |
| CI成功率 | 先行 | 自動テスト・ビルドの成功割合 | 90%以上 |
| デプロイ自動化率 | 先行 | 手動作業を伴わないリリース比率 | 95%以上 |
上位4つがFour Keys（遅行）、下位5つが「その数字を動かすための行動（先行）」だ。遅行KPIだけを壁に貼っても現場は動けない。必ず先行KPIとセットで運用する。
KSFは「比較」から見つける
「どの指標を改善すれば最も効くのか（KSF＝重要成功要因）」は、理屈で逆算するより比較で発見する方が速く、外さない。
やり方はシンプルだ。同じ組織の中で、リードタイムが短いチームと長いチームの行動データを並べる。すると差が出る変数が浮かび上がる。多くの現場でボトルネックになっているのは、コーディング時間ではなく「レビュー待ち時間」と「PRサイズの大きさ」だ。速いチームはPRが小さく、レビューが数時間で回り、大きいチームは1PRが数千行でレビューが数日滞留している——この差分がKSFになる。
ハイパフォーマーと平均の差分を測る。これがKSF発見の王道であり、机上で「たぶんこれが重要だろう」と決め打ちするより遥かに確度が高い。
先行指標の作り方
先行指標を設計する条件は3つ。①現場が自分で動かせる ②遅行KPIと因果でつながっている ③日次〜週次で観測できる。
たとえば「変更リードタイム（遅行）」を縮めたいとき、逆算して手前の行動を分解する。
- リードタイム＝コーディング時間＋レビュー待ち時間＋マージ待ち時間＋デプロイ待ち時間
- このうち実測すると滞留の大半は「レビュー待ち」と「デプロイ手作業」に集中している
- よって先行KPIは「レビュー待ち時間（数時間以内）」「PRサイズ（400行以下）」「デプロイ自動化率（95%以上）」に設定する
先行KPIは「これを動かせば遅行KPIが動く」という因果の仮説だ。動かしても遅行が変わらなければ、その先行KPIは間違い。KPIは設計して終わりではなく、因果を検証しながら差し替えるものだと掴んでおきたい。