🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「レビュー投稿促進キャンペーン機能」の開発が決まった。あなたはエンジニア3年目としてこのプロジェクトの担当エンジニア兼進行管理役に任命された。体制はエンジニア2名（あなたともう1名）・デザイナー1名・QA1名で、6週間後のリリースを目指す。
背景として、CS部門から「商品レビューの投稿数が少なく、購入検討時の参考情報が不足している」という指摘が続いており、マーケ部門はレビュー投稿にポイントインセンティブを付ける施策を求めている。
要件:
- 会員は購入済み商品に対して、星評価・テキスト・写真（任意）付きでレビューを投稿できる
- レビュー投稿完了時、テキストが50字以上等の条件を満たせば500ポイントが自動付与される
- 写真付きレビューにはさらに300ポイントが追加付与される
- コピペ・文字数水増し・NGワードを含むなど「悪質レビュー」を自動検知し、該当する場合はポイント付与を保留して運営の人力確認に回す
- 同一会員が同一商品に複数回レビューを投稿してポイントを重複取得することを防止する
- 会員はマイページで自分のレビュー履歴・獲得ポイントを確認でき、月間レビュー投稿数ランキングも表示される
📝 課題
あなたのタスク: 上記プロジェクトのWBSを、作業パッケージ単位（1〜2週間で完了できる粒度）まで分解して表形式で作成してください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- まず大きなフェーズ（要件定義/設計/実装/テスト/リリース準備）に分け、そこから機能単位・技術要素単位に分解していく
- 「実装する」だけでなく「悪質レビュー自動検知ロジックの実装」のように具体的な粒度まで割ること
- 悪質レビュー検知は自動化だけで完結させると誤検知のリスクがあるため、人力確認フローも独立した作業パッケージとして扱う
- ポイントは金銭的価値を持つため、経理・会計への影響確認を要件定義の早い段階に入れる
- 重複投稿防止やランキング表示など、目立たないが要件に明記されている要素を漏らさないこと（100%ルール）
📚 背景知識・用語解説
WBS（Work Breakdown Structure、作業分解構造）とは、プロジェクトのスコープ全体を、管理・見積もりが可能な単位まで階層的に分解したものです。単なるタスクリストと違い、「プロジェクトの成果物」を起点に分解していく点が特徴です。タスク（動詞ベース）ではなく成果物（名詞ベース）で考えると、「言われた作業だけ並べて肝心な成果物を作り忘れる」抜け漏れに気づきやすくなります。
作業パッケージ（Work Package）: WBSの最下層、実際にアサイン・見積もりの対象になる単位。目安として1〜2週間で完了できる粒度に分解します。これより粗いと「今どこまで進んでいるか」が見えず、遅延に気づくのが遅れます。逆に細かすぎると管理コスト（進捗確認・報告のオーバーヘッド）が増えて非効率になります。
WBSとタスクリストの違い: タスクリストは思いついた順に並ぶ「To-Doの羅列」になりがちですが、WBSはフェーズ→機能→作業パッケージという階層構造を持ち、抜け漏れを構造的にチェックできる点が異なります。
✅ 模範解答
| コード | フェーズ / 作業パッケージ | 見積もり | 担当ロール |
|---|---|---|---|
| 1.0 | 要件定義 | ||
| 1.1 | レビュー投稿条件（文字数・ポイント額・NGワード基準）のヒアリング・要件確定 | 2日 | エンジニア/マーケ |
| 1.2 | 悪質レビューパターンの洗い出し（コピペ・文字数水増し・過去の問題事例の収集） | 2日 | エンジニア |
| 1.3 | ポイント付与の会計・経理処理への影響確認 | 1日 | エンジニア/経理 |
| 2.0 | 設計 | ||
| 2.1 | レビュー投稿・ポイント付与のDB・API設計 | 4日 | エンジニア |
| 2.2 | 悪質レビュー自動検知ロジックの設計（NGワード辞書・文字数閾値・画像有無判定） | 4日 | エンジニア |
| 2.3 | 人力レビュー承認フロー（保留→運営確認→承認/却下）の設計 | 3日 | エンジニア |
| 2.4 | マイページ「レビュー履歴・獲得ポイント」画面＆月間ランキング画面のUI設計 | 3日 | デザイナー |
| 3.0 | 実装 | ||
| 3.1 | レビュー投稿フォーム（星評価・テキスト・写真アップロード）の実装 | 4日 | エンジニア |
| 3.2 | レビュー投稿完了時のポイント自動付与処理の実装 | 3日 | エンジニア |
| 3.3 | 悪質レビュー自動検知ロジックの実装 | 6日 | エンジニア |
| 3.4 | 運営向け人力レビュー承認管理画面の実装 | 4日 | エンジニア |
| 3.5 | マイページ「レビュー履歴」画面・月間ランキング画面の実装 | 4日 | エンジニア/デザイナー |
| 3.6 | 同一会員・同一商品の重複レビュー投稿防止ロジックの実装 | 2日 | エンジニア |
| 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日 | エンジニア |
合計見積もり: 約58人日（6週間・体制4名で並行作業する前提と整合）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「悪質レビュー検知」を実装(3.3)だけの一行で済ませる | 誤検知時の運用対応（人力承認フロー）が抜け落ち、リリース後に「正当なレビューがブロックされた」というクレーム対応に追われる | 検知ロジックの設計・実装に加え、人力確認フローを独立した作業パッケージとして必ず立てる |
| 重複レビュー投稿防止をWBSに明記しない | 要件に明記されているのに見積もりから漏れ、100%ルール違反になる。実装終盤に「あ、これも必要だった」と気づき手戻りが発生する | 要件一覧とWBSの作業パッケージを突き合わせ、全要件がどこかの作業パッケージでカバーされているか確認する |
| ポイントという金銭的価値を伴う機能で経理連携を書き忘れる | リリース直前に経理側の承認プロセスが未整備であることが発覚し、リリースが止まる | 「お金・ポイントが動く機能」では要件定義の段階で経理・会計への影響確認を作業パッケージとして必ず入れる |
| 見積もりを楽観値だけで出す | バッファがなく、少しの遅延で全体が破綻する | 不確実性の高い作業パッケージ（悪質レビュー検知ロジック等）は三点見積もり（PERT）でリスクを織り込む |
🏆 実務での使いどころ
WBSはキックオフ後の最初の成果物として、PMだけでなくエンジニアも作成に関わることが多いです。特に「見積もりの根拠をチームリードや非エンジニアの関係者に説明する」場面で、WBSの粒度がそのまま説得力になります。今回のようにポイント（金銭的価値）が絡む機能では、経理・会計との連携作業や、自動検知だけに頼らない人力確認フローをWBSに明示的に含められるかどうかが、エンジニアとしての視野の広さの評価につながります。エンジニアがWBS作成に主体的に関わると、後工程での「言った/言わない」の齟齬が減り、スケジュール遅延時にも「どの作業パッケージで遅れているか」を具体的に説明できます。
🚀 次のステップ
このWBSから、次はテーマ1-2「見積もり手法（三点見積もり）」を使って、不確実性の高い作業パッケージ（3.3 悪質レビュー自動検知ロジックの実装など）を楽観値・悲観値・最頻値からPERT期待値で見積もり直してみましょう。単一の見積もり日数だけでは見えないリスクバッファの必要性が見えてくるはずです。