🎬 シナリオ
あなたはMOps（Marketing Ops/販促システム）チームのエンジニア3年目。9月最初の月曜朝、チームリーダーから声をかけられた。
MOpsチームのエンジニア体制は5名（あなた、B・C・D、リードエンジニアのAさん）。現在、次の4つの案件が同時並行で走っている、または着手を求められている。
P1. 検索キーワードサジェスト機能（先週プランニングしたSprint 23が進行中）
- 体制: Aさん（50%稼働）＋B＋C
- Aさんは全社検索基盤刷新PJへ今後2スプリント（Sprint 23・24、9/7〜10/2の4週間）50%兼務中
- 4週間で目標ベロシティ34pt/2週×2スプリント、換算工数はおよそ50人日
- すでに投資が進んでおり、中断すればコンテキストスイッチとスプリントの手戻りコストが大きい
P2. 誕生日月限定クーポン自動発行機能（先々週リスク登録簿を作成、これから実装フェーズ）
- マーケティング本部長からの要求: 「12月生まれ会員への配信を年内に間に合わせたいので、11月1日のバッチ本稼働に絶対間に合わせてほしい」（12月生まれ会員という顧客属性起点の自然な締切であり、逃すと来年まで1年分の機会損失になる）
- 見積もり: エンジニア2名×3週間、換算工数30人日
- リスク登録簿で洗い出したR9（有効期限の月末計算バグ）は未解消のまま実装フェーズに入る
P3. 値下げ通知機能（先々々週WBSを作成し、すでに本番リリース済み）
- 本番稼働後の安定化フェーズで、「1日上限＋ダイジェスト切替」ロジックに想定外の不具合（重複通知）が発生
- 直近1週間でCS問い合わせが37件（平常時の約5倍）と実害が出ている
- 緊急対応: エンジニア1名×2週間、換算工数10人日、今すぐ着手が必要
P4. 店舗連携デジタル会員証機能の改善（先週リサーチした「非利用率88%」の原因仮説がまだ検証されていない）
- リサーチで浮上した仮説「レジでの提示手順の分かりにくさ」はまだ裏付けが取れていない段階
- 店舗連携推進室長からの要求: 「来期の店舗拡大計画に直結するので、年内（12月末）までに改善を入れたい」
- 見積もり: エンジニア2名×2週間、換算工数20人日
チームの供給キャパシティ（9/7〜10/4の4週間）
- あなた・B・C・D: 4名×5人日/週×4週間 = 80人日
- Aさん（リード）: 50%稼働×5人日/週×4週間 = 10人日
- 合計供給: 90人日
📝 課題
あなたのタスク: チームリーダーへの報告に向けて、以下4つの成果物を作成してください。
- リソース需要マップ: 4案件の需要（工数・期限の性質・遅延時の影響）と、チームの週次供給キャパシティを対比し、どこでどれだけ競合が起きているかを可視化する
- 優先順位判定表: 4案件を客観的な基準で比較し、優先順位を決定する。特に、マーケティング本部長と店舗連携推進室長という発言力が拮抗する2人がそれぞれ別案件を「最優先」と主張している状況を、どう裁定するかを明記する
- 再配分後の統合スケジュール: 5名のメンバーを4週間×週単位でどの案件に割り当てるか、実行可能な配分表を作る。理論値（110人日の需要）を供給（90人日）に収めるために、どの案件をどう調整したかを明示する
- リスク登録簿＋ステークホルダー合意形成レポート: 再配分によって新たに生まれるリスク（オーバーコミット、レビュー不足など）を洗い出し、関係部門への説明資料をまとめる
単に4点をバラバラに作るのではなく、優先順位判定表の結論が再配分スケジュールにそのまま反映されているか、リスク登録簿で洗い出したリスクが、既存のリスク登録簿（P2のR9など）と矛盾なくつながっているかの整合性を意識してください。また、選ばなかった判断（例: 店舗連携デジタル会員証の改善を今すぐ最優先にする、という判断）がなぜ劣後するかも明記し、唯一の正解ではなくトレードオフのある意思決定であることを残してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- リソース需要マップは「工数の大小」だけで並べても優先順位は決まらない。「今すぐ着手しないと実害が拡大する案件」「動かせない外部締切がある案件」「すでに投資済みで中断コストが高い案件」「まだ仮説段階で検証が済んでいない案件」は、それぞれ性質が違う
- 発言力が拮抗する2人のステークホルダーが対立する要求を出してきた場合、「声の大きさ」や「役職の上下」で決めると禍根が残る。Day019（MoSCoW法）で扱った「要望が実績データに基づくか、未検証の仮説か」という基準がここでも使える
- 需要110人日を供給90人日に収めるには、「全部を少しずつ削る」のではなく、「1つの案件をはっきり後ろ倒しにする」方が実行可能性が高い。中途半端にどの案件も薄く配分すると、どの案件も期限に間に合わなくなる
- 再配分スケジュールを作るときは、リードエンジニア（希少スキル）がどの案件のどのタイミングに必要かを最初に固定してから、他のメンバーを埋める順番で組むとうまくいく
- リスク登録簿は「新しいリスクを発見すること」だけでなく、「既存のリスク登録簿に書かれていたリスクが、今回のリソース再配分によって発生確率が変わっていないか」を確認することも重要
📚 背景知識・用語解説
なぜリソース競合は「声の大きさ」で解決してはいけないか（PM-推進・PdM-優先順位の復習）: 複数の部門が同時に「自分の案件を最優先にしてほしい」と要求してくる場面は、実務では日常的に発生します。ここで役職の上下や発言の強さで優先順位を決めてしまうと、次回以降「強く言った者勝ち」という学習が組織に蓄積し、本当に優先すべき案件が通らなくなります。今回のように、マーケティング本部長と店舗連携推進室長という対等な発言力を持つ2人が対立する要求を出す場面では、両者の役職とは独立した客観的基準（実害の有無、外部締切の動かしにくさ、検証状態など）で裁定し、その基準自体を両者に説明できるようにしておく必要があります。
「まだ仮説段階」の案件に工数を先出ししてはいけない理由（PdM-リサーチとの接続）: 先週のPdM-リサーチで扱った店舗連携デジタル会員証機能の非利用調査は、まだインタビューを設計した段階であり、「レジでの提示手順が分かりにくい」という原因はまだ検証されていない仮説にすぎません。この仮説がもし外れていた場合、2名×2週間＝20人日のエンジニア投資はまったく無駄になります。検証されていない仮説に先に重い投資をするのではなく、まず安価な検証（この場合はエンジニアの手をほぼ借りない軽量な施策）で仮説の裏付けを取ってから、本格的な改修に工数を投じる、という順序が合理的です。
リソース配分計画にゼロバッファはなぜ危険か（PM-計画・PM-リスクの復習）: 需要と供給がぴったり一致する配分（今回は90人日=90人日）は、一見「無駄なく計画できた」ように見えますが、実際には誰か1人が1日でも計画外の作業（体調不良、他チームからの緊急支援要請など）に時間を取られた瞬間に、計画全体が破綻するという意味でもあります。PM-計画で学んだ「予備費・コンティンジェンシー」の考え方は、人日ベースのリソース配分でも同様に当てはまり、バッファがゼロの計画には「バッファが切れたときにどの案件から犠牲にするか」を事前に決めておく必要があります。
既存のリスク登録簿との接続を確認する重要性（PM-リスクの復習）: 先々週P2（誕生日クーポン機能）のリスク登録簿で洗い出した「R9: 有効期限の月末計算バグ」は、当時は一般的な実装リスクとして記録されていました。しかし今回のリソース再配分によって、「このロジックを設計する担当者が、リードエンジニアのレビューをほぼ受けられない期間に単独で作業する」という新しい状況が生まれると、R9の発生確率そのものが上昇します。リスクは一度登録して終わりではなく、状況（今回はリソース配分）が変わるたびに再評価する必要があります。
✅ 模範解答
1. リソース需要マップ
案件別の需要と性質
| 案件 | 状態 | 必要工数 | 期限の性質 | 遅延・未着手時の影響 |
|---|---|---|---|---|
| P1: 検索キーワードサジェスト | 進行中（Sprint23実行中） | 50人日 | 内部目標（10月末リリース希望）だが、中断コストが最も高い | スプリント中断によるベロシティ毀損、リードの専門知識が絡む設計判断が宙に浮く |
| P2: 誕生日月限定クーポン | 未着手（リスク登録簿完了済み） | 30人日 | 外部要因の締切（12月生まれ会員への配信、11/1稼働厳守） | 逃すと来年まで1年分の機会損失、マーケ本部の年間販促計画にも影響 |
| P3: 値下げ通知の緊急安定化 | 進行中（本番不具合対応） | 10人日 | 現在進行形の実害（CS問い合わせ37件/週、平常比5倍） | 問い合わせがさらに増加、ユーザー体験の毀損が拡大し続ける |
| P4: 店舗連携デジタル会員証改善 | 未着手（原因は未検証の仮説） | 20人日 | 内部目標（年内）だが根拠は仮説段階 | 仮説が外れていた場合、投資が無駄になるリスクを抱えたまま着手することになる |
チームの週次供給キャパシティ（9/7〜10/4、4週間）
| メンバー | 稼働率 | 週あたり供給 | 4週間供給 | 備考 |
|---|---|---|---|---|
| あなた | 100% | 5人日 | 20人日 | |
| Bさん | 100% | 5人日 | 20人日 | |
| Cさん | 100% | 5人日 | 20人日 | |
| Dさん | 100% | 5人日 | 20人日 | |
| Aさん（リード） | 50%（全社検索基盤刷新PJへ50%兼務、Sprint23・24の2スプリント継続） | 2.5人日 | 10人日 | アーキテクチャ判断・高リスクコードレビューができるのは実質Aさんのみ |
| 合計 | 22.5人日/週 ／ 90人日 | |||
競合の可視化
| 需要 | 供給 | 差分 | |
|---|---|---|---|
| 4週間合計 | 110人日（P1:50+P2:30+P3:10+P4:20） | 90人日 | ▲20人日の超過 |
2. 優先順位判定表
判定基準
| 基準 | 説明 |
|---|---|
| ① 現在の実害 | すでに顕在化している悪影響があるか |
| ② 締切の動かしにくさ | 締切が外部要因（顧客属性・法制度・他社連携等）によるものか、内部目標にすぎないか |
| ③ 中断・着手遅延のコスト | すでに投資が進んでいて中断コストが高いか、これから着手する案件か |
| ④ 検証状態 | 投資判断の根拠がデータで裏付けられているか、まだ検証されていない仮説か |
基準ごとの該当状況
| 案件 | ①現在の実害 | ②締切の動かしにくさ | ③中断・遅延コスト | ④検証状態 |
|---|---|---|---|---|
| P1 | なし | 内部目標（動かせる余地あり） | 高い（Sprint進行中、リードの専門知識が投入済み） | 検証済み（要求は明確） |
| P2 | なし | 高い（12月生まれ会員という外部要因、逃すと1年分機会損失） | 中（未着手だがリスク登録簿まで完了） | 検証済み |
| P3 | 高い（CS問い合わせ37件/週） | 中（放置するほど悪化） | 低（まだ2週間の対応） | 検証済み（不具合の事実が明確） |
| P4 | なし | 低（「年内」は内部目標、動かせる余地が大きい） | 低（未着手） | 未検証（非利用の原因はまだ仮説段階） |
| 順位 | 案件 | 判断 |
|---|---|---|
| 1 | P3（値下げ通知の緊急安定化） | 現在進行形の実害があり、放置コストが時間とともに増加するため最優先で即着手 |
| 2 | P1（検索キーワードサジェスト） | すでに投資が進んでおり中断コストが最も高い。リードの専門知識を要する設計判断も継続中のため、体制を維持したまま進める |
| 3 | P2（誕生日月限定クーポン） | 外部要因による動かせない締切（11/1）があるため、9月中に必ず着手する。P1ほど中断コストは高くないが、着手を遅らせるほど11/1に間に合わなくなるリスクが線形に増える |
| 4 | P4（店舗連携デジタル会員証改善） | 本格改修へのエンジニア投入は今回の4週間では見送る。ただし完全に後回しにするのではなく、次の代替案を提示する |
P4への代替案（店舗連携推進室への回答）
店舗連携推進室長の「年内に改善したい」という要求そのものは否定せず、次の2段階アプローチを提案する。
- 9月中（今回の4週間内）: エンジニアをほぼ介さない軽量検証を先行実施する。店舗連携推進室とデザイナー主導で、レジでの掲示物の文言変更・アプリ内の会員証表示までの導線を1〜2手順短縮する簡易改修（エンジニア関与は動作確認のみ、0.5人日程度）を行い、利用率が改善するかを2週間観測する
- 10月以降（供給が回復するタイミング）: 軽量検証で「提示手順の分かりにくさ」という仮説が裏付けられた場合に、本格的なエンジニア投入（2名×2週間）を行う。裏付けが取れなかった場合は、別の原因仮説（認知経路の問題など）に切り替えて再度リサーチする
この段階分けにより、「年内」という要求には応えつつ、検証されていない仮説に工数を先出しするリスクを避けられる。
3. 再配分後の統合スケジュール（9/7〜10/4、4週間）
| メンバー | Week1 (9/7-9/11) | Week2 (9/14-9/18) | Week3 (9/21-9/25) | Week4 (9/28-10/2) |
|---|---|---|---|---|
| あなた | P3（緊急対応、5人日） | P3（緊急対応、5人日） | P2（合流、5人日） | P2（5人日） |
| Bさん | P1（5人日） | P1（5人日） | P1（5人日） | P1（5人日） |
| Cさん | P1（5人日） | P1（5人日） | P1（5人日） | P1（5人日） |
| Dさん | P2（要件確定・API仕様確認、5人日） | P2（設計〜実装開始、5人日） | P2（実装、5人日） | P2（実装・結合、5人日） |
| Aさん（リード、50%） | P1（2.5人日） | P1（2.5人日） | P1（2.5人日） | P1（2.5人日） |
| 週合計 | 22.5人日 | 22.5人日 | 22.5人日 | 22.5人日 |
案件別の実績配分と当初見積もりの対比
| 案件 | 当初見積もり | 実際の配分（4週間合計） | 差異・調整内容 |
|---|---|---|---|
| P1 | 50人日 | 50人日（B+C+リード×4週） | 差異なし。最優先で体制を死守 |
| P2 | 30人日 | 30人日（D単独2週間＋あなた合流後2週間） | 差異なし。ただしDが週1-2を単独で担当する点は後述のリスクあり |
| P3 | 10人日 | 10人日（あなた単独2週間） | 差異なし |
| P4 | 20人日 | 0人日 | 本格改修は10月以降に延期。軽量検証（0.5人日程度、上表には計上せず店舗連携推進室・デザイナー主導）のみ9月中に実施 |
| 合計 | 110人日 | 90人日 | P4の本格投入を延期することで、需要と供給がちょうど一致する計画にした |
4. リスク登録簿＋ステークホルダー合意形成レポート
リスク登録簿
| # | リスク内容 | 確率×影響 | 対応 | オーナー |
|---|---|---|---|---|
| R1 | Dさんが週1-2でP2の有効期限計算ロジックを単独設計する期間、リードのレビュー枠がゼロ。既存のP2リスク登録簿のR9（有効期限の月末計算バグ）の発生確率が、通常のレビュー体制時より上昇している | 高×高 | 週2終了時点で、リードの通常業務時間外に最低1時間の緊急レビュー枠を死守で確保する。infra案件側の担当者にも事前にその旨を共有し合意を取る | あなた |
| R2 | 需要と供給が完全に一致（90人日=90人日）しており、計画上のバッファがゼロ。誰か1人が1日でも体調不良・他チームからの緊急支援要請等で離脱すると、計画全体が崩れる | 中×高 | 事前に「バッファが切れた場合はP4の軽量検証をさらに後ろ倒しにする」という優先順位を経営層・関係部門とあらかじめ合意しておき、離脱発生時に即座に判断できるようにする | チームリーダー |
| R3 | P3（値下げ通知の緊急対応）があなた1人・2週間で収束する保証がない。原因究明に想定以上の時間がかかると、後続のP2着手（週3のあなた合流）が押し、11/1納期に影響する | 中×高 | 週1終了時点で進捗チェックポイントを設け、収束の見込みが立たなければリードのレビュー時間を1時間だけP3の原因究明に振り向ける（P1への影響は最小限に抑える） | あなた |
| R4 | 店舗連携推進室が今回の「P4は先に軽量検証、本格改修は10月以降」という判断を、「後回しにされた」とネガティブに受け取る可能性 | 中×中 | 判断根拠（未検証の仮説に工数を先出ししないこと）を明示した資料を用意し、店舗連携推進室長に個別説明の場を設ける。「年内」という要求自体は否定していないことを明確に伝える | チームリーダー |
| R5 | マーケティング本部長は11/1の「バッチ本稼働」を求めているが、週4完了直後に即座に本番投入するとQA・段階リリースの期間が確保できない | 高×高 | 週4完了後、最低3営業日のQA・段階リリース期間を明示的にスケジュールに組み込み、マーケ本部長に「開発完了日」と「本稼働日」が別であることを事前に合意させる | あなた |
ステークホルダーマップ（影響力×関心度）
| 象限 | 該当者 | 対応方針 |
|---|---|---|
| 影響力: 高 / 関心度: 高 | マーケティング本部長（P2）、チームリーダー | 個別説明＋定期進捗共有。今回の判断根拠を最も丁寧に伝える相手 |
| 影響力: 高 / 関心度: 中 | 店舗連携推進室長（P4） | R4への対応として個別説明の場を設ける。「後回し」ではなく「段階分け」であることを伝える |
| 影響力: 中 / 関心度: 高 | Aさん（リード）、B・C・Dさん | R1・R3のレビュー枠確保について事前合意を取る当事者 |
| 影響力: 低 / 関心度: 中 | CS部門 | P3の不具合対応状況を週次で共有し、問い合わせ対応の一次回答に反映してもらう |
経営層・関係部門向けステータスレポート（1ページサマリー）
| 信号 | 🟡 Yellow（対応中、バッファなしの綱渡り計画） |
|---|---|
| 結論 | 4案件（P1〜P4）の需要合計110人日に対し、9/7〜10/4の供給は90人日。P4（店舗連携デジタル会員証の本格改修）を10月以降に延期し、需要と供給を一致させる計画とする |
| 優先順位の根拠 | 現在の実害（P3）、外部要因による動かせない締切（P2）、既存投資の中断コスト（P1）を優先し、検証されていない仮説段階の案件（P4）への工数先出しを避けた |
| P4への対応 | 完全な先送りではなく、9月中に軽量検証（エンジニア関与0.5人日程度）を店舗連携推進室・デザイナー主導で先行実施し、原因仮説の裏付けが取れ次第、10月以降に本格投入する二段階アプローチとする |
| 主なリスク | 計画にバッファがなく、メンバー1人の離脱でも計画全体に影響が及ぶ（R2）。P2の設計初期をDさん単独で担当する期間、リードレビューが手薄になる（R1、既存リスクR9と関連） |
| 依頼事項 | ①マーケ本部長へ「開発完了（10/2）」と「本稼働（11/1）」の間にQA期間が必要であることの事前合意、②店舗連携推進室長への個別説明の場の設定、③リードのレビュー緊急枠についてinfra案件側担当者との調整 |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 声が大きい・役職が上のステークホルダーの要求を優先順位の基準にしてしまう | 「強く言った者勝ち」という前例が組織に蓄積し、次回以降さらに声の大きい要求が通りやすくなる | 実害・締切の動かしにくさ・中断コスト・検証状態といった、要求元の役職とは独立した客観基準で判定する |
| 需要が供給を超えた際、全案件を少しずつ薄く配分してしまう | どの案件も期限に間に合わなくなり、全案件が中途半端に遅延する「共倒れ」を招く | 1つの案件をはっきり後ろ倒しにするか規模を縮小し、残りの案件には十分な工数を確保する |
| 未検証の仮説段階の案件に、検証済みの案件と同列の優先度でエンジニア工数を先出しする | 仮説が外れていた場合、投資した工数がまるごと無駄になる | 本格投資の前に、エンジニア工数をほとんど使わない軽量な検証を挟み、仮説の裏付けが取れてから本格投資する |
| リソース再配分を決めた後、既存のリスク登録簿を見直さずそのまま放置する | リソース配分の変化（例: レビュー体制が手薄になる）によって、既存リスクの発生確率が変わっていることに気づけない | リソース再配分のたびに、関連する既存のリスク登録簿を見直し、発生確率・影響度が変わっていないか確認する |
| バッファゼロの配分計画を「無駄なく計画できた」と評価してしまう | メンバー1人の離脱や想定外の作業で計画全体が崩れるリスクを見落とす | バッファがゼロであること自体をリスクとして明示し、「バッファが切れたらどの案件から犠牲にするか」を事前に合意しておく |
🏆 実務での使いどころ
複数プロジェクト間のリソース競合調整は、EM（エンジニアリングマネージャー）やPMOが日常的に直面する意思決定であり、テックリード・PdMへのキャリアパスのいずれに進んでも避けて通れない場面です。エンジニアとして個々の案件のWBSやリスクを作れるようになった次のステップは、複数の案件を横断で見て、限られた人的リソースをどう配分するかという「配分の意思決定」です。この判断は技術的な正しさだけでなく、対立する要求元との関係性・組織への影響も同時に扱う必要があり、今回の「客観基準で裁定する」「完全な却下ではなく段階分けで提案する」というアプローチは、EM・PdMいずれの立場でも汎用的に使えます。また、リソース配分の変化が既存のリスクに与える影響を見逃さない視点は、プロジェクトが複数同時進行する組織のPMOに特に求められる力です。
🚀 次のステップ
来週も引き続き各カテゴリを曜日ごとに深掘りしていきます。次回の統合回（来週日曜）では、今回・Day015（指標悪化した機能のKill判断）・Day008（炎上プロジェクトの立て直し）・Day001（新機能ローンチ90日計画）とは異なる切り口として、複数のステークホルダーが矛盾する要求を出す中での、要求自体の再定義や交渉（例: 「全部やってほしい」という要求に対し、本当に必要な部分だけを引き出すヒアリングと合意形成）を扱う想定です。今回学んだ「客観基準で裁定する」「完全な却下ではなく段階分けで提案する」という考え方は、次回の交渉場面でも土台として使えます。