「起きてから考える」は遅すぎる——PMが身につけるべきリスク管理の実践手法

「リスクは起きてから考える」では遅すぎる

プロジェクトを担当して間もない頃、筆者はリスク管理を「何か問題が起きたときに対応するための仕組み」だと思っていました。しかし実際には、問題が表面化した時点でできることはひどく限られています。予算は使い込まれ、スケジュールは逼迫し、ステークホルダーの信頼は揺らいでいる——そういう状態でできる「対応」は、傷口を広げないことが精一杯です。

リスク管理の本質は「まだ何も起きていないうちに、起きる可能性を特定し、影響を小さくしておく」ことです。地味で、成果が見えにくく、うまくいっているときほど「やる必要があったのか」と問われがちな仕事ですが、プロジェクトの命運を左右する最重要活動の一つです。本記事では、PMBOKに基づくリスク管理のプロセスを軸に、現場で実際に機能する手法を具体的に解説します。

リスク管理の全体像：4つのプロセス

PMBOKのリスク管理知識エリアでは、リスク管理は大きく以下の4プロセスで構成されます。

この4つはプロジェクト開始時に一度やれば終わりではなく、フェーズの節目ごと、あるいは環境の変化があるたびに繰り返し実施するものです。リスク管理を「計画フェーズだけの作業」と捉えているPMほど、後工程で想定外の事態に振り回されることになります。

プロセス1：リスクの特定

「思いつかなかった」では済まされない

リスクの特定とは、プロジェクトに悪影響を及ぼす可能性のある要素をできる限り網羅的に洗い出すことです。「思いつきで列挙する」のではなく、構造的なアプローチを使うことが重要です。

代表的な手法のひとつがWBS（Work Breakdown Structure）を活用したリスク洗い出しです。プロジェクトの作業を階層的に分解したWBSを見ながら、各作業単位に対して「何がうまくいかないか」を問いかけていきます。設計工程なら「要件の認識齟齬」「技術的な実現可能性の未確認」、テスト工程なら「テスト環境の整備遅延」「想定外の不具合件数」——このように作業の粒度に落として考えると、見落としが大幅に減ります。

もう一つ有効なのがチェックリストによる確認です。過去のプロジェクトで発生した問題を記録・整理したリストは、組織の「転ばぬ先の杖」として機能します。初めてのプロジェクトタイプでも、類似プロジェクトの経験者に話を聞くインタビューを行うことで、机上では気づけないリスクを発見できます。

ネガティブリスクだけでなく「好機」も特定する

PMBOKでは、リスクにはマイナスの影響をもたらす「脅威」とプラスの影響をもたらす「好機」の両方が含まれると定義されています。「新しいクラウドサービスを使うことでコストが想定より下がる可能性」「競合製品の遅延によって自社の市場投入タイミングが有利になる可能性」——こうした好機を積極的に特定・活用する意識もリスク管理の一部です。日本のIT現場では脅威ばかりに目が向きがちですが、好機の活用はプロジェクト価値の最大化に直結します。

プロセス2：リスクの分析

定性分析：まず「ざっくり優先順位」をつける

リスクをすべて同じ力で対処しようとすると、リソースが分散して本当に重要なリスクへの対応が手薄になります。そこでまず行うのが定性的リスク分析です。各リスクについて「発生確率（高・中・低）」と「影響度（高・中・低）」の2軸で評価し、優先順位をマトリクスに可視化します。

このリスクマトリクスは、発生確率と影響度が両方高いリスクを「最優先対応」として赤でマーキングし、低いものをグリーンゾーンとして扱うヒートマップ的な表現が一般的です。視覚的にわかりやすく、ステークホルダーへの説明にも使いやすいため、チームで共有するアーティファクトとして非常に有効です。

定量分析：数字で影響を測る

重要度が高いリスクに対しては、さらに踏み込んで定量的リスク分析を行います。モンテカルロシミュレーション（確率論的なシミュレーション手法）を使って「このリスクが現実化した場合、スケジュールが何日延びるか」「コストはどれだけ増えるか」を数値で見積もります。

定量分析は専門的なツールや知識が必要なため、すべてのプロジェクトで実施する必要はありません。しかし、予算規模が大きいプロジェクトや、リスクが現実化した際のビジネス影響が甚大なケースでは、投資に見合うだけの価値があります。少なくとも「コンティンジェンシー予備（リスク対応のための予算バッファ）」を定量的に算出する際には、この考え方が役立ちます。

プロセス3：リスク対応計画

4つの対応戦略を使い分ける

リスクの優先順位が定まったら、各リスクに対してどう対処するかを決めます。対応戦略は大きく4つあります。

回避（Avoid）は、リスクの原因そのものを除去する戦略です。「特定の技術を採用するとリスクが高いため、別の実績ある技術を選ぶ」という判断がこれにあたります。最もリスクを確実に下げられる反面、スコープや技術選定の変更を伴うため、早い段階でないと選びにくい戦略です。

転嫁（Transfer）は、リスクの影響を第三者に移す戦略です。保険の契約、外部ベンダーへの作業委託、契約上のペナルティ条項の設定などがこれにあたります。リスクそのものをなくすわけではありませんが、影響を受ける主体を変えます。

軽減（Mitigate）は、リスクの発生確率や影響度を下げる対策を打つ戦略です。「テスト環境の整備を早めに着手する」「技術検証（PoC）を先行して行う」「経験豊富なメンバーをアサインする」などが代表例です。最も日常的に使われる戦略です。

受容（Accept）は、対処コストが影響度を上回る場合や、確率が極めて低い場合にリスクをそのまま受け入れる判断です。ただし受容する場合も、発生時の対応手順（コンティンジェンシープラン）をあらかじめ準備しておくことが重要です。「受容」と「放置」は全く異なります。

プロセス4：リスクの監視とコントロール

リスク台帳を「生きたドキュメント」として維持する

リスク管理で最もよく見られる失敗パターンは、「計画フェーズでリスク台帳を作って、その後誰も更新しない」というものです。リスクは静的なものではありません。プロジェクトが進むにつれて新たなリスクが浮上し、既存のリスクの重要度は変わり、対応策の効果も検証が必要になります。

リスク台帳は週次や隔週の進捗会議で定期的にレビューし、状態を「未対応・対応中・解消・顕在化（問題化）」で更新し続けることが必要です。顕在化したリスク、すなわち実際に問題となったものは「課題（Issue）」として別管理に移し、リスク台帳からは切り離します。リスクと課題を混在させると、管理の精度が著しく落ちます。

残存リスクと二次リスクを忘れない

対応策を実施した後も、リスクが完全になくなるとは限りません。対応後に残るリスクを残存リスクと呼び、引き続き監視の対象です。また、対応策を実施したことで新たに生まれるリスクを二次リスクと呼びます。たとえば「外部ベンダーに作業を委託する（転嫁）」という対応を取った場合、「ベンダーの品質管理が不十分になるリスク」という二次リスクが生じます。対応後の世界にも目を向けることが、成熟したリスク管理の証です。

まとめ：リスク管理は「心配性の仕事」ではない

リスク管理を丁寧にやるPMは、「悲観的な人」ではなく「最悪の事態を想定しながら最善を尽くす人」です。リスクを早期に特定し、対応策を持った状態でプロジェクトを進めることは、チームに安心感を与え、ステークホルダーへの信頼を積み上げます。

「起きてから考える」と「起きる前に備える」では、プロジェクトの消耗度がまったく異なります。リスク管理に費やした時間は、後工程での炎上対応時間として何倍にもなって返ってきます。これはコストではなく、投資です。