フレームワーク活用ガイドひとことで言うと#
スプリントごとにチームが完了させたストーリーポイント（またはアイテム数）を計測し、その推移を分析することで、計画精度の向上と持続可能な開発ペースの維持を実現する管理手法。
押さえておきたい用語#
- ベロシティ（Velocity）
- 1スプリントでチームが完了させたストーリーポイントの合計値のこと。計画のための予測指標として使う。
- ストーリーポイント（Story Point）
- ユーザーストーリーの相対的な作業量・複雑さを表す単位のこと。時間ではなく相対値で見積もる。
- 完了の定義（Definition of Done）
- ストーリーが「完了」と見なされるための品質基準のチェックリストのこと。ベロシティの計測基準になる。
- サステナブルペース（Sustainable Pace）
- チームが長期間にわたって維持できる安定した開発速度のこと。短期的な無理は長期的なベロシティ低下を招く。
チームベロシティ管理の全体像#
こんな悩みに効く#
- 毎スプリント、計画した量が終わらない
- チームの生産性が上がっているのか下がっているのか分からない
- マネジメントから「もっと速く」と言われるが、根拠を持って反論できない
基本の使い方#
スプリント終了時に、完了したアイテムのストーリーポイントの合計を記録する。
- 「完了」は「完了の定義（DoD）」を満たしたもののみカウントする
- 途中まで進んだアイテムはカウントしない（0か100か）
- スプリントごとの数値を時系列で記録する
ポイント: 「着手した」ではなく「完了した」ポイントだけを数える。これが鉄則。
直近5〜8スプリントのデータからトレンドを読む。
- 平均ベロシティを算出する（計画の基準値として使用）
- ばらつき（標準偏差）を確認する。ばらつきが大きい場合は原因を調査する
- 上昇・下降・安定のどのトレンドにあるかを判断する
ポイント: 単一スプリントの数値に一喜一憂しない。トレンドで判断する。
平均ベロシティを基準に、次のスプリントの取り込み量を決める。
- 平均ベロシティの80〜100%を目安に計画する
- チームの状況（休暇、新メンバー加入、技術的不確実性）に応じて調整する
- リリース計画では、ベロシティを使って「あと何スプリントで完了するか」を予測する
ポイント: ベロシティは「目標」ではなく「実績に基づく予測値」。無理に上げようとしない。
ベロシティが不安定な場合、その原因を特定して改善する。
- 割り込みタスクの頻度を記録し、削減策を講じる
- ストーリーポイントの見積もり精度を振り返る
- 技術的負債やテスト不足がベロシティを下げていないか確認する
ポイント: ベロシティの改善は「速く作る」ことではなく「安定して完了できる環境を整える」こと。
具体例#
背景: ECサイト開発チーム5名（エンジニア3名、QA1名、デザイナー1名）。2週間スプリント。立ち上げ当初はベロシティが不安定。
直近8スプリントのベロシティ推移:
| Sprint | ベロシティ | 備考 |
|---|---|---|
| S1 | 24pt | 初スプリント、見積もりに慣れず |
| S2 | 28pt | |
| S3 | 18pt | メンバー1名病欠 |
| S4 | 30pt | |
| S5 | 26pt | 緊急バグ対応で割り込み |
| S6 | 32pt | |
| S7 | 29pt | |
| S8 | 31pt |
分析結果:
- 全体平均ベロシティ: 27.3pt
- S3を外れ値として除外した平均: 28.6pt
- S5以降（割り込み対策後）の平均: 29.5pt
- ばらつき（標準偏差）: S5以降は2.6pt（安定）
リリース計画への活用:
- 残りのバックログ: 120pt
- ベロシティ28pt/スプリントで計算: 約4.3スプリント（9週間）
- バッファ込みで10〜11週間でリリース可能と予測
結果: 実際のリリースは10週間目。予測誤差は+1週間。S5で割り込みタスク専用のバッファ（全体の15%）を設けたことでS6以降のベロシティが安定し、予測精度が大幅に向上した。
背景: 法人向けSaaSの開発チーム8名。マネジメントが「ベロシティ30pt/スプリント以上」をKPIに設定。
失敗期（S1〜S6）のベロシティ推移:
| Sprint | 計画 | 実績 | 見積もり精度 |
|---|---|---|---|
| S1 | 30pt | 32pt | 適正 |
| S2 | 35pt | 36pt | ポイントインフレ開始 |
| S3 | 38pt | 40pt | 3ptタスクを5ptに水増し |
| S4 | 42pt | 38pt | バグ急増で完了できず |
| S5 | 42pt | 35pt | 技術的負債が顕在化 |
| S6 | 40pt | 28pt | 品質問題でリリース延期 |
回復策（S7以降）:
- ベロシティをKPIから外し、「計画の基準値」に戻した
- プランニングポーカーの基準ストーリーを再設定
- 技術的負債返済に毎スプリント20%のキャパシティを確保
- ベロシティの代わりに「リリース頻度」と「本番障害件数」をKPIに設定
回復後（S7〜S12）の平均ベロシティ: 26pt（安定、標準偏差2.1pt）
結果: 数字上のベロシティは下がったが、本番障害件数が月平均4.2件から0.8件に減少。リリース頻度は月1回から月2回に向上。ベロシティを「評価」に使うと見積もりが歪み、結果として品質も生産性も下がることを学んだ。
背景: 人口5万人の地方自治体がDX推進のため内製チームを新設。メンバー4名（うち開発経験者1名）。住民向けゴミ分別アプリを開発。
導入プロセス:
- まずアイテム数（完了ストーリー数）でベロシティを計測開始
- S3からストーリーポイント（フィボナッチ数列）に移行
- S5からプランニングポーカーを導入
ベロシティ推移:
| Sprint | ベロシティ | 計画 | 計画達成率 |
|---|---|---|---|
| S1 | 3件 | - | -（計測のみ） |
| S2 | 4件 | - | -（計測のみ） |
| S3 | 15pt | 20pt | 75% |
| S4 | 18pt | 18pt | 100% |
| S5 | 16pt | 18pt | 89% |
| S6 | 19pt | 17pt | 112% |
| S7 | 18pt | 18pt | 100% |
| S8 | 20pt | 19pt | 105% |
分析: S5以降の平均ベロシティは18.3pt。計画達成率がS4以降90%超で安定。
結果: 8スプリント（16週間）でアプリを市民向けリリース。ダウンロード数は想定の1.4倍。開発未経験者3名のチームでも、ベロシティを「自分たちの実力値を知るツール」として使うことで、現実的な計画を立てられるようになった。
やりがちな失敗パターン#
- ベロシティをチーム間で比較する — ストーリーポイントの基準はチームごとに異なる。チームAの30ptとチームBの30ptは同じ作業量ではない。ベロシティはチーム内の時系列比較にのみ使える
- ベロシティをKPIにして「上げろ」と要求する — ベロシティを目標にすると、ポイントのインフレ（水増し）が起きる。ベロシティは計画のための指標であって、評価指標ではない
- データが少ない段階で予測する — 2〜3スプリントのデータでリリース日を確約すると危険。最低5スプリントのデータが溜まるまでは予測にレンジ幅を大きく取る
- ベロシティ低下を「怠慢」と決めつける — ベロシティが下がったとき、チームの努力不足と断定するのは危険。技術的負債、要件の複雑化、割り込みタスクの増加など環境要因を先に調査する
まとめ#
チームベロシティ管理は、アジャイル開発における計画精度と予測可能性を高める基本的な手法。計測→分析→計画活用→改善のサイクルを回すことで、チームは持続可能なペースで安定した成果を出せるようになる。最大の注意点は「ベロシティを評価指標にしない」こと。あくまで「実績に基づく計画ツール」として正しく使おう。