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

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第82回】トリガーポイント~リスクが問題・課題に進化する瞬間


【第82回】トリガーポイント~リスクが問題・課題に進化する瞬間


ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

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

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

 

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

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

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

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

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

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

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

 

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

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
トリガー条件とか、トリガーポイントという言葉を聞いたことはあるでしょうか?PMBOKガイド第5版の用語集には、以下の説明があります。(※1)

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

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

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

| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事