数字は「嘘をつける」──KPIがチームの協力を破壊する構造的な理由

はじめに

2週間に一度の振り返りミーティング──スプリントレトロスペクティブと呼ばれる場の午後だった。

チームの作業量を示す数字が、2回連続で下がっていた。この数字はベロシティと呼ばれ、タスクごとに振られたポイントの合計で表される。

マネージャーがグラフを画面共有した。右肩下がりの折れ線。「なぜベロシティが落ちたのか、チームで話し合いたい」。全員がカメラの前で黙った。

本当の理由を、全員が知っていた。前回の振り返りでベロシティを「盛った」のだ。3ポイントのタスクを5ポイントに見積もった。報告のときに「今回は順調です」と言えるように。

今回は正直に見積もっただけだ。下がったのではない。元に戻ったのだ。しかし、それを言う人は誰もいなかった。言えば、前回の数字が嘘だったことになる。

数字が嘘をつくのではない。数字が嘘をつかせる。 私自身、サービスの信頼性目標（SLO）の数値設計でこの力学に加担してきた側です。測る側として振る舞いながら、別の場面では測られる側に回る。その二重性に気づくまでに、時間がかかりました。

測ったものが目的になる

前回の『「あの人さえいなければ」──この誤診が、チームの生産性を下げる』では、意味のない忙しさの原因が「個人」ではなく「構造」にあることを見ました。

構造が見えたとき、人は自然に「では測ろう」と考えます。見える化しよう。数値化しよう。ダッシュボードを作ろう。計測は、構造を可視化する強力な道具です。

しかし、道具にはもう1つの顔があります。

計測の歴史を振り返ると、この二面性は人類と計測の付き合いの最初期から存在しています。

古代エジプトのナイルメーター（ナイル川の水位を測る装置）は、洪水を予測する道具であると同時に、税を徴収するための道具でもありました。水位が高ければ豊作が見込まれ、税率が上がります。農民にとって、計測は恩恵であり、脅威でもありました。

あなたの職場にも同じものがあるはずです。月次の売上報告、四半期の目標達成率。数字が見えた瞬間、その数字を「良く見せたい」力学が生まれる。数千年前から変わっていない構造です。

私はシステムの信頼性を守るSREという仕事をしてきました。「このサービスは99.9%の時間、正常に動くべきだ」という目標を立て（これをSLO──サービスレベル目標と呼びます）、「今月は実際に99.7%だった」と達成度を測る指標を設計します（これをSLI──サービスレベル指標と呼びます）。

「測ること」の価値は身に染みて知っています。エラーの発生率を測らなければ、障害に気づけません。応答にかかる時間を測らなければ、ユーザー体験の悪化に気づけません。計測は、見えないものを見えるようにする福音です。

問題は、「測ったものが目的になる」ときに始まります。 SLOを設定した瞬間、チームの行動が変わります。「SLOを守る」が目的になり、「ユーザーにとって良いサービスを提供する」が後景に退きます。SLOの数値は達成しているが、ユーザーは不満を感じている──この乖離を何度も経験しました。

私たちのオフィスにも、大きなモニターにダッシュボードが映っています。「どれくらいの頻度でリリースしているか」「問題が起きたとき、どれくらい早く直せるか」──開発チームの健康診断のような数字が並んでいます。DORA指標（開発・運用チームの能力を測る4つの指標）と呼ばれるものです。これ自体は有用な指標です。

しかし、モニターに常時表示されることで、「この数字を良くすること」が目的に置換されます。

リリースの頻度を上げるために小さなリリースを乱発します。障害からの復旧時間（MTTR）を短くするためにロールバック（以前のバージョンに戻す操作）で済ませて根本原因を調べません。

ダッシュボードの数字は改善します。しかし、システムの健全性は改善していません。ナイルメーターと同じ構造です。測る側が権力を持ち、測られる側が行動を歪めます。この構造は、数千年前から変わっていません。

指標が壊す3つのもの

計測への過信は、組織を静かに壊します。

「測定すれば改善できる」──この信念が行き過ぎると、数字に取り憑かれた状態になります。すべてを数字で把握しなければ不安になります。数字で説明できないものは存在しないことにする。

この症状が職場で引き起こす罠は、特に3つが致命的です。

手段が目的を駆逐する

冒頭の振り返りを思い出してください。チームの作業量を示すベロシティは本来、チームの作業能力を見積もるための参考値です。「先週20ポイント消化したから、今週も同じくらいできるだろう」という予測の道具。それが、いつの間にか評価の道具になります。

「ベロシティを上げよう」が目標になった瞬間、チームの行動が変わります。タスクのポイントを水増しします。大きなタスクを分割して見かけのポイントを増やします。数字は上がります。しかし、ユーザーに届く価値は増えていません。

指標の数字を良くすること自体が目的になり、指標が本来測ろうとしていた目的、つまりユーザーに価値を届けることは忘れ去られます。手段が目的を駆逐するのです。ベロシティを上げることに夢中になり、肝心の「ユーザーにとっての価値が増えたか」は誰も問わなくなります。

ベロシティの批判は、もう千回は書かれています。千回書かれて、なお多くのチームがベロシティで評価されています。私のチームもそうでした。全員がベロシティの問題を知っていました。知っていて、四半期報告にはベロシティのグラフを載せ続けていました。載せないと「何で評価すればいいかわからない」と上から言われるからです。

知っていることと、構造を変えられることは別です。問題は個人の無知ではなく、組織の慣性にあります。マネージャーが代替指標を持たないとき、数字は便利すぎます。数字は説明責任を果たした気にさせてくれます。これも前回触れた「証拠づくりの仕事」の一種でしょう。

短期の成果が長期の価値を駆逐する

2つ目の罠は、計測が時間軸を短縮することです。

四半期ごとに成果を報告します。報告には数字が要ります。数字を出すには、四半期以内に成果が出る仕事を選ぶ必要があります。結果として、半年かかるリファクタリング（設計の改善）は後回しになります。1年かけて育てるべき技術基盤への投資は見送られます。「今期の数字」のために、来期の問題を先送りします。

私のチームでも起きました。「技術的負債（いずれ対処が必要な設計上の借金）の返済に充てる開発サイクル」を提案したとき、上司に言われたのは「それ、今期のOKR（目標と主要な成果指標）にどう貢献するの？」でした。技術的負債の返済は、今期のOKRには貢献しません。成果が目に見える形で現れるのは来期以降だからです。

しかし、返済しなければ来期の開発速度が30%落ちます。返済を先送りするコストは月ごとに膨らみます。最初の月は気づかない。3ヶ月目には新機能開発の時間を蝕み始める。30%という数字は見積もりであって、証明ではありません。証明できない未来の損失より、計測できる今期の成果が優先されます。

計測可能な短期の成果が、計測困難な長期の価値を駆逐します。四半期の数字は出せますが、チームの基盤は蝕まれていきます。やがて開発速度が落ちたとき、「なぜ遅くなったのか」をまた数字で測ろうとします。数字が作った問題を、数字で解こうとする。同じことが延々と繰り返される罠です。

その後、技術的負債の返済を「今期のOKR」として通したことがあります。説得に使ったのは、皮肉にも数字でした。「対応工数を月20時間削減」という見積もりを出しました。本当の理由は「このままでは半年後に手が打てなくなる」という直感です。しかし直感では予算は通りません。数字の言語で語らなければ、数字の組織では聞いてもらえません。

個人KPIが助け合いを壊す

ここまでの2つは、組織が自分たちにやっていたことです。3つ目は、自分が同僚にやっていたことで、最も根深い罠です。

個人のパフォーマンスを数字で評価します。コードのコミット数、レビューの件数、解決したタスクの数。一見合理的です。しかし、個人KPIを導入した瞬間、チーム内の助け合いが変質します。

同僚が困っています。手を止めて30分助ければ、その人のタスクは終わります。しかし、30分を使えば自分のタスクが1つ減ります。KPIは自分のタスク消化数で評価されます。助けることにインセンティブがありません。むしろ、助けないことにインセンティブがあります。

構造的に見れば、個人の業績指標は、集団の協力を破壊します。誰も悪意を持っていません。全員が合理的に行動しているだけです。しかし、個人の合理性の総和が、チーム全体の非合理を生みます。

ゲーム理論でいう囚人のジレンマ（2人とも協力すれば最善の結果になるのに、相手を出し抜いた方が得をするため、結局2人とも裏切ってしまう構造）と同じです。

協力が最適解だと全員が知っています。しかし、評価制度が裏切りにインセンティブを与えています。前回紹介した「全員忙しいのに何も進まない」構造の、もう1つの原因がここにあります。

計測は設計者を裏切る

3つの罠に共通する構造があります。測る側が権力を持ち、測られる側が行動を歪めます。

計測の歴史を振り返ると、この構造が、人類がずっと抱えてきた治らない病であることがわかります。

ナイルメーターは税徴収の道具になりました。産業革命の工場時計は労働者の管理ツールになりました。現代の業績指標（KPI）ダッシュボードも同じ系譜にあります。

ナイルメーターの前に立つ農民と、ダッシュボードの前に立つエンジニア。数千年の隔たりがあるのに、構造は同じです。測られる側は、測る側が見たい数字を「演じる」ようになります。

ただし、1つ重要な違いがあります。ナイルメーターを設置したのは農民ではありませんでした。しかし、エンジニアはダッシュボードを自分で設計します。私たちは自ら檻を作り、その中に入っています。設計者であり囚人でもある構造は、ナイル川の時代にはありませんでした。

設計者であり囚人。この自覚があるなら、どう振る舞えばいいのか？

完全な数字を求めると動けなくなります。SREとして基盤刷新を提案したとき、「半年で応答時間を50%改善」を数字で約束しました。しかし蓄積した技術的負債のために、最初のコードを本番に置くだけで3ヶ月かかりました。数字で約束した瞬間、数字が自分を追い詰めます。

計測は、感覚的に言えば7割の解像度で「方向性」を確認する道具であって、100%の精度で「正解」を保証する道具ではありません。7割わかれば十分です。残りの3割を追い求めるコストは、最初の7割を得るコストより遥かに大きい。

完全な計測は幻想であり、その幻想が計測の設計者自身を裏切ります。

「何を測るか」ではなく「何のために測るか」

「測ることが害なら、測るのをやめればいいのか？」──そうではありません。計測を捨てるのは、本末転倒です。

SREの経験から学んだことがあります。SLO（サービスレベル目標）を設計するとき、最初に問うのは「何を測るか」ではなく「何のために測るか」です。

ユーザーがログインできること。ページが2秒以内に表示されること。注文が正しく処理されること。すべてユーザーの体験に紐づいています。ユーザー体験に紐づかない指標は、構造的に害になるリスクを持ちます。

この原則は、チームの指標設計にも適用できます。

「作業量の数字を測る」のではなく、「ユーザーに届いた価値を測る」。「コードの更新回数を数える」のではなく、「チームが解決した問題の影響範囲を振り返る」。「個人のタスク消化数を評価する」のではなく、「チームとして何が前に進んだかを確認する」。

しかし、「ユーザーに届いた価値」を測ることは、ベロシティを測ることよりはるかに難しい。数字にしにくい。比較しにくい。説明責任を果たしにくい。だから多くの組織が、測りやすいベロシティに逃げます。「測りやすいもの」と「測るべきもの」の不一致こそが、計測の根本的な困難です。

そして、もう1つ告白すべきことがあります。「ユーザーに届いた価値で測れ」という主張自体が、別の測定執着を生む可能性があります。

「ユーザー価値」を定量化しようとした瞬間、NPS（顧客推奨度）やCSAT（顧客満足度スコア）が新たな支配的指標になります。測定対象を入れ替えても、「測ったものが目的になる」構造は残ります。

完全な解決策は、この記事には書けません。書けませんが、この構造的な限界を認識しておくことには意味があります。

チームの生産性にとって最も重要なものは、ほとんどの場合、測定困難です。

心理的安全性──チームの生産性を最も強く予測する因子は、技術力でも勤勉さでもなく「心理的安全性」だという研究結果があります。失敗を報告しても責められない。「わからない」と言える。質問しやすい。私のチームでも、ある時期「障害を報告すると怒られる」空気ができたことがありました。その3ヶ月間、障害報告の件数が半分に減りました。障害が減ったのではありません。報告が減ったのです。しかし、心理的安全性をKPIにした瞬間、アンケートで「安全だと感じている」と回答することが目的になりかねません。

暗黙知の共有──あるベテランが10年かけて蓄積した障害対応（トラブルシューティング）の勘。「このエラーが出たとき、たいていあの構成要素（コンポーネント）が原因」という経験則。チームの生産性に直結しますが、数字にはなりません。

「ちょっといいですか」の質問しやすさ──隣の席の同僚に気軽に聞ける雰囲気。リモートワークでは「ちょっといいですか」のハードルが上がります。そのハードルの高さは、チームの生産性に直結しますが、測定する方法はほぼありません。

これらは測定困難ですが、チームの生産性を左右する核心です。測れなくても、確かに存在しています。

むしろ、測れないからこそ、数字で駆逐されやすい。

ベロシティは測れるから注目されます。「気軽に話しかけられる雰囲気」「質問のしやすさ」は、本質的には測れないから後回しにされます。測れるものが測れないものを追い出す。数字への執着が行き着く先です。

「測れない」に隠された価値

あるチームにベテランのSREがいました。障害が起きたとき、ログを3行読むだけで原因の見当をつけました。新人に「このパターンはあの構成要素を疑え」と教えていました。

この人の四半期のタスク消化数は、チームで最も少なかった。ベロシティの表では最下位です。組織再編でそのベテランは別チームに異動しました。翌四半期、チームのMTTR（障害からの復旧時間）が2倍になりました。

正直に言えば、あのベテランがいた頃、私もタスク消化数の表を見る側にいました。「測りやすいもの」で人を見ていた側です。

でも、暗黙知は測れません。測れないから、ベロシティの表には載りません。載らないから、失われるまで誰も価値に気づきません。駆逐された側は、存在しなくなったわけではありません。見えなくなっただけです。見えないものは予算がつかず、評価されず、やがて本当に失われます。

経済学にグレシャムの法則というものがあります。「悪貨は良貨を駆逐する」。計測の世界では「測りやすい指標が、測りにくい指標を駆逐する」。この力学をさらに別の方向へ歪めるものがあります。AIです。

先月、四半期レビューの資料をAIに下書きさせました。数字の整理は正確でした。グラフも整っていました。しかし「MTTRが改善したのに、なぜチームの疲弊感は増しているのか」への答えは書かれていませんでした。あのベテランが持っていた「数字の裏側」を読む力──それはAIの出力には含まれていません。

「測りやすいもの」──コード、ドキュメント、分析レポート──をAIがほぼゼロコストで大量生産できるようになると、グレシャムの法則が別の形で効くかもしれません。

安くなったアウトプットではなく、AIには生成しにくいもの──判断の責任を引き受けること、チームの文脈を身体で理解していること、失敗のリスクを負って意思決定すること──の方が希少になっていく。

計測の限界を語ってきたこの連載の議論は、AI時代にはもう少し切実さを増すのではないかと感じています。

おわりに

振り返りミーティングの話に戻ります。

ベロシティの折れ線グラフが画面に映っている。全員が黙っている。あの日、私はこう言ってみました。

「ベロシティの数字をいったん置いて、今週チームで一番うまくいったことを話しませんか？」

少し間があって、1人が言いました。「木曜に新人の質問に30分つきあった。あの後、新人が自力でタスクを2つ終わらせていた」。別のメンバーが続けました。「あのAPI設計、レビューで3回やり直したけど、結果的にすごくシンプルになった。あの時間は無駄じゃなかった」。

どちらもベロシティには表れない話です。新人の成長も、設計の改善も、ポイントでは測れません。しかし、チームの生産性にとって最も重要なことは、まさにそこにありました。

計測は道具です。包丁が料理にも凶器にもなるように、道具は使い方を選びます。「何を測るか」の前に、「何のために測るか」を問います。測れないものの存在を忘れません。数字を見ながら、数字の外にあるものへ目を配ります。

正直に告白すれば、私はこの記事で計測の問題点ばかりを書きました。しかし、SLOが深夜の障害検知を何度も救ってくれた事実は変わりません。計測を捨てたいのではありません。計測に支配されたくないだけです。結局のところ、計測の限界を知ることが、計測を正しく使う前提条件です。

「生産性を取り戻せ」と題したこの連載で、第1回は忙しさの構造を見ました。第2回で見えたのは、その構造を数字で「直そう」とした結果、数字に生産性を奪われたということです。

では、数字の外にある生産性とは何か？

新人に30分つきあったこと。設計を3回やり直したこと。ベロシティには載らないが、チームの未来を作った時間。生産性を取り戻すとは、数字に奪われた「意味」を取り戻すことかもしれません。 その「意味」の正体は、まだ見えていません。

測ることの限界が見えた。 しかし、数字の外にある意味を判断するには、人間の認知が健全に機能している必要があります。ところが、その認知自体が構造的に歪んでいるとしたら。

次回は、「賢さ」そのものがチームを壊すメカニズムを見ていきます。

参考資料

↓連載第1回の記事はこちら

2026年4月16日「あの人さえいなければ」──この誤診が、チームの生産性を下げる