「リスクを”予測”しようとするから失敗する」——不確実性を”シナリオの束”として扱い、プロジェクトの適応力を設計するリスク管理の実践技法

なぜリスク管理は「リスト作成」で終わってしまうのか

多くのプロジェクトで、リスク管理は「リスクを洗い出してリストに並べる」作業として認識されている。キックオフ時に関係者を集めてブレインストーミングを行い、確率と影響度を評価し、対応策を書き込む。そこで終わりだ。

しかしそのリストは、その後のプロジェクト会議で一度も開かれることなく、フォルダの奥に眠り続ける。そして何かが起きたとき、誰かが「あのリストに載っていたのに…」とつぶやく。

この構造的な失敗の原因は、リスク管理を「予測」の問題として捉えていることにある。リスクは予測するものではない。リスクは「シナリオの束」として保持し、現実の変化に照らし合わせながら、意思決定の質を高めるために使うものだ。

本記事では、この発想転換を出発点に、リスク管理を「生きた意思決定ツール」として機能させるための実践的な設計技法を紹介する。

「シナリオの束」として設計するリスク管理

リスクを”点”ではなく”文脈”として捉える

従来のリスク管理は、個々のリスクを独立した「点」として扱う。「外部ベンダーの納期遅延」「キーパーソンの離脱」「要件の後出し変更」——これらはそれぞれ別のリスクとして列挙され、個別に対策が割り当てられる。

しかし現実のプロジェクトでは、リスクは連鎖し、文脈の中で意味を持つ。ベンダー遅延が要件変更と重なったとき、影響は単純な足し算ではなく、指数関数的に膨らむことがある。

そこで有効なのが、「シナリオ・マッピング」というアプローチだ。個々のリスクを単体で管理するのではなく、「もし〇〇と〇〇が同時に発生したら、プロジェクトはどの状態に至るか」というシナリオとして記述する。

【実践Tips】シナリオを3層で設計する

• 楽観シナリオ：主要なリスクが顕在化しなかった場合のプロジェクトの姿
• 基本シナリオ：現在の前提条件が概ね維持された場合の姿（計画の根拠）
• 悲観シナリオ：複数のリスクが重なった場合に何が起きるかを具体的に記述

この3層構造を持つことで、「現在の状況は3つのシナリオのどれに近づいているか」という問いが、週次会議の中で自然に立てられるようになる。リスク管理が、会議の議題として生きた形で機能し始める瞬間だ。

「先行指標」を設計し、シナリオの遷移を早期に察知する

リスクが顕在化する前に「サイン」を読む

シナリオを設計しても、現実との照合ができなければ意味がない。ここで重要になるのが、「リスクトリガー指標（先行指標）」の設計だ。

リスクトリガー指標とは、あるリスクが顕在化しつつあることを示す、観測可能なシグナルのことだ。たとえば「外部ベンダーの納期遅延リスク」であれば、以下のような先行指標が考えられる。

• 週次の進捗報告の提出が遅れ始めている
• 担当者からの返信に「確認中」が増えてきた
• 中間成果物のレビュー依頼が予定より遅れた

これらは「遅延が起きた」という事実ではなく、「遅延が起きつつある」というシグナルだ。このシグナルを観測できる体制を作ることで、対応の時間的猶予を大幅に引き延ばすことができる。

【実践Tips】リスク台帳にトリガー欄を追加する

リスク管理台帳に「発生確率」「影響度」「対策」に加えて、「トリガー指標（観測対象）」と「観測頻度・担当者」の列を設ける。これにより、リスク台帳は「リスト」から「モニタリングの設計書」へと変貌する。

「対応策」ではなく「対応オプション」を持つ

決め打ちの対策がかえってリスクになる

リスクに対して「対応策」を1つ書き込む習慣は、実は危険だ。現実のリスクは、想定したとおりの形では顕在化しないことが多い。「ベンダー遅延に備えて内製化する」という対策を立てていても、内製リソースが別の課題に取られていたら、その対策は機能しない。

そこで有効なのが、各リスクに対して「対応オプションを複数保持する」発想だ。

• オプションA（予防策）：リスクが顕在化しないよう事前に打つ手
• オプションB（軽減策）：顕在化した場合に影響を最小化する手
• オプションC（転嫁策）：第三者に影響を移す手（保険・契約条項など）
• オプションD（受容）：コストを踏まえた上で、リスクを受け入れる判断

重要なのは、「どのオプションを選ぶか」を事前に決めきらず、「トリガーが何を示しているかに応じて、どのオプションを発動するか」を設計することだ。これにより、リスク管理はルールブックではなく、意思決定の地図として機能する。

リスク管理を「PMの仕事」から「チームの習慣」へ

週次のリズムにリスクレビューを埋め込む

リスク管理がPMだけの責任になると、現場から遠い「書類仕事」に堕してしまう。チームメンバーが日常業務の中でリスクのシグナルを最も早く察知できるからこそ、リスク管理はチーム全員の習慣として設計する必要がある。

具体的には、週次の進捗会議に「今週気になったこと・変化したこと」を5分間共有するアジェンダを追加するだけでよい。これをシナリオ・マップと照らし合わせることで、「それはBシナリオへの遷移サインかもしれない」という対話が自然に生まれる。

リスク管理とは、PMが「管理する」ものではなく、チームが「対話する」ものだ。その対話の設計こそが、PMの本当の仕事である。

まとめ：リスク管理は「予測」ではなく「適応の設計」だ

不確実性の高い現代のプロジェクトにおいて、リスクを正確に予測することは誰にもできない。PMに求められるのは、予測の精度を高めることではなく、何が起きても適応できる構造をプロジェクトに埋め込むことだ。

シナリオを束として持ち、先行指標でシグナルを観測し、複数の対応オプションを用意しておく。この設計思想を持つことで、リスク管理は「転ばぬ先の杖」から「プロジェクトの適応エンジン」へと進化する。

今日から、あなたのリスク台帳に「シナリオ」「トリガー指標」「対応オプション」の3つを追加することから始めてみてほしい。