「どの戦略を選ぶか」より「なぜその戦略か」が問われる——リスク対応4戦略を現場で使い分けるための判断設計術

＜目次＞

「4つの戦略を知っている」と「使い分けられる」は別の話だ
4つの戦略を「判断軸」で整理する
現場で起きる「戦略選択ミス」の典型パターン
判断をシンプルにする「2×2の選択フレーム」
戦略を「選んで終わり」にしないための設計
現場PMへの問い——「なぜその戦略か」を言語化できるか
1. リスク管理を「仕組み」として機能させたい方へ

「4つの戦略を知っている」と「使い分けられる」は別の話だ

リスク対応戦略として「回避・転嫁・軽減・受容」の4つを知っているPMは多い。しかし現場では、「このリスクにはどれを使うのか」という問いに対して、明確な根拠を持って答えられるPMは意外と少ない。

よくある失敗はこうだ。リスク登録簿を作ったはいいが、すべてのリスクに対して「リスク軽減」を書いておく。形としては体裁が整い、承認も通る。だが実際には、軽減しようのないリスクに対しても「対策を検討する」という曖昧な文言が並び、いざリスクが顕在化したとき、誰も何もできなかった——そういうケースは珍しくない。

4つの戦略は「知識」ではなく「判断の道具」だ。この記事では、現場でどの戦略をどう選ぶかを、具体的な状況と判断基準とともに解説する。

4つの戦略を「判断軸」で整理する

まず前提として、4つの戦略を教科書的な定義から少し視点を変えて整理しておきたい。

回避（Avoid）：リスクそのものを取り除く。計画や方針を変えることでリスクが発生する状況自体をなくす。
転嫁（Transfer）：リスクの影響を第三者に移す。保険・契約・アウトソーシングなどが典型。
軽減（Mitigate）：リスクの発生確率や影響度を下げる。プロトタイプ・冗長化・テスト強化などが代表的な手段。
受容（Accept）：リスクをそのまま受け入れる。能動的受容（コンティンジェンシー予備の確保）と受動的受容（何もしない）の2種類がある。

選択の判断軸は主に3つだ。①影響度の大きさ、②発生確率、③対応コストと効果のバランス。この3軸を組み合わせて考えると、選択の方向性が見えてくる。

現場で起きる「戦略選択ミス」の典型パターン

パターン1：軽減しか知らない現場

あるシステム開発プロジェクトで、「外部APIの仕様変更リスク」に対して「仕様変更を監視し、影響を軽減する」という対応が登録されていた。しかし実態としてこのAPIはサービス終了の可能性があり、軽減では対処しきれない状況だった。

本来取るべき戦略は「回避」——つまり代替APIへの切り替えを計画に組み込む、あるいはそのAPIへの依存をアーキテクチャレベルで最小化することだった。「軽減」を選んだのは、変更を嫌う組織文化と「今は大丈夫だろう」という楽観バイアスの産物だった。

パターン2：受容が「放置」になっている

受容は4つの戦略の中で最も誤解されやすい。「受け入れる」というと「何もしない」と同義のように聞こえるが、能動的受容は明確に違う。コンティンジェンシー予備（リスクが顕在化したときのための予算・期間のバッファ）を確保した上で、「起きたときはこう動く」という対応計画を持っている状態だ。

一方で現場では、受容が単なる「先送り」として機能してしまうことがある。影響度が低いと判断してリスクを受容したものの、発生確率の再評価を怠り、いつの間にか高リスクになっていたケースもある。受容は「判断」であって「忘却」ではない。

パターン3：転嫁しても責任は残ることを忘れる

コスト変動リスクを固定価格契約で転嫁したつもりが、ベンダーが品質を落とすことで帳尻を合わせてきた——これも現場ではよくある話だ。転嫁はリスクの「財務的負担」を移すことはできるが、「プロジェクト目標への影響リスク」をすべて移せるわけではない。転嫁後も、モニタリングと関係管理の責任は発注者側のPMに残る。