🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「お気に入り商品の値下げ通知（プライスドロップアラート）機能」の開発が決まった。あなたはエンジニア3年目としてこのプロジェクトの担当エンジニア兼進行管理役に任命された。体制はエンジニア2名（あなたともう1名）・デザイナー1名・QA1名で、6週間後のリリースを目指す。
背景として、マーケ部門から「お気に入り登録された商品はセール時に再訪問・再購入されやすいが、値下げに気づかず機会損失になっているケースが多い」というデータが共有され、値下げ発生時に会員へ能動的に通知する機能が企画された。
要件:
- 会員は既存のお気に入り登録機能で商品をお気に入りに追加できる（この機能自体は開発対象外）
- お気に入り商品の価格が登録時の価格より下がったら、プッシュ通知・メールで会員に通知する
- セール開始時など大量の値下げが同時発生すると通知が殺到し会員体験を損なうため、1会員あたり1日の通知数に上限を設け、上限を超える分は「本日の値下げまとめ」ダイジェスト形式に切り替える
- 在庫調整で短期間に値下げ→値上げを繰り返す商品があり、そのたびに通知が飛ぶと会員の信頼を損なうため、同一商品について一定期間は再通知しないクールダウン期間を設ける
- 会員はマイページで通知方法（プッシュ/メール/両方/オフ）を設定できる
- 価格変動データは、物流・価格担当部門が運用する外部価格管理システムから日次バッチで取得する
📝 課題
あなたのタスク: 上記プロジェクトのWBSを、作業パッケージ単位（1〜2週間で完了できる粒度）まで分解して表形式で作成してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- まず大きなフェーズ（要件定義/設計/実装/テスト/リリース準備）に分け、そこから機能単位・技術要素単位に分解していく
- 「通知を実装する」だけでなく「通知殺到防止ロジック（上限・ダイジェスト切替・クールダウン）の実装」のように具体的な粒度まで割ること
- 通知殺到防止（上限・ダイジェスト・クールダウン）は要件としては地味に見えるが、設計・実装・テストいずれにも影響する重要要素なので独立した作業パッケージとして扱う
- 外部価格管理システムとの連携はプロジェクト外部に依存する要素なので、要件定義の早い段階で連携仕様を確認しておく
- 「通知が来ない」「通知が来すぎる」という問い合わせが増えることを見越し、CS部門向けの対応準備も忘れずに含める（100%ルール）
📚 背景知識・用語解説
WBS（Work Breakdown Structure、作業分解構造）とは、プロジェクトのスコープ全体を、管理・見積もりが可能な単位まで階層的に分解したものです。単なるタスクリストと違い、「プロジェクトの成果物」を起点に分解していく点が特徴です。タスク（動詞ベース）ではなく成果物（名詞ベース）で考えると、「言われた作業だけ並べて肝心な成果物を作り忘れる」抜け漏れに気づきやすくなります。
作業パッケージ（Work Package）: WBSの最下層、実際にアサイン・見積もりの対象になる単位。目安として1〜2週間で完了できる粒度に分解します。これより粗いと「今どこまで進んでいるか」が見えず、遅延に気づくのが遅れます。逆に細かすぎると管理コスト（進捗確認・報告のオーバーヘッド）が増えて非効率になります。
外部依存を含むWBSの注意点: 今回のように「物流・価格担当部門の外部価格管理システム」というプロジェクト外部のシステムに依存する場合、そのシステムのバッチ頻度・データ項目仕様を確認する作業を要件定義フェーズの独立した作業パッケージとして立てておくべきです。仕様確認を後回しにすると、設計・実装段階で「想定していたデータ項目がない」といった手戻りが発生しやすくなります。
✅ 模範解答
| コード | フェーズ / 作業パッケージ | 見積もり | 担当ロール |
|---|---|---|---|
| 1.0 | 要件定義 | ||
| 1.1 | 通知条件（値下げ幅の閾値有無、対象範囲）のヒアリング・要件確定 | 2日 | エンジニア/マーケ |
| 1.2 | 通知殺到防止ルール（1日上限・ダイジェスト切替基準・クールダウン期間）の方針決定 | 2日 | エンジニア |
| 1.3 | 外部価格管理システムとのデータ連携仕様（バッチ頻度・データ項目）の確認 | 1日 | エンジニア/物流・価格担当 |
| 1.4 | メール配信基盤・プッシュ通知基盤の既存キャパシティ確認（配信数急増耐性） | 1日 | エンジニア/インフラ |
| 2.0 | 設計 | ||
| 2.1 | お気に入り商品価格変動検知バッチのDB・処理設計 | 4日 | エンジニア |
| 2.2 | 通知殺到防止ロジック（上限カウント・ダイジェスト切替・クールダウン管理）の設計 | 4日 | エンジニア |
| 2.3 | プッシュ通知・メール配信の既存配信基盤への連携設計 | 3日 | エンジニア |
| 2.4 | マイページ通知設定画面のUI設計 | 3日 | デザイナー |
| 3.0 | 実装 | ||
| 3.1 | 外部価格管理システムからの日次バッチ取り込み実装 | 4日 | エンジニア |
| 3.2 | 価格変動検知・値下げ判定ロジックの実装 | 4日 | エンジニア |
| 3.3 | 通知殺到防止ロジック（上限カウント・ダイジェスト生成・クールダウン管理）の実装 | 5日 | エンジニア |
| 3.4 | プッシュ通知送信処理の実装 | 3日 | エンジニア |
| 3.5 | メール通知（通常・ダイジェスト両テンプレート）送信処理の実装 | 3日 | エンジニア |
| 3.6 | マイページ通知設定画面の実装 | 3日 | エンジニア/デザイナー |
| 4.0 | テスト | ||
| 4.1 | 単体テスト・結合テスト | 3日 | エンジニア |
| 4.2 | 大量値下げ同時発生を想定した通知殺到シナリオテスト | 3日 | QA/エンジニア |
| 4.3 | 短期間に値下げ・値上げを繰り返す商品でのクールダウン動作確認テスト | 2日 | QA/エンジニア |
| 4.4 | QAによる機能テスト・シナリオテスト（正常系・異常系） | 4日 | QA |
| 5.0 | リリース準備 | ||
| 5.1 | 配信基盤の送信数急増に対する運用監視・アラート整備 | 2日 | エンジニア |
| 5.2 | CS部門向けFAQ・問い合わせ対応手順の整備（通知が来ない/来すぎる問い合わせ想定） | 1日 | エンジニア/CS |
| 5.3 | 段階的リリース（社内先行公開→一部会員→全体）計画 | 2日 | エンジニア |
合計見積もり: 約59人日（6週間・体制4名で並行作業する前提と整合）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「通知を送る」を実装(3.4・3.5)だけの一行で済ませる | 通知殺到防止（上限・ダイジェスト・クールダウン）という要件の核心部分が見積もりから抜け落ち、セール時に会員から苦情が殺到するリスクを見落とす | 通知殺到防止ロジックを設計・実装それぞれで独立した作業パッケージとして必ず立てる |
| 外部システム（外部価格管理システム）との連携仕様確認を実装フェーズまで後回しにする | 想定していたデータ項目やバッチ頻度が実際と異なることが実装段階で発覚し、大きな手戻りが発生する | 外部依存のある要素は要件定義フェーズで仕様確認を独立した作業パッケージとして先に済ませる |
| CS部門向けの対応準備をWBSに含めない | リリース後に「通知が来ない」という問い合わせが殺到してもCS部門が説明できず、エンジニアへのエスカレーションが増えて本来の開発業務を圧迫する | 会員向けの挙動が複雑な機能（通知の抑制・遅延がある機能）では、CS対応準備を独立した作業パッケージとしてリリース準備フェーズに必ず入れる |
| 見積もりを楽観値だけで出す | バッファがなく、少しの遅延で全体が破綻する | 不確実性の高い作業パッケージ（通知殺到防止ロジック等）は三点見積もり（PERT）でリスクを織り込む |
🏆 実務での使いどころ
WBSはキックオフ後の最初の成果物として、PMだけでなくエンジニアも作成に関わることが多いです。特に「見積もりの根拠をチームリードや非エンジニアの関係者に説明する」場面で、WBSの粒度がそのまま説得力になります。今回のように外部システム依存や、通知抑制のような「機能としては地味だが会員体験に直結する非機能要素」をWBSに明示的に含められるかどうかが、エンジニアとしての視野の広さの評価につながります。エンジニアがWBS作成に主体的に関わると、後工程での「言った/言わない」の齟齬が減り、スケジュール遅延時にも「どの作業パッケージで遅れているか」を具体的に説明できます。
🚀 次のステップ
このWBSから、次はテーマ1-2「見積もり手法（三点見積もり）」を使って、不確実性の高い作業パッケージ（3.3 通知殺到防止ロジックの実装など）を楽観値・悲観値・最頻値からPERT期待値で見積もり直してみましょう。単一の見積もり日数だけでは見えないリスクバッファの必要性が見えてくるはずです。