測定が目標になるとき：窓税からPull Request数まで

はじめに

以前ある職場で、四半期内に僕（そしてチームメンバー）がどれだけPull Requestに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計する小さなツールを自作したことがある。その数字を使って、上司に自分のアウトプットと貢献度を証明したかったのだ。

上司は僕のレポートを見ると、評価は単にアウトプットだけでなく、影響力やどんな価値をもたらしたかも見るのだと淡々と語った。当時の僕は少し腹を立て、自分はこれだけやったのに相応の評価が得られないと感じていた。

少しムッとした僕は、「じゃあ、僕がサボって何もアウトプットを出さなくてもいいということですか？」と上司に尋ねた。上司はその質問に正面からは答えなかった。そして当然のごとく、僕は望ましい評価を得ることはできなかった。

数年が経ち、僕はようやく上司の言葉を理解し、むしろ僕のアウトプットを短絡的に褒めなかったことに感謝すらしている。測定が目的になってしまうと、測定はその意味を失うのだ。

指標をハックして台無しにした歴史

1696年、英国は建物の窓に対して課税を始めた。窓が多ければ多いほど、税金は重くなる。通常、窓が多いのは富裕層の家であり、徴税吏がいちいち家の中に入らなくても、通りから数を数えるだけで済むため便利だった。

税金を減らすため、国中の窓が次々とレンガで塞がれ、新築の家には窓すら作られなくなった。当時の英国では感染症が流行していたが、窓がないことで家の換気が悪化し、人々はより感染症にかかりやすくなってしまった。

古代エジプト人はナイル川のほとりに専用の水位計（ナイロメーター）を建て、毎年の氾濫の高さによってその年の税率を決めていた。水位の高さは絶対に改ざんできない自然の指標だが、それでも課税逃れはなくならなかった。

税率そのものは変えられないため、農民たちは耕地面積を過少申告し、測量を行う書記に賄賂を贈り、上納する穀物に石を混ぜて重さをかさ増しした。その結果、国家は穀物の刈り取りから輸送に至るまで、全行程を監視する人員を派遣せざるを得なくなった。税率が高い状況では限界効用が逓減し、農民たちも自然と生産量を増やそうとはしなくなった。

1902年のベトナム・ハノイでは、ネズミを撲滅するために政府がネズミの尻尾1本と引き換えに報奨金を出すとお触れを出した。その結果、尻尾だけを切り落として逃がすケースや、さらには報奨金目当てにネズミを養殖する者まで現れた。ネズミの被害は解決するどころか、かえって悪化したのだ。

測定が目標になるとき、それはもはや良い測定ではなくなる

なぜ代理指標はこれほど魅力的なのか？

指標を測定することは極めて重要だ。ソフトウェア開発には「オブザーバビリティ（可観測性）」という言葉がある。数値を可視化することはソフトウェア開発において非常に重要な要素であり、数値があって初めて改善方法やバグの修正方法がわかる。

• データベースのコネクション数が急増：特定のSQLが適切に書かれておらず、スロークエリがコネクションを占有している可能性がある
• CPU使用率が高すぎる：データ量が膨大で計算量が急増している可能性がある
• APIレスポンスタイムが著しく増加：依存しているサードパーティのサービスに障害が発生している可能性がある

測定は、僕たちが問題を発見し、プロダクトを改善するための重要な手段の一つだ。問題なのは、多くの企業の上層部が測定指標のもたらす影響を中途半端にしか理解しておらず、指標の測定を始めた瞬間から、数字の見栄えを良くすること自体が目的化してしまうという事実に気づいていないことだ。これは古今東西、常に変わらない。

Pull Request数、解決したバグ数、LLMのトークン数、コード行数で開発者のアウトプットを評価しようとすると、開発者は数字の見栄えを良くするために行動するようになる。たとえば、わざとシステムを少し雑に書く、1つのPull Requestで解決できる機能をあえて10個に分割する、あるいはAIに無意味なコードを吐き出させ続ける自動化ツールを作るといったことだ。測定が目標になるとき、それはもはや良い測定ではなくなる。

さらに微細な影響は、日々の開発現場にも現れる。こうした代理指標で評価を行うことは、チーム内での助け合いを奨励しないことを意味する。他の同僚を助けることは自分のPull Request数を犠牲にすることを意味し、プロダクトをより良くしようとする動機も失われてしまうからだ。

重要な指標ほど測定しにくい

本当に重要な指標ほど、測定が難しい。評価は通常数値と結びつけられるため、数値を出せないということは、自身がもたらした影響を説明できないことと同義になってしまうからだ。

開発者のアウトプットは定量化が難しいため、手軽さからPull Request数やLLMトークン数、バグ数といった目に見えやすい代理指標が使われる。アウトプットは増えたように見え、エンジニアチームはより忙しくなったが、プロダクトは少しも良くなっていないように思える。

『フェニックスプロジェクト』の中のある言葉が強く印象に残っている――重要なのは結果であり、仕事量ではない。肝心なのは何のために測定するのかであり、何を測定するのかではない。

そうだ、僕たちは何のために測定しているのだろうか？ 代理指標はあまりにも手軽なため、油断すると僕たちは本当に重要なことを棚上げにしてしまう。

チームの生産性にとって、本当に重要なこととは何だろうか？ 実はGoogleの Project Aristotle を見るとそのヒントがある。

これはGoogleが2012年頃から開始し、2015年に公開した社内研究で、自社の数百に及ぶチームを分析し、何がチームの生産性を高めるのかを突き止めようとしたものだ。彼らが発見したのは、チームのメンバーが「誰であるか」よりも、チームが「どのように協力しているか」の方がはるかに重要だということだった。具体的には以下の要素があり、重要度の順位は次の通りだ：

1. 心理的安全性（Psychological Safety）：メンバーが恥をかいたり報復されたりすることを恐れずに、リスクを取ったり弱みを見せたり、ミスを認めたりできること
2. 信頼性（Dependability）：時間通りに成果物を仕上げ、高いクオリティ基準を満たすこと
3. 構造と明確さ（Structure and Clarity）：役割、目標、実行計画が明確であること
4. 仕事の意味（Meaning）：仕事が個人にとって意味を持っていること
5. 仕事のインパクト（Impact）：自分の仕事に実質的な貢献があると信じられること

これら5つの要素を定量化するのは難しい。心理的安全性を例にとると、それは次のような点に現れるかもしれない：

• 怒られるのを恐れずに、気軽にSlackで質問できるか
• シニア開発者に質問し、必要な情報をすべて得ることができるか
• 入社した最初の1週間で、次に自分が何をすべきかを明確に把握できているか

これらの指標は測定が難しいが、チームのアウトプットを左右する極めて重要な要素だ。これらはすべて、数字が教えてくれないことなのだ。測定が難しいがゆえに、見過ごされがちでもある。

あるミーティングで、僕は上層部と工数見積もりの目的と期待する効果について議論した。

そのミーティングで、見積もりの目的について双方の認識に大きなズレがあることに気づいた。

僕は、見積もりとは主に要件をすり合わせ、実装に対する双方の認識を一致させるためのものであり、チームのアウトプット指標として扱うべきではないと考えていた。一方、上層部は見積もりを、開発者が成長しているかを評価し、その後のスケジュールを調整し、チームのアウトプットを把握するための指標だと考えていた。見積もりの仕組みが導入されたとき、チームが感じたのはプレッシャーと義務感だった。長めの見積もりを出せば、上層部から「なぜそんなに時間がかかるのか」と問い詰められ、短めの見積もりを出して達成できなければ、「なぜ見積もりを守れなかったのか」と叱責される。

チームは軽率に見積もりを出すことを恐れ、見積もりを出すこと自体がリリース日の確約になってしまうことを恐れた。また、要件の認識違いによる手戻りを恐れるあまり、積極的に要件をすり合わせることすら躊躇するようになった。チームのアウトプットを把握したかっただけなのに、なぜかえって状況が悪化してしまうのか？

測定が目標になるとき、それはもはや良い測定ではなくなるのだ。

結論

開発者にとって、指標がもたらすメリットは疑いようがない。しかし、測定が目標になるとき、それはもはや良い測定ではなくなる。特にマネジメント層にいる場合、通常は指標を定義する側になる。指標を決める人間とそれを達成する責任を負う人間が異なることで、権限と責任の不均衡という問題に陥りやすい。

測定は強力なツールであり、その限界を知ってこそ使いこなすことができる。数字そのものだけでなく、数字の外側にある定量化しにくいものこそが、僕たちが真に追い求める価値のあるものなのかもしれない。