ベロシティって何？わかりやすく解説

アプリやWebサービスを作る仕事をしている人って、「あと何週間でこの機能が完成するのか」という計画を立てるのに悩むことがあるんだよね。完成予定が延びたり、急に短縮されたり。その時に使える便利な考え方が「ベロシティ」なんだ。ベロシティを理解すれば、チームの作業速度をちゃんと把握して、もっと正確に計画できるようになるよ。

ベロシティっていうのはね、つまり『チームが1週間や2週間で完成させられる仕事の量』のことなんだよ。野球の投手の球速と同じで、「このチームはこのくらいの速さで仕事をこなせるな」という目安になる数字なんだ

いい質問だね。仕事の量は『ストーリーポイント』という単位で測るんだ。つまり『この機能はどのくらい難しくて、どのくらい時間がかかるか』を数字に変えるんだよ。1から13くらいの数字を使うことが多いんだ

そこがいいポイントだね。実はベロシティを『上げる』って考え方は要注意なんだ。ベロシティは『上げるもの』じゃなくて『測るもの』なんだよ。大事なのは『うちのチームの本当の速さを正確に知ること』なんだ

もうちょっと詳しく

ベロシティの考え方は、アジャイル開発という「短い期間で何度も改善しながら進める開発方法」から生まれたんだ。通常の開発では「完成予定日は3ヶ月後」みたいに決めてから始めるけど、アジャイル開発では「2週間のスプリントを何回も繰り返す」という方法を使うんだよ。その時に『毎回のスプリントでどれだけ進んだか』を測るのがベロシティなんだ。そうすると「今のペースなら、全部で15スプリント必要だから、3〜4ヶ月かな」という予測ができるようになるんだ。

⚠️ よくある勘違い

[toc]

ベロシティの基本〜スクラムって何？

ベロシティを理解する前に、まず「スクラム」という開発の進め方を知っておくといいよ。スクラムっていうのは、つまり『野球のチームスポーツみたいに、チームで目標を決めて短い期間で完成させる進め方』のことなんだ。このスクラムが使われるのは、ソフトウェア開発やアプリ開発の現場なんだ。

スクラムでは「スプリント」という短い期間を使うんだよ。スプリントっていうのは、つまり『1週間から2週間の短い開発期間』のことなんだ。多くの場合は2週間を1スプリントとするんだ。その2週間の間に「ユーザーストーリー」という『ユーザーが必要な機能や改善』をいくつか完成させることを目指すんだよ。

例えば、SNSアプリを作ってるチームだとしようか。1スプリント（2週間）の中で、『ユーザーが写真を投稿できる機能』『いいね機能を改善する』『通知機能を追加する』みたいな複数の仕事を並行して進めるんだ。そして2週間の最後に「あ、今回はこれだけできたね」という結果を確認するんだよ。それが「ベロシティ」に繋がるんだ。

昔のやり方だと『3ヶ月後の完成を目指して、今から全部計画を立てる』というやり方をしてたんだ。でも、開発をしてると思わぬ問題が出てきたり、ユーザーからの要望が変わったりするじゃない。だから「短い期間で区切って、終わるたびに『どのくらい進んだか』を確認して、次の計画を立て直す」という方法に変わったんだ。その時に『どのくらい進んだか』を測る数字がベロシティなんだ。

ベロシティがあると、チーム全体で「今のペースなら、あと何スプリント必要かな」という見通しが立つんだよ。野球の投手の球速みたいに『この投手はだいたい時速150km出してるな』という目安があると、試合の戦略が立つのと同じなんだ。

スプリントの流れ

スプリントはこんな流れで進むんだ。まず最初の日に『このスプリントでやることを決める』というミーティングをするんだ。チーム全体で「今回はこの5つの機能を目指そう」と決めるんだよ。そして2週間、毎日短いミーティングで「今日は何をした？何が問題？」を確認するんだ。そして2週間の最後に『できたものを確認する』ミーティングと『前回と比べてどう改善できるか』を話し合うんだ。

この『できたもの』の量を数字で測ったのがベロシティなんだよ。だから、スプリントが終わるたびに「あ、今回は50ポイント進んだね。前回は45ポイントだったから、ちょっと速くなった」という感じで、パターンが見えてくるんだ。

ベロシティはどうやって測るのか

ベロシティを測るには「ストーリーポイント」という考え方が必要なんだ。ストーリーポイントっていうのは、つまり『仕事の大きさを1から13の数字で表す方法』のことなんだ。

例えば、SNSアプリの場合を考えてみようか。『ユーザーの名前を表示する機能』みたいに『簡単で、すぐにできそう』な仕事は「1ポイント」とするんだ。『新しい写真フィルター機能を追加する』みたいに『ちょっと複雑で、1〜2日かかりそう』な仕事は「5ポイント」とするんだ。そして『複雑で、テストも難しそう』な仕事は「13ポイント」みたいに、難しさと時間がかかりそう度合いで評価するんだよ。

ここで大事なのは『ポイント = 時間』じゃないってこと。1ポイントが1時間とか1日とかっていう意味じゃなくて『相対的に、前の機能と比べてどのくらい大きいか』という比較なんだ。チームの中で「あれは5ポイントだったから、これも同じくらい複雑なら5ポイントだね」という感じで、バラつきなく評価するための数字なんだよ。

では、具体的な例を見てみようか。Webサイトを作るチームがいるとしよう。

【1スプリント目の仕事】
・トップページのレイアウトを作る（3ポイント）
・ボタンのデザインを統一する（2ポイント）
・ユーザープロフィール画面を作る（5ポイント）
・検索機能を実装する（8ポイント）
・エラー画面を作る（1ポイント）

合計が「3＋2＋5＋8＋1 = 19ポイント」だとしよう。この19ポイントが『1スプリント目のベロシティ』になるんだ。つまり「このチームは2週間で19ポイント分の仕事をこなせる」という目安になるんだよ。

【2スプリント目の仕事】
・ユーザー登録機能（8ポイント）
・メール送信機能（5ポイント）
・ダッシュボード画面（8ポイント）
・ヘルプページ（3ポイント）

合計が「8＋5＋8＋3 = 24ポイント」だったとしよう。今回のベロシティは24ポイントなんだ。

こうやって何スプリントか進んでいくと『平均的には1スプリント21ポイント進むな』というパターンが見えてくるんだ。これが「このチームのベロシティは大体21ポイント」という感じで判断するんだよ。

ポイント評価の工夫

ストーリーポイントを評価する時に、チーム内で「え、これ5ポイント？俺は3だと思ったけど」みたいな意見がバラバラになることがあるんだ。そこで「プランニングポーカー」という方法を使うんだ。つまり『チームの全員がそれぞれ『この仕事は何ポイント？』って思う数字を書いて、全員で見せ合う』という方法なんだ。そうすると『あ、この人は5だって思ってるんだ。じゃあ詳しく聞こう』という話し合いができるんだよ。

このポイント評価がちゃんとしてないと、ベロシティも正確じゃなくなるんだ。だから『今回の仕事をどう評価するか』という話し合いが大事なんだよ。

ベロシティでプロジェクト全体がわかる

ベロシティの本当に便利なところは『これを使ってプロジェクト全体の完成時期が予測できる』というところなんだ。

例えば、さっきのWebサイト開発チームの場合を考えてみようか。全体で『やることリスト』が150ポイント分あるとしよう。そして『このチームのベロシティは平均的に20ポイント』だってわかってるんだ。そしたら『150ポイント ÷ 20ポイント = 7.5スプリント』という計算ができるんだ。1スプリントが2週間なら『7.5 × 2週間 = 15週間』つまり『あと3〜4ヶ月で完成するな』という予測ができるんだよ。

これが『完成予定は3ヶ月です』って最初に決めるやり方と違うところなんだ。『本当のペースから逆算してる』から、割と当たるんだよ。

もう1つ大事な使い方が『スプリント中に仕事の量が増えたら、どうするか？』という判断なんだ。例えば『あ、急に新しい機能要望が20ポイント分来た』となった場合。ベロシティが20ポイントなら『あ、20ポイント追加ってことは、完成が1スプリント遅れるな』という判断ができるんだ。経営層とか営業に「あと1スプリント待ってもらえますか」という交渉ができるんだよ。

ベロシティがないと『急に20ポイント増えた！終わるの遅れます』って報告になって、いつ終わるのかがわからないんだ。でも『これは今のペースなら1スプリント遅れます』という具体的な日数が言えるから、判断がしやすいんだ。

ベロシティで判断する例

【例1：バグが大量に見つかった場合】
スプリント中に「あ、バグが結構あるな。このバグ修正に10ポイント分の時間を使わないといけない」となったとしよう。ベロシティが20ポイントなら『あ、今回はバグで10ポイント使うから、新機能に使える時間は10ポイント分だね』という判断ができるんだ。計画を直すことができるんだよ。

【例2：チームメンバーが休んだ場合】
夏休みの時期に『チーム3人のうち、1人が2週間休む』となったとしよう。ベロシティが20ポイントで、その1人が全体の30%の仕事をしてたなら『20 × 70% = 14ポイント』くらいの予測ができるんだ。経営層に『この週は少し遅れます』と正確に伝えられるんだよ。

【例3：技術的な課題に気づいた場合】
開発を進めてると『あ、ここの処理システムが古いから、新機能を追加するのが難しい』という技術的な問題が見つかることがあるんだ。その修正に5スプリント必要だってわかったとしたら『全体の予定が5スプリント遅れます』って計算できるんだ。その上で『技術改善優先でいきましょう』という判断をするんだよ。

ベロシティを使う時の落とし穴

ベロシティはとても便利な道具なんだけど、使い方を間違えると逆効果になることがあるんだ。最も多い間違いが『ベロシティを上げろ』という指示なんだ。

経営層が『今月のベロシティが20ポイントだから、来月は25ポイントにしろ』って指示することがあるんだよ。でも、これは大きな勘違いなんだ。ベロシティは『測る道具』であって『上げる対象』じゃないんだ。野球の投手に『来月は球速160kmにしろ』って言えないでしょ。その投手の体質と技術の中での最大の速さがあるんだ。』同じでね、チームの規模と技術と条件の中での『本当のペース』がベロシティなんだ。

無理にベロシティを上げようとするとどうなるか。『時間がないから、品質チェック減らそう』『テスト簡潔にしよう』『ドキュメント書かなくていいや』みたいなことになるんだ。そしたら『あ、バグが増えた』『後で保守するのが大変だ』という問題が出てくるんだよ。

結果的に『短期的には速くなった気がするけど、長期的には遅くなった』という状況になるんだ。だから『ベロシティを上げる』って考え方は危険なんだ。

ベロシティが変わる正当な理由

じゃあ、ベロシティが変わることはないのかというと、そうじゃないんだ。ベロシティは『その時の条件』を反映してるから、条件が変わると変わるんだ。

【ベロシティが上がる正当な理由】
・チームメンバーが増えた
・チームが経験を積んで、同じ仕事が効率的にできるようになった
・新しいツールやシステムが導入されて、作業がしやすくなった
・技術的な課題を解決して、開発速度が上がった

【ベロシティが下がる正当な理由】
・複雑な技術課題に取り組むようになった
・ユーザーが増えて、パフォーマンス改善に時間がかかるようになった
・品質基準が上がって、テストが厳しくなった
・チームメンバーが抜けた

重要なのは『ベロシティの変化を理由を考えずに受け入れて、対策を立てる』ってことなんだ。『ベロシティが25に下がった。なぜ？→複雑な課題があるから。じゃあ、スケジュール全体の計画を立て直そう』という流れなんだ。『なぜ下がった！改善しろ！』っていう怒りの声じゃなくてね。

チーム間でのベロシティ比較は意味がない

もう1つ大事な注意点は『AチームのベロシティはBチームより高い』という比較は意味がない、ってことなんだ。ベロシティは『そのチームの個性』だからね。

例えば『AチームのベロシティはSNS開発で50ポイント。Bチームの企業システム開発のベロシティは15ポイント』だったとしよう。これを『Aチームが優秀』って判断するのは間違いなんだ。理由は『仕事の種類が違う』『メンバーの組成が違う』『使ってる技術が違う』からなんだ。

SNS開発って『やることが比較的決まってて、パターン化しやすい』仕事なんだ。だからベロシティが高くなりやすいんだ。一方、企業システムって『複雑な要件があって、1個の要件が15ポイント分ぐらい大きい』こともあるんだ。だから『どちらがいい悪い』じゃなくて『条件が違うから、ベロシティも違う』ってだけなんだ。

ベロシティは『自分のチームの過去との比較』『自分のチームの予測』に使う道具なんだ。他のチームとの比較に使うと、却って悪いモチベーションが生まれるんだ。『ベロシティを上げるため』に品質を落とす、みたいなね。

ベロシティの正しい使い方のまとめ

ベロシティを正しく使うには『測定→予測→改善』という3つのステップを回すんだ。

【測定】毎スプリント終わりに『今回はいくつポイント完成させたか』を正確に記録するんだ。ポイント評価にブレがないようにチーム全体で話し合うんだ。

【予測】『過去5スプリントの平均は20ポイント。全体でやることが100ポイント。だから5スプリント必要。つまり10週間』という予測を立てるんだ。経営層や顧客に『完成は10週間後です』と正確に伝えるんだ。

【改善】『今回は22ポイント進んだ。いつもより多い。理由は何？』『前回は15ポイント。品質チェックが厳しかったから。どちらがいい状態？』という話し合いをするんだ。そこから『技術改善するべきか』『チーム編成を変えるべきか』『そのままでいいか』を判断するんだ。

つまり『ベロシティは計画と改善の友だち。敵じゃない』って考え方が大事なんだ。『このペースなら、いつ完成するかな』という見通しを立てて『どうしたら、もっと安定して、品質良く進められるか』を考えるための情報なんだ。だからベロシティを上手に使えば『チーム全体の予定が立てやすくなって、ストレスが減る』んだよ。