フレームワーク活用ガイドひとことで言うと#
各スプリントで「完了」したストーリーポイントの合計値（ベロシティ）を記録し続けることで、チームがどれくらいの作業をこなせるかを把握し、将来の計画に活かす手法。
押さえておきたい用語#
- ベロシティ（Velocity）
- 1スプリントで完了したストーリーポイントの合計値のこと。チームの「実績に基づく作業量の目安」として使う。
- バーンダウンチャート（Burndown Chart）
- スプリント内の残作業量の推移をグラフ化したもののこと。ベロシティが「スプリント間」の指標であるのに対し、バーンダウンは「スプリント内」の指標。
- レンジ予測（Range Forecast）
- 楽観値・基本値・悲観値の3パターンでリリース時期を予測する手法のこと。単一の数値よりも信頼性が高い。
- ポイントインフレ（Point Inflation）
- ベロシティを上げるために見積もりポイントを意図的に大きくする現象のこと。ベロシティをKPIにすると発生しやすい。
ベロシティトラッキングの全体像#
こんな悩みに効く#
- スプリントで毎回、計画した量を終わらせられない
- 「この機能はいつ完成しますか？」と聞かれても答えられない
- チームの生産性が上がっているのか下がっているのかわからない
基本の使い方#
各スプリントの終わりに、「完了の定義」を満たしたアイテムのポイント合計を記録する。
- 未完了のアイテムはカウントしない（部分完了も含めない）
- スプリントレビューで「完了」と認められたものだけが対象
- スプレッドシートやツール（Jira等）で記録を蓄積する
ポイント: 中途半端なものをカウントしないのが鉄則。完了したものだけをカウントする。
棒グラフでスプリントごとのベロシティを並べて表示する。
- 横軸にスプリント番号、縦軸にストーリーポイントを取る
- 直近3〜5スプリントの平均値を計算する
- 上下のブレ幅（レンジ）も把握する
ポイント: 1回のスプリントの値で判断しない。3〜5スプリントのトレンドで見ることが大事。
平均ベロシティを基準に、次のスプリントで取り込む量を決める。
- 直近3スプリントの平均ベロシティが30ptなら、次も30pt前後を目安にする
- 新メンバー加入や休暇などの変動要因は加味して調整する
- 慣れるまでは平均の80%程度に抑えるのが安全
ポイント: ベロシティは「目標」ではなく「実績に基づく予測」。無理に上げようとしない。
残りのバックログのポイント合計を平均ベロシティで割り、リリース時期を予測する。
- 残バックログ: 120pt、平均ベロシティ: 30pt/スプリント → 約4スプリント（8週間）
- 楽観値（最大ベロシティ）と悲観値（最小ベロシティ）でレンジも出す
- バックログの追加を見込んで、バッファを加えるとより現実的
ポイント: レンジで伝えるのがコツ。「6〜10週間で完了見込み」のように幅を持たせる。
具体例#
背景: BtoC Webサービス開発チーム6名。2週間スプリント。残バックログ90ptのリリース時期をステークホルダーに報告したい。
ベロシティ推移:
| Sprint | ベロシティ | 備考 |
|---|---|---|
| S1 | 22pt | 初スプリント |
| S2 | 28pt | |
| S3 | 25pt | |
| S4 | 30pt | |
| S5 | 27pt | メンバー1名が半日研修 |
| S6 | 32pt |
分析:
- 全体平均: 27.3pt/スプリント
- 直近3スプリント平均: (30+27+32) ÷ 3 = 29.7pt
- 最大値: 32pt、最小値: 22pt
リリース予測（残バックログ90pt）:
| シナリオ | ベロシティ | 必要スプリント数 | 期間 |
|---|---|---|---|
| 楽観 | 32pt | 2.8S | 6週間 |
| 基本 | 30pt | 3.0S | 6週間 |
| 悲観 | 25pt | 3.6S | 8週間 |
報告: 「6〜8週間でリリース可能な見込みです。バックログの追加がなければ、7週間を中心に見ています」
結果: 実際のリリースは6.5週間目。レンジ予測の範囲内に収まり、ステークホルダーの信頼を獲得。「○週間で完了します」ではなく「6〜8週間の見込み」とレンジで伝えたことで、期待値を適切にコントロールできた。
背景: 法人向けSaaSの開発チーム10名。2週間スプリント。S8からベロシティが急低下し、原因を調査。
ベロシティ推移:
| Sprint | ベロシティ | 計画 | 計画達成率 |
|---|---|---|---|
| S5 | 45pt | 45pt | 100% |
| S6 | 48pt | 45pt | 107% |
| S7 | 44pt | 46pt | 96% |
| S8 | 32pt | 46pt | 70% |
| S9 | 28pt | 40pt | 70% |
| S10 | 30pt | 35pt | 86% |
原因分析:
- S8から新機能の技術スタックが変更（React→Next.js移行）
- 学習コストがベロシティに反映されていなかった
- S8〜S9で割り込みバグ対応が合計18時間発生
- DoDを厳格化（セキュリティレビュー追加）がS7から適用
対応策:
- 技術移行期は平均ベロシティの70%で計画する方針に変更
- 割り込みバグ対応のバッファとして全体の15%を確保
- DoD変更後のベロシティを「新しいベースライン」として再設定
結果: S11以降のベロシティは33〜36ptで安定。新ベースライン34ptで計画したS12〜S14の計画達成率は95%以上に回復。ベロシティの低下を「問題」ではなく「環境変化の反映」と正しく捉え、計画を再調整したことが回復の鍵だった。
背景: 人口6万人の自治体がDX推進チーム5名（うちエンジニア2名）を新設。住民向け申請ポータルを開発。アジャイル開発は初体験。
導入ステップ:
- 最初の2スプリントはストーリーポイントを使わず、完了アイテム数で計測
- S3からフィボナッチ数列（1,2,3,5,8,13）で見積もり開始
- S5からJiraでベロシティチャートを自動生成
ベロシティ推移:
| Sprint | ベロシティ | 見積もり精度 |
|---|---|---|
| S1 | 4件 | -（件数のみ） |
| S2 | 5件 | -（件数のみ） |
| S3 | 12pt | 見積もりに慣れず |
| S4 | 18pt | 基準ストーリー設定後 |
| S5 | 16pt | GW休暇で稼働減 |
| S6 | 20pt | |
| S7 | 19pt | |
| S8 | 21pt |
平均ベロシティ（S4以降）: 18.8pt/スプリント
リリース予測: 残バックログ75pt → 75 ÷ 18.8 = 約4スプリント（8週間）。悲観値（16pt）で約4.7スプリント（10週間）。
結果: 実際のリリースは9週間目。予測レンジの範囲内。住民向けポータルの利用登録率は初月で世帯の23%を達成。アジャイル未経験のチームでも、ベロシティを「自分たちのペースを知る道具」として素直に使ったことで、無理のないスケジュール管理ができた。
やりがちな失敗パターン#
- ベロシティをKPIにする — ベロシティを「チームの成績」として扱い、上げることを目標にすると、見積もりのインフレ（簡単な作業に高ポイントをつける）が起きる。ベロシティは計画ツールであり、評価ツールではない
- チーム間で比較する — ベロシティの単位はチームごとに異なる。Aチームの30ptとBチームの30ptは同じ量の仕事ではない。チーム間比較は無意味であり有害
- 最初のスプリントから信用する — ベロシティが安定するには3〜5スプリントかかる。初期のデータはノイズが多いことを前提にする
- 環境変化を考慮しない — メンバーの増減、技術変更、DoDの変更などがベロシティに影響する。変化があったらベースラインを再設定する
まとめ#
ベロシティトラッキングは、チームの「実力値」を客観的に把握し、計画とリリース予測に活用する手法。ベロシティは目標でも評価指標でもなく、「実績に基づく計画ツール」として使うのが正解。3〜5スプリントのデータが溜まれば、精度の高いスプリント計画とリリース見通しが立てられるようになる。レンジで予測を伝えることで、ステークホルダーとの信頼関係も築ける。