🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「誕生日月限定クーポン自動発行機能」の開発が決まった。会員の誕生日月に、自動で特別クーポン（購入金額の10%OFF、上限3,000円）をメール・アプリ内通知で配信する販促施策で、マーケティング部門から「離脱防止とロイヤルティ向上のため、今期中に必ず入れたい」という要望が発端になっている。
体制はエンジニア2名（あなたともう1名）・マーケティング担当1名、5週間でのリリースを目指す。
要件:
- 会員の誕生日情報は、社内の別チームが運用する会員基盤（CRM）から、毎月1日 朝5時の日次バッチで取得する（このチームがCRMバッチ連携を使うのは初めてではないが、これほど大規模な一斉配信に使うのは初めて）
- 誕生日月に該当する会員（月平均7,500人）に対し、月初1営業日にまとめてクーポンをメール＋アプリ内通知で一斉配信する
- クーポンの有効期限は配布月の月末まで（会員の誕生日によって有効日数が1日〜31日とばらつく）
- 退会済み会員・メール配信停止設定をしている会員には配信しない
- 過去に「全会員向け一斉セールメール」を配信した際、配信基盤の送信キューが詰まり、一部会員への到達が翌日にずれ込んだ実績がある
- 過去に別の販促施策で、退会済み会員へ販促メールが誤って送信され、CS部門に苦情が入った実績もある
📝 課題
あなたのタスク: 上記プロジェクトについて、ブレインストーミング＋過去プロジェクトのチェックリスト活用の2つの手法を使ってリスクを洗い出し、簡易リスク登録簿（内容/カテゴリ/発生確率/影響度/想定される引き金）の形式で最低8件以上まとめてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- ブレインストーミングは「技術面」「外部依存面」「業務・運用面」「人・体制面」のように切り口を変えて発散させると偏りが減る
- 「過去プロジェクトのチェックリスト活用」とは、自チームや近い性質のプロジェクトで過去に実際に起きた問題を思い出し、同じことが今回も起きないかを点検する手法。今回は「配信キュー詰まりで到達が遅れた」「退会済み会員への誤送信でCS苦情が入った」という2つの過去事例が与えられているので、両方を深掘りする
- この段階ではまだ「対応策」までは決めなくてよい（対応戦略の設計はテーマ2-5で扱う）。まずは「何が起きうるか」を広く・具体的に洗い出すことに集中する
- 「他チームが運用する外部システム（CRM）」との連携は、自チームでスケジュールや品質を完全にはコントロールできない点が要注意ポイント
- 誕生日という個人情報を扱う施策のため、「意図しない相手に届く／届かない」という不整合のケースも洗い出す
- リスクは「〇〇によって△△が起きる可能性がある」のように、原因と結果をセットで書くと後工程（対応戦略の検討）で扱いやすくなる
📚 背景知識・用語解説
リスク特定（Risk Identification）とは、プロジェクトに影響を与えうる不確実な事象を、実際に発生する前に洗い出す活動です。設計や実装に着手してから「こんなリスクがあった」と気づくのでは手遅れになりやすいため、通常はキックオフ直後、要件が固まった段階で行います。
ブレインストーミングは、参加者が自由に思いつくリスクを発散的に出し合う手法です。ただし何も切り口がないと「思いつきやすいリスク」に偏りがちなので、次の4カテゴリを先に用意してから発散させると抜け漏れが減ります。
| カテゴリ | 内容 | 例 |
|---|---|---|
| 技術面 | 実装・設計・性能に起因するリスク | 処理性能不足、データ不整合 |
| 外部依存面 | 自チームの管理外にあるシステム・部門に起因するリスク | 他チーム運用システムの遅延、外部配信基盤の仕様変更 |
| 業務・運用面 | 運用ルール・体制・意思決定プロセスに起因するリスク | 仕様の未確定、トラブル時の判断基準が未定義 |
| 人・体制面 | メンバーのスキル・稼働・離脱に起因するリスク | 兼任によるリソース不足、経験不足 |
過去プロジェクトのチェックリスト活用は、自チームや類似プロジェクトで過去に実際に起きた問題を思い出し、「同じ原因が今回のプロジェクトにも存在しないか」を1件ずつ点検していく手法です。ゼロから発想するブレインストーミングと違い、「実際に一度起きたこと」を起点にするため、発生確率の見積もりに実績の裏付けが持てるのが強みです。
この段階ではリスクへの「対応策」までは決めません。対応策を早く決めすぎると、洗い出し自体が浅くなり（「対応できそうなリスクしか書かない」という無意識のバイアスがかかる）、重大リスクの見落としにつながるためです。まずは広く・具体的に「何が起きうるか」を出し切ることに集中します。
✅ 模範解答
ブレインストーミング（切り口別）
① 技術面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R1 | 月初一斉配信（月平均7,500件）が配信基盤の送信キューで詰まり、一部会員への到達が翌日以降にずれ込む | 高 | 高 | 過去の全会員向け一斉セールメールで同様の事象が実際に発生している。今回はさらに「誕生日月限定」という個人向け特別感を訴求する施策のため、到達が遅れると会員の信頼低下に直結しやすい |
| R4 | CRMから取得した誕生日データに不正値（存在しない日付、未入力、システム移行時の初期値等）が混在し、対象会員の抽出処理でエラーが発生する | 中 | 中 | 誕生日データはCRM側で長年運用されてきた項目で、任意入力・過去の手動登録も含まれるため、クレンジングされていないレコードが一定数残っている可能性がある |
| R9 | クーポン有効期限（配布月の末日まで）の計算ロジックが、31日ある月と28日（うるう年は29日）の月の違いを正しく扱えず、有効日数の計算に不具合が出る | 低 | 中 | 「月末まで」という相対的な期限指定は、月ごとに日数が変わるため実装時にハードコーディングの誘惑が生じやすく、テストケースが2月に偏らないと見落とされやすい |
② 外部依存面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R2 | CRMの日次バッチが5時に完了しない場合、当日の配信対象抽出ができず月初1営業日の配信スケジュール全体がずれ込む | 中 | 高 | CRMは他チームが運用しており、自チームにはバッチの完了時刻やSLAをコントロールする権限がない。過去の完了実績（成功率・遅延頻度）もまだ確認できていない |
| R3 | 退会済み会員・配信停止設定をした会員へ、フラグ反映のタイムラグにより誤ってクーポンメールが届く | 中 | 高 | 過去に別の販促施策で同種の誤送信が実際に発生し、CS部門に苦情が入った実績がある。CRM側のフラグ更新タイミングと自チームのバッチ取得タイミングの間にズレが生じる余地がある |
| R6 | メール配信基盤（外部ASP等）の送信可否判定・宛先エラー時の挙動をチームが正確に把握しないまま実装に入り、後半で想定外の挙動に気づく | 中 | 中 | 配信基盤の詳細仕様（バウンス処理、再送ポリシー等）はドキュメントが古い、または過去の実装担当者が既にチームを離れており、正確な仕様を把握しているメンバーが少ない |
③ 業務・運用面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R5 | クーポン割引率（10%）・上限額（3,000円）の最終値がマーケティング部門内で未確定のまま開発に着手し、実装後半で数値変更の依頼が入る | 中 | 中 | 割引原資の予算確保がマーケティング部門の別会議体で並行して進んでおり、開発着手時点ではまだ経営層の最終承認が下りていない |
| R7 | 配信トラブル（一部未達・二重配信等）が発生した際、誰がどの基準で再送や会員への謝罪対応を判断するかが決まっていない | 中 | 高 | 過去の誤送信トラブル時も、CS部門への一次対応とエンジニアチームへのエスカレーションの役割分担が曖昧なまま対応が後手に回った経緯がある |
| R10 | 「誕生日月」の判定基準（暦月で区切るのか、誕生日から起算した30日間なのか）について、マーケティング部門とエンジニアの間で認識の齟齬がある | 中 | 中 | 要件定義の会話の中で「誕生日月」という言葉が双方で使われているが、月末生まれの会員の扱い（前月扱いか当月扱いか）まで具体的にすり合わせた記録がない |
④ 人・体制面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R8 | エンジニア2名のうち1名が既存の販促システムの保守と兼任しており、5週間のうち本プロジェクトに割ける時間が読みにくい | 中 | 中 | MOpsチームは少人数体制で、保守対応は優先度が高い障害対応も含むため、突発的な保守稼働がいつ発生するか事前に見通しづらい |
発生確率・影響度の目安: 高＝プロジェクト中に70%以上の確率で発生しうる／全体のリリース可否や会員の信頼に関わる影響、中＝30〜70%程度／一部機能や一部会員に限定的な影響、低＝30%未満／軽微または局所的な影響
🗂️ 過去プロジェクトのチェックリスト活用
「配信キュー詰まりによる到達遅延」と「退会済み会員への誤送信」というヒントを深掘りし、過去に実際に起きたパターンを今回のプロジェクトに照らし合わせる。
| 過去に起きたこと | 今回のプロジェクトの同じ引き金 | 該当リスク |
|---|---|---|
| 全会員向け一斉セールメール配信時、送信キューが詰まり一部会員への到達が翌日にずれ込んだ | 今回も月初1営業日に7,500件規模の一斉配信を行う。さらに「誕生日月限定」という会員個人に紐づく特別感を訴求する施策のため、到達遅延が起きた場合の会員体験への悪影響は一斉セールより大きい可能性がある | R1 |
| 退会済み会員へ販促メールが誤送信され、CS部門に苦情が入った | 今回も退会済み・配信停止会員の除外はCRM側のフラグに依存している。フラグの反映タイミングと自チームのバッチ取得タイミングの間にズレが生じる構造は前回と変わっていない | R3 |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「他チーム運用のシステムだから」とCRM側のリスク（R2・R3）を自分たちの登録簿に書かない | 自チームがコントロールできないリスクほど、事前に洗い出して連携先と合意しておかないと、発生時に責任の所在が曖昧なまま対応が遅れる | 管理外のシステムに起因するリスクこそ「外部依存面」として明示的に登録し、連携先との合意事項（SLA、フラグ反映タイミング等）を確認するアクションにつなげる |
| 過去の障害事例を「今回は気をつける」で済ませ、具体的なリスク項目に落とし込まない | チェックリスト活用の本来の価値（実績に基づく発生確率の裏付け）が失われ、単なる精神論になる | 過去事例を「今回のプロジェクトのどの要素が同じ引き金を持っているか」まで分解して記述する（R1・R3のように） |
| 洗い出しの段階でいきなり対応策まで書いてしまう | 「対応できそうなもの」しか書かなくなり、対応が難しい重大リスク（R2のような自チームで制御できないもの）を無意識に避けてしまう | まずは「何が起きうるか」だけを出し切り、対応策の検討は次のステップに分離する |
🏆 実務での使いどころ
リスクの洗い出しは、設計に入る前のキックオフ直後に行うのが最も効果的です。この段階で洗い出したリスクは、そのまま設計判断に反映できます（例: R3のフラグ反映タイムラグを先に洗い出しておけば、設計時に「配信直前にもう一度最新の除外フラグを再確認する」といった安全側の設計を最初から組み込めます）。
エンジニアがこの活動に主体的に関わる価値は、技術的な実現可能性を踏まえたリスク（R1・R4・R6・R9のような項目）を、PMやマーケティング担当者だけでは出せない解像度で洗い出せる点にあります。逆にR5・R7・R10のような業務プロセスのリスクは、エンジニア単独では気づきにくいため、マーケティング担当者やCS部門を巻き込んだブレインストーミングにする価値があります。
🚀 次のステップ
洗い出した10件のリスクを、次はテーマ2-2（リスク登録簿の書き方）で正式なリスク登録簿の形式（オーナー・対応期限・ステータス等の項目を追加）に整理してみましょう。特にR1（配信到達遅延）とR3（誤送信）は過去に実際に発生した実績があるため、どのような記載項目を追加すればチーム外の人が見てもリスクの重大さと対応状況が一目で分かるか、考えてみてください。