リスクマネジメントとは
リスクマネジメントとは、PMBOKで解説されているプロジェクトマネジメントプロセスの一つです。リスクマネジメントとは、プロジェクトに関するリスク・マネジメントの計画、特定、分析、対応の計画、対応策の実行、およびリスクの監視を遂行するプロセスからなります。プロジェクトとは多数の要素が複雑に絡み合っているため、遂行上様々な困難や問題になりうる事象が日々発生します。リスクマネジメントの目的は、プロジェクト成功の可能性を最大限に高めるために、プロジェクトのリスクとなる不確実性要素を計画的に管理することです。
リスクとは
リスクとは、日本語で言うと危険性もしくは脅威です。プロジェクトマネジメントにおいては、リスクとはプロジェクトを遂行する上で将来発生しうる危険性・不確実性のことを言います。リスクマネジメントでは、プロジェクトに対して悪い影響を及ぼす事象だけではなく、良い影響を及ぼす事象も管理し、プロジェクトにとって悪い影響を及ぼす事象の発生確率を最小化し、プロジェクトにとって良い影響を及ぼす事象の発生確率を最大化できるようにリスク項目を管理していきます。
リスクマネジメントプロセス
リスクマネジメントプロセスは以下のステップに分けられます。
- リスクマネジメント計画
- リスクの特定
- リスクの定性的分析
- リスクの定量的分析
- リスクの対応策計画
- リスクの対応策実行
一般的に、上記のプロセスを一括りにしてリスクマネジメントと呼ばれます。各組織でどのようにリスクマネジメントプロセスを行っていくかという詳細な手順は会社や組織ごとに調整して自分に合った手法を用いるべきですが、PMBOKに基づき、以下に一般的な手順を紹介します。
1. リスクマネジメントの計画
まず最初に、プロジェクトを通してどのようにリスクマネジメントを行なっていくかを決めます。具体的には以下に述べるリスクの特定や分析、対応策の決定と監視をどのように行うかを決める必要があります。決定した計画はリスクマネジメント計画書に記載し、チームに共有します。プロジェクトを通して変更があれば適宜リスクマネジメント計画書を更新します。同定されたリスクはリスクマネジメント計画書に基づき一般的に表形式でリスク登録簿としてまとめ、適宜更新していきます。
2. リスクの特定
プロジェクトのリスクとなりうる事象を特定して書き出し、テーブル形式でエクセル等にリスト化します。例えば、建物の建設プロジェクトの場合、以下のような項目をリスクとして書き出します。
- 自治体からの工事着工承認が遅れる
- 資材が見積もりよりも高騰する
- 下請け業者が十分な工員を確保できない
- 客先から設計後半に変更要請が出る
など。リスクの影響の大きさや発生確率分析は次以降のプロセスで行うため、ひとまずリスクとして考えられる事象をここでは書き出しておきます。プロジェクトの全体に関わるリスクだけでなく、個別の作業項目に関するリスクであっても書き出します。リスクの書き出しに際し、個人で書き出していくのも手ですが、皆で集まってのブレインストーミングや、その分野の専門家へのインタビューなどの手法を用いることも有効です。
3. リスクの定性的分析 (Qualitative Analysis)
各リスクの発生確率、影響の大きさを3から5段階程度でランクづけし、リスクに優先順位をつけます。定性的分析のため、ある程度主観的にランク付けしていけば十分です。ただし、リスクを分析する個人によってあまりにランク付けに違いがでてもまく分析ができないため、リスクを分析する個人はある程度共通の認識を持って定性的分析を行う必要があります。定性的分析の前には事前に打ち合わせ等でランク付けのある程度の方向性や程度については擦り合わせておくほうがより効果的な分析ができます。
代表的な評価項目はリスクの発生確率と影響の大きさですが、リスクを定性的に分析するにあたって、プロジェクトの特性に合わせた独自の評価項目を設定することもできるため、発生確率と影響度だけでなく、それぞれのプロジェクトに見合った評価指標を補助的に設定してよりリスクの管理精度を上げることもできます。
4. リスクの定量的分析 (Quantitative Analysis)
基本的にはリスクの分析は定性的分析程度で十分ですが、場合によっては各リスクの影響や発生確率をより詳細に定量分析することもあります。分析の手法としては過去の事象から事象発生の確率分布(三角分布、正規分布、ベータ分布など)を定義し、モンテカルロシミュレーションを反復して行い、結果をヒストグラムにまとめてリスクを定量的に分析する方法がありますが、シミュレーションのための詳細なインプットデータが必要で手間もかかるため、プロジェクトリスクに対して定性的分析まで行うことはあまりありません。基本的には定性的に分析してリスク自体をランクづけすることで十分にリスクマネジメントの目的は果たせることが多いです。
5. リスク対応策計画
各リスクに対してそのリスクを最小化(最大化)するためにどういったアクションを取れば良いかを決定します。リスク対応策の考え方としては以下があります。
エスカレーション
リスクが与える影響が甚大である場合や、プロジェクトを飛び越えて会社そのもののポートフォリオやプログラムなどに影響を与える可能性があり、プロジェクトマネージャーとしてリスクの対応策を一存で決定できない場合は組織の上位者にリスクを報告(エスカレーション)します。上位者にリスクをエスカレーションした後は、対応策は上位者ににて決めてもらうため、それ以上の対応は不要です。
回避
特にリスクの発生確率と影響が大きい場合は、リスク自体が発生しないような対応策を練り、リスク自体を回避すると言う考え方です。
転嫁
リスクが発現した場合、リスクによる影響を第三者に肩代わりしてもらうような対応策を練ることです。例えば、保険に加入しておくことは転嫁の考え方を適用したリスク対応策になります。
軽減
リスクが発現した際に、影響が小さくなるような対応策を練ることです。例えば、本製作に移る前にプロトタイプを作成したり、システムを製作する際にある程度の設計変更に耐えられるように余裕を持った設計にしておくことは軽減アプローチの一例です。
受容
リスク自体の発生を受け入れてしまう、というのも一つの対応策なります。リスク対応のためのコストがあまりに大きく非現実的な場合は、リスク自体の発生を受け入れ、コンティンジェンシー(予備費)を使って対応すると言った考え方もリスクマネジメントです。
活用
リスクの発生を好機ととらえ、積極的にリスクの発現を自分たちが有利になるように活用する対応策です。受容と似ていますが、リスクの発現を積極的にプラスな方向で活用すると言う点が異なります。例えば、リスクが発現することによって発注元への追加費用や時間を請求する理由にする、人員増強の理由にする、などがあります。
強化
リスクがプラスの影響のある好機である場合、リスクがより発現しやすくなるように仕向ける対応策です。リスクを活用したい場合に有効な手法です。
共有
リスクを複数のパーティで引き受けるようにする対応策です。例えば複数人でジョイントベンチャーや特別目的会社を設立し、リスクが発現した際にその影響や利益を共有できるようにします。利益も共有されるため、こう言った枠組みでリスクを共有するする場合はパートナーの選定は今後関係性等を鑑み、慎重に行う必要があります。
6. リスク対応策の実行
5のプロセスを経て決定されたリスク対応策を実行していきます。基本的には実行すべきアクションがある人が粛々と対応策を実行していくことになります。リスク対応策を確実に実行するためには、だれがどういったアクションをいつまでに取るかをリスク登録簿上に明確にしておく必要があります。
7. リスクの監視
リスク対応策が実行されたら、次はリスクの対応策が確実に実行されているか、新たなリスクはないか、リスク対応策の更新が必要ではないか等を日々監視します。例えば、週次ミーティング等でこういった項目を定期的に確認するなどの手法が有効です。
リスクマネジメントでよくある失敗は、リスクを列挙ししっかりと対策まで練ったものの、誰も適切なアクションとらずに結局リスクの発現を許してしまうことです。リスク登録簿はプロジェクト開始直後から作成するため、数年にわたるプロジェクトの場合、プロジェクト中盤や後半のリスクの管理が疎かになりがちです。リスクの監視プロセスを確実に実行し、計画された対策が確実にとられているかを監視していくことは非常に重要ですので、定期的なミーティング等で確実に監視しましょう。
週次ミーティングやリスクレビューミーティング等では、主に以下のような項目を確認してリスクを監視します。
- リスク対応策が確実に実行されているか
- 現在のリスク対応策が有効か
- 新たなリスクはないか
プロジェクトを取り巻く状況はダイナミックに変化していくため、リスクを定期的に見直すことでプロジェクトに想定外の影響を及ぼすことを避けることが大切です。プロジェクトが多数のフェーズに分かれている場合（見積もりフェーズ、設計フェーズ、調達フェーズ、施工フェーズなど）は例えば各フェーズごとにリスクを大規模に見直すといったことも有効です。
コンティンジェンシー(予備費)戦略
コンティンジェンシーとは、プロジェクトの遂行中に不測の事態が起こった時に限って使用できる予備費です。プロジェクトの遂行中には、どんなに綿密に計画を練ったとしてもプロジェクトに悪影響を与えるような計画外の事件が必ず起こります。こういった、”よくわからないけど必ず発生するであろう計画外の事象（英語でいうと、known unknown）”に関する対策費用として確保しておくのがコンティンジェンシーリザーブ（予備費）です。
コンティンジェンシーリザーブをどういった事象の場合に使用するかは事前によく計画しておき、必要な金額は想定する計画外の事象に合わせて確保しておく必要があります。
コンティンジェンシーリザーブの一部として、マネジメントリザーブと呼ばれるものが別で引き当てられる場合があります。これは、通常のコンティンジェンシーリザーブが想定する事象以外の、”発生するとは思ってもいなかった計画外の事象（英語でいうと、unknown unknown）”に関しての対策費用となります。プロジェクトや組織のポリシーにもよりますが、プロジェクト総コストの数パーセントを一律費用として引き当てておく場合があり、組織の上位者の決定でしか使用することができない予備費となります。
ネット見積もり予算と一般コンティンジェンシーリザーブまでを含んだものをコストベースラインとして扱い、プロジェクトの遂行管理のベースとなります。マネジメントリザーブまでを含んだものがプロジェクトコストバジェット(予算)となり、プロジェクトの終了までに使える全予算ということになります。何が通常のコンティンジェンシーリザーブで何がマネジメントリザーブに対応する事象かの線引きはあいまいな部分もありますが、例えば以下のように分類できます。
コンティンジェンシーリザーブに関わる事象例
- ベンダーによる製作が著しく遅れ、プロジェクトへの影響を最小化するためにベンダーに追加資金を投入する必要がある
- 地盤改良工事中に多量の埋設物が出てきて処理が必要になる
- プロジェクトが納期通りに終わらないことを見越して遅延損害金分を一部確保しておく
マネジメントリザーブに関わる事象の例
- 想定していた発注先とバックアップとして挙げていた発注先が2社とも倒産したため、新たな発注先に発注するための追加コストが発生した。
- 突然の規制により、予定していた海上輸送ルートが使用できなくなったため空輸コストが追加で発生した
マネジメントリザーブは原則見積もり時に想定できていなかった不測の事態が発生した場合に使用しますが、そういった事象は非常に大きなインパクトをプロジェクトに及ぼすことが多いです。不可抗力条項を契約で別途定めて戦争や天変地異、国の規制変更等の巨大リスクは発注元に持ってもらうような工夫も必要になります。
結論
リスクマネジメントの一般的な流れとコンティンジェンシーリザーブについて解説しました。
リスクマネジメントはプロジェクト遂行を成功裏に行うために欠かせないプロセスです。特に複雑で巨大なプロジェクトや定額請負のプロジェクトにおいては、確実にリスクマネジメントプロセスを実行することが採算の確保に直結します。各々のプロジェクトにあったリスクマネジメント手法を取り入れ、プロジェクトを成功に導きましょう。
