ソフトウェア開発チームのパフォーマンスや「生産性」をどうやって測定・評価するかは、古くから多くのマネージャーを悩ませてきたテーマです。
これまで様々な測定手法が試みられてきましたが、名著『LeanとDevOpsの科学』では、過去に流行した生産性指標の多くを「望ましくない尺度（アンチパターン）」として明確に否定しています。
今回は、なぜ従来の手法がダメなのか、そして具体的によく使われがちな「3つのNG指標」とその落とし穴について解説します。
山脇 弘成（SSAITS代表）
PMP®有資格者・Webプロジェクトマネージャー。
大手メディアや官公庁のWebプロジェクト実績多数。
「技術」だけでなく「対話」を重視し、御社の「ほんとは、こうしたかった」を形にします。
従来の手法が抱える「2つの根本的な難点」
具体的なNG指標を見る前に、これまでの生産性測定手法がなぜ機能しなかったのか、その根本的な理由を押さえておきましょう。本書では以下の2点を指摘しています。
- 「成果（価値）」ではなく「出力（量）」に焦点を当てている
ビジネスとしてどれだけ価値を生み出したかではなく、単に「どれだけ作業をこなしたか」という量を測ってしまっている点です。 - チーム全体ではなく「ローカルな個人レベル」に偏っている
組織全体のグローバルな成果ではなく、個人や単一チームの成果ばかりを測定するため、部門間の対立や非協力を招いてしまう点です。
これを踏まえた上で、過去によく使われてきた「3つの望ましくない測定手法」とその問題点を見ていきましょう。
やってはいけない「3つの望ましくない指標」
「書いたコードの量（行数）」で測る
かつて、開発者が書いたコードの行数（Lines of Code）で生産性を測り、評価する手法がありました。しかし、これは最悪の指標です。
行数で評価（報酬）を与えてしまうと、開発者は評価を上げるために、わざとコードを長く書く（水増しする）ようになります。本来、1,000行よりも10行でシンプルに問題を解決できるエンジニアの方が圧倒的に優秀です。行数で評価すると無駄に肥大化したソフトウェアが生み出され、後々の保守や変更のコストを爆発的に増大させてしまいます。
極論を言えば、「コードを1行も書かずに問題を解決できること」のほうが、ビジネスとしての価値は高いのです。
「ベロシティ（速度）」で測る
アジャイル開発の普及に伴い、チームがスプリント内でこなした作業量（ストーリーポイント）の合算である「ベロシティ」を生産性の指標にする手法が登場しました。
ベロシティ自体は「チームが自分たちの計画を立てるためのツール」としては優秀ですが、これを管理者が生産性の測定やチーム間の比較に使おうとすると、途端に害悪になります。
- 比較できない： チームが置かれている状況やポイントの基準はそれぞれ異なるため、ベロシティはあくまで「そのチーム独自の相対的な尺度」であり、他チームとの比較には絶対に使えません。
- 悪用される： ベロシティを評価基準にした瞬間、チームは「作業の見積もりポイントをわざと大きくする（水増しする）」「他チームとの協力を犠牲にして、自分のチームのポイント稼ぎを優先する」といった数字の操作（ハック）を始めてしまいます。
「利用率（稼働率）」で測る
最近では、チームメンバーの「利用率（稼働率）」を常に100%に近づけようとする手法もありますが、これにも大きな落とし穴があります。
利用率を常に高く保とうとすると、チームから「余力（余裕）」が完全に失われます。その結果、予想外のトラブル対応や計画変更、システム改善のための作業を割り込ませる隙がなくなり、待ち行列理論が示すように「リードタイム（作業に着手してから完了するまでの時間）」が無限大に伸びてしまうという悪循環に陥ります。適度な「遊び（余白）」がない組織は、変化に対応できないのです。
まとめ：評価指標が「誤った行動」を引き起こす
これらの従来の手法に共通しているのは、「チームがビジネスに対してどれだけ早く、安定して価値を提供できているか」という真のパフォーマンスを測れていないという点です。
それどころか、開発者にコードを水増しさせたり、ポイントを誤魔化させたりと、かえって「組織にとってマイナスな行動」を引き起こす原因になっていました。
「人は測定されたとおりに行動する」という言葉があります。
誤った指標はチームを崩壊させます。見せかけの生産量や個人の稼働率を測るのをやめ、真の価値提供にフォーカスした指標（Four Keysなど）へシフトしていくことが、現代の開発組織には求められています。
