ベロシティ(アジャイル)

ベロシティ(アジャイル)とは?

サクッとわかるゾーン

ひとことで言うと

ベロシティは、アジャイルチームが1スプリント(通常1~4週間)で完了できる作業量を相対的に測定するメトリクスです。ストーリーポイントという単位で表現され、チームが過去の実績に基づいて現実的なコミットメントを立てるための予測ツールとなります。

ポイントまとめ

相対的な作業量の測定 - 時間ではなく、ストーリーポイント(相対的な複雑さ・手間)で計測
チーム固有のメトリクス - チーム間での比較には使わず、同じチームの改善追跡に活用
予測と計画の基盤 - 過去のベロシティから将来のスプリント計画やリリース予測を行う

深掘りゾーン

なぜ重要か

ベロシティは、不確実性の大きいソフトウェア開発において、チームが「現実的に何ができるのか」を客観的に把握するための仕組みです。時間ベースの見積もり(「このタスクは3日かかる」)よりも、相対的なサイジング(「このストーリーはあれと比べて2倍複雑」)の方が、実際のチームの能力を正確に反映します。継続的なベロシティ測定により、チームは燃え尽き防止、現実的な約束、品質維持のバランスを取れるようになります。

仕組みをわかりやすく解説

ベロシティサイクルは以下の流れで機能します。

まず、バックログリファインメントで、プロダクトオーナーと開発チームがユーザーストーリーをストーリーポイントで見積もります。プランニングポーカーなどの技法を使い、相対的な複雑さについてチーム全体で合意します。

次に、スプリント計画で、チームは過去のベロシティ履歴を確認します。例えば過去5スプリントの平均が40ポイントなら、今スプリントも約40ポイント分のストーリーを選びます。

スプリント中のデイリースタンドアップでは、進捗確認と障害対応を行い、予定通り完了できるか見通しを立てます。

スプリント終了時に、完成の定義を満たす完全なストーリーのポイント合計をベロシティとします。部分的な完成や品質不備のストーリーはカウントしません。

最後に、レトロスペクティブで、パフォーマンスを分析します。ベロシティが下がった場合は「チーム構成が変わった」「技術的負債が増えた」など原因を特定し、改善策を立てます。

このサイクルを繰り返すことで、チームはますます正確な見積もり精度と安定したベロシティを獲得します。

実際の活用シーン

スプリント計画 - 平均ベロシティが40ポイントのチームが、次スプリントのストーリーを選ぶ際、合計38~42ポイント分を選択。チーム全体で「これなら実現できる」と確信を持てる目標設定になる
リリース計画 - 重要な機能200ポイント分が必要で、チームのベロシティが平均40ポイント/スプリント(2週間)の場合、5スプリント(10週間)で完成と予測。マーケティング部門との協調が容易になる
キャパシティ予測 - 新しいプロジェクトのリソース計画時に、ベロシティ実績データを基に「このチームなら3ヶ月でこれくらい」と判断
パフォーマンス監視 - ベロシティが連続して低下している場合、「技術的負債対応が増えた」「チームメンバー交代」など問題を早期発見

メリットと注意点

メリット

現実的な計画立案 - 希望的観測ではなく、実績に基づいた計画が可能
チーム自律性向上 - メンバーが自分たちのペースを可視化し、自己組織化が進む
ステークホルダー信頼構築 - 「約束したことを実現できる」という実績が積み重なる
早期のリスク発見 - ベロシティの異変から、問題を素早く検知

注意点

チーム間比較禁止 - 異なるチームのベロシティを比較するとゲーミングが発生
見積もり較正が必須 - ストーリーポイントの定義がぶれると、ベロシティの信頼性が失われる
チーム構成の変更に弱い - メンバーの入れ替わりで再較正期間が必要
外部要因への脆弱性 - 技術的負債や外部依存により、純粋なチーム能力を測定できない場合がある

関連用語

スプリント - ベロシティを測定する時間単位
ストーリーポイント - ベロシティ測定の基本単位
スクラム - ベロシティを活用するアジャイルフレームワーク
プロダクトバックログ - ベロシティで計測する対象の一覧
完成の定義 - ベロシティカウント時の判定基準

よくある質問

Q1. ベロシティが上がり続けたら、チームは本当に成長している?

A. 必ずしもそうではありません。初期段階(最初の3~5スプリント)は見積もり精度向上で上がることがあります。その後安定化するのが正常。継続的に上昇する場合は「見積もりがぶれている」「完成の定義を甘くしている」「ゲーミングが発生している」可能性があります。重要なのは「安定性」です。

Q2. 新しいチームはどのくらいでベロシティが信頼できるレベルになる?

A. 一般的に3~5スプリント必要です。ただし、メンバー構成が不安定だと再スタートになります。最初のスプリントは「較正」と考え、その結果から学ぶことが重要です。

Q3. ベロシティが急に下がったら何をすればいい?

A. 原因特定がすべてです。チーム構成の変化、新技術導入、バグ対応の増加、見積もり基準の変更など、複数の要因を検討。レトロスペクティブで徹底的に議論し、「一時的な変動」か「構造的な問題」かを区別することが重要。