ベロシティとは？スクラムにおける計算方法や使い方を初心者向けにわかりやすく解説

はじめに

スクラムやアジャイル開発について学んでいると、ベロシティという言葉が登場します。

ベロシティは、チームが過去のスプリントでどのくらいの作業を完成できたかを表す指標です。

過去の実績を確認することで、次のスプリントにどの程度の作業を選べそうか、プロダクトバックログがいつごろ完了しそうかを予測する材料になります。

しかし、初めて学ぶ方にとっては、

• ベロシティはチームの開発速度なのか
• どのように計算するのか
• ストーリーポイントとは何が違うのか
• 作業途中の項目も計算に含めるのか
• ベロシティが高いチームほど優秀なのか
• ベロシティを目標値として引き上げるべきなのか
• バーンダウンチャートやキャパシティとは何が違うのか

といった点が分かりにくいのではないでしょうか。

ベロシティを一言で表すと、

「チームが1回のスプリントで完成できた作業量の実績」

です。

ベロシティは、チームの生産性を評価する点数ではありません。

同じチームが、自分たちの過去の実績をもとに、今後の計画を立てるために利用する指標です。

この記事では、ベロシティの意味や計算方法、ストーリーポイントとの関係、使い方、注意点について、初心者向けにわかりやすく解説します。

ベロシティとは？

ベロシティは、チームが1回のスプリントで、どのくらいの作業を完成できたかを表す実績値だよ。

開発する速さを測る数値なの？

名前から速度を連想するけれど、単純な作業速度ではないよ。スプリントで完成した作業量を表す指標なんだ。

ベロシティは、英語でVelocityと書きます。

一般的な英語では「速度」という意味ですが、アジャイル開発では、一定期間に完成した作業量を表す言葉として使われます。

スクラムでストーリーポイントを利用している場合は、スプリント内で完成したプロダクトバックログ項目のポイントを合計して求めます。

例えば、あるスプリントで次の項目が完成したとします。

完成した項目は、8ポイント、5ポイント、3ポイントです。

したがって、このスプリントのベロシティは次のようになります。

8＋5＋3＝16ポイント

未完成の注文履歴表示は、計算に含めません。

かなり進んでいても、完成していなければ0ポイントなの？

基本的にはそうだよ。ベロシティは作業した量ではなく、完成した成果の量を見る指標だからね。

ベロシティを引っ越しで例えてみよう

引っ越しの荷造りで考えてみよう。

部屋には、次の荷物があるとします。

• 本棚の本
• 衣類
• 食器
• 家電
• 趣味の道具

1日目に荷造りを始め、本棚の本と衣類を箱へ詰め終えました。

食器にも取りかかりましたが、半分しか終わっていません。

この場合、1日目に完成した荷造りは、

• 本棚の本
• 衣類

の二つです。

食器は途中まで進んでいても、運び出せる状態になっていなければ完成とはいえません。

どれだけ手を動かしたかではなく、運べる状態まで完成した荷物を見るんだね。

そう。ソフトウェア開発でも、完成の定義を満たした成果だけを数えることが大切なんだ。

ストーリーポイントとは？

ベロシティを理解するには、ストーリーポイントとの関係を知る必要があります。

ストーリーポイントとは、プロダクトバックログ項目の大きさを相対的に表すための単位です。

作業時間だけでなく、次のような要素を考慮して見積もります。

• 作業量
• 技術的な難しさ
• 複雑さ
• 不確実性
• リスク

例えば、三つの機能を次のように見積もったとします。

この場合、クレジットカード決済は、パスワード変更よりも相対的に大きな作業であると判断しています。

13ポイントなら13時間で終わるの？

ストーリーポイントは、時間そのものではないよ。チーム内で作業の大きさを相対的に比較するための数値なんだ。

ベロシティとストーリーポイントの違い

ストーリーポイントは一つの作業の大きさで、ベロシティは完成したポイントの合計なんだね。

ベロシティの計算方法

ベロシティの基本的な計算方法は単純です。

スプリント内で完成したバックログ項目の見積値を合計する

ことで求めます。

計算例

あるスプリントで、次の5項目へ取り組んだとします。

完成した項目だけを合計します。

3＋8＋5＋2＝18

このスプリントのベロシティは、18ポイントです。

未完成の項目は部分的に計上しない

注文履歴表示が90％完成しているなら、8ポイントの90％を計上してもいい？

通常は計上しないよ。完成の定義を満たしていなければ、ベロシティには含めないんだ。

例えば、8ポイントの項目が次の状態だったとします。

• プログラムは完成した
• 単体テストも完了した
• しかし、結合テストで重大な不具合が見つかった

作業の多くが終わっていても、利用可能な成果として完成していないため、そのスプリントでは0ポイントとして扱います。

次のスプリントで修正し、完成の定義を満たしたときに、完成した項目として計上します。

ただし、スプリントをまたいで同じ8ポイントをそのまま使うか、残作業を再見積りするかは、チームの見積方法によって異なります。

重要なのは、実績を良く見せるために部分的なポイントを計上しないことです。

完成の定義との関係

ベロシティへ含められるのは、完成の定義を満たした項目です。

完成の定義とは、成果が必要な品質を満たしているか判断する共通基準です。

例えば、次のような条件があります。

• 実装が完了している
• コードレビューが終わっている
• 必要なテストに合格している
• 重大な不具合が残っていない
• セキュリティ基準を満たしている
• ドキュメントを更新している
• 本番環境へ公開できる状態である

完成の基準を緩くすれば、ベロシティを上げられるんじゃない？

数値だけは上がるかもしれないけれど、品質を犠牲にしたら意味がないよ。

ベロシティを目標にすると、完成の定義を緩めて数字を上げる行動が起こる可能性があります。

そのため、ベロシティは評価目標ではなく、完成の定義を守った結果として得られる実績として扱います。

ベロシティの求め方

1回のスプリントだけでは、偶然の影響を強く受けます。

そこで、複数回のスプリントのベロシティから平均を求め、今後の予測に利用することがあります。

例えば、過去5回のベロシティが次のとおりだったとします。

平均ベロシティは次のようになります。

（18＋22＋20＋24＋16）÷5＝20

このチームは、過去の実績では1スプリント当たり平均20ポイント程度を完成していると分かります。

次のスプリントでも、20ポイント選べば必ず完成するの？

必ずではないよ。平均は計画を立てるための参考値であって、保証ではないんだ。

平均だけでなく範囲も確認する

平均値だけを見ると、ベロシティの変動が分かりません。

例えば、次の二つのチームを考えてみましょう。

チームA

18、20、22、19、21

チームB

5、35、10、30、20

どちらも平均は20です。

しかし、チームAは比較的安定しているのに対し、チームBは大きく変動しています。

将来を予測するときは、平均だけでなく、最低値・最高値や変動の大きさも確認することが大切です。

ベロシティはどのように使う？

ベロシティは、主に次の目的で利用します。

• 次のスプリントで選ぶ作業量の参考
• リリース時期の予測
• バックログ完了までのスプリント数の予測
• 見積りや作業分割の改善
• チーム内の変化を把握する材料

次のスプリントで選ぶ作業量を考える

過去の平均ベロシティが20ポイントであれば、次のスプリントでも20ポイント前後を選ぶことを検討できます。

ただし、過去のベロシティだけで決めるのではありません。

次のような条件も考慮します。

• メンバーの休暇
• 祝日
• 研修や会議
• チーム構成の変更
• 技術的な不確実性
• 緊急対応の予定
• スプリントの長さ
• 完成の定義の変更

平均20なら、毎回必ず20ポイントを入れるわけではないんだね。

そう。ベロシティは参考資料であって、自動的に作業量を決める命令ではないよ。

完了までに必要なスプリント数を予測する

プロダクトバックログに、残り100ポイントの作業があるとします。

平均ベロシティが20ポイントであれば、単純計算では次のように予測できます。

100÷20＝5スプリント

1スプリントが2週間なら、約10週間が一つの目安になります。

ただし、これは次の条件が大きく変化しない場合の予測です。

• チームの構成
• スプリントの長さ
• 完成の定義
• 見積り基準
• プロダクトバックログの範囲
• 技術や業務の状況

新しい要望が追加されれば、必要なスプリント数も増えます。

複数の予測を示す

平均値だけで一つの完了日を断定すると、予測が外れたときに問題になります。

例えば、最近のベロシティが16～24ポイントの範囲なら、残り100ポイントの作業は次のように考えられます。

16ポイントの場合

100÷16＝約6.25スプリント

24ポイントの場合

100÷24＝約4.17スプリント

したがって、単純な目安では5～7スプリント程度と考えられます。

完了日は1日だけを断言するのではなく、幅を持たせた方が現実的なんだね。

そう。不確実性がある以上、予測にも幅があることを伝える方が誠実だよ。

ベロシティが安定するとは？

ベロシティが安定するとは、毎回まったく同じ数値になることではありません。

スプリントごとの数値が、ある程度同じ範囲に収まる状態を指します。

例えば、

18、20、19、22、21

であれば、18～22程度の範囲で比較的安定しています。

一方、

8、30、12、35、10

のように変動が大きい場合は、予測に使いにくくなります。

ベロシティが大きく変動する原因には、次のようなものがあります。

• バックログ項目が大きすぎる
• 見積り基準が統一されていない
• 割り込み作業が多い
• 未完成作業の持越しが多い
• チームメンバーが頻繁に変わる
• スプリント期間が変わっている
• 完成の定義が曖昧
• 外部の承認や回答待ちが多い
• 作業を選びすぎている

ベロシティを無理に一定にするのではなく、変動の背景を確認し、仕事の進め方を改善します。

ベロシティが上がる理由

ベロシティが以前より高くなる場合があります。

考えられる理由には、次のようなものがあります。

• チームがプロダクトや技術に慣れた
• 作業の分割が上手になった
• 自動テストなどによって作業が効率化した
• 障害や待ち時間が減った
• チームの人数が増えた
• ストーリーポイントの付け方が変わった
• 完成の定義が緩くなった
• 見積りを大きく付けるようになった

ベロシティが上がったら、必ずチームが成長したということ？

必ずしもそうではないよ。見積り基準が変わっただけかもしれないからね。

ベロシティの数字だけを見るのではなく、品質、利用者への価値、チームの働き方なども確認する必要があります。

ベロシティが下がる理由

ベロシティが下がることにも、さまざまな理由があります。

• メンバーが休暇を取った
• 祝日が多かった
• 新しいメンバーが加わった
• 技術的な調査が多かった
• 重大な不具合へ対応した
• 完成の定義を厳しくした
• システムの品質改善へ取り組んだ
• 大きなバックログ項目が未完成になった
• 外部チームの作業を待っていた

ベロシティの低下が、必ずしも悪い状態を意味するわけではありません。

例えば、これまで省略していたセキュリティテストを完成の定義へ追加した場合、短期的にはベロシティが下がる可能性があります。

しかし、品質や安全性は高まっています。

数値が下がっても、チームが悪くなったとは限らないんだね。

そう。背景を見ずに数字だけで判断してはいけないよ。

ベロシティとキャパシティの違い

キャパシティは、チームが次のスプリントで作業へ使える時間や能力を表します。

例えば、5人のチームで1人当たり10日働ける場合、単純な稼働日数は50人日です。

しかし、休暇や会議がある場合は減少します。

ベロシティが過去の結果で、キャパシティがこれから使える時間なんだね。

そう。次のスプリントの計画では、両方を参考にするとよいよ。

ベロシティとバーンダウンチャートの違い

バーンダウンチャートは、期間内に残っている作業量の変化を表すグラフです。

一方、ベロシティは、スプリントで完成した作業量を表す数値です。

ベロシティは1回のスプリントを一つの数字で表し、バーンダウンは日々の変化を見るんだね。

ベロシティと生産性の違い

ベロシティはチームの生産性を表すのではないの？

単純な生産性とは違うよ。

一般的な生産性は、投入した資源に対して、どの程度の成果を得たかを考えます。

一方、ベロシティは、チームが独自に見積もった作業量のうち、スプリント内で完成した量です。

ベロシティからは、次のことは直接分かりません。

• 利用者がどれだけ満足したか
• 売上が増えたか
• 品質が高まったか
• 開発費用を削減できたか
• 社会的な価値を生み出したか
• 無駄な機能を作っていないか

100ポイント完成しても、利用者が使わない機能であれば、大きな価値を生んだとは限りません。

反対に、5ポイントの小さな修正が、重大な問題を解決することもあります。

チーム同士でベロシティを比較できない理由

チームAのベロシティが30で、チームBが20なら、チームAの方が優秀？

そのようには比較できないよ。

ストーリーポイントは、各チームが自分たちの基準で相対的に付けます。

例えば、同じ機能でも次のようになる可能性があります。

見積りの基準が異なるため、ベロシティの数字を直接比較しても意味がありません。

また、次の条件もチームごとに異なります。

• メンバー数
• スキルや経験
• スプリントの長さ
• プロダクトの複雑さ
• 技術的負債
• 完成の定義
• テストやレビューの範囲
• 外部チームへの依存

ベロシティは、同じチームが同じ基準を継続して使うことで、初めて予測に役立ちます。

個人のベロシティを測ってはいけない理由

ベロシティはチーム全体の指標です。

個人ごとの完成ポイントを計算すると、次のような問題が起こりやすくなります。

• 簡単な作業だけを選ぶ
• ポイントの高い作業を取り合う
• 他のメンバーを助けなくなる
• レビューや相談を避ける
• 未完成でも完了にしたくなる
• チームではなく個人の数字を優先する

スクラムでは、チームでスプリントゴールを目指します。

設計を手伝う、レビューを行う、問題を一緒に解決するといった活動は、個人の完成ポイントだけでは正しく評価できません。

ベロシティをノルマにすると何が起こる？

平均20なら、次は25を目標にすればチームが成長するのでは？

ベロシティをノルマにすると、数字を増やすことが目的になる危険があるよ。

例えば、次のような行動が起こる可能性があります。

• 同じ作業へ以前より大きなポイントを付ける
• 未完成の項目を完成扱いにする
• テストやレビューを省略する
• 小さな作業を大量に登録する
• 技術的負債の解消を避ける
• 他のチームへの支援を断る
• 難しい改善へ挑戦しなくなる

このように、測定値が目標になると、本来測りたかった状態を正しく表さなくなることがあります。

ベロシティは、自然な実績として観察することが大切です。

ベロシティを使うメリット

過去の実績を計画に利用できる

希望や感覚だけでなく、実際に完成した作業量を参考にして次の計画を立てられます。

作業の詰め込みすぎを防ぎやすい

平均20ポイント程度のチームが、毎回50ポイントを選んでいる場合、計画が現実的でない可能性に気づけます。

完了時期を予測しやすい

残っているバックログの作業量とベロシティを使い、必要なスプリント数の目安を計算できます。

チームの変化に気づける

ベロシティが急激に変化したときに、チーム構成、割り込み、品質基準などに変化がなかったか確認できます。

見積り方法を改善できる

予測と実績の違いを振り返ることで、バックログ項目の分割や見積り基準を改善できます。

ベロシティを使うデメリット・注意点

数値が独り歩きしやすい

管理者や関係者が、ベロシティを生産性や人事評価の点数として扱う可能性があります。

見積り方によって数字を操作できる

作業へ大きなポイントを付ければ、実際の成果が同じでもベロシティは高くなります。

品質や価値は分からない

ベロシティから、完成した成果が利用者に役立ったか、品質が高いかは判断できません。

チーム構成が変わると参考にしにくい

メンバーの増減やスプリント期間の変更があると、過去のベロシティをそのまま比較しにくくなります。

新しいチームでは実績がない

スクラムを始めた直後は、過去のベロシティがありません。

数回のスプリントを経験し、実績を集める必要があります。

作業範囲の変化を表しにくい

ベロシティだけでは、プロダクトバックログに新しい作業がどの程度追加されたか分かりません。

バーンアップチャートなどと組み合わせることがあります。

ベロシティを正しく使うポイント

同じチーム内で使う

他チームとの比較ではなく、同じチームの過去の実績として利用します。

数回分の実績を見る

1回だけの数値で判断せず、複数回のスプリントから傾向を確認します。

平均だけでなく変動を見る

平均値に加えて、最低値・最高値やばらつきを確認します。

チームの状況を合わせて確認する

休暇、メンバー変更、障害対応など、数値へ影響した背景を確認します

完成の定義を維持する

ベロシティを上げるために品質基準を緩めてはいけません。

予測には幅を持たせる

「必ず5スプリントで終わる」と断定せず、「過去の実績では5～7スプリント程度」のように示します。

利用者への価値も確認する

ベロシティだけでなく、利用率、満足度、売上、品質など、プロダクトの目的に合った情報も確認します。

ベロシティはスクラムで必須？

スクラムを実施するなら、ベロシティは必ず計算するの？

必須ではないよ。

スクラムで定められている作成物は、次の三つです。

• プロダクトバックログ
• スプリントバックログ
• インクリメント

ベロシティは、この三つには含まれていません。

また、ストーリーポイントもスクラムで必須とされるものではありません。

チームによっては、次の方法で将来を予測します。

• 完成した項目数であるスループット
• リードタイム
• サイクルタイム
• 過去の完了件数
• 確率を使った予測
• バーンアップチャート

大切なのは、必ずベロシティを使うことではなく、実際の情報をもとに現実的な計画を立てることです。

ベロシティが向いている場面

ベロシティは、次の条件がある程度そろっている場合に使いやすくなります。

• 同じチームが継続して開発している
• スプリントの長さが一定
• ストーリーポイントの基準が安定している
• 完成の定義が共有されている
• バックログ項目を適切に分割できている
• 過去のスプリント実績がある

ベロシティが使いにくい場面

次のような場合は、過去のベロシティをそのまま使いにくくなります。

• チームを新しく作ったばかり
• メンバーが頻繁に入れ替わる
• スプリントの長さが毎回異なる
• 見積り基準を変更した
• 完成の定義を大きく変更した
• 予測不能な割り込みが非常に多い
• バックログ項目の大きさが極端に異なる
• 複数チームの数値をまとめて比較したい

この場合は、ベロシティだけに頼らず、キャパシティ、スループット、リードタイムなども確認します。

ITパスポート・基本情報・応用情報の試験対策

ベロシティは、アジャイル開発やスクラムに関連する用語として、情報処理技術者試験で問われる可能性があります。

試験では、細かな計算よりも、ベロシティが何を表す指標なのかを理解しておくことが重要です。

試験別に押さえたい内容

試験で覚えたい重要用語

試験問題で注目する表現

類似用語の比較表

よくある誤解

ベロシティは作業の速度を表す

ベロシティが20なら、時速20のように開発速度を表すの？

違うよ。1回のスプリントで完成した作業量の実績だよ。

単位時間当たりのプログラミング速度や、個人が作業する速さを表すものではありません。

ベロシティが高いチームほど優秀

チームごとにストーリーポイントの基準が異なります。

完成の定義、人数、プロダクトの複雑さも異なるため、単純比較はできません。

ベロシティは毎回上げるべきである

ベロシティは自然な実績です。

毎回上げることを目標にすると、見積りを大きくしたり、品質基準を下げたりする危険があります。

計画したポイントがベロシティになる

スプリント開始時に25ポイントを選んでも、完成したのが18ポイントならベロシティは18です。

計画量ではなく、完成量を表します。

作業途中の項目も進んだ割合だけ計上する

基本的には、完成の定義を満たした項目だけを計算に含めます。

80％完成という主観的な進捗率を部分的に計上すると、利用可能な成果の量が分かりにくくなります。

ベロシティから正確な納期が分かる

ベロシティを使って完了時期の目安を計算できます。

しかし、将来の要望追加、メンバー変更、技術的問題などによって変化するため、正確な納期を保証するものではありません。

平均ベロシティと同じ作業量を必ず選ぶ

平均値は参考です。

休暇、祝日、会議、技術的な不確実性などを考慮し、開発者が現実的な作業量を選びます。

ベロシティが下がるのは悪いことである

品質基準を強化した、技術的負債を解消した、メンバーが休暇を取ったなど、正当な理由で下がることがあります。

背景を確認する必要があります。

ベロシティが安定すればプロダクトは成功する

安定したベロシティは予測に役立ちます。

しかし、価値の低い機能を安定して作っていても、プロダクトの成功にはつながりません。

利用者や事業への成果も確認する必要があります。

個人別のベロシティを評価に使える

ベロシティはチーム全体の成果量です。

個人別に測ると、助け合いや共同作業を妨げる可能性があります。

スクラムではベロシティの計測が必須

ベロシティもストーリーポイントも、スクラムで必須の要素ではありません。

チームの目的に合った予測方法を選びます。

まとめ

ベロシティとは、チームが1回のスプリントで完成できた作業量を表す実績値です。

ストーリーポイントを利用している場合は、完成の定義を満たしたプロダクトバックログ項目のポイントを合計して求めます。

作業途中の項目は、どれだけ進んでいても、完成していなければ基本的に計算へ含めません。

複数回のスプリントのベロシティを確認すると、次のスプリントでどの程度の作業を選べそうか、残りのバックログを完成させるまでに何スプリント必要かを予測できます。

ただし、ベロシティはチームの能力や生産性を評価する点数ではありません。

ストーリーポイントの基準はチームごとに異なるため、他チームとの比較にも適していません。

また、ベロシティをノルマとして引き上げようとすると、見積りの水増しや品質低下につながる可能性があります。

同じチームが、自分たちの過去の実績をもとに、現実的な計画を立てるための指標として利用することが大切です。

最後に要点を整理します。

ベロシティは、チームがどれだけ速く働いたかを評価する点数ではないんだね。

そう。過去のスプリントで、完成の定義を満たした作業量を表す実績だよ。

ストーリーポイントは一つひとつの作業の大きさで、完成したポイントの合計がベロシティなんだね。

ただし、未完成の項目は基本的に含めないよ。

過去の平均を見れば、次のスプリントにどのくらい選べそうか予測できるんだね。

そう。でも、休暇やチームの変化もあるから、必ず同じ量を完成できるとは限らないよ。

他チームと競争したり、毎回数字を上げたりするための指標でもないんだね。

バッチリ。「過去に完成できた量から、未来を予測する」と覚えておこう。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。