■ 1. 開発生産性の本質的な問題
- 生産性の定義: 生産性とはアウトプットとインプットの比率であり、単純な数値として表現される
- 改善の逆説: 開発生産性を改善しようとする試みが、しばしば状況を悪化させる結果を招いている
- AIによる問題の深刻化: AI技術の導入により、生産性測定と制御の問題が更に悪化している
- 終わりなきプレッシャー: やることは常に山積みであり、どれだけ生産性を上げてもプレッシャーが軽減されることはない
■ 2. マッキンゼーレポートの問題点
- 世間知らずな提案: 約2年前にマッキンゼーが発表した開発生産性レポートは、経験ある開発者から見て明らかに不適切な内容だった
- すべてが逆効果: 生産性向上のための提案がすべて状況を悪化させるものであった
- 批評記事の執筆: Gergely Oroszと共同で批評を執筆し、大きな反響を呼んだ
■ 3. グッドハートの法則の基本概念
- 法則の要約: 指標が目標になると、それは良い指標ではなくなる
- タイピング速度の例: タイピング速度を指標とすると、開発者は意味のない高速タイピングに専念するようになる
- 本来の観察: 統計的規則性が観察されても、それを制御手段として利用すると規則性は崩壊する
- イングランド銀行の事例: 短期金利と借入の相関関係を制御に利用しようとしたが、他のプレイヤーの適応により効果が消失した
■ 4. 測定の目的と誤用の区別
- 測定の価値: ソフトウェア開発プロセスの測定は非常に価値があり、自分のやっていることを数値化・分析・解釈できる
- 制御との違い: 測定による理解と、レバーでシステムを制御できるという感覚は全く別物である
- 理解のための測定: 指標は開発プロセスを理解するためのものであり、システムを機械的に制御する手段ではない
- ソフトウェアの特殊性: 純粋な知的活動の中で、ソフトウェア開発ほど規模を拡大できるものは他にない
■ 5. プルリクエスト指標の事例分析
- 正のフィードバックループ: 優れた開発者は小さなPRを多く出し、それが読みやすさ、協力の増加、無駄の削減につながる自己強化型の仕組みを形成する
- 圧力による崩壊: PRランキング表を作成して圧力をかけると、開発者は筋の通ったPRを細切れにして数を水増しするようになる
- 協力の減少: PRを細分化することで読みにくくなり、協力が減少し、無駄が増加し、最終的にPR数も減少する
- 悪循環の発生: 誰も下位にいたくないため全員が同じ行動を取り、ソフトウェア開発プロセス全体が悪化する
■ 6. コード行数指標の歴史的失敗
- 生産性指標としての採用: コード行数がプログラマーの生産性を測る正しい指標だと考えられた時代があった
- プログラマーの対応: プログラマーはコードを生成するプログラムを書くことができるため、機械的に大量のコードを生産できる
- 逆効果の結果: 求めていた成果とは正反対の結果を生み出し、仕組みを悪化させた
■ 7. グッドハートの法則を超える悲観的現実
- 規則性の崩壊を超える破壊: 統計的規則性に圧力をかけると、単に規則性が崩壊するだけでなく、規則性を生み出した仕組み自体を壊してしまう
- 意図と逆の結果: レバーを引くことで期待や意図とは真逆の結果が生じる
- より深刻な問題: 単にレバーが機能しなくなるのではなく、システム全体が望まない方向に向かう
■ 8. 複数指標によるバランスの幻想
- バランス指標の提案: PR数だけでなく欠陥数やレビュー時間など複数の指標を組み合わせるべきだという主張がある
- 問題の非解決: 導入するすべての指標が仕組みをゆがめるため、複数の指標を導入しても問題は解決しない
- 理解困難化の加速: 指標が多ければ多いほど、システムは理解しづらく制御しづらいものになる
- 完璧な指標セットの不在: うまく開発するための指標のセットは存在せず、指標による自動的な改善という発想自体が誤りである
■ 9. 人間性の軽視と創造性の抑圧
- 機械的制御の危険性: 何も考えずに指標を改善するだけですべてうまくいくという発想は、開発者の人間性を無視している
- 思考の後押しの必要性: プログラマーは考えることを促され、創造性に任せられることを望んでいる
- 数値化不可能な要素: 思考、洞察、創造性のプロセスは単純な数字に表すことができない
- 創造性の喪失: 数値化しようとするあらゆる試みが、ソフトウェア開発に注ぎ込まれるべき思考と創造性を奪う
■ 10. システムによるゆがんだ目標の採用
- 目標の放棄を超える問題: システムは制御の圧力を軽減するために本来の目標を放棄するだけでなく、ゆがんだ目標を新たに採用する
- 本番障害指標の例: 本番環境での障害をなくせという圧力をかけると、障害報告がなくなる(報告しないことで数字をゼロにする)
- 創造的な回避行動: 頭が良く創造的な開発者は、数字をゼロにする何らかの方法を必ず見つけ出す
- 全方位的な悪影響: 仕組みをだますプログラマー、会社、顧客、社会全体にとって悪い結果をもたらす
■ 11. 指標による制御の本質的限界
- 人間の判断の排除: 人の働きを単純な数字で表し、人間の判断を不要にして数字だけで制御しようとする試み自体が問題である
- 望まない目標の採用: システムが新たに採用する目標は、組織が真に達成したい目標とは異なるものになる
- 指標の種類や数は無関係: どのような指標を使用し、いくつ組み合わせ、どれだけバランスを取っても問題の本質は変わらない
- 脱出方法の必要性: この悪循環から抜け出す方法を見つける必要がある
■ 1. ソフトウェアが価値を生み出す4段階のプロセス
- 労力(Effort): プログラマーがプログラミングに費やす時間、金銭、機会費用で測定される最初の段階である
- アウトプット(Output): 労力を費やした結果として形になるもの(例:ボタンの追加)であり、比較的測定が容易である
- 成果(Outcome): 顧客が新しい行動を取り、ユーザーの行動変化として現れる段階である
- 影響(Impact): 会社の収益増加、顧客満足度向上、コスト削減など、企業に価値が還元される最終段階である
■ 2. 測定の容易さと仕組みのゆがみの関係
- 労力側の測定リスク: 価値の道すじの初期(労力側)に近いほど測定は容易だが、指標が仕組みをゆがめる可能性が高くなる
- 過労の危険性: 若い頃に週100時間以上働いた経験から、時間の最適化は良くない結果を招くと警告している
- アウトプットの測定: ボタンの数など比較的測定しやすいが、顧客が気にするかどうかは成果が出るまで分からない
- 貢献度の切り分け困難: 複数のチームの貢献が組み合わさって成果が出る場合、個別の功績を切り分けることは困難である
■ 3. 経営者の関心と測定の優先順位
- 顧客行動への注目: 経営者として測定したいのはプログラマーの労働時間ではなく、顧客がどう行動を変えたかである
- 影響の測定可能性: 四半期ごとの財務状況など影響レベルでの測定は可能だが、誰の功績かを特定することは不可能である
- 帰属の困難さ: プログラミングとマーケティングの成果が混在する場合、収益性の変化を特定の要因に帰属させることはできない
- ゆがみの軽減: プロセスの後期(影響側)で測定するほど、指標が仕組みをゆがめる傾向は弱くなる
■ 4. AIによる労力とアウトプットの変化
- 拡張プログラミングの体験: Gene Kim氏の影響でAIベースのプログラミングを始め、機能完成に必要な労力が劇的に減少した
- 労力減少とアウトプット増加: AIのおかげで作業時間が大幅に短縮され、プログラマー1人当たりのアウトプットが増加する
- AIの不完全性: AIというコーディング仲間は時にとんでもなくバカなこともするため、労力が増えることもある
- 管理方法の不変性: 10時間の作業が1時間でできるようになっても、プロセスをどう管理すべきかについては何も変わらない
■ 5. AI時代における若手育成の選択
- 若手不要論への反論: ジーニー(AI)を使えばシニアプログラマーの方が生産性が高いため若手が不要になるという懸念がある
- チューターとしてのAI活用: RustやHaskellなど理解できない言語でも、AIがいつでも説明してくれるため学習効率が向上する
- 学習重視の評価: 若手を労力やアウトプットではなく、毎週学んだことで評価する方式を提案している
- 長期的価値の創出: 若手は大量のコードを書くためにいるのではなく、早く学ぶことが雇用者にとっての長期的価値を生み出す
■ 6. 指標を見る人と行動の重要性
- 見落とされる質問: 誰がこの数字を見るのか、見た結果どんな行動を取るのかという質問がめったに議論されない
- CFOの解雇意図: 最高財務責任者がプログラマーの2割を解雇したいと思っているなら、どんな指標も恐ろしいゆがみを生む
- 現場マネジャーの育成意図: 部下が早く学ぶのを助けたいと思っている現場マネジャーでは、全く異なる見方になる
- 単位の重要性: 開発者1人当たりのPRは投資家にとって意味がなく、利益という単位で測定すべきである
■ 7. 投資家視点での生産性測定
- 金銭的価値の測定: 投資家として気になるのは利益であり、アウトプットもインプットも金額で測定してほしい
- 雇用判断の根拠: 追加のプログラマーを雇って生産性が1.4倍や3倍になると分かれば、雇用は理にかなっている
- PR数の無意味性: 1日当たりのPR数が3件から6件になると言われても、プログラマーを追加で雇うべきか判断できない
- 意思決定への貢献: 利益の数字を使えば、投資家として良い決断を下すことができる
■ 8. リーダーシップの実践:後段階での確認
- 確認タイミングの遅延: 価値の道すじの初期段階ではなく、後期段階で確認することが重要である
- タイムカード導入の危険性: 労働時間の管理やバグの自己申告など、初期段階での確認は仕組みをゆがめる
- 開発者1人当たりの利益: 達成方法は問わず、競合他社との比較で開発者1人当たりの利益を提示する
- 成果の観察: 会社への直接的な影響が確認できないなら、成果を観察することがソフトウェア開発の有効性を評価する良い方法である
■ 9. リーダーシップの実践:意識向上の促進
- グラフ化による意識向上: システムの速度をグラフ化して週に1度提示するだけで、プログラマーは改善に夢中になる
- 圧力の回避: 何も言わず、ただグラフを見せるだけで、プログラマーは自発的に調査し改善しようとする
- 圧力とゆがみの関係: リーダーとして圧力をかけないことは難しいが、圧力をかけると仕組みにゆがみが生じる
■ 10. リーダーシップの実践:目的の浸透
- 引く姿勢の採用: 本番障害の削減を命令するのではなく、「できるよ、私たちなら可能だ」と励まし、必要なものを尋ねる
- 非難の回避: 障害が起きた際に「君はダメなプログラマーだ」と圧力をかけるのではなく、引く姿勢で接する
- リーダーの責任: 現状に対する責任を自ら持ち、「私は障害が多すぎる環境を作ってしまった」と認める
- やり方の変更宣言: 今後はやり方を変えていきたいと伝え、チームを前向きに導く
■ 11. グッドハートの法則を回避する方法
- 圧力回避による測定: 指標に圧力をかけなければ、結果を変えずに測定できる
- 最高の自分の追求: 人々が最高のレベルで創造し、共有する目標に全力を注ぐことを後押しする
- 揺るぎない目標: より大きな視点でソフトウェア開発を見ることで、目標が揺るがなくなる
- 魔法のようなプロセス: ソフトウェア開発は誰もが参加でき、成長を続け、目標達成が可能な魔法のようなプロセスである