>前回はPMBOK第4版による「プロジェクト・リスク」の定義について、「成果物出来高と時間の二軸によるプロジェクト・モデル」にあてはめて考えてみました。ここまでならわかるのですが、トム・デマルコ氏はさらにリスクを「考えうる結果と、それによる影響をあらわす加重パターン」と再定義しています。その意図するところは何なのでしょうか?どうやら、まだまだリスクについて知っておくべきことがありそうですね。(※1)今回はもう少し大きな視点で「プロジェクト・リスク」について考えていきます。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~当ブログの「【第11回】超ハイリスク?甲子園への道・プロジェクト!」では、「甲子園への道・プロジェクトは超ハイリスクだ!」という言い方をしました。その意味するところをもう少しかみくだいて言うと、次のようになります。「甲子園への道・プロジェクトのプロジェクト・ゴールである甲子園出場を達成することは非常に難しい。」また、この「非常に難しい」ことの根拠として、東東京大会の参加校が139校に対して出場できるのは1校だけであり、「甲子園への道・プロジェクトの成功確率は単純計算で0.72%と非常に小さく、逆にプロジェクトの失敗確率は99.28%と非常に高い」という事実をあげました。ここで着目してほしいのは次の2点です。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~普通「プロジェクト・リスク」というと、たとえば「仕様変更多発リスク」や「品質リスク(障害多発等)」などを思い浮かべますよね。前回とりあげた「甲子園への道・プロジェクト」における「怪我リスク」や「緊張感リスク」の具体例も、確かに発生したら「プロジェクト・ゴール」の達成に影響はしますが、「プロジェクト・ゴール」そのものが達成できるかどうかということを対象としているわけではありませんでした。これら「怪我リスク」や「緊張感リスク」のように「プロジェクト・ゴール」の達成に影響を与えるかもしれない特定の「事象」や「状態」のことを「個別リスク」と呼びます。それに対して「甲子園出場を達成することは非常に難しい」などの「プロジェクト・ゴール」そのものを対象とした不確実性のことを「プロジェクト全体リスク」と呼びます。(※2)この呼び方はPMBOKの発行元であるPMIから出されている「プロジェクト・リスクマネジメント実務標準」に定義されています。プロジェクトマネジメントの権威であるトム・デマルコ氏も明確に、「リスクには全体リスクと部分リスクがあり、それぞれ扱い方が異なる。あり、「プロジェクト全体リスク」の対応戦略として「プロジェクト中止」「再計画」などがあります。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~前述の通り「甲子園への道・プロジェクト」が超ハイリスクであることの根拠として、プロジェクトの成功確率が0.72%と超低い数字であることをあげました。リスクは不確実なものであり、その発生確率は0%と100%の間にあります。そのため、リスクの度合いを表現する際には、その発生確率を%で示すのが最も簡単に感じます。プロジェクト管理の権威であるトム・デマルコ氏は、「リスクについて数字で考える習慣を捨て、視覚的に考える」ことを推奨しています。具体的には次のような「リスク図」を用いて、「プロジェクト・ゴール」を達成することの不確実性を表現すべきということです。(※4)確かに「プロジェクトの成功確率は0.72%です。」と言われるより、「プロジェクトの結果はこの図のように予測できます。」と言われた方が、プロジェクトの先行きを見通すことができますよね。このような「リスク図」は、たとえば昨年までの戦績などの過去のデータを元にして作成することができます。システム開発プロジェクトのリスクを分析する際には、モンテカルロ・シミュレーションという技法が使われます。(※5)トム・デマルコ氏によるリスクの再定義「考えうる結果と、それによる影響をあらわす加重パターン」は、このような「リスク図」のことを示していたのです。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~「プロジェクト全体リスク」をもう少し私流にわかりやすく説明するため、前回登場した「プロジェクト・モデル」上で表現してみます。さあ「プロジェクト・リスク」に関するもう一つの視点「プロジェクト全体リスク」がどんなものか理解できたでしょうか?図2ではプロジェクトに内在する不確実性の影響で、「プロジェクト・ゴール」に対して「プロジェクト最終結果」が振り子のように振れることを示しています。この「プロジェクト最終結果」の振れ幅そのものを「プロジェクト全体リスク」ととらえてください。概念的な話ばかりで納得感は少ないかもしれませんね。「プロジェクト全体リスク」をどのようにマネジメントして行けば良いのか?次回は「プロジェクト全体リスク」の具体的な扱い方についてご紹介します。ここではあえて「プロジェクト目標」と「プロジェクト・ゴール」を使いわけています。一般的に「プロジェクト目標」には、「スコープ」「スケジュール」「コスト」「品質」などがありますが、「プロジェクト全体リスク」の対象が、個々の「プロジェクト目標」ではなく、プロジェクト全体であることを表現したかったためです。「プロジェクト・ゴール」はプロジェクトの成功と失敗の判断基準であり、図2で登場する「プロジェクト最終結果」はプロジェクトがどう転ぶか(転んだか)の最終結果を示しています。モンテカルロ・シミュレーションについては、前掲の『プロジェクト・リスクマネジメント実務標準』や『熊とワルツを~リスクを愉しむプロジェクト管理』に概要が紹介されています。モンテカルロ分析ツールもいくつか出回っていますので、興味のある方はWEBで検索してみてください。■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。(プロジェクトマネージャ、システム監査技術者他)など。社員の声アクセス採用情報ブログ株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。Inc.)の登録商標です。Provider)です。Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。アイ・ティ・イノベーションまたは各社の商標もしくは登録商標です。