トピックス

PMBOK®ガイド 第5版紹介シリーズ 第9回  リスク・マネジメント

PMBOK®ガイド  第5版 紹介シリーズ
第9回 リスク・マネジメント

PMBOK® 委員会
川俣 賢一 

はじめに

 最近、「自己責任」、「オウンリスク」という言葉を頻繁に聞くようになってきました。プロジェクトマネジメントの世界におけるリスクとはどういうことでしょうか?また、それをどのようにマネジメントするべきなのでしょうか?
 今回は、プロジェクトを成功へ導く重要な知識エリアのひとつである「リスク・マネジメント」について、わかりやすく解説します。

 プロジェクトにおけるリスクとは何でしょうか?
 PMBOK®ガイド には、「リスクとは、それが発生すれば少なくともスコープ、スケジュール、コスト、品質といったプロジェクト目標に影響を与える不確実な事象・状態」とあります。
 必ず発生するもの、すでに発生してしまったものはリスクとはいいません。これらは、問題や課題として対応していきます。

 では、発生するかどうかわからないのだから、発生したらそのときに考えればいいのでしょうか? リスクというものを何にも考えていない状態の時にリスクが顕在化したらどのように対応するのでしょうか?
 有識者を集め、影響を分析し対応策を検討、対応策を実行するために予算を計上し承認を得て・・、とやっているうちに状況は刻々と変わり、プロジェクト目標への影響が大きくなり、もしかしたら手遅れになるかも知れません。
 手遅れにならないようにするために、リスクについて、いつ検討を行えばいいのでしょうか?

 その答えは、「プロジェクトの計画段階からリスクが発生しなくなるまで」、すなわちプロジェクトが終わるまでです。

 フロー図.jpg
  • リスクマネジメント計画
     スコープ・ベースラインから成果物を生み出すための活動に落とし込みます
  • リスク特定
     リスクを洗い出し「リスク登録簿」に記載します
  • 定性的リスク分析
     発生確率と影響より、リスク管理の優先度を決めます
  • 定量的リスク分析
     リスク顕在化時の影響を金額など数値化します
  • リスク対応計画
     それぞれのリスクに対して、「回避」「転嫁」「軽減」「受容」の戦略で対応策を立てます
  • リスクコントロール
     リスク事象が発生していないか、新たなリスクが発生していないか監視し、変化があった場合は対応策を検討します

PMとしてやるべきこと

 あなたは、新システム開発プロジェクトで要件定義フェーズが終了したあとの、設計、開発・実装、テスト・フェーズのプランニングから担当することになりました。
 要件定義フェーズはコンサルティング会社が行っており、一見、要件定義書は完成しているようです。ただ、過去の経験では、この会社が要件定義を行ったプロジェクトには、要件の不備から問題を抱えたプロジェクトが多々ありました。
 PMに任命されたあなたは、リスク・マネジメントの観点からどのような対応をとればいいのか、考えてみましょう。

 まず、どのようなリスクがあるか考えます。
 リスクを考えるときには、プロジェクト・メンバーだけでなく部門や会社の有識者を入れて、プロジェクトを進めていくときのプロセスをイメージし、契約、環境、リソース、技術、外部、マネジメントの観点で、気をつけなくてはいけないことは何か、もし、こうなったらどうなるだろう、と進めていきます。その際に、PMBOK®ガイド 第5版対応 テンプレート集のリスク・チェックシートを参考にしてください。

 たとえば、スコープの記述が曖昧であるとか、成果物の受け入れ基準が明確でないケースがあります。このままプロジェクトを進めると、要件が雪だるま式に増え続け、当初予定していたコストやスケジュールで終わらなくなる可能性があります。また、無理矢理計画していたスケジュールで終わらせようとするために、品質の劣化を招く可能性があります。

 このリスクの対応策は、要件定義書の見直しを行い、スコープを明確にすること、成果物の受け入れ基準を明確にすることです。そのためにはWBSに見直しのためのワークを作成し、コストとスケジュールを確保することで、リスクの軽減を図ります。ただし、他のプロジェクトやプログラムの関係で、十分な見直し時間がとれないケースも多々あります。そのときは、リスクが顕在化したときのために、コンティンジェンシー予備費を計上します。

 また、要件として新しい技術を使用することもあるでしょう。そのときは、その新しい技術は、プロジェクトにとって本当に必要な技術なのか考えましょう。他に使用できる安定した技術があればそちらに変更することで、リスクを回避することができます。

 しかし、どうしても必要な技術であれば採用せざるを得ません。そのときは、その技術に精通したベンダーに該当部分の作業を委託することで、そのベンダーにリスクを転嫁できます。
 正しい対応策をとるためには、リスクを明確にし、リスクの発生頻度、発生したときの影響度を分析して優先度の高いものから対応策を検討し、計画しておく必要があります。

 これらのリスク・マネジメントを、正しい時期・正しい方法で行わなかった場合、プロジェクトの進行に伴って面白いようにリスクが顕在化し、都度、対応策を検討しスケジュールの変更、要員計画の変更、プロジェクト・オーナーへの説明に追われ、本来実施すべきプロジェクトマネジメント活動が手薄になり、新たなリスクの顕在化や問題の発生となりかねません。

 プロジェクトの計画段階で、リスクの特定、分析、対応計画の策定を終えた後は、リスク・コントロールとして、定期的にリスクの見直しを行い、リスクの再査定や新たなリスクの有無を確認し、変更があれば、対応策の検討・策定を行います。

 事前にどのようなリスクが発生するか、発生したらどのような影響があるのか、そのときどのように対応すればいいか、ということを検討しておけば、いざというときに慌てなくて済みますね。
 備えあれば憂いなしです。

リスク対応戦略789リスク.jpg

PMBOK®ガイド 第5版対応 テンプレート集、11131RiskManagementPlanV5R1.doc より
(注: テンプレート集は支部会員専用ページでダウンロードいただける資料です)

 「既知の未知」と「未知の未知」

 リスクは「既知の未知」と「未知の未知」に大きく分類されます。既知の未知はリスクとして特定しその対応策をとれるものです。これは前述のように対応します。

 未知の未知はリスクとして特定できず、想定外の事象です。
 事前には具体的な対応策をとることができません。だからといって何もしないでよいわけではありません。事前に対応策を検討していないので、顕在化したときにはプロジェクトに大きな影響を与えるかもしれません。

 発生したときに有効な対策を打てるように、マネジメント予備としてコストを計上しておきます。

 リスクでマネジメントするもの

 リスク・マネジメントでマネジメントするのはリスクそのものではありません。

 リスクを特定し、分析、対応策の立案、コントロールのプロセスをマネジメントすることで、リスクが顕在化したときにプロジェクトへの影響を最小限にとどめる活動をマネジメントします。

 

 以上、今回はPMBOK®ガイド 第5版「リスク・マネジメント」について概略を解説しました。
 プロジェクト目標を実現するためにリスクを早期に特定し、対応策を立案することが重要になってきます。リスクの可視化を早期に実施、ステークホルダー間で共有し、プロジェクト成功への一歩を踏み出しましょう。
 
以上

当連載の他の記事へのリンク

  第1回 イントロダクション
  第2回 ISO21500について
  第3回 ステークホルダー・マネジメント
  第4回 ナレッジ・マネジメント
  第5回 アジャイル型ライフサイクル
  第6回 プログラム、ポートフォリオ
  第7回 スコープ・マネジメント
  第8回 タイム・マネジメント
  第9回 リスク・マネジメント
第10回 統合マネジメント
第11回 PMBOK®ガイド は使えるのか
第12回 PMBOK®ガイド 拡張版