🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「友達紹介キャンペーン（リファラルプログラム）」の開発が決まった。既存会員に1人1つの招待コード（8桁英数字）を発行し、LINE・SMS・メールで友人に共有できるようにする。招待された友人が招待コードを使って新規会員登録し、初回注文が確定（返品期間7日経過後に確定とみなす）すると、招待した会員・招待された会員の双方に1,000ポイントを自動付与する施策で、マーケティング部門から「来期の新規会員獲得の主要施策として最重要KPIに据えたい」という強い要望が発端になっている。
体制はエンジニア3名（あなたともう2名）・マーケティング担当1名、6週間でのリリースを目指す。
要件:
- 招待コードは会員ごとに1つ発行する8桁英数字。重複は不可
- 招待リンクの共有には、LINE・SMSへの送信ができる外部SDKを新規導入する（このチームがこの外部SDKを使うのは初めて）
- ポイント付与は「新規登録 → 初回注文確定 → 返品期間7日経過」の条件を満たした会員を対象に、日次バッチで非同期に判定・付与する
- ポイント原資の予算は月間300万円が上限で、超過が見込まれる場合はキャンペーンを自動停止する想定になっている
- 決済代行会社がクレジットカード情報を保持しており、自社システム側からは同一カード番号での直接突合ができない制約がある
- 過去に「期間限定クーポンコード」施策を実施した際、コードがSNS上で無制限に拡散され想定の20倍利用され、原資が予算超過し経理部門から厳しく指摘を受けた実績がある
- 他社の同種のリファラル施策で「家族間の紹介や自分の別アカウントを使った自己紹介」による不正ポイント取得が問題化した事例を、マーケティング部門が共有してきた
📝 課題
あなたのタスク: 上記プロジェクトについて、ブレインストーミング＋過去プロジェクトのチェックリスト活用の2つの手法を使ってリスクを洗い出し、簡易リスク登録簿（内容/カテゴリ/発生確率/影響度/想定される引き金）の形式で最低8件以上まとめてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- ブレインストーミングは「技術面」「外部依存面」「業務・運用面」「人・体制面」のように切り口を変えて発散させると偏りが減る
- 「過去プロジェクトのチェックリスト活用」とは、自チームや近い性質のプロジェクトで過去に実際に起きた問題を思い出し、同じことが今回も起きないかを点検する手法。今回は「クーポンコードのSNS拡散による原資超過（自社事例）」「自己紹介による不正ポイント取得（他社事例）」という2つの事例が与えられているので、両方を深掘りする
- この段階ではまだ「対応策」までは決めなくてよい（対応戦略の設計はテーマ2-5で扱う）。まずは「何が起きうるか」を広く・具体的に洗い出すことに集中する
- 「決済代行会社の制約で同一カード番号を直接突合できない」という技術的制約は、不正検知の設計そのものを難しくする要因として要注意
- ポイントは会員にとって実質的に金銭価値を持つため、「意図せず多く付与される／意図せず付与されない」の両方向の不整合を洗い出す
- リスクは「〇〇によって△△が起きる可能性がある」のように、原因と結果をセットで書くと後工程（対応戦略の検討）で扱いやすくなる
📚 背景知識・用語解説
リスク特定（Risk Identification）とは、プロジェクトに影響を与えうる不確実な事象を、実際に発生する前に洗い出す活動です。設計や実装に着手してから「こんなリスクがあった」と気づくのでは手遅れになりやすいため、通常はキックオフ直後、要件が固まった段階で行います。
ブレインストーミングは、参加者が自由に思いつくリスクを発散的に出し合う手法です。ただし何も切り口がないと「思いつきやすいリスク」に偏りがちなので、次の4カテゴリを先に用意してから発散させると抜け漏れが減ります。
| カテゴリ | 内容 | 例 |
|---|---|---|
| 技術面 | 実装・設計・性能に起因するリスク | 処理性能不足、データ不整合 |
| 外部依存面 | 自チームの管理外にあるシステム・部門に起因するリスク | 他チーム運用システムの遅延、外部SDK・決済代行会社の制約 |
| 業務・運用面 | 運用ルール・体制・意思決定プロセスに起因するリスク | 判定基準の未確定、トラブル時の対応フローが未定義 |
| 人・体制面 | メンバーのスキル・稼働・離脱に起因するリスク | 特定領域の経験者不在、兼任によるリソース不足 |
過去プロジェクトのチェックリスト活用は、自チームや類似プロジェクトで過去に実際に起きた問題を思い出し、「同じ原因が今回のプロジェクトにも存在しないか」を1件ずつ点検していく手法です。ゼロから発想するブレインストーミングと違い、「実際に一度起きたこと」を起点にするため、発生確率の見積もりに実績の裏付けが持てるのが強みです。
この段階ではリスクへの「対応策」までは決めません。対応策を早く決めすぎると、洗い出し自体が浅くなり（「対応できそうなリスクしか書かない」という無意識のバイアスがかかる）、重大リスクの見落としにつながるためです。まずは広く・具体的に「何が起きうるか」を出し切ることに集中します。
✅ 模範解答
ブレインストーミング（切り口別）
① 技術面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R1 | 招待コード生成時に重複チェック処理が同時実行された場合、競合状態（レースコンディション）により同一コードが2人の会員に発行される | 低 | 中 | 8桁英数字の組み合わせ空間自体は十分広いが、生成と重複チェックを1つのトランザクションで原子的に行わないと、瞬間的な同時発行のタイミングで重複が漏れる余地がある |
| R2 | ポイント付与判定バッチが「初回注文確定」と「返品期間7日経過」を跨いで非同期に動くため、判定処理の途中で注文がキャンセル・返品されるとポイントの二重付与や誤付与が発生する | 中 | 高 | 判定ロジックが日次バッチ実行時点のスナップショットに依存する場合、バッチ実行後〜次回実行までの間に発生した状態変化（キャンセル等）を正しく反映できない設計になりやすい |
| R3 | 招待コード入力欄で、紛らわしい文字（0とO、1とIとl等）の誤入力によりコードが一致せず、CS部門への問い合わせが増加する | 中 | 低 | 8桁英数字という文字種の広いコード形式は視認性への配慮が実装時に後回しにされやすく、入力補助（大文字小文字を区別しない、紛らわしい文字を除外する等）がないと発生しやすい |
② 外部依存面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R4 | LINE・SMS送信の外部SDKを初めて導入するため、送信失敗率や仕様変更、事業者側の審査・申請に要する期間が事前に見積もれず、6週間のスケジュールに影響する | 中 | 中 | 自チームがこの外部SDKを使った実装経験がなく、ドキュメントベースの想定と実際の挙動（レート制限、審査リードタイム等）にズレが生じる可能性がある |
| R5 | 決済代行会社の制約により自社システムから同一クレジットカード番号での直接突合ができないため、「自分の別アカウントを使った自己紹介」を技術的に検知する手段が限定される | 高 | 高 | クレジットカード情報の非保持化（PCI DSS対応）は決済代行会社側の仕様であり、自チームの実装だけでは変更できない制約であるため、不正検知の設計余地が最初から狭い |
③ 業務・運用面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R6 | ポイント原資予算（月間300万円）への到達が見込まれる際、自動停止のトリガー条件（何をもって「到達見込み」とするか）と、判定から実際の停止までのタイムラグの許容範囲がマーケティング部門と合意されていない | 高 | 高 | 「上限に達したら自動停止する」という方針だけがキックオフで共有されており、判定タイミング（リアルタイムか日次集計か）や停止までのラグの許容値が具体的に詰められていない |
| R7 | 「同居家族間の紹介」のような自己紹介とは言い切れないグレーゾーンの許容基準がマーケティング部門と合意されておらず、CS部門が問い合わせ対応時に判断できない | 中 | 中 | 他社事例として「自己紹介による不正取得」が共有されたことで警戒感はあるが、「どこまでを不正とみなすか」という線引きの議論自体がまだ行われていない |
| R8 | ポイント付与のタイミング（新規登録直後ではなく、初回注文確定後さらに返品期間7日経過後）が会員から見て分かりにくく、「ポイントが付与されない」という問い合わせが集中する | 高 | 低 | 「友達紹介で1,000ポイント」という訴求文言だけが先行し、付与条件・タイミングの説明が招待画面やヘルプページでどこまで丁寧に案内されるか、コンテンツ設計がまだ固まっていない |
| R9 | 招待実績（誰が何人紹介し何ポイント付与されたか）を集計・レポーティングする要件が定義されておらず、マーケティング部門が施策のROI（獲得単価）を測定できない | 中 | 中 | 要件定義が「ポイント付与の実装」に集中しており、施策の効果測定に必要なデータ集計・可視化の要件がキックオフ時点でまだ言語化されていない |
④ 人・体制面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R10 | 不正検知ロジックの実装・チューニング経験があるメンバーがチームにおらず、R5・R7で洗い出した不正利用リスクへの設計対応が妥当かどうかを自チームだけで判断しきれない | 中 | 中 | MOpsチームはこれまで販促システムの機能開発が中心で、ポイントという金銭価値を伴う施策の不正対策設計に特化した知見の蓄積がまだ薄い |
発生確率・影響度の目安: 高＝プロジェクト中に70%以上の確率で発生しうる／全体のリリース可否や原資・会員の信頼に関わる影響、中＝30〜70%程度／一部機能や一部会員に限定的な影響、低＝30%未満／軽微または局所的な影響
🗂️ 過去プロジェクトのチェックリスト活用
「クーポンコードのSNS拡散による原資超過（自社事例）」と「自己紹介による不正ポイント取得（他社事例）」というヒントを深掘りし、過去に実際に起きたパターンを今回のプロジェクトに照らし合わせる。
| 過去に起きたこと | 今回のプロジェクトの同じ引き金 | 該当リスク |
|---|---|---|
| 期間限定クーポンコードがSNS上で無制限に拡散され、想定の20倍利用されて原資が予算超過し、経理部門から指摘を受けた（自社事例） | 今回のコードは会員1人につき1つの個人専用コードだが、そのコード自体がSNSに投稿・拡散されれば不特定多数が利用できてしまう構造は変わらない。原資上限（月間300万円）到達時の自動停止の基準・タイムラグが未確定なままだと、前回と同じ規模の超過が再発しうる | R6 |
| 家族間の紹介や自分の別アカウントを使った自己紹介による不正ポイント取得が問題化した（他社事例） | 決済代行会社の制約で同一クレジットカードでの直接突合ができないため、技術的な不正検知手段が最初から限られている。加えて「どこまでを不正とみなすか」というグレーゾーンの線引きも未合意で、他社と同じ構造の問題が起きる土壌が今回も存在する | R5・R7 |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「ポイント付与のロジックさえ正しく実装すれば大丈夫」と技術リスクだけに集中し、R6〜R9のような業務ルールの未確定を見落とす | 原資上限の停止基準やグレーゾーンの判断基準が未合意のままリリースすると、実装は正しくても運用開始直後にトラブルが起きる | 技術・外部依存だけでなく、業務・運用面（誰がいつ何を判断するか）も同じ重みで洗い出しの対象に含める |
| 他社事例を「うちは大丈夫だろう」と自社事例より軽く扱う | 自社で一度も起きていないというだけで、同じ施策構造（招待コード×ポイント付与×検知手段が限られる）であれば同じ問題が起きる可能性は自社事例と変わらない | 他社事例も「今回のプロジェクトのどの要素が同じ引き金を持っているか」まで自社事例と同じ解像度で分解する |
| 洗い出しの段階でいきなり対応策まで書いてしまう | 「対応できそうなもの」しか書かなくなり、対応が難しい重大リスク（R5のような技術的制約に起因するもの）を無意識に避けてしまう | まずは「何が起きうるか」だけを出し切り、対応策の検討は次のステップに分離する |
🏆 実務での使いどころ
リスクの洗い出しは、設計に入る前のキックオフ直後に行うのが最も効果的です。この段階で洗い出したリスクは、そのまま設計判断に反映できます（例: R2の二重付与リスクを先に洗い出しておけば、設計時に「付与直前に注文ステータスを再確認する」といった安全側の設計を最初から組み込めます）。
エンジニアがこの活動に主体的に関わる価値は、技術的な実現可能性を踏まえたリスク（R1・R2・R3・R9のような項目）を、PMやマーケティング担当者だけでは出せない解像度で洗い出せる点にあります。逆にR6〜R8のような業務プロセスのリスクは、エンジニア単独では気づきにくいため、マーケティング担当者やCS部門、原資予算を管理する経理部門を巻き込んだブレインストーミングにする価値があります。
🚀 次のステップ
洗い出した10件のリスクを、次はテーマ2-2（リスク登録簿の書き方）で正式なリスク登録簿の形式（オーナー・対応期限・ステータス等の項目を追加）に整理してみましょう。特にR5（自己紹介の技術的検知の限界）とR6（原資上限の自動停止基準未確定）は、対応策の設計自体に時間がかかりそうなリスクのため、どのような記載項目を追加すれば「まだ対応方針が決まっていない」こと自体をチーム外の人にも分かるように示せるか、考えてみてください。