できるPMの決め手は「リスクマネジメント」プロジェクトマネジメントスキル 実践養成講座(8)(1/2 ページ)

» 2005年05月25日 00時00分 公開
[耵岡充宏スカイライトコンサルティング]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

コミュニケーション不足は一刻も早く解決を

 前回(「第7回 PM最大の武器、コミュニケーションスキル」)は、コミュニケーションマネジメントを解説した。

 コミュニケーションに問題があるといわれるプロジェクトには、2つの共通点がある。1つは「自分からいわない」点であり、もう1つは「自分からあえて気付かないようにする」点である。

 前者は、「気付いているけれど自分からはいわない」ことである。この背景には“誰かほかの人がいうだろう”という「責任回避」と、“ここで何かいって目立つのは嫌だな“という「不要な遠慮」があることが多い。後者は、あえて「自分からやっかいなことを見つけてしまわないようにする」ことであり、“何か気になるけど、まあいいか“というような「無責任・無関心」によりもたらされることが多い。

 自分の行動を振り返って、思い当たることはないだろうか。周囲にこのようなメンバーはいないだろうか。

 「責任回避」「不要な遠慮」「無責任・無関心」という問題の背景には、何かの原因があるはずである。例えば、プロジェクトの運営方法についての小さな不満がきっかけとなり、不満が積もりに積もったことが原因となることもよくある。

 本来、プロジェクトマネージャは、自らが積極的にコミュニケーションの手本となり、このような事態に陥らないよう周囲を導いていくことが求められる。しかしながら、やむを得ずこのような事態に陥った場合は、その根本原因を突き止め、一刻も早く解決することも求められる。ここでは特に「一刻も早く」という部分を強調しておきたい。このような悪い現象は、不思議とあっという間にプロジェクト全体へ伝染するものである。さらに個人レベルでいえば、時間の経過とともに根深い問題となってしまうことも多いので注意が必要である。

問題を未然に防ぐリスクマネジメント

 さて、今回はリスクマネジメントについて解説する。最近ではリスクマネジメントという言葉は広く普及してきており、あらゆる場面で用いられている。時には国家運営や企業経営そのものがリスクマネジメントの観点から語られることもあるが、ここではITプロジェクトにおけるリスクマネジメントの実践的な勘所を解説する。

 初めに、「リスク」という言葉の定義を確認しておく。リスクは「課題」と対比させると理解しやすい。

 課題とは例えば、テスト環境が構築されていないためテストが開始できない、あるいはバグが大量に発生してテストを予定どおり進めることができないなど、日々のプロジェクトでわれわれの多くが頭を悩ましている諸問題である。これら課題は、いずれもすでに起こった事象であり、いい換えれば「明確になった事実」である。

 一方、リスクとはすでに起こった事象ではなく、今後起こるかもしれない「不確実な事象」をいう。上記と同じ例でいえば、テスト環境の構築が期日に間に合わないかもしれない、あるいはバグが大量に発生してテストを予定どおり進めることができないかもしれないという、まだ不確実な段階での事象である。

 マネジメントという観点から説明すると、課題マネジメントはすでに発生した問題の対処であり、「事後処置的なマネジメント」といえる。これに対してリスクマネジメントでは、不確実な事象が顕在化する前に把握し、プロジェクトにマイナスの影響を与える事象が発生しないよう、未然に対処する。発生した場合でもその影響を最小限にとどめるように対処する。いい換えれば「事前予防的なマネジメント」である。

 プロジェクトにはリスク、課題の両方のマネジメントが必要だが、より重要なのは問題を未然に防ぐリスクマネジメントの方である。

 問題の発生を未然に防ぐことができるか、それとも、何か問題が起こってから対処するのか。プロジェクトマネージャの力量の差は、この点に集約されるといっても過言ではない。

 では、どのようにすれば問題を未然に防ぐことができるのか。まずPMBOKにおけるリスクマネジメントの定義を確認しよう。

PMBOKでのリスクマネジメントとは

 PMBOKには、「リスクマネジメントとは、プロジェクトのリスクを識別し、分析し、リスクに対応するための系統的なプロセスで、プロジェクトの目標に対してプラスに働く事象には、それが起こる確率とその発生結果が最大となるように、マイナスに働く事象については、逆に最小となるようにすること」とある(表1)。「不確実な事象」にはマイナスの影響を及ぼすものとプラスの影響を及ぼすものがあり、その両方をリスクとして扱っている点は注意が必要である。

プロセス 主要成果物 説明
リスクマネジメント計画 リスクマネジメント計画書 「リスクマネジメント計画書」は、個別のリスクに対する計画書ではなく、プロジェクトの計画時点で、プロジェクトで発生するリスクをどのようにマネジメントしていくかを決めること。例えば、リスクを認識したら、誰がどういうシートに何を記述するか、また、そのリスクをどう評価し優先順位付けるかを定めておくこと。
リスク識別 認識されたリスク、トリガーなど 関係者からの話や、成果物のレビューなどを基にプロジェクトのリスク事象を把握する。ささいな気掛かりがリスクの芽であるケースも多く、これを「トリガー」(リスク兆候)として認識することも重要である。
定性的リスク分析 リスク優先順位リストなど 認識されたリスクを「現実のものとなった場合の影響度」と「発生確率」の2つの観点から評価する。この評価を基に取り組むべきリスクの優先順位付けを実施する。
定量的リスク分析 定量化したリスクの優先順位リストなど 優先順位付けされたリスクを数量的に分析し、おのおののリスクがプロジェクトに与える影響を考慮し、どのリスクにどの程度注力するかを決める。場合によっては必要となるコスト・スケジュールのコンティンジェンシー予備の規模を決める。
リスク対応計画 リスク対応計画書など 個別のリスクへの対応策である。負の要因については、発生しないような対処、あるいは、発生した場合の影響を最小限にする施策を「リスク対応計画書」として取りまとめる。
リスクの監視・コントロール 迂回(うかい)策の計画など いったん識別されたリスクは、必要がなくなるまでプロジェクト期間を通じてモニタし続ける必要がある。これは、プロジェクトの状況が変われば発生確率や影響度が変わるケースがあるためである。
表1 PMBOK(2000Edition)におけるリスクマネジメント

 このように、PMBOKでのリスクマネジメントは6つのプロセスにより構成されているが、実際のプロジェクトではリスクはどのようにマネジメントされているだろうか。リスクの発見を、経験に基づくプロジェクトマネージャの思いつきに頼るなど、「頭の中でのリスクマネジメント」が多いのではないだろうか。

 プロジェクトマネージャも万能ではない。このようなことを続けている限り、問題発生→事後対処のループから抜け出すことは難しい。

 重要なことは、「個人の頭の中でのリスクマネジメント」から脱却し、リスクを、プロジェクト組織全体および期間全体を通じて目に見える形にして(可視化)対処することである。これが「問題を未然に防ぐプロジェクト」への第1歩といえよう。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。