プロジェクトリスクマネジメントとは：6ステップのプロセスを解説

プロジェクトリスクマネジメントとは、プロジェクトで何が問題になり得るかを特定し、各脅威が実際にどれほど起こりやすく、どれほど深刻かを見極め、脅威が危機になる前に対応計画を用意しておく体系的な実践です。未来を予測することが目的ではありません。チームが反応するのではなく、先回りして行動できるだけの十分な警告を与えることが目的です。

失敗するプロジェクトの多くは、一つの壊滅的な出来事によって失敗するわけではありません。小さく予見可能な問題が放置され、積み重なって失敗に至るのです。主要ベンダーの納品が遅れた。設計確定後に要件が変更された。ある技術的前提が誤りだった。これらの出来事はどれも予測可能でした。足りなかったのは、それらを早期に表面化させるプロセスでした。

このガイドでは、PMBOKガイド（Project Management Body of Knowledge）で定義されている6ステップのプロセスを順に解説し、各ステップで使うツールを説明し、脅威と好機の両方を扱います。そうです、リスクマネジメントには上振れの要素も含まれます。ポジティブなリスクも、ネガティブなリスクと同じくらい管理する価値があります。

プロジェクトリスクマネジメントとは何ですか

プロジェクトリスクマネジメントとは、プロジェクトのライフサイクル全体を通じてリスクの計画立案、特定、分析、対応、モニタリングをカバーする、プロジェクトマネジメントの知識エリアです。PMBOKガイドでは、これをスコープ、スケジュール、コスト、品質と並ぶ10の中核知識エリアの一つとして扱っています。

リスクとは、発生した場合にプロジェクト目標にプラスまたはマイナスの影響を与える、不確実な出来事や状況のことです。この最後の部分が重要です。リスクはすべてが悪いものとは限りません。

• 脅威とはネガティブなリスクです。遅延、予算超過、リソース不足、技術的な失敗などです。
• 好機とはポジティブなリスクです。ベンダーが早期に納品する、ある技術が想定より速く機能する、市場のタイミングが開けるなどです。

どちらの種類も管理する価値があります。脅威だけを追跡しているチームは、有利な条件が生まれたときにそれを積極的に活かすチャンスを逃してしまいます。

リスクマネジメントの成果物は懸念事項のリストではありません。各リスクに対して何をするか、誰が責任を持つか、いつ行動すべきかを判断できる一連の意思決定です。

重要な事実

• PMIの「Pulse of the Profession」調査によると、効果的なリスクマネジメントの実践を持たない組織は、プロジェクトの失敗やスコープクリープの問題を経験する可能性が著しく高くなります。PMIのデータは一貫して、高パフォーマンスの組織は低パフォーマンスの組織よりもプロアクティブなリスク特定にはるかに多くを投資していることを示しています。（出典：PMI Pulse of the Profession, 2023年）
• PMBOKガイド（第7版）は、リスクマネジメントを単なるプロセス群ではなく、12のプロジェクトマネジメント原則の一つとして扱っています。これは、リスクをチェックリストとして捉える見方から、プロジェクトライフサイクル全体を通じた継続的な規律として捉える見方への転換を反映しています。
• KPMGなどによる大規模資本プロジェクトの調査によると、スケジュールやコストの超過は、早期に把握されていたにもかかわらず正式に追跡されず、誰も所有していなかったリスクに起因することが最も多いとされています。予測不可能な出来事が原因であることはまれです。

プロジェクトリスクマネジメントの6ステップ

PMBOKガイドは、リスクマネジメントを6つの連続的かつ反復的なプロセスに整理しています。プロジェクトの開始時にほぼこの順序で実行し、その後は特定とモニタリングを継続的に繰り返します。

ステップ1：リスクマネジメントを計画する

リスクを管理する前に、どのように管理するかを決める必要があります。この段階の成果物がリスクマネジメント計画です。そこには次の内容が文書化されます。

• リスクマネジメントのアプローチと方法論
• リスク関連活動の役割と責任
• リスクカテゴリー（多くの場合、リスク・ブレークダウン・ストラクチャー、RBSとして整理されます）
• 発生確率と影響度の尺度（全員が同じ基準でリスクをスコアリングできるように）
• リスク許容度（組織とステークホルダーが受け入れる用意のあるリスクの水準）
• 報告フォーマットとコミュニケーションプロトコル

このステップはきちんとやる価値があります。「発生確率中」という評価をチームが一致して定義できなければ、リスク登録簿は一貫性を欠き、優先順位付けの役に立たなくなります。早い段階で定義をすり合わせましょう。

このステップで使うツール：**リスク・ブレークダウン・ストラクチャー（RBS）**とリスクマネジメント計画のテンプレート。

ステップ2：リスクを特定する

特定とは、思いつく限りのリスクを人々の頭の中から共有ドキュメントへと引き出す作業です。ここでの目的は精密さではなく網羅性です。絞り込みと分析は後で行います。

一般的な特定手法には次のようなものがあります。

• コアプロジェクトチームによるブレインストーミングセッション
• 有識者やプロジェクトのベテランへの専門家インタビュー
• 過去の類似プロジェクトの履歴リストを用いたチェックリスト分析
• SWOT分析（強み、弱み、機会、脅威）
• 前提条件分析（プロジェクトの前提のどこが間違っている可能性があるかを特定する）
• プロジェクト憲章、スコープ記述書、スケジュールのドキュメントレビュー

この成果物が初期のリスク登録簿（リスクログとも呼ばれます）です。これは、特定された各リスクを簡単な説明、カテゴリー、初期のオーナーとともに記録する生きたドキュメントです。含めるべき内容の詳細はリスク登録簿のガイドを参照してください。

すべてのメンバーが参加すべきです。開発者が気づくリスクは、調達部門や財務部門が気づくリスクとしばしば異なります。部門横断的なインプットが盲点を防ぎます。

ステップ3：定性的リスク分析を行う

すべてのリスクに等しく注意を払うことはできません。定性的分析は、発生確率（どれくらい起こりやすいか）と影響度（起きた場合にどれほど深刻か）という2つの観点で各リスクに優先度スコアを付けます。

標準的なツールは発生確率・影響度マトリクスで、リスクマトリクスと呼ばれることも多いです。各リスクを尺度（通常は各観点で1〜5、または低・中・高）で評価し、スコアを掛け合わせて、どこに注意を向けるべきかを示すランキングを得ます。

このステップの成果物は、優先度スコアと重点監視リストを反映した更新済みのリスク登録簿です。定性的分析はスピーディーでデータを必要としません。ただし主観的であるという限界があります。経験豊富な2人のPMが同じリスクを異なるスコアで評価することもあります。

ステップ4：定量的リスク分析を行う

すべてのプロジェクトにこのステップが必要というわけではありません。定量的分析は、プロジェクト全体のリスクを数値で見積もる必要がある、大規模、複雑、あるいは影響の大きいプロジェクトで手間をかける価値があります。

一般的な手法には次のようなものがあります。

• モンテカルロシミュレーション：数千通りのコンピューターモデルによるシナリオを実行し、プロジェクトの結果（コスト、スケジュール）の確率分布を導き出します。シミュレーションでプロジェクトが期限内に完了する確率が70%と出れば、どこに注力すべきかが分かります。実務での動かし方についてはモンテカルロシミュレーションのガイドを参照してください。
• 期待金額価値（EMV）：リスクイベントの発生確率にその財務影響を掛け合わせ、金額で重み付けしたリスクスコアを算出します。対応オプションの比較に役立ちます。
• デシジョンツリー分析：各分岐に確率と結果を付与し、枝分かれするシナリオを図示します。

成果物は、コンティンジェンシー予備費、スケジュールバッファ、実行可否の判断を支える定量化されたリスクエクスポージャーの全体像です。

ステップ5：リスク対応を計画する

実際のマネジメントが行われるのはここです。優先度の高い各リスクについて、チームは具体的な対応戦略を定義し、オーナー（「PM」や「チーム」ではなく、名前の付いた特定の人物）を割り当てます。

対応戦略はリスクの種類によって異なります。脅威と好機では取るべきアプローチが異なるため、次のセクションで詳しく扱います。

リスク対応計画では、以下も特定しておくべきです。

• 残存リスク：対応を実施した後にも残るリスク
• 二次リスク：対応そのものによって新たに生まれるリスク
• コンティンジェンシープラン：対応にもかかわらずリスクが発生した場合にどうするか
• フォールバックプラン：コンティンジェンシープランも失敗した場合の代替策
• コンティンジェンシー予備費：既知のリスクをカバーするために確保しておく予算やスケジュールのバッファ

ステップ6：リスク対応を実行し、リスクをモニタリングする

計画書を書いた時点でリスクマネジメントが終わるわけではありません。最終ステップ（継続的に実行されます）には次が含まれます。

• 計画した対応の実行
• トリガー（リスクが顕在化しようとしている早期警告サイン）のモニタリング
• プロジェクトの進展に応じた既存リスクの再評価
• プロジェクト途中で新たに現れるリスクの特定
• ステークホルダーへのリスクステータス報告
• もはや該当しなくなったリスクのクローズ

たとえ短時間でも、週次のリスクレビュー会議を行うことで登録簿を最新の状態に保てます。RAIDログは、リスクを前提条件、課題、依存関係とともに一箇所で追跡する実用的なツールです。

リスク対応戦略

異なるリスクには異なる対応が求められます。PMBOKガイドは、脅威に対して4つ、好機に対して4つの戦略を定義しています。

プロジェクトリスクマネジメントのメリット

適切に行えば、リスクマネジメントは災害を防ぐだけにとどまりません。チームの働き方そのものを変えます。

サプライズが減る。 リスクが文書化され、オーナーが明確になっていれば、何か問題が起きてもチームは不意を突かれません。既に対応策が用意されています。

より良い意思決定。 定量化されたリスクエクスポージャーは、コンティンジェンシー予備費、実行可否のゲート、スコープのトレードオフに関する意思決定に直接活かされます。勘ではなく根拠に基づいて判断できます。

ステークホルダーの信頼。 経営層やクライアントは、「上位5つのリスクはこれで、それぞれについてこう対処しており、対策が及ばない場合のバッファはこれです」と言えるチームを信頼します。

見積もり精度の向上。 リスクを長期にわたって追跡しているチームは、プロジェクトで実際に何がうまくいかなかったかの履歴を蓄積します。その履歴が将来の見積もりの精度を高めます。

好機の獲得。 ポジティブなリスクを追跡しているチームは、有利な条件を見過ごさず積極的に活用します。

プロジェクトリスクマネジメントでよくある間違い

一度作って終わりのリスクログ。 リスク登録簿はプロジェクトのキックオフ時に作成された後、二度と更新されません。リスクは進化します。新しいリスクが現れます。古いリスクは意味を失います。一度しか更新されない登録簿は、マネジメントツールではなくコンプライアンス上の成果物にすぎません。

ポジティブなリスクを無視する。 ほとんどのチームは脅威しか追跡しません。計画より物事がうまく進む可能性のある条件を誰も注視していないため、好機が見逃されます。

名前の付いたオーナーがいない。 「チーム」に割り当てられたリスクは、実質的に誰にも割り当てられていないのと同じです。すべてのリスクには、トリガーを監視し対応を実行する責任を負う、名前の付いた一人の担当者が必要です。

曖昧な対応。 「注意深く見守る」はリスク対応にはなりません。実際の対応とは、いつ、誰が、どのようなアクションを取るのかを具体的に示すものです。

リスクスコアを固定と見なす。 キックオフ時に「発生確率低」と評価されたリスクが、条件の変化により3週間後には「発生確率高」のリスクになることもあります。スコアは一度記録して終わりではなく、定期的に見直す必要があります。

複雑なプロジェクトで定量ステップを省略する。 予算への影響が大きい大規模プログラムでは、定性的スコアリングだけでは不十分です。モンテカルロ分析やEMV分析は、スポンサーに対して根拠を示せる数値を与えてくれます。

プロジェクトリスクマネジメントの例

あるソフトウェア企業が、契約更新に紐づく厳格な締め切りの中で、レガシーCRMを新しいクラウドプラットフォームに移行するケースを考えてみましょう。

リスクマネジメントのプロセスは次のように展開します。

チームはスケジュール見積もりを使ってモンテカルロシミュレーションを実行します。現行計画では締め切りを守れる確率は65%ですが、2週間のバッファを追加しデータ移行テストを2週間早く開始すれば確率は90%になることが分かります。これをスポンサーに提示し、スケジュール延長が承認されます。プロジェクトは修正後の期日で完了します。

これは、ステークホルダー分析マトリクスとプロジェクト憲章が事前に整えておくものです。つまり、作業開始前にリスク許容度についての合意を作っておくことです。

ベストプラクティス

プロジェクト開始前からリスク計画を始める。 スコープ、スケジュール、コストのトリプルコンストレイントは計画段階で定まります。この段階で行うリスクに関する意思決定は、実行途中での変更よりもはるかに低コストです。

構造化されたテンプレートを使う。 リスク登録簿のフォーマットを統一しておけば、新しいメンバーが説明を受けなくてもドキュメントを理解できます。一貫性は過去との比較も可能にします。

リスクレビューを定例アジェンダにする。 週次プロジェクト会議の15分程度の時間があれば、登録簿を最新に保ち、リスクを可視化し続けるのに十分です。

残存リスクのオーナーも割り当てる。 軽減策を実施した後も、残った残存リスクには誰かの監視が必要です。

尺度をプロジェクトに合わせて調整する。 5万ドルの社内プロジェクトにおける「影響度高」のリスクと、5,000万ドルのインフラプログラムにおける「影響度高」のリスクは異なります。チーム全体でスコアを比較できるよう、尺度をリスクマネジメント計画の中で定義しておきましょう。

リスクをワークブレークダウンストラクチャーと紐づける。 リスクを特定のWBS要素（リスク登録簿参照）と関連づけることで、どのワークパッケージに最もリスクが集中しているかが把握しやすくなり、適切にリスクオーナーを割り当てられます。

よくある質問

リスクと課題（イシュー）の違いは何ですか

リスクとは、まだ発生していない将来の不確実な出来事です。**課題（イシュー）**とは、すでに発生していて能動的な解決を必要とする問題です。リスクマネジメントは将来の出来事を防ぐ、あるいは備えることを扱います。イシューマネジメントは現在の問題を解決することを扱います。どちらもRAIDログ（Risks、Assumptions、Issues、Dependenciesの頭文字）で追跡されます。

リスク登録簿とは何で、リスクマネジメントとどう関係しますか

リスク登録簿は、リスクマネジメントプロセスの主要な成果物であり、日々使う作業ドキュメントです。特定されたすべてのリスクについて、説明、カテゴリー、発生確率と影響度のスコア、優先度、割り当てられたオーナー、計画された対応、現在のステータスを記録します。リスクマネジメントプロセスをエンジンだとすれば、リスク登録簿は計器盤に相当します。

リスクはどのくらいの頻度でレビューすべきですか

最低限、リスクはプロジェクトのステータス会議のたびにレビューされるべきです。トリガーとなる出来事が近づいている優先度の高いリスクは、日次でのモニタリングが必要になることもあります。リスク登録簿全体は、各主要プロジェクトフェーズゲートやマイルストーンごとに完全な再評価を受けるべきです。

残存リスクとは何ですか

残存リスクとは、リスク対応が実施された後にも残るリスクのことです。どの対応もリスクを完全にゼロにすることはできません。軽減はリスクを減らし、回避はリスクを避け、転嫁はリスクを移動させます。対応後に残ったエクスポージャーが残存リスクです。これには専用のオーナーとモニタリングの仕組みが必要です。

すべてのプロジェクトに定量的リスク分析が必要ですか

必ずしもそうではありません。定性的分析（発生確率・影響度によるスコアリング)は、ほとんどの中小規模プロジェクトには十分です。モンテカルロシミュレーションのような定量的手法は、コストやスケジュールの結果について数値的な信頼区間が必要な大規模、複雑、あるいは影響の大きいプロジェクトや、スポンサーがコンティンジェンシー予備費についてデータに基づく根拠を求める場合に最も価値を発揮します。

プロジェクトリスクマネジメントは、キックオフ時に一度実施して片付けておく作業ではありません。最も価値を引き出しているチームは、これを継続的な対話として扱います。登録簿を最新に保ち、各ステータス会議でトリガーを見直し、プロジェクトの進展に合わせて対応計画を更新します。明確な計画から始め、リスクを広く洗い出し、一貫した基準でスコアリングし、実在するオーナーを割り当て、定期的にレビューする。それがこの実践の核心です。