🎬 シナリオ
MOps（Marketing Ops/販促システム）チームで「在庫連動フラッシュセール機能」の開発が決まった。特定商品を対象に、開始時刻ぴったりに「残り◯点」のカウンター表示とカウントダウンタイマーが出現し、在庫がなくなり次第そのページから自動的に商品を非表示にする販促機能で、マーケティング部門から「競合ECサイトが同様の施策で好調な数字を出しており、今期中にどうしても投入したい」という強い要望が発端になっている。
体制はエンジニア2名（あなたともう1名）・デザイナー1名、6週間でのリリースを目指す。
要件:
- セール開始と同時に対象商品ページへカウントダウンタイマーと残数表示を出す
- 残数は物流部門が運用する外部の倉庫管理システム（WMS）のAPIから15秒間隔でポーリング取得する（このチームがWMS APIを使うのは初めて）
- 在庫が0になった時点で、当該商品を一覧・詳細ページから自動非表示にする
- セール対象商品・開始終了時刻はマーケティング担当者が管理画面から設定する
- 過去に大型セール施策を打った際、開始直後のアクセス集中でサイト全体が数分間表示不安定になったことがある
📝 課題
あなたのタスク: 上記プロジェクトについて、ブレインストーミング＋過去プロジェクトのチェックリスト活用の2つの手法を使ってリスクを洗い出し、簡易リスク登録簿（内容/カテゴリ/発生確率/影響度/想定される引き金）の形式で最低8件以上まとめてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- ブレインストーミングは「技術面」「外部依存面」「業務・運用面」「人・体制面」のように切り口を変えて発散させると偏りが減る
- 「過去プロジェクトのチェックリスト活用」とは、自チームや近い性質のプロジェクトで過去に起きた問題を思い出し、同じことが今回も起きないかを点検する手法。今回は「過去に大型セールでアクセス集中による表示不安定があった」というヒントが与えられているので、それを深掘りする
- この段階ではまだ「対応策」までは決めなくてよい（対応戦略の設計はテーマ2-5で扱う）。まずは「何が起きうるか」を広く・具体的に洗い出すことに集中する
- 「初めて扱う外部連携」（今回はWMS API）は要注意ポイントになりやすい。ポーリング間隔・レート制限・障害時のフォールバックまで想像する
- 在庫と表示の同期には「ズレ」がつきもの。在庫0なのに表示が消えない、逆に在庫があるのに非表示になる、といった不整合のケースも洗い出す
- リスクは「〇〇によって△△が起きる可能性がある」のように、原因と結果をセットで書くと後工程（対応戦略の検討）で扱いやすくなる
📚 背景知識・用語解説
リスク特定（Risk Identification）とは、プロジェクトに影響を与えうる不確実な事象を、実際に発生する前に洗い出す活動です。設計や実装に着手してから「こんなリスクがあった」と気づくのでは手遅れになりやすいため、通常はキックオフ直後、要件が固まった段階で行います。
ブレインストーミングは、参加者が自由に思いつくリスクを発散的に出し合う手法です。ただし何も切り口がないと「思いつきやすいリスク」に偏りがちなので、次の4カテゴリを先に用意してから発散させると抜け漏れが減ります。
| カテゴリ | 内容 | 例 |
|---|---|---|
| 技術面 | 実装・設計・性能に起因するリスク | 処理性能不足、データ不整合 |
| 外部依存面 | 自チームの管理外にある外部システム・サービスに起因するリスク | 外部APIの障害・仕様変更・レート制限 |
| 業務・運用面 | 運用ルール・体制・意思決定プロセスに起因するリスク | 承認フローの遅延、緊急停止の判断基準が未定義 |
| 人・体制面 | メンバーのスキル・稼働・離脱に起因するリスク | 初めて扱う技術への習熟不足、キーパーソンの休暇 |
過去プロジェクトのチェックリスト活用は、自チームや類似プロジェクトで過去に実際に起きた問題を思い出し、「同じ原因が今回のプロジェクトにも存在しないか」を1件ずつ点検していく手法です。ゼロから発想するブレインストーミングと違い、「実際に一度起きたこと」を起点にするため、発生確率の見積もりに実績の裏付けが持てるのが強みです。
この段階ではリスクへの「対応策」までは決めません。対応策を早く決めすぎると、洗い出し自体が浅くなり（「対応できそうなリスクしか書かない」という無意識のバイアスがかかる）、重大リスクの見落としにつながるためです。まずは広く・具体的に「何が起きうるか」を出し切ることに集中します。
✅ 模範解答
ブレインストーミング（切り口別）
① 技術面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R1 | セール開始直後のアクセス集中により、対象商品ページの表示が数分間不安定になる | 高 | 高 | 過去の大型セールで同様の事象が実際に発生している。今回はカウントダウン演出で開始時刻に注目が集まりやすく、瞬間的な同時アクセスが過去より増える可能性がある |
| R4 | 在庫0になった商品の自動非表示処理が、キャッシュ（CDN・アプリ内キャッシュ）の影響で反映に時間差が出る | 中 | 中 | 商品一覧・詳細ページに既存のキャッシュ機構が入っている場合、在庫0の判定と表示更新の間にキャッシュのTTL分のラグが生じる。この点を要件定義時に確認していない |
| R9 | 在庫連動ロジックの単体テストが「在庫が十分にある」ケースに偏り、境界値（残り1点、同時購入で0を下回る等）のテストが手薄になる | 中 | 中 | 開発スケジュールが6週間とタイトなため、テスト設計の段階で境界値ケースの洗い出しに十分な時間を割けない懸念がある |
② 外部依存面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R2 | WMS APIの15秒ポーリングが、開始直後の大量リクエストでレート制限に引っかかり、残数取得が失敗する | 中 | 高 | 初めて使うWMS APIのレート制限値をまだ確認していない。多数の商品ページから同時にポーリングが走ると、通常時の想定を超えるリクエスト数になる |
| R3 | WMS APIのレスポンス遅延・タイムアウトにより、残数表示が古い値のまま更新されず、在庫0なのに購入できてしまう（売り越し） | 中 | 高 | 外部システムである以上、応答時間の保証がない。ポーリング失敗時のフォールバック仕様が未定義のまま設計に入ると、エラー時に「直前の値を表示し続ける」実装になりがちで、実在庫とのズレが起きる |
| R6 | WMS API連携が初めてのため、想定外の仕様（在庫数のマイナス値、欠品時のステータスコードの意味等）に実装後半で気づき、手戻りが発生する | 高 | 中 | チームにWMS API連携の経験者がおらず、公開ドキュメントだけを頼りに実装を進める予定になっている。ドキュメントと実際の挙動が異なるケースは外部APIでは珍しくない |
③ 業務・運用面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R5 | セール開始・終了時刻をマーケティング担当者が管理画面から誤って設定し、意図しないタイミングで公開・非公開が切り替わる | 中 | 中 | 管理画面の入力バリデーションが甘い、あるいは確認画面がないまま初回リリースを迎えると、時刻の入力ミス（タイムゾーン取り違え等）に気づけない |
| R7 | セール中に想定外の高負荷や不具合が発生した際、誰がどの基準で緊急停止を判断するかが決まっておらず、対応が遅れる | 中 | 高 | 過去の大型セール障害時も「誰が止める判断をするか」で数分の空白があったと聞いている。今回も緊急停止の権限者・基準が事前に合意されていない |
| R10 | セール対象商品の選定・除外ルール（在庫僅少商品を除く等）がマーケティング側の判断に依存しており、直前まで確定しない | 中 | 中 | 対象商品リストの最終確定フローがまだ合意されておらず、過去の販促施策でも対象商品の確定が開発着手後にずれ込んだ実績がある |
④ 人・体制面
| No | リスク内容 | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|
| R8 | 開発期間中にエンジニア2名のうち1名が別の緊急対応（既存障害対応等）に割かれ、6週間のスケジュールに遅延が出る | 中 | 中 | MOpsチームは少人数体制で、過去にも他案件の緊急対応でメンバーが一時的に抜けたことがある。専任化の合意が取れていない |
過去プロジェクトのチェックリスト活用
「過去に大型セールでアクセス集中による表示不安定があった」というヒントを深掘りし、過去の障害で実際に起きたパターンを今回のプロジェクトに照らし合わせる。
| 過去に起きたこと | 今回のプロジェクトの同じ引き金 | 該当リスク |
|---|---|---|
| 大型セール開始直後、アクセス集中でサイト全体の表示が数分間不安定になった | カウントダウン演出により開始時刻への注目が過去以上に集中する。さらに今回は複数商品ページから15秒間隔でWMS APIへのポーリングが一斉に走るため、自社サーバーだけでなく外部API側にも同時に負荷がかかる複合要因になっている | R1・R2 |
| 障害発生時、誰が緊急停止を判断するかが決まっておらず対応に空白時間があった | 今回もセール中の緊急停止権限者・基準がまだ合意されていない。カウントダウン演出は「止める」判断自体がユーザー体験への影響も大きく、判断のハードルが過去よりさらに上がっている | R7 |
発生確率・影響度の目安: 高＝プロジェクト中に70%以上の確率で発生しうる／全体のリリース可否に関わる影響、中＝30〜70%程度／一部機能や品質に限定的な影響、低＝30%未満／軽微または局所的な影響（今回は「低」に該当する項目がなかった）
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 技術的なリスクしか洗い出さない | R5・R7・R10のような業務・体制起因のリスクは、実際の障害では技術リスクと同じかそれ以上に頻発する。片方だけでは重大な見落としが残る | 4つの切り口をチェックリスト化し、各カテゴリで最低1〜2件は出すようにする |
| 洗い出しの段階でいきなり対応策まで書いてしまう | 「対応できそうなもの」しか書かなくなり、対応が難しい重大リスク（R6のような未知数の多いもの）を無意識に避けてしまう | まずは「何が起きうるか」だけを出し切り、対応策の検討は次のステップに分離する |
| 過去の障害事例を「なんとなく気をつける」で済ませ、具体的なリスク項目に落とし込まない | チェックリスト活用の本来の価値（実績に基づく発生確率の裏付け）が失われ、単なる精神論になる | 過去事例を「今回のプロジェクトのどの要素が同じ引き金を持っているか」まで分解して記述する（R1・R7のように） |
🏆 実務での使いどころ
リスクの洗い出しは、設計に入る前のキックオフ直後に行うのが最も効果的です。この段階で洗い出したリスクは、そのまま設計判断に反映できます（例: R3のフォールバック仕様を先に洗い出しておけば、設計時に「WMS API失敗時は在庫非表示側に倒す」といった安全側の設計を最初から組み込めます）。
エンジニアがこの活動に主体的に関わる価値は、技術的な実現可能性を踏まえたリスク（R2・R3・R6・R9のような項目）を、PMやマーケティング担当者だけでは出せない解像度で洗い出せる点にあります。逆にR5・R7・R10のような業務プロセスのリスクは、エンジニア単独では気づきにくいため、マーケティング担当者や運用担当者を巻き込んだブレインストーミングにする価値があります。
🚀 次のステップ
洗い出した10件のリスクを、次はテーマ2-3（発生確率×影響度マトリクス）で4象限に整理し、どのリスクから優先的に対応を検討すべきかを判断してみましょう。特にR3（売り越し）とR7（緊急停止判断の不在）は影響度が高いため、マトリクス上でどの象限に落ちるか、また対応戦略（テーマ2-5: 回避/軽減/転嫁/受容）をどう選ぶかを考えてみてください。