プロジェクトのリスク管理：特定・分析・対応計画・監視を回す実務手順

「もう起きていること」はリスクに入らない

PMIはリスクを、「発生した場合にプロジェクトの目標にプラスまたはマイナスの影響を与える、不確実な事象または状態」と定義しています。短い一文ですが、含意は2つあります。すでに起きた事柄は、この定義から外れる。そして影響はマイナス側だけとは限らない。

マイナスの影響を与えるリスクを脅威、プラスの影響を与えるリスクを好機と呼びます。実務で「リスク管理」と言うとき、指しているのはほぼ脅威の管理でしょう。ただし標準の枠組みは、好機も同じプロセスに乗せます。納期を縮められる技術が出てくる、想定より安く調達できる目処が立つ。こうした事柄も、意識して管理すれば取りに行けます。

PMBOKガイドの体系では、2025年11月に公開された第8版で、リスクが独立したパフォーマンス領域の1つになりました。第8版の領域は、ガバナンス、スコープ、スケジュール、財務、ステークホルダー、リソース、リスクの7つです。第7版では「不確かさ」という、曖昧さや変動性まで含む広い概念の領域が置かれていましたが、第8版ではそこから、より実務で使われる「リスク」という名称の領域として切り出された形になっています。

プロセスの並びについては、第6版の知識エリア「プロジェクト・リスク・マネジメント」が、リスクマネジメントの計画、リスクの特定、定性的リスク分析、定量的リスク分析、リスク対応の計画、リスク対応策の実行、リスクの監視という7つで整理していました。第8版は約40のプロセスを各領域の中に置き直していますが、いずれも守るべき手順ではなく、プロジェクトの性質に応じて取捨選択する参照情報として提示されています。なお、第8版のリスク領域に属するプロセスの正確な一覧は、一次情報にあたって確認できていません。そのためこの記事では、第6版の7プロセスの流れを実務の骨格として使います。

以下、特定から監視までを順に追います。ただし全プロセスを律儀に回す必要はありません。期間3か月・5人のプロジェクトで定量分析まで実施すると、分析の工数だけが残り、判断は何も変わらないことのほうが多いはずです。

リスク管理と課題管理は別物：混ぜると両方が機能しなくなる

実務で最初につまずくのが、リスクと課題（イシュー）の区別です。両者の違いは発生しているかどうかの一点に尽きます。リスクはまだ発生していない不確実な事象であり、課題はすでに発生している事象です。そしてリスクが顕在化した瞬間、それはリスクではなく課題になります。

分ける理由は、打つ手がまるで違うからです。リスクに対して行うのは、発生確率を下げる、影響を小さくする、発生したときの備えを用意しておく、といった予防です。課題に対して行うのは、目の前で起きている事態を収束させることです。予防と対処を同じ表に載せると、締切が明確な課題ばかりが注目され、まだ起きていないリスクは後回しになります。

混ぜたときのもう1つの弊害は、管理表の肥大化です。まだ発生していない懸念事項まで課題管理表に登録されると、行数が膨らんで優先順位の判断が難しくなり、本当に対応すべき課題が埋もれます。逆に、すでに発生している事象がリスク管理表に残り続けると、対応期限が設定されないまま放置されます。

運用としては、リスク登録簿と課題管理表を別々に持ち、リスクが顕在化したらリスク登録簿の当該行を「顕在化」でクローズし、課題管理表に新しい行を起こす、という受け渡しのルールを決めておくのが分かりやすい形です。このとき、リスク登録簿に書いてあった対応策がそのまま課題の初動になるため、事前に対応策を書いておく意味がここで回収されます。

手順1：リスクを特定する

リスク管理は、洗い出しの網羅性で成否がほぼ決まります。ここで漏れたリスクは、以降のどのプロセスでも拾えません。

洗い出しを個人の思いつきに任せないための道具が、RBS（Risk Breakdown Structure、リスク分解構成図）です。リスクの発生源をカテゴリ別に階層化した一覧で、これをチェックリストとして使いながら「この分類に該当するリスクはうちのプロジェクトにないか」と順番に問うていきます。大分類としては、技術リスク、外部リスク、組織リスク、プロジェクトマネジメントリスクの4つがよく用いられます。技術には要件・技術選定・性能などが、外部には規制・調達先・市場環境などが、組織には要員・予算・優先順位の変更などが、プロジェクトマネジメントには計画・コミュニケーション・見積もりなどが含まれます。

特定の場は、PM1人ではなくチームで持つべきです。技術的なリスクは開発担当が、調達のリスクは購買担当が、顧客側の事情はアカウント担当がいちばんよく知っています。ブレーンストーミングのほか、経験者へのヒアリング、過去の類似プロジェクトの記録の参照、前提条件の棚卸しなどを組み合わせます。前提条件の棚卸しは、いちばん短い近道です。計画書に「顧客の要員が3名確保される前提」と書いてあれば、その前提が崩れることがそのままリスクになります。

書き方にも定石があります。実務で広く使われるのが、原因・事象・影響の3つを分けて記述する形式です。「確定している原因が存在するために、不確実な事象が発生する可能性があり、その結果として目標にこの影響が及ぶ」という構造で書きます。たとえば「移行対象データの仕様書が存在しないため、移行プログラムの手戻りが発生する可能性があり、その結果として結合テストの開始が遅れる」といった形です。

この形式を使う利点は、リスクではないものを弾けることです。「仕様書が存在しない」だけでは、それはすでに確定している事実であり原因にすぎません。「テストの開始が遅れる」だけでは、それは影響であって、何が起きるのかが書かれていません。原因と影響しか書けないリスクは、たいてい掘り下げが足りていないか、そもそもリスクではなく課題です。

手順2：定性分析で優先順位をつける

洗い出したリスクをすべて同じ熱量で管理することはできません。次のプロセスは、優先順位づけです。ここで使うのが定性的リスク分析で、各リスクの発生確率と影響度を評価し、優先度を決めます。

標準的な道具が確率・影響度マトリクスです。縦軸に発生確率、横軸に影響度を取り、各リスクをマスに配置します。確率と影響度をそれぞれ高・中・低の3段階、あるいは1から5の数値で評価し、掛け合わせた値をリスクスコアとして順位づけするのが一般的な運用です。

先にやることが1つあります。評価尺度を、プロジェクト開始時に決めておくことです。「影響度：大」が何を指すのか決めないまま各自に評価させると、人によって基準が3倍も5倍も違い、順位づけが成立しません。金額なら「500万円以上を大、100万円以上を中、それ未満を小」、スケジュールなら「クリティカルパスに2週間以上の遅延なら大」というように、プロジェクトの規模に合わせた具体的な閾値を先に合意しておきます。確率についても、「50%以上を高」といった目安を決めておきます。

定性分析は主観にもとづきます。それが欠点とは限りません。全リスクを1時間ほどでふるいにかけられるので、上位に残ったものだけを定量分析や個別の対応計画に送る、という絞り込みの道具として使えます。

手順3：定量分析は必要なときだけ

定量的リスク分析は、リスクの影響を数値として算出する手法です。定性分析が高・中・低といったランクづけであるのに対し、定量分析は金額や日数といった数値でプロジェクト目標への影響を計算します。

代表的な手法が期待金額価値（EMV）です。各結果の金額に発生確率を掛け、それらを合計して加重平均を求めます。発生確率30%、発生時の追加費用が1,000万円のリスクであれば、期待金額価値は300万円です。この考え方は、コンティンジェンシー予備の金額を積み上げる根拠として使えます。

もう1つがモンテカルロ・シミュレーションです。各作業の所要期間やコストに、点ではなく幅（分布）を与え、乱数を使って何千回もプロジェクト全体を試行します。結果として「この納期を守れる確率は何%か」「80%の確率で収まる予算はいくらか」という確率的な答えが得られます。ほかに、意思決定の分岐を図に描いて期待値を比較する決定木分析や、どの変数が結果に最も影響するかを見る感度分析があります。

ただし、定量分析はすべてのプロジェクトで必要なわけではありません。入力データの精度が低ければ、出てくる数値の精度も低くなります。実施が正当化されるのは、金額規模が大きい、失敗の影響が重大である、あるいはステークホルダーが「どの程度の確度でこの予算に収まるのか」という定量的な説明を求めている、といった場合です。小規模なプロジェクトで無理に実施しても、労力に見合う判断材料は得られません。定性分析までで止めるという判断も、正当な選択です。

手順4：対応を計画する（脅威への4戦略とエスカレーション）

優先度の高いリスクには、具体的な対応方針を決めます。脅威に対する戦略として整理されているのが、回避、転嫁、軽減、受容の4つです。これに加えて、PMの権限を超えるリスクを上位者に引き渡すエスカレーションが位置づけられています。

回避は、脅威そのものをなくす、あるいは影響を受けないようにする戦略です。実績のない新技術の採用をやめて枯れた技術に切り替える、リスクの高い範囲をスコープから外す、といった対応が該当します。発生確率も影響度も高いリスクに向いた戦略ですが、多くの場合は計画そのものの変更を伴うため、代償があります。

転嫁は、脅威の影響を第三者に移す戦略です。保険をかける、契約形態を変える、専門ベンダーに委託するといった手段があります。発生確率は低いが、起きたときの影響が大きいリスクに向いています。ただし転嫁はリスクを消すわけではなく、対価を払って移すだけです。

軽減は、発生確率か影響度、あるいはその両方を下げる戦略です。実務で最も多く使われるのがこれにあたります。プロトタイプを先に作って技術検証する、冗長構成にする、レビュー回数を増やす、といった対応が該当します。

受容は、何もしないという積極的な判断です。発生確率も影響度も低いリスクに向いています。受容には、発生したときに備えてコンティンジェンシー予備（時間や費用の予備）を確保しておく能動的な受容と、予備も置かず発生したら都度対応する受動的な受容があります。「何も書かない」ことと「受容と書く」ことは違います。後者は、検討したうえで対応しないと決めた記録が残ります。

エスカレーションは、そのリスクがプロジェクトのスコープやPMの権限の外にある場合に選びます。全社的な法規制の変更や、複数プロジェクトに共通する組織課題などが典型です。エスカレーションした時点で、そのリスクの所有権はプログラムや組織の側に移ります。ここを曖昧にしたまま「報告はした」で止めると、誰も対応していない状態が生まれます。引き取り先と引き取り後の責任者を明確にすることが必要です。

対応を計画する際には、2種類の派生リスクにも注意します。1つは二次リスクで、リスク対応策を実施した結果として新たに生じるリスクです。遅延対策として増員した結果、品質のばらつきが増えるといったケースが該当します。もう1つは残存リスクで、対応策を講じたあとも残るリスクです。どちらも「対応したから安心」という思い込みを防ぐために、登録簿に明示しておく価値があります。

なお、好機に対しては、活用、共有、強化、受容といった戦略が対応するものとして整理されています。脅威側の回避・転嫁・軽減・受容と鏡写しの関係です。

リスク登録簿の書き方

ここまでの検討結果を1つにまとめる文書がリスク登録簿（リスク管理表）です。リスクの特定プロセスで初めて作成され、以降の分析・対応計画・監視の各段階で継続的に更新されていきます。

記載する項目としては、次のようなものが挙げられます。まずリスクID、リスクの記述（原因・事象・影響の3点セット）、リスクのカテゴリ。次に発生確率、影響度、それらを掛け合わせたリスクスコアと優先度。そしてリスクオーナー、対応戦略の区分、具体的な対応策、対応の期限。さらにトリガー（予兆）、コンティンジェンシー計画とその発動条件、二次リスクと残存リスク、ステータス（未対応・監視中・顕在化・クローズなど）です。

この中で運用上とりわけ効くのが、リスクオーナーとトリガーの2項目です。リスクオーナーは、そのリスクを監視し、必要になったら対応策を実行する責任を負う個人です。「チーム」や「開発部」といった組織名で書くと、誰も見ていない状態になります。必ず個人名で1人を指定してください。

トリガーは、リスクが顕在化しつつあることを示す予兆や条件です。たとえば「要員が確保できない」というリスクであれば、「着手2週間前の時点で候補者の面談が完了していない」がトリガーになります。トリガーを事前に定義しておくと、リスクの監視が「なんとなく気にかける」から「この条件を満たしたか確認する」という判定可能な作業に変わります。そして、トリガーを検知したらコンティンジェンシー計画を発動する、という接続まで書いておけば、いざというときの初動が速くなります。

予算の扱いについても整理しておきます。特定済みのリスク、いわゆる既知の未知に備えて確保するのがコンティンジェンシー予備で、これはコスト・ベースラインに含まれ、PMの裁量で使えます。一方、特定できていないリスク、いわゆる未知の未知に備えるのがマネジメント予備で、これはコスト・ベースラインには含まれず、使用にあたっては上位者の承認が必要です。この2つを区別せずに「予備費」として一括で持つと、リスク対応で使ったのかスコープ追加で使ったのかが分からなくなり、次のプロジェクトの見積もり精度が上がりません。

手順5：登録簿を腐らせない監視と、現場で繰り返される6つの失敗

計画時に一度洗い出して登録簿を作り、あとは触らない。これが最も多い壊れ方です。リスクの監視は、プロジェクト全期間を通じて登録簿をレビューし、更新し続けるプロセスとして位置づけられています。作成した瞬間が、そのプロジェクトで最も情報が少ない瞬間です。更新されない登録簿は、その最も情報が少ない時点の推測を貼り付けたまま残ります。

運用の型としては、定例会議の議題にリスクレビューを固定枠で入れるのが確実です。毎回すべてのリスクを見る必要はありません。優先度の高い上位のリスクについて、トリガーの状況、対応策の進捗、確率や影響度の再評価を確認し、あわせて新規リスクの有無を問う、という進め方で足ります。フェーズの切り替わりや大きな変更が起きたタイミングでは、全件の棚卸しを行います。

第1の典型的な失敗が、いま述べた「作って終わり」です。回避策は、レビューの頻度とタイミングをリスクマネジメント計画に明記し、定例の議題に組み込むことです。

第2の失敗は、リスクと課題を同じ表で管理することです。前述のとおり、予防の議論が対処の議論に押し流されます。表を分け、顕在化したときの受け渡しルールを決めてください。

第3の失敗は、リスクオーナーが不在か、組織名になっていることです。個人名で1人を指定し、その人が定例で状況を報告する仕組みまで作ってはじめて機能します。

第4の失敗は、対応策が抽象的なことです。「注意する」「早めに着手する」は対応策ではありません。誰が、いつまでに、何をするかが書かれていなければ、実行されたかどうかを確認できません。

第5の失敗は、悪い情報が上がってこない文化です。リスクを報告した人が責められる、あるいは「対策は考えたのか」と詰められる環境では、リスクは隠されます。隠れたリスクは分析も対応もできないまま、ある日課題として表面化します。報告を歓迎する姿勢を、PMが繰り返し示す必要があります。

第6の失敗は、登録簿の肥大化です。数百行の一覧を作っても、全部は見られません。優先度の低いリスクは監視リストに落とし、定例で扱うのは上位の一定件数に絞る運用にしたほうが、実際には多くのリスクに対処できます。

最後に、着手の順序について。リスク管理は、精緻な様式を整えることから始める必要はありません。まずはチームを集めて1時間、原因・事象・影響の形式でリスクを書き出し、確率と影響度で並べ替え、上位のものにオーナーと対応策とトリガーを付ける。これだけで、リスク管理の骨格は動き始めます。様式の精緻化は、運用が回り始めてからで間に合います。