🎬 シナリオ
MOps（Marketing Ops/販促システム）チームが利用している在庫管理システム（WMS）は外部ベンダーが提供するSaaSで、在庫連携は3つのAPI（在庫数取得API・予約在庫確保API・入荷通知API）経由で行っている。ある日、そのベンダーから「現行のv1 APIを終了し、v2への移行を必須とする」という通告が届いた。通告から実際にv1が完全停止するまでの猶予は8週間しかない。
このAPIは、MOpsチームが開発してきた複数の販促機能に組み込まれている。
- タイムセール残数表示: セール対象商品の残数を、在庫数取得APIを高頻度でポーリングして画面にリアルタイムに近い形で表示する
- 在庫連動バナー非表示: トップページの特集バナーが、対象商品の在庫が0になった時点で自動的に非表示になる
- 入荷お知らせ通知: 入荷通知API経由のWebhookを受け取り、入荷を待っている会員にメールを送信するバッチ処理
v2では、認証方式がAPIキー方式からOAuth2方式に変更され、レスポンスの一部フィールド（在庫数が文字列型から数値型に変更）が変わり、さらにレートリミットが新設される（v1は無制限だったが、v2は1秒あたり10リクエストまで）。
体制はバックエンドエンジニア2名（あなたともう1名）・QA1名、8週間での移行完了を目指す。また、以下の過去事例が共有されている。
- 自社事例: 半年前、決済代行会社のAPI強制移行に対応した際、タイムアウトエラー発生時のリトライ挙動がv1とv2で異なることに気づかずに実装し、決済の二重処理事故が発生した
- 他社（業界）事例: 大手ECサイトが在庫システムのAPI移行を行った際、残数表示のキャッシュ更新ロジックが新APIのレスポンス形式に対応しておらず、タイムセール中に売り切れ商品が「購入可能」と表示され続け、注文後に欠品が判明して大量キャンセル対応に追われた
📝 課題
あなたのタスク: 上記プロジェクトについて、ブレインストーミング＋過去プロジェクトのチェックリスト活用の2つの手法を使ってリスクを洗い出し、簡易リスク登録簿（内容/カテゴリ/発生確率/影響度/想定される引き金）の形式で最低10件以上まとめてください。
🔍 ヒント（段階的開示）
取り組む前のヒント
- ブレインストーミングは「API仕様差異面」「データ整合性面」「スケジュール・体制面」「業務影響面」「外部ベンダー面」のように切り口を変えて発散させると偏りが減る
- 「API仕様差異面」は、認証方式・レスポンスの型・レートリミットという3つの変更点それぞれが、既存のどの実装に影響するかを1つずつ辿ると見つけやすい
- 「過去プロジェクトのチェックリスト活用」では、与えられた自社事例（決済代行APIのタイムアウト挙動差異による二重処理事故）・他社事例（在庫キャッシュ更新ロジックの不整合による売り切れ誤表示）の両方について、「今回の3つの販促機能のどこに同じ引き金があるか」を具体的に辿ってみる
- レートリミットの新設は「タイムセール残数表示のポーリング頻度」という、既存実装の前提そのものを崩す変更点であることに注意する
- v1・v2の並行稼働期間があるなら、「どちらを正とするか」の切替基準という業務ルールの未確定もリスクになりうる
- この段階ではまだ「対応策」までは決めなくてよい（対応戦略の設計はテーマ2-5で扱う）。まずは「何が起きうるか」を広く・具体的に洗い出すことに集中する
📚 背景知識・用語解説
リスク特定（Risk Identification）とは、プロジェクトに影響を与えうる不確実な事象を、実際に発生する前に洗い出す活動です。ベンダー主導の強制移行のように「自チームでスケジュールをコントロールできない」プロジェクトほど、着手前のリスク洗い出しの価値が高くなります。日程を動かせない代わりに、どこで問題が起きても被害を最小化できるように事前に備える必要があるためです。
ブレインストーミングは、参加者が自由に思いつくリスクを発散的に出し合う手法です。今回のようなAPI移行プロジェクトでは、切り口を用意してから発散させると、抜け漏れが減ります。
- API仕様差異面: 新旧APIの仕様の違い（認証方式・レスポンス形式・レートリミット等）に起因するリスク
- データ整合性面: 移行前後・並行稼働期間中のデータの一貫性に起因するリスク
- スケジュール・体制面: 移行に要する期間・メンバーのスキル・稼働に起因するリスク
- 業務影響面: 移行の失敗・遅延が実際の販促機能・会員体験に及ぼす影響に起因するリスク
- 外部ベンダー面: 自チームの管理外にあるベンダー側の対応・ドキュメント整備状況に起因するリスク
過去プロジェクトのチェックリスト活用は、自チームや類似プロジェクトで過去に実際に起きた問題を思い出し、「同じ原因が今回のプロジェクトにも存在しないか」を1件ずつ点検していく手法です。特に今回のようなAPI移行プロジェクトでは、「新旧APIの挙動差異」というカテゴリの事故そのものが再発しやすい構造を持っています。決済代行APIでの事故（自社事例）は対象APIも事故の種類（タイムアウト時のリトライ挙動差異）も今回のWMS APIとは異なりますが、「新旧APIの細部の挙動差異に気づかず実装し、想定外の事故が起きる」という構造は同じであるため、深掘りする価値があります。同様に、他社の在庫キャッシュ不整合事例も、「新APIのレスポンス形式変更に既存のキャッシュ・表示ロジックが追従できていない」という構造がタイムセール残数表示にそのまま当てはまるかを点検します。
この段階ではリスクへの「対応策」までは決めません。対応策を早く決めすぎると、洗い出し自体が浅くなり、重大リスクの見落としにつながるためです。まずは広く・具体的に「何が起きうるか」を出し切ることに集中します。
✅ 模範解答
リスク登録簿（洗い出し段階）
| No | 内容 | カテゴリ | 発生確率 | 影響度 | 想定される引き金 |
|---|---|---|---|---|---|
| R1 | v2で在庫数フィールドが文字列型から数値型に変わることを既存のタイムセール残数表示ロジックが想定しておらず、型変換エラーで表示処理が実行時に落ちる | API仕様差異面 | 高 | 高 | 既存実装は文字列型のレスポンスを前提に文字列連結で残数表示を組み立てており、型変更を反映する改修箇所が広範囲（3機能すべて）に及ぶ |
| R2 | 認証方式がAPIキーからOAuth2に変わることで、トークンの取得・有効期限管理・自動リフレッシュという新規の実装要素が発生するが、この作業量が当初の見積もりに含まれていない | API仕様差異面 | 高 | 中 | チームがOAuth2連携の実装経験を踏まえた見積もりをまだ行っていない段階で、8週間という期間だけが先に確定している |
| R3 | v2のレートリミット（1秒10リクエストまで）により、タイムセール残数表示の高頻度ポーリングという既存実装の前提そのものが崩れ、残数表示がリアルタイムに更新されなくなる | API仕様差異面 | 高 | 高 | v1は無制限だったためポーリング頻度に制約がない設計になっており、レートリミットを踏まえたポーリング間隔の見直し・キャッシュ設計が必要になる |
| R4 | 入荷通知APIのWebhookペイロード形式がv1・v2で変わり、既存の入荷お知らせメール送信バッチがフィールド不一致で通知を送信できなくなる | データ整合性面 | 中 | 中 | バッチ処理がWebhookのペイロードを固定のフィールド名で読み取っており、レスポンス形式の変更を吸収する変換層が現状存在しない |
| R5 | 移行期間中にv1・v2が並行稼働する場合、どちらのAPIから取得した在庫数を正とするかの切替基準が決まっておらず、切替タイミングで在庫数の不整合（二重販売や過小表示）が発生する | データ整合性面 | 中 | 高 | 「8週間で移行する」という期間だけが決まっており、移行を一斉切替にするか段階的に行うか、並行稼働時のデータの正本をどちらにするかの方針がまだ議論されていない |
| R6 | ベンダーからの通告が6週間前の短期間で行われ、8週間のプロジェクト期間中にOAuth2実装・レートリミット対応・3機能分の改修とテストを収めきれない可能性がある | スケジュール・体制面 | 高 | 高 | 移行の必要性自体がベンダー都合で発生しており、自チームの通常の開発サイクルに割り込む形で期間が決まっているため、他の開発予定とのリソース競合が起きやすい |
| R7 | バックエンドエンジニア2名のうち1名がOAuth2の実装経験がなく、キャッチアップに要する時間が見積もりに含まれていない | スケジュール・体制面 | 中 | 中 | チーム内の技術スキルの分布を踏まえた作業アサインの検討が、通告を受けてすぐの段階ではまだ行われていない |
| R8 | 在庫連動バナー非表示機能が、新APIのレスポンス遅延・エラー時にどう振る舞うか（フォールバック仕様）が未定義で、エラー時にバナーが「在庫あり」の状態のまま表示され続ける | 業務影響面 | 中 | 中 | 現行のバナー非表示ロジックは「正常にレスポンスが返る」ことを前提に組まれており、APIエラー時の表示状態の定義がv1稼働時から曖昧なままだった |
| R9 | v1停止予定（3月末）がマーケティング部門の春の大型セール（3月最終週）と重なっており、移行作業がセール期間中の在庫連携に影響するリスクが増幅される | 業務影響面 | 中 | 高 | ベンダーが提示した移行期限は自チームの販促カレンダーを踏まえて決められたものではなく、たまたま重なった状態でスケジュールが固定されている |
| R10 | ベンダーのv2移行ドキュメントが一部未整備で、レートリミットの具体的な仕様（バースト許容量、超過時のレスポンス等）が問い合わせないと分からない | 外部ベンダー面 | 中 | 中 | 強制移行の通告自体がベンダー都合で急に行われており、移行対象の詳細ドキュメントの整備が通告のタイミングに追いついていない |
| R11 | 半年前の決済代行API移行時にタイムアウトエラーのリトライ挙動の差異で二重処理事故が起きた。同じ構造で、今回も予約在庫確保APIのタイムアウト時のリトライ挙動がv1・v2で異なると在庫の二重確保が発生しうる | 外部ベンダー面 | 中 | 高 | 「新旧APIの細部の挙動差異に気づかず実装する」という事故の構造は対象APIが変わっても再発しうるが、今回のプロジェクトでタイムアウト時の挙動差異を明示的に確認する作業がまだ計画に入っていない |
| R12 | 他社の在庫システムAPI移行で、残数表示のキャッシュ更新ロジックが新APIレスポンス形式に対応しておらず売り切れ商品が購入可能のまま表示され続けた。同じ構造で、キャッシュ更新ロジックがv2のレスポンス形式（R1の型変更含む）に対応していないと同じ事故が起きうる | 業務影響面 | 中 | 高 | R1（型変更への未対応）が解決されないままキャッシュ層だけ改修すると、表示層とキャッシュ層で型の不整合が残り、他社事例と同じ「売り切れなのに購入可能に見える」誤表示が起きる |
発生確率・影響度の目安: 高＝プロジェクト中に70%以上の確率で発生しうる／全体の移行可否や販促機能の信頼性に関わる影響、中＝30〜70%程度／一部機能や一部期間に限定的な影響、低＝30%未満／軽微または局所的な影響
過去プロジェクトのチェックリスト活用
| 過去に起きたこと | 今回のプロジェクトの同じ引き金 | 該当リスク |
|---|---|---|
| 決済代行会社のAPI強制移行時、タイムアウトエラー発生時のリトライ挙動がv1・v2で異なることに気づかず実装し、決済の二重処理事故が発生した（自社事例） | 対象APIも事故の種類も異なるが、「新旧APIの細部の挙動差異に気づかず実装する」という構造は同じ。予約在庫確保APIのタイムアウト時のリトライ挙動をv1・v2で明示的に比較確認する作業が今回もまだ計画に入っていない | R11 |
| 大手ECサイトが在庫システムAPI移行時、残数表示のキャッシュ更新ロジックが新APIのレスポンス形式に対応しておらず、売り切れ商品が購入可能と表示され続けた（他社事例） | タイムセール残数表示は既存のキャッシュ更新ロジックを持っており、v2のレスポンス形式変更（在庫数の型変更含む）にキャッシュ層が追従できていないと同じ「売り切れなのに購入可能に見える」誤表示が起きる | R1・R12 |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「APIの仕様差異（認証・レスポンス形式・レートリミット）にだけ対応すればよい」と技術面に集中し、R6・R7・R9のような体制・スケジュールのリスクを見落とす | ベンダー主導の強制移行では自チームが期間をコントロールできないため、体制・スケジュール側の無理を洗い出さないと着手後に「そもそも8週間では終わらない」ことが手遅れの段階で判明する | 技術的な仕様差異だけでなく、体制・スケジュール・他部門との衝突も同じ重みで洗い出しの対象に含める |
| 過去事例（自社・他社）を「対象のAPIも事故の内容も違うから今回は関係ない」と切り捨てる | 事故の表面的な内容（決済の二重処理／在庫の誤表示）だけを見て構造的な類似性（新旧APIの細部の挙動差異に気づかず実装する）を見落とすと、同じ原因で別の事故が再発する | 過去事例は「何が起きたか」ではなく「なぜ起きたか（構造）」まで分解し、今回のプロジェクトの同じ構造を持つ箇所を具体的に探す |
| リスク同士の関連（R1が解決しないとR12が起きる、等）を無視してすべて独立の項目として並べたまま対応戦略の検討に進む | 個々のリスクへの対応を独立に検討すると、根本原因（R1の型変更対応）を後回しにしたまま派生的な症状（R12のキャッシュ不整合）だけに対処するという非効率な対応順序になりやすい | 洗い出し段階でリスク間の依存関係が見えたら、その場でメモとして残しておき、対応戦略検討時に対応順序の判断材料にする |
🏆 実務での使いどころ
ベンダー主導の強制移行プロジェクトは、自チームが日程をコントロールできないという点で通常の機能開発と性質が異なります。この段階でリスクを洗い出しておくと、「8週間で全部やる」という前提が本当に成立するのかを、着手前にチームリードやプロダクト側に説明できます（例: R6・R7を先に洗い出しておけば、「OAuth2実装経験者が1名しかいない」ことを理由にスケジュール調整や外部支援の要否を早期に相談できます）。
エンジニアがこの活動に主体的に関わる価値は、R1〜R5・R11・R12のような技術的な挙動差異に起因するリスクを、PMや他部門だけでは出せない解像度で洗い出せる点にあります。逆にR9（他部門の販促カレンダーとの衝突）のようなリスクは、マーケティング部門を巻き込んだブレインストーミングでなければ気づけません。ベンダー都合の移行だからこそ、技術・業務の両面から抜け漏れなく洗い出す価値が高くなります。
🚀 次のステップ
洗い出した12件のリスクを、次はテーマ2-2（リスク登録簿の書き方）で正式なリスク登録簿の形式（オーナー・対応期限・ステータス等の項目を追加）に整理してみましょう。特にR1・R12（型変更とキャッシュ不整合の連鎖）とR5（並行稼働時のデータ正本未確定）は、対応策の設計自体に時間がかかりそうなリスクのため、どのような記載項目を追加すればリスク同士の依存関係も含めてチーム外の人に伝わるように示せるか、考えてみてください。