残留リスクと二次リスクを見逃さない管理のコツ——「対応した」で終わらせないPMの追跡設計術

リスク対応策を打ったにもかかわらず、プロジェクトが後から崩れていく。その原因の多くは、対応後に生まれる「残留リスク」と「二次リスク」の見落としにある。本記事では、この2つの概念を整理し、現場で見逃しやすいパターンと、追跡・管理を機能させるための実践的な設計術を具体的に解説する。

＜目次＞

「対応した」は終わりではなく始まりだ——残留リスクと二次リスクの本質
1. 多くのPMが陥る「完了バイアス」
2. なぜこの2つは見逃されやすいのか
残留リスクを「見える化」する追跡設計のつくり方
1. リスク台帳に「対応後ステータス」の欄を設ける
2. 「対応後レビュー」を議題として固定する
二次リスクを「生まれた瞬間」に捕捉する仕組み
1. 対応策の実施前に「二次リスク棚卸し」を義務化する
2. 二次リスクは「新規リスク」として登録する
現場を動かすための「軽い仕組み」の設計思想
1. 完璧な管理より「抜けが見える管理」を目指す
2. 「リスクの連鎖」を可視化するシンプルな地図を作る
まとめ——「対応後」を設計することがリスク管理の本丸だ
よくある質問

「対応した」は終わりではなく始まりだ——残留リスクと二次リスクの本質

多くのPMが陥る「完了バイアス」

リスク管理のプロセスにおいて、PMが最も油断しやすい瞬間がある。それは「対応策を実行したとき」だ。回避策を講じた、保険をかけた、バッファを積んだ——そこでリスク管理台帳に「対応済み」と記入した瞬間、多くのPMは無意識にそのリスクへの注意を緩める。これを「完了バイアス」と呼んでいい。

しかし、PMBOKが明確に定義しているとおり、リスク対応策を実行した後には必ず2種類の残存リスクが生まれる。ひとつが残留リスク（Residual Risk）、もうひとつが二次リスク（Secondary Risk）だ。前者は「対応を講じた後もなお残るリスク」であり、後者は「対応策を実行したことによって新たに生まれるリスク」を指す。

例えば、あるシステム開発プロジェクトで「主要ベンダーが納期に遅れるリスク」に対して「代替ベンダーを事前に確保する」という移転戦略を取ったとしよう。この時点で残留リスクとして「代替ベンダーも同様に遅延する可能性（確率は低いが消えてはいない）」が存在し、二次リスクとして「代替ベンダーへの仕様伝達コストが増加し、品質が下がるリスク」が新たに発生する。対応策を打ったことで1つのリスクが減り、別の2つのリスクが生まれているのだ。

なぜこの2つは見逃されやすいのか

残留リスクと二次リスクが見落とされる構造的な理由は3つある。第一に、リスク台帳の設計がそもそも「対応後」を記録する欄を持っていないことが多い。「リスク内容」「発生確率」「影響度」「対応策」の4列で終わっているリスク登録簿では、対応後の状態を追跡できない。第二に、レビューの頻度が「対応前」に集中していること。週次のリスクレビューが、未対応リスクの議論で時間を使い切り、対応済みのものは議題から外れていく。第三に、「対応した」ことへの心理的安堵感だ。チームとして一つの問題に向き合い、手を打てたという達成感は、注意のアンテナを下げる。

この3つが重なると、「対応済み」と書かれたリスクが事実上の盲点になり、プロジェクトの終盤に突如として問題が噴出する。

残留リスクを「見える化」する追跡設計のつくり方

リスク台帳に「対応後ステータス」の欄を設ける

残留リスクを管理するための第一歩は、リスク台帳そのものの構造を変えることだ。具体的には、以下の列を追加する。

対応後残存確率：対応策実施後の発生確率（例：対応前30% → 対応後10%）
対応後残存影響度：対応策実施後の影響規模
残留リスクの許容判断：この残存レベルをステークホルダーが承認したかどうか
モニタリング担当者と次回確認日：誰がいつ確認するかを明示

特に重要なのが「残留リスクの許容判断」だ。対応策を打った後に残るリスクが、プロジェクトオーナーやスポンサーにとって許容範囲内かどうかを明示的に合意する。この合意がないまま進めると、後に「そんなリスクが残っているとは聞いていない」というステークホルダーとの摩擦が生まれる。

あるインフラ移行プロジェクトでは、「データ消失リスク」に対してバックアップを三重化する対応策を講じた。残留リスクとして「バックアップ自体の整合性エラー（確率2%）」が残っていたが、これをPMが「許容範囲」と独断で判断し、顧客に伝えなかった。結果、移行後に実際にエラーが発生し、「なぜ事前に知らせなかったのか」という信頼問題に発展した。残留リスクの許容は、PMが一人で決めるものではない。

「対応後レビュー」を議題として固定する

対応後の残留リスクをモニタリングするには、週次リスクレビューの議題に「対応済みリスクの残留状況確認」を固定枠として設けることが効果的だ。時間は5〜10分でいい。「先週対応策を実行したAリスクについて、現在の残留状況はどうか」を問う時間を定例化するだけで、対応後の盲点が大幅に減る。

重要なのは、この確認を「形式」にしないことだ。「問題ありません」という報告を鵜呑みにせず、「具体的に何で確認したか」「数字はあるか」を問う習慣がPMには求められる。

二次リスクを「生まれた瞬間」に捕捉する仕組み

対応策の実施前に「二次リスク棚卸し」を義務化する

二次リスク管理の最大のコツは、対応策を実行する前の段階で「この対応策が何を引き起こすか」を問うステップを組み込むことだ。これを「二次リスク棚卸し」と呼ぼう。所要時間は対応策の規模にもよるが、15〜30分程度のミニレビューで十分だ。

具体的には以下の問いをチームで回す。

この対応策を実施することで、誰の仕事量が増えるか？
この対応策は、現在安定している別のプロセスを変えるか？
この対応策が外部（ベンダー・顧客）に影響を与えないか？
この対応策のコストが予算バッファを圧迫しないか？
この対応策を実施することで、スケジュールの別の箇所に負荷が移らないか？

実際の失敗例を挙げる。あるECサイト構築プロジェクトで、「パフォーマンス劣化リスク」に対してキャッシュサーバーを追加導入するという対応策を取った。この対応策の棚卸しを行わなかったため、キャッシュの整合性管理が複雑化し、「決済データが古いキャッシュを参照して二重請求が発生するリスク」という深刻な二次リスクを見落とした。リリース後に実際に問題が起き、緊急対応に3日を費やした。

二次リスク棚卸しを15分やっていれば、この問題は事前に発見できた。対応のコストより、見落としのコストの方がはるかに大きい。

二次リスクは「新規リスク」として登録する

棚卸しで発見した二次リスクは、元のリスクと紐づけた上で、リスク台帳に新規エントリとして登録する。これが重要だ。「Aリスクへの対応策から派生した二次リスクB」という形で親子関係を明示することで、二次リスクが独立して追跡可能になる。

また、リスク対応の戦略選択においても、二次リスクの性質によってアプローチが変わる。二次リスクが軽微であれば受容でよいが、影響度が高い場合はさらなる回避策や軽減策を設計しなければならない。「対応策の対応策」まで設計できているかどうかが、PMの深度を測る試金石になる。

なお、リスク登録簿を更新し続ける仕組みがなければ、二次リスクを新規登録しても形骸化する。台帳の更新ルールと確認サイクルがセットで設計されていることが前提条件だ。

現場を動かすための「軽い仕組み」の設計思想

完璧な管理より「抜けが見える管理」を目指す

残留リスクと二次リスクの管理を「完璧にやろう」とすると、プロセスが重くなり、チームが疲弊してリスク管理全体が形骸化する。現場PMに必要なのは、「抜けたときに気づける仕組み」であって、「抜けをゼロにする仕組み」ではない。

例えば、以下のような軽量チェックリストを対応策実施のたびに回すだけで十分だ。

□ 残留リスクの確率・影響を再評価したか？
□ 残留リスクの許容をステークホルダーと合意したか？
□ この対応策が生む二次リスクを3つ以上考えたか？
□ 二次リスクをリスク台帳に登録したか？
□ モニタリング担当者と次回確認日を設定したか？

5項目のチェックリストを1枚のシートに貼り付けておくだけで、対応後の管理が劇的に改善する。実際に筆者が支援したある製造業のDXプロジェクトでは、このチェックリストを導入した翌月のリスクレビューで、それまで「対応済み」と分類されていたリスクの約40%に残留リスクまたは二次リスクが未確認のまま放置されていたことが判明した。

「リスクの連鎖」を可視化するシンプルな地図を作る

プロジェクトが複雑になるほど、リスクは連鎖する。Aリスクへの対応が二次リスクBを生み、Bへの対応がさらに二次リスクCを生む。この連鎖を台帳の行として並べるだけでは全体像が見えない。

そこで有効なのが、リスク連鎖マップの作成だ。ホワイトボードや付箋、あるいはシンプルな図解ツールを使い、「Aの対応策→残留リスクA’→二次リスクB→Bの対応策→二次リスクC」という連鎖を矢印で視覚化する。これにより、チーム全員がリスクの全体像を共有でき、「次にどこを見るべきか」の優先順位が直感的に分かるようになる。

重要なのは、このマップを精緻に作ることではなく、「対話のツール」として使うことだ。週次レビューの冒頭5分でこのマップを眺め、「今週新たに発生した二次リスクはどこに追加するか」を議論するだけで、チームのリスク感度は着実に上がっていく。