🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「友達紹介キャンペーン機能」の開発が決まった。あなたはエンジニア3年目としてこのプロジェクトの担当エンジニア兼進行管理役に任命された。体制はエンジニア2名（あなたともう1名）・デザイナー1名・QA1名で、6週間後のリリースを目指す。
要件:
- 会員は自分専用の紹介コード付きURLを発行できる
- 友達がそのURLから新規会員登録すると、紹介関係が記録される
- 被紹介者が初回購入を完了した時点で、紹介者・被紹介者の双方にクーポン（1,000円分）が自動付与される
- 同一人物が複数アカウントを作って自己紹介する不正利用を検知・ブロックする仕組みが必要
- 紹介実績（紹介人数・獲得クーポン数）を会員がマイページで確認できる
📝 課題
あなたのタスク: 上記プロジェクトのWBSを、作業パッケージ単位（1〜2週間で完了できる粒度）まで分解して表形式で作成してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- まず大きなフェーズ（要件定義/設計/実装/テスト/リリース準備）に分け、そこから機能単位・技術要素単位に分解していく
- 「実装する」だけでなく「紹介コード発行APIの実装」のように具体的な粒度まで割ること
- 不正利用防止のロジックは要件としては地味に見えるが、設計・実装・テストいずれにも影響する重要要素なので独立した作業パッケージとして扱う
- QAやドキュメント整備、クーポン付与の会計・経理連携確認など、機能実装以外の作業も忘れずに含める
- 100%ルール（プロジェクトのスコープを漏れなく分解できているか）を意識する
📚 背景知識・用語解説
WBS（Work Breakdown Structure、作業分解構造）とは、プロジェクトのスコープ全体を、管理・見積もりが可能な単位まで階層的に分解したものです。単なるタスクリストと違い、「プロジェクトの成果物」を起点に分解していく点が特徴です。タスク（動詞ベース）ではなく成果物（名詞ベース）で考えると、「言われた作業だけ並べて肝心な成果物を作り忘れる」抜け漏れに気づきやすくなります。
作業パッケージ（Work Package）: WBSの最下層、実際にアサイン・見積もりの対象になる単位。目安として1〜2週間で完了できる粒度に分解します。これより粗いと「今どこまで進んでいるか」が見えず、遅延に気づくのが遅れます。逆に細かすぎると管理コスト（進捗確認・報告のオーバーヘッド）が増えて非効率になります。
WBSとタスクリストの違い: タスクリストは思いついた順に並ぶ「To-Doの羅列」になりがちですが、WBSはフェーズ→機能→作業パッケージという階層構造を持ち、抜け漏れを構造的にチェックできる点が異なります。
✅ 模範解答
| コード | フェーズ / 作業パッケージ | 見積もり | 担当ロール |
|---|---|---|---|
| 1.0 | 要件定義 | ||
| 1.1 | キャンペーン条件（付与額・付与タイミング）のヒアリング・要件確定 | 2日 | エンジニア/マーケ |
| 1.2 | 不正利用の想定パターン洗い出し（同一端末・同一決済手段での複数アカウント等） | 2日 | エンジニア |
| 1.3 | クーポン自動付与の経理・会計処理への影響確認 | 1日 | エンジニア/経理 |
| 2.0 | 設計 | ||
| 2.1 | 紹介コード発行・紹介関係記録のDB・API設計 | 4日 | エンジニア |
| 2.2 | 不正利用検知ロジックの設計（判定基準・スコアリング方式） | 4日 | エンジニア |
| 2.3 | クーポン自動付与バッチ処理の設計（初回購入完了イベントとの連携） | 3日 | エンジニア |
| 2.4 | マイページ「紹介実績」画面のUI設計・ワイヤーフレーム | 3日 | デザイナー |
| 3.0 | 実装 | ||
| 3.1 | 紹介コード発行API・専用URL生成の実装 | 4日 | エンジニア |
| 3.2 | 新規登録フローへの紹介コード紐付け実装 | 3日 | エンジニア |
| 3.3 | 不正利用検知ロジックの実装 | 6日 | エンジニア |
| 3.4 | 初回購入完了トリガーによるクーポン自動付与バッチ実装 | 5日 | エンジニア |
| 3.5 | マイページ「紹介実績」画面の実装 | 4日 | エンジニア/デザイナー |
| 4.0 | テスト | ||
| 4.1 | 単体テスト・結合テスト | 4日 | エンジニア |
| 4.2 | 不正利用検知の突破テスト（意図的に不正パターンを試す） | 3日 | QA/エンジニア |
| 4.3 | QAによる機能テスト・シナリオテスト（正常系・異常系） | 4日 | QA |
| 5.0 | リリース準備 | ||
| 5.1 | クーポン付与ログ・不正検知結果の運用監視手順の整備 | 2日 | エンジニア |
| 5.2 | 経理部門向け付与実績レポートの整備 | 1日 | エンジニア |
| 5.3 | 段階的リリース（社内先行公開→10%→100%）計画 | 2日 | エンジニア |
合計見積もり: 約53人日（6週間・体制4名で並行作業する前提と整合）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「不正利用防止」を実装(3.3)だけの一行で済ませる | 設計・テストへの影響が大きい要素なのに見積もりが甘くなり、後工程で手戻りが発生する | 要件定義・設計・テストそれぞれのフェーズに不正利用防止の作業パッケージを明示的に立てる |
| 「実装」を1つの作業パッケージにまとめる | 粒度が粗すぎて進捗が見えず、遅延に気づくのが遅れる | 1〜2週間単位（機能・技術要素ごと）まで分解する |
| クーポンという金銭的価値を伴う機能で経理連携を書き忘れる | 100%ルール違反。リリース直前に経理側の承認プロセスが未整備であることが発覚し、リリースが止まる | 「お金が動く機能」では要件定義の段階で経理・会計への影響確認を作業パッケージとして必ず入れる |
| 見積もりを楽観値だけで出す | バッファがなく、少しの遅延で全体が破綻する | 不確実性の高い作業パッケージ（不正利用検知ロジック等）は三点見積もり（PERT）でリスクを織り込む |
🏆 実務での使いどころ
WBSはキックオフ後の最初の成果物として、PMだけでなくエンジニアも作成に関わることが多いです。特に「見積もりの根拠をチームリードや非エンジニアの関係者に説明する」場面で、WBSの粒度がそのまま説得力になります。エンジニアがWBS作成に主体的に関わると、後工程での「言った/言わない」の齟齬が減り、スケジュール遅延時にも「どの作業パッケージで遅れているか」を具体的に説明できます。今回のように金銭的価値（クーポン）を伴う機能では、経理・会計といった非エンジニア部門との連携作業をWBSに明示的に含められるかどうかが、エンジニアとしての視野の広さの評価につながります。
🚀 次のステップ
このWBSから、次はスケジュール線表（ガントチャート）に落とし込み、クリティカルパス（テーマ1-5）を分析してみましょう。どの作業パッケージが遅れると全体リリース日に直結するか、依存関係（例: 2.2の検知ロジック設計が終わらないと3.3の実装に着手できない）を整理してみてください。