【初心者必見】プロジェクトマネジメントのリスク管理とは？リスク管理の目的、手順と対策を解説

システム開発のプロジェクトマネージャーを任命されたけど、リスク管理画はどうすればいいの？
そもそもリスク管理ってなに？
リスク管理のやり方がわからない？

リスク管理の目的は、潜在的な問題を予測しておき、その問題が発生した時の影響範囲や対処方法をまとめておくことで、リスクの影響を最小限にすることです。

プロジェクトには必ず問題が発生します。問題が起こってから対処するのではなく、常にリスクが無いかを評価してプロジェクトを進めることが重要です。

今回は、プロジェクトにおけるリスク管理とは何か？リスク管理の目的、手順と対策をわかりやすく解説します。

前回のおさらい（プロジェクト計画の書き方）
プロジェクトにおけるリスク管理とは？
リスク管理の目的は？
リスク管理の手順
リスク管理として記録すべき項目
リスクを最小限にしてプロジェクトを円滑に運営しよう

前回のおさらい（プロジェクト計画の書き方）

これまで、プロジェクトを成功させるためにプロジェクト計画を立てること、そしてプロジェクト計画の最初は「プロジェクト概要」をまとめることを解説しました。

プロジェクト概要がまとまったら、次はプロジェクト計画を詳細に落とし込んでいきます。プロジェクト計画でやるべきことは、そのプロジェクト概要を含めて11項目あります。

これらはプロジェクトを円滑に運営するための重要なガイドと言えるものです。この11項目をプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。

今回は、リスク管理を解説します。

プロジェクトにおけるリスク管理とは？

リスクとは何でしょうか？　ウィキペディアで「リスク」を検索してみると

リスクとは、将来のいずれかの時において何か悪い事象が起こる可能性をいう。　
引用：ウィキペディア｜リスク

と記載されています。

言い換えると、リスクとは「潜在的なもの」であり、将来的に起こるかもしれない「不都合な出来事（阻害要因）」と言えます。

ここで注意したいことは、リスクは「欠陥」や「課題」とは異なるということです。

欠陥とは、プロジェクトの全工程で発見される機能要件やシステム仕様の不備や障害を指します。欠陥は「顕在化」した品質上の不具合であってリスクとは違います。
※欠陥について、こちらの記事に詳しくまとめています。

また、課題とは、プロジェクトの計画や目標、決定事項を阻害する問題のことを指します。課題も「顕在化」したものであるためリスクとは違います。
※課題について、こちらの記事に詳しくまとめています。

つまり、リスクとは「プロジェクトの将来に発生する可能性がある潜在的な阻害要因」ということです。

リスク管理の目的は？

プロジェクトには必ず問題が発生します。問題が起こってから対処したのではスケジュールが遅れる場合もあるでしょう。問題に気づいた時に「あの時になぜ気づかなかったのか？」「あれをしておけばよかった」など後悔した方はたくさんいるのではないでしょうか。

リスク管理の目的は、潜在的な問題を予測しておき、その問題が発生した時の影響範囲や対処方法をまとめておくことで、リスクの影響を最小限にすることです。

場合によっては社長やお客様のトップに報告して支援いただくことも必要なりますので、あらかじめ想定したリスクをステークホルダーで共有しておくことが重要になります。

また、問題が顕在化した時に慌てないためにも、ステークホルダーへのエスカレーションフローやルールもまとめておきましょう。

リスク管理の手順

リスクの洗い出し

まずは、リスクを洗い出します。リスクは主に次の4つに分類されます。

4つのリスク

組織に関するリスク
プロジェクトマネジメントに関するリスク
品質や技術・性能に関するリスク
外的要因に関するリスク

リスクが潜む箇所

リスクが潜む箇所とリスク要因例をまとめます。

リスクが潜む箇所	主なリスク要因例
体制	プロジェクト規模と体制がアンバランスで、予算・スケジュール・品質の問題が発生する
予算	予算通りにプロジェクトをコントロールできない
スケジュール	計画通りにシステム開発が進まず納期が遅れる
ステークホルダー	プロジェクトのキーマンが人事異動で交代する、退職する
開発メンバー	開発メンバーをアサインできない、開発メンバーが体調不要で休む
ビジネス環境	競合他社の動向によってプロジェクト計画が急遽変更になる
外部環境	社会情勢の変化や規制などによる外的要因でコントロールできない
システム環境	プロジェクトで採用したソフトウェアで技術的な問題が発生する

これ以外にも、リスクは不明確な箇所に隠れています。

お客様と合意した要件（機能）、スコープ（責任の範囲）、スケジュール、費用、品質に曖昧な箇所が無いか、合意できていない箇所は無いか確認しましよう。

特に、現行業務から変化がある部分は注意が必要です。

業務の流れの変化、ルールの変化、組織の変化、サーバーやネットワークの変化、データ管理の変化など、変化がある部分にリスクが潜んでいないか評価しましょう。

また、この作業は１度やれば終わりではありません。

工程が進むことでプロジェクトも変化していきます。洗い出したリスクの状況がどうなったか確認し、新たなリスクが無いか常に評価していくことが重要です。

リスクの優先度の決定と評価

プロジェクトの規模が異なれば管理方法（どれだけ管理に費用と時間をかけるか）も変わってきます。

リスク管理も同じで、リスクの高いプロジェクトを重点的に管理し、リスクの低いプロジェクトは簡易に管理すればいいわけです。

それを評価するため、洗い出したリスクから影響度と発生確率で優先度を決めます。優先度１が最も優先すべきものでリスクが一番高いものになります。

この優先度が高い（数値が小さい）ものがどれだけあるかでプロジェクトのリスクを評価していきます。 優先度1～2があるプロジェクトはリスクが高いプロジェクトとして、経営層や品質管理部門を入れて細心の注意を払って管理していく必要があります。

	発生確率
↓影響度	確率（高い）	確率（中間）	確率（低い）
影響（大）	優先1	優先2	優先3
影響（中）	優先2	優先3	優先4
影響（小）	優先3	優先4	優先5

４つのリスク対策

リスクを評価したら、それぞれの対策を決めていきます。

リスクの対策には、主に以下の４つがあります。

回避

回避とは、リスクの要因を排除することでリスクを回避することを指します。リスクの発生確率が高い、影響度が大きい場合に回避を検討する必要があります。

リスクに対して対策を講じる訳ではありません。あくまでも代替案を採用して回避することが目的となります。

例えば、課題の多い機能は一旦スコープから外してあと回しにする（二次開発に遅らせる）ことで回避できます。

低減（軽減）

低減（軽減）とは、リスクの発生確率を下げること、もしくは影響度を下げることを指します。リスクが無くなるのが一番ですが、発生確率が低くなるように、もしリスクが発生しても影響を小さくすることが目的です。

例えば、新技術を使ったプロジェクトよりも、枯れた技術（使いこなされた技術）を採用するほうがリスクを低減できます。

移転（転嫁）

移転（転嫁）とは、リスクが発生した場合に第三者にリスク対応を移すことを指します。これも回避と同様に、リスクそのものが無くなるわけではありません。リスク対応の責任と合わせて移転することが目的となり、主に財務的なリスクに有効です。

例えば、契約に瑕疵担保責任をつけることで品質リスクを開発会社へ移転できます。

容認

容認とは、リスクが発生しても対策は取らずに受け入れることを指します。リスクの発生確率が低い、影響度が小さい場合に容認を検討する必要があります。リスク対策の費用よりもリスクを容認する方が財務的にも影響が小さい場合に有効です。

リスクが高いプロジェクトには、あらかじめ予算を上乗せ（予備費）しておくことで「容認」を採用しやすくなりますが、予備費が無い場合は利益を削ることになります。

開発途中でお客様から仕様変更の要求があり無償で対応しないといけない場合、影響範囲が小さければ予備費で対応することが多いと思います。

これら４つの観点でリスクを検討して対策を決めます。
あわせて下記も明確にし、定期的に監視と結果を記録できるようにしましょう。

リスクが発生したと判断する基準（例えば、課題が多く発生した時など、判断基準を明記）
監視するサイクル（週次、月次、工程完了時など）
監視記録（監視結果の日時、リスク状況、対策した場合はその対策状況など）

リスク管理として記録すべき項目

リスク管理として記録すべき項目を下記にまとめます。これらを横に並べて一覧表の形式で管理すると便利です。

分類	記録項目	項目内容
リスク	記入日	リスクを記入した日
	記入者	リスクを記入した担当者
	リスク内容	リスクの内容
	リスク影響	リスクの影響（リスクが発生した場合の状態や結果）
	リスク判断基準	リスクが発生したと判断する基準
	影響度	発生した場合の影響度を「大」「中」「小」で記載
	発生確率	リスクが発生する確率を「高」「中」「低」で記載
	リスク優先度	発生確率と影響度から前述の表より優先度1～5を記載
リスク対策	予防対策	リスクを未然に防ぐための対策
	リスク対策	リスクの対策（前述の4つの観点でリスクを検討して対策を決定）
	監視サイクル	日時、週次、月次、工程完了時など
監視記録	リスク状況	発生したリスクの状況、対策後のリスクの状況
	監視日	監視を行った日
	監視者	監視をした担当者
	状況	「対策検討中」「監視中」「完了」などの状態
	完了日	リスクを回避して完了した日