🎬 シナリオ
あなたはMOps（Marketing Ops/販促システム）チームのエンジニア3年目。ある月曜の朝会で、マーケティング本部長から急な相談が入った。
現状のトップページ「おすすめ商品」枠は、マーケティング担当者が週次で手動更新する全ユーザー共通表示になっている。新機能では、外部ベンダーのレコメンドAPI（自社初導入のサードパーティSaaS）を使い、ユーザーの閲覧・購買履歴に基づくパーソナライズ表示に切り替える。
分かっている情報:
- 体制: エンジニア2名（あなたともう1名）、デザイナー1名、マーケティング担当1名（要件定義）
- 外部ベンダーとの契約・API仕様のすり合わせはまだ着手していない（初取引）
- 表示内容が個人ごとに変わるため、CS部門への事前説明が必要（問い合わせ増加の懸念）
- 物流部門は基本関与しないが、在庫切れ商品をレコメンドしない連動が必要になった場合は関与
- 経営会議は月1回。90日以内に「ローンチ」を経営会議で報告する必要がある
- 本部長は「スピード重視」だが、あなたはエンジニアとして外部API依存・初回契約のリスクを感じている
このように企画（何を・なぜ作るか）→計画（どう分解して90日に収めるか）→リスク（何が計画を崩しうるか）→推進（誰とどう合意形成するか）を一気通貫で扱う必要がある場面が、統合カテゴリのテーマです。
📝 課題
あなたのタスク: 本部長への報告に向けて、以下4つの成果物を作成してください。
- 課題仮説キャンバス（1枚）: 「誰の・どんな課題を・なぜ今解くか」を明文化
- WBS（90日、フェーズ単位の作業パッケージ、15項目以上）
- リスク登録簿（上位5〜6件、確率×影響度、対応戦略つき）
- ステークホルダーマップ（影響力×関心度の4象限＋対応方針）
単に4つを別々に作るのではなく、リスク登録簿で洗い出した懸念がWBSのどこかに作業として反映されているか、ステークホルダーマップの「要注意」人物への対応がリスク登録簿と矛盾していないかなど、4点セットの整合性を意識してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 課題仮説は「パーソナライズ機能を作ること」自体を目的にしない。「なぜ今、このEC事業にとって必要か」まで掘り下げる
- WBSの中に「外部ベンダーとの契約・API仕様すり合わせ」「CS部門への説明」という、実装以外の作業パッケージを忘れずに入れる（100%ルール）
- リスク登録簿は技術リスクだけでなく、「初回契約のベンダーが遅延したら」「CSへの説明が漏れて問い合わせが殺到したら」という事業側のリスクも含める
- ステークホルダーマップでは、CS部門・物流部門のような「影響力は中程度だが事前調整を怠るとブロッカーになる」関係者の扱いを丁寧に考える
- 4点セットの整合性: リスク登録簿の「軽減策」がWBSの作業パッケージとして存在しているか、必ず後で見比べる
📚 背景知識・用語解説
課題仮説キャンバス: 「誰の（Who）・どんな課題を（Pain）・なぜ今解くか（Why now）・解決策の仮説（How）・成功の定義（Success）」を1枚にまとめたもの。機能要求よりも前段階で使い、「そもそもこの機能は作る価値があるか」を関係者と早期にすり合わせるために使います。
WBSとリスク登録簿の関係: WBSは「やることの分解」、リスク登録簿は「やる上での不確実性」です。優れたリスク対応策（軽減策）は、多くの場合WBSに新しい作業パッケージとして反映されます（例: 「ベンダー遅延リスク」への軽減策として「代替ベンダーの事前調査」という作業パッケージを追加する）。逆に言えば、リスク登録簿だけ作って対応策がWBSに反映されていないと、それは「言ったつもりで何もしていない」状態になります。
ステークホルダーマップと合意形成のタイミング: 影響力が高く関心度が低い人（例: 経営層）には「定期的に簡潔な報告」、影響力は中程度でも事前調整を怠るとブロッカーになる人（CS部門など）には「早期に巻き込む」という対応方針の違いが重要です。この判断を誤ると、後工程で「聞いていない」という手戻りが発生します。
✅ 模範解答
1. 課題仮説キャンバス
| 誰の課題か | トップページで「おすすめ商品」を閲覧するも、自分の興味と合わず離脱してしまうユーザー（特にリピーター層） |
|---|---|
| どんな課題か | 現状のレコメンド枠は全ユーザー共通表示のため、閲覧履歴・購買履歴と無関係な商品が並び、クリック率が低い（現状CTR 1.8%、業界平均は3%前後） |
| なぜ今解くか | 競合サイトがパーソナライズ導入後CVR+15%という情報があり、今期の売上目標達成に向けてトップページ経由の売上比率を高める必要がある。マーケティング担当の手動更新工数（週2時間）も削減できる |
| 解決策の仮説 | 外部レコメンドAPIを導入し、ユーザーごとの閲覧・購買履歴に基づく動的表示に切り替えれば、CTR・CVRが改善する |
| 成功の定義（初期仮説） | ローンチ後4週間でトップページ経由CTRが1.8%→2.5%以上、かつCS問い合わせ増加が許容範囲内（既存比+10%未満） |
| 検証されていない前提（要注意） | 「パーソナライズ表示がCS問い合わせを増やさない」という前提は未検証。表示内容が人によって異なることに対する違和感の声が出る可能性がある |
2. WBS（90日）
| コード | フェーズ / 作業パッケージ | 見積もり | 担当ロール |
|---|---|---|---|
| 1.0 | 企画・要件定義（Day 1-14） | ||
| 1.1 | 課題仮説のマーケ本部長レビュー・合意 | 2日 | エンジニア/マーケ |
| 1.2 | 表示要件・パーソナライズ条件のヒアリング | 3日 | マーケ/エンジニア |
| 1.3 | 外部ベンダー選定・見積もり取得（複数社比較） | 5日 | エンジニア |
| 1.4 | CS部門への事前説明・懸念ヒアリング | 2日 | エンジニア/CS |
| 2.0 | ベンダー契約・設計（Day 15-35） | ||
| 2.1 | ベンダーとの契約締結・NDA/データ提供範囲の確認 | 7日 | エンジニア/法務 |
| 2.2 | レコメンドAPI仕様の技術検証（レイテンシ・データ連携方式） | 5日 | エンジニア |
| 2.3 | ユーザー行動データ連携基盤の設計（既存ログ基盤からの連携） | 5日 | エンジニア |
| 2.4 | 表示UI/UXデザイン（パーソナライズ枠のワイヤーフレーム） | 4日 | デザイナー |
| 3.0 | 実装（Day 36-63） | ||
| 3.1 | ユーザー行動データ連携バッチ・API実装 | 8日 | エンジニア |
| 3.2 | レコメンドAPI呼び出し・キャッシュ層の実装 | 6日 | エンジニア |
| 3.3 | トップページ表示コンポーネントの実装 | 5日 | エンジニア/デザイナー |
| 3.4 | 在庫切れ商品の除外ロジック実装 | 3日 | エンジニア |
| 3.5 | フォールバック処理（API障害時は従来の共通表示に切替） | 3日 | エンジニア |
| 4.0 | テスト・社内合意形成（Day 64-77） | ||
| 4.1 | 単体・結合テスト | 4日 | エンジニア |
| 4.2 | パーソナライズ精度の社内検証（ダミーユーザーでの表示確認） | 3日 | マーケ/エンジニア |
| 4.3 | CS向けFAQ・問い合わせ対応フローの整備 | 3日 | CS/エンジニア |
| 4.4 | 経営会議向け進捗報告（Go/No-Go一次判定） | 1日 | エンジニア/マーケ |
| 5.0 | 段階リリース（Day 78-90） | ||
| 5.1 | 社内ユーザーのみへの先行公開（ドッグフーディング） | 3日 | エンジニア |
| 5.2 | 10%ユーザーへの段階公開・CTRモニタリング | 4日 | エンジニア/マーケ |
| 5.3 | 全ユーザー展開・ローンチ報告資料の作成 | 3日 | エンジニア/マーケ |
合計見積もり: 約76人日相当（体制4名の並行作業・ベンダー待ち期間を含めて90日に収める前提）
3. リスク登録簿
| # | リスク内容 | 確率 | 影響度 | スコア | 対応戦略 | 具体的な対応策（WBSとの対応） | オーナー |
|---|---|---|---|---|---|---|---|
| R1 | 初取引の外部ベンダーとの契約締結が想定より長引く（法務レビュー・NDA調整） | 高 | 高 | 最優先 | 軽減 | 契約交渉と並行して技術検証(2.2)を先行着手し、契約完了を待たずに検証可能な範囲を進める。候補ベンダーを1社に絞らず2社と並行交渉(1.3) | エンジニア(あなた) |
| R2 | パーソナライズ表示に対するCS問い合わせが想定以上に増加する | 中 | 中 | 中 | 軽減 | 4.3でFAQ・対応フローを事前整備。5.2の段階公開で問い合わせ量を事前に観測してから全展開する | CS部門 |
| R3 | レコメンドAPIのレイテンシがトップページ表示速度を悪化させる | 中 | 高 | 高 | 軽減 | 2.2で技術検証を実施。3.2でキャッシュ層を設け、API応答が遅い場合のタイムアウト・フォールバック(3.5)を必須要件にする | エンジニア |
| R4 | ユーザー行動データの外部API連携が個人情報保護方針に抵触する | 低 | 高 | 中 | 回避/転嫁 | 2.1の契約時にデータ提供範囲を法務レビューで確定し、提供するのは匿名化済みの行動ID単位に限定する | 法務/エンジニア |
| R5 | マーケティング担当の要件定義が曖昧なまま実装に着手し、手戻りが発生する | 中 | 中 | 中 | 軽減 | 1.2のヒアリングを課題仮説キャンバスの「成功の定義」と紐づけて具体化し、2.4のワイヤーフレーム承認をゲートにする | マーケ/エンジニア |
| R6 | レコメンドAPI障害時にトップページ全体が表示不能になる | 低 | 高 | 中 | 軽減 | 3.5のフォールバック処理を必須要件として最初から実装スコープに含める（後付けにしない） | エンジニア |
4. ステークホルダーマップ（影響力 × 関心度）
重点管理（影響力高×関心度高）
マーケティング本部長（発注元・意思決定者）
外部ベンダー担当（契約〜稼働まで密なやり取り）
要早期巻き込み（影響力中×関心度高）
CS部門長（事前説明必須。巻き込みが遅れるとR2が現実化しブロッカー化）
満足維持・簡潔な報告（影響力高×関心度低）
経営会議（月1回1ページ報告のみ）
法務部門（契約時レビューのみ）
最小限の関与（影響力低×関心度低）
物流部門（在庫連動(3.4)が発生する場合のみ関与）
| 象限 | 該当者 | 対応方針 |
|---|---|---|
| 重点管理 | マーケティング本部長、外部ベンダー担当 | 週次の進捗共有、意思決定が必要な論点は早めにエスカレーション |
| 要早期巻き込み | CS部門長 | WBS 1.4で企画初期から巻き込み、4.3で対応フローを一緒に整備。後回しにすると「聞いていない」でブロッカー化するリスク（R2）が現実化する |
| 満足維持・簡潔な報告 | 経営会議、法務部門 | 経営会議には月次の1ページサマリーのみ。法務は2.1の契約レビュー時にピンポイントで関与を依頼する |
| 最小限の関与 | 物流部門 | 在庫連動（3.4）が必要になった時点で初めて仕様確認の連絡をする。現時点で巻き込みすぎるとお互いの工数を無駄にする |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 4つの成果物をそれぞれ独立して作り、内容の整合性を見比べない | リスク登録簿で「軽減する」と書いた対応策がWBSに存在せず、報告資料としては立派でも実行計画になっていない | 成果物を作り終えた後、「このリスクの対応策はWBSのどの作業パッケージに対応するか」を1つずつ突き合わせる |
| ステークホルダーマップを影響力の大小だけで機械的に4象限に配置する | CS部門のように「影響力は中程度だが、巻き込みが遅れるとブロッカーになる」関係者を軽視し、後工程で手戻りが発生する | 「今の影響力」だけでなく「巻き込みが遅れた場合に何が起きるか」を併せて検討する |
| 課題仮説を「作りたい機能の説明」で終わらせる | 「なぜ今このEC事業にとって必要か」が抜けると、途中で優先順位が下がった際に説得力のある反論ができない | 事業側の数値（現状CTR、競合の実績、売上目標との関係）まで踏み込んで書く |
| WBSに実装作業だけを並べ、契約・社内調整・段階公開といった非実装作業を抜かす | 100%ルール違反。終盤になって「ベンダー契約がまだ終わっていない」と気づき、90日という期限そのものが崩れる | フェーズを立てる段階で「実装以外に何が必要か」（契約、社内説明、段階リリース）を先に洗い出す |
🏆 実務での使いどころ
このような「企画・計画・リスク・推進」を横断する統合的な整理は、新機能や新規プロジェクトのキックオフ直後、特に経営層やマーケティング部門など非エンジニアの意思決定者に「進め方の全体像」を説明する場面で頻繁に求められます。エンジニアであっても、こうした4点セットを自分で組み立てられると、「言われたものを作る人」から「プロジェクトの進め方そのものを設計できる人」へと信頼が変わります。特に外部ベンダーが絡む案件では、技術的な実現性だけでなく契約・法務・CS対応といった非技術的な作業がボトルネックになることが多く、エンジニア自身がこれらをWBS・リスク登録簿に織り込めるかどうかが、テックリード・EMとしての評価に直結します。
🚀 次のステップ
来週は各カテゴリ（PM-計画/PM-リスク/PdM-要求/PdM-優先順位/PM-推進/PdM-リサーチ）を曜日ごとに個別に深掘りしていきます。今日作成したWBS・リスク登録簿・ステークホルダーマップは、それぞれ月曜（WBS基礎の深掘り）・火曜（リスク特定手法の深掘り）・金曜（ステークホルダーマップの深掘り）で再登場する題材の原型になります。次回の統合回（来週日曜）では、今週個別に深掘りした内容を踏まえて、今日よりも一段階複雑な複合ケース（例: 炎上プロジェクトの立て直し）に取り組みます。