フレームワーク活用ガイドひとことで言うと#
プロジェクトで特定したリスクに対し、「回避」「軽減」「転嫁」「受容」の4つの戦略から最適な対応を選び、事前に備える手法。「リスクが起きてから考える」のではなく「起きる前に戦略を持っておく」。
押さえておきたい用語#
- 回避（Avoid）
- リスクの原因そのものを取り除いて発生を防ぐ戦略のこと。未経験技術の採用を取りやめるなど、根本的な対処。
- 軽減（Mitigate）
- リスクの発生確率または影響度を下げる施策を打つ戦略を指す。4つの中で最も多用される。
- 転嫁（Transfer）
- リスクの影響を第三者に移す戦略のこと。保険、外部委託、契約条項による責任移転などが該当する。
- 受容（Accept）
- 対策コストがリスクの影響を上回る場合にリスクをそのまま受け入れる戦略のこと。ただしコンティンジェンシープランは用意する。
- コンティンジェンシープラン
- リスクが顕在化した場合に発動する事前策定済みの対応計画を指す。「もし起きたらこうする」を決めておく。
リスク対応戦略の全体像#
こんな悩みに効く#
- リスクを洗い出しても、具体的な対策に落とし込めない
- リスクが顕在化するたびに場当たり的な対応になる
- どのリスクにどれだけリソースを割くべきか判断できない
基本の使い方#
まず、特定したリスクの発生確率と影響度を評価する。
- リスクマトリクスを使い、各リスクを「高・中・低」で分類する
- 発生確率 × 影響度 = リスクスコアを算出する
- リスクスコアの高い順に優先的に対応を検討する
ポイント: 全リスクに同じ労力をかけない。上位20%のリスクに集中するのがパレートの法則。
各リスクに対して、最適な戦略を選ぶ。
① 回避（Avoid）: リスクの原因そのものを取り除く
- 例: 未経験の技術を使わず、実績のある技術を選択する
② 軽減（Mitigate）: 発生確率または影響度を下げる
- 例: プロトタイプを早期に作り、技術的な不確実性を減らす
③ 転嫁（Transfer）: リスクの影響を第三者に移す
- 例: 保険、外部委託、契約条項による責任の移転
④ 受容（Accept）: リスクをそのまま受け入れる（対策コスト > 影響の場合）
- 例: 発生確率が低く影響も軽微なリスクは、発生時に対処する
ポイント: 「軽減」が最も多用されるが、コストとのバランスを必ず考慮する。
選んだ戦略に基づいて、具体的なアクションプランを作成する。
- 予防計画: リスクが顕在化しないためのアクション
- コンティンジェンシープラン: リスクが顕在化した場合のアクション
- 各計画にオーナー、期限、必要リソースを明記する
ポイント: 予防計画だけでなく、「もし起きたらどうするか」のプランBを必ず用意する。
リスクの状況は常に変化するため、定期的に見直す。
- 週次または隔週でリスクレジスターをレビューする
- 新たなリスクの追加、既存リスクの状況更新を行う
- 対応計画の実行状況を確認し、必要に応じて調整する
ポイント: プロジェクト初期はリスクレビューの頻度を高める（不確実性が最も高いため）。
具体例#
状況: エンジニア6名のスタートアップ。新規Webサービスのローンチプロジェクト（予算2,500万円、期間5ヶ月）。5つの主要リスクを特定し、対応戦略を策定。
| リスク | 確率 | 影響 | 戦略 | 対応計画 |
|---|---|---|---|---|
| 主要エンジニアの離脱 | 中 | 高 | 軽減 | ペアプロ導入でナレッジ分散。ドキュメント整備 |
| 外部API仕様変更 | 高 | 中 | 軽減 | API抽象化レイヤーを設計。変更通知の監視体制構築 |
| サーバーコスト超過 | 中 | 中 | 転嫁 | 従量課金→年間契約で上限を設定 |
| セキュリティ脆弱性の発見 | 低 | 高 | 受容 | 72時間以内の緊急パッチリリース手順を事前に策定 |
| 要件の大幅変更 | 中 | 高 | 回避 | MVP定義を確定し、変更管理プロセスを厳格化 |
実際に発生したリスク: 外部APIの仕様変更がローンチ2ヶ月前に発生。抽象化レイヤーのおかげで影響を2日間の修正で吸収。事前の備えがなければ2週間の遅延が発生していた。
5つのリスクに対してわずか3人日の事前投資で対応計画を策定し、実際に発生したリスクでは12日分の遅延を防げた。リスク対応のROIは極めて高い。
状況: 従業員420名の食品メーカー。老朽化した本社工場から新工場への移転プロジェクト。予算15億円、期間18ヶ月。生産ラインの停止は売上に直結するため、リスク管理が最重要課題。
リスク対応戦略:
| リスク | 戦略 | 具体的対応 | コスト |
|---|---|---|---|
| 生産ライン停止（移転時） | 回避 | 新工場で生産開始後に旧工場を停止（並行稼働2ヶ月） | +8,000万円 |
| 設備の搬送中の破損 | 転嫁 | 搬送保険（全額補償）に加入 | 1,200万円 |
| 新工場の建築遅延 | 軽減 | 建築会社との契約に遅延ペナルティ条項。月次進捗会議 | 契約コストのみ |
| 従業員の通勤問題（離職） | 軽減 | 通勤バスの運行（1年間）＋引越し手当の支給 | 3,000万円 |
| 食品安全基準の認証遅延 | 回避 | 認証取得を移転の前提条件とし、取得完了まで移転しない | スケジュール調整 |
結果: 並行稼働により生産停止ゼロ。従業員離職率は5%に抑制（業界平均12%）。認証は予定通り取得。
この取り組みが示すように、最大のリスクであった「生産ライン停止」を回避戦略（並行稼働）で対処した判断が正しかった。8,000万円のコスト増は、生産停止による売上損失（1日あたり推定2,000万円）と比較すれば合理的な投資である。
状況: 受験者数年間1.8万人の私立大学。入試システムの刷新プロジェクト。「入試本番でシステムが停止する」リスクが最大の懸念。予算5,000万円、期間10ヶ月。
リスク対応の特殊性: 入試は「やり直し」が効かない。1回の失敗が大学の信用に致命的なダメージを与えるため、通常以上に慎重な対応が必要。
| リスク | 確率 | 影響 | 戦略 | 対応計画 |
|---|---|---|---|---|
| 本番でのシステム障害 | 低 | 致命的 | 軽減+受容 | 負荷テスト（想定の3倍）実施 + 紙ベースのバックアップ手順を策定 |
| 受験者のUI操作ミス | 中 | 高 | 軽減 | ユーザビリティテスト3回実施。操作ガイド動画を作成 |
| データ移行の不整合 | 中 | 高 | 回避 | 旧システムとの並行運用を1年間継続。段階的に移行 |
| ベンダーの開発遅延 | 中 | 高 | 軽減 | マイルストーン払い。遅延時は入試時期を考慮してスコープ縮小 |
実際の本番: 受験者1.8万人の入試で、システム稼働率99.98%（ダウンタイム計12秒のみ）。バックアップ手順の発動は不要だったが、紙ベースの準備があることでスタッフの安心感につながった。
「起きたら致命的」なリスクには、コストをかけてでも複数の防御層を敷く。負荷テストの3倍設計と紙のバックアップという「過剰に見える対策」が、1.8万人の受験者と大学の信用を守った。
やりがちな失敗パターン#
- すべてのリスクを「軽減」にする — 回避や転嫁の方が適切な場合もある。4つの戦略をバランスよく使い分ける
- 受容を「何もしない」と混同する — 受容でもコンティンジェンシープランは必要。「起きたときの対応手順」は事前に決めておく
- リスク対応のコストを考慮しない — 対策コストがリスクの影響額を上回る場合は受容の方が合理的。費用対効果を必ず検討する
- リスクレビューを怠る — プロジェクト開始時に作ったリスクレジスターを更新しない。リスクの状況は常に変化するため、最低でも隔週でレビューする
まとめ#
リスク対応戦略は、プロジェクトリスクに対して「回避」「軽減」「転嫁」「受容」の4つの選択肢から最適な対応を選ぶフレームワーク。リスクの評価→戦略の選択→計画の具体化→定期レビューのサイクルを回すことで、場当たり的な対応を防ぎ、プロジェクトの安定性を高められる。