hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

測りすぎ――なぜパフォーマンス評価は失敗するのか?

計測結果をインセンティブに結びつけるとハックされてしまうという本。
科学実験とかなら計測するのは有益だけど、対象が人間の営みとかだと、指標とする数字を上げるための操作が可能になってしまう。学校において、テストの平均点を上げるために、点数の悪い生徒を障害児として別のグループに入れる、とか、医療現場において、手術成功率を上げるために、リスクのある手術をしない、とか、厳しい事例が紹介されている。

短期的な目標が報酬に紐付いていると売上を追い求めて値上げし続けて信頼を失ったりする、指揮官は固定給に切り替えている事例もある、という話も載っていた。
我が社では半年ごとに目標を決めて、今期はこれをやりましょうってやっているけど、上の方の人の目線も一律で半年後で売上を追い求めている、というよりは、もうちょっと先を見据えて、一喜一憂したり数字をハックしたりせずに暮らせるようになっている方がよさそう。
たとえばチームのリーダー的なポジションのエンジニアが採用活動に関わらず、数カ月後が締め切りの開発に専念していたら、もうちょっと先を見据えた動きをしたほうがよいのではないか、という思いになりそう。少なくとも、締切が終わったらバランスを戻して採用活動とか、未来に向けた段取りとかの活動をしてほしい、と思いそう。

専門的な現場では統一した指標を作るのは難しく、指標を作れたとしてもその現場に特化していて他の現場では何の役にも立たない、という話もおもしろかった。たとえば全社の生産性を上げるためのチームを作ることを考えると、まずは全社一律の指標を取って、それを上げればよい、という発想になりそうだけど、数字を取れてるからOK、とか、数字を取って上げれば解消、ではなくて、チームごとに原因となっている課題は別だと思われるので、実際に起きている問題を解決できてるかを考えるべきだと思う。

我が社では数年ごとにいろんなチームを渡り歩く形で異動することが推奨されているけど、そうすると同一人物が長期間プロダクトを担当するときよりは、一人あたりの経験とか専門性が薄まってしまうのではないか、ということを読みながら考えていた。プログラマーの友達でも長期間同じことをやっている人は特定のプロダクトの上のレイヤから下のレイヤまで幅広くチューニングできていてかっこいいなと感じることがある。経験を積むという点では新卒で入社してしばらくは渡り歩いたらいいけど、その後はテーマを決めてじっくり取り組むほうが専門性のある良い結果を出せるかもしれない。