アジャイルにおけるベロシティとは:チームのスループットを測定する方法

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
アジャイルのベロシティは、Scrumチームが追跡できる最も実践的な数値の1つです。チームが1スプリントで実際にどれだけの作業を平均的に完了させているかを教えてくれるもので、これはあらゆる誠実なリリース予測やキャパシティ計画の土台になります。
多くのチームは、アジャイルの旅の早い段階でベロシティについて耳にし、それを人事評価のスコアとして誤用してしまい、なぜそれが明確さではなくプレッシャーを生むのかと疑問に思います。本ガイドでは、ベロシティとは何か、正しい計算方法、そして数字を操作することなく予測ツールとして活用する方法を解説します。
アジャイルにおけるベロシティとは
アジャイルのベロシティとは、チームが1スプリントで完了させるストーリーポイントの平均数のことです。直近の複数スプリントで完了した合計ポイントを、そのスプリント数で割ることで算出します。
これがすべての定義です。ベロシティは品質、スピード、効率、努力の量を測るものではありません。決まった期間内に完了したスループットのみを測定します。
キーワードは「完了した」という点です。スプリントが終わる前に着手されたものの完了しなかったストーリーポイントは、ベロシティにはカウントされません。部分点は存在しません。この厳密さこそが、ベロシティを信頼できる予測用の入力値にしています。チームの平均ベロシティが42ポイントであれば、その数字は試みたことではなく実際に出荷されたことを反映しているため、妥当な自信を持って将来のスプリントを予測できます。
重要ポイント
- 少なくとも6スプリント分ベロシティを追跡しているチームは、勘だけで見積もるチームよりも40%正確なリリース日予測を出しています(Scrum Alliance State of Scrum、2023年)。
- 平均的なScrumチームのベロシティは1スプリントあたり20〜60ストーリーポイントの範囲ですが、数字そのものよりも時間を通じた安定性の方が重要です(VersionOne State of Agile、2023年)。
- アジャイルチームのおよそ60%が、ベロシティを主要なキャパシティ計画指標として使っていると報告しており、Scrumにおいて最も広く採用されているスループット指標となっています(Digital.ai State of Agile Report、2023年)。
ベロシティの計算方法
計算式は単純です。
ベロシティ=完了した合計ストーリーポイント÷測定対象のスプリント数
移動平均には直近3〜5スプリントを使いましょう。3スプリント未満ではノイズの多い像になり、7スプリントを超えるとチーム構成や見積もりの習慣が異なっていた時期のデータまで混ざり始めます。
2週間スプリントを実施しているチームの計算例を見てみましょう。
| スプリント | コミットしたポイント | 完了したポイント |
|---|---|---|
| スプリント1 | 48 | 42 |
| スプリント2 | 45 | 44 |
| スプリント3 | 50 | 39 |
| スプリント4 | 46 | 45 |
移動平均ベロシティ(4スプリント): (42 + 44 + 39 + 45) / 4 = 42.5ポイント
このチームの実働ベロシティはおよそ1スプリントあたり42ポイントです。この計算においてコミットした数字自体は関係がないことに注目してください。重要なのは、スプリントが終わる前に「完了」ラインを越えたものです。スプリント3の数字が低く見える場合は、それを軽視したり水増ししたりするのではなく、原因(スコープ変更か、スプリント途中のブロッカーか、休暇か)を調べましょう。
ベロシティを予測に使う方法
安定したベロシティが手に入ったら、あらゆるステークホルダーが最終的に尋ねてくる「これはいつ完了しますか」という問いに答えられるようになります。
やり方はシンプルです。残っているバックログ(あるいは特定のリリースに対応するバックログの一部)のストーリーポイントを合計し、それを平均ベロシティで割ります。
完了までのスプリント数=残りのバックログのポイント÷平均ベロシティ
例えば、チームのリリースバックログに210ポイント残っていて、ベロシティが42だとします。これは5スプリント、2週間サイクルであれば10週間に相当します。それがあなたの予測です。
実務でこれをより有用にするいくつかの工夫があります。
- 単一の見積もりではなく範囲を使う。 直近のスプリント結果の最低値と最高値を当てはめて信頼区間を出しましょう。「ちょうど5スプリント」よりも「4.5〜6スプリントの間」の方が誠実です。
- スプリントごとに再予測する。 チームが作業を完了させたり、新しい項目を追加したり、スコープを削ったりするたびに予測は変わります。契約書としてではなく、生きた数字として扱いましょう。
- ベロシティをバックログリファインメントの習慣に結び付ける。 ベロシティの予測は、バックログのサイズと順序を整えるスプリントプランニングの質次第でしか良くなりません。見積もりがずれたり、バックログが陳腐化したりすると、ベロシティは予測力を失います。
- ロードマップのマイルストーンに結び付ける。 ロードマップである機能をQ3にリリースするとされている場合、締め切りから逆算して残りスプリント数を確認し、ベロシティを掛け合わせ、残りのスコープが収まるかどうかを確認しましょう。収まらない場合、締め切り当日ではなく早い段階でスコープやタイムラインについての会話をする必要があります。
この予測手法はプランニングポーカーとも相性が良く、チーム全体でストーリーポイントの見積もりの精度を保つことで、ベロシティが長期的に意味を持ち続けるようにしてくれます。
ベロシティが「ではないもの」
ここでほとんどのチームが誤解します。
ベロシティは生産性指標ではありません。 ベロシティが60のチームは、ベロシティが30のチームより「優れている」わけではありません。ストーリーポイントは各チーム独自のスケールに対して相対的なものです。あるチームはある機能を8ポイントと見積もり、別のチームは同じ機能を3ポイントと見積もるかもしれません。共通の単位は存在しません。チーム間でベロシティを比較することには意味がありません。
ベロシティは引き上げるべき目標ではありません。 マネージャーが「ベロシティを20%改善する」を目標に設定すると、チームは決まって1つのことをします。ストーリーポイントの見積もりを水増しするのです。数字は上がりますが、実際のアウトプットは変わりません。単に見積もりシステムの精度を損なっただけです。
ベロシティは個人の成果を測るものではありません。 ベロシティはチームに帰属するものであり、特定の1人に帰属するものではありません。これを個人の評価に使うと、誤ったインセンティブが生まれ、指標を正確なものにしている協働的な見積もりが崩れます。
ベロシティはコミットメントではありません。 ステークホルダーはときに、ベロシティを下限のように扱うことがあります。「前のスプリントで44ポイントできたのだから、今回も少なくとも44はコミットしているはずだ」というように。しかしそれは違います。ベロシティは計画のために使う過去の平均値であり、最低限のスループットを義務付けるものではありません。
ベロシティに影響する要因
ベロシティは時間とともに変化し、その変化の多くには明確な原因があります。何がばらつきを生んでいるかを知ることで、数字にただ反応するのではなく、解釈できるようになります。
チーム構成の変化。 新しいメンバーが加わると、立ち上がりの期間として通常2〜3スプリントほどベロシティが下がります。メンバーが離脱すると、その影響は即座に現れます。どちらの変化も、チームが失敗していることを意味しません。
休暇と休日。 祝日をまたぐスプリントや、複数人が休暇を取っているスプリントは、ベロシティが低くなります。これに応じてスプリントのキャパシティを調整するチームもあれば、平均値を見直す際に単に記録として残すチームもあります。
スプリント途中のスコープ変更。 予定外の作業を取り込んだり、スプリントの途中でストーリーを入れ替えたりすると、計画した内容と完了した内容との関係が崩れます。これがWIP制限が重要な理由の1つです。仕掛り作業に上限を設けることで、スプリントを途中の割り込みから守れます。
見積もりのドリフト。 数か月の間に、チームは無意識のうちに作業の見積もり方を変えてしまうことがあります。1か月目の「5ポイントのストーリー」が、チームが同種の作業に慣れるにつれて、6か月目には「3ポイントのストーリー」のように感じられるかもしれません。チーム規模やツールに変化がないのにベロシティが着実に上昇傾向にある場合は、チームが本当に速くなったと決めつける前に、見積もりがドリフトしていないか確認しましょう。
技術的負債と環境上の摩擦。 CIパイプラインの遅さ、頻発する本番障害、コード品質の問題は、バックログには表れないままスプリントのキャパシティを消費します。大きな技術的負債を抱えているチームは、本来のキャパシティから期待されるよりも低く、かつばらつきの大きいベロシティになりがちです。
ベロシティ対その他のフロー指標
ベロシティはスプリントレベルの指標です。決まった時間枠におけるスループットを教えてくれます。しかし、システム内を作業がどう流れているかのすべてを教えてくれるわけではありません。
| 指標 | 測定するもの | 最適な用途 |
|---|---|---|
| ベロシティ | スプリントごとに完了したストーリーポイント | リリース予測、スプリントキャパシティ |
| 累積フロー図 | 時間経過に伴うワークフロー各段階の作業項目数 | ボトルネックの発見、WIPの増加、フローの安定性 |
| WIP制限 | ある段階における同時進行の項目の上限 | スループットの最適化、コンテキストスイッチの削減 |
| サイクルタイム | 項目ごとの開始から完了までの時間 | 項目レベルでの予測可能性 |
| バーンダウンチャート | スプリントまたはリリース内の残作業 | リアルタイムのスプリントの健全性 |
ベロシティと累積フロー図は補完関係にあります。ベロシティはスプリントレベルの予測数値を与えてくれ、CFDはそのワークフローがそれを持続できるほど健全かどうかを示してくれます。ベロシティは良好でもCFDが不安定な(WIP帯が拡大している、帯の交差が頻発している)チームは、ベロシティ低下に向かっている可能性があります。
ベロシティを改善(安定化)する方法
目標はベロシティを最大化することではありません。ベロシティを予測可能にし、予測を信頼できるものにすることです。以下がその方法です。
一貫したスプリントを運用する。 スプリントの長さが変動する(1週間と2週間を切り替える)と、ベロシティのデータを比較できなくなります。1つのサイクルを選び、結論を出す前に少なくとも6スプリントはそれを維持しましょう。
ストーリーをクローズする前に完了の定義を満たす。 チームの完了の定義があいまいだと、ストーリーは異なる品質レベルで完了ラインを越えてしまい、ポイントの比較ができなくなります。定義を明確にし、それを徹底しましょう。
予定外の作業からスプリントを守る。 スプリント途中に発生する「火消し」対応のたびに、開発者が引き離され、ベロシティに直接的な打撃を与えます。スプリントのコミットメントを崩さずに緊急項目を振り分ける、軽量なトリアージプロセス(プロダクトオーナーによるフィルタリング、「非常時」ルールなど)を構築しましょう。
見積もりの精度を保つ。 四半期ごとに簡単な再調整の演習を行いましょう。完了済みのストーリーを5〜10件取り出し、現在のチームで再見積もりします。新しい見積もりが元の見積もりと大きく異なる場合、その変化以前のベロシティデータには頭の中で補正をかける必要があります。
外れ値となったスプリントの原因を追跡する。 ベロシティが移動平均から20%以上急上昇または急落した場合は、その原因をスプリントレトロスペクティブに記録しましょう。パターンが見えてきます。休日を含むスプリントが一貫して25%下がるなら、それをキャパシティ計画に織り込めます。
バックログリファインメントを継続的に行う。 リファインメントされていないバックログ項目は信頼性の低い見積もりを生み、それがノイズの多いベロシティにつながります。定期的にリファインメントを行うチームは、よく理解され適切なサイズに整えられたストーリーに基づいて作業しているため、より安定したベロシティを維持できます。
スコープの変動を減らす。 スプリント途中の頻繁なスコープ変更は、ほとんどのチームにとってベロシティの不安定さを生む最大の要因です。スコープ変更の少ない安定したスプリントは、安定したベロシティを生みます。
よくある質問
ベロシティが信頼できるようになるまでに、何スプリント分のデータが必要ですか。 ほとんどの実践者は、ベロシティを予測用の入力値として扱う前に、少なくとも5〜6スプリント分の完了データを推奨しています。それ以前は、ノイズを取り除くにはサンプルが小さすぎます。最初の数スプリントの間は、ベロシティを予測的なものとしてではなく、方向性を示すものとして扱いましょう。
スプリントごとにベロシティが大きく変動する場合はどうすればよいですか。 分散が大きい場合、通常はいくつかの原因のいずれかを示しています。一貫性のないスプリント期間、頻繁なスプリント途中のスコープ変更、最近変更されたチーム構成、あるいは見積もりのドリフトです。まずは各外れ値スプリントの原因をレトロスペクティブで記録することから始めましょう。ばらつきを説明できるようになれば、ノイズをただ平均化するのではなく、根本原因に対処できます。
ベロシティをステークホルダーと共有すべきですか。 生の数字ではなく、リリース予測を共有しましょう。ベロシティの数字だけを単独で見たステークホルダーは、それを目標や他チームとの比較基準として扱ってしまいがちです。予測(「現在のペースなら、このリリースはQ3に間に合う見込みです」)であれば、誤ったプレッシャーを生むことなく必要な情報を提供できます。
ストーリーポイントなしでベロシティを使うことはできますか。 できます。一部のチームは、ポイントではなくストーリー数でベロシティを追跡しています。これはストーリーの規模が常に似通っている場合にうまく機能します。Tシャツサイズを数値スケールに変換して使うチームもあります。重要なのは、どの単位を使うにせよ、意味のある平均値を構築できるだけの期間、一貫して使い続けることです。
ベロシティとキャパシティの違いは何ですか。 キャパシティは計画された稼働可能量(スプリント内のチームの合計時間)です。ベロシティは実際のスループット(完了したポイント)です。キャパシティは入力であり、ベロシティは出力です。チームはスプリント目標を設定するためにキャパシティを使うことがありますが、将来のリリースを予測するためにはベロシティを使います。この2つを混同すると過剰なコミットメントにつながります。100%のキャパシティで臨んだスプリントだからといって、計画したポイントの100%が完了することは保証されません。
ベロシティはシンプルな数字ですが、チームがそれを追いかけるのをやめて読み解き始めたときに、最大の恩恵を得られます。安定したベロシティは、見積もりと納品の習慣が、それを基に計画を立てられるだけ一貫していることを意味します。ベロシティが変化するとき、それは情報です。チームの環境やプロセスの何かが変わったのであり、それが何かを理解する価値があります。
スプリントプランニングの規律、精度の高いストーリーポイントの見積もり、そして累積フロー図によるフローの可視性を組み合わせれば、ステークホルダーが実際に信頼できる予測システムが手に入ります。

Senior Operations & Growth Strategist