スクラム外部委託の KPI にベロシティは使える？発注者向け 5 指標フレーム

「外注チームのベロシティは毎スプリント上がっているのに、経営会議で『それで本当に成果が出ているのか』と問われて言葉に詰まった」。スクラム外部委託を発注している担当者の方から、このような相談をよく受けます。契約更新のたびに費用対効果の説明を求められ、手元にあるベロシティの数字を提示すべきか、それとも別の指標を用意すべきか。社内のエンジニアからは「ベロシティを評価に使うのは危険」と言われ、頼れる指標が見つからず感覚的な評価から抜け出せない状況ではないでしょうか。

結論からお伝えすると、スクラム外部委託の KPI にベロシティを「単独の評価指標」として使うことはおすすめできません。しかしベロシティを完全に捨てるべきかというと、それも極端な話です。ベロシティは「進捗の予測可能性」を測るトラッキング指標として役割を変えることで、外部委託チームの状態を測る重要な観測点になります。

本当に必要なのは、ベロシティを含めた複数の指標をどう組み合わせるかというフレームです。進捗・計画精度・開発フローの健全性・品質・ユーザー価値の 5 側面を同時に観測することで、はじめて「この外注費用に見合う成果が出ている」「継続すべき」「追加発注に耐える」といった経営判断に耐える説明ができるようになります。

本記事では、なぜベロシティを単独 KPI にするとチームと成果が壊れるのかを整理した上で、発注者が明日から使える 5 指標フレームと、契約更新・単価交渉・追加発注の 3 つの意思決定シーンでの活用方法を解説します。ベロシティを「対話の起点」に位置づけ直し、感覚評価から数字に基づく多面評価に移行するための実務的な枠組みをご紹介します。

結論——スクラム外部委託の KPI にベロシティは「単独では」使えない

本題に入る前に、本記事の結論を先にお伝えします。スクラム外部委託の KPI について、経営層に説明できる形で成果を可視化したい発注者にとって、押さえるべきポイントは次の 3 つです。

• ベロシティは、契約継続・単価妥当性・追加発注の可否を判断する「主 KPI」としては使えません
• ただし、進捗の予測可能性を測る「トラッキング指標」としては非常に有用です
• ベロシティを進捗指標として残しつつ、価値・品質・予測精度を測る他指標と組み合わせれば、経営説明に耐える多面評価が作れます

3 行で分かる結論

一つずつ補足します。ベロシティを主 KPI にできない理由は、後述するように「Goodhart の法則」による指標ハックが発生し、数字が上がるほど実質的な価値提供が下がるという逆転現象が起きるためです。「ある指標が目標になった瞬間、それは良い指標ではなくなる」というこの法則は、スクラムの現場でも繰り返し検証されています（アジャイルメトリクス 〜 良い指標・悪い指標・酷い指標（サーバントワークス））。

一方でベロシティを完全に捨てる必要はありません。「今回のスプリントで完了したストーリーポイントの合計」という素直な観測データとして扱えば、チームがどの程度安定して仕事をこなしているか、いつまでに何が完了しそうかを予測する材料になります。数字の絶対値ではなく「安定度」を見る発想への切り替えが鍵です。

そして、契約更新会議で経営層に説明する際は、ベロシティを含む 5 つの指標を組み合わせます。詳細は後半で扱いますが、進捗・計画精度・開発フローの健全性・品質・ユーザー価値の 5 側面を並置することで、単独指標では見えない「本当に価値が生まれているか」を可視化できます。

なぜ「単独 KPI 化」が壊れるのか——Goodhart の法則

ベロシティを単独 KPI にすると壊れる理由を、少しだけ理論的に補足します。経済学者チャールズ・グッドハート氏の名前がついた「Goodhart の法則」は、平たく言えば「測定値が目標になった瞬間、人はその測定値を最大化するように行動する。結果、測定値の裏にあった本来の目的が達成されなくなる」というものです。

スクラム開発の文脈でこれが起きると、次のような現象が発生します。ストーリーポイントは「相対見積もり」であるため、同じ作業でも大きく見積もれば数字は上がります。楽な作業を優先すれば消化速度は上がります。「完了」の定義を緩めれば、テストが不十分な状態でも Done 扱いにできます。いずれも、発注者が受け取る成果の質を下げる方向の行動ですが、ベロシティの数字だけは向上します。

この構造上、ベロシティを単独 KPI にした瞬間、発注者は自分の期待とは逆の結果を招くことになります。「ベロシティを評価に使うのは危険」と社内エンジニアが指摘する背景には、こうしたメカニズムの理解があります（ベロシティ Deep Dive（Publickey））。

そもそもベロシティとは何か——発注者向け前提知識

ここからの議論をスムーズに追っていただくため、ベロシティの定義を簡単に整理します。すでに理解されている方は、次のセクションへ進んでいただいて構いません。

1 分で分かるベロシティの定義

ベロシティとは、1 スプリント（通常 1〜2 週間）で完了したストーリーポイントの合計値です。ストーリーポイントは、開発チームがユーザーストーリー（機能要求の単位）に対して「相対的な大きさ」を付ける見積もり単位で、フィボナッチ数列（1、2、3、5、8、13...）などが使われます。

たとえば、あるスプリントで「ログイン機能改修（3 ポイント）」「決済エラー修正（5 ポイント）」「レポート出力機能（8 ポイント）」の 3 つが完了した場合、そのスプリントのベロシティは 16 となります。次のスプリントでチームが計画を立てる際、直近数スプリントのベロシティの平均を目安に「今回はだいたい 16 ポイント分を計画に入れよう」という判断に使うのが、本来の使い方です（スクラムにおけるスプリント ベロシティ（Atlassian））。

数字を読むときの 3 つの前提

発注者としてベロシティの数字を受け取るとき、必ず押さえておきたい前提が 3 つあります。

1 つ目は「相対見積もり」であること。ストーリーポイントは、そのチームが過去に扱った基準タスクとの比較で決められています。同じ 5 ポイントでも、チーム A の 5 ポイントとチーム B の 5 ポイントは違う意味を持ちます。

2 つ目は「チーム固有の値」であること。1 つ目と関連しますが、ベロシティは異なるチーム間で比較しても意味がありません。「A 社は毎週 40 ポイント、B 社は 25 ポイントだから A 社の方が生産的」という判断は成立しません。

3 つ目は「時間に換算できない」こと。「1 ポイント = 半日」のような換算表を作ると、それは実質的に工数見積もりに戻ってしまい、ストーリーポイントを使う意味がなくなります。「ベロシティ × 時給」で費用対効果を計算するアプローチも、この理由で成立しません。

これら 3 つの前提は、スクラム指標の基礎（Atlassian） でも「ベロシティは顧客価値の測定にはならない」と明言されており、業界共通の認識です。

なぜベロシティを単独 KPI にするとチームと成果が壊れるのか

先ほど Goodhart の法則の概要を紹介しました。ここでは、実際にスクラム外部委託の現場で起きる 3 つの「指標ハック」を具体的に見ていきます。いずれも、発注者が受け取る成果の質を下げる方向にチームを追いやってしまう現象です。

ハック 1: ストーリーポイントの水増し

もっとも典型的なハックは、見積もりを大きく付けるようになることです。ベロシティが評価軸として使われると意識した瞬間、チームは「小さく見積もると自分たちの評価が下がる」というインセンティブに直面します。結果として、同じ規模の作業でも徐々にポイントが膨らんでいきます。

数値上はベロシティが右肩上がりになりますが、実際に届く機能の量は変わりません。発注者は「順調に速度が上がっている」と誤認しますが、実態は「ものさし自体が伸びている」だけです。この現象は、マネージャ必見! ベロシティでのスクラムチームの評価が危険な理由（Gonkun Blog） でも詳しく指摘されています。

ハック 2: 楽な作業の優先選択（価値の後回し）

2 つ目のハックは、確実にポイントを稼げる作業を優先することです。バックログには「価値は高いが実装が難しく、途中で詰まるリスクもある機能」と「実装が容易で確実に完了できる機能」が混在しています。ベロシティを最大化しようとすると、後者を優先する動機が働きます。

その結果、UI の細かい調整や軽微なバグ修正のような「消化しやすい作業」が積み上がり、本来最も価値を生むはずの中核機能開発が後回しになります。ベロシティは順調でも、プロダクトとしての競争力が伸びない、という状況が発生します。

ハック 3: 「完了」定義の緩和（品質のなし崩し）

3 つ目のハックは、「完了」の定義を緩めることです。スクラムでは「完了の定義（Definition of Done）」を明確にすることで、Done とされたタスクの品質を保証します。しかしベロシティが評価対象になると、「テストが通っていなくても、レビュー未実施でも、動作確認だけしたら Done にしよう」というプレッシャーが働きます。

その場のベロシティは上がりますが、後工程で品質問題が噴出します。本番障害の増加、リグレッションによる再対応、ユーザーからの不具合報告といった形で、遅れて発注者側に跳ね返ってきます。

発注者側に跳ね返る損失

これら 3 つのハックが同時に進行すると、発注者は次のような損失を被ります。まず「見た目のベロシティは高いのに、実際にリリースされる機能価値は下がる」という費用対効果の実質悪化が起きます。次に「品質問題への対応工数」が新たに発生し、追加コストとして表面化します。そして最も深刻なのは「開発チームの改善サイクルが崩れる」ことです。数字を守るための行動が優先され、レトロスペクティブでの本質的な振り返りや技術的負債への対処が後回しになります。

つまり、ベロシティを単独 KPI にすることは、発注者自身の利益に反する結果を招きます。ここまでが「なぜ単独 KPI にすべきでないか」の実務的な理由です。

ベロシティを「進捗指標」に位置づけ直す使い方

では、ベロシティを完全に捨てるべきかというと、そうではありません。役割を変えれば、依然として有用な指標です。ここでは、ベロシティを「達成目標」ではなく「進捗トラッキング指標」として使う 3 つの方法をご紹介します。

「達成目標」ではなく「予測可能性」の指標として使う

ベロシティを見るときの視点を「絶対値」から「安定度」に切り替えます。直近 3〜5 スプリントの平均値とブレ幅（標準偏差や最小・最大）を確認し、次のように解釈します。

• 平均に対してブレ幅が小さい → 予測可能性が高いチーム。計画通りに進む見込みが立てやすい
• 平均に対してブレ幅が大きい → 何らかの要因（見積もり精度・技術的負債・チーム内問題）で不安定。改善余地あり

数字が高いか低いかは、そのチームの特性であって評価対象ではありません。むしろ「常に一定のペースで進んでいるか」を見ることで、契約更新後の見通しの立てやすさを判断できます。

完了時期予測への活用

もう 1 つの有用な使い方は、リリース予測です。残っているバックログの総ポイントを、直近数スプリントの平均ベロシティで割ることで、「あと何スプリントで完了するか」の目安が得られます。

たとえば、残 120 ポイントのバックログがあり、平均ベロシティが 20 だとすれば、単純計算で 6 スプリント（12 週間）が完了予測です。ここで平均ではなく「悲観値（過去最小のベロシティ）」で割れば、リスクを見込んだ悲観予測が出せます。契約更新会議で「現状のペースなら○月に完了見込み、遅れリスクを織り込むと○月」と幅を持って報告できるようになります。

経営説明では絶対値ではなく安定度を報告する

経営層への報告では、「今週のベロシティは 32 でした」という絶対値の報告は避けます。代わりに、次のようなフレーズで報告します。

• 「直近 5 スプリントの平均は 30、ブレ幅は ±3 で安定推移しています」
• 「予測可能性が高い状態を維持しており、残バックログから逆算するとリリースは○月見込みです」
• 「今週は一時的に 20 まで低下しましたが、原因は特定済みで来週以降は元の水準に戻る見込みです」

数字そのものではなく「その数字が示す状態」を語ることで、ベロシティ単独 KPI 化の罠に陥らずに経営説明ができます。

スクラム外部委託の KPI に組み合わせる 5 つの指標フレーム

ここからが本記事の中核です。ベロシティを進捗指標として位置づけ直した上で、他の 4 つの指標と組み合わせた「発注者向け 5 指標フレーム」を提示します。この 5 つを 3 ヶ月推移で並べれば、経営説明・契約継続判断・単価妥当性検証・追加発注の可否のいずれにも耐える情報が揃います。

指標 1: ベロシティ（進捗の予測可能性）

• 何を測るか: 1 スプリントで完了したストーリーポイントの合計
• 何が分かるか: チームの計画立案の安定度・完了時期予測
• どう計測するか: 直近 3〜5 スプリントの平均値とブレ幅
• 確認すべき閾値の目安: ブレ幅が平均の ±15% 以内に収まっていれば「予測可能な状態」

前セクションで整理した通り、絶対値ではなく安定度を見る指標として使います。

指標 2: コミットメント達成率（計画精度）

• 何を測るか: スプリント計画時にコミットしたポイントのうち、実際に完了した割合
• 何が分かるか: チームの計画立案精度・見積もり能力
• どう計測するか: (完了ポイント ÷ 計画ポイント) × 100
• 確認すべき閾値の目安: 80〜90% 前後に安定していれば健全。100% を超え続ける場合は計画が保守的すぎる、60% を下回る場合は計画に無理がある

ベロシティが単純に「消化量」を測るのに対し、達成率は「予定通りに進む力」を測ります。この 2 つはペアで見ることで、水増しの兆候をつかめます（後述）。

指標 3: リードタイム / デプロイ頻度（開発フローの健全性）

• 何を測るか: 変更要求から本番リリースまでの所要日数（リードタイム）、および単位期間あたりのデプロイ回数
• 何が分かるか: 開発から本番反映までのフロー全体の速さ・詰まり
• どう計測するか: チケット作成日と本番デプロイ日から算出（GitHub や Jira のデータで抽出可能）
• 確認すべき閾値の目安: リードタイムが徐々に短縮していれば健全。長期化していれば技術的負債や合意形成の遅延が疑われる

この指標は、Google の DORA レポートで有名な「Four Keys」の一部です。開発チーム内で完結する速度ではなく、要求からリリースまでの全体フローを測るため、発注者にとっての「価値提供までの時間」を可視化できます。詳細は Four Keys メトリクスとは何か（Google Cloud） を参考にしてください。

指標 4: 品質指標（本番障害・再オープン率）

• 何を測るか: 本番リリース後に発生した障害件数、および Done とされたチケットが後日再オープンされた率
• 何が分かるか: 「完了の定義」が実質的に守られているか・品質の耐久性
• どう計測するか: 障害管理ツールの本番障害数、チケット管理ツールの再オープンフラグ集計
• 確認すべき閾値の目安: 本番障害数が月次で減少傾向、再オープン率が 10% 未満

ベロシティやコミットメント達成率が上がっていても、品質指標が悪化していれば「完了定義の緩和」というハックが起きているサインです。ペア観測の中核となる指標です。

指標 5: 価値実現指標（ユーザー価値・受入率）

• 何を測るか: 機能ローンチ後の実利用率、スプリントレビューでの受入率、ユーザーからの評価
• 何が分かるか: 実装された機能が実際にユーザー価値を生んでいるか
• どう計測するか: 機能利用ログ（GA4 等）、スプリントレビューの受入判定記録、ユーザーインタビュー・NPS
• 確認すべき閾値の目安: リリース機能の 70% 以上が想定利用率を超えている、レビュー受入率が 90% 以上

これはチーム内では観測できない、発注者・ステークホルダー側で観測する指標です。「作ったもの」ではなく「価値が生まれたもの」を測るため、5 指標の中で最も上位に位置づけます。契約更新・追加発注判断の主軸は、この指標です。

単独ではなく「ペア観測」で数字ハックを防ぐ

5 指標フレームを運用する際、必ず守るべき原則が「ペア観測」です。単独指標を切り取って報告するのではなく、必ず組み合わせで見ます。

代表的なペアと、そこから読み取れるパターンを表にまとめます。

この「ペア観測」の発想は、単独指標では捉えられない構造的な問題を可視化するために不可欠です。5 つの指標がそれぞれ独立に動くのではなく、互いに牽制し合う関係で観測することで、Goodhart の法則を実務レベルで無効化できます。

契約更新・単価交渉・追加発注に KPI をどう使うか

5 指標フレームを整えたところで、次は実際の意思決定シーンでの使い方です。発注者が迫られる 3 つの典型的な意思決定について、5 指標をどう活用するかをご紹介します。

契約更新会議で使う 3 ヶ月推移レポートの型

契約更新の判断では、5 指標の 3 ヶ月推移を並べて評価します。おすすめするレポート構成は次の通りです。

1. エグゼクティブサマリ（1 段落）: 「予測可能性は確立、価値実現指標は右肩上がり、品質指標も安定。契約継続が妥当と判断」等の結論を先出し
2. 5 指標推移グラフ: 各指標の 3 ヶ月分（12〜13 スプリント分）を折れ線で表示
3. ペア観測所見: ベロシティ × 品質、達成率 × 価値実現などのペアで異常兆候がないかコメント
4. リスクと対応: 何らかの警戒パターンが出ていた場合、その原因と対応策
5. 継続判断の推奨: 継続 / 条件付き継続 / 見直しのいずれかを、根拠とセットで提示

ここで注意すべきは、ベロシティ単独が高い/低いを判断材料にしないことです。「ベロシティは向上したが品質指標が悪化」の場合、契約継続は保留です。「ベロシティは変化なしだが価値実現指標が右肩上がり」の場合、継続妥当と判断できます。

単価妥当性を「価値 ÷ 費用」で見る

外注単価の妥当性を検証するときも、5 指標フレームが使えます。ただし単価そのものを「ベロシティ 1 ポイントあたりの費用」で計算するのは誤りです（ストーリーポイントは時間に換算できないため）。

代わりに次のように考えます。

• 算式: 1 スプリントあたりの「価値実現指標のスコア」÷ 1 スプリントの費用
• 相場感: 継続的にリリースされた機能のうち、実利用に至った割合と、それが売上・KPI にどう寄与したかを金額換算する
• 比較対象: 過去の別スプリント、または類似規模の内製プロジェクトとの比較

例として、月額 500 万円で 2 スプリント / 月のチームが、1 スプリントあたり平均 3 機能をリリースし、そのうち 2 機能が想定利用率を超えたとすれば、「1 スプリント 250 万円で価値の高い 2 機能が届いている」と評価できます。これを内製時のコストや、他のスクラム外部委託事例と比較することで、単価の妥当性が見えます。

ベロシティ数値を単価計算に使うと、水増しハックが単価妥当性の判断まで歪めてしまいます。必ず価値実現指標を主軸に据えることが重要です。

追加発注に耐えるチームかを見極める指標条件

既存チームに追加発注（メンバー増員・スコープ拡大）を検討する場合、そのチームが追加投資に耐えるかを判断する必要があります。判断基準は次の通りです。

• リードタイムが安定または短縮傾向: 現行フローが詰まっていない証拠。追加スコープを受け入れる余地がある
• 品質指標が悪化していない: 現行負荷でも品質を維持できている。増員後の品質崩壊リスクが低い
• コミットメント達成率が 80〜90% で安定: 計画立案が機能している。増員時の計画も信頼できる

逆に、リードタイムが長期化傾向、品質指標が悪化、達成率が変動大の場合は、追加発注ではなく現行チームの改善が先です。「ベロシティが高いから追加発注可能」と判断すると、増員後に問題が一気に噴出します。

発注者側の運用ルール——数字ハックを予防する 3 つの姿勢

5 指標フレームは道具にすぎません。発注者側の関与姿勢を誤ると、結局チームがハックを始めます。ここでは、指標を導入した後に守るべき 3 つの姿勢をお伝えします。

姿勢 1: 「数字で叱責しない」

もっとも重要なのが、指標の低下をチームへの叱責材料にしないことです。「今週ベロシティが 5 下がった、どうして」「品質指標が悪化した、責任者を出せ」といった問い方をした瞬間、チームは「次からは数字を守るための行動をとる」モードに入ります。それがハックの入り口です。

代わりに「今週ベロシティが下がった背景を教えてほしい」「品質指標の悪化はどこで発生したか、一緒に整理させてほしい」という問い方に変えます。指標は「対話の起点」であり、「評価の道具」ではありません。この姿勢の切り替えができるかどうかが、5 指標フレームが機能するか失敗するかの分水嶺です。

姿勢 2: 「複数指標を必ず同時に見る」

指標が 5 つあっても、報告の場で「今週のベロシティは...」と 1 指標ずつ読み上げる形にしてしまうと、結局単独 KPI 化と同じ罠に落ちます。必ず 5 指標を一枚のダッシュボードに並べ、ペア観測のパターンで議論します。

これは会議の設計にも影響します。「毎スプリントレビューで 5 指標を一括表示する」「契約更新会議では 3 ヶ月推移をペア観測でコメントする」といった運用ルールを、契約締結時に発注者側から提案しておくことが望ましいです。

姿勢 3: 「価値実現指標をチーム外で観測する」

5 指標のうち、指標 1〜4 はチーム内で観測できますが、指標 5（価値実現）はチーム外で観測する必要があります。ここをチーム自身に測らせると、無意識のバイアスや自己評価の甘さが混入します。

具体的には、機能利用ログの集計・分析は発注者側の分析部門が担当する、スプリントレビューの受入判定はステークホルダーが記録する、ユーザーインタビューは第三者が実施する、といった役割分担を作ります。「作ったもの」を測るのはチーム、「価値が生まれたか」を測るのは発注者、というシンプルな線引きです。

この 3 つの姿勢を守ることで、5 指標フレームは指標ハックへの耐性を持ちます。逆に、姿勢を守らずに指標だけを導入しても、数ヶ月で数字は美しくなり実質は悪化する、という結果になります。

まとめ——ベロシティは KPI ではなく「対話の起点」として使う

長い記事になりましたが、最後に本記事の要旨を整理します。

• ベロシティは単独 KPI にはならないが、5 指標フレームの一角として進捗の予測可能性を担う重要な指標である
• 経営説明は 5 指標の推移（ベロシティ・コミットメント達成率・リードタイム/デプロイ頻度・品質指標・価値実現指標）で行う
• 契約継続・単価妥当性・追加発注の判断は、価値実現指標を主軸に据える
• ペア観測の原則（ベロシティ × 品質、達成率 × 価値実現など）で数字ハックを防ぐ
• 発注者側の運用姿勢（数字で叱責しない・複数指標を同時に見る・価値実現指標をチーム外で観測する）が要

読者の方が明日から始められる第一歩は、現在受け取っているスプリントレポートに「価値実現指標」と「品質指標」の追加をチームに依頼することです。ベロシティとコミットメント達成率は既に多くの現場で計測されているはずなので、そこにこの 2 つが加わるだけで、5 指標フレームの原型ができあがります。

ベロシティを評価の道具ではなく、チームとの対話の起点として使い直す。この視点の転換が、感覚評価から抜け出し、経営説明に耐える多面評価フレームを持つための第一歩になります。次回の契約更新会議で「この 5 指標でこう推移しているので継続妥当」と、根拠付きで説明できる状態を目指してみてください。