この記事ではPMBOKの知識エリアの一つである「リスクマネジメント」について紹介します。
どの様なプロジェクトでもリスクが潜んでいます。そして、それらのリスクを全て取り除くのは難しいもの。しかし、リスクを特定して分析を行い、予防策を実行したり、もしくはリスクが顕在化した際の対策を事前に考えてから実行する事で、プロジェクトへのダメージを最低限に抑える事が可能です。
プロジェクトの計画段階では特に重要視されるエリアでもありますので、しっかりとツボを押さえておきたい所。ここでリスクマネジメントに関する知識や活用方法を覚えて、今後のマネジメントの中で活かすようにしましょう。
コンテンツ
リスクマネジメントとは
リスクマネジメントとはプロジェクトに含まれる様々なリスクを分析し、必要な対応・処理を行っていく活動の事を言います。
リスクを語る上で重要なのはネガティブなリスクだけではなくて、ポジティブなリスクも検討する必要があるという事です。この点はこの後詳しく説明します。
また、問題が起きてから原因分析を開始する事はリスク管理とは言いません。そもそもリスクが起きてしまってからの対応ではプロジェクト目標に大打撃を与えてしまうものも少なくありません。リスク分析において、大きなリスクが含まれると判断した場合には、事前に対応策を立てて適切な対処をする必要があります。
プロジェクト立ち上げの時点では特に重要視される部分とも言えます。
リスクマネジメントの計画
実施プロセス：計画プロセス
アウトプット：リスクマネジメントの計画書
どの様にリスクマネジメントを行うかを定義して計画化します。
リスク分析の方法や対応方法などは、優秀なツールや考え方を参考にしても良いです。ただ、プロジェクトの特徴などを踏まえて、プロジェクト固有のリスクマネジメント計画が必要となる事も少なくありません。
基本的には、リスクの定義方法、分析方法、監視方法、対処方法などをここで計画する事になります。
リスク特定
実施プロセス：計画プロセス
アウトプット：リスク登録簿（リスク管理表）
プロジェクトとってのリスクをリスク登録簿へ記載します。この時点では細かい分析は行わず、リスクの洗い出しを行うだけになります。
ただ、各リスクがプロジェクト全体へのリスクなのか、個別のリスクなのかは分類するのが一般的です。
リスクの定性的分析
実施プロセス：計画プロセス
アウトプット：リスク登録簿、リスクの発生確率・影響度マトリクス
個別にリスクに対して、発生確率と影響度を分析します。
ここがプロジェクトマネージャ試験等でもよく問われるポイントで、発生確率・影響度のマトリクスを作成してマイナスリスク（脅威）、プラスリスク（好機）をイメージできる様にする事が多いです。
ちなみに、このプラスのリスクは意図せずにプロジェクトが良い方向へと進んでいくというニュアンスがあります。この様な状況になれば良いのですが、これはプロジェクトマネージャーや開発側の努力だけで何とかなる訳ではありません。ですから、プラスリスクはあくまでリスクと考え、このリスクが発生した際にどの様な対応を行うべきかは事前に検討しておく必要があります。
発生確率
冷静にプロジェクトを観察してリスクの発生原因とその確率を定義します。確率というのは経験がなければ算出する事は難しいので、先輩のプロマネの方や、社内標準の考え方に準拠するのが一般的です（それがベストという訳ではありません）。
影響度
リスク発生時にプロジェクトにどの様な影響を与えるのかを分析します。
もし対応が発生したら、必要な要員や作業量がどの位になるのかをしっかりとイメージできていなければなりません。
分析完了後
分析を行ったら各リスクへの優先順位付けを行います。
リスクの定量的分析
実施プロセス：計画プロセス
アウトプット：リスク登録簿
定性的分析後には定量的な分析を行います。
このプロセスは必要な場合のみ実施を行います。定性的分析からこの後対応計画を作成しても全然OKですが、今後の対応に向けて定量化が必要な場合は定量的分析をする事になります。
特定をしたリスクがプロジェクトに与える影響を数値化する等して、定量的に評価を行うための分析となります。
リスク対応の計画
実施プロセス：計画プロセス
分析した内容への対応計画を立てます。
この対応計画を作成する際の対応方法には「回避、軽減、転嫁、受容」等があり、プロジェクトの中でもよく使われるキーワードになります。
※PMPやプロジェクトマネージャ試験においてもこれらのキーワードはよく問われます。
これらのキーワードを基に、具体的な対応方法を検討して計画化します。リスクマネジメントにおいても非常に重要なプロセスと言えます。
また、これらの対応計画は必ずステークホルダー等と合意をする必要があります。
リスク対応策の実行
実施プロセス：実行プロセス
策定・合意した対応計画に基づいて、リスク対応策を実行します。
もしも、対応内容の変更が必要と判断した場合は、再度計画を行ってステークホルダー等に合意を得た上で実行する必要があります。
また、事前に把握できていなかったリスクが発見され、そのリスクが顕在化した場合には、即座に対応策を考え、同じくステークホルダーの合意を得て対応を行う必要があります。
リスクそのものを事前に洗い出せていないというのは、プロジェクト運営上の大きな問題となっていますが、リスクが顕在化しない様に予防措置を取ったにも関わらず、リスクが顕在化してしまうケースというもあります。これは事後対策、もしくはコンティンジェンシプラン等とも言われます。
リスクの監視
実施プロセス：監視・コントロールプロセス
事前にリスク登録簿に挙げていたリスクが顕在化していないかどうか、さらに新たなリスクが発生していないかどうかを監視します。リスクが顕在化していると判断した場合は計画に沿って対策を行います。
また、既に対応済みのリスクについても、その後の経過を管理するプロセスになります。
事後対策（コンティンジェンシプラン）が発動してしまうと、コスト的にも大きな打撃になってしまい、プロジェクト目標の達成にも大きな影響が出てしまいますので、リスクが発生していないか、顕在化していないかどうかについては常にチェックをしておく必要があります。
リスクマネジメントの活用
リスクマネジメントの活用方法については、ほぼ上述した通りとなりますが、ここでは具体的な活用事例等についてご紹介します。
開発側に起因するリスク
開発側（つなりプロジェクトマネージャーがいる側）に起因するよくあるリスクについては、有識者が少ない、新人がいる、開発環境の問題等々があります。
特に開発対象のシステムや使用するツールに関する知識不足により、スケジュールに遅延が発生してしまう、というのは特によくあるケースです。このリスクが顕在化してスケジュール遅延となってしまうと、最終的な納期に間に合わなかったり、増員によりコストが大きく増えるといった結果になってしまう事もしばしばです。
基本的に開発側に起因するリスクが顕在化してしまった場合は、開発側で責任を取るという結果になりますので、リスクが発生しない様に事前に予防策を十分に検討しておく必要があります。
リスクマネジメントをしっかりと行い、不要なリスクを顕在化させない様にしましょう。そして万が一リスクが顕在化した場合には、落ち着いて適切な対応が取れる様にしましょう。
利用側に起因するリスク
利用側に起因するリスクとしては、ステークホルダーからの要望による仕様の途中変更といった事例があります。これはシステム開発を経験された方であれば、よくある話だと思うかもしれません。この場合、基本的には変更管理対応として、別費用が発生します。
別費用の発生が見込まれる場合は、利用側に別費用が発生する旨を明確に伝えなければなりません。場合によっては交渉事になるため、気を遣う仕事にもなるかもしれませんが、ここは踏ん張りどころです。
ただ、できれば事後対応とならない様に、利用者側からの要望による仕様変更は全て変更管理として別タスク・別費用となる旨を、リスク登録簿に登録しておき、事前にプロジェクトに関わっているメンバーにも周知をしておきましょう。そうする事で、不要な仕様変更を減らす予防措置にもなり得ます。
利用側に起因するリスクについても、しっかりとコントロールを行い、プロジェクトの運営に影響を与えない様にしましょう。
まとめ
今回はPMBOKのリスクマネジメントについて解説をしました。
リスクマネジメントの方法は、本文中でも触れましたが各企業で予め決められている事が多いです。そのため、自社で推奨するリスクマネジメントの方法があれば、その方法に則ってまずは管理を行いましょう。
その上で今回紹介をした、
- リスクマネジメントの計画
- リスクの特定
- リスクの定性的分析
- リスクの定量的分析
- リスク対応策の計画
- リスク対応策の実行
- リスクの監視
というプロセスを適切に踏んでいるのかをしっかりと確認をしながらマネジメントを行う様にしましょう。
特に計画段階で、想定されるリスクへの対策を立てているかどうか？は、プロジェクトの結果に大きな影響を及ぼします。
人間は、今目の前で行っている事には全力で対応しますが、想定の中の事には無頓着になりがちです。だからこそ、効果的なプロセスを参考にして、最適なマネジメントを目指したいものです。
