オルタナティブ・ブログ > プロジェクトマジック >

あるいはファシリテーションが得意なコンサルタントによるノウハウとか失敗とか教訓とか

偉い人がゼロリスクを求めるとかえってリスキーになる現象、あるいはITプロジェクトでのコミュニケーションスタイル

»

この5年くらいで、日本社会はずいぶんリスク拒絶度合いが高まったように思う。会議で「リスクは充分潰したのか?」という発言も増えたと思う。ITに限っても、情報漏洩、サービス停止、誤作動、遅延、コストオーバー・・・避けたいリスクは山のようにある。
リスク対策を検討するのはもちろん重要なのだが、「成し遂げようとしているチャレンジはやる価値があるか」「どうやったら、よりいいものが出来るか」「それで競争に勝てるのか?」よりも優先的にリスクのことばっかり話す姿勢に、正直うんざりしている。
そして「リスクをゼロにしろ」という指示は、一見ごもっともだが、ほとんど意味が無い指示だ。有害ですらある。そして指示する時にほとんど脳みそを使わなくていい。そういう点で、「品質を無限に上げろ」というのと似ている。



★そもそもプロジェクトは不確実性に満ちている
僕の主戦場はプロジェクトワークなのだが、もちろんリスクとどうお付き合いするか?というのは大きなテーマだ。将来起こりうる困った事態にどう対処するか?をよく議論する。
とは言え、リスクをゼロにすることはできない。なぜなら、プロジェクトは本質的にそういうものだからだ。プロジェクトは定義上、「初めてやる仕事」である。初めてやるということは、思ってもみなかったことが起こるということだ。もし将来が完璧に見通せる仕事があるとしたら、それは経理の締め作業とか毎月の給与計算とか、すでに何度も経験がある仕事だし、そういうのはプロジェクトとは呼ばない。

そして僕らがプロジェクトでやろうとしていることは、業務の変革(再設計)なり新規事業なりITの構築なり、どちらにせよ複雑なものを相手にしている。「複雑なもの」というのは、因果関係が事前に100%見通せない、ということだ。
初めてやる仕事であっても、AをいじるとBがB'になって・・と見通せるならば、リスクはほとんどない。
でも組織とか人間とかコンピュータ・システムは複雑なものなので、見通しが悪い。
結果として、やってみて初めて分かることが必ずある。

だから、優れた人々がどんなに時間をかけて検討しても、リスクは事前にゼロにはならない。



★でも「ゼロにしろ」というと何が起こるか?
本質的にリスクにまみれた仕事であるプロジェクトでも、ゼロリスクを求める偉い人はいる。特に、それまでのキャリアであまりプロジェクト的な仕事をしてこなかった人は、リスクをとにかく下げたがる。
会社を守るために必要なことだろうし、サラリーマンでもあるので個人としても自然なことなのかもしれない。

ただし、過剰にリスクを求める代償は結構大きい。

1)隠蔽体質になる
本質的にリスクがあるのにゼロにすることを求められる。でもできない。そうすると隠蔽が有力な選択肢になってくる。隠蔽というとおおごとに聞こえるが「大きなリスクなんて存在しないように報告する」「問題があっても、さも大した問題ではないように報告する」というのは、普通に行われていることだ。
30年前に書かれた「プログラミングの心理学」にも、組織の最下層での「大きな問題です!」という報告が5つか6つの階層を上がって役員に到達する頃には「全て順調です」に変換される現象が描かれている。プロジェクトワークをやっている人なら誰もが経験するアレ、大昔からあるんですね。

隠蔽体質が最悪なのは、リスクが大きくなって、もうにっちもさっちも行かない状態になって爆発というか露呈することだ。これこそ一番避けたいリスクなのに。小さいリスクすら許容しないと、逆に大きなリスクを招いてしまう。


2)内向きの説明にマインドが向かう
上司がゼロリスク志向な人だと、部下の人たちはその人を説得しないと仕事が進まないから、内向きになる。
社内への説明資料をいっぱい作る。それに時間をかける。プロジェクトを前に進めたり、お客さんにサービスしたり物を作ることよりも、社内を納得させるのに必死になる。
お客さんに「こう書かないとウチの社内が通らないんですよ」とか、平気で口にする人とかいますからね。お客さんからしたら、知るかボケ、の世界ですよ。


3)どこかにリスクを丸投げしようとする
「プロジェクトの納期とコストを絶対守るように!」という指示をまともに受け止められない(やる自信がない)場合は、外部ベンダーに丸投げすることで、対応しようとするかも知れない。
「○年○日までに、△△を××円で完成させます」という請負契約を結んだのであれば、確かに、プロジェクトをやりきれないことのリスクはベンダー側に持ってもらうことになる。
ただ、ベンダーさんの側も商売だ。リスクを見込んで高い金額になる。さらに、ベンダー側がすべてのリスクを背負う契約になっていない事が多いが、発注側は背負ってもらっている気になってしまう事が多い。プロジェクトがうまくいかないケースで揉めるのは、たいていはこの認識の違いだ。
丸投げはかえって本質的なリスクを増やすことが多い。そもそも、上手く行かなかった時に影響を受けるのは、発注者側のビジネスなのだし。


4)プロジェクトをやらないリスクに目が行かない
プロジェクトはリスクにまみれているのだが、避けてばかりもいられない。プロジェクトをやるリスクに比べて分かりにくいのだが、やらないリスクは確かに存在するし、たいてい致命傷になる。
競合他社に決定的な差を付けられたり、業務が分かるベテランが社内にいなくなって変えることすらできなくなったり。長期的でじわじわくる話なので、やらないことの責任の所在も問われにくいのが非常に厄介なのだが。



★では、リスクにどう向き合うのか?
ゼロリスク志向の上司と戦うのもひとつの手だ。僕は本当に必要ならば戦います。でも対決モードになる前に、できる事も多いので、なるべくならそっちで対処する。対決モードはその後協力を取り付ける時なんかに、デメリットが大 きいから。

a)リスクをリストアップする
リスクが見えないこと、検討しないことが最大のリスクなので、とりあえず考えられるリスクは全部書き出す。単純だが、これだけでもずいぶん違う。
そしてゼロリスク志向の上司さんには「リスクがゼロにならないことではなく、今の時点で見えていること自体を評価してください」と説得する。


b)許容するリスク/対処するリスクを決める
リスクはあくまで将来起こる「かもしれない」問題である。起こらないかもしれない。だから100%対処するのは間違っている。「プロジェクトルームに隕石が落ちてメンバー全員が死亡する」みたいなリスクまで対処してもしょうがない。
せっかくリストアップしたのだから、落ち着いて対処するかしないかを仕分けしていく。
通常は「発生確率×起きた時の影響度合い」で優先順位を決める。

ただ、どのリスクを許容して、どのリスクを許容しないのか?というのは、かなり高度な経営判断になる。
「このサービスが1日停止する確率を1%から0.1%に下げるのに1億かかりますけど、どうします?」と聞かれて即答できる人はほとんどいない。さらに、サービス停止じゃなくて顧客情報の漏洩だったら、いくらまでなら許容出来るだろうか??
「リスクをゼロにしろ」という指示でどうにかなる話ではないのだ。


c)専門家と経営者がすり合わせて決める
だから、この手の意思決定をするためには、専門家と経営者が意見交換する必要が絶対にある。
「リスクをゼロにしろ」という指示が最悪なのは、そういうコミュニケーションを拒絶する言葉だからだ。どこまで行ってもさじ加減の問題なのに、0か1かという簡単な話にすり替えてしまう態度だからだ。

そして、こういう意見交換の土台は、オープンなカルチャーだ。
今あるリスクを赤裸々に話しても、身に危険が及ばないという信頼感。逆に経営者が専門家、現場の人に基礎的なことを質問しても威厳を失わないという信頼感。
こういうオープンなコミュニケーションの土台がない組織は、そもそもリスクとは戦えない。

プロジェクトでは、「成功に向いたカルチャーかどうかが成否を分ける」と常々言っているのは、例えばこういう話。

Comment(0)

コメント

コメントを投稿する