ダッシュボードの前に、三つの問いをそろえる
では、明日から何をすればよいでしょうか。数値をやめるのではなく、数値の設計と使い方を変えます。
指標を一つ決める前に、第1回と同じ三つの問いを指標ごとに書き出してみてください。
- 何のためにこの数値を見るのか
- 誰が、何の判断に使うのか
- 個人の評価や人事に直結させないか
そのうえで、最低でも二軸のセットを選びます。例として、変更リードタイムと変更失敗率のように、速さと安定性の対をデリバリー指標に置く。仕事量の指標を別に置くなら、チーム単位で改善のためだけに使うと明言する。四半期ごとに指標がゲーム化されていないか、実際の価値創出とずれていないかを見直します。
関係者ごとに「開発生産性で何を重視しているか」を15分ずつヒアリングし、表にまとめるだけでも会話は変わります。エンジニアは持続可能な開発速度とコード品質、QAはテスト時間とバグの段階、PMはユーザー価値と計画の信頼性、管理職は売上とコスト。これらはそれぞれ正しい視点です。統合するのは一つの数字ではなく、共通のゴールと、指標の役割分担です。
合意した数値とその理由は、議事メモやダッシュボードの横に、なぜこの指標を見ているかを短く残してください。数値を武器に理論武装するのではなく、遅れたときや改善するときに同じ材料を見ながら話すための道具にします。
指標がゲーム化されていないか確認するときは、次の三つをチームで見ます。
- 指標を上げるためだけの行動が増えていないか
- 指標が上がってもユーザー満足度や障害件数、計画の信頼性が伴っているか
- リファクタリングや調査のような見えにくい仕事が継続的に時間を確保できているか
このうちの一つでもずれていれば、指標の見直しか、評価との切り離しを検討します。
現場で明日からできることは、使っている指標を一枚のメモに書き、三つの問いに答え、上司やPMと15分すり合わせることです。ダッシュボードを増やす前に、誰のための数字かをそろえるだけで、指標を上げることが目的化した会話は止まりやすくなります。
数字をやめるのではなく、使い方を変える
開発生産性は定量化できます。ただし、一つの数字で測れ、測れば信頼が生まれる、全員が同じ数字を見ているという前提は誤解です。立場によって分子と分母が異なり、指標が評価に直結すると形骸化し、チームの改善が組織の成果に届かないこともあります。これは数値を否定しているわけではなく、数値の設計と対話のあり方を直すための提案です。
次回は数字に乗りにくい技術的負債をどう扱うか、第3回「技術的負債の誤解〜測れないから説明できないを越える〜」で扱います。測ることと、測れない価値を伝えることは、セットで考える必要があります。
参考文献
- 広木大地. 「開発生産性について議論する前に知っておきたいこと」. Qiita, 2022
- Petersen, K. et al. "Measuring and predicting software productivity: A systematic map and review." 2011
- DORA. DORA metrics guide
- Forsgren, N. et al. "The SPACE of Developer Productivity." ACM Queue, 2021
- Faros AI. The AI Productivity Paradox（AI Engineering Impact Report, July 2025）
