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

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

あっという間に8月も終わりですね。今年の夏に盛り上がったもののひとつに「ポケモンＧＯ」があります。ポケモンは、たとえばピチュー→ピカチュウ→ライチュウといった形で進化していくものです。最初はかわいいポケモンたちも、進化してかわいくなくなるのもあるようです。

ポケモンたちは必ずしも人間社会に悪影響を及ぼすものではありませんが、プロジェクトの中には放っておくとプロジェクト目標に悪影響を及ぼす問題・課題に進化するリスクというモンスターがたくさんひそんでいるのです。。。

【　問題・課題はリスクの進化型？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「リスクが問題・課題に進化する」という表現に、Ｐ子さんはまた何かひっかかりを感じているようです。

＜新人Ｐ子さん＞　：　「リスクはまだ発生していない事象または状態で、問題・課題はプロジェクト計画と現状のギャップでしょ？管理方法も違うし、リスクと問題・課題を混同しちゃいけないと思ってたのに『リスクが問題・課題に進化』って言われてもピンとこないわ。」

＜ベテランＰＭのＭ男氏＞　：　「だからリスクなんてよくわからない概念は必要ないんじゃ！無駄にいろんな概念を作りだすから、リスク管理表なんて余計な資料作らなきゃいけなくなって、管理工数が増えるんじゃろ？気になることは全部TodoListに書きだして、手を付けやすいところから適当にやっときゃええんじゃ！時間が経てば自ずと別の問題・課題が出てきて古いTodoは自然消滅するんじゃ！」

―――　おやおや、「進化」というメタファがＰ子さんを混乱させてしまったようです。Ｍ男氏はリスクも問題・課題も管理しているふりをしているだけで、行き当たりばったりのプロジェクト運営を行っているようですね。それでは、先手管理どころか、問題の先送りをしていることになり、プロジェクトの成否は神頼みとなってしまい、成功確率の向上など期待できません。

リスクと問題・課題は違うものであり、管理方法が異なるのは、当ブログで何度も触れてきた通りです。あらためてプロジェクト・リスクとプロジェクトにおける問題の定義とその違いを確認してみましょう。当ブログの　【第１２回】プロジェクト・リスクとは何か？　では、一般的なシステム開発プロジェクトの特徴をピックアップした「プロジェクト・モデル」に対して、「プロジェクトにおける問題」と「プロジェクト・リスク」をそれぞれ表現しました。このふたつを同じモデルの中に描くとどうなるでしょう？

図１の８月１日時点ではプロジェクト計画と現状にはまだギャップは生じていませんが、９月１日時点ではリスクが顕在化したことによるギャップが生じています。つまり、８月１日時点ではリスクに過ぎなかったものが、９月１には問題・課題に進化したととらえることができるのです。

【　トリガーポイントは、リスクと問題・課題の境界線　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
トリガー条件とか、トリガーポイントという言葉を聞いたことはあるでしょうか？PMBOKガイド第５版の用語集には、以下の説明があります。（※１）

トリガー条件(Trigger Condition).
リスクが発生間近であることを示すイベントまたは状況。

要はリスクが顕在化したとみなす条件ということですが、私はリスクと問題・課題の境界を示すポイントであるという意味でトリガーポイントという言い方が好きです。リスクが顕在化する前は、リスクが顕在化しないようにリスク予防策を講じて、リスクの状態をモニタリングするのですが、リスクが顕在化した後は、もう予防策やモニタリングなどと言っている状況ではなくなっていて、発生時対策を発動することになります。

なので、トリガーポイントはリスクの発生時対策を発動する判断基準であると考えることができ、その定義の方が理解しやすいかもしれません。たとえば、「仕様変更多発リスク」が顕在化したとみなすトリガーポイントとしては「仕様変更が多発した場合」などあいまいな表現にするのではなく、「外部設計着手後１ヶ月以内に１０件以上の変更依頼が起票された場合」など、第三者から見ても納得感の得やすい、具体的定量的な判断基準を設定する必要があります。

トリガーポイントがあいまいで、どのようにでも解釈できるような表現であった場合は、いつどんなタイミングで発生時対策を発動するかは関係するステークフォルダーの顔色を見ながら判断しなければならず、リスク管理が形骸化する要因にもなってしまうのです。トリガーポイントはリスクが問題・課題に進化する瞬間を示すものであり、リスク管理においてたいへん重要な概念であるということを押さえておく必要があるのです。

「トリガーポイントはリスクと問題・課題の境界線であり、具体的定量的に示す必要がある！」

【　リスクと問題・課題の目線の違い　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここまで見てきた通り、問題・課題はリスクの進化型であり、リスクが顕在化する前と顕在化した後で取り扱いが異なるものです。そして、この関係性を突き詰めると、完璧なリスク管理が行えていれば、プロジェクト進行中にどこからともなく突然問題・課題が発生するということはあり得ず、必ずリスク管理表にあがっているリスクの中から問題・課題に進化するものがたまに出現するという状態になるはずです。そのような状態が実現できれば、将来発生するかもしれない問題・課題に対する準備はいつもできていることになり、プロジェクトの成功確率はきっと高くなるはずです。

しかし、現実のプロジェクトにおいては、なかなかそうすっきりとリスク管理の延長として問題・課題を管理できるわけではありません。その理由は、以下の通りです。

問題・課題は既に発生したプロジェクト計画と現状のギャップであり、具体的定量的に示すことが比較的容易なのに対し、リスクはまだ顕在化していない事象や状態を扱うために、いろいろな可能性や結果を広く視野に入れる必要があり、具体的定量的に示すことが難しいという特徴があります。

また、既にプロジェクト計画に対してギャップが生じてしまっている問題・課題を解消するためのアクションは必須ですが、まだ顕在化していないリスクへの対応は、なんでもかんでも取り上げるのではなく、プロジェクト目標への影響があるかどうかといった少し高い目線にする方が理にかなっており、少し目線にずれが生じざるをえないという事情があります。

だからといって、抽象的定性的なリスクばかりあげていては、リスク予防策、リスクモニタリング方法、トリガーポイント、発生時対策などがともずれで抽象的定性的なものになってしまい、効果的なリスクマネジメントができず、やがて形骸化を招くのが目に見えています。

では、具体的定量的なリスクをあげるためにはどうすれば良いか？

ひとつのやり方として、これまでの過去プロジェクトで起こっていたプロジェクトの失敗につながるようなリアルな問題・課題を題材にして、リスク発生の具体的なシナリオを思い描いたうえで、リスク管理表にのせるのが効果的です。自組織の事例でも、他社の例でも良いので、実際に起きた失敗事例や問題・課題は、同じようなシチュエーションになった場合に再現する確率は高いはずです。リアルな事例であれば、具体的定量的なリスクとして設定しやすいはずなので、まずはそこから着手すべきです。

その上で、リスク・ブレークダウン・ストラクチャ（ＲＢＳ）などの網羅的なリスク識別のためのツールを活用して、過去事例だけでは網羅しきれていないリスク顕在化のシナリオを描いてリスク管理表に追記していくのです。いったん、過去事例から具体的定量的なリスクをいくつかピックアップしておくことで、後で追加するリスクの表現も具体化定量化しやすくなるはずです。

これを継続的に実施するためには、プロジェクト実績データの収集が不可欠です。たとえば、仕様変更の件数がどれくらいだと失敗につながる可能性が高くなるのかなどのデータを定量的に把握することができれば、トリガーポイントを定量的に表現する場合の精度が増していくことになるのです。リスク管理に基づく先手管理を実現して、プロジェクトの成功確率を高めるためには、プロジェクト・リスク・データベースの充実が必要なのです！

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

工藤武久

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

※１　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.