🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「ポイント有効期限リマインド通知機能」の開発が決まった。会員が保有するポイントの失効が近づくと、メール・アプリPUSH・LINE通知のいずれか（会員が選択したチャネル）で事前に知らせる機能で、CS（カスタマーサポート）部門から「有効期限切れの問い合わせが月間300件以上あり、通知があれば大きく減らせるはず」という要望が発端になっている。
体制はエンジニア2名（あなたともう1名）・デザイナー1名、8週間でのリリースを目指す。
要件:
- 会員ごとのポイント失効日をバッチで計算し、失効30日前・7日前・前日の3タイミングで通知を送る
- 通知チャネルは会員が設定画面で選択（メール/PUSH/LINE、複数選択可）
- 通知文言には失効予定ポイント数と失効日を動的に埋め込む
- 通知経由でポイント利用ページに遷移できるディープリンクを付与する
- 外部のLINE公式アカウント連携APIを新規に利用する（このチームでは初めての連携）
📝 課題
あなたのタスク: 上記プロジェクトについて、ブレインストーミング＋過去プロジェクトのチェックリスト活用の2つの手法を使ってリスクを洗い出し、簡易リスク登録簿（内容/カテゴリ/発生確率/影響度/想定される引き金）の形式で最低8件以上まとめてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- ブレインストーミングは「技術面」「外部依存面」「業務・運用面」「人・体制面」のように切り口を変えて発散させると偏りが減る
- 「過去プロジェクトのチェックリスト活用」とは、自チームや近い性質のプロジェクトで過去に起きた問題を思い出し、同じことが今回も起きないかを点検する手法。今回は「過去にも通知系機能で本番障害があった」というヒントが与えられているので、それを深掘りする
- この段階ではまだ「対応策」までは決めなくてよい（対応戦略の設計はテーマ2-5で扱う）。まずは「何が起きうるか」を広く・具体的に洗い出すことに集中する
- 外部API（LINE連携）のような「初めて扱う要素」は要注意ポイントになりやすい
- リスクは「〇〇によって△△が起きる可能性がある」のように、原因と結果をセットで書くと後工程（対応戦略の検討）で扱いやすくなる
📚 背景知識・用語解説
リスク特定（Risk Identification）とは、プロジェクトに影響を与えうる不確実な事象を、できるだけ早い段階で・できるだけ網羅的に洗い出す活動です。設計や実装が進んでからリスクに気づくと、手戻りのコストが跳ね上がるため、キックオフ直後のこの段階でまとめて行うのが定石です。
ブレインストーミング（発散的手法）: 制約を設けず自由にリスクを出し合う手法。ただし完全に自由だと視点が偏りやすいため、実務では「技術」「外部依存」「業務・運用」「人・体制」「スケジュール」のようにカテゴリの切り口を用意して、各カテゴリで最低1件は出す、という運用が有効です。
過去プロジェクトのチェックリスト活用（収束的手法）: 自社・自チームで過去に実際に起きた問題（インシデント・障害・炎上プロジェクトの振り返り記録など）をリストとして持っておき、新規プロジェクトのキックオフ時に「これは今回も起きうるか？」と機械的に照らし合わせる手法。ゼロから発想するより見落としが少なく、再発防止の観点からも有効です。
リスクの記載粒度: 「通知が遅れるかもしれない」のような曖昧な書き方では対応策を検討しづらくなります。「バッチ処理が失効日計算の対象会員数増加により想定時間内に終わらず、通知が失効当日に間に合わない可能性がある」のように、原因（引き金）・対象・結果をセットで書くのがコツです。
✅ 模範解答
ブレインストーミング（切り口別）
① 技術面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R1 | 会員数増加に伴い、失効日計算バッチが夜間バッチウィンドウ内に終わらず、通知が失効当日に間に合わない | 中 | 高 | 対象会員数が想定（現行会員数ベース）を超えて増加した場合、または他バッチとのリソース競合 |
| R2 | 通知文言への動的埋め込み（失効ポイント数・失効日）で、タイムゾーンや金額表示の実装ミスにより誤った内容が配信される | 中 | 高 | 実装時のテストケース漏れ（境界値：失効当日ちょうど等） |
| R3 | ディープリンクの遷移先パラメータ設計ミスで、通知をタップしても正しいポイント利用ページに遷移しない | 低 | 中 | アプリ側・Web側でディープリンクの仕様が食い違う |
② 外部依存面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R4 | LINE公式アカウント連携APIがチーム初導入のため、認証・レート制限・メッセージフォーマットの仕様理解に想定以上の時間がかかる | 高 | 中 | チーム内にLINE API連携の実装経験者がいない |
| R5 | LINE API側のレート制限に達し、大量配信タイミング（失効7日前一斉通知等）で送信遅延・失敗が発生する | 中 | 高 | 会員数に対してLINE側の送信可能件数/秒の上限が想定より低い |
③ 業務・運用面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R6 | 通知内容とポイント残高の実際の値がずれて表示され、CSへの問い合わせが減るどころか「表示がおかしい」という新規問い合わせが増える | 中 | 高 | バッチ実行時点と会員がページを見た時点の間にポイント利用があり、表示に差分が出る |
| R7 | 通知チャネル選択（複数選択可）の初期値・未設定会員への扱いが要件として詰め切れておらず、リリース直前に仕様の揺り戻しが起きる | 中 | 中 | マーケ部門・CS部門との要件合意が口頭ベースで文書化されていない |
④ 人・体制面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R8 | エンジニア2名体制のため、どちらか1名が急な離脱（体調不良・異動等）をすると代替要員がおらずスケジュールが即座に崩れる | 低 | 高 | 属人化（LINE連携部分を1名のみが把握している等） |
過去プロジェクトのチェックリスト活用
「過去にも通知系機能で本番障害があった」というヒントを深掘りし、過去の通知系プロジェクトで実際に起きたパターンを照らし合わせる。
| No | 過去に起きたこと（チェック項目） | 今回のプロジェクトへの当てはめ | 発生確率 | 影響度 |
|---|---|---|---|---|
| R9 | 過去のクーポン失効通知機能で、テスト環境の会員データがそのまま本番配信バッチの対象に混入し、テスト用の不正なポイント数が実会員に配信された | 今回もバッチ対象の抽出条件（本番会員のみ）を誤ると同様の事故が起きうる。テスト環境と本番環境のデータ分離チェックが必須 | 低 | 高 |
| R10 | 過去のセール開始通知で、PUSH通知の一斉配信時に配信基盤の同時接続上限に達し、一部会員に通知が届かなかった | 失効7日前・前日は対象会員が集中しやすいタイミングであり、同様の配信集中が起きうる | 中 | 中 |
| R11 | 過去の類似機能で、退会済み会員・ポイント無効会員へのバッチ対象抽出条件の考慮漏れがあり、退会後にも通知が届いてクレームになった | 今回も対象抽出条件（有効会員のみ・ポイント保有者のみ）の定義を要件定義段階で明確化しておく必要がある | 中 | 中 |
合計: 11件のリスクを洗い出し（技術3件、外部依存2件、業務・運用2件、人・体制1件、過去事例照合3件）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 技術的なリスクだけを列挙する | 業務要件のすり合わせ不足や体制リスクを見落とし、実装は正しくてもプロジェクトが失敗する | 技術/外部依存/業務・運用/人・体制のように切り口を分けて発散させる |
| 「バグが出るかもしれない」のような曖昧な書き方をする | 対応戦略を検討する段階で、何をどう対応すればいいか判断できない | 原因（引き金）・対象・結果をセットで具体的に書く |
| 過去の障害事例を参照せず、毎回ゼロから発想する | 同じ失敗を繰り返す。チェックリスト化されたノウハウが活用されない | キックオフ時に必ず「過去に似た機能で何が起きたか」を確認するステップを設ける |
| リスクと課題（すでに起きていること）を混同する | リスク登録簿に「対応中の課題」が混ざり、優先度判断がぶれる | 「まだ起きていないか」を基準に、すでに起きていることは課題管理表に分離する |
🏆 実務での使いどころ
リスク特定はキックオフ直後、まだ設計に入る前のタイミングで行うのが最も効果的です。設計・実装が進んでから「実はこれリスクだったのでは」と気づくと、すでに前提にしてしまった設計をやり直すコストが発生します。エンジニアがこの段階から関わることで、「技術的には実現可能だが、外部APIの制約で想定通りに動かないかもしれない」といった、PMだけでは気づきにくい技術寄りのリスクを早期に拾い上げられます。また、洗い出したリスク一覧はこの後の発生確率×影響度マトリクス（テーマ2-3）や対応戦略の検討（テーマ2-5）の入力にもなるため、この段階で粒度・具体性を揃えておくことが後工程の質に直結します。
🚀 次のステップ
洗い出した11件のリスクを、次は発生確率×影響度マトリクス（テーマ2-3）で4象限に整理し、どのリスクから優先的に対応戦略を検討すべきかを判断してみましょう。特にR1（バッチ遅延）とR4/R5（LINE API連携）は、発生確率・影響度ともに軽視できない組み合わせになりそうです。