見えるリスクと見えないリスク

PMBOK Guideによると、プロジェクトとは「特定の製品またはサービスを創出するための時限的営為」である、と定義されている(A project is a temporary endeavor undertaken to create a unique product or service)。正直に言うと、PMBOK Guideは最近「教科書」として過剰に絶対視され過ぎていると私は思うのだが、冒頭にあるこのプロジェクトの定義も、若干の違和感を感じる部分である。なぜなら、この定義には『リスク』の語が欠けているからだ。

プロジェクトとは、リスクを伴う、時限的営為である。プロジェクトにはリスクがつきものだ。私の同僚には、「プロジェクト・マネジメントはリスク・マネジメントにつきる」とまで断言する人もいる。たしかに、一度限りの営為であっても、リスクの全くない仕事、たとえば飲み会の相談など、誰もプロジェクトとは呼ばないだろう。

PMBOK Guideはそれでも、1章を割いてリスク・マネジメントを論じ、プロジェクト管理の9領域の一つと説明している。また最近はリスク管理論の出版も増えつつあり、通信講座の電話勧誘までかかってくる始末だ。

ところで、私は現在のリスク・マネジメント論には、不満を持っている。PMBOK Guideを含めて、通常の解説では、リスクを洗いだし、それを定量/定性評価して、どう抑え込むかばかりが論じられる。そして、前半をリスク・プランニング、後半をリスク・コントロールと名付け、コントロールの手法として回避・軽減・保有・転嫁(移転)があるが、このための金銭的用意をリスク・ファイナンスという、という風に続いていく。

だが、はたしてこれで良いのだろうか? リスク移転とはすなわち保険による対処に他ならないのだが、プロジェクトのリスクは本当に保険屋がかぶってくれるのだろうか?

私が思うに、実はリスクには3種類ある:
(1) 予測され、計数化されたリスク
(2) 予測されたリスク
(3) 思いもよらない潜在的なリスク

プロジェクトにおいて実際に問題となるのは、プロマネが一番神経をすり減らすのは、圧倒的に(3)ではないだろうか?(なお、ここではidentifyという英語によい訳語がないので、「予測」としている)

ふつうのリスク管理の教科書では、(2)をどう(1)にするかという問題ばかり、詳しく説明されている。しかし、そもそも私の実務感覚では、予測されたら、それだけでリスクは半分減ったような気がする。お化けが出てから、それを枯れ尾花と見極めるのはたやすいので、怖いのはどんなお化けが出るかわからないからなのだ。この「怖さ」は、定量化されていないにもかかわらず、プロマネやチーム員の心的エネルギーを、確実に消耗させていく。

保有と転嫁について言えば、保有すれば自分に被害がかかる可能性があるのだから、転嫁の方が良いように思える。でも、ふつう転嫁にはお金がかかる(だから保険屋は商売として成り立つのだ)。まして、保険は間接損害はカバーしてくれない。35年以上前のことだが、、私の勤務先は海難事故で会社が傾きかけたことがあったらしい。アルジェリアの建設現場に送る巨大な機器の輸送船が、海に沈んだのだ。損害保険は無論かけてあった。だが、それは沈んだ機器の再製造費用は出してくれるが、機材の到着遅れによるプロジェクト全体の納期遅れについてはカバーしてくれない。保険は失った時間は返してくれないのだ。プロマネの悩みを完全に救ってくれるような保険など存在しないのである。

リスクを保有する場合は、プロジェクト実行予算の上で、予備費用をもっておく必要がある。予備費用は、予期されたリスク(見えるリスク)に対するアロウアンスと、予期できぬ(見えない)リスクに対するコンティンジェンシーに分類できる。つまり、いずれにしてもリスク・ファイナンスとは、お金で持つか現物で持つかの違いでしかないのである。

こうして見ると、ふつうのリスク・マネジメント論には、ひとつの大きな欠落があることがわかる。それは、見えないリスクが現実化して障害事象が起こってしまったら、どう対処するかというイシュー・マネジメントの方針論が欠けていることだ。発生防止は王道だ。しかし発生後の対策も必須である。

交通事故というリスクを考える時に、車の衝突安全性を上げる工夫や、運転技術を向上させる方策だけを論じるだけでは十分とは言えない。車の改造や運転講習会もいいだろう。しかし通勤途上で事故にあったら、どこの誰にどう連絡するか、決めておくことも必要なのだ。プロジェクトで何か起きたら(そして大概なにか起きるのだ)、それを誰が誰に報告してどう判断するかを考えておかねばならない。

以前、「サプライチェーンのリスク・マネジメント」に書いたように、リスク低減策は冗長性・多重化を要求するので、プロジェクトのコストダウンの要求とはかみ合わない。サプライヤーの絞り込み、人的リソースのミニマム化、などはすべて相反する。スリム化しすぎたプロジェクト組織では、変動に対処する自由度がなさすぎるのだ。

リスク・マネジメントにとっては、自由度がもっとも重要である。自由度がなければ、現場で代替手段を判断できない。プロジェクト計画における自由度の大事さを、もっと広く認識してもらうよう努めて行かねばならないだろう。
by Tomoichi_Sato | 2010-09-26 21:48 | リスク・マネジメント | Comments(0)
<< 「ITって、何?」質問1: ど... 「ITって、何?」 第0回 疑... >>