外部ベンダーにアジャイル開発を発注していると、スプリントレビューのたびに「今回のベロシティは32でした」「先週は40だったので少し下がりました」といった報告を受けます。けれども、その数字が順調なのか、それとも遅れの兆候なのか、自分では判断できずに戸惑った経験はないでしょうか。
数字が前回より下がったときは、なおさら不安になります。「チームの調子が悪いのか」「このままだとリリースに間に合わないのではないか」と気になりつつ、何をどう確認すればよいか分からない。社内では上長から「進捗はどうなっている？」と問われ、答えに詰まってしまう——発注者としては、なかなかつらい状況です。
ベロシティが分かりにくいのは、それが「絶対的な成績」のように見えて、実はそうではないからです。ベロシティは他社や他チームと比べる指標ではなく、そのチーム固有の作業ペースを映す目安にすぎません。この前提を取り違えたまま数字だけを追うと、判断を誤りやすくなります。
本記事では、発注者の視点に立って、ベロシティの基本的な意味から、数字の良し悪しを判断する目安、急落したときにチームで何が起きているかの読み解き方、そして「評価指標として使ってはいけない」理由までを解説します。読み終えるころには、ベロシティを「チームの成績表」ではなく「チームの状態を映す計器」として読めるようになり、次のスプリントレビューで建設的な質問ができるようになるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ベロシティとは？発注者がまず押さえるべき基本
ベロシティとは、アジャイル開発（とくにスクラム）において、1つのスプリント（1〜2週間程度の短い開発期間）で開発チームが完了させた作業量の合計を数値化したものです。具体的には、そのスプリントで「完了」となったストーリーポイントを足し合わせた値がベロシティになります（Asana「ベロシティとは何か？」）。
たとえば、あるスプリントで5ポイント・8ポイント・3ポイントの3つの作業が完了したなら、そのスプリントのベロシティは16です。シンプルな足し算なので、計算そのものは難しくありません。発注者にとって重要なのは、計算式よりも「この16という数字が何を意味しているか」を正しく捉えることです。
ここで発注者が最初に理解しておきたいのは、ベロシティは絶対的な成績ではなく、そのチーム固有の作業ペースを示す目安だという点です。テストの点数のように「80点なら優秀、40点なら不合格」と読めるものではありません。同じ16でも、あるチームにとっては好調を意味し、別のチームにとっては事情があって落ち込んでいる状態を意味することもあります。この感覚をまず押さえておくと、以降の解釈がぐっと正確になります。
ベロシティとストーリーポイントの関係（時間見積もりとの違い）
ベロシティを理解するには、その材料であるストーリーポイントを知っておく必要があります。ストーリーポイントとは、開発する一つひとつの作業（ユーザーストーリー）について、その「大きさ」や「難しさ」を相対的に見積もるための単位です。時間（人日・人時）ではなく、作業同士を比べたときの相対的な規模で表す点が特徴です（レバテック「アジャイル開発におけるベロシティとは？」）。
なぜ時間ではなく相対値を使うのか、と疑問に思うかもしれません。理由は、人間は「これは何時間かかる」という絶対的な見積もりが苦手な一方で、「これはあの作業の倍くらい大変だ」という相対的な比較は比較的得意だからです。3ポイントの作業に対して、明らかに倍くらい手間がかかりそうな作業を8ポイントとする——このように、作業同士の大小関係をそろえていくのがストーリーポイントの考え方です。
ここから一つ大事な注意点が導かれます。ストーリーポイントが相対的な単位である以上、ベロシティの数値も「時間に換算できる絶対量」ではありません。「ベロシティ40＝40時間分」「ベロシティが2倍になれば作業スピードが2倍」とは読めないということです。ベロシティはあくまで、そのチームが自分たちの基準で測った作業量の積み上げである、と捉えてください。
なぜチーム間・他社とベロシティを比較してはいけないのか
発注者がやってしまいがちなのが、「前のベンダーはベロシティ50だったのに、今のチームは30しかない。生産性が低いのでは」といった比較です。しかし、これは意味のない比較です。
理由は、ストーリーポイントの付け方がチームごとに違うからです。あるチームが3ポイントと見積もる作業を、別のチームは5ポイントと見積もることは普通にあります。基準がそろっていない以上、数値の大小を直接比べても、どちらのチームが優秀かは分かりません。同じ作業を「3」と呼ぶか「5」と呼ぶかの違いでしかなく、実際にこなしている仕事量が違うとは限らないのです。
複数のチームや過去のプロジェクトと数字を並べて優劣をつけたくなる気持ちは自然なものですが、ベロシティに関してはその比較は成り立ちません。発注者が意味のある形でベロシティを使えるのは、あくまで「同じチームの中での時間的な推移」を見るときだけです。次の章では、その推移をどう読むかを具体的に見ていきます。
ベロシティの「良し悪し」は安定度で見る
「では、いくつなら良くて、いくつなら悪いのか」——これがおそらく最も知りたいところだと思います。結論から言うと、ベロシティに「この数字なら正常」という絶対的な正解値はありません。けれども、発注者が判断材料として使える実用的な見方はあります。それが「安定度」で見るという考え方です。
具体的には、直近3〜5スプリントの平均と、そのブレ幅（上下にどれだけ揺れているか）に注目します。数字の絶対値そのものよりも、「安定して推移しているか、それとも大きく揺れているか」のほうが、発注者にとってはるかに有益な情報になります。
「絶対的な正解値」はない・チーム固有である理由
前章までで見たとおり、ベロシティはチーム固有の作業ペース指標であり、ストーリーポイントの基準もチームごとに異なります。そのため、「ベロシティ40が標準」のような業界共通の正常値は存在しません。
新しく立ち上がったチームの場合、最初の数スプリントはベロシティが安定しないのが普通です。チームがお互いの進め方に慣れ、ストーリーポイントの付け方の基準がそろってくるまでには時間がかかるためです。立ち上げ直後の低い数字や大きなブレを見て「このチームは大丈夫か」と心配する必要は、必ずしもありません。むしろ、数スプリントを経て数値が落ち着いてくるかどうかを見守るほうが大切です。
安定度で見る（直近3〜5スプリントの平均とブレ幅）
実際の読み方を整理すると、次のようになります。
- 安定して推移している場合: 直近数スプリントのベロシティが、たとえば「34・36・33・35」のように近い値で並んでいる状態です。これはチームのペースが読みやすく、計画の予測が立てやすい良い状態と捉えられます。発注者としても、今後の見通しを立てやすくなります。
- 大きく上下に揺れている場合: 「45・22・38・18」のように、スプリントごとに数字が乱高下している状態です。これは見積もりの精度に課題があるか、スプリントごとに割り込み作業が入るなどチームの状況が安定していない可能性を示します。数値の高さ・低さよりも、この「揺れ」のほうが注意すべきサインです。
ポイントは、1スプリントの数字だけで一喜一憂しないことです。たまたま大きな作業が完了したスプリントは数字が伸びますし、検証に時間がかかった作業が重なれば下がります。1回の値ではなく、複数スプリントの流れとして眺めることで、はじめてチームの本当のペースが見えてきます。
完了時期の予測にベロシティを使う
安定したベロシティが得られると、発注者にとって特に役立つ使い方ができます。それが完了時期の予測です。
考え方はシンプルで、「残っている作業の総ストーリーポイント ÷ 平均ベロシティ ＝ 完了までに必要なおおよそのスプリント数」という計算です（Asana「ベロシティとは何か？」）。たとえば、残作業が合計240ポイントで、チームの平均ベロシティが40なら、おおよそ6スプリント程度で完了する見込み、と見積もれます。
これは、リリース時期の見通しを立てたり、社内に進捗を報告したりするうえで非常に有用な情報です。ただし、これはあくまで「現在のペースが続けば」という前提の概算であり、仕様変更や割り込みが入ればずれていきます。固定された約束ではなく、現時点での見通しとして扱うことが大切です。なお、より短い期間（スプリント内やリリースまで）の残作業の進み具合を見たいときは、後ほど触れるバーンダウンチャートが役立ちます。
ベロシティが急落するよくある原因とチームの状態
発注者がベロシティについて検索する最大の動機は、おそらく「前回より数字が大きく下がった」ときの不安です。ここでは、急落の代表的な原因を3つに整理し、それぞれ「数字の裏で、チームに何が起きているのか」を発注者の視点で読み解いていきます。あわせて、発注者として確認すべきこと・とるべき対応もセットで示します。
大前提として覚えておきたいのは、ベロシティの低下は必ずしも「チームの怠慢」や「能力不足」を意味しないということです。むしろ、数字の低下はチームの状態を知らせてくれるサインです。原因を一緒に探る姿勢が、結果的に最も早い解決につながります。
原因1: 体制変更・オンボーディング（多くは一時的）
新しいメンバーが加わったり、メンバーが交代したりした直後は、ベロシティが一時的に下がるのが普通です。新メンバーがプロジェクトの仕様やコードに慣れるまでには時間がかかりますし、既存のメンバーもその指導に時間を割くため、チーム全体としての完了量は一時的に落ちます（合流直後のベロシティ低下をどう乗り越えたか？ - SmartHR Tech Blog）。
これは「増員したのにかえって遅くなった」という、発注者から見ると一見不可解な現象を生みます。けれども、これはオンボーディング（新メンバーの立ち上げ）に伴う自然なコストであり、多くの場合は数スプリントで回復していきます。
- 発注者が確認すべきこと: 直近で人員の追加や交代がなかったかをベンダーに尋ねます。「体制が変わったタイミングと、数字が下がったタイミングは一致していますか」と確認するだけで、原因の切り分けができます。
- とるべき対応: 増員直後の低下に対して急かすのは逆効果です。立ち上げ期間を見込んだうえで、数スプリント後に回復傾向が見えるかを見守る姿勢が適切です。
原因2: 割り込み・仕様変更・技術的負債による圧迫
予定していた開発作業以外に、突発的な対応が入るとベロシティは下がります。代表的なのは、本番障害への緊急対応、急な仕様変更、そして「技術的負債」と呼ばれるものへの対処です。
技術的負債とは、過去に急いで作った部分や、後回しにされてきた改善が積み重なって、新しい開発の足を引っ張っている状態を指します。負債が溜まっていると、一つの機能を追加するだけでも周辺の確認や手直しが必要になり、実質的にこなせる作業量が削られていきます。
見落とされやすいのが、発注者側からの割り込みです。「ついでにこれもお願い」という小さな依頼や、頻繁な仕様変更が積み重なると、チームが計画した作業に集中できず、ベロシティが下がる原因になります。
- 発注者が確認すべきこと: 「今回のスプリントで、計画外の作業や割り込みはどのくらいありましたか」と尋ねます。あわせて、自分自身が出した追加依頼が影響していないかも振り返ります。
- とるべき対応: 割り込みが多いなら、緊急のもの以外は次のスプリントに回す、といった優先順位づけをベンダーと相談します。技術的負債が原因なら、その解消にどれくらいの時間を見込むべきかを一緒に検討する姿勢が有効です。
原因3: 見積もり基準・完了の定義のズレ
3つ目は、数字の「測り方」自体に関わる原因です。チームのストーリーポイントの付け方が途中で変わったり、「何をもって完了とするか」の基準（完了の定義）が変わったりすると、見かけ上のベロシティが変動します。
たとえば、これまでは「コードが書けたら完了」としていたのを、「テストとレビューまで終えて初めて完了」と基準を厳しくした場合、1スプリントで完了する作業量は減り、ベロシティは下がります。しかしこれは、品質の担保という意味ではむしろ望ましい変化であり、チームが悪くなったわけではありません。数字だけを見ると後退に見える一方で、実態は前進していることもあるのです。
- 発注者が確認すべきこと: 「見積もりの基準や、完了とみなす条件に最近変更はありましたか」と確認します。これにより、実際の作業量が減ったのか、それとも測り方が変わっただけなのかを区別できます。
- とるべき対応: 完了の定義を厳しくした結果の低下なら、それを前向きな変化として受け止めます。新しい基準のもとで数スプリント様子を見て、新たな安定値を把握し直すのが適切です。
一時的な低下か・継続的な低下かの見分け方
ここまでの3つの原因に共通して大切なのが、「その低下が一時的なものか、継続するものか」を見極めることです。判断の目安はシンプルで、複数スプリントの流れで見ることです。
1スプリントだけ落ち込んで翌スプリントで戻るなら、突発的な割り込みやスプリント固有の事情だった可能性が高く、過度に心配する必要はありません。一方、3スプリント以上にわたって低下が続いたり、回復の兆しが見えなかったりする場合は、技術的負債の蓄積やチーム状態の悪化など、根本的な課題が隠れている可能性があります。この場合は、ベンダーと腰を据えて原因を掘り下げる必要があります。
つまり、急落そのものに即座に反応するのではなく、「この低下は続きそうか」を数スプリント観察してから対応の強さを決める、というのが発注者として落ち着いた向き合い方です。
発注者がやりがちなベロシティの誤用（評価指標にしてはいけない）
ここまで読んで、ベロシティの読み方が少し見えてきたところで、発注者として最も気をつけたい落とし穴をお伝えします。それは、ベロシティをチームの「成績」や「生産性」として評価・叱責の材料に使ってしまうことです。これは発注者が最もやりがちで、かつ最も害が大きい誤用です。
数字が下がったときに「もっと上げてください」とプレッシャーをかけたり、ベロシティの高さでチームを評価したりすると、短期的には数字が上がるように見えるかもしれません。しかし、その先に待っているのは、かえって価値が下がるという皮肉な結果です。
評価に使うと数字が壊れる仕組み
なぜ評価に使うと逆効果なのか。それは、ベロシティが「チーム自身が見積もる数字」だからです。
ベロシティを上げろと求められたチームは、実際の仕事量を増やすのではなく、見積もりを操作することで簡単に数字を上げられてしまいます。具体的には、これまで3ポイントと見積もっていた作業を5ポイントと見積もる（ポイントの水増し）、あるいは確実にこなせる楽な作業ばかりを優先して数字を稼ぐ、といった行動です。チームが自分たちを良く見せたくなるのは心理的に自然なことで、評価指標になればその傾向は加速します（マネージャ必見! ベロシティでのスクラムチームの評価が危険な理由 - Salaryman Gonkun's Blog）。
その結果、ベロシティの数値は上がっても、実際にユーザーに届く価値は増えていない、という事態が起こります。これは「ベロシティのインフレ」とも呼ばれ、目標として課された途端に発生しやすくなります（目標ベロシティとベロシティのインフレ | Ryuzee.com）。それどころか、難しいけれど重要な作業が後回しにされ、プロジェクト全体としては悪化することすらあります。さらに悪いことに、見積もりが水増しされると、ベロシティ本来の役割である「完了時期の予測」も当てにならなくなります。発注者が数字でチームを詰めることは、自分が頼りにしている指標を自分の手で壊す行為でもあるのです。
ベロシティの本来の目的（計画と認識合わせ）
では、ベロシティは何のためにあるのか。それは、チームが自分たちの計画の精度を高め、発注者と「だいたいこのくらいのペースで進む」という認識を合わせるための道具です。チームを管理・評価するための道具ではありません。
この位置づけを発注者と開発チームが共有できていると、ベロシティは健全に機能します。チームは数字をよく見せようとする必要がなくなり、正直な見積もりを出せます。正直な数字だからこそ、完了予測も信頼できるものになり、発注者は安心して社内報告や計画立案に使えます。
数字が下がったときに発注者がとるべき自然な反応は、「なぜ下がったのか」をチームを責めずに一緒に探ることです。次の章では、そのための具体的な質問を紹介します。
ベロシティ報告時に発注者が投げるべき質問リスト
ここまでの内容を、次のスプリントレビューですぐ使える形にまとめます。ベロシティの報告を受けたとき、発注者が建設的に使える質問の例を挙げます。
いずれの質問も、チームを問い詰めるためのものではなく、状況を正しく把握し、必要なら一緒に手を打つためのものとして使ってください。同じ言葉でも、詰問の調子で投げれば前章で述べた数字の水増しを招き、状況把握の姿勢で投げれば建設的な対話につながります。
- 直近数スプリントの平均と比べてどうですか？ ——1回の数字ではなく流れの中で位置づけるための質問です。「平均的な範囲内」なのか「明らかに外れている」のかをまず確認します。
- 今回の増減の主な要因は何ですか？ ——数字が動いた背景を、推測ではなくチームの認識として把握します。
- この変動は一時的なものですか、それとも続きそうですか？ ——対応の強さを決めるための見極めです。一時的なら見守り、継続しそうなら掘り下げます。
- 見積もりの基準や「完了の定義」に変更はありましたか？ ——実際の作業量が変わったのか、測り方が変わっただけなのかを切り分けます。
- 計画外の割り込みや仕様変更はどのくらいありましたか？ ——自分の側の依頼が影響していないかを振り返るきっかけにもなります。
- このペースが続いた場合、リリース予定への影響はどう見ていますか？ ——ベロシティを完了予測につなげ、今後の見通しをすり合わせます。
これらの質問に共通するのは、「数字をどう上げるか」ではなく「今チームに何が起きているか」を理解しようとする姿勢です。この姿勢で対話を重ねるほど、チームは正直な情報を共有しやすくなり、発注者はより正確に状況を把握できるようになります。
なお、こうした対話の主な場となるのがスプリントレビューです。スプリントレビューへの関わり方そのものについては、スプリントとは？発注者が知るべきスプリントレビューの関わり方と費用評価で詳しく解説しています。
バーンダウンチャートと組み合わせた読み方
ベロシティは強力な指標ですが、それ単独ですべてが分かるわけではありません。発注者がより正確に状況を判断するには、もう一つの代表的な指標であるバーンダウンチャートと組み合わせて見るのがおすすめです。両者は競合するものではなく、補い合う関係にあります。
役割の違いを整理すると、次のようになります。ベロシティは「チームのペースが安定しているか」を、スプリントをまたいだ流れの中で見る指標です。一方、バーンダウンチャートは、残っている作業量が時間とともにどう減っていくかを折れ線で表したもので、「このペースで進めば期限までに終わりそうか」をひと目で確認するための指標です。
この2つを併せて見ると、遅延の兆候をより早く、より正確にとらえられます。たとえば、ベロシティは安定しているのにバーンダウンチャートの線がなかなか下がらない場合、「ペース自体は悪くないが、そもそも作業量が計画に対して多すぎる」可能性が見えてきます。逆に、バーンダウンチャートは順調でもベロシティが大きく揺れているなら、「今回はたまたま間に合いそうだが、ペースが不安定で次回以降が読みにくい」状態かもしれません。
発注者として大切なのは、一つの数字だけに頼らず、複数の指標を組み合わせて状況を立体的に判断することです。ベロシティで「チームのペースの健全さ」を、バーンダウンチャートで「期限への到達見込み」を確認する——この役割分担を意識するだけで、進捗の見え方が大きく変わります。
まとめ
ベロシティは、発注者にとって分かりにくく感じる指標ですが、読み方の軸さえ押さえれば、チームの状態を映す頼もしい計器になります。最後に要点を整理します。
- 絶対値ではなく安定度で見る: 「いくつなら正常」という共通の正解値はありません。直近3〜5スプリントの平均とブレ幅を見て、安定して推移しているかどうかを判断します。
- 急落は責めるのではなく原因を一緒に探る: 体制変更・割り込みや技術的負債・見積もり基準の変化など、低下にはチームの状態を示す理由があります。一時的か継続的かを数スプリントの流れで見極めることが大切です。
- 評価指標にしない: ベロシティをチームの成績として詰めると、数字が水増しされ、かえって届く価値も完了予測の信頼性も下がります。ベロシティは管理の道具ではなく、計画精度を高め認識を合わせるための道具です。
- 質問で建設的に関与する: 報告を受けたら、状況把握のための質問を投げます。「今チームに何が起きているか」を一緒に理解する姿勢が、最も早く確実な前進につながります。
ベロシティの数字に振り回されるのではなく、その背後にあるチームの状態に目を向ける。そうすることで、発注者は開発チームと健全に協働し、プロジェクトを着実にゴールへ近づけていけます。次のスプリントレビューでは、ぜひ「数字を詰める」のではなく「状況を一緒に読み解く」対話を試してみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
