 |
|
「ITプロジェクトのリスクマネジメント」 PMAJ関西(幹事・副代表) 土出 克夫：5月号
PMBOK®第11章「プロジェクト・リスク・マネジメント」は、初版(1996年版)では4つのプロセスで構成されていたのが、2000年版で6つのプロセスとして全面的に改訂され、さらに第3版(2004年版)では記述ページ数も倍増し(これは他の章も同様であるが)、内容が強化・充実されている。いかにプロジェクトにとって「リスクマネジメント」が重要かが伺える。 さてPMBOK®で明快に解説されているリスクマネジメントプロセスをITプロジェクト(ここでは、受託案件型のシステムインテグレーションのプロジェクトを想定)に適用しようとすると、結構悩ましい問題が起こる。 「リスク」はPMBOK®第3版 用語集の中で「もしそれが発生すれば、プロジェクト目標にプラスやマイナスの影響を及ぼす不確実な事象あるいは状態」と定義されている。プロジェクトにとって発生した(顕在化してしまった)問題・課題はリスクではなく、「まだ発生していないが将来起こる可能性がある(潜在的な)事象」を対象とするのがリスクマネジメントである。一連のプロセスとしてはまず当該プロジェクトやステークホルダーの特性を勘案したリスクマネジメントの取組み方針や進め方、判断基準の明確化に始まり、リスクの識別、対応計画を策定すべきリスクのランク(優先順位)付け、対応計画策定、そのモニタリングと監視コントロールの繰り返し、という流れであり、納得性のある手順である。 しかし、ITプロジェクトでは、リスクマネジメントの捉え方やリスク識別の結果が各人各様、組織のPM成熟度によっても様々であるからタチが悪い。即ち、ベテランPM(プロジェクトマネジャー)にとっては過去の経験や類似プロジェクトをベースに、事前の必須作業としてアタリマエの如くWBSとして具体化し、リソース・時間・金を割当て、実行に移す。そこにはリスクマネジメントをやっているという認識・感覚は殆どない。出来るPMはそれらの作業を阻害するかも知れない要因を明らかにしつつ、一段上位の？リスクマネジメントに手を掛ける。 一方、経験の浅いプロジェクトマネジャーや組織自身が未経験分野のプロジェクトでは、何が起こりうるかが想定できず、当然その結果としてベテランPMなら描くであろうWBSは登場せず、案の定、問題を顕在化させ、後手後手の対応でプロジェクト目標のQCDを大幅悪化させる結末を迎える。そのときに「リスクマネジメントはどうなっていたんだ？」と突付かれることも少なくない。 このようにITプロジェクトでは、スコープ達成にむけて必要かつ十分なWBSをどこまで洗い出しができるかによってリスクマネジメントの対象が大きく変わる。即ちプロジェクトマネジャーに経験や力量があり、また組織にPMをサポートする仕組みがあると、スコープ、Q、C、Dといった通常のマネジメント対象項目にすぎないものが、そうでないプロジェクトマネジャーや組織ではリスクマネジメントの対象となってしまう。これはITプロジェクトが知識集約型で眼に見えないシステム／ソフトウェアを扱っていること、また建築基準法の如き設計基準・規定がないことが背景にあると言えなくもない。 筆者は2004/10からPMAJ(当時、JPMF)のRISK-Management-SIGに参画し、目下「SIプロジェクトの実践的リスクマネジメント・ガイドブック」の共同執筆に取り組んでいるところであるが、同じIT業界からの参加メンバであってもリスクの捉え方は様々である。リスク識別を取り上げてもその切り口をどうするかで様々な意見が出てくる。 現時点(4/末)ではリスクマネジメントの手順・アプローチについてPMBOK®の6プロセスにならって、また識別〜監視コントロールの具体的な事象・アクション項目・留意点等については共通フレームのフェーズ・タスクの観点でマトリックス化する方向で整備しつつあるが、どのレベルをリスクとして扱うかが、また悩ましい。 ガイドブックの性格上、経験の浅いPMにもベテランPM(ではあるがこれまでリスクマネジメントに正面からは取り組んでいないPM)にもソレナリに有益となるガイドブックを目指そうとしているが、ベテランPMから見れば「なんでこんなんがリスクやねん？」とSIGの成果物にイチャモンがつきそうでもある。 9/1のPMAJ主催の“PMシンポジウム2006”ではSIGの成果の一部を報告させていただくが、その席で紛糾しないように、逆にSIプロジェクトのリスクマネジメントについて、より多くの有識者の皆様にお集まりいただいて、本質を突いた議論が出来ることを願って、執筆に注力していきたい。 ＜完＞
|
 |