🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「福袋（数量限定セット商品）オンライン抽選予約機能」の開発が決まった。あなたはエンジニア3年目としてこのプロジェクトの担当エンジニア兼進行管理役に任命された。体制はエンジニア2名（あなたともう1名）・デザイナー1名・QA1名で、5週間後のリリースを目指す。
背景として、マーケ部門は年末年始向けに「アパレル福袋」「コスメ福袋」「家電福袋」など5種類の数量限定福袋を企画し、応募開始日時（12/20 10:00）を既にプレスリリースと公式SNS広告で告知済みである。
要件:
- 応募受付期間（12/20 10:00〜12/27 23:59の1週間）中、会員は1アカウントにつき1回のみ応募できる。5種類の福袋から第1〜第3希望まで選んで応募する
- 応募時点では決済を行わず、登録済みクレジットカードのオーソリ（仮売上）のみ確保する。当選確定後に本会計、落選時はオーソリを取り消す
- 応募締切後、抽選バッチで当選者を確定する。各福袋の在庫数に対してランダム抽選し、第1希望で落選した会員は自動的に第2希望のプールに繰り越して再抽選する
- 同一会員が複数アカウントを作成して重複応募することを防ぐ不正対策が必要（本人確認情報の突合等）
- 当選発表はメール＋マイページ通知で一斉に行い、発表後48時間以内に本会計（オーソリの実売上への変更）が完了しない場合は当選を自動的に無効化し、繰り上げ当選者に権利を移す
- 応募受付開始時刻（12/20 10:00）は告知済みで変更不可。開始直後のアクセス集中に耐えられる設計が必須
📝 課題
あなたのタスク: 上記プロジェクトのWBSを、作業パッケージ単位（1〜2週間で完了できる粒度）まで分解して表形式で作成してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- まず大きなフェーズ（要件定義/設計/実装/テスト/リリース準備）に分け、そこから機能単位・技術要素単位に分解していく
- 「抽選ロジックを作る」だけでなく「第1希望落選時の第2希望繰り越し再抽選ロジックの実装」のように具体的な粒度まで割ること
- 開始日時が対外告知済みで動かせない「固定日程プロジェクト」であることは、WBS全体の作業パッケージの優先順位・並行度の判断に影響することを意識する
- オーソリ（仮売上）・本会計・繰り上げ当選という決済フローの状態遷移は、実装だけでなくテストでも独立した作業パッケージとして扱うこと
- 重複応募不正対策と繰り上げ当選ロジックは見落としやすいので、要件定義段階で明示的に扱う（100%ルール）
- 開始直後のアクセス集中対策（負荷試験含む）を独立した作業パッケージにすること
📚 背景知識・用語解説
WBS（Work Breakdown Structure、作業分解構造）とは、プロジェクトのスコープ全体を、管理・見積もりが可能な単位まで階層的に分解したものです。単なるタスクリストと違い、「プロジェクトの成果物」を起点に分解していく点が特徴です。タスク（動詞ベース）ではなく成果物（名詞ベース）で考えると、「言われた作業だけ並べて肝心な成果物を作り忘れる」抜け漏れに気づきやすくなります。
作業パッケージ（Work Package）: WBSの最下層、実際にアサイン・見積もりの対象になる単位。目安として1〜2週間で完了できる粒度に分解します。これより粗いと「今どこまで進んでいるか」が見えず、遅延に気づくのが遅れます。逆に細かすぎると管理コスト（進捗確認・報告のオーバーヘッド）が増えて非効率になります。
固定日程プロジェクト（Fixed-Date Project）がWBSに与える影響: 今回のように開始日時が対外的に告知済みで動かせない場合、「日程が遅れたらリリース日をずらす」という選択肢がありません。この制約下でWBSを組むと、①スコープを削ってでも日程を守る判断がしやすいよう機能単位で作業パッケージを分割しておく、②不確実性が高くリスクの大きい作業パッケージ（抽選ロジック・決済状態遷移・負荷対策）を早い段階に前倒しし、問題が出た場合の手戻り時間を確保する、という2つの設計判断が必要になります。単に「フェーズ順に並べる」だけでなく、「動かせない日付から逆算して、どの作業パッケージを先に潰すべきか」という視点がWBSの並び順・並行度に反映されるべきです。
決済状態遷移（オーソリ→本会計→取消）をWBSで扱う視点: 「応募時オーソリ確保」「当選時オーソリ→本会計」「落選時オーソリ取消」「48時間以内に本会計が完了しない場合の当選無効化」という4つの状態遷移は、それぞれ異なるタイミング・異なるトリガー（バッチ処理か会員の能動的操作か）で発生するため、1つの決済処理としてまとめて実装するとテストで見落としが起きやすくなります。WBSの段階で状態遷移ごとに独立した作業パッケージとして明記しておくことで、実装者が「今どの状態遷移を作っているか」を意識しながら手を動かせます。
✅ 模範解答
| コード | フェーズ / 作業パッケージ | 見積もり | 担当ロール |
|---|---|---|---|
| 1.0 | 要件定義 | ||
| 1.1 | 抽選ルール（希望順位数・繰り越し再抽選の可否・在庫配分単位）のヒアリング・要件確定 | 2日 | エンジニア/マーケ |
| 1.2 | オーソリ〜本会計〜取消の決済フロー要件を決済代行会社と確認 | 2日 | エンジニア/経理 |
| 1.3 | 重複応募不正対策の基準（本人確認情報の突合範囲・判定閾値）の確認 | 2日 | エンジニア/法務 |
| 1.4 | 開始直後のアクセス集中を想定した想定同時アクセス数・許容応答時間の要件確認 | 1日 | エンジニア/インフラ担当 |
| 2.0 | 設計 | ||
| 2.1 | 応募受付フォーム（第1〜第3希望選択・1アカウント1回制限）の設計 | 2日 | デザイナー/エンジニア |
| 2.2 | 抽選ロジック（各福袋在庫数に対するランダム抽選・落選時の第2希望繰り越し再抽選）の設計 | 4日 | エンジニア |
| 2.3 | 決済状態遷移（オーソリ確保→当選時本会計→落選時取消→48時間超過時の当選無効化）の設計 | 3日 | エンジニア |
| 2.4 | 重複応募不正検知ロジックの設計 | 3日 | エンジニア |
| 2.5 | アクセス集中対策（受付開始直後の流量制御・待機列表示等）の設計 | 3日 | エンジニア |
| 2.6 | 当選発表通知（メール・マイページ）文面・画面設計 | 2日 | デザイナー/マーケ |
| 3.0 | 実装 | ||
| 3.1 | 応募受付フォームの実装 | 3日 | エンジニア |
| 3.2 | 抽選ロジック（初回抽選・第2希望繰り越し再抽選）の実装 | 5日 | エンジニア |
| 3.3 | オーソリ確保処理（応募時）の実装 | 2日 | エンジニア |
| 3.4 | 当選時本会計処理の実装 | 2日 | エンジニア |
| 3.5 | 落選時オーソリ取消処理の実装 | 2日 | エンジニア |
| 3.6 | 48時間以内未決済の当選無効化・繰り上げ当選処理の実装 | 3日 | エンジニア |
| 3.7 | 重複応募不正検知ロジックの実装 | 3日 | エンジニア |
| 3.8 | アクセス集中対策（流量制御・待機列）の実装 | 4日 | エンジニア |
| 3.9 | 当選発表通知（メール・マイページ）送信処理の実装 | 2日 | エンジニア |
| 4.0 | テスト | ||
| 4.1 | 単体テスト・結合テスト | 3日 | エンジニア |
| 4.2 | 抽選ロジックの公平性検証（大量シミュレーションによる偏り確認） | 3日 | QA/エンジニア |
| 4.3 | 決済状態遷移の全パターンテスト（当選即決済/落選取消/未決済失効/繰り上げ当選） | 3日 | QA/エンジニア |
| 4.4 | 重複応募不正検知の検知率テスト | 2日 | QA/エンジニア |
| 4.5 | 受付開始直後を想定した負荷試験 | 3日 | QA/エンジニア/インフラ担当 |
| 4.6 | QAによる機能テスト・シナリオテスト（正常系・異常系） | 4日 | QA |
| 5.0 | リリース準備 | ||
| 5.1 | 応募数・抽選結果・決済状況のモニタリングダッシュボード整備 | 2日 | エンジニア |
| 5.2 | CS部門向けFAQ・問い合わせ対応手順の整備（未当選問い合わせ・決済失敗想定） | 1日 | エンジニア/CS |
| 5.3 | 受付開始日当日の障害対応体制・エスカレーション手順の確定 | 1日 | エンジニア/チームリード |
合計見積もり: 約66人日（5週間・体制4名で並行作業する前提と整合。うち抽選ロジックと決済状態遷移・アクセス集中対策を設計フェーズの早い段階に集中配置し、問題発覚時の手戻り余地を確保）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 抽選ロジックと決済状態遷移をフェーズの後半（実装終盤）に持ってくる | 固定日程プロジェクトでは、リスクの高い作業パッケージで問題が出た時点でリカバリーの時間が残っておらず、開始日時に間に合わなくなる | 不確実性が高くやり直しコストの大きい作業パッケージほど設計・実装の早い段階に前倒しする |
| オーソリ確保・本会計・取消・当選無効化を1つの「決済処理」としてまとめて見積もる | それぞれ異なるトリガーで発生する別々の状態遷移であることが見えなくなり、48時間経過による自動無効化のようなタイマー起点の処理が実装・テストから漏れる | 決済状態遷移はトリガーごとに独立した作業パッケージとして分解する |
| 重複応募不正対策をアプリ側のバリデーション実装のついでに扱う | 検知率の検証が後回しになり、リリース後に複数アカウントでの不正応募がSNSで指摘されて炎上する | 重複応募不正検知は設計・実装・テスト（検知率測定）の各フェーズで独立した作業パッケージとして必ず立てる |
| アクセス集中対策を「まず機能を作ってから、余裕があれば負荷試験する」という位置づけにする | 開始時刻が対外告知済みで確実にアクセスが集中するタイミングが事前にわかっているにもかかわらず、負荷試験が後回しになりリリース当日にサイトダウンするリスクが残る | 開始日時が固定されているプロジェクトでは、アクセス集中対策と負荷試験を本線の作業パッケージとして最初からスケジュールに組み込む |
🏆 実務での使いどころ
WBSはキックオフ後の最初の成果物として、PMだけでなくエンジニアも作成に関わることが多いです。今回のように「開始日時が対外告知済みで動かせない」プロジェクトでは、単にフェーズ順にタスクを並べるだけでなく、「どの作業パッケージにリスクが集中しているか」を見抜いて前倒しする判断がWBSの並び順に表れます。この視点はエンジニアがスケジュールの単なる実行者ではなく、進行管理にも主体的に関わる立場であることを示す評価ポイントになります。抽選の公平性・決済状態遷移・アクセス集中対策のように「機能要件の文章には明記されにくいが実装上は必須の要素」を独立した作業パッケージとして見積もりに含められるかどうかも、後工程でのスケジュール遅延時に「どこで遅れているか」を具体的に説明できるかを左右します。
🚀 次のステップ
このWBSから、次はテーマ1-2「見積もり手法（三点見積もり）」を使って、不確実性の高い作業パッケージ（3.2 抽選ロジックの実装、4.5 受付開始直後を想定した負荷試験等）を楽観値・悲観値・最頻値からPERT期待値で見積もり直してみましょう。固定日程プロジェクトでは、単一の見積もり日数だけでは見えないバッファの必要量がより明確に見えてくるはずです。