ホントのリスクの識別、出来ていますか？

on

「リスクマネジメント」と言うと片仮名だからかもしれないけれどかっこいい印象を持つよね。で、印象がいいから

「リスクマネジメントやってますよ！」


って言うだけで、ホントにやっている「ような」気がしてくるでしょ？ね？


うーん、でも「気」だけなんだよなぁ、大概の人のリスクマネジメントは。だって、全方位的に識別していると思えないんだもの。

「えッ？そう思うのは『ワタシの周りだけだよ！』だって？……そうかもしれないけれど、そうかもしれないけど。」


荒ぶるリスクマネジメント概論
荒ぶるは、とっても乱暴な、みたいな意味合いで。


つべこべ言わずに識別しなさいってば！！
で、リスクマネジメントなんだから、兎に角、識別しないと始まらない。


あのですね、識別するんですよ。そこから始まります。リスクマネジメントって。それ自体わかっていない人というかエンジニアが多い。いや、経験値的にはわかっているのかもしれないけれど、頭でわかっていない、暗黙知化されていない、というか。それはいいとしてリスクマネジメントは、

識別→エクスボージャを推測する→対策方針を立てる→対策を実行する


となるのですよ。勿論、エクスボージャから「何もしない」というリスクを「受容する」を選択する場合もあります。何が何でも対策を実行するわけではないです。


識別が難しんだって！！
そう、多分、識別という行為をできていないエンジニアは、どこからどこまでの範囲をリスクマネジメントとして識別したらいいのか、その世界観が判然としないんだろうねぇ。


ぶっちゃければ、試行錯誤すればいいんです。今回は「ここまでの範囲でリスクを識別してみる。」、って。で、上手くいけばその案件はそれで良かったわけだし、もし、リスクマネジメントの識別するエリア以外のことが生じれば「仮定した範囲が狭かったね。」と実害を支払えばいいだけの話だし。


え？「そんなの嫌！」だって？じゃあ、頑張って識別しなさいな。


勉強代を払いながら経験を積まないと、身にならないんだけど。あぁ、そうか、いきなりリスクが発現したらインパクトが大きな案件とかプロジェクトとかから試そうとしていないかな。そんなチャレンジを越えたギャンブルなんてしなくていいじゃん。もっと、身近の、普段の、仕事のタスクで試してみたら。そうするんだよ。


大雑把に識別のはこのカテゴリ
個別のリスクは個別の案件やプロジェクトで違うから、フレームワークっぽく考えよう。でないと、応用が利かないから。


そのフレームワークはこんな感じでリスクのエリアを線引きしてみよう。

(自分でコントロールできない) (自分でコントロールできる)


次に「自分でコントロールできない」を線引きしてみる。

(自分でコントロールできない)
(自然災害) (自分の組織外)


自然災害は、隕石が落ちてくる、日本が沈むなどSFぽいことで、その起因が人災ではないケース。もう一つの自分の組織外は、影響を及ぼすことが出来ないステークホルダ的な意味合いで。SIerからみた官庁とか。自然災害よりはとっても現実的で、そのリスクの発現する確率は高いよね。


例えば、担当官が変われば一から説明して「今までやってきたこと」をひっくり返されないように刷り込みが必要かもしれない。往々にして、新任者は前任者と違うことをやろうとしますから。そうそう、東京の担当はオーケーを出していても、関西の担当に持っていったらだめですと言われるケースは関東に対する対抗心というかそういった心理が働くようで、実際にある話です。


次は、「自分でコントロールできる」ケース。

(自分でコントロールできる)
(スコープと適用技術と実現するシナリオ) (リソース) (時間)


これもいくつかに線引きできます。一つ目は、スコープと適用技術と実現するシナリオ。スコープを実現できる技術がなければ契約不履行になることこの上ないです。あと、どういう手段、段取りで実現するのか、そういった「こんな手順でやればいい」がないとそれもツライ。


二つ目は、リソース。それもおもに人的リソースの意味合いです。スコープを実現するために必要なスキルセットとスキルレベルを充足するメンバが一致しなければいけません。


三つ目は時間。スコープを実現する技術、リソースが確保できたとしても、現実的ないタイムボックスの中ではどんなに優秀なエンジニアが集まっても日の目を見ることは無理です。


都合、五つのカテゴリで基本的に起きたら困ることを考える。逆のケースも考える。ちょー楽観的に考えて案件が上手くいくとして、それを阻害するケースを考える。


これがリスクマネジメントの識別している、ってヤツです。