こんにちは。Findy Tech Blog編集長の高橋（@Taka_bow）です。
2025年7月3日、ファインディ主催の開発生産性Conference 2025にて、エクストリームプログラミング(XP)の提唱者として知られるKent Beck氏による基調講演が行われました。
本記事では、Findy Conferenceで公開された講演動画とともに、全文の日本語文字起こしをお届けします。前編では、グッドハートの法則の本質と、それが開発現場でどのように機能するのかを解説します。
後編はこちら tech.findy.co.jp
講演動画
※ 視聴には Findy Conference へのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。
講演について
Kent Beck氏は、アジャイル開発の礎を築いた開発者として世界的に知られています。
1999年に出版された『エクストリームプログラミング』は日本でも大きな反響を呼び、25年ぶりの来日となりました。
また、2024年には『Tidy First? ―個人で実践する経験主義的ソフトウェア設計』が出版され、現代のソフトウェア設計についての思想を発信し続けています。
今回の講演では、ソフトウェア開発の生産性測定におけるトレードオフと、単純な指標のリスクについて語られました。
講演タイトルの「グッドハートの法則はもっと悲観的に捉えるべきだった」は、イギリスの経済学者チャールズ・グッドハートが提唱した「指標が目標になると良い指標ではなくなる」という法則を指しています。
Beck氏はこの講演で、グッドハートの法則が示す問題は、実際にはグッドハートが想定していたよりも深刻であると主張しました。
開発生産性を向上させようとする試みがなぜ逆効果をもたらすのか。AIの台頭によってこの問題はどう変化するのか。リーダーは測定の目的と限界をどう理解すべきか。
Beck氏の講演内容をノーカットでお届けします。
日本語訳全文
オープニング
Kent Beck氏：ありがとう。ありがとうございます。
（会場拍手）
日本に戻ってこられてうれしいです。皆さんのスマホがダンスのように一斉に上がりましたね。練習したみたいに。
（会場笑）
前回日本に来たのはもう25年ほど前になります。「エクストリームプログラミング」が出版された時です。
あの本は…ああ、笑顔が見えますね。日本で非常に人気の本でした。世界のどこよりも日本で人気がありました。
（注：現在発売されているものは、2nd Editionです）
そこ（登壇者控え席）に座って、"どう話を始めようか？"と考えていると、前に来日した時のことを思い出しました。
大きな書店に行くと私の本が山積みで売られていて、"すごくいい気分だ、これが私の本だなんて"と思いました。
私は本にサインしようと１冊手に取りました。⋯⋯お持ちですね、後でサインします。
私は積んである本から１冊を手に取りレジに向かいました。そしてレジの女性にペンを借りてもいいか尋ねました。
彼女は私を見ました。
「違うんです、この表紙は私ですよ」と私は言いました。
（会場笑）
彼女は疑った様子でペンを貸してくれました。
本を開いて私が名前を書き始めると息をのむ音が聞こえました。私が落書きをしているように見えたんでしょうね、本の中にね。彼女は、"信じられない"といった様子で…。
私はただ本を山に戻して店から逃げ出しました。
それが私の前回の日本での経験ですが、戻ってこられてうれしいです。ファインディに感謝します。私を招待しこのセッションを実現させてくれてありがとう。
スポンサーの皆さんにも感謝を。きっとすてきな人々なので彼らの製品を買いましょう。これで、このセッション内での宣伝は終わりです。
開発生産性とは何か
さて、今日は開発生産性について話すよう依頼されました。そして、これは一見とても単純な話に思えます。開発者がいて、彼らは何かを開発する。
生産性が高ければ良いことであり、生産性が低ければ悪いことです。では生産性を上げるには、どうすれば？
これは単純な話ではありません。あるドイツ語の単語があります、発音しませんが、"改善しようとして悪化させてしまう"という意味の言葉です。
開発者の生産性に関して私が何度も目にしてきたのは、物事を改善しようと押し進めることで悪化させてしまうことです。
そして、招待されてから今日までの間にも、AIがその問題を良くするどころか更に悪くしてしまいました。
今日は、ある組み合わせについてお話しします。大事なのは組み合わせです。１つは開発者の生産性です、その定義についてもお話しします。
もう１つは測定の問題、つまり単純な指標が、しばしば意図した効果と逆の結果を引き起こすという問題。そしてAIの使用によりなぜそれが悪化してしまうのか？
最後に、ここにいる皆さんは技術者ですから、"もっと早く"、"もっと生産性を高く"というプレッシャーに直面した時、この問題にどう立ち向かえばいいのか？
今朝、一番上の子どもからメッセージが来ました。あるプロジェクトに30週間かかる予定だったのに、24週間ですべてを終わらせるように、そう指示されたそうです。
私の子ですから、"全部は終わりませんよ"と答えた。"でも、やるんだ"と言われ、"それは私の仕事じゃない"と返す。
私たちが常に直面していることですね。やることが多すぎるのです。そうでなかったら給料をもらいすぎということになる。
やることは常に山積みです。だからどんなに生産性を上げてもプレッシャーが軽くなることはありません。プレッシャーは常にあります。
私はAIを"ジーニー"と呼ぶのですが、それは…。ジーニーとは願いをかなえてくれるものです。願いを３つかなえてくれますが、与えられるものは願ったものとは違います。
かなったように見えるだけです。世界中の金を願ったらその金の下敷きになるとかね。それが今、私たちが扱っているものです。
おかげでこの問題はますます悪化しています。詳しく見てみましょう。
生産性の定義
まずは基本中の基本から。生産性とは何でしょうか？
生産性とは比率です。アウトプットとインプットの比率であり割合です。そして、今はこれ以上詳しくは話しませんが、このあとの測定の問題を話す間、頭の片隅に置いておいてください。
話を戻します、生産性とは何を意味するのか？どうすればそれを悪い方向ではなく良い方向に役立てることできるのか？
マッキンゼーレポートへの批判
２年ほど前のことです。コンサル会社のマッキンゼーが、開発生産性に関するレポートを発表しました。そしてそれは…、言葉を選んで話しましょう。礼儀正しく言えば"世間知らず"でした。世間知らずです。
"開発生産性を上げる"ための提案はどれも、状況を悪化させるものでした。経験ある開発者としては明らかにひどいアドバイスだと思いました。
そこで私は Gergely Orosz と一緒に、かなり話題になっていたこのレポートに対する批評を書きました。その後、解決のためにマッキンゼーに雇われてはいないので、どう解釈すべきか、分かりませんけどね。
これが開発生産性という問題に再び向き合うきっかけになりました。この話は最後にまた触れることにします。
グッドハートの法則
その前にまずお話ししたいのは測定の問題です。なぜ物事を改善しようとした取り組みが事態を悪化させるのでしょう？
ここで、ある古典的な言葉があります。グッドハートというイギリスの経済学者がいました。後ほどお話ししますが、彼はある観察をして、その観察は人類学者によってこう言い換えられました。
"指標が目標になるとそれは良い指標ではなくなる"
これは完全に事実です。こう言われたとします。
"君はプログラマーだな、タイピングはどれぐらい速い？"
"もっと速くタイプしろ"
もし仮にタイピング速度と利益率に相関関係があったとしてもです。開発者はただ座って指をたくさん動かすようになるでしょうね。指を速く動かせば給料が上がるんですから。それは本当に求めていたものではありません。
指標自体は役に立つものですが、指標が目標になった途端、それは良い指標ではなくなってしまうのです。
これは言い換えられたもので、グッドハートの言葉ではありません。本来の彼の言葉は…。舌を噛みそうになる言葉です。
ある仕組みの中で統計的な規則性が観察されたとします。"これが上がると、これが下がる"というような規則性です。
しかし仕組みを制御しようとインプットに働きかけてアウトプットを変えると、その規則性は崩れてしまうのです。
例として、ある時期イングランド銀行が、借入の水準をコントロールしたいと考えていました。インフレ率を調整したかったのです。
そこで気づいたのは、短期金利を上げると借入は減り、短期金利を下げると借入が増えるということです。
統計分析の結果、このような規則性があることは世の理だと分かりました。短期金利が下がると借入が増え、上がると借入が減るのです。
彼らは思いました。
"やるべきことが分かったぞ"
"我々はハンドルを手に入れた"
"金利を上げれば借入を減らせる、下げれば借入を増やせる"
"完璧だ"
これは成功しました。短い間だけはね。
この方法の問題は、意思決定者が自分だけではないということです。銀行は金利を下げたり上げたりできますが、借り手にも選択権があります。
更に他の銀行が新しい金融商品を作って、短期借入金利の影響から顧客を守ろうとします。
最初のうちは確かに金利を上げれば借入は減りました。しかし、しばらくそれを意図的に繰り返していると、金利を上げても借入は減らなくなります。
なぜなら他のプレイヤーがそれに適応してしまうからです。
ここで、"指標が目標になると良い指標でなくなる"というグッドハートの法則の言い換えですが、その下にまた別の層があります。
それが元々グッドハートが言ったことです。
誰も読まないような地味な論文の脚注に書かれました。そんな脚注で有名になるとは、皮肉ですよね。
とにかく、統計的な規則性を見つけ、それを仕組みを制御するために使うと、それはもう制御手段としては機能しなくなってしまうのです。
さて、私はよくグッドハートの法則について話すのですが、それは最近ソフトウェア開発の指標が注目されているからです。
生産性もその１つですね。
深い層にあったグッドハートの元の言葉を見つけられて、うれしかったものです。
そこから考えるようになりました。世界はこれよりもずっと悪い状況なんじゃないかとね。これも悪いですよ。
つまりレバーがあって、それを引くと、最初はうまくいったとしてもしばらくすると何も起こらなくなる。
仕組みを制御できないということですから、これは悪い状況です。
しかし実際はもっと悪いのです。
測定は必要だが、制御のためではない
例を挙げましょう。
私はよく、ソフトウェア開発の測定を行う人たちと議論しているのですが、その際、ソフトウェアの測定方法についてたくさんの指標が提案されているのを耳にします。
先日LinkedInでこれについて少し書きました。私が受けた反応は"あなたはただ…"
⋯⋯何かな？慌てた顔も見えましたが大丈夫です。動かないようにします。（注：ちょっとした機材トラブルがあった模様）
私が指標に懐疑的なことを言うと誰かがこう返しました。
「あなたはただ何も測りたくないだけでしょう」
それは100万％違います。
私は自分のソフトウェア開発プロセスを測定しています。開発を始めてからずっとです。そして非常に価値があると思っています。
自分がやっていることを数値化して分析して解釈できるのですから。
しかしそれは、"このレバーでシステムを制御できる"という感覚とは全く別物です。人と話していて指標を提案されると私は、"でもこの場合はどうなる？"と聞きます。
私はソフトウェア開発というものを理解しようとしていますよ。私たち全員が参加できて、規模が変わっても機能する、魔法のようなプロセスです。
ソフトウェアの驚くべきところは、純粋な知的活動の中で、これほど規模を拡大できるものはないということです。
数学などにも同じような美しさがありますが、１つの定理に100万人の数学者を取り組ませることはできません。数学はそういうものではありませんが、ソフトウェアでは可能です。
さて、私はソフトウェアを測定して理解したい。
プルリクエスト(PR)を見てみましょう。プログラマー１人当たりの１日のPR数を数えることにします。
なぜなら、プログラマーを観察していると、非常に効率的に見える人もいれば、そう見えない人もいます。そして、全員により効率的になってほしいんです。
ここで気づいたのは、優れたプログラマーは小さいPRを多く出す傾向にあります。
小さなPRであれば読むのも簡単で、マージの際に他のPRとの競合も起きにくく、不具合が含まれる可能性も低くなります。読みやすければ、その分チーム全体で協力しやすくなります。
この矢印は小さなPRが多いほど読みやすいということを表しています。コードが読みやすければ協力しやすくなります。
そしてマルのついた矢印は逆相関を意味しています。協力が増えると無駄が減ります。そして時間の無駄が減るほど、PRを作る時間が増えます。
いい仕組みですね。これは自己強化型、または正のフィードバックループです。回せば回すほど速く回せるようになります。
これがすべてではありませんが、ソフトウェア開発で起きていることの一部は説明できます。
今のところは順調ですね。"開発者の１日当たりのPRは多いほど良い"いいですね。
さて、この仕組みに圧力をかけてみます。PRが多いほど良いなら、どう増やすか？圧力をかけます。
ではランキング表を作りましょう。
PRの多いプログラマーを上位に置き、そして…
うげっ。（顔をしかめて見せる）
PRの少ないプログラマーを下にします。そうやって圧力をかけるのです。多いほど良いのですから、これで数が増えて幸せになれるはず。ですよね？
全然、違います。
これはソフトウェア開発チームにとって終わりの始まりです。
物事を改善しようとして悪化させています。誰だって一番下になりたくはないですからね。
それなりに筋の通ったPRが準備できると、わざわざそれを小分けにして出すようになります。
１件のPRが４件になり、いきなり以前の４倍になりました。
でもPRを細切れにしたことで、読みにくくなり、協力が減り、無駄が増えれば、PR件数も減ることになります。
しまった。では今度は４つではなく10件に分けて出しましょう。
皆さんはバカではないから、同じことをするでしょう。
誰も下位にいたくないからです。
つまり、ソフトウェア開発プロセスを改善しようと圧力をかけた結果、事態を悪化させてしまったのです。
さて、長い間プログラマーをやっていると、同じことが何度も繰り返されるのを見ることになります。私はキャリアの中で、こういうプロセスの流れを何度も見てきました。
コードの行数がプログラマーの生産性を測る正しい指標だと言われた時代もあります。生産性を測る人たちが気づいていなかったのは、私たちがプログラマーだということです。
プログラムを書くプログラムも書けるんです。
私をコードの行数で評価するというなら、コンピューターと同じようなすごい速さでコードを量産できます。
でもそれは最終的に求めるものではなく、むしろ逆の結果になっています。仕組みを良くするために圧力をかけることで悪化させてしまったのです。
グッドハートはもっと悲観的に捉えるべきだった
このトークのタイトルは、"グッドハートの法則はもっと悲観的に捉えるべきだった"です。
彼の観察では、もし統計的な規則性があるならば…。例えば、"PRが多い開発者は効率的"というのが統計的な規則性です。
統計的規則性のある仕組みに圧力をかけると、規則性は崩壊するというのが彼の観察でした。
しかし実際は更に悪く、改善のため規則性に圧力をかけると、その規則性を生み出した仕組み自体を壊してしまうことになります。
ただレバーが緩んでしまうということではなく、レバーを引くことで、私たちの期待や意図とは真逆の結果になってしまいます。
だから、"もっと悲観的に捉えるべきだった"と言うのです。
規則性のある仕組みがあったとして、それを制御しようとしても、思ったようにはなりません。
PRのようなレバーを引くことで、意図した効果と逆の結果を得ることになってしまいます。なぜなら規則性を生み出した仕組み自体を壊してしまうからです。
指標にこだわりすぎる人たちは、この測定の問題を理解せず、こう言います。
"バランスの取れた複数の指標が必要だ"、"PR数だけでなく、欠陥の数も計測しよう"、"PRのレビュー時間も測ろう、それから…"。
これでは問題は解決しません。導入するすべての指標が仕組みをゆがめてしまいます。あなたが望まない方向にね。
仕組みをゆがめる指標が多ければ多いほど、その仕組みは理解しづらく制御しづらいものになっていくでしょう。
うまく開発するための指標のセットなんて存在しないんです。
意図はこうでしょう。
もし正しい指標のセットがあれば、"何も考えずに指標が改善するようにプログラムするだけで、すべてうまくいく"。
指標をどんどん導入するプロセスのゴールは、そこにあるように思えます。
それは私が望むものとは正反対です。プログラマーとして私はそんな風に扱われたくはない。考えることを後押ししてほしいし、自分の創造性に任せてほしい。
そしてこれらの思考と洞察と創造性のプロセスは、単純な数字に表せるものではありません。
（数値化しようとする）いかなる試みも、ソフトウェア開発に注ぎ込まれるべき思考、創造性、洞察を奪ってしまいます。
さて、先週このスライドを作りながら、私自身も楽観的すぎたと気づきました。システムは制御の圧力を軽減するために目標を放棄するだけでなく、ゆがんだ目標を採用してしまうのです。
例えば、"コード行数を増やす"、"PRを増やす"、"本番環境の障害を減らす"などの指標があります。
"障害を減らす"指標に注目します。本番環境での障害は避けたいですよね。そこで、"本番環境での障害をなくせ"と圧力をかければ、本番環境の障害報告はなくなるでしょう。
報告件数を減らす最も簡単な方法は、報告しないことだからです。
しかも相手は頭が良く創造的な人々ですから、数字をゼロにしろと言われれば、ゼロにする何らかの方法を見つけるでしょう。
これは仕組みをだましていると自覚するプログラマーにとって悪いことです。会社にとっても、顧客にとっても悪いことです。社会全体にとっても悪いことです。
これは人の働きを単純な数字で表そうとして、人間の判断を不要にして数字だけで制御しようとした結果です。
システムは目標を放棄するだけでなく、新しい目標を採用してしまいます。それは私たちが達成したい目標ではありません。これが指標に圧力をかけるということの本質です。
指標がどんなもので、いくつあって、どれだけバランスが取れていても関係ありません。
必要なのは、ここから抜け出す方法です。
後編に続きます
後編では、Beck氏が提唱する「価値の道すじ」の概念と、AI時代における測定の問題、そしてリーダーが実践すべき具体的なアプローチについて解説します。
後編はこちら tech.findy.co.jp
We're Hiring
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。
