🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「カート放棄リマインダー機能」の開発が決まった。あなたはエンジニア3年目としてこのプロジェクトの担当エンジニア兼進行管理役に任命された。体制はエンジニア2名（あなたともう1名）・デザイナー1名・QA1名で、6週間後のリリースを目指す。
背景として、データ分析チームから「カートに商品を入れたまま離脱する会員が全体の約35%おり、その一部は在庫や価格に不満があるわけではなく単純に忘れているだけ」という分析結果が共有され、マーケ部門が離脱会員に対してメールでリマインドする施策を企画した。
要件:
- 会員がカートに商品を入れたまま24時間操作せずに離脱した場合、1通目のリマインダーメールを送る
- 24時間後の1通目で購入に至らなかった場合、72時間後に2通目を送る。2通目には「24時間限定10%OFFクーポン」を添付する
- 送信時点でカート内商品が在庫切れ・販売終了になっている場合はその商品をメール内容から除外し、カート内の全商品が対象外になった場合は送信自体をスキップする
- 会員がメルマガ配信停止設定を行っている場合、特定電子商取引・特定電子メール法の観点から一切送信してはならない。メール本文には配信停止リンクを必須で含める
- 会員が既にそのカートの内容で注文を完了している場合、リマインダーを送ってはならない（送信予約後に注文完了した場合の停止漏れも防ぐ必要がある）
- リマインダー経由でどれだけ購入につながったか（コンバージョン率）を計測できるようにする
📝 課題
あなたのタスク: 上記プロジェクトのWBSを、作業パッケージ単位（1〜2週間で完了できる粒度）まで分解して表形式で作成してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- まず大きなフェーズ（要件定義/設計/実装/テスト/リリース準備）に分け、そこから機能単位・技術要素単位に分解していく
- 「メールを送る」だけでなく「カート放棄検知バッチの実装」「配信停止・opt-out除外ロジックの実装」のように具体的な粒度まで割ること
- 配信停止設定の会員への誤送信は法令違反に直結するため、独立した作業パッケージとして設計・実装・テストそれぞれに置くこと
- 「送信予約後に注文完了した場合の停止漏れ」のようなタイミングの競合は見落としやすいので、テストフェーズで明示的に扱うこと
- クーポン発行は金銭的価値を伴うため、経理・会計への影響確認を要件定義の早い段階に入れる（100%ルール）
📚 背景知識・用語解説
WBS（Work Breakdown Structure、作業分解構造）とは、プロジェクトのスコープ全体を、管理・見積もりが可能な単位まで階層的に分解したものです。単なるタスクリストと違い、「プロジェクトの成果物」を起点に分解していく点が特徴です。タスク（動詞ベース）ではなく成果物（名詞ベース）で考えると、「言われた作業だけ並べて肝心な成果物を作り忘れる」抜け漏れに気づきやすくなります。
作業パッケージ（Work Package）: WBSの最下層、実際にアサイン・見積もりの対象になる単位。目安として1〜2週間で完了できる粒度に分解します。これより粗いと「今どこまで進んでいるか」が見えず、遅延に気づくのが遅れます。逆に細かすぎると管理コスト（進捗確認・報告のオーバーヘッド）が増えて非効率になります。
タイミングの競合（Race Condition）をWBSで扱う視点: 今回のように「送信予約後に注文完了した場合の停止漏れ」は、要件定義の文章だけを読むと見落としがちですが、非同期処理（バッチによるメール送信予約と、リアルタイムの注文完了イベント）が絡む機能では必ず発生しうる問題です。WBSの段階でこの種の競合を独立したテスト作業パッケージとして明記しておくことで、実装者が「送信直前に最終チェックを入れる」といった設計判断を早期にできます。
✅ 模範解答
| コード | フェーズ / 作業パッケージ | 見積もり | 担当ロール |
|---|---|---|---|
| 1.0 | 要件定義 | ||
| 1.1 | リマインダー送信条件（放置時間・クーポン内容・送信回数）のヒアリング・要件確定 | 2日 | エンジニア/マーケ |
| 1.2 | 特定電子メール法対応要件（配信停止リンク必須化・opt-out済み会員の除外基準）の確認 | 1日 | エンジニア/法務 |
| 1.3 | クーポン発行の会計・原資管理への影響確認 | 1日 | エンジニア/経理 |
| 1.4 | カート内商品の在庫切れ・販売終了判定に使うデータ仕様の確認 | 1日 | エンジニア/在庫管理部門 |
| 2.0 | 設計 | ||
| 2.1 | カート放棄検知バッチ（24時間/72時間経過判定）の設計 | 3日 | エンジニア |
| 2.2 | 在庫状態チェック・対象外商品除外ロジック（全滅時は送信スキップ）の設計 | 3日 | エンジニア |
| 2.3 | 配信停止・opt-out除外ロジックの設計 | 2日 | エンジニア |
| 2.4 | メール経由コンバージョン計測（トラッキングパラメータ設計）の設計 | 3日 | エンジニア |
| 2.5 | リマインダーメールテンプレート（1通目・2通目クーポン付き）のUI・文面設計 | 3日 | デザイナー/マーケ |
| 3.0 | 実装 | ||
| 3.1 | カート放棄検知バッチの実装 | 4日 | エンジニア |
| 3.2 | 在庫状態チェック・対象外商品除外ロジックの実装 | 4日 | エンジニア |
| 3.3 | 配信停止・opt-out除外ロジックの実装 | 2日 | エンジニア |
| 3.4 | クーポン自動発行・メール添付処理の実装 | 3日 | エンジニア |
| 3.5 | メール送信処理（1通目・2通目テンプレート出し分け）の実装 | 3日 | エンジニア |
| 3.6 | コンバージョン計測（トラッキング付与・購入完了時の突合処理）の実装 | 4日 | エンジニア |
| 3.7 | 注文完了済みカートの送信停止処理（送信直前の最終チェック含む）の実装 | 2日 | エンジニア |
| 4.0 | テスト | ||
| 4.1 | 単体テスト・結合テスト | 3日 | エンジニア |
| 4.2 | 在庫切れ・全商品対象外（送信スキップ）パターンのシナリオテスト | 2日 | QA/エンジニア |
| 4.3 | 配信停止設定会員への誤送信防止テスト | 2日 | QA/エンジニア |
| 4.4 | 送信予約後に注文完了した場合の送信停止テスト（タイミング競合の確認） | 2日 | QA/エンジニア |
| 4.5 | QAによる機能テスト・シナリオテスト（正常系・異常系） | 4日 | QA |
| 5.0 | リリース準備 | ||
| 5.1 | 送信数・コンバージョン率のモニタリングダッシュボード整備 | 2日 | エンジニア |
| 5.2 | CS部門向けFAQ・問い合わせ対応手順の整備（クーポン未着・二重発行想定） | 1日 | エンジニア/CS |
| 5.3 | 段階的リリース（社内先行公開→一部会員→全体）計画 | 2日 | エンジニア |
合計見積もり: 約59人日（6週間・体制4名で並行作業する前提と整合）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 配信停止・opt-out除外ロジックをメール送信実装(3.5)の一部として扱い、独立した作業パッケージにしない | 見積もりが甘くなり、テストも他機能のついでにしか行われず、法令違反となる誤送信を見逃すリスクが上がる | 配信停止・opt-out除外ロジックは設計・実装・テストの各フェーズで独立した作業パッケージとして必ず立てる |
| 「送信予約後に注文完了したケース」をWBSに明記しない | 非同期のバッチ処理とリアルタイムの注文完了イベントという異なるタイミングの処理間の競合が実装段階まで気づかれず、リリース後に「買ったのにリマインダーが届いた」というクレームにつながる | 非同期処理とリアルタイムイベントが絡む機能では、タイミングの競合を扱うテスト作業パッケージを明示的に立てる |
| 在庫状態チェックを「メール送信」の付随処理として軽く見積もる | 全滅時のスキップ判定や一部除外のロジックが後回しになり、欠品商品を案内してクレームにつながる | 在庫状態チェック・除外ロジックを設計・実装それぞれで独立した作業パッケージとして見積もる |
| 見積もりを楽観値だけで出す | バッファがなく、少しの遅延で全体が破綻する | 不確実性の高い作業パッケージ（タイミング競合の実装・テスト等）は三点見積もり（PERT）でリスクを織り込む |
🏆 実務での使いどころ
WBSはキックオフ後の最初の成果物として、PMだけでなくエンジニアも作成に関わることが多いです。特に「見積もりの根拠をチームリードや非エンジニアの関係者に説明する」場面で、WBSの粒度がそのまま説得力になります。今回のように法令順守（特定電子メール法）や非同期処理のタイミング競合といった「機能要件の文章には明記されにくいが実装上は必須の要素」をWBSに独立した作業パッケージとして含められるかどうかが、エンジニアとしての設計視野の広さの評価につながります。エンジニアがWBS作成に主体的に関わると、後工程での「言った/言わない」の齟齬が減り、スケジュール遅延時にも「どの作業パッケージで遅れているか」を具体的に説明できます。
🚀 次のステップ
このWBSから、次はテーマ1-2「見積もり手法（三点見積もり）」を使って、不確実性の高い作業パッケージ（3.7 送信停止処理の実装、4.4 タイミング競合の確認テスト等）を楽観値・悲観値・最頻値からPERT期待値で見積もり直してみましょう。単一の見積もり日数だけでは見えないリスクバッファの必要性が見えてくるはずです。