ケント・ベック氏講演録：『グッドハートの法則は楽観的すぎた〜開発生産性の罠と未来〜』
開発生産性カンファレンス
2025/07/03 Keynote:
開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった
はじめに：25年ぶりの来日と生産性への問題意識
25年ぶりに来日しました。かつて『エクストリーム・プログラミング（XP）』の本が日本の書店に平積みされているのを見て、とても嬉しかったことを覚えています。（サインしようとして店員に怪しまれ、逃げたという面白いエピソードもありましたが。）
今日は「開発生産性」について話します。より多く、より早く作れば生産性は向上するのでしょうか？ドイツには「物事を良くしようとして、かえって悪化する」という趣旨の言葉がありますが、まさにそれが生産性の議論で起きています。特にAIの登場は、この問題をさらに悪化させるのではないかと懸念しています。
核心的な問題：グッドハートの法則とその限界
開発生産性の議論の中心には、常に「グッドハートの法則」があります。
グッドハートの法則：ある測定値が目標として設定された途端、それは良い指標ではなくなる。
例えば、もし統計的に「生産性の高いプログラマーはタイピングが速い」という相関が見つかったとします。しかし、経営者が「よし、全員タイピング速度を上げろ！」と目標に設定した瞬間、人々は生産性を高めることではなく、ただタイピング速度を上げるためだけの行動を取り始めます。本来の目的との相関は失われ、指標は意味をなさなくなるのです。
これは経済学でも見られました。かつて中央銀行は金利操作によってインフレをコントロールしようとしました。短期的には成功しましたが、市場参加者（借り手）がその操作に適応し始めると、金利というレバーは効果を失っていきました。
しかし、私はソフトウェア開発の世界を見ていて、「世界はグッドハートの法則が主張するよりも、もっと悪い状況にある」と感じるようになりました。
なぜ「グッドハートの法則は楽観的すぎる」のか？
法則は「指標が役に立たなくなる」と主張しますが、現実はもっと深刻です。「プレッシャー（圧力）」を伴う指標管理は、システムそのものを破壊するからです。
例を挙げましょう。良いプログラマーは、一般的に小さなプルリクエスト（PR）を作ります。小さなPRはレビューしやすく、欠陥が混入しにくく、他者との協調を促進します。これは良い傾向です。
では、リーダーが「全員、PRを小さくしろ！」とリーダーボードで競わせたらどうなるでしょう？それは「終わりの始まり」です。エンジニアは「協調しやすく、品質の高い変更」を目指すのではなく、「リーダーボードで最下位にならないために、意味もなくPRを分割する」というハックに腐心し始めます。本来の目的は忘れ去られ、システムは歪んでいくのです。
「コード行数を指標にすれば、無意味な行数が水増しされる」
「インシデント数を指標にすれば、インシデントが報告されなくなる」
このように、プレッシャーを伴う指標管理は、人々の善意や倫理観を蝕み、システム全体を目標から遠ざけてしまうのです。複数の指標でバランスを取ろうとしても、複雑さが増すだけで、人々は新たなハックを見つけ出すでしょう。
では、どうすればいいのか？：「終端」で測定せよ
私は測定を否定しているわけではありません。開発する限り測定は不可欠です。しかし、「レバーとして操作する」のではなく、「理解のために使う」のです。
解決策のヒントは、価値が生まれる連鎖（バリューチェーン）にあります。
Effort（工数） → Output（生成物） → Outcome（成果） → Impact（影響）
Effort（始端）: 投入時間など。測定は非常に容易だが、指標にすると歪みが最大になる。「週100時間働け」は最悪の例。
Impact（終端）: ビジネス上の利益（ROI）など。測定は非常に困難だが、指標にしても歪みは最小になる。
原則：バリューチェーンのできるだけ「終端」で測定せよ。
始端に近いものを測定すればするほど、「終わり」は近づいてきます。
Outputの測定: 作成したオブジェクトの数？ それが何の価値を生んだかは分かりません。
Outcomeの測定: ユーザーの行動変容を観測する。「この機能でユーザーの〇〇という作業が速くなった」など。これは良いアプローチです。
Impactの測定: 「プログラマー一人当たりの利益」など。直接測定は難しいですが、これが究極の目標です。
投資家がプログラマーの価値を判断するとき、PRの数など気にしません。投資に対するリターン（ROI）を見ます。我々もその視点を持つべきです。
AI時代における生産性と「学び」
AIの登場で、若手プログラマーの仕事が奪われるという懸念があります。しかし、AIを「常に自分に合わせてくれる家庭教師（チューター）」として活用すればどうでしょう？ 若手はAIに無限に質問し、説明を受けられます。
この時、私たちは何を見るべきでしょうか？ AIによって増えたコードの量（Output）でしょうか？ いいえ、若手の「学び」（Outcome） こそが重要です。これもまた、測定しにくいですが、真に価値のあるものです。
リーダーへのメッセージ
1. 測定せよ、ただしレバーとして使うな: 測定は理解のために行い、安易なコントロールの手段にしてはいけません。
2. 終端で測定せよ: 開発チームの活動を、ビジネス上のインパクトや顧客の成果（Outcome / Impact）に結びつけて評価せよ。
3. プレッシャーではなく、気づきを促せ: チームが自ら改善点に「気づく」ための情報を可視化し、提供せよ。リーダーボードで競わせるのではなく、内発的な動機付けを支援せよ。
4. 大局に立て: リーダーは、個々の指標に一喜一憂せず、チームの情熱やパフォーマンスが全体のインパクトにどう繋がっているかという大局的な視点を持つ責任があります。