フレームワーク活用ガイドひとことで言うと#
「いつ、何を、どの順番でリリースするか」をチームとステークホルダーで合意し、プロダクトの価値を段階的に届ける計画を立てる手法。スプリント計画の上位に位置する中長期の計画。
押さえておきたい用語#
- リリーステーマ（Release Theme）
- リリースの目的を表すビジネスゴールと紐づいたテーマのこと。「新規顧客獲得率20%向上」のように定量的に定義する。
- MoSCoW法（モスクワ法）
- フィーチャーをMust/Should/Could/Won’tの4段階で優先度分類する手法のこと。リリーススコープの決定に使う。
- バーンアップチャート（Burn-Up Chart）
- 完了ポイントの累積と全体スコープを時系列で可視化するグラフのこと。リリース予測の精度向上に役立つ。
- スコープ調整（Scope Negotiation）
- 日付固定ならスコープを、スコープ固定なら日付を柔軟に調整する意思決定のこと。両方固定は破綻の元。
リリースプランニングの全体像#
こんな悩みに効く#
- 「いつリリースできるのか」と聞かれても、明確に答えられない
- 機能を詰め込みすぎて、リリースが延々と延期される
- ステークホルダーごとに期待するリリース内容がバラバラ
基本の使い方#
このリリースで「顧客にどんな価値を届けるか」を明確にする。
- ビジネスゴールと紐づけたリリーステーマを設定する（例: 「新規顧客の獲得率を20%向上」）
- リリースの成功基準を定量的に定義する
- 対象ユーザーと主要なユースケースを明確にする
ポイント: 「全部入り」を目指さない。最も価値の高いテーマに絞ることがリリース成功のカギ。
リリースゴールを達成するために必要なフィーチャーを選び、優先順位をつける。
- バックログからリリーステーマに関連するフィーチャーを抽出する
- MoSCoW法（Must/Should/Could/Won’t）で優先度を分類する
- 各フィーチャーのストーリーポイントを見積もる
ポイント: Must（必須）だけでリリースを構成し、Should以下はバッファとして扱う。
チームのベロシティを使って、リリース日を予測する。
- 選定したフィーチャーの合計ポイントを算出する
- 平均ベロシティで割って、必要なスプリント数を計算する
- バッファ（20〜30%）を加算してリリース日を設定する
ポイント: 「日付固定」ならスコープを調整する。「スコープ固定」なら日付を調整する。両方固定は破綻の元。
スプリントの進行に合わせて、リリース計画を見直す。
- スプリントレビューごとにベロシティと残作業を更新する
- スコープ変更が発生したら、影響をリリース計画に反映する
- バーンアップチャートで全体の進捗を可視化する
ポイント: リリース計画は「一度作って終わり」ではない。生きたドキュメントとして更新し続ける。
具体例#
リリースゴール: 「ユーザーリテンション率を30%→45%に改善する」
フィーチャー選定:
| フィーチャー | 優先度 | ポイント |
|---|---|---|
| プッシュ通知のパーソナライズ | Must | 20pt |
| お気に入り機能 | Must | 13pt |
| SNS共有機能 | Should | 8pt |
| ダークモード対応 | Could | 5pt |
| 合計（Must） | — | 33pt |
| 合計（全体） | — | 46pt |
スケジュール:
- チームのベロシティ: 15pt/スプリント（2週間）
- Must完了に必要: 33pt / 15pt = 2.2スプリント
- バッファ30%込み: 約3スプリント（6週間）
- Should/Couldは余裕があれば含める
更新: Sprint 2終了時点でベロシティが14ptだったため、SNS共有機能をv2.1に延期決定。
結果: 6週間でMust機能を全て完了しリリース。リテンション率は42%に改善（目標の93%達成）。v2.1で追加したSNS共有機能により、さらに47%まで向上。
背景: エンタープライズ向けSaaSを開発する3チーム・25名。四半期ごとのリリースサイクル。顧客から「機能が多すぎて何が変わったかわからない」との声があり、テーマを絞ったリリースに転換。
Q3リリーステーマ: 「管理者のレポート作成時間を50%削減する」
フィーチャーとスケジュール:
| フィーチャー | 優先度 | ポイント | チーム |
|---|---|---|---|
| ダッシュボード自動生成 | Must | 40pt | A |
| カスタムレポートビルダー | Must | 55pt | B |
| データエクスポート強化 | Must | 20pt | C |
| レポートスケジューリング | Should | 30pt | A |
| AI要約機能 | Could | 45pt | B |
- 各チームのベロシティ: A=18pt、B=22pt、C=15pt（2週間スプリント）
- 6スプリント（12週間）でMust完了可能
- Shouldは2チームが早期完了した場合に着手
バーンアップチャートによる追跡: Sprint 3で全体進捗が計画の85%と若干遅延。チームBのカスタムレポートビルダーの複雑さが想定以上。Sprint 4でチームCがMust完了し、チームBの支援に回る。
結果: 12週間でMust+Shouldを全て完了。管理者のレポート作成時間は62%削減を達成し、顧客満足度（NPS）が+15ポイント向上した。
背景: 地方信用金庫（職員150名）がインターネットバンキングを新規導入。ベンダーへの外注開発。12ヶ月計画、予算6,000万円。金融庁の検査対応が必須。
リリース計画（3段階リリース）:
| リリース | 時期 | 内容 | 優先度 |
|---|---|---|---|
| R1（MVP） | 6ヶ月目 | 残高照会・入出金明細・振込（個人） | Must |
| R2 | 9ヶ月目 | 定期預金・ローン残高照会・通知機能 | Should |
| R3 | 12ヶ月目 | 法人向け機能・外貨預金・API連携 | Could |
ベロシティ管理: ベンダーとのスプリントレビューを隔週で実施。月次でバーンアップチャートをステアリングコミッティに報告。
スコープ調整: 8ヶ月目にマイナンバーカード認証への対応要求が発生。影響評価の結果、R3の法人向け機能をR4に延期し、認証機能をR3に組み込む決定。
| 指標 | 計画 | 実績 |
|---|---|---|
| R1リリース | 6ヶ月目 | 6ヶ月目（予定通り） |
| R2リリース | 9ヶ月目 | 9.5ヶ月目（2週間遅延） |
| R3リリース | 12ヶ月目 | 12ヶ月目（スコープ調整済み） |
| 利用者数（3ヶ月後） | 2,000名 | 2,800名 |
結果: R1のMVPを計画通りにリリースし、早期に利用者フィードバックを獲得。段階リリースにより金融庁検査への対応も各段階で確認でき、コンプライアンスリスクを最小化した。
やりがちな失敗パターン#
- スコープも日付も固定する — 両方を固定すると、品質か人の健康が犠牲になる。必ずどちらかに柔軟性を持たせる
- ベロシティを楽観的に見積もる — 「最高のスプリント」のベロシティで計算すると、ほぼ確実に遅れる。平均値の80%で計算するのが安全
- 計画を更新しない — 3ヶ月前の計画を根拠にリリース日を約束し続けると、直前で大幅遅延が発覚する。最低月1回は更新する
- Mustに機能を詰め込みすぎる — 「全部Must」にすると優先順位の意味がなくなる。Mustは全体の50%以下に抑え、残りはShouldとCouldに分類する
まとめ#
リリースプランニングは、プロダクトの価値をタイムリーに届けるための中長期計画手法。リリースゴールの定義、フィーチャーの優先順位づけ、ベロシティベースのスケジュール、そして定期的な更新が4つの柱。「全部入りを期日通りに」ではなく「最も価値の高いものを確実に届ける」のがアジャイルなリリース計画の考え方。