ベロシティの測定と運用｜スクラムチームの生産性を数値で把握して計画精度を上げる

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

ベロシティが計画の精度を下げる根本原因は、「ベロシティを個人の生産性の尺度として使ってしまうこと」にあります。 結論から言えば、ベロシティはチームが1スプリントで完了できる作業量を表す指標であり、個人の評価ツールでも、チーム間の比較指標でもありません。ベロシティの本来の目的は「このチームはこのペースで動いている」という事実を積み上げ、次のスプリントで引き受けられる量を予測することです。本記事では、AtlassianやAsanaの解説をもとに、ベロシティの測定方法・安定化プロセス・スプリント計画への活用・外部要因の影響対応を整理します。

ベロシティとは

ベロシティ（Velocity）とは、スクラムチームが1スプリントで完了したストーリーポイントの合計値です。たとえばあるスプリントで5本のバックログアイテムが完了し、それぞれのストーリーポイントが3・5・3・8・5であれば、そのスプリントのベロシティは 24 SP になります。

Atlassian はベロシティを「チームがスプリントごとにどれだけの作業を完了できるかを測定する指標」と定義しており、Agile Alliance は「各スプリント終了時に完全に完了したユーザーストーリーの見積もり合計」と定義しています、スプリント計画・リリース計画の根拠として使われます。

ベロシティが必要な理由

スクラムではスプリント計画の場で「次のスプリントで何を引き受けるか」を決めます。このとき根拠がなければプロダクトバックログから感覚でアイテムを選ぶことになり、スプリント後半に「やっぱり無理だった」という事態が繰り返されます。ベロシティはこの問題を「過去の実績に基づいた見積もり」で解決します。

ベロシティの用途	内容
スプリント計画の根拠	直近スプリントの平均ベロシティ = 次スプリントで引き受ける上限の目安
リリース計画	残り総SP ÷ 平均ベロシティ = 完了に必要なスプリント数
変化の検知	ベロシティが急落したらチームへの阻害要因がある可能性

---

ベロシティの測定方法

ベロシティの測定は、スプリントが終わるたびに行います。計算式はシンプルです。

スプリントベロシティ = そのスプリントで完了したアイテムのSP合計

ここで重要なのは 「完了」の定義を事前に決めておくことです。スクラムでは完成の定義（Definition of Done / DoD）をチームで合意し、DoDを満たしていないアイテムはたとえ90%完成していても「未完了」として扱います。途中で止まったアイテムのSPはベロシティに含めません。

測定するタイミング

ベロシティの記録はスプリントレビューの直後が最適です。スプリントレビューでステークホルダーと成果物を確認したその場で、完了SPを集計してチームのツール（Jira・Backlog・スプレッドシートなど）に記録します。

ベロシティの推移を追う：ベロシティチャート

複数スプリントのベロシティを棒グラフで並べたものがベロシティチャートです。JiraなどのアジャイルPMツールは自動でこのグラフを生成しますが、Excelでも縦軸=SP数・横軸=スプリント番号のシンプルな棒グラフで十分です。

スプリント	計画SP	完了SP（ベロシティ）
Sprint 1	30	22
Sprint 2	25	24
Sprint 3	25	27
Sprint 4	28	25
Sprint 5	26	26

上の例では初回スプリント（Sprint 1）のベロシティが低く、以降安定してきています。これは典型的なパターンで、チームが新環境・新メンバー構成に慣れていくにつれてベロシティが収束していきます。

---

ベロシティが安定するまでの期間

ベロシティは導入直後から安定するわけではありません。Atlassian によれば、一般的に 3〜5スプリント（6〜10週間） を経て安定する傾向があります。

安定化しない初期の主な原因

原因	説明
ストーリーポイントの基準が定まっていない	チーム内でSPの「1」「3」「5」が何を意味するか合意できていない
チームの完成の定義（DoD）が揺れている	DoDが曖昧で、完了の判断がスプリントごとにバラつく
スプリント後半にスコープが変わる	スプリント中に割り込みや要件変更が入り計画が乱れる
新チーム・新メンバーの習熟不足	初期はコミュニケーションコストや学習コストが乗る

安定化を早める3つの工夫

① バックログリファインメントを毎スプリント実施する スプリント前にプロダクトバックログのアイテムを精査・見積もっておくことで、プランニングの精度が上がります。詳細は「スクラムの5つのイベント」を参照ください。

② 基準アイテムを1つ定めて固定する 「このアイテムは3 SP」という基準ストーリーをチームで1つ決めておき、新しいアイテムを見積もる際の比較基準にします。時間が経ってもこの基準アイテムのSPを変えないことが重要です。

③ スプリントレトロスペクティブで振り返る ベロシティが計画より大幅に低かった場合、その理由をスプリントレトロスペクティブで掘り下げます。「阻害要因が何だったか」を明確にしないまま次のスプリントに進むとベロシティが安定しません。

---

スプリント計画へのベロシティ活用

ベロシティが安定してきたら、スプリント計画に実績値を使います。Asana は「直近3〜5スプリントの平均ベロシティを次スプリントの引き受け上限の目安にする」ことを推奨しています。

平均ベロシティの使い方

次スプリントの引き受け目安 ≈ 直近3スプリントの平均ベロシティ

例：直近3スプリントのベロシティが 24、26、25 であれば、平均は 25 SP。次のスプリントプランニングでは、プロダクトバックログの上位アイテムから合計SPが約25になるよう選定します。

なぜ「直近3スプリント平均」か

• 直近のデータほど現状を反映している：チーム構成や技術的文脈は変化するため、古い実績は参考にならなくなる
• 1スプリントの単点では変動が大きい：祝日・チームメンバーの休暇・突発的なバグ対応などで1スプリントだけ大きく下がることがある
• 5スプリント以上は古すぎる可能性：半年前のベロシティが現在の状況を反映しているとは限らない

リリース計画への活用

ベロシティが安定すれば、「あとどれくらいで完成するか」のリリース計画にも使えます。

必要スプリント数 = プロダクトバックログ残り総SP ÷ 平均ベロシティ

例：残り総SP = 200 SP、平均ベロシティ = 25 SP の場合、完了まで 8スプリント（約16週間）。

残り総SP	平均ベロシティ	必要スプリント数（2週間/Sprint）	完了見込み期間
100	25	4	約2ヶ月
200	25	8	約4ヶ月
300	20	15	約7.5ヶ月

ただしこれはあくまで目安です。バックログへのアイテム追加・スコープ変更・チーム変動があれば見込みは変わります。リリース計画はバッファを持って提示し、四半期ごとに更新する運用が現実的です。

---

外部要因がベロシティに与える影響

スクラムチームのベロシティは固定値ではなく、さまざまな外部要因によって変動します。主な要因と対処法を整理します。

1. 祝日・長期休暇

スプリントに祝日が含まれるとチームの稼働日数が減り、ベロシティは下がります。

対処法： 祝日が入るスプリントでは、引き受けSPをあらかじめ少なく見積もります。具体的には「祝日1日ごとに稼働日の20〜25%分のSPを引く」方法が一般的です。スプリント計画の際に「このスプリントは実質8稼働日」と明示するだけで計画精度が改善します。

2. チームメンバーの変動

新メンバーの参画・既存メンバーの異動・チームの分割・合併はベロシティを大きく変動させます。Promapedia は「チーム構成が変わったらベロシティをリセットして再計測する」ことを推奨しています。

注意すべきは「人を追加したからベロシティが即座に上がる」ではないこと。新メンバーは習熟に時間がかかり、既存メンバーのオンボーディング支援コストも乗るため、参画後2〜3スプリントはベロシティが一時的に下がることがあります。

3. 技術的負債・バグ対応の割り込み

計画外のバグ修正や緊急の技術的負債対応が入るとスプリントゴールが圧迫されます。

対処法： 「バッファSP」として計画SPの10〜20%を毎スプリント予備として確保する方法があります。あるいは「割り込みキャパシティ」としてスプリントバックログの枠を最初から割り込み対応用に空けておく運用も有効です。

4. チームの集中力・モチベーション

心理的安全性の低下・長期間の高負荷・チーム内の対立はベロシティに表れます。ベロシティが数スプリント連続で下がっているときは単純な見積もり精度の問題ではなく、チームの状態に問題が生じているサインかもしれません。

5. スプリント期間の変更

スプリント期間を2週間から1週間に変えるといった変更もベロシティを変動させます。当然、期間が半分になれば1スプリントあたりのベロシティも約半分になります。スプリント期間を変更する場合は、リリース計画の計算式も合わせて見直す必要があります。

---

ベロシティに関するよくある失敗5選

❌ 失敗1：ベロシティで個人の生産性を評価する

「AさんはBさんより多くのSPをこなした」という比較はベロシティの誤用です。Atlassian は「ベロシティはチームの指標であり、個人の生産性を測るものではない」と明言しており、Agile Alliance も「個人ベロシティは意味がなく、チームの集計値だけが意味を持つ」と述べています。個人ベロシティを可視化するとチームメンバーが「SPを多く取れるアイテムだけを選ぶ」インセンティブが生まれ、協働が壊れます。

❌ 失敗2：チーム間でベロシティを比較する

「Aチームはベロシティ40、Bチームは25だからBチームは生産性が低い」という比較は意味がありません。ストーリーポイントはチーム固有の相対尺度であり、チームが異なれば「1 SP」の意味が異なります。ベロシティは同一チームの時系列の変化を見るためのものです。

❌ 失敗3：ベロシティ目標を設定する

「今期のベロシティ目標は30 SP」という設定は逆効果です。ベロシティ目標を設けるとチームは数字を達成するためにDoDを甘くしたり、小さいアイテムを優先的に選んだりするようになり、本来のバックログ優先順位に従った開発ができなくなります。

❌ 失敗4：部分完了アイテムのSPをカウントする

スプリント終盤に「あと少しで終わりそうだから0.8SPとしてカウントしよう」と計算するのは正確なベロシティ計測を妨げます。完了/未完了の二値判定を徹底し、未完了アイテムは次スプリントに持ち越します。

❌ 失敗5：ベロシティだけでスプリント計画を決める

ベロシティはスプリントで引き受けられる「目安」であり、すべてではありません。スプリントの実態（祝日・チームメンバーの休暇・技術難度の高いアイテムの集中など）を加味して調整することが重要です。「ベロシティが25だから機械的に25 SP引き受ける」という硬直した運用は避けましょう。

---

ベロシティのメリット・デメリット

---

FAQ

Q1. ベロシティはどのツールで管理すればよいですか？

Jira・Backlog などのアジャイルPMツールはスプリントが終わるたびに自動でベロシティを集計し、グラフ表示します。ツールがない場合はGoogleスプレッドシートで「スプリント番号・計画SP・完了SP」の3列を管理するだけで十分です。

Q2. ベロシティは何スプリント分の平均を使うべきですか？

一般的には直近3〜5スプリントの平均が推奨されます。3スプリント未満は変動が大きすぎ、5スプリント超は古い実績が混ざりすぎます。チーム構成や技術スタックが安定しているなら直近3スプリントで十分です。

Q3. カンバンはベロシティを使いますか？

カンバンはスプリントという固定期間を持たないため、ベロシティの概念はそのまま適用できません。代わりにスループット（一定期間あたりの完了アイテム数）やリードタイム（着手から完了までの時間）を計画の根拠に使います。

Q4. ベロシティが毎スプリント大きくぶれます。どうすれば安定しますか？

まず変動の原因を特定します。①スプリント中の割り込みが多い場合はバッファSPの確保、②ストーリーポイントの見積もりがブレる場合は基準アイテムの固定と見積もりミーティングの改善、③チームメンバーの変動が多い場合は構成の安定化を優先します。スプリントレトロスペクティブでこれらを議題にしましょう。

Q5. ベロシティを上司やクライアントに報告する必要はありますか？

ベロシティは本来チーム内部の計画ツールです。外部への報告に使う場合は、「前スプリントより〇SP多く完了した」ではなく、「残りのバックログを完了するのにあと〇スプリント（約〇週間）の見込み」というリリース見込みとして伝えると誤解が少なくなります。ベロシティの数字そのものを公開するとチーム間比較や個人評価に使われるリスクがあります。

---

まとめ

ベロシティは、スクラムチームが1スプリントで完了したストーリーポイントの合計であり、次のスプリント計画とリリース計画の根拠になります。測定のポイントは以下のとおりです。

ポイント	内容
計測タイミング	スプリントレビュー直後に完了SPを集計
完了の定義	DoDを満たしたものだけカウント（部分完了は0）
安定化期間	一般的に3〜5スプリント（6〜10週間）
計画への使い方	直近3〜5スプリントの平均を次スプリントの引き受け上限の目安に
外部要因への対処	祝日・メンバー変動はあらかじめSPを調整して吸収
やってはいけないこと	個人評価・チーム比較・ベロシティ目標の設定

ベロシティは「チームが今どのペースで動いているか」を映す鏡です。その数字を上げることが目的ではなく、実績に基づいた現実的なコミットを繰り返すことで、チームとステークホルダーの信頼関係を積み上げることが本来の目的です。

ベロシティに慣れてきたら、ストーリーポイントとプランニングポーカーの精度を上げる方法や、スプリント計画の進め方も合わせて参照してください。