アジャイルおよびスクラム手法の文脈において、あまりにも多くの混乱や不安を引き起こす概念は他にないバティティ。経営陣によってパフォーマンスのスコアカードとして扱われたり、チームによって厳格な目標として扱われることが多いが、このメトリクスはしばしばその本来の目的を逸脱する。バティティはマネージャーの鞭ではなく、チーム自身のためのツールである。正しく理解されれば、能力と予測可能性に関する洞察を提供する。誤解されると、行動を歪め、信頼を損なう。
このガイドでは、バティティの真の性質、スクラムフレームワーク内での働き方、そして健全性を保つために必要な重要な境界について探求する。技術的な定義、誤解を招く一般的な落とし穴、そして心理的安全性を損なうことなく、データを活用してフローを改善するための戦略についても検討する。
🧩 スクラムにおけるバティティとは何か？
本質的に、バティティとはスクラムチームが1回のスプリントで対処できる作業量を測る指標である。これは従来の意味でのスピードの測定ではなく、生産性の普遍的な基準でもない。むしろ、チーム自身の過去のパフォーマンスに基づいて導かれる相対的な単位である。
- それは後向きである： それは過去のスプリントで完了した作業に基づいて計算される。
- それはチーム固有である： それは特定のチームの独自の能力、スキルセット、文脈を反映している。
- それは計画の支援である： 主な目的は、チームが将来どれだけの作業をコミットできるかを予測するのを助けることである。
バティティは安定化の役割を果たす。時間とともに、チームが「完了の定義」と推定手法の整合性を保てば、バティティの数値は安定化傾向にある。この安定性により、製品の予測がより正確になる。しかし、この数値を固定された目標として扱うと、摩擦が生じる。
⚙️ バティティの計算方法
計算のメカニズムを理解することは、このメトリクスの限界を理解するために不可欠である。バティティは通常、ストーリーポイントを使って算出される。ストーリーポイントは、ユーザー・ストーリーの努力、複雑さ、リスクを評価するために用いられる相対的な推定手法である。
計算式
計算はシンプルだが、入力には自制心が必要である：
- スプリント内で完了したすべてのユーザー・ストーリーを特定する。
- 各項目について、完了の定義（DoD）が満たされていることを確認する。
- 完了した項目に割り当てられたストーリーポイントを合計する。
- その合計が、そのスプリントにおけるバティティとなる。
重要なのは、開始したが完了しなかった作業はカウントされないということだ。遅れて追加され、完了した作業はカウントされる。この違いは正確性を保つために不可欠である。
- 完了した作業： 受け入れ基準を完全に満たした項目のみがスコアに貢献する。
- 部分的な作業： 半分しか終わっていないストーリーは計算から除外される。
- スパイク： 時間制限付きの調査スパイクは、出荷可能な進捗をもたらさない限り、通常はベロシティにカウントされません。
- 技術的負債： リファクタリング作業は、DoDを満たしている場合、ベロシティに貢献しますが、機能開発とのバランスを取る必要があります。
🚫 ベロシティの一般的な誤用
危険なのは指標そのものではなく、外部のステークホルダーがどのようにそれを適用するかにあります。ベロシティが文脈から切り離されると、計画ツールではなく、圧力の源になります。以下に、この指標が最も頻繁に誤って使われる方法を示します。
1. チーム間の比較
最も害を及ぼす誤りの一つは、チームAのベロシティとチームBのベロシティを比較することです。この比較は根本的に誤りである理由は以下の通りです：
- 見積もりスケールが異なる： チームAはストーリーを5ポイントと見積もり、チームBは自らのキャリブレーションに基づいて同じストーリーを8ポイントと見積もります。
- 複雑さが異なる： 一方のチームは高い技術的負債を抱えるレガシーシステムで作業している一方、もう一方のチームはグリーンフィールドプロジェクトで作業しています。
- チーム構成： シニアアーキテクトを擁するチームは、ジュニア開発者だけのチームとは異なるペースで動きます。
ベロシティでチームをランク付けすることは、内部の競争を促進し、協力を阻害します。高い数値が良いことを示唆し、ポイントの誇張を促進します。
2. 目標の設定
マネジメントはしばしばベロシティの目標を設定しようとします。たとえば「スプリントごとに40ポイントを達成してほしい」というようなものです。これにより、記述的な指標が規定的な目標に変化します。ベロシティが目標になると、以下の行動が生じます：
- 見積もりの余裕を取る： チームメンバーが目標を達成するため、ストーリーポイントを誇張する可能性があります。
- 範囲の削減： チームが機能を小さな単位に分割して、数を意図的に増やそうとする可能性があります。
- 品質の犠牲： 価値の提供から数値を達成することへの焦点が移り、テストやドキュメントの作成を省略する可能性があります。
3. ステークホルダーへの日付予測
単一のスプリントのパフォーマンスに基づいて、ベロシティを使ってクライアントに特定のリリース日を約束するのは危険です。ベロシティは変動します。チームが休暇、欠勤、または予期せぬ技術的障害のためにスローなスプリントを経験することはあります。単一のデータポイントを使って日付を約束すると、現実的でない期待を生み出します。
4. 個人のパフォーマンスの測定
ベロシティはチームの指標です。それを個人のパフォーマンスに分解することは、スクラムの原則に違反します。アジャイルはクロスファンクショナルな協力に依存しています。開発者Aが5ポイントを完了し、開発者Bが8ポイントを完了したとしても、それらを比較することは、タスクの複雑さやそれらの間の依存関係を無視することになります。
✅ ベロシティの適切な活用
適切に使われると、ベロシティはチームの自己管理を支援します。それはハンマーではなく、鏡です。効果的に活用する方法を以下に示します。
1. スプリント計画
ベロシティの最も適切な使用法はスプリント計画です。過去3〜5回のスプリントの平均ベロシティを確認することで、次のスプリントにおける現実的な能力をチームは把握できます。
- 平均計算：直近の3〜5回のスプリントのポイントを合計し、スプリント回数で割る。
- コミットメント： チームは、合計の見積もりポイントがこの平均と一致するまでスプリントに作業を引き込む。
- バッファ： 中断や予期せぬ作業を考慮するため、平均より少し低めに計画することが賢明である。
2. リリース予測
ベロシティは、「製品はいつ完成するか？」という問いに答えるのに役立つ。残りの製品バックログのポイントを平均ベロシティで割ることで、作業を完了するために必要なスプリント回数を推定できる。
- 日付ではなく範囲で： 特定のカレンダーデートではなく、範囲（例：「スプリント10〜12の間」）で予測を提示する。
- ローリング更新： 新しい情報が得られたり、バックログが変更されたりするたびに、予測を定期的に更新する。
- 透明性： ステークホルダーと予測を共有し、範囲と時間の関係を理解してもらう。
3. テンダーの特定
時間とともにベロシティを追跡することで、チームやプロセス内の健全性を示す指標が明らかになる。
- 継続的な低下： 持続的な低下は、燃え尽き、技術的負債の増加、またはチーム構成の変化を示している可能性がある。
- 継続的な急上昇： 突然の増加は、以前の見積もりが保守的すぎたか、チームがより効率的なワークフローを見つけたことを示している可能性がある。
- 変動性： 高いばらつきは、プロセスまたは「完了の定義」に不安定さがあることを示唆する。
📉 ベロシティ vs. カパシティ
ベロシティとカパシティを区別することは非常に重要である。これらを混同すると、過剰なコミットメントにつながる。
- カパシティ： チームが作業に使える時間（時間単位）を指す。休暇、会議、サポート業務を含む。
- ベロシティ： 完了した作業量（ポイント）を指す。チームのスピードと効率を含む。
チームが高カパシティ（多くの利用可能時間）を持っているが、低ベロシティ（複雑さに苦しんでいる）である可能性がある。逆に、低カパシティ（多くの会議）だが高ベロシティ（高い効率）のチームも存在する。計画には両者のバランスが必要である。
| メトリクス | 測定単位 | 主な目的 | 誰が使うべきか |
|---|---|---|---|
| ベロシティ | ストーリーポイント | 予測と計画 | スクラムチーム |
| 能力 | 時間 | スケジューリングの可用性 | スクラムチームとスクラムマスター |
| バーンダウン | 時間／ポイント | 進捗の追跡 | ステークホルダーとチーム |
🧠 メトリクスの心理学
メトリクスは行動に影響を与えます。これは組織心理学の基本原則です。Xを測定すれば、人々はXに最適化しようとします。ベロシティが成功の主な指標になると、チームは価値ではなくベロシティに最適化するようになります。
心理的安全性
ベロシティが正確であるためには、チームが作業がブロッキングされているときや見積もりが間違っていたときにそれを認めても安全だと感じることが必要です。チームが低いベロシティが罰則につながると恐れている場合、彼らは：
- リスクを低く見積もる。
- 障害を隠す。
- 複雑なタスクを避ける。
これは進捗の錯覚を生みます。恐怖の文化の中で高いベロシティの数値は、効率の証ではなく、機能不全の兆候であることが多いです。
継続的改善
ベロシティはリトロスペクティブで議論されるべきですが、KPIとしてではなく、代わりにプロセスベロシティを生み出したプロセスについて議論する。
- なぜ今回のスプリントは通常よりも遅かったのか？
- 私たちにはあまりにも多くの中断があったのか？
- 完了の定義が厳しすぎたか、緩すぎたか？
プロセスに注目することで、チームは基盤となるシステムを改善し、それが自然に時間の経過とともにベロシティを安定化させる。
🔄 変動と異常の対応
すべてのスプリントが同じとは限らない。ベロシティの変動は通常であり、しばしば予想される。こうした変動が起こる理由を理解することが、データを正しく解釈する鍵である。
1. チームの変化
開発者が離脱したり、新しいメンバーが加わったりすると、ベロシティはおそらく変化する。新しいメンバーには習得の過程がある。タスクを完了するのに時間がかかるかもしれないし、予期しない形で貢献するかもしれない。過去の数値と即座に同等になることを期待してはならない。
2. スコープクリープ
ステークホルダーがスプリント途中で作業を追加すると、チームがコミットした項目に割く時間が減るため、ベロシティが低下する可能性がある。あるいは、チームが変更をうまく吸収できた場合、ベロシティは安定するかもしれないが、燃え尽きのリスクがある。変更を拒否するか、バックログに移動するのが望ましい。
3. テクニカルデット
テクニカルデットが蓄積すると、変更に必要な作業量が増えてしまうため、ベロシティはしばしば低下する。これはリファクタリングにスプリントを割り当てるべきというサインである。これを無視すると、パフォーマンスはゆっくりと低下する。
📊 まとめ：やるべきこととやらないこと
ベロシティが有用なツールのまま保つためには、以下のガイドラインに従うことが重要である。
| やること ✅ | やらないこと ❌ |
|---|---|
| 内部の計画にのみ使用する。 | チーム間の比較に使用する。 |
| 完了した作業に基づいて計算する。 | 部分的に完了した作業を数える。 |
| リトロスペクティブでトレンドを議論する。 | パフォーマンス目標として設定する。 |
| 相対的な見積もりに注目する。 | 時間や個人の生産性に注目する。 |
| 変動を当然のこととして受け入れる。 | ベロシティの低下を罰する。 |
| バックログを定期的に更新する。 | スコープを長期間固定する。 |
🚀 持続可能な成長のための最終的な考察
ベロシティは健全なシステムの副産物である。システムが健全であれば、ベロシティは安定する。システムが壊れているならば、ベロシティは激しく変動したり低下したりする。目標はベロシティを最大化することではなく、価値の提供を最大化することである。
リーダーシップがベロシティが生産性のエンジンではなく、計画上の制約であることを理解すると、状況は変わる。チームは証拠に基づいて自らのペースを設定できると感じ、ステークホルダーは約束ではなく範囲に基づいて期待を管理するようになる。焦点は、ユーザーの問題を解決する質の高いソフトウェアの提供に戻る。
メトリクスは検査と適応のためのツールであることを忘れないでください。それ自体が目的ではない。チームを会話の中心に置き、データが意思決定を支援するようにし、戦略は人間の判断が導くべきである。
🔍 よくある質問
速度は無限に増加することができるか？
いいえ。チームが受け入れられる作業量には、身体的および認知的な限界がある。複雑さが増すと、速度はしばしば横ばいまたは低下する。速度の継続的な増加は、生産性の向上ではなく、見積もり基準の緩みを示していることが多い。
ストーリーポイントを使わない場合はどうなるか？
速度は、時間から抽象化された点数としてのストーリーポイント以外にも、時間や理想日などの単位で計算できる。ただし、ストーリーポイントが好まれるのはその時間からの抽象化のためである。単位が何であれ、原則は同じである。過去のパフォーマンスと比較して完了した作業を測定する。
速度はバグを考慮に入れるか？
デフォルトの完了定義を満たす場合にのみ含まれる。バグ修正がバックログに追加された新しいタスクである場合、完了するとそのポイントは速度にカウントされる。すでに納品された作業の欠陥である場合は、通常、別個の事象として扱われる。
何回のスプリントを平均すればよいのか？
最低3回のスプリントで基準が得られる。5～10回のスプリントはより安定したトレンドラインを提供する。最新のデータを使用すべきである。それは現在のチームの状態と文脈を反映しているからである。
速度のニュアンスを尊重することで、チームは指標主導の管理の罠を避けられる。指標はチームのためにあるのではなく、逆ではない。この整合性が、予測可能性と品質が共に育つ環境を創出する。
