こんにちは。Findy Tech Blog編集長の高橋（@Taka_bow）です。
前編では、グッドハートの法則の本質と、指標に圧力をかけることで開発現場がいかに歪められるか、そして"もっと悲観的に捉えるべきだった"理由を見てきました。
後編では、Beck氏が提唱する「価値の道すじ」の概念と、AI時代における測定の問題、そしてリーダーが実践すべき具体的なアプローチについて解説します。
前編はこちら tech.findy.co.jp
講演動画
※ 視聴には Findy Conference へのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。
日本語訳全文（続き）
ソフトウェアが価値を生み出す4つの段階
Kent Beck氏：ではどうやって抜け出すのか？プログラミングのジーニー（生成AIのこと）についてお話しします。
ソフトウェアの価値を生み出す方法は？他にもありますが、私はプログラマーですから、今はソフトウェアの話をします。
まずは"労力(Effort)"の話です。プログラマーが何かのアプリのために、プログラミングに時間をかける。それが労力(Effort)です。
それは時間で測ることができます。
お金で測ることもできます。
その時間で他に何ができたかという機会費用で測ることもできます。とにかく最初の指標は労力(Effort)です。
アプリにボタンを追加したいとして、作るのにどれだけ時間がかかったか？プログラマーが労力(Effort)を費やせば、何かしら形になるものができます。これが"アウトプット"です。
今までなかったボタンが表示されます。よし、いいぞ。
労力(Effort)は比較的簡単に測定できます。アウトプットは少し難しくなります。
10個のボタンがあったら、５個のボタンより２倍良いのでしょうか？数えることはできます。まだ確信は持てませんが、それでもアウトプットの測定も比較的簡単です。
さて、アプリに新しいボタンがつきました。しかし、まだ価値は生まれていません。顧客が何か新しい行動を取るまではね。
顧客がこれらのボタンがあることの価値を認識し始めます。
"ここからここへのショートカットがずっと欲しかったんだ"、"今では新しいショートカットをいつも使っている"、"だからこのアプリがもっと好きになった"。
私が話している、"成果(Outcome)"とは、こういうことです。つまりユーザーの行動の変化なんです。
そして最終的に、私たちがプログラマーとして時間を費やして生み出した価値は、会社に戻ってきます。その形は収益の増加であったり、顧客満足度の向上であったりします。
コスト削減もまた、私たちの会社が収益性を上げる１つの方法かもしれません。
そして、そのプロセスの成果(Outcome)を収穫し、再び労力(Effort)に注ぎます。そうして会社は、プログラマーに報酬を払えるのです。プログラミングで報酬を得られるのはうれしいですね。
この、"価値の道すじ"のプロセスで、私が気づいたのは、"労力(Effort)"に近いほど物事を測定しやすいということです。
ですが同時に、指標は仕組みをゆがめる可能性があることを思い出してください。指標に圧力をかけると、仕組みの目標をゆがめてしまうのです。労力(Effort)の側に寄るほど、仕組みをゆがめる可能性が高くなります。
私は、若いプログラマーだった頃、より良いプログラミングをするために、より多くの時間を費やしました。
結論だけ言うと、それで自分を壊しかけました。週100時間以上働いて。
でも結局、それは無理なんです。念のため言っておきますが、やめてください。
時間は測定しやすく、制御も簡単です。しかしプログラミングに費やす時間を測定し制御しようとし、そして最適化しようとすると、良くない結果になります。
ちょっと右に移動しますね。少し難しい話になります。
ボタンを作るとして、それは難しいでしょうか？簡単でしょうか？
ボタンが２つあります、あなたが１つ作って、私が１つ作った。これは比較的、測りやすいですね。
労力(Effort)ほど簡単ではありませんが、比較的簡単に測定できます。そして私が話しているゆがみの影響(Impact)も少し小さくなります。
しかし、追加したボタンを誰かが気にしますか？成果(Outcome)が出るまで分からないんです。
"あなたはボタンを10個追加した、彼らは５個追加した"、"だから、あなたは２倍優秀だ"。
ですが顧客の行動を見るまでは、成果(Outcome)を比較することはできません。しかしユーザーの行動を注意深く観察すれば、アウトプットを比較することは少し簡単になります。
ではもし、あなたがボタンを追加することで、彼が追加したボタンが使いやすくなっていたら？その２つがそろって初めて、顧客がその機能を評価してくれるとしたら？
あなたが検索の速度を５倍にして、彼がグラフを追加する。高速になって、更にグラフがあるから、人々の行動が変わる。その場合、２つのチームの貢献度を切り分けるのは難しくなります。
どちらの功績かハッキリ言えません。こうして測定は更に難しくなります。
しかし、例えば、プログラマーの労働時間を測るか、顧客の行動変化を測るか。経営者として選ぶとしたら、私が測りたいのは100％、顧客がどう行動を変えたかです。プログラマーの頑張りには、あまり関心がありません。
そして、"影響(Impact)"の話に戻ります。
"この会社はどれくらい利益を出しているか？"、収益の増加は？コストの低下は？成長のスピードは？これらはすべて影響(Impact)の話です。
この時点でも測定は可能です。四半期ごとの財務状況もあります。しかし誰の功績なのかは分かりません。
"君が労働時間を増やしたから会社の利益が上がったね"。そんなことは誰にも分かりません、不可能なんです。
プログラマーが優秀でも、マーケティングの仕事がひどかったら？
そして収益性が変わらなかったら？
プログラマーの生産性とは関係ありません。その逆もあり得ます。プログラマーの仕事の出来が悪くても、マーケティングは優秀で収益性が上がっていたら？
価値の道すじの中で先の方へ進めば進むほど、特定の人や特定のチームに価値を帰属させるのは難しくなります。しかし指標が仕組みをゆがめる傾向は弱くなります。
アメリカ企業がよくやるように、四半期の利益だけにこだわれば、さすがにこの仕組みはゆがみ、期待とは違う結果になります。
それでも、プロセスの初期でプログラマーにこう言うよりは、ゆがみは少ないんです。
"６時半に帰宅したのか、うちのチームは８時まで残ってるぞ"。
もしそんなレベルで制御するなら、確実にゆがみを生むでしょう。
"プログラマー１人当たりの収益性は？"の方がマシです。"プログラマー１人当たりの売上"、"１人当たりのコスト"も同じです。
AIが変えるもの、変えないもの
さて、AIについて少しお話しします。
この会場でGene Kim氏に会えてうれしいです。（注：Gene Kim氏はもう一人の基調講演者です）
Gene Kimは私を、AIベースのプログラミングに、"感染"させました。
私は、"拡張プログラミング"と呼んでいます。これが２ヵ月前か３ヵ月前のことで、それ以来、AIを使ったプログラミングを私は非常に楽しんでいます。
そして気づいたのは、機能を完成させるために必要な労力(Effort)が劇的に減ったということです。
さて、拡張コーディングの話は楽しいので何日でもできますが、今日はやめておきます。しかし時には労力(Effort)が増えることもあります。
AIというコーディング仲間は、とんでもなくバカなこともするからです。そこは覚悟してください。
しかし労力(Effort)は減り、プログラマー１人当たりのアウトプットは増えます。しかし労力(Effort)とアウトプットのレベルでの測定は、仕組みをゆがめることを思い出してください。
AIのおかげで10時間の作業が１時間でできたとしても、このプロセスをどう管理すべきかについては、何も変わらないのです。
もし私たちが、"10倍速くなったぞ、すばらしい、みんなに10倍の速さで作業させよう"、こんなことを言えば、仕組みにゆがみが生じることになります。
やはり私たちが重視すべきなのは、ソフトウェア開発全体を測定し、全体を意識することです。そうでないと、制御しようとして仕組みをゆがめてしまいます。
ジーニーでコーディングすれば労力(Effort)は減り、アウトプットは増えます。多分ね。
具体例を出します。人々は心配しています。
"ジーニーを使ったコーディングで若手プログラマーが不要になるのでは？"と。
シニアプログラマーの方が生産性が高いからです。"若手なんて必要ないだろう？"、"彼らは大きな混乱をより速く生み出すだけだ"。
私は選択の問題だと思います。
私はジーニーを教育用チューターとして使うのが好きです。Rustなどの理解できない言語でも、プログラミングをしてきました。Haskellとかね。そんなプログラムを見て思うことがあります。
この、"&&[~~"というのは一体何なんだ？そこで手を止めて、"これを説明して"と言うと、ジーニーがいつでも説明してくれます。
すばらしいことです。
若手を育てる際に、彼らの労力(Effort)やアウトプットではなくて、どれだけ学んだかで評価してはどうでしょう？
例えば毎週の若手との会話の中で、こう聞くんです。
"今週、学んだことを３つ教えて"とね。"今週、追加した機能を３つ見せて"ではありません。
アウトプットを重視するか、学びを重視するかの選択です。長期的に見れば、雇用者にとっての価値を生み出すのは学びです。
若手は大量のコードを書くためにいるわけではありません。むしろ問題の種になることが多いので、大量のコードは書いてほしくないのです。でも早く学んでほしいと思っています。
そしてジーニーは、若手の学びを早める新しい手段となり得るのです。
もし私たちがアウトプットを重視するのであれば、学習に集中することで、確かにアウトプットは遅くなるでしょう。
それでも私は断然、学習を重視したいです。なぜならそれが長期的に見て、必要な価値を生み出すからです。
指標を見る人と行動が重要
私がめったに見ない質問は…。生産性の話に戻りますね。生産性とはアウトプットとインプットの比率です。
私がめったに見ないのは、"誰がこの数字を見るのか？"、"見た結果、どんな行動を取るのか？"という質問です。
もし最高財務責任者が、プログラマーの２割を解雇したいと思っているなら、どんな指標を当てはめようが同じです。ソフトウェア開発に恐ろしいゆがみを生むでしょう。
しかし例えば、現場のマネジャーが、部下が早く学ぶのを助けたいと思っているのなら、全く異なる見方になるでしょう。
私がいつも考えるのは、"単位は何か？"ということです。
"１日当たりの開発者１人当たりのPR"と誰かが言ったとします。しかし私が投資家の立場だとしたら、開発者のPRなんかに興味はありません。
会社の成長や収益性に何の影響(Impact)もありませんからね。"いつか株を売れるだろうか？"という判断に何の関係もありません。
"開発者の生産性を測っています"と言われても、それは私が気にかける単位ではありません。
投資家として気になるのは利益です。私はアウトプットもインプットも、金額で測定してほしいのです。
もし追加のプログラマーを雇うとして、生産性が1.4倍とか３倍とか７倍になると分かれば、プログラマーを雇うのは理にかないます。
しかし、"１日当たりのPR数が３件から６件になります"と言われても、プログラマーを追加で雇うべきなのか分かりません。しかし利益を見ることができれば、その数字を使って良い決断を下すことができます。
リーダーにできること
ではどうすればいいでしょう？皆さんはマネジャーなのか、上級開発者なのか、リーダーシップを取る立場にあるとします。
まず最初に…、ちょっと気が滅入る話なのは分かってます。聞いてくださる皆さんに感謝します。できることは、いくつかあります。
１つ目は、"あとで確認すること"です。早い段階でしてはダメです。価値の道すじの初期段階で確認すると…、確認するだけでもダメですよ。
"タイムカードをつけよう"とかね。年配のプログラマーとしては、何か恐ろしいことの始まりだと思います。
または、"バグを自己申告しよう"とかね。私は疑い深いんです。
指標は労力(Effort)の側に近づけば近づくほど、仕組みをゆがめるので、あとで確認してください。そして、あとの段階で言ってください。
"これが開発者１人当たりの利益だ、達成する方法は問わない"、"でもこれが…"、"うちの開発者１人当たりの利益と、競合他社の開発者１人当たりの利益"、"どうするかは君たちに任せる"。
早い段階ではなく、あとで確認してください。会社への直接的な影響(Impact)が確認できないなら、成果(Outcome)を観察するのが良い方法です。ソフトウェア開発の有効性を評価するためにはね。
２つ目のポイントは、意識向上の促進です。つまり、システムを速くするための最高の手法の１つは、システムの速度をグラフ化することです。何も言わなくていい。ただ…。
"これがこのシステムの速度です"というグラフを週に１度出すだけです。プログラマーはそれに夢中になり、改善したくなるでしょう。
"このグラフは何だ？なぜ上昇したんだ？"、"分からないな、自分で調べてみてよ"。リーダーはこれだけで意識を向上させられます。
圧力とは真逆です。リーダーとして圧力をかけないのは難しいことです。しかも圧力をかけると、仕組みにゆがみが生じます。
その代わりにできるのは、私が直面した中でも困難な課題ですが、目的を浸透させることです。どうチームに伝えればいいでしょう。
"ねえ、これを見て"、"本番障害がこのペースで起きなかったら、すばらしいと思わないか？"、"できるよ、私たちなら可能だ"、"今、何があれば、それを達成できると思う？"。
いけないのは、"本番環境で障害？君はダメなプログラマーだ"と言うことです。
それは圧力のアプローチです。押すのではなく、引くのです。
そのためには、リーダーとして現状に対する責任を持つ必要があります。そしてこう言います。
"私は障害が多すぎる環境を作ってしまった"、"でも今後はやり方を変えていきたい"。
この転換ができれば、グッドハートの法則に…。グッドハートの法則の悲観的な部分に、私たちは影響(Impact)を受けなくなります。指標に圧力をかけなければ、結果を変えずに測定できます。
代わりに、人々が最高の自分を目指すことを後押しできます。それは最高のレベルで創造し、共有する目標に全力を注ぐことです。その目標は揺るぎません。
私たちは、より大きな視点でソフトウェア開発を見ることを選んだからです。
ソフトウェア開発は、誰もが参加できる魔法のようなプロセスで、今でも成長を続け、私を驚嘆させ続けています。私たちなら目標を達成できます。
皆さんのお時間とご清聴に感謝します、ありがとうございました。
（会場拍手）
※ 講演後行われたサイン会は大盛況でした。
まとめ
25年ぶりの来日となったKent Beck氏の講演は、開発生産性の測定がもたらす根本的な問題を語るものでした。四半世紀の時を経ても変わらぬパワフルなメッセージは、私たちの開発現場の課題を深く考えさせられる内容でした。
講演から得られた重要なポイントをまとめます。
- グッドハートの法則の真の意味 - 指標が目標になると良い指標ではなくなるだけでなく、仕組み自体を壊してしまう
- 測定と制御は別物 - 測定すること自体は価値があるが、指標でシステムを制御しようとすることが問題を引き起こす
- 価値の道すじ - 労力(Effort)→アウトプット→成果(Outcome)→影響(Impact)という流れの中で、測定しやすい指標ほどシステムをゆがめる
- AIは本質を変えない - AIで効率が上がっても、指標に圧力をかければシステムをゆがめるという本質的な問題は変わらない
- リーダーシップの役割 - 圧力ではなく、目的を浸透させ、意識を高めることが重要
Beck氏が最後に語ったのは、指標に圧力をかけなければ結果を変えずに測定できるということです。
つまり、測定そのものは続けながら、グッドハートの法則が引き起こす問題から逃れられる。測定は理解のため、意識向上のために使い、制御の手段にはしない。
この転換により、開発者は最高の自分を目指し、創造性を発揮できるようになります。単なる生産性向上のテクニックではなく、開発組織のあり方そのものを問い直す講演でした。
前編はこちら tech.findy.co.jp
We're Hiring
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。
