DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は「プロジェクト・リスク」について、PMBOK第4版やトム・デマルコ氏の定義を引用してみましたが、なかなかすっきりしませんでしたね。「プロジェクトの成功確率を高めるためには、しっかりとリスクマネジメントしていく必要がある」ということについては誰しも異論が無いと思います。しかし、「プロジェクト・リスクとは何か？」ということをあいまいにしたままでは、現実のプロジェクトにおいて具体的にどうやってリスクマネジメントして行けばよいのか、ステークホルダー間で共通認識が持てずに、結局は形式的な運用に陥ってしまうでしょう。
今回はこのやっかいな「プロジェクト・リスク」をやっつけたいと思います。（※１）

【　一般的なシステム開発のプロジェクト・モデル　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
人によっていろいろなとらえ方がされている「プロジェクト・リスク」というものを説明するためのベースとして、まずは一般的なシステム開発プロジェクトの特徴をピックアップした「プロジェクト・モデル」を設定してみます。リスクの定義の中心にある、『プロジェクト目標』を中心に考えて、次のようなモデルを設定してみました。（※２）

『プロジェクト目標』には、「スコープ」「スケジュール」「コスト」「品質」などがありますが、できるだけシンプルに表現したかったので、成果物出来高（≒「スコープ」）と時間（≒「スケジュール」）の二軸による「プロジェクト・モデル」としています。つまり、プロジェクトが開始して終了するまでの間に成果物を少しずつ作り上げて行って、成果物が完成したら『プロジェクト目標』に達するということを表現しています。

そして『プロジェクト目標』に向かう道のりを一本の点線の矢印で表現しました。その道のりは、「いつまでに、どれだけ成果物を作成する」というプロジェクト計画にあたる部分です。さらに、そのプロジェクト計画を示す矢印のうち現時点までを実線で示すことで、そこまでのプロジェクト実績を示しています。図１においては、プロジェクト計画を示す点線部分とプロジェクト実績を示す実線部分が一致しているため、現時点における成果物出来高の状況（進捗状況）は、オン・スケジュールであることを示しています。

【　プロジェクト・モデルにおける問題の定義　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、いきなりリスクの定義に入る前に、もう少しとっつきやすいプロジェクトにおける問題の定義でウォーミングアップです。当ブログの「【第４回】プロジェクトにおける問題とは何か？」において、「プロジェクトにおける問題とは、プロジェクト計画と現状とのギャップである！」と定義しました。その定義を「プロジェクト・モデル」にあてはめてみます。

プロジェクト計画を示す点線の矢印に対して、プロジェクト実績を示す実線が現時点において離れてしまっています。【第４回】で定義したプロジェクトにおける問題は、この点線と実線のギャップを指しています。つまり、図２の状況では、現時点までの成果物出来高（Ｂ）が、プロジェクト計画で立てた予定（Ａ）に到達していないということが問題ということになります。（※３）

＜ 目標（あるべき姿）＞　＝　（Ａ）「計画で立てた現時点での成果物出来高予定」
＜　　現　　 　状　　＞　＝　（Ｂ）「現時点での成果物出来高実績」
＜　　問 題　　＞　＝　（Ａ）と（Ｂ）のギャップ

【　プロジェクト・モデルにおけるリスクの定義　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、いよいよPMBOK第4版のリスクの定義を「プロジェクト・モデル」にあてはめてみます。

「リスク(Risk)．もし発生すれば、プロジェクト目標にプラスあるいはマイナスの影響を及ぼす、不確実な事象あるいは状態。」

できるだけPMBOKの定義を忠実に表現するため、リスクの定義に出てきている『発生』『プロジェクト目標』『プラスあるいはマイナスの影響』『不確実』『事象』『状態』という用語は全て図の中に含めました。

では、これを「甲子園への道・プロジェクト」にあてはめてみて、リスクの具体例を考えてみましょう。

＜プロジェクト目標＞　＝　地方予選で優勝して、甲子園に出場する

＜リスク（事象）の具体例＞　＝　エースピッチャーが怪我をする
＜マイナスの影響＞ ＝　控えピッチャーが登板して大量失点
＜プラスの影響＞　　＝　臨時登板の１年生投手が頭角を現し大活躍

＜リスク（状態）の具体例＞　＝　選手が緊張して普段の力が出せない
＜マイナスの影響＞ ＝　エラー続出による大量失点
＜プラスの影響＞　　＝　緊張感からスイングに力が入りホームラン連発

上記の『事象』や『状態』は現時点では『発生』しておらず、『発生』するかどうかもわからない、いわば『不確実』なものです。『プロジェクト目標』の達成（すなわち、プロジェクトの成功）を確実なものにしたければ、これらの『不確実』な『事象』や『状態』が『発生』することで『プロジェクト目標』に『影響』を及ぼすかもしれないことをリスクとして認識する必要があります。そして、これらのリスクによる『マイナスの影響』を軽減したり、『プラスの影響』を強化するために、「甲子園への道・プロジェクト」のＰＭである監督は、たとえば、次のようなリスク予防策（事前対策）を講じるということになります。

＜リスク予防（事前対策）の具体例＞
・　練習試合でのエースピッチャーの登板が過度にならないよう配慮する
・　エースピッチャーが利き腕で重い荷物を持つことを禁止する
・　下級生や肩の良い野手等、他のピッチャー候補を積極的に育てる
・　選手たちに駅前で校歌を歌わせるなど、緊張状態を何度も経験させる
・　選手たちに座禅を体験させるなど、平常心を保つ訓練をする
・　事前に試合会場を訪れ、大声援を録音した音声をヘッドフォンで聞きながら、各選手のポジションに立ちイメージトレーニングを行う

なお、リスクによる『プラスの影響』については、リスクマネジメントの対象からは除外されることが多いようです。私の経験上も、実際のプロジェクトの現場でリスク一覧表に『プラスの影響』を記載している例は確かに見たことはありません。。。

さあ、「プロジェクト・モデルによるリスクの定義」により、リスクが何者かが直感的にわかりやすくなったでしょうか？

まだまだですか。。。

そうですねえ。ここまでの説明だけなら、リスクについてそんなに悩むことは無いでしょう。しかし、前回登場のトム・デマルコ氏の再定義「考えうる結果と、それによる影響をあらわす加重パターン。」っていったい何のことでしょう？「プロジェクト管理の権威」であるトム・デマルコ氏が、わざわざリスクを再定義しているところからして、もっと大事なことが潜んでいそうですよね。それに『プラスの影響』を本当に無視していいのかもひっかかります。

なので、「プロジェクト・リスク」の話はまだ続きます。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　PMBOK第4版およびトム・デマルコ氏のリスクの定義とその参考文献については、当ブログの前回「【第１１回】超ハイリスク？甲子園への道・プロジェクト！」を参照

※２　一般的なシステム開発プロジェクトの特徴をピックアップした「プロジェクト・モデル」は、マックス・ヴェーバーの理念型の概念を利用していると言えるでしょう。当ブログ「【第８回】マックス・ヴェーバーの問題分析テクニック」を参照

※３　「問題の定義」および「プロジェクトにおける問題の定義」については、当ブログの以下の回を参照

・「【第３回】問題とは何か？」

・「【第４回】プロジェクトにおける問題とは何か？」

・「【第５回】プロジェクト計画と現状とのギャップ具体例紹介」