前回の連載はこちらから。
「数字で示せ」と言われたあと、現場で起きること
DMMの開発現場でも、指標の話は次のような着地になりがちです。
リーダーが「開発生産性 指標」と検索すると、コード行数、機能リリース数、ストーリーポイント、デプロイ頻度、変更のリードタイムといった候補が並びます。どれも一理ある。どれも完璧ではない、という感触だけが残ります。エンジニアはプルリクエスト（PR）数やデプロイ頻度、プロジェクトマネージャー（PM）はユーザー価値やリリースの予定どおりさ、QA（品質保証）はバグの少なさとテスト時間、管理職は売上貢献とコスト効率を見ています。同じ「開発生産性」という言葉を使って会議しても、分子も分母も、そもそも何を良くしたいのかが揃っていない。テックリードはコードの複雑度と見積もり精度のずれを示しても、スピードが落ちているとしか受け取られないというもどかしさがあります。技術的負債の返済に時間を使うべきだとわかっていても、新機能が優先され、説明の言葉が届かない。数字が求められるほど、測れない価値のほうが見えにくくなる。
例えば、DMM内のチームでも普段の振り返りの場で、開発生産性に関する付箋を見てみると「時間が足りない」「仕様変更が多い」といった指摘が上がってきます。
そうなるとチーム目標として数値の目標を準備して対応しますが、ストーリーポイントを水増しして見積もりを合わせたり、簡単なタスクばかり選んでベロシティを稼いだり、リリース頻度だけ見られるから小さな変更を細切れに出したりします。リファクタリングや技術調査は評価に乗りにくく、誰も手を出さなくなります。数字を上げる仕事と、本当に必要な仕事のあいだに溝ができ、それは次第に広がっていきます。計画の信頼性を取り戻すために指標をそろえようとしたはずが、指標そのものが新たな圧力になっているという構図です。
定量化はできる。破綻するのは「一つの数字」に集約すること
開発生産性を定量化できないというより、一つの数字に閉じ込めようとすると破綻するという見方のほうが現場に近いです。
立場が違えば、分子と分母も違う
開発生産性は、アウトプットをインプットで割った比率として語られがちです。分子にコード量を置くか売上を置くか、分母に人数を置くか人月を置くかで、出る数字の意味は変わります。広木大地さんの整理では、仕事量としてどれだけこなしたか（レベル1）、価値があると期待して選んだ施策をどれだけ届けたか（レベル2）、売上やKPIへの実貢献（レベル3）の三階層に分けて考えるとすれ違いが減るとされています（「開発生産性について議論する前に知っておきたいこと」)、Qiita、2022）。経営の関心はレベル3に寄りやすく、現場の会話はレベル1に聞こえやすい。レベル3が低いからといって、すぐにレベル1の効率だけが悪いとなるわけではありません。
物的生産性は労働時間あたりのコード行数やリリース数のように数値化しやすい一方、品質や価値は乗りにくい。付加価値生産性はユーザー価値や事業への貢献に近いが、結果が出るまで時間がかかる。どちらか一方だけを追うと、もう一方の話が消えます。
数値指標が先行指標になると危ない
グッドハートの法則は、指標が目標になるとその指標は機能しなくなると述べています。キャベルの法則も、状態が数値を作るのであって、数値が状態を作るわけではないと指摘しています。Petersenらの体系的レビュー（2011）でも、単純な output/input 比は歪みを生み、メトリクスを評価に直結させるとゲーミングを誘発しやすいと繰り返し報告されています。ストーリーポイントの水増し、PRの細切れ、レビューを薄くしてマージ数を稼ぐ。いずれも指標を上げるための行動であり、本質的な改善とは別物です。
指標を改善しても、事業の成果に接続しないことがあります。Faros AIのThe AI Productivity Paradox（2025）では、1,255チーム・1万人超のテレメトリを分析し、タスク完了数やマージPR数は伸びても、組織レベルのスループットや品質KPIには有意な改善が見られず、PRレビュー時間の増加やバグ発生率の上昇が報告されています。
チームの活動量だけが改善したように見え、価値が顧客に届くまでの流れのボトルネックに吸収される、いわゆる消える生産性の例です。PR数は伸びたのに組織の成果に届かないのは、グッドハートの法則が組織規模で起きている状態と言えます。
AIで実装の入口が速くなるほどコード量やPR数は伸びやすく、活動量指標だけが良くなったように見える罠が強まります。一方で、リファクタリングや技術的負債の返済は数字に乗りにくく、測れないから説明できないという不満が残ります。連載第3回では、技術的負債の誤解としてこの壁に触れます。
信頼が積み上がっているときは、意図したタイミングで成果物が届くことが重視されます。遅延が続くと、なぜ遅れたのか説明できない不安から、数字で測ろうとする圧力が強まります。数値は信頼の代替にはなりにくく、測り方を誤ると信頼を削ります。追う数値だけを先に立てると、チームの改善が組織の成果に届かないまま、見かけの指標だけが先行していきます。
測るなら「対」と「束」で
DORA（DevOps Research and Assessment）のFour Keysは、デプロイ頻度と変更リードタイムでスピードを、変更失敗率とサービス復元時間で安定性を捉え、どちらか一方だけを追わない設計です（DORA metrics guide）。フォースグレンらのThe SPACE of Developer Productivity（ACM Queue, 2021）も、満足度、成果、活動量、コミュニケーション、効率の多次元で見るべきだとしています。単一指標の代わりに、緊張関係を含めた指標の束を選ぶことが、定量化の現実的な形です。
DORAとSPACEは対立する指標ではなく、重ねて使う枠組みです。ざっくりした違いは次のとおりです。
| 観点 | DORAメトリクス | SPACE |
|---|---|---|
| 何を測るか | DevOpsのスピードと安定性 | 開発者の生産性とウェルビーイング |
| 焦点 | ソフトウェアを速く、信頼性高く届ける | チームが生産的で健全に働けること |
| 考え方 | スピードと安定性を対で捉える | 満足度と成果をセットで捉える |
| 向いている場面 | デリバリー速度を上げたいエンジニアリング組織 | 開発者体験と協働を重視する組織 |
| 使い方を誤ると…… | 品質を欠いたスピード追求が燃え尽きを招く | ソフトな指標だけではプロジェクト成果がぼやける |
| いつ使うか | DevOpsパフォーマンスの最適化 | 開発者へのより良い体験の設計 |
DORAとSPACEはセットで使うのが前提です。DORAだけを公式指標にすると、デプロイ頻度やリードタイムは改善してもレビュー待ちや障害対応で開発者の負荷が増え、満足度が落ちていることに気づきにくくなります。SPACEだけを重視すると、サーベイ上の満足度やチームの雰囲気は守れても、変更が本番に届くまでの遅れや失敗率の悪化には届きにくい。DORAは届け方の速さと壊れにくさを、SPACEはその速さを支える人と仕組みの状態を別のレンズで見る枠組みです。
重ねるときの役割分担はシンプルです。DORAでスピードと安定性の対を追い、どちらかが悪化していないかを確認する。SPACEで満足度、成果、活動量、協働、効率の束を見て、活動量だけが伸びていないか、満足度が先に削られていないかを確認する。デプロイは増えたが活動量の水増しで疲弊している、リードタイムは短いが失敗率が上がっている、といったずれは、片方の数字だけでは見逃しやすい。
どちらか一方を全社の公式指標にしないことが大切です。経営向けにはDORAの四指標を、チーム改善の場ではSPACEのサーベイやワークフロー指標を、それぞれの目的に合わせて使い分けることをお勧めします。対と束をセットにしたダッシュボードは、単一指標の誤解を防ぐための補正レンズとして機能します。
開発生産性の誤解について、体系的に解説した書籍が出ます！
