生産性メトリクスがエンジニアリングの最高の仕事を罰する理由

ほとんどのソフトウェア生産性指標は間違ったものを測定しており、機械がコードを書き始める前からすでに間違っていました。コミット数、追加された行数、クローズされたチケット数、そして総コード量は、すべてより多くのものを作ることに報いるものです。しかし、最良のエンジニアリング作業は、通常、より少ないものしか作りません。不要になったモジュールを削除し、3つの絡み合ったサービスを1つの明確なサービスに置き換え、バグにパッチを当てるのではなく、その根本原因を修正します。これらの成功はどれも、ボリューム指標ではマイナスまたはゼロとして記録されます。アウトプットに対して人々に報酬を支払うと、アウトプットが得られますが、アウトプットは進捗と同じではありません。この記事では、どの指標が良い仕事を覆してしまうのか、なぜAIコーディングが問題をより深刻にするのか、そして代わりに何を測定すべきかについて説明します。

間違った行動に報酬を与えるメトリクス

最も一般的なダッシュボードから始めましょう。追加されたコード行数。コミット数。消費されたストーリーポイント。週にクローズされたチケット数。マージされたプルリクエスト。これらはそれぞれ価値の代理指標のように見えますが、それぞれが静かに、あなたが望むものとは逆の行動に報酬を与えています。

実際の作業の形を考えてみましょう。あるエンジニアが、もはや誰も理解していないサブシステムを4日間かけて読み解き、その後600行を削除して80行に置き換えたとします。システムは今や同じ仕事をし、障害モードは減り、次の人が読めるようになりました。ダッシュボード上では、これはマイナス520行、1コミット、そしてクローズされた機能チケットがない1週間として表示されます。あらゆる量のメトリクスによれば、そのエンジニアは悪い週を過ごしたことになります。実際には、それはチームの誰もがその四半期に経験するであろう最も価値のある週の1つでした。

次に、同じチケットを取り上げ、山積みの作業の上に新しいサービスを後付けしたエンジニアを考えてみましょう。2000行の追加、14のコミット、新しい設定ファイル、新しいデプロイターゲット。ダッシュボードは緑色に点灯します。システムは今や推論するのがより困難になり、壊れる可能性のある箇所も増えましたが、そのどれもが数字には現れません。そして、報酬構造は、2つのアプローチのうちどちらが注目されるかを皆に示したのです。

なぜ削除と単純化は常に負けるのか

削除は、メトリックが逆に作用する最も明確なケースです。コードの削除は、システムに対して行える最も影響の大きいことの1つです。なぜなら、削除したすべての行は、もはやバグを持つことも、ビルドを遅くすることも、読者を混乱させることも、メンテナンスを要求することもなくなるからです。機能を維持しながら縮小するコードベースは、より健全になっています。しかし、標準的なメトリックで削除を肯定的な貢献として数えるものはありません。最善の場合でも無視されるだけです。通常は、何もしないよりも作業量が少ないと評価されます。

根本原因の修正も同じように負けます。本当に解決された困難なバグは、2日間の調査の末に3行の変更しか生まないかもしれません。症状を隠すだけの対症療法的なパッチは、50行と3つのコミットを生み出し、後で再び壊れたときにはさらに多くのチケットを生成するでしょう。メトリックはパッチの方を好みます。将来のチケットも同様に好みます。なぜなら、それは来月クローズされるもう1つのアイテムになるからです。

「ノー」と言うこともまた負けにつながります。メンテナンスの負担になったであろう機能の構築をしないようチームを説得したエンジニアは、本当の仕事をしたのです。彼らはコストを防ぎました。しかし、防がれたコストは目に見えません。あなたが書かなかった2000行のコード、デプロイしなかったサービス、決して受けることのないオンコールでの呼び出しに対して、計上される項目はありません。メトリックは存在するものをしか見ることができないため、不要なものを構築した人が、それを止めた人よりも高く評価されます。

これら3つの根底にあるパターンは同じです。量的なメトリックは加算しか測定できず、最高のエンジニアリングの多くは減算なのです。

グッドハートの法則が残りの損害をもたらす仕組み

なぜこれが単に不正確なままでいるのではなく、時間とともに悪化していくのかを説明する法則があります。ある指標が目標になると、それはもはや良い指標ではなくなります。人々は受動的ではありません。ある数字があなたの評価、ボーナス、あるいは地位を決定するようになった瞬間、あなたはその数字に向かって舵を取り始め、その数字は現実を説明するものではなくなります。

コミット数を目標にすると、人々は1つの変更を8つのコミットに分割するようになります。追加された行数を重視する文化では、報酬は明確さではなく量にあるため、人々はより多くのコードを書いて問題を解決するようになります。クローズしたチケット数を目標にすると、人々は作業を多くの小さなチケットに分割し、週ごとのカウントを下げてしまうような根深い単一チケットの問題を避けるようになります。これらのいずれも、誰かが不正を働くことを要求するものではありません。それは、人々がインセンティブに反応することを要求するだけであり、誰もがそうするものです。

そのため、量的な指標は良い仕事を捉えられないだけではありません。それは、チームがスコアを稼ぎやすい種類の仕事、すなわち、水増しされ、過剰に構築され、数えやすい種類の仕事を生み出すように、積極的に仕向けます。その指標は、本来観測すべきだったものを劣化させます。最終的に手にするのは、ダッシュボードのために最適化されたコードベースです。

なぜAIコーディングはコード量メトリクスを完全に破壊するのか

これまでの話はすべて、人間が一行一行手でコードを書いていた時代には真実でした。AIコーディングアシスタントは、その同じ破綻したメトリクスを採用し、そこにかろうじて残っていた意味さえも取り除いてしまいます。

その理由は、AIがコード量をほぼ無料にするからです。モデルは1分で500行を生成できます。昼食前に10コミット分の変更を作成することも可能です。もしあなたのメトリクスが追加された行数や作成されたコミット数に報いるものなら、アシスタントは今やそれだけでそのメトリクスを満たすことができます。そして、その隣に座っている人間は、ほとんど何も考えずに、3年前なら英雄的に見えたであろうアウトプットの数値を叩き出すことができるのです。アウトプットは労力から切り離され、さらには価値からも切り離されてしまいました。

機械がしないことは、何が存在すべきかを決定することです。AI支援エンジニアリングにおける希少な仕事は、判断です。問題を正しく構成すること。何をビルドしないかを決定すること。生成されたコードを批判的に読み、間違っている、安全でない、または不必要に大きい部分を捨てること。モデルが過剰に生成したソリューションを、実際にシステムに適合するバージョンまで削除すること。これらは、AIがコードベースをより良くしたのか、それとも単に大きくしただけなのかを決定するタスクですが、そのどれもがコード量として現れることはありません。むしろ、これらのタスクをうまくこなせば、行数やコミット数は減少します。なぜなら、生成されたコードの良いレビューとは、主にそれを拒絶し、削減することを意味するからです。

したがって、コード量メトリクスはAI時代においても単に間違ったままでいるだけではありません。それらは今や、安価になったものを報奨し、希少になったものを罰するのです。アウトプットで測定されるチームは、AIを使って自らをコードの洪水に溺れさせるでしょう。成果で測定されるチームは、同じAIを使い、より少ないコードでより多くのことを成し遂げる結果になるでしょう。

代わりに何を測定すべきか

解決策は、作業を生み出す動きそのものではなく、作業の結果を測定することです。成果指標は、活動が忙しく見えることではなく、現実がより良くなることと結びついているため、ごまかすのがより困難です。

最も強力なシグナルは、システムが機能しているかどうか、そしてどれだけ速く安全に変更できるかに関するものです。サービスの信頼性はどの程度か。アイデアから本番環境への変更にどれくらいの時間がかかるか。デプロイがインシデントを引き起こす頻度はどのくらいか。変更のうち、差し戻される割合はどのくらいか。何かが壊れたときに復旧するのにどれくらいの時間がかかるか。これらはシステムの健全性と作業の流れを表しており、コミットを水増ししても改善することはできません。これらを改善するには、システムを純粋に良くすることであり、それが重要なのです。

それらと並行して、簡素化を明確に評価します。振る舞いを維持したままの削除を第一級の貢献として扱い、レビューや昇進でそのように言及します。出荷したスコープだけでなく、断ったスコープも数えます。誰かが負担になったであろう機能を防いだ場合、その決定は、出荷された機能と同じように、目に見え、評価されるべきです。もし報われる唯一の動詞が「構築した」ことであれば、行われるべきではなかった構築も含め、構築ばかりが行われることになるでしょう。

平易な言葉で対比を以下に示します。

右側の指標はどれも、コードを書くこと自体を目的としてより多くのコードを書いても満たすことはできません。そのほとんどは、書くコードが少ないほど改善します。それこそが望むべき特性です。良い指標とは、削除、簡素化、そして自制が、実際にあるがままに優れたものとして見えるようにするべきです。

メトリクスは対話であり、スコアボードではない

最後のポイントは、これらのいずれをどのように使うかということです。より優れたメトリクスでさえ、それがターゲットになった瞬間に有害なものに変わります。なぜなら、グッドハートの法則は、あなたがどの数値を選んだかを気にしないからです。手戻り率は、リスクのあるものを一切出荷しないことでごまかすことができます。リードタイムは、レビューを省略することでごまかすことができます。給与や地位を決定するスコアボードにされた単一の数値は、それが本来意味していたものを失うまで最適化されるでしょう。

したがって、メトリクスの正しい役割は、判断の終わりとしてではなく、問いの始まりとしてあるべきです。インシデント率の上昇は、何が変わったのかを問う理由であり、罰するための棒ではありません。1週間のマイナスの行数は、何が簡素化されたかを見るきっかけであり、赤点ではありません。数値はどこに目を向けるべきかを示してくれます。それでも人が見なければなりません。そのステップを省略し、ダッシュボードに直接人々を評価させると、これまで常にボリュームメトリクスが生み出してきた、水増しされ、過剰に構築され、ダッシュボードに合わせた形の作業が、今やあなたが求めるだけのボリュームを喜んで提供するマシンによって、かつてない速さで生成されることになります。

全ては一つの指示に集約されます。機械が量をほぼ無料にする時代において、どれだけ作られたかを測定するのはやめましょう。システムがより良くなったかどうかを測定し、それをよりシンプルにした作業を評価し、全ての数値を追いかけるべきものではなく、話し合うべきものとして扱いましょう。より少なく、正しく行うことこそが、仕事なのです。メトリクスはそう語るべきです。