EMメトリクス: 開発速度、コード品質、人材定着、採用

初めてQBRにstory pointsのチャートを持ち込んだとき、VPは私が90秒ほど話すのを聞いてからこう言いました。「Camellia、惜しまれる離職率は? それからデプロイ頻度は? pointsは忘れて。」

どちらの数字も持っていませんでした。sprintごとの開発速度の美しいカラーバーチャートと「Q3スループット+18%」というスライドを持っていました。その何も質問には通用しませんでした。彼は失礼だったわけではありません。正直だっただけです。エグゼクティブ層は成果に資金を出しています。私はアクティビティを持ってきていました。同じ言語を話していなかった。その後の予算の会話は、想像通りの温度でした。

そのミーティングでダッシュボードの運用方法が変わりました。このガイドは、あれば良かったと思うダッシュボードです: 6つのメトリクス、実際の数値の範囲、名前付きの診断、QBRスライド1枚。それ以上はありません。それ以上がGoodhart's Lawに食われる方法だからです。

なぜスループットよりアウトカムか

スループットメトリクス、つまりstory points、クローズされたチケット、コード行数、記録された時間は、アクティビティを測定します。アクティビティはチームが行ったことです。アウトカムは会社が得たものです。エグゼクティブ層はアウトカムに資金を出します: リリース速度、信頼性、チームの耐久性、採用スループット。これらの4つのバケツにチームの作業を翻訳できなければ、人員計画の会話から外され、採用凍結の通知が届くまでそれに気づきません。

2つ目の理由もあります。スループットメトリクスは誰も意図することなく簡単に操作できます。チケットのクローズ数を測定すると言えば、1四半期以内に小さなチケットが増えます。story pointsを測定すると言えば、2四半期以内に中央銀行家でも目を疑うようなインフレーションが起きます。アウトカムメトリクスは現実に結びついているため操作が難しいです。デプロイが起きたかどうかは二択、エンジニアが残ったか去ったかは二択、オファーが受諾されたか断られたかは二択です。

6つのメトリクスです。リリースと信頼性に4つ、チームの健全性に2つ。これがセットです。

デプロイ頻度

チームのコードが本番環境に届く頻度はどれくらいか? 毎日、毎週、毎月、またはそれ以下。これが最初のDORAメトリクスであり、リリースパイプラインが実際にパイプラインなのか、手動の鍵が必要な一連の施錠されたドアなのかを示す最もクリーンなシグナルです。

チームの成熟度別ターゲット層:

ほとんどのプロダクトチームはHighに位置するべきです。Mediumにいて業務が正当化する場合（規制業界、長いQAサイクル）は、スライドでそう述べてください。SaaSチームでLowにいるなら、それは数字ではなく所見です。

変更のリードタイム

commitから本番環境まで。これが2番目のDORAメトリクスで、ボトルネックが実際にどこにあるかを教えてくれます。時間、日数、または週数。

これを測定して分解すると、通常3つの犯人の1つが見つかります: コードレビュー（PRがシニアエンジニアを2日間待っている。ミーティング中）、CI（テストスイートが47分かかり5回に1回flakeする）、またはデプロイゲート（誰かのカレンダーに手動承認がある）。最も長いものを選んで修正する。3つすべてを一度に修正しようとしない。

チームタイプ別の健全な範囲:

• プロダクトチーム、Webアプリ: 24時間以下、理想的には8時間以下。
• プラットフォームチーム、インフラ: 48時間以下。
• モバイルチーム: 3〜7日、アプリストアのレビューで制限される。

リードタイムが2週間でデプロイ頻度が毎日なら、数学的におかしいことになります。ほとんどが些細な変更をデプロイしていて大きなものが滞留しているか、カウントが間違っています。スライドを出す前に調査してください。

変更失敗率

rollback、hotfix、または本番障害を引き起こすデプロイの割合。3番目のDORAメトリクス。ターゲット帯は0〜15%で、健全なチームは5〜10%に位置します。

2つのことに注意してください。まず、変更失敗率ゼロはアピールではなくフラグです。通常、チームがテストをしすぎているか、デプロイ頻度が低すぎるか、インシデントを過少カウントしていることを意味します。次に、このメトリクスには自然な下限があります。ソフトウェアは難しく、人間はバグをリリースし、2%の率はノイズであり、下降のシグナルではありません。開発速度を犠牲にして最後のパーセンテージポイントを追いかけないでください。

変更失敗率が15%を超えたとき、診断はほぼ常にこのうちの1つです: クリティカルパスのテストカバレッジが不十分、リリースプロセスが多くを一括にしすぎて失敗が絡み合う、または新入社員が影響範囲を理解する前に本番にリリースしている。どれかを名指ししてください。平均化して隠さないでください。

MTTR

平均復旧時間。本番環境で何かが壊れたとき、正常に戻るまでどれくらいかかるか? 日数ではなく時間単位です。これが4番目のDORAメトリクスであり、on-callの衛生状態に最も結びついています。

SaaSプロダクトの良いMTTRは4時間以下です。eliteチームなら1時間以下。コツは、MTTRが本当にどれだけ速く修正を書けるかではないことです。検出、診断、デプロイがどれだけ速くできるかです。デバッグした遅いMTTRのほとんどは、3つの場所の1つからでした: アラートが発火しなかった（チームは顧客からアウテージを知った）、runbookが存在しなかった（on-callエンジニアがゼロから把握していた）、またはデプロイパイプラインに90分かかる（修正が書かれた後も待機）。

MTTRが徐々に上昇しているなら、on-callの負荷を見てください。燃え尽きたon-callエンジニアは対応が遅いon-callエンジニアです。これはデプロイ頻度、変更失敗率、チームの健全性が互いに触れ合うメトリクスです。

12か月間の惜しまれる離職率

2つのチーム健全性メトリクスのうちの1つ目であり、VPが最も気にするものです。

惜しまれる離職は、残っていてほしかった人だけをカウントします。低パフォーマーが去ってもそれは惜しまれる離職ではありません。静かに目立たなかったミッドレベルのエンジニアが去って肩をすくめてもそれは惜しまれる離職ではありません。シニアIC、tech lead、または高い成長軌道にあるジュニアが去ったなら、それは惜しまれる離職です。ラベルを貼るときに自分に正直になってください。マネージャーは去った全員が「適切なフィットではなかった」と後付けで決める傾向があり、惜しまれる離職率0%で半分が去ったチームになる方法がそれです。

テック業界の基準値、2026年:

• 健全: 年間8〜12%。
• 要注意: 13〜15%。
• 問題: 15%超。
• 重大な問題: 20%超。

四半期ごとではなく、12か月のローリングベースで追跡してください。四半期の数値は小さなチームでは変動が大きすぎます。8人のエンジニアがいてQ2に惜しまれる離職が1件あれば12.5%: ローリングベースでは問題なし、四半期チャートでは恐ろしい数字。

採用のオファー受諾率とランプアップ期間

2つ目のチーム健全性メトリクス。チームが成長できるかどうかを教えてくれます。

2つのサブメトリクス、1つのスライドの行。オファー受諾率: 前四半期に出したオファーのうち、何パーセントが受諾されたか? ターゲットは70%以上。60%以下はオファーが競争力を欠いていることを意味します（通常はコンプ、時にはタイトル、時々ストーリー）。

立ち上がり期間: 入社日から最初の重要なPRが本番にマージされるまで何日かかるか? ターゲットは30日以下。平均的な新入社員が何か本物をリリースするのに60日かかるなら、オンボーディングが壊れているかコードベースが迷路です。いずれにせよ所見です。

2つの数字を合わせると採用のストーリーが分かります。高いオファー受諾率、速いランプアップ: 採用エンジンが機能している。高いオファー受諾率、遅いランプアップ: 売り込みは上手くできているが、オンボーディングが悪い。低いオファー受諾率、速いランプアップ: 入社した人は活躍しているが、クローズできない。低いオファー受諾率、遅いランプアップ: エンジンが両端で壊れている。

エンジニアリングNPS

四半期ごとのパルスサーベイ、1つの質問: 「このチームを別のエンジニアに推薦しますか?」 0〜10のスケール。批判者（0〜6）から推奨者（9〜10）を差し引き、中立者（7〜8）は無視。結果は-100〜+100の間になります。

健全なエンジニアリングチームは30〜50点を出します。50以上は良い。20以下は警告。マイナスはすでに始まっている問題です。ただ、まだ煙が見えていないだけです。

毎四半期同じ週に実施してください。匿名で。必ず1つのオープンエンドのフォローアップ質問を含めてください: 「スコアを1ポイント上げるために1つだけ変えるとしたら何ですか?」 すべての回答を読んでください。数字は見出しです。コメントが診断です。

「高い開発速度だが高い離職率」の診断

これはほとんどのEMが不意打ちを受けるアーキタイプです。デプロイ頻度は高い。変更失敗率は低い。リードタイムは優秀。MTTRは安定している。4つのDORAメトリクスでチームはチャンピオンのようにリリースしています。

そして惜しまれる離職率が上がっています。エンジニアリングNPSが下がっています。残ってほしかった人たちが去っています。

チームはリリースしながら会社を去っています。

これをまさに1度経験しました。月60回デプロイ、変更失敗率4%、MTTR90分以下、そして1四半期に3人のエンジニアを失いました。うち2人はシニアでした。メトリクスダッシュボードは省略によって嘘をついていました。真実は退職面談に現れました: 「疲れました。」「18か月間成長していません。」「競合他社の友人は同じ仕事で30%多く稼いでいます。」

通常3つの原因があり、しばしば重なります:

1. 燃え尽き。 高い開発速度は1四半期、時に2四半期は持続可能です。それを超えると、チームの未来を担保にしています。
2. 報酬格差。 市場が動き、あなたのバンドは動かず、シニアは毎週火曜日にLinkedInのメッセージを受け取るので知っています。
3. 成長パスがない。 学んでいる間は残りました。コードベースが小さく感じられ始めると、より大きなものを探します。

スライドで原因を名指ししてください。「人が去っている、エンゲージメントに取り組む」という一般的な文にまとめないでください。その文でチームが救われたことは一度もありません。

報告をやめるべき虚栄の指標

Goodhart's Law: ある測定がターゲットになると、良い測定ではなくなります。このリストのすべてのメトリクス、上の6つを含めて、脆弱です。ただし、以下の4つは十分に脆弱なので完全に廃止すべきです:

• 完了したstory points。 インフレーションが保証されています。より大きなものとしてフレームされたより小さなストーリーをリリースします。何が本番に届いたかについては何も教えてくれません。
• クローズされたチケット。 同じ問題、別のスコアボード。チケットが増殖するよう促します。
• コード行数。 タイピングの測定であり、エンジニアリングではありません。削除にペナルティを与えます。削除は通常最高のPRです。
• 記録された時間。 存在を測定し、アウトプットではありません。親たちにペナルティを与え、深夜の演技的なSlackメッセージに報酬を与えます。

入れ替えてください。story pointsとチケットはデプロイ頻度とリードタイムになります。コード行数は変更失敗率になります。記録された時間はエンジニアリングNPSになります。なぜなら、チームが健全でリリースしているなら、時間をカウントする必要はないからです。

QBRスライド

スライド1枚、6つのメトリクス行、3つの列: 現在、ターゲット、トレンド矢印。各行に1文の診断を追加する。それがフォーマットです。

レイアウトのサンプル:

6行。6つの診断。story pointsなし。付録に隠れた開発速度チャートなし。数字が悪ければ、はっきりそう言い、何をしているかを述べる。VPがそれを自分で見つけるより速く問題を名指しするEMを信頼します。隠すEMは信頼しません。

VPに何を求めるか

QBRは勝利のアピールではなく、質問で締めくくる。この四半期の会社にとって最も重要な6つのうちの2つはどれか、そしてどのターゲット帯が勝利と見なされるかを尋ねる。

6つすべてを一度に最適化しようとするのは何も得られない方法です。リリース速度に取り組んでいるチームは同時に採用スループットにも取り組んでいません。採用に取り組んでいるチームは、シニアがPRをレビューする代わりに候補者を面接している間、リードタイムが一時的に悪化します。2つを選ぶ。ターゲットについて合意する。来四半期また質問を繰り返す。

VPが「6つすべて」と言ったら、丁寧に押し返す。「今四半期2つに完全投資するために2つを投資不足にしなければならないとしたら、どの2つを優先度を下げるべきですか?」 その質問はほぼ常に実際の答えを引き出します。なぜならトレードオフを表に出すからです。

これが最初から入るべきだったQBRのバージョンです。6つのメトリクス。実際の数字。名前付きの診断。スライド1枚。story pointsチャートはしまっておくべき引き出しの中に収まっています。

関連記事

• 実際に機能する1:1のケイデンス
• チームを燃え尽きさせずにon-callローテーションを運営する
• 演劇なしのエンジニアへの人事評価
• 厳しい市場でシニアエンジニアを採用する
• Companion JD: Staff Software Engineer