リスクマネジメントが重要ということは理解していても、具体的にどのように管理していけば良いのを説明できる人は多くはありません。
そのため当記事では「リスクマネジメントとは」「リスクの種類」「リスクの特定方法と分析方法」「リスクの対処方法」についてわかりやすく解説します。
本記事の執筆者
PMBOKの勉強を進めていくと「10の知識エリア」が登場します。
この「10の知識エリア」のうち「リスクマネジメント」はプロジェクトで発生しうるリスクをどのように特定して対処するかに関する領域です。
私はプロジェクトを進める上でリスクマネジメントが最も大事であると考えています。
この記事を読めばリスクマネジメントを行うためのリスクの特定と分析方法、リスクの対処法がわかるようになりますので、ぜひ最後までお付き合いください。
※はじめにリスクマネジメントの概要を解説していますので、具体的な内容をすぐに知りたいというかは「リスクの種類」から目を通してください。
リスクマネジメントとは
はじめに
PMBOK Guideは大きく「フェーズ」「5つのプロセス群」「10の知識エリア」で構成されています。
「リスクマネジメント」とは「10の知識エリア」の1つであり、プロジェクトのリスクに対処するための領域です。
リスクマネジメント
プロジェクトにはリスクがつきものです。 ここでいうリスクとは、プロジェクトに影響を与えうる発生が不確実な事象のことです。 予め発生しうるリスクにはどのようなものがあり、リスクが顕在化した場合にはどのように対応するかを管理することをリスクマネジメントと言います。
リスクマネジメントのプロセス
「リスクマネジメント」と「5つのプロセス群」との関係性について解説します。
5つのプロセス群との対応
リスクマネジメントは「5つのプロセス群」のうち「計画プロセス群」「実行プロセス群」と「監視コントロールプロセス群」に関係があります。 
リスクマネジメントと各種プロセス群に含まれるプロセスの関係は下表の通りです。
| プロセス群 | プロセス |
| 計画プロセス群 | ①リスクマネジメントの計画プロセス |
| ②リスクの特定プロセス | |
| ③リスクの定性的分析プロセス | |
| ④リスクの定量的分析プロセス | |
| ⑤リスク対応の計画プロセス | |
| 実行プロセス群 | ⑥リスク対応策の実行プロセス |
| 監視コントロールプロセス群 | ⑦リスクの監視プロセス |
7つのプロセス
各種プロセスの役割について説明します。
①リスクマネジメントの計画プロセス
プロジェクト憲章をもとに、リスクマネジメントの活動方法を定義する。
②リスクの特定プロセス
過去の類似プロジェクトの情報や現在のプロジェクトの情報から、リスクを特定する。
③リスクの定性的分析プロセス
特定されたリスクに対する発生確率と影響度を評価して、リスクを高中低の3段階で等級分けする。
④リスクの定量的分析プロセス
納期や予算に対して、各リスクが与える具体的な影響を、日数や金額など詳細に数値化して、各リスクの優先順位を決定する。
⑤リスク対応の計画プロセス
各リスクに対する対処法を検討する。 同様に、リスク発生時の対処法を検討する。
⑥リスク対応策の実行プロセス
事前に計画したリスクの対処法に従って、リスクに対処する。
⑦リスクの監視プロセス
新しく発生したリスクに対処したり、不要なリスクの消込を行う。 また、リスクマネジメント自体の有効性を確認する。
リスクの種類
リスクには「全体リスク」と「個別リスク」があります。 また、全体リスクと個別リスクはそれぞれ「ネガティブリスク」と「ポジティブ」にわけることができます。 
全体リスクと個別リスク
全体リスクとは、政治や経済、社会情勢および技術の進歩などプロジェクトでは管理できないものから発生する事象を指します。
政治情勢の悪化などでプロジェクトの収益確保が著しく難しくなりプロジェクトを中断せざるを得ない状況に陥る場合もあります。
個別リスクとは、スケジュール遅延やメンバーの突然の離任などプロジェクトで管理できる事象を指します。
ポジティブリスク
皆さんが「リスク」と聞いて最初に思い浮かべるのはプロジェクトに悪い影響を与える事象のことでしょう。
しかし、PMBOK Guideではプロジェクトの計画から「良い方向」に影響を与えるものもリスクとして扱い、「ポジティブリスク」と呼んでいます。
※「好機のリスク」や「投機的リスク」とも呼ばれる。
行動を起こすことでプロジェクトの資源や時間を消費する可能性がありますが、それにより得られるメリットの方が大きい場合は、そのリスクを選択します。
- 特定のフェーズで良い成果を収めたチームや個人を表彰し、報酬を与えることにより、さらにパフォーマンスが向上する。
ネガティブリスク
計画から「悪い方向」に影響を与える事象を「ネガティブリスク」と呼びます。
※純粋にマイナス面しかないため「純粋リスク」や「脅威のリスク」とも呼ばれる。
- 顧客が仕様を固めない
- メンバーのスキルが低く設計書作成スケジュールが遅延する
- メンバーが突然離任する
リスク対応方針を計画する
リスクマネジメント計画書
プロジェクト憲章やスコープや資源、コストなどの計画書に基づいて、リスクにどのように対処するかをリスクマネジメント計画書としてまとめます。
リスクマネジメント計画書にはリスクの特定方法、分析方法、対応策の立て方、対応策の実行方法、リスクの監視方法を定義します。 
リスクを特定する
リスク登録簿
リスクマネジメント計画書をもとにして、過去の類似プロジェクトや現在のプロジェクト情報からリスクを特定します。
特定したリスクを一覧としてまとめたものをリスク登録簿と呼びます。
リスクの特定方法
リスクを特定するための２つの方法を紹介します。
①データ収集
顧客へのヒアリングやプロジェクトメンバーによるブレーンストーミングによって意見を集め、その中からリスクを特定する。
②データ分析
前提条件および制約条件の分析やSWOT分析を利用してリスクを特定する。
- Strength（強み）
- Weakness（弱み）
- Opportunity（機会）
- Threat（脅威）
リスク登録簿の作成
リスクと特定したらリスク登録簿として一覧表にまとめます。 
この後のリスク分析やリスク対応策の策定により、リスク登録簿を完成させます。
リスクを分析する
リスクを特定したらそのリスクの発生確率や影響度を分析します。
リスクの定性的分析
発生確率・影響度マトリクスを作成し、リスクを「高」「中」「低」の3段階で等級付けする方法。
各リスクの発生確率を5段階、影響度を5段階のマトリクスで表し、それぞれの数値を掛け合わせてリスクの大きさを示します。
この掛け算の数値をリスクスコアと言い、リスクスコアに対して閾値を設け等級を決定します。
- 高：リスクスコア >= 12
- 中：12 > リスクスコア >=5
- 小：5 > リスクスコア
リスク発生時の対応方法を決める
リスクを特定したら、次はそのリスクが発生した際の対応方法を予め決めておきます。
個別リスク：脅威の戦略
プロジェクトにマイナスの影響を与える要因を「脅威」と言います。
脅威の戦略として、エスカレーション、回避、転嫁、軽減、受容の5つがあります。
| エスカレーション | 脅威の影響が自身の権限を越える場合に、上長にエスカレーションし支持を仰ぐ方法 |
|---|---|
| 回避 | 契約を変更するなど特定したリスクを完全になくす方法 |
| 転嫁 | 保険や契約など第三者に責任を転嫁する方法 |
| 軽減 | 通常よりも手厚いテストを実施するなど、特定したリスクの発生確率や影響度を減少させる方法 |
| 受容 | リスクを受け入れる方法
|
個別リスク：好機の戦略
プロジェクトにプラスの影響を与える要因を「好機」と言います。
好機の戦略として、エスカレーション、活用、共有、強化、受容の5つがあります。
| エスカレーション | 好機の影響が自身の権限を越える場合に、上長にエスカレーションし支持を仰ぐ方法 |
|---|---|
| 活用 | プロジェクト計画書の一部を変更するなど、特定したリスクが確実に発生するようにする方法 |
| 共有 | 好機の全部もしくは一部を第三者に移転する方法 |
| 強化 | 成果を上げたメンバーを表彰しモチベーションを高めるなど、特定したリスクの発生確率や影響度を助長する方法 |
| 受容 | リスクを受け入れる方法
|
- 活用：脅威の戦略における回避策の反対の対応法
- 強化：脅威の戦略における軽減策の反対の対応法
全体リスクへの対応
全体リスクとは政治情勢、経済情勢、社会情勢、技術の進歩によりプロジェクトに影響がでるリスクでした。
この全体リスクへの対応方法として、エスカレーション、回避、活用、転嫁と共有、軽減と強化、受容の6つがあります。
| エスカレーション | 発生したリスクが自身の権限を越える場合に、上長にエスカレーションし支持を仰ぐ方法 |
|---|---|
| 回避 | 全体リスク(脅威)がリスク許容度を超える場合に、スコープの高リスク要素をプロジェクトから除去するなどの回避策をとる方法 場合によってはプロジェクトの中止を選択するときもある |
| 活用 | 全体リスク(好機)が著しくプラスである場合に、高利益の作業をプロジェクトに取り込むなど活用策をとる方法 |
| 転嫁と共有 | リスクが自分たちの手に負えない場合に第三者に入ってもらう方法
|
| 軽減と強化 | スコープ変更や優先度変更など、脅威の場合は軽減、好機の場合は強化の戦略をとる方法 |
| 受容 | リスクを受け入れる方法
|
念には念をコンテンジェンシー計画
コンテンジェンシー計画
コンテンジェンシー計画とは、リスクが発生してその対応策が不十分な場合に実施する対応の計画です。
「もし〇〇が発生したらXXXする。」のように何かが起きた場合に用意しておく計画で、「〇〇」のことをトリガーと言います。
リスク登録簿への加筆
軽減策を実施した後にも残ってしまうリスクのことを残存リスクと言います。
また、回避や活用策を実施した結果に対してさらに発生するリスクが2次リスクです。
これらの内容をリスク登録簿へ加筆しておきます。 
リスク発生時の対処
リスクが顕在化した際には、リスク登録簿に従って対応します。
脅威はプロジェクトへの影響を最小に、好機はプロジェクトへの影響が最大になるように管理します。
ほとんどのプロジェクトにおいて、ここで重要な問題が発生します。
それは、リスクが顕在化したにも関わらず「リスク登録簿」が活用されないという問題です。
リスク内容をアップデート
プロジェクトが開始されフェーズが進むにつれて新しいリスクを特定できる場合があります。
これらのリスクについても対応策をしっかりと検討するようにしましょう。
監査
自社組織内の第三者により、リスクマネジメント活動の有効性を確認します。
問題がある場合は監査機関はプロジェクトに対して助言します。
会議
リスクレビューを主な目的とし、新たなリスクの有無や既存リスクの発生確率/影響度に変化がないか、除外すべきリスクはないかを確認します。
リスクに変更があればリスク登録簿を修正します。
【現場のリアル】SIer PMが管理するリスクの具体例
PMBOKではリスクの特定・分析・対応という理論的なフレームワークが示されていますが、現場では「理論通りにいかない」状況が頻繁に起きます。ここでは、SIerのシステム開発現場で実際に発生しやすいリスクを3つ、現場の空気感とともに紹介します。
※リスク登録簿への登録具体例ではなく、PMが見るべきリスク視点での紹介です。
① 製造遅延の早期把握失敗によるスケジュール崩壊
現場ではこんなことが起きています
製造フェーズで担当者が「○○機能は80%完成しています」と報告し続けるものの、実態は設計書の読み込みすら追いついておらず、実装は30%程度しか進んでいない——という状況です。「もう少しで終わる」とPMが信じたまま、フェーズ終了1週間前になって初めて「実は全然進んでいなかった」という事実が発覚するケースが後を絶ちません。「80%完成」が2週間続くプロジェクトは、遅延が確定していると読み替えるべきです。
顕在化したときの影響
- 試験工程の開始が大幅に遅延し、後続のすべての工程が圧迫される
- スケジュール回復のためにレビューやテストが省略され、品質が低下する
- 無理な残業強制によりメンバーのモチベーションが低下し、離脱リスクが高まる
回避するために
進捗をパーセンテージで報告させるのではなく、「完了した機能数 / 全体機能数」「残作業の実工数見積もり」など、客観的に検証できる指標で管理することが重要です。完成した成果物（動くコード・単体テスト結果）を定期的にPMが直接確認する習慣を持つことが最大の対策です。「報告を信じる」と「確認する」は別のことです。
② スコープクリープ(拡大)によるコスト・スケジュール超過
現場ではこんなことが起きています
「この仕様って含まれていますよね？」
顧客キーマンのこの一言が起点になることが多いです。メンバーが顧客の要望を口頭で合意し、善意で追加機能を実装し始め、一件一件は小さな変更でも、積み重なると当初のスコープを大きく超えていきます。変更管理票に記録のない実装が試験工程で初めて発覚し、「誰がいつ指示したのか」という議論に発展する。これはスコープクリープが顕在化した典型的な場面です。善意の追加実装が、プロジェクトを静かに壊します。
顕在化したときの影響
- 見えない追加作業により工数が増大し、コストとスケジュールを超過する
- 品質が担保されていない機能が本番環境に混入し、障害リスクが高まる
- 「言った・言わない」のトラブルに発展し、顧客との信頼関係が損なわれる
回避するために
「仕様変更は必ず変更管理票に記録し、PMが承認した場合のみ対応する」というルールをプロジェクト開始時に顧客・メンバー双方と明示的に合意しておくことが大前提です。特に注意が必要なのは、メンバーが顧客から直接「ちょっとこれも」と頼まれるケースです。追加要求は必ずPMに集約する文化をチームに根付かせることが、スコープ管理の要となります。
③ リスク管理形骸化による問題発生後の対応遅れ
現場ではこんなことが起きています
プロジェクト開始時にリスク登録簿を丁寧に作成したものの、その後一度も更新されず、発生確率と影響度が半年前のまま放置されている。これは「リスク管理をやっているつもりのプロジェクト」に非常によくある状態です。週次会議でリスクが議題に上がることもなく、「顕在化したら対応する」というスタンスが暗黙の了解になっていきます。PMBOKを理解しているPMでも、プロジェクトが忙しくなると陥りがちな罠です。
顕在化したときの影響
- 事前に対策を打てたはずのリスクが「想定外」として顕在化し、対応コストが跳ね上がる
- 「前から分かっていたのに何も手を打たなかった」という議論が発生し、チームの信頼関係が損なわれる
- 初期消火が遅れ、プロジェクト全体のコントロールを失うリスクがある
回避するために
リスク登録簿は作るだけでなく、週次定例でリスクの消込・更新を必ずアジェンダに加えることが重要です。「新たに顕在化したリスクはないか」「既存リスクの発生確率・影響度に変化はないか」「除外できるリスクはないか」を定期的に問い続けることで、リスク管理を生きたプロセスとして機能させましょう。リスク登録簿が最後に更新された日付を見るだけで、そのプロジェクトのリスク管理の実態が分かります。
現場で見てきたリスク観点、まとめています
私がPMとしてシステム開発の現場で見てきたリスクを一覧にまとめています。要件定義から移行・切替、管理共通まで、フェーズ別にトータル50項目のリスク観点と現場の具体的な空気感を収録しています。リスク登録簿のたたき台として、あるいはプロジェクト開始前のチェックリストとして、ぜひご活用ください。
まとめ
今回は、「10の知識エリア」の一つであるリスクマネジメントについて解説しました。
◆リスクマネジメントとは「10の知識エリア」の1つであり、プロジェクトのリスクに対処するための領域である。
◆リスクは大きく「全体リスク」と「個別リスク」に分けられ、それぞれに「ポジティブリスク」と「ネガティブリスク」が存在する。
◆リスクにどのように対応するかを記したリスクマネジメント計画書を作成しよう。 ◆リスクの特定方法としてデータ収集とデータ分析がある。
◆リスクを分析する際には発生確率・影響度マトリクスを用いる。
◆脅威の戦略はエスカレーション、回避、転嫁、軽減、受容の5つ。
◆好機の戦略はエスカレーション、活用、共有、強化、受容の5つ。
◆全体リスクへの対応方法はエスカレーション、回避、活用、転嫁と共有、軽減と強化、受容の6つ。
◆コンテンジェンシー計画を立て、プロジェクト中盤でも新たなリスクの特定と対応策を検討していくことが大事。
では、今回はここまで。
最後まで読んでいただきありがとうございました。
