第18章 リリースプランニング（長期計画）
本章では、プロダクトのビジョン（第17章）を現実の開発スケジュールに落とし込み、「いつ、どのような機能群がリリースされるのか」を計画する「リリースプランニング」について解説します。
18.1 概要
Section titled “18.1 概要”リリースプランニングは、数週間から数ヶ月先のデリバリーに向けた計画を立てる活動です。
- 顧客やステークホルダーが持つ「いつ完成するのか？」「いくらかかるのか？」という問いに対して、現時点での最良の答えを提供する目的があります。
- スクラムにおいて、この計画は一度作って終わりの静的なものではなく、スプリントごとの学習（ベロシティの実績など）をもとに継続的に更新されていきます。
18.2 スクラムにおけるリリースプランニング
Section titled “18.2 スクラムにおけるリリースプランニング”スクラムのリリースプランニングは、以下の3つの変数のバランスを取る作業です。
- スコープ（Scope）: 顧客に提供するフィーチャー（機能）の量。
- 期日（Date）: リリースが行われるタイミング。
- 予算（Budget）: 開発にかかるコスト（主にチームの稼働時間）。
伝統的な開発ではこれらすべてを固定しようとして失敗しますが、スクラムではこれらを柔軟な変数として扱い、現実と向き合います。
18.3 期日固定リリースとスコープ固定リリース
Section titled “18.3 期日固定リリースとスコープ固定リリース”リリースプランニングには、主に2つのアプローチがあります。
期日固定（Fixed-Date）リリース
Section titled “期日固定（Fixed-Date）リリース”- 特徴: リリースする「日」が絶対に動かせないプロジェクトです（例：法改正の施行日、展示会への出展など）。
- 戦略: 時間が固定されているため、チームのベロシティに合わせて「スコープ（機能）」を調整（削減・変更）することで対応します。アジャイル開発と非常に相性が良いアプローチです。
スコープ固定（Fixed-Scope）リリース
Section titled “スコープ固定（Fixed-Scope）リリース”- 特徴: 特定の「機能セット」がすべて揃わないとリリースできないプロジェクトです（例：既存システムからの完全移行など）。
- 戦略: スコープが固定されているため、チームのベロシティに基づいて「期日」が変動（延期）することを受け入れる必要があります。
18.4 ベロシティの予測
Section titled “18.4 ベロシティの予測”リリースプランを立てるには、チームが1スプリントあたりどれだけの作業を消化できるか（ベロシティ）を知る必要があります。以下の3つの方法で予測します（上から推奨順）。
- 過去の実績データを使う: 同じチームが同じドメインで開発を続けている場合、過去数スプリントの平均ベロシティを使うのが最も正確です。
- 実際に数スプリント走ってみる: 新しいチームや新しい技術を使う場合、計画を立てる前にまず1〜3スプリントだけ実際に開発を行い、その実績値をベースに計画を立てます。
- 推測する: 過去のデータもなく、先に走ることも許されない場合の最終手段です。チームのキャパシティ（稼働可能時間）から大まかに推測しますが、不確実性が最も高くなります。
18.5 リリースプランの作成
Section titled “18.5 リリースプランの作成”見積もられたバックログと予測ベロシティが揃ったら、リリースプランを作成します。
- スプリントへのマッピング: プロダクトバックログの上位（優先順位が高い）アイテムから順に、チームの予測ベロシティの範囲内で各スプリントに割り当てていきます。
- リリースラインの描画: 「ここまでの機能を実装するには、約N回のスプリントが必要になる」という境界線（リリースライン）をバックログ上に引きます。
- 悲観的・楽観的な予測: ベロシティは一定ではないため、「平均ベロシティ」だけでなく、「低いベロシティが続いた場合」と「高いベロシティが出た場合」の幅（コーン・オブ・アンサーティンティ：不確実性のコーン）を持たせて計画を可視化することが推奨されます。
18.6 リリースプランの伝達
Section titled “18.6 リリースプランの伝達”リリースプランは、作って終わりではなく、関係者全員に進捗を透過的に共有し続ける必要があります。そのための強力な視覚化ツールとして、主に2つのチャートが用いられます。
リリースバーンダウンチャート
Section titled “リリースバーンダウンチャート”- 概要: 縦軸に「残りの作業量（ストーリーポイントなど）」、横軸に「スプリント（時間）」を取り、作業が減っていく（バーンダウンする）様子を示すグラフです。
- メリット: 「あとどれくらいで完了するか」が直感的にわかります。
- 弱点: スプリントの途中で新しい要件が追加された場合（スコープの拡大）、グラフの線が上に向かってしまうため、「チームの作業が遅れているのか」「要件が追加されたのか」を一目で区別しにくいという欠点があります（これを解決するために、横軸（ゼロのベースライン）を下げる特殊な描き方もあります）。
リリースバーンアップチャート（推奨）
Section titled “リリースバーンアップチャート（推奨）”- 概要: 縦軸に「作業量」、横軸に「スプリント」を取るのは同じですが、「チームが完了させた作業量の累積線（バーンアップ）」と「プロジェクトの総作業量（スコープ）の線」の2本の線を引くグラフです。
- メリット: スコープの変更が非常にわかりやすくなります。途中で要件が追加された場合、上部の「総作業量の線」が一段上がるため、チームの進捗（完了した作業の線）とは明確に分離して視覚化できます。
- スコープクリープの防波堤: 「なぜリリースが遅れているのか？」と問われた際、バーンアップチャートを見せれば「チームの進捗スピードは順調ですが、途中でこれだけ要件（総スコープ）が追加されたためです」と、客観的なデータに基づいてステークホルダーと冷静な対話ができます。
18.7 終わりに
Section titled “18.7 終わりに”リリースプランニングは、不確実な未来に対する「現時点での最良の予測」です。
- 計画は固定された契約ではなく、スプリントを重ねてチームの実際のベロシティが明らかになるにつれて、継続的に更新され、精度が高まっていくものです。
- スコープ、期日、予算のバランスを取りながら、バーンアップチャート等を用いて透明性を保つことで、ビジネス側と開発チームの健全な信頼関係を築くことができます。
次章（第19章）では、このリリースプランをさらに細かく分割し、目の前の1イテレーションの作業計画を立てる「スプリントプランニング」について詳しく掘り下げます。