🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは、会員ランク制度（シルバー／ゴールド）の判定ルール変更を 11/1（日）早朝のバッチで切り替える。今日は 9/29（火）、コード凍結は 10/23（金）、ブラックフライデー（11/27）の 4 週間前。切り替え日には全会員を新ルールで一括再判定し、2025年度のデータで再計算すると降格 3,100人／昇格 5,400人、ゴールド会員は 6,200人（月初にランク別クーポン 500円）。
| 項目 | 現行 | 変更後 |
|---|---|---|
| 判定期間 | 暦年（1/1〜12/31）の購入額 | 直近365日のローリング |
| 判定タイミング | 毎月1日のバッチ（判定とランク別クーポン付与を同時に実行） | 毎日の再判定バッチ。クーポンは別ジョブで毎月1日に付与 |
| 閾値 | シルバー 3万円／ゴールド 10万円 | 変更なし |
体制はバックエンド 3 名（リード佐藤・山田・あなた）、QA 1 名（高橋）、PdM 1 名（鈴木）。関係者は CS 部門、経理部門、データ基盤チーム、アプリチーム。
💬
リード佐藤: 「先輩の山田さんがリスクの下書きを作ってくれたが、あれでは週次で管理できない。登録簿として使える形に作り直して。評価の尺度（確率・影響度の定義）も一緒に決めてほしい。」
山田さんの下書き（そのまま）
| # | リスク | 確率 | 影響 | 対応 | オーナー |
|---|---|---|---|---|---|
| 1 | スケジュールが遅延する | 高 | 高 | 注意する | チーム |
| 2 | 品質が心配 | 中 | 大 | テストを頑張る | QA |
| 3 | ステージングのデータが古く、検証できない | 高 | 中 | データを更新してもらう | 高橋 |
| 4 | CS の問い合わせが増える | 中 | 中 | CS に伝えておく | 鈴木 |
| 5 | クーポン原資が超過する | 低 | 高 | 経理に確認 | 経理部 |
| 6 | バッチが落ちる | 低 | 高 | 受容 | 佐藤 |
| 7 | 仕様変更があるかも | 中 | 中 | 様子を見る | 鈴木 |
| 8 | 高橋さんが 10/14〜10/17 に休む | 高 | 中 | カバーする | 佐藤 |
追加で分かっている情報（設定値）
| 情報 | 値 | 出所 |
|---|---|---|
| CS の通常問い合わせ／日 | 220件 | 仮定（演習の設定） |
| CS の処理能力／日 | 320件（余力 100件/日、3日で 300件） | 仮定 |
| 降格通知なしの場合、降格者の問い合わせ率 | 15% | 仮定（他施策の経験則という設定） |
| 降格通知ありの場合の問い合わせ率 | 5% | 仮定 |
| 旧バッチが 11/1 に付与するゴールドクーポン | 6,200人 × 500円 | 仮定 |
| ステージングのテストデータ | 今日の時点で 2024年 9 月のまま | 実測（現に起きている） |
| 返品・キャンセルの購入額相殺 | 現行は「返品分を差し引く」。経理の集計は「返品月で相殺」。新ルールでの扱いは未定義 | 仮定 |
| 法務 | 会員規約の改定レビューは通常 2 週間 | 仮定 |
📝 課題
あなたのタスク: 次の 3 点を作成してください。
- 尺度の定義: 確率 5 段階・影響度 5 段階の「各段階の意味」を、数・金額・日数で書く。点数の計算と、色ごとの扱いも決める
- リスク登録簿: 下書き 8 行を、登録簿に載せるものと載せないものに仕分け、載せるものは「原因→事象→影響」で書き直す。列は ID／記述／確率／影響度／点数／兆候／対応（戦略＋行動）／オーナー／期限／状態
- 運用ルール: レビューの頻度、リスクが発生したときの扱い、クローズの条件
🔍 ヒント（段階的開示）
ヒント1
「スケジュールが遅延する」は原因か結果か。遅延はどのリスクが起きた結果として現れるか
ヒント2
下書きの 8 行のうち、「もう起きていること」と「もう決まっていること」はリスクか
ヒント3
「高・中・低」を 2 人が別々に付けたら同じ値になるか。数字で割れる尺度にできないか
ヒント4
対応の「注意する」「頑張る」「様子を見る」は、いつ・誰が・何をしたかが後から確認できるか
ヒント5
オーナーに「チーム」「経理部」と書くと、誰が週次で状況を言うことになるか
ヒント6
「受容」は何も決めないことと同じか。受容を選ぶなら何を一緒に書くべきか
📚 背景知識・用語解説
📖
リスクとは: まだ起きていない不確かな出来事で、起きたら目標（日程・費用・品質・顧客への影響）に作用するもの。確率が 100% なら課題（Issue）、確定した制約は前提・制約で、リスクではない。
リスク登録簿: リスクを 1 件 1 行で管理する表。PMBOK 第 6 版ではリスク特定の出力（§11.2.3.1。節番号は記憶に基づき未照合）。表そのものより、毎週更新されることに価値がある。
書き方（原因→事象→影響）: 原因を書くと対応の相手が、事象を書くと兆候が、影響を書くと影響度が数字で決まる。「品質が心配」は 3 つとも決まらない。
点数の限界: 1〜5 の点を掛けて優先度を付けるのは定番だが、順序しか意味のない数の積なので順位がずれることがある。Cox (2008) What's Wrong with Risk Matrices?（Risk Analysis 28(2), 497–512、Crossref で書誌確認、参照日 2026-09-29）。点数は議論の順序づけに使い、例外を明文化する。
オーナー: 毎週状況を報告し対応を進める責任を持つ1 名。外部チームは「依頼先」であってオーナーにならない。
リスク登録簿: リスクを 1 件 1 行で管理する表。PMBOK 第 6 版ではリスク特定の出力（§11.2.3.1。節番号は記憶に基づき未照合）。表そのものより、毎週更新されることに価値がある。
書き方（原因→事象→影響）: 原因を書くと対応の相手が、事象を書くと兆候が、影響を書くと影響度が数字で決まる。「品質が心配」は 3 つとも決まらない。
点数の限界: 1〜5 の点を掛けて優先度を付けるのは定番だが、順序しか意味のない数の積なので順位がずれることがある。Cox (2008) What's Wrong with Risk Matrices?（Risk Analysis 28(2), 497–512、Crossref で書誌確認、参照日 2026-09-29）。点数は議論の順序づけに使い、例外を明文化する。
オーナー: 毎週状況を報告し対応を進める責任を持つ1 名。外部チームは「依頼先」であってオーナーにならない。
✅ 模範解答
答えを見る前に自分の登録簿を作ってから読み比べてください。
1. 尺度の定義
確率（P）
| P | 範囲 | 目安 |
|---|---|---|
| 1 | 10% 未満 | 起きる理由が見当たらない。起きたら驚く |
| 2 | 10〜30% | 過去に他チームで起きた。当チームは対策済み |
| 3 | 30〜50% | 半々。誰かが何もしなければ起きる |
| 4 | 50〜70% | 起きる前提で動いている。対策がまだない |
| 5 | 70% 超 | ほぼ起きる（ここまで高いと課題との境目を確認する） |
影響度（I）— 3 軸のうち最も大きい段階を採る
| I | 日程 | 金額（原資・損失） | CS への影響 |
|---|---|---|---|
| 1 | 1 人日以内 | 10 万円未満 | 追加 30 件未満 |
| 2 | 1〜2 日の遅延 | 10〜50 万円 | 追加 30〜99 件 |
| 3 | 3〜5 日の遅延 | 50〜150 万円 | 追加 100〜299 件（3 日の余力 300 件の範囲内） |
| 4 | 1〜2 週間の遅延 | 150〜500 万円 | 追加 300 件以上（余力を超える） |
| 5 | 11/27 に間に合わない | 500 万円超 | 会員への誤課金・個人情報の誤表示 |
点数（P × I）と扱い
| 色 | 点数 | 扱い |
|---|---|---|
| 赤 | 15 以上 | 判明した日のうちにリードへ報告。毎朝の確認事項に載せる |
| 橙 | 10〜14 | 週次レビューで必ず状況を言う。期限なしは認めない |
| 黄 | 7〜9 | 週次レビューで一覧を確認 |
| 緑 | 6 以下 | 2 週間に 1 回確認 |
⚠️
例外: 影響度 5 は点数にかかわらず橙以上。起きたら取り返せないものを緑に埋もれさせないため。
色の分布（このプロジェクトの 10 件）
2. 下書きの仕分け（クイズ）
各行を「リスク／課題／前提・制約／削除」のどれにするか考えてから「答え」を押してください。
| 下書き | あなたの判定 |
|---|---|
| #1 スケジュールが遅延する | 削除。結果であり原因ではない。各リスクの影響欄に日数として分散 |
| #3 ステージングのデータが古く、検証できない | 課題（I-01）。今起きている。期限つきで解決する |
| #8 高橋さんが 10/14〜10/17 に休む | 前提・制約。確定済み。線表に非稼働で織り込む。残る不確かさは R08（それ以外の欠員） |
| #6 バッチが落ちる | リスク 2 件に分解。R05「遅くて枠を超える」と R07「戻せない」では対応が違う |
| #2 品質が心配 | リスク（R03 に具体化）。何が検証できないか（境界値）を特定する |
仕分けの全体
| 下書き | 判定 | 理由・行き先 |
|---|---|---|
| #1 スケジュールが遅延する | 載せない（削除） | 遅延は結果であり、他のリスクの影響欄に日数として入る。これ自体に対応は打てない |
| #2 品質が心配 | R03 に具体化 | 何が検証できないかを特定する |
| #3 ステージングのデータが古い | 課題管理表へ（I-01） | 今この瞬間に起きている。確率ではなく、期限つきの解決の話 |
| #4 CS の問い合わせが増える | R02 に具体化 | 原因（降格通知がない）と数（465 件）を足す |
| #5 クーポン原資が超過する | R01 に具体化 | 原因（旧バッチと新ジョブの重複）を特定 |
| #6 バッチが落ちる | R05・R07 に分解 | 「遅い」と「戻せない」は対応が違う |
| #7 仕様変更があるかも | R06 に具体化 | 誰から・いつまでの変更かを特定 |
| #8 高橋さんが休む | 前提・制約へ | 休暇は確定済み。線表に 10/14〜10/17 を非稼働として織り込む。残るのは「それ以外の欠員」（R08） |
3. リスク登録簿（2026-09-29 時点）
| ID | リスク（原因→事象→影響） | P | I | 点 | 色 | 兆候（トリガー） | 対応（戦略: 行動） | オーナー | 期限 | 状態 |
|---|---|---|---|---|---|---|---|---|---|---|
| R02 | 降格通知メールを送らないと、降格 3,100 人の 15% が問い合わせ、465 件が 3 日に集中する。CS の余力 300 件を超え、一般の問い合わせが滞る | 4 | 4 | 16 | 赤 | 10/21 までに通知メールの文面が確定していない | 軽減: 10/25 に降格対象者だけに事前通知を配信（問い合わせ率 5% → 155 件、余力内）。文面は CS 部門と 10/14 までに確認 | 鈴木（PdM） | 10/25 | 対応中 |
| R03 | 本番に近いデータが無く、境界値（購入日がちょうど 365 日前／うるう日／返品との相殺）を検証できないまま切り替え、降格・昇格を誤る。誤判定の修正で 3〜5 日の遅延 | 3 | 4 | 12 | 橙 | 10/9 までにデータ基盤チームからマスク済みコピーが届かない | 軽減: 10/2 に依頼を出し、10/9 までにコピー取得。境界値のテストケース 24 件を 10/16 までに作る。10/9 に届かなければ橙→赤で報告 | 高橋（QA） | 10/16 | 対応中 |
| R06 | マーケから「ランク別先行セール」などの追加要望が凍結（10/23）後に入り、判定ロジックの変更が 11/1 に混ざって検証が薄くなる。3〜5 日の遅延 | 4 | 3 | 12 | 橙 | 10/16 までに追加要望の相談が出る | 回避: 10/2 に鈴木がマーケ部長と「凍結後の変更は 11/1 に入れない」ことを合意し、議事録に残す | 鈴木（PdM） | 10/2 | 未着手 |
| R09 | 会員規約の改定レビューに 2 週間かかり、適用日 11/1 の周知が間に合わない。適用日の延期（1〜2 週間）か、周知不足による苦情 | 3 | 4 | 12 | 橙 | 10/9 時点で法務のレビュー着手が確認できない | 軽減: 10/2 に法務へレビューを依頼し、規約改定が必要か（定型約款の変更に当たるか）を先に確認。確認先: 法務窓口。法令の当否は今回未検証 | 鈴木（PdM） | 10/9 | 未着手 |
| R07 | 切替後に重大な不具合が見つかったとき、旧ランクに戻す手順がなく、会員の誤ランク表示・誤付与が数日続く（影響度 5、確率 8% と見積もり） | 1 | 5 | 5 | 橙（I=5 の例外） | 10/21 までに戻し手順のリハーサル日程が決まっていない | 軽減: 切替前に会員ランク表のスナップショットを保存し、戻す手順を 10/28 にステージングで 1 回通す | 佐藤（リード） | 10/28 | 未着手 |
| R01 | 11/1 に旧バッチ（判定＋クーポン付与）と新しい日次バッチが両方走り、ゴールド 6,200 人に 500 円クーポンが二重に付与される。310 万円の原資超過 | 2 | 4 | 8 | 黄 | 11/1 03:00 のジョブ実行ログに旧バッチの起動が残る | 回避: 切替手順書に「旧バッチのスケジュール停止」を明記し、10/16 に山田とあなたでレビュー。付与ジョブには同一会員・同一月の二重付与を弾く条件を入れる | あなた | 10/16 | 未着手 |
| R04 | 返品・キャンセルの購入額の扱いが、新ルールの実装・CS の説明・経理の集計で食い違い、会員が「返品したのに降格しない／した」と問い合わせる。100〜299 件 | 3 | 3 | 9 | 黄 | 10/7 時点で経理から相殺ルールの回答が来ていない | 軽減: 10/7 までに経理と相殺ルールを書面で合意し、仕様書に反映 | 鈴木（PdM） | 10/7 | 未着手 |
| R10 | アプリがランク API の応答を最大 24 時間キャッシュしており、切替直後のランク表示が 1 日ずれる。降格者・昇格者から表示のずれの問い合わせ | 4 | 2 | 8 | 黄 | 10/9 までにアプリチームの返信がない | 軽減: 10/2 にアプリチームへ依頼（依頼先: アプリチームリード）、切替日のみ TTL を 1 時間に下げてもらう。オーナーは依頼を出す山田 | 山田 | 10/9 | 未着手 |
| R05 | 再判定バッチが本番の件数（約 82 万件）で夜間の実行枠（3:00〜5:00）を超え、朝のサイトに旧ランクが残る。ランク表示のずれで 100〜299 件の問い合わせ | 2 | 3 | 6 | 緑 | ステージングで 82 万件相当に換算した所要時間が 90 分を超える | 軽減: 10/16 に本番相当件数で負荷試験を 1 回実施 | 山田 | 10/16 | 未着手 |
| R08 | QA が 1 名のため、10/14〜10/17 の休暇以外に欠員が出ると、テスト実行が止まる。2 日の遅延 | 2 | 3 | 6 | 緑 | QA 作業の遅れが 2 日分を超える | 受容: 予備日 2 日（10/26〜10/27）で吸収する。理由: 代替要員を今から育てる費用が、起きたときの損失（2 日）を上回る。起きたら山田がテスト実行を引き継ぐ | 佐藤（リード） | 10/16（再評価） | 受容 |
課題管理表（登録簿とは別）
| ID | 課題 | 影響 | 対応 | オーナー | 期限 |
|---|---|---|---|---|---|
| I-01 | ステージングのテストデータが 2024 年 9 月のまま | 現行テストで直近 365 日の判定が再現できない | R03 のマスク済みコピー取得で解消 | 高橋 | 10/9 |
前提・制約: 高橋さん 10/14〜10/17 休暇（線表に非稼働として反映）／コード凍結 10/23／切替 11/1 03:00。
4. 運用ルール
| 項目 | 決めたこと |
|---|---|
| レビュー | 毎週火曜の定例の最初の 10 分。赤・橙は全件、黄は一覧、緑は隔週 |
| 発生したとき | 登録簿の状態を「発生」にして課題管理表へ移す。登録簿は消さず、発生した日と原因を残す（次回の確率の見積もりの材料） |
| 更新の責任 | 各行のオーナーが火曜までに「確率・影響の変化」と「対応の進み」を 1 行で書く |
| クローズの条件 | ①対応完了で兆候が消えた、②期限（11/1）を過ぎた、③発生して課題へ移した、のいずれか。期限を過ぎたら「次のリリースに持ち越すか」を判断する |
| 色の再計算 | 兆候が出たら P を 1 つ上げる（R03 は 10/9 に届かなければ 3→4 で 16、赤） |
試算: R02（降格通知の有無と CS の余力）
数値は演習の設定値（仮定）。スライダーで動かすと、対応の効果と「余力を超えるか」が見えます。
💡 なぜこう作るのか
- 尺度を先に決めた理由: 「中」は人によって 10% にも 50% にもなる。山田さんの下書きの「高・中・低」を、鈴木さんと高橋さんが別々に付けると割れる。割れたとき「どちらが正しいか」は尺度に書いてある数字で決まる。影響度に日程・金額・CS 件数の 3 軸を並べたのは、このリリースで起きうる被害がこの 3 種類だからで、軸を 1 つに揃えると R02（CS 件数）や R01（金額）が日数に換算できず測れなくなる
- 「遅延」を削除した理由: 遅延は他のリスクが起きた結果の見え方。行として置くと、対応欄に「注意する」としか書けず、毎週「変わらず」で終わる。遅延は各行の影響欄の日数として分散させた
- R02 を赤にした理由: 465 件 > 余力 300 件という数字で超過が分かるから。対応後は 155 件で余力に収まるため、行動の効果が見える（確率 4 を 2 に下げられる）
- R07 を I=5 の例外で橙にした理由: 点数は 5（緑）だが、戻せない被害は他のリスクと質が違う。点数だけで並べると Cox (2008) が指摘する「大きなリスクが小さく見える」状態になる
- R06 の戦略に「回避」を選んだ理由: 軽減（変更が入ってもテストで拾う）は、凍結後に追加テストの時間が無いので成立しない。要望そのものを 11/1 に入れないと決めるほうが安い
🔀 迷った他案と採らなかった理由
| 案 | 採らなかった理由 | 判断が変わる条件 |
|---|---|---|
| 確率・影響を「高・中・低」の 3 段階にする | 割れる幅が大きく、10 件のうち 8 件が「中」に寄る（山田さんの下書きがその例） | 登録簿が 5 件以下で、全員が同じ人に報告するだけの場合 |
| 期待損失額（確率×金額）で並べる | 確率に根拠のある数字が無い（今回は仮定のみ）。Senior テーマ 2-12 で扱う | 過去の発生率が数十件分ある場合 |
| Jira など課題管理ツールに載せる | 10 件ならスプレッドシートで週次 10 分に収まる。ツール導入の説明のほうが重い | 50 件を超える、または他チームが自分で更新する場合 |
| 列に「残余リスク」「二次リスク」を足す | 10 件・4 週間では更新されず空欄になる（空欄の列は登録簿への信頼を落とす） | 対応が新しいリスクを生む場合（備考欄で足りなければ列にする） |
| オーナーを経理・データ基盤・アプリの担当者にする | 他チームの担当者は MOps の週次に出ない。報告されない行が増える | 他チームも同じ登録簿を使う合意がある場合 |
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「遅延する」「品質が心配」など結果・感情を 1 行にする | 対応も兆候も書けず、毎週「変わらず」になる | 原因→事象→影響の 1 文にする。書けなければまだリスクとして特定できていない |
| もう起きていること（ステージングのデータ）を確率「高」で載せる | 確率が 100% のものは期限つきの課題。登録簿に置くと優先度が混ざる | 課題管理表へ移し、解決の期限を決める |
| 対応を「注意する」「頑張る」「様子を見る」にする | いつ、誰が、何をしたか確認できない。実行されたか分からない | 動詞＋対象＋期限（「10/9 までにコピーを取得」）で書く |
| オーナーに「チーム」「部署」を書く | 週次で誰も自分の行と思わない | 1 名の個人名。外部は依頼先として別欄または対応欄に書く |
| 作って終わりにする | 兆候が出ても点数が変わらず、リスクが発生して初めて課題になる | レビューの日と、点数の更新ルール（兆候で P を 1 つ上げる）を決める |
| 受容を「何もしない」の言い換えにする | 起きたときに誰も動けない | 受容する理由・予備（日数や費用）・起きたときの動き方を書く |
🏢 実務での使いどころ
- 使う局面: キックオフ直後（最初の登録簿）、設計レビューの後（技術リスクの追加）、凍結前（残りのリスクの棚卸し）。リリース後は発生した行と回避できた行を振り返り、次の尺度の見直しに使う
- エンジニアとして: 設計書の「懸念点」を 1 行ずつ登録簿に書き直すと、懸念が誰の仕事かが決まる。PM が居ないチームでも、リードの佐藤に「登録簿を作り直しました」と見せられる成果物になる
- 隣の役割: PdM（鈴木）は要望・法務・マーケ調整の行を持ち、QA は検証の行、CS・経理・データ基盤・アプリは「依頼先」として対応欄に名前が出る。経営層には赤・橙だけを 1 ページで出す
- 個人開発への転用: 件数が 5〜10 のとき、列は「リスク／確率／影響／対応／期限」の 5 つで足りる。尺度の定義（何を 1 とするか）だけは省かない
➡️ 次のステップ
- テーマ 2-3 の「確率×影響度マトリクス」で、今日の 5×5 の尺度を 4 象限に簡略化したとき何が失われるかを比べる
- R06 の戦略（回避）が使えない場合に軽減策を考える。対応戦略の使い分けはテーマ 2-5（Mid）
- 問い: R02 の対応（事前通知）が新しいリスク（通知メールの誤配信）を生む場合、それを R11 として追加するか、R02 の備考に書くか。どちらが 10 件の登録簿で運用しやすいか
- 課題管理表（Issue Log）とリスクの境界はテーマ 2-4 で詳しく扱う
🧭 扱わなかった範囲・検証していない点
- 期待損失額・モンテカルロなどの定量分析は扱っていない（Senior テーマ 2-12。確率に根拠のある数字が無いため）
- 対応戦略 4 種の使い分けの詳細は扱っていない（Mid テーマ 2-5）。今日は回避・軽減・受容を例として使っただけ
- 数値（問い合わせ率・クーポン付与人数・CS 処理能力・降格人数など）は演習の設定値であり、実在企業の実測ではない
- 規約改定の要否（定型約款の変更に当たるか）は法務確認に回し、本文では結論を出していない（今回は法令の原文を照合していない）
- PMBOK 第 6 版の節番号と、「原因→事象→影響」の書き方の出典は記憶に基づくため未照合。Cox (2008) のみ Crossref で書誌を確認した
- 世界の実物との比較: ISO 31000 のリスク記録や、商用の GRC ツール（リスクの階層・統制・監査証跡を持つもの）が扱う概念の多く（統制、残余リスク、リスク許容度、KRI）は扱っていない。10 件・4 週間のプロジェクト用の最小の登録簿に絞った