トラブルを報告したくなる風土を作るやる気を引き出すプロジェクト管理(8)(1/2 ページ)

最終回は、プロジェクトのリスクマネジメントを中心に解説する。それにより、トラブルを未然に防ぐ方法と発生後の対処法の基本を学んでいく。

» 2009年05月18日 12時00分 公開
[安達裕哉,トーマツ イノベーション]

 プロジェクトを「見える化」するには、トラブル予測、予防、発見、対応の4つを行うことが大切であると、前回の「プロジェクトの肝、見える化に挑戦!」で話しました。今回はその4つについて、もう少し詳しく解説を行いたいと思います。

トラブルの予測

 トラブルを予測するうえで最も重要なのが、リスクの体系化です。リスクの体系化は予想以上に多くの知見をプロジェクトマネージャに与えてくれます。

 なぜならば、通常プロジェクトマネージャはリスクを、自分自身の経験の範囲内で見ることが多いのではないでしょうか。しかし、個人で見切ることのできるリスクの数は限りがあり、しかも想定外のリスクも多いのです。そこでリスクの体系化を行い、漏れなくリスクを洗い出すことで、どこに着目すればトラブルを予測できるのかを明らかにします。

 それでは、具体的にリスクの体系化とは何を行えばよいのでしょうか? まずは、下の図1を見てください。

ALT 図1 リスクを階層化し、全体を見渡せるようにする(出所:トーマツ イノベーション)

 最上位の階層をプロジェクトリスクとし、プロジェクトリスクとはどのようなものがあるか、漏れなく、重複なく分解を行います。この図を、プロジェクト管理の世界標準規格であるPMBOKではRBS(リスク・ブレークダウンストラクチャ)と呼びます。

 リスクを構造化、分解することにより、リスクを漏れなく俯瞰(ふかん)することができ、予想外のトラブルを減らすことが可能となります。

 それでは、具体的なRBSを見ていきましょう。下がRBSの事例です。

ALT 図2 RBS(リスク・ブレークダウンストラクチャ)の例(出所:トーマツ イノベーション)

 この図において、プロジェクトリスクはいかなるプロジェクトにおいても共通に存在する「コアリスク」とプロジェクトおのおのに固有のリスクである「個別リスク」に分解されています。

 さらに、「コアリスク」は「無理なスケジュール設定」「要求の増大」「要員の離脱」「決まらない仕様」「生産性の低迷」「不適切な要員設定」「コンプライアンス違反」に分割することができます。

参考文献
『熊とワルツを??リスクを愉しむプロジェクト管理』(トム・デマルコ著、日経BP社)

 ここまで準備が終われば、後はプロジェクトにおいて「リスクの洗い出しミーティング」を行い、さらに下位の要素へ分解してゆけばいいのです。ミーティングの結果は下のような様式(リスク一覧表)にまとめます。

ALT 表 このようなリスク一覧表にリスクを洗い出し、漏れなく記入する。ただし、トラブルの前触れの発見の欄は後で埋める(出所:トーマツ イノベーション)

 「想定されるリスク」まで埋めれば、トラブルの予測は終了です。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ