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

前言

僕はある仕事で、自分で小さなツールを書いて、僕（そして他のチームメンバー）がその四半期にどれだけ Pull Request を出したか、どれだけ Review Comments を残したか、どれだけ Tickets を片付けたかを集計し、それをもとに上司に僕の成果と貢献を証明しようとしたことがある。

上司は僕のレポートを見たあと、淡々と、評価は成果だけを見るのではなく、影響力や、君がどんな価値をもたらしたかも見るのだと言った。当時の僕は少し腹が立った。あれだけやったのに、正当な報酬をもらえていないと感じたのだ。

そのときの僕は腹を立てていて、上司にこう聞いた。「つまり、僕がサボって何も出さなくてもいいってことですか？」上司はその問いに真正面からは答えなかった。そして僕は当然、理想的な評価は得られなかった。

数年後、僕はようやく上司の言葉を理解し、むしろ僕の成果を直接褒めなかったことに感謝するようになった。測定が目的になったとき、測定の意味は失われる。

指標を壊してしまう話

1696年、イギリスでは家の窓に税金がかけられるようになった。窓が多いほど税は重い。たいてい窓が多いのは金持ちの家なので、税吏は通りから数えればよく、家に入る必要がなかった。

税率を下げるために、国中の窓が一つずつ煉瓦で塞がれ、新築の家でさえ窓を作らなくなった。当時のイギリスでは感染症が流行しており、窓がないと家の換気が悪くなり、人々は感染症にかかりやすくなった。

古代エジプト人はナイル川のほとりに、専用のナイル川水位計を建て、毎年の氾濫の高さをもとにその年の税率を決めていた。水位の高さは絶対にごまかせない自然指標だが、それでも回避はなくならなかった。

税率を変えられないなら、農民は耕作地の面積を少なく申告し、測量する書記に賄賂を渡し、納める穀物に石を混ぜて重量をかさ増しした。すると国家は、収穫から穀物の輸送まで全工程に監視員をつけなければならなくなった。税率が高いと限界効用は逓減し、農民は自然と生産量を増やしたがらなくなる。

1902年のベトナム・ハノイでは、ネズミを根絶するために、ネズミの尻尾一つで報奨金を出すと政府が公告した。すると、尻尾だけ切って放したネズミや、さらにはネズミを専門に飼う人まで現れた。鼠害は解決するどころか、かえって悪化した。

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

なぜ代理指標はそんなに魅力的なのか？

指標を測ることは極めて重要だ。ソフトウェア開発には「可観測性（Observability）」という言葉がある。数字を見えるようにすることはソフトウェア開発の重要な一部であり、数字があるからこそ、どう改善し、どうバグを直すべきかが分かる。

• データベース接続数が急増した：どこかの SQL がよくなくて slow query が接続を埋め尽くしているのかもしれない
• CPU 使用率が高すぎる：データ量が大きすぎて計算量が急増しているのかもしれない
• API の応答時間が大きく伸びた：依存している第三者サービスが故障しているのかもしれない

測定は、問題を見つけてプロダクトを改善するための重要な手段の一つだ。問題は、多くの会社の上層部が測定指標のもたらす影響を十分に理解していないことだ。いったん指標を測り始めると、数字をきれいに見せること自体が目的の一つになってしまう。昔からずっとそうだ。

Pull Request 数、解決した Bug 数、LLM Token 数、コード行数で開発者の成果を評価すると、開発者は数字をよく見せるためにそれに対応した行動を取るようになる。たとえば、わざとシステムを少し壊れやすく書いたり、Pull Request 一つで解決できる機能を 10 個に分けたり、AI が無意味なコードを延々と生み出すような自動化ツールをわざわざ書いたりする。測定が目標になったとき、それはもはや良い測定ではない。

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

重要な指標は測りにくい

本当に重要な指標は、測りにくい。評価はたいてい数字と結びつけられるので、数字を出せないということは、自分がもたらした影響を説明できないのと同じだ。

開発者の成果は定量化しづらいので、手軽さのために Pull Request 数、LLM Token 数、Bug 数のような分かりやすい代理指標を使う。成果は上がっているように見え、エンジニアリングチームはより忙しくなったように見えるが、プロダクトはどうも良くなっていない。

Phoenix プロジェクトの一節が僕の印象に強く残っている——重要なのは結果であって、作業量ではない。要点は何を測るかではなく、何のために測るかだ。

そうだ、僕たちは何のために測っているのだろう。代理指標はあまりに便利で、少し油断すると、本当に重要なことを脇に追いやってしまう。

チームの生産性にとって、本当に重要なことは何だろうか。実は Google の Project Aristotle から、その一端がうかがえる。これは Google が 2012年ごろから始め、2015年に公開した社内研究で、社内の数百チームを分析し、何がチームを生産的にするのかを探ったものだ。そこで分かったのは、チームのメンバーが誰かよりも、チームがどう相互作用するかのほうがはるかに重要だということだった。具体的には次の要因があり、重要度の順は以下の通りである。

1. 心理的安全性: メンバーが、辱められたり報復されたりする心配なく、リスクを取ったり、弱さを見せたり、ミスを認めたりできること
2. 可靠性: 期限通りに出し、品質基準を満たすこと
3. 役割期待: 役割、目標、計画が明確であること
4. 意義: 仕事が個人にとって意味を持つこと
5. 影響力: その仕事に実質的な貢献があると信じられること

この五つの要因は定量化しにくい。心理的安全性でいえば、たとえばこういう形で現れる。

• Slack で気軽に質問でき、叱られる心配をしなくてよいか
• 経験豊富な開発者に質問して、必要な情報をすべて得られるか
• 入社して最初の一週間で、次に何をすべきかがはっきり分かっているか

これらの指標は測りにくいが、チームの成果にかなり重要な要素であり、数字では教えてくれないことだ。測りにくいということは、見つけにくいということでもある。

ある会議で、僕は上層部と見積もりの目的と期待される効果について話し合った。

その会議で、見積もりの目的について双方の認識にかなり大きなずれがあることが分かった。

僕は、見積もりは主に要件をすり合わせ、双方の実装に対する認識を揃えるためのものであり、チームの成果指標として扱うべきではないと考えていた。一方で上層部は、見積もりは開発者が進歩しているかを評価し、今後のスケジュールを組み、チームの成果を把握するための指標だと考えていた。見積もり制度が導入されると、チームが感じるのは圧力と約束だった。長めの見積もりを出せば、なぜそんなに時間がかかるのかと疑われる。短めの見積もりを出して達成できなければ、なぜ見積もりを守らなかったのかと叱責される。

チームはむやみに見積もりを出せなくなり、いったん見積もりを出せばリリース時期を約束したことになるのではないかと恐れたし、要件の認識違いで再開発になるのが怖くて、積極的に要件をすり合わせることもできなくなった。ただチームの成果を理解したかっただけなのに、なぜか状況は悪くなる一方だったのだ。

測定が目標になったとき、それはもはや良い測定ではない。

結論

開発者として、指標がもたらす利点は疑いようがない。しかし、測定が目標になった瞬間、それはもはや良い測定ではなくなる。特に上に立つ者としては、たいてい自分が指標を定義する側だ。指標を定める人と、それを達成する責任を負う人が別であると、権責不均衡 の問題に陥りやすい。

測定は強力な道具だ。その限界がどこにあるかを知ってこそ、うまく使える。数字そのものだけでなく、数字の外側にある、定量化しにくいことこそ、僕たちがより追求すべきものなのかもしれない。