「今スプリントのベロシティ予測は？」
月曜の朝、プロダクトオーナーの問いかけに私は答えに窮しました。先週は高い値なのに、その前は半分以下。毎週バラバラな数字を前に、曖昧な返答をするしかありません。
あなたも同じような経験はありませんか？
ベテランのスクラムマスターとの出会いが転機でした。
「ベロシティが安定しないのは、測定方法の問題じゃないよ。もっと根本的な部分に原因がある」
その一言から始まった改善の旅。今回は、その過程で学んだ「ベロシティが安定しない本当の理由」と「実践的な解決法」をお話しします。
なぜベロシティは「嘘をつく」のか
ベロシティとは、1スプリントでチームが完了したストーリーポイントの合計値。教科書的にはそう定義されています。
でも実際は、この数字ほど「嘘をつきやすい」指標はありません。
罠その1：見積もり基準がスプリントごとに変わる
「このストーリー、前回の〇〇機能と同じくらいだから5ポイントかな」
プランニングポーカーでよく聞く会話です。でも、その「前回の〇〇機能」を正確に覚えている人はいるでしょうか？
私のチームでも、同じような機能なのにスプリントによって3ポイントになったり8ポイントになったりしていました。基準となる「ものさし」が、知らないうちにずれていたんです。
そこで私たちは基準ストーリーをチームのWikiにピン留めして常に参照できるようにすることにしました。
シンプルですが効果的でした。チームで基準となるストーリーを決め、その内容をチームのWikiに固定表示しプランニング時には必ず画面に表示させることにしたんです。ログイン機能の実装を基準とし、以下の作業内容を明記しました。
- フロントエンドの画面実装
- API実装とバリデーション
- 単体テストとE2Eテスト
見積もりの際は必ずこの基準と比較します。「ログイン機能より複雑だから大きめ」「半分くらいの作業量だから小さめ」という具合に。
効果は劇的でした。見積もりのばらつきが激減し、「なぜその見積もりなのか」を説明できるようになったんです。
罠その2：「完了」の定義が人によって違う
ある金曜日の夕方のことでした。
「ストーリーA、完了しました！」
開発者の報告を受けて、私はベロシティに8ポイントを加算しました。しかし翌週...
「あのストーリー、まだレビュー終わってないんですけど」 「ドキュメントも更新されてませんね」
そう、「完了」の定義が人によってバラバラだったんです。コードを書き終えたら完了とする人、テストが通ったら完了とする人、本番にデプロイされたら完了とする人...
そこで私たちがとった対策は、Definition of Doneをカンバンボードの各列に明記して、移動条件を厳格化することでした。
「In Progress」から「Review」に移動するには、コード実装と単体テストが必須。「Review」から「Testing」に移動するには、コードレビューが完了していること。「Testing」から「Done」に移動するには、結合テストとプロダクトオーナーの承認が必要。
各列の上部に移動条件を大きく表示し、デイリースクラムではボード上のチケットを一つずつ確認しながら、「このチケット、本当にこの列にいていいの？」と問いかける習慣を作りました。
さらに週次の振り返りで「Doneの定義を満たさずに完了にしたチケット数」を計測し、ゼロを目指すことにしました。最初は抵抗もありましたが、この可視化によってチーム全体の意識が変わり、「あれ、まだ終わってなかったの？」という会話が激減したんです。
罠その3：割り込み作業を「なかったこと」にする
これが最も深刻な問題でした。
スプリント中、必ず発生する割り込み作業。本番障害の対応、急な仕様確認、他チームからの相談...これらに費やした時間を、私たちは「なかったこと」にしていました。
「今スプリントは割り込みが多かったから、ベロシティが下がっても仕方ない」
そう言い訳して、根本的な対策を打たずにいたんです。
そこで私たちは割り込みバッファを最初から確保することにしました。
過去のスプリントの割り込み作業時間を集計したところ、かなりの割合を占めていることが分かりました。
それなら最初から適切なバッファを確保すればいい。
スプリント計画で予定していたストーリーを適切に減らす。単純ですが、これで予測精度が劇的に向上しました。
さらに、割り込み作業自体を減らす取り組みも始めました。
- 緊急度の判定基準を作成（本当に今スプリントで対応必要か？）
- 問い合わせ対応の担当者ローテーション
- ドキュメント整備による問い合わせ削減
結果として、割り込み作業は大幅に減少。その分、本来のストーリーに集中できるようになりました。
ベロシティを「武器」に変える3つの実践
ここまでは「安定化」の話でした。でも本当の目的は、ベロシティを使ってチームをより良くすることですよね。
実践1：トレンドを読む
数字の絶対値より、時系列での変化パターンの方が重要です。
私のチームでは、過去3〜4スプリントのベロシティ推移を折れ線グラフにしてダッシュボードに表示し、チーム全員がいつでもアクセスできるようにしました。そして月に一度、その変化パターンを分析する時間を設けました。
ベロシティが右肩上がりの時は「何が良かったのか」を言語化しました。 ベロシティが下がり続けている時は「何が障害になっているのか」を特定しました。 数値が横ばいで安定している時は「次の改善ポイントは何か」を探しました。
この習慣により、チームは自然と「改善」を意識するようになりました。
実践2：個人ではなくチームで考える
「田中さんが休んだから、今スプリントはベロシティが下がりますね」
こんな会話、していませんか？
ベロシティは個人の成績表ではありません。チーム全体の指標です。誰かが休んでも、チームでカバーし合えるようになることが理想です。
私たちは「ペアプログラミング」と「知識の共有会」を定期的に行うようにしました。最初はベロシティが一時的に下がりましたが、数ヶ月後には誰が休んでも安定したベロシティを維持できるチームに成長していました。
実践3：ベロシティ以外の指標も見る
ベロシティだけを追いかけると、品質が犠牲になります。
私たちは「ベロシティ」「バグ率」「顧客満足度」の3つを常にセットで確認するようにしました。ベロシティが上がってもバグが増えていたら、それは改善ではありません。
特に効果的だったのは、「価値ベロシティ」という概念の導入でした。単純なポイント数ではなく、顧客価値の高いストーリーには重み付けをして計算するんです。
よくある質問と現実的な回答
Q: 他のチームと比較してうちは遅いでしょうか？
A: その質問自体が間違っています。
ベロシティはチーム固有の指標です。見積もり基準も、チーム構成も、扱う技術も違うのに、数字だけ比較しても意味がありません。
大切なのは、自分たちのチームが「先月より良くなっているか」です。
Q: ベロシティを上げるにはどうすればいいですか？
A: まず「安定」させることが先決です。
不安定なベロシティを無理に上げようとすると、たいてい失敗します。品質を犠牲にしたり、メンバーが疲弊したり...
安定してから、少しずつ改善していく。急がば回れです。
Q: 経営層がベロシティの数字ばかり気にします
A: ベロシティだけでなく、ビジネス価値に繋がる指標も一緒に報告しましょう。
ベロシティの絶対値に一喜一憂するのではなく、「予定機能の完成度」「リリース予定日への影響」「品質指標」などを合わせて伝えます。「ベロシティは先月と同じですが、より複雑な機能を高品質で実装できました」といった文脈を添えることで、数字の背景を理解してもらえるようになります。
ベロシティは「体温計」だと思えばいい
ベロシティは、チームの健康状態を測る体温計のようなものです。
体温が安定していれば健康。乱高下していれば何か問題がある。でも体温を上げること自体が目的ではないですよね。健康であることが大切なんです。
私がスクラムマスターになってから数年。多くのチームを見てきて確信したことがあります。
ベロシティが安定しているチームは、必ず良いプロダクトを作っている。
数字に振り回されるのではなく、数字を味方につける。そのための第一歩は、今日お話しした「3つの罠」を避けることから始まります。
明日の朝会で、まずはDefinition of Doneの確認から始めてみませんか？小さな一歩が、大きな変化につながるはずです。
まとめ
ベロシティが安定しない3つの罠は以下のとおりです。
- 見積もり基準の曖昧さ → 基準ストーリーをWikiにピン留め
- 完了定義のばらつき → カンバンボードの各列に移動条件を明記
- 割り込み作業の無視 → 最初からバッファを確保する
ベロシティを武器にする3つの実践は以下のとおりです。
- トレンドを読んで改善につなげる
- 個人ではなくチームで考える
- ベロシティ以外の指標も合わせて見る
チームの健康状態を正しく把握し、着実に改善していく。それがベロシティマネジメントの本質です。
