🎬 シナリオ
あなたはMOps（Marketing Ops/販促システム）チームのエンジニア3年目。6週間計画で進めていた「季節送料無料バナー」実装プロジェクトが、5週目の水曜になって炎上状態になっていることに気づいた。
体制: エンジニア2名（あなたと相方）、デザイナー1名、マーケティング担当1名（兼務）。当初WBSでは実装フェーズは3週目末に完了し、4〜6週目はテスト・段階公開に充てる計画だった。
現状を整理すると、次のことが起きている:
- 実装フェーズが5週目時点でもまだ完了していない（2週間相当の遅延）
- 原因1: 当初スコープは「送料無料バナー表示のみ」だったが、マーケ担当から口頭で「ついでにクーポン組み合わせ表示も」「モバイルアプリとの表示統一も」という要望が段階的に入り、正式な優先順位の合意なしになし崩し的に実装へ着手していた
- 原因2: 相方のエンジニアが3週目に他チームの障害対応へ2日間、その後さらに別チームの緊急案件へ丸1週間応援に駆り出された
- 原因3: 要件がふらついたことで、実装済み部分の手戻りが2回発生した
- 直近2スプリントの実績ベロシティが計画を大きく下回っている（計画18pt→実績11pt、計画16pt→実績9pt）
- 上長はすでに2週間後の経営会議で「予定通りローンチ」と報告してしまっている
- 当初のリスク登録簿には「表示切替時にCS問い合わせが増える懸念」がありFAQ整備のタスクも計画には存在したが、実装の遅れのあおりで後回しにされたまま未着手
- 「在庫切れ商品をレコメンドから除外する連動ロジック」も優先度が低いと判断されたまま着手できていない
今日、チームリーダーから「状況を整理してリカバリー案を出してほしい。経営会議までに現実的な着地点を決めたい」と依頼された。
📝 課題
あなたのタスク: 経営会議に向けて、以下4つの成果物を作成してください。
- リスク登録簿（更新版）: 当初のリスク登録簿を復元しつつ、どのリスクが顕在化したか・新たに判明したリスクは何かを反映する
- PRDスコープ再定義（MoSCoW）: 追加要望も含めた全機能をMust/Should/Could/Won'tに再仕分けし、Non-Goals（今回は対象外とする理由）を明記する
- リカバリーWBS: 残り2週間、Mustスコープのみを対象に作業パッケージを再構築する
- リカバリースプリント計画: 残り2スプリント分、直近の実績ベロシティを踏まえて現実的な積み込み量を判断する
単に4点をバラバラに作るのではなく、リスク登録簿で「顕在化」とマークしたリスクへの対応がWBS・スプリント計画に反映されているか、MoSCoWでWon'tにした機能がWBSから正しく除外されているかの整合性を意識してください。また、この状況では「スコープを削る」「納期を延ばす」「人員を増やす」という複数の選択肢がありえます。単一の正解はありません。どれか一つを選び、選ばなかった選択肢がなぜ今回は劣後するかも明記してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- リスク登録簿の更新は「新しく全部作り直す」のではなく、当初リスクのうち何が実際に起きたか（顕在化）・起きていないか、を区別することが目的。顕在化したリスクは対応戦略を"予防"から"対処"に切り替える必要がある
- 「上長が経営会議で先に予定通りと報告してしまった」ことも、技術的なリスクではないが無視できない事実。これも登録簿に加える
- MoSCoWでWon't（今回はやらない）と判断する機能には、必ず「なぜ今回はやらないか」の理由を書く。理由がないと「後で言った言わないの対立」になる
- リカバリーWBS・スプリント計画は、当初のベロシティ計画ではなく直近の実績ベロシティを基準にする。希望的観測でスケジュールを組むと同じ失敗を繰り返す
- スコープ削減・納期延長・増員のどれを選ぶにせよ、選ばなかった案の欠点も1〜2行で示すと、報告時に「他の案は検討したのか」という質問に即答できる
📚 背景知識・用語解説
リスクの「顕在化」と課題管理の違い（PM-リスクの復習）: リスク登録簿に載っていた「まだ起きていないこと」が実際に起きたら、それはもう課題（Issue）です。リスク登録簿を更新するときは、単に削除するのではなく「このリスクは顕在化し、こういう影響が出た」と記録を残すことで、次のプロジェクトのリスク特定チェックリストの材料になります。
スコープクリープと「なし崩し合意」: 今回の炎上の根本原因は、追加要望自体ではなく「正式な優先順位付けの合意なしに着手したこと」です。口頭での「ついでにこれも」を都度リスト化・MoSCoWで再評価するプロセスを挟んでいれば、着手前に工数超過に気づけました。PdM-優先順位の実務では、バックログに乗った瞬間に優先順位を判断する仕組みがスコープクリープの予防策になります。
実績ベロシティで計画し直す理由: 計画時のベロシティ見積もりは、あくまで「開始前の期待値」です。プロジェクトが進行し実績データが取れたら、以後の計画は実績値を基準にするのが原則です（PM-推進の「進捗可視化」と同じ考え方）。ここで希望的観測（「次スプリントから本来のペースに戻るはず」）に頼ると、リカバリー計画自体が二度目の"予定通りローンチ"という嘘になります。
Non-Goalsを明記する意味（PdM-要求の復習）: 「Won't」にした機能は、単にバックログから消すのではなく、PRDに「今回はやらない」と明記することで、後から「あの機能はどうなった」と聞かれたときに一貫した説明ができます。特に今回のように要望がなし崩し的に増えたプロジェクトでは、Non-Goalsの明文化がスコープクリープの再発防止策そのものになります。
✅ 模範解答
1. リスク登録簿（更新版）
| # | リスク内容（当初の想定） | 当初評価 | 現在の状態 | 更新後の対応 | オーナー |
|---|---|---|---|---|---|
| R1 | マーケ要求が実装中に膨らみ、スコープが曖昧なまま進行する | 中×中 | 顕在化（クーポン表示・アプリ統一の2要望が正式合意なく着手された） | 予防策（早期の要件固め）は手遅れ。対処として、全要望をMoSCoWで再仕分けし、着手済みでもWon't判定した部分は実装ごと巻き戻す（本PRD参照） | あなた |
| R2 | チームメンバーが他案件へ引き抜かれ、稼働が計画を下回る | 低×高 | 顕在化（相方が計8日間離脱、直近2スプリントの実績ベロシティが計画比 61%・56%） | 予防は不可（他チーム都合のため）。対処として、残り2週間は実績ベロシティ（平均10pt）を基準に再計画し、絶対に希望的観測で積み込まない | あなた |
| R3 | 表示切替に伴うCS問い合わせの増加 | 中×中 | 未顕在化だが兆候あり（FAQ整備タスクが未着手のまま残っている） | 軽減策を維持しつつ、リカバリーWBSでFAQ整備をMustとして最優先着手に格上げ（他タスクより先に着手） | エンジニア/CS |
| R4 | 在庫切れ商品との連動ロジックの実装漏れ | 中×低 | 未顕在化（優先度判断により未着手のまま） | MoSCoWでWon't（Non-Goals）に確定。次回リリースへ持ち越しをPRDに明記し、リスクとしてはクローズ | マーケ/エンジニア |
| R5（新規） | 上長が経営会議で「予定通りローンチ」とすでに報告済み | ― | 新規発生・進行中（報告と実態の乖離） | 技術リスクではないが最優先の組織リスク。経営会議より前に、上長へ実績ベロシティに基づく現実的な着地点（後述のスコープ・納期）を先に共有し、報告内容の訂正を依頼する | あなた/リーダー |
| R6（新規） | モバイルアプリとの表示統一は、見積もりなしに要望だけが先行していた | ― | 新規発見（アプリ側の改修工数が未見積もりのままバックログに乗っていた） | MoSCoWでCould（今回は対象外）に確定。アプリ側エンジニアと工数を見積もった上で次サイクルで再検討する | エンジニア |
2. PRDスコープ再定義（MoSCoW）
| 分類 | 機能・要望 | 判断理由 |
|---|---|---|
| Must | 送料無料バナー表示（PC/モバイルブラウザ、当初スコープ） | プロジェクトの本来の目的そのもの。これが出ないと今回のリリースに意味がない |
| Must | CS向けFAQ・問い合わせ対応フローの整備 | R3が兆候段階にある。表示バナーだけ出してFAQが無いと、問い合わせ増という既知のリスクを放置したままローンチすることになる |
| Must | 表示エラー時のフォールバック（非表示に戻す） | バナー表示ロジックに不具合があった場合、トップページ全体が壊れるのを防ぐ最低限の保険 |
| Should | クーポン組み合わせ表示（マーケからの追加要望） | 事業的な価値はあるが、実装済みの一部を除き大部分が未着手。残り2週間のMustを優先し、Mustが確実に収まった場合のみ着手を検討する枠として残す |
| Could | モバイルアプリとの表示統一 | R6の通り工数未見積もり。今回のスコープには入れず、アプリ側と正式に工数合意した上で次サイクルで扱う |
| Won't（Non-Goals） | 在庫切れ商品との連動除外ロジック | 表示価値への影響が小さく（在庫切れは全体の3%未満）、実装コストに見合わない。次回リリースへ明示的に持ち越す |
| Won't（Non-Goals） | クーポン組み合わせ表示の高度な条件分岐（併用不可条件の自動判定等） | Should化したクーポン表示の中でも特に複雑な部分。今回は「単純な複数クーポン併記」までとし、条件判定ロジックは対象外とする |
3. リカバリーWBS（残り2週間・Mustスコープのみ）
| コード | 作業パッケージ | 見積もり | 担当 | 備考 |
|---|---|---|---|---|
| R.1 | クーポン組み合わせ表示（着手済み分）の実装を凍結し、Mustスコープへ影響しないよう分離 | 0.5日 | エンジニア | 巻き戻しではなくコード上で無効化し、Should着手時に再利用できる状態にする |
| R.2 | CS向けFAQ・問い合わせ対応フローの整備（最優先着手） | 2日 | エンジニア/CS | R3の兆候対応。他タスクより先に着手する |
| R.3 | 送料無料バナー表示ロジックの実装完了（残作業） | 4日 | エンジニア | 手戻り2回分の影響を踏まえ、実績ベースで見積もり直した日数 |
| R.4 | 表示エラー時のフォールバック実装 | 1日 | エンジニア | Mustとして必須スコープに含める（後付けにしない） |
| R.5 | 単体・結合テスト | 2日 | エンジニア | R.3完了後に着手 |
| R.6 | 社内ドッグフーディング・表示確認 | 1日 | エンジニア/マーケ | |
| R.7 | 経営会議向け報告資料の作成（実績ベロシティ・スコープ判断の説明を含む） | 1日 | あなた/リーダー | 経営会議の3日前までに上長へ内容共有（R5への対応） |
合計: 約11.5人日（残り2週間＝実働10営業日に対し、2名体制での並行作業を前提に収まる計算。ただしバッファはほぼゼロのため、新たな割り込みが発生した場合は即座にリーダーへエスカレーションする運用とする）
4. リカバリースプリント計画（残り2スプリント）
| 直近2スプリントの実績ベロシティ | 11pt、9pt（平均10pt。計画値18pt・16ptに対し56〜61%） |
|---|---|
| 残り2スプリントの積み込み方針 | 実績平均の10ptを上限とし、計画値には戻さない（希望的観測を排除） |
| Sprint N（今週）の積み込み | R.1（凍結作業）＋R.2（FAQ整備）＋R.3の一部 = 見積もり相当 9pt。CS部門との調整が必要なR.2を最優先で着手し、後半でR.3に着手 |
| Sprint N+1（来週） | R.3の残り＋R.4＋R.5＋R.6 = 見積もり相当 10pt。R.3完了を待たないと着手できないR.5があるため、Sprint N終盤の進捗次第でR.6を翌週送りにする判断を事前にリーダーと合意しておく |
| Should（クーポン表示）の扱い | 2スプリントのバッファに一切含めない。Mustが計画通り収まった場合のみ、経営会議後の3週目に着手を検討する |
| 実績と計画の乖離が出た場合の運用 | 日次で残タスクの消化状況を確認し、R.2・R.4（Must中のMust）が2日以上遅れた場合は即座にリーダーへエスカレーションし、Mustのさらなる絞り込みを検討する |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 遅延が発覚した際、リスク登録簿を見直さずにいきなりスケジュールだけ再作成する | 何が原因で計画が崩れたかの記録が残らず、次のプロジェクトで同じ失敗（要件の口頭合意、他チームへの引き抜き）を繰り返す | リスク登録簿の更新を必ず最初のステップにし、「当初の想定と何が違ったか」を先に言語化する |
| リカバリー計画を立てる際、計画時のベロシティのまま「取り戻す」前提で積み込む | 二度目の「予定通り」報告になり、経営会議で再び計画未達を報告する事態を招く | 直近の実績値のみを根拠にし、計画値に戻る合理的な理由がない限り希望的観測を排除する |
| Won't（対象外）にした機能をPRDに明記せず、口頭やSlackのやり取りだけで済ませる | 後日マーケ担当から「あの機能はいつ出るのか」と聞かれた際に、判断根拠を示せず信頼を損なう | Non-Goalsとして文書に残し、判断理由（工数・優先度）を添える |
| 「スコープを削る」「納期を延ばす」「増員する」のうち1つだけを検討し、他の選択肢を報告資料に書かない | 経営層やリーダーから「他の案は検討したのか」と聞かれた際に即答できず、判断の信頼性が下がる | 選ばなかった選択肢とその欠点を1〜2行でよいので明記しておく |
🏆 実務での使いどころ
炎上プロジェクトの立て直しは、新規立ち上げよりも実務での発生頻度が高い局面です。特にエンジニアからテックリード・EMへのキャリアパスでは、「計画通りに進める力」以上に「計画が崩れたときに、感情論ではなく事実（実績ベロシティ、顕在化したリスク）を根拠に現実的な着地点を再設計する力」が評価されます。今回のように「上長がすでに予定通りと報告してしまっている」状況は実務でも頻発し、技術的な対処と並行して上長・経営層とのコミュニケーションの立て直しも同時に行う必要がある点が、新規立ち上げのケースとの大きな違いです。この「事実ベースでの再計画」ができるかどうかが、炎上プロジェクトの火消し役を任せられる人材かどうかの分かれ目になります。
🚀 次のステップ
来週も引き続き各カテゴリを曜日ごとに深掘りしていきます（PM-計画は見積もり手法、PM-リスクはリスク登録簿の書き方、PdM-要求はユーザーストーリー、PdM-優先順位はValue vs Effortマトリクス、PM-推進は進捗可視化、PdM-リサーチはJTBDへと進む想定）。次回の統合回（来週日曜）では、今回とは異なる切り口（例: 指標悪化した既存機能のKill判断、複数プロジェクト間でのリソース競合の調整）を扱い、単一の正解がない意思決定に繰り返し取り組みます。