1-5-2.リスク(U,V)への対処

上位ページ

はじめに

曖昧なことや不必要な複雑さは
「課題」でしたが、

不確実性や変動性は「リスク」です。

なので、リスクマネジメントの手法が使えます。
そして、リスクマネジメントの際には
フィードバックループを回すことが
必要不可欠です。

不確実性と変動性への対処方法

リスクへの対処は
リスクマネジメントと
フィードバックループですが、
この二つを実施する際に問題となる
対処が二つがあります。
それは

ゼロリスク志向
と
方向性が定まっていない場合への対処

です。
この二つがリスクの対処を誤らせます。

リスクマネジメントについて

リスクマネジメントで注意が必要なのは、
リスクマネジメント自体がまともに
実施されていない場合があることです。

正解病を患っている人が行う
リスクマネジメントは
実はリスクマネジメントではなく、
「ゼロリスク志向(リスクをなくす)」なんです。

正解病を患った人の発想は
結果は選択可能である
です。

でも実際は
結果は選べない
です。

リスクも思い通りに制御可能だ、
という前提のもとに対策を
決めてしまうことがあるんですね。

これは企業が行う労働災害の再発防止策が
そうだなーって思います。

リスクマネジメントの対策は
低減、回避、転嫁、受容(無視)
に分かれますが、

ゼロリスク志向の考えの人は
「受容(無視)」を選択しないんですね。

リスクマネジメントは
ブレインストーミングでリスク
を洗い出し、それぞれのリスクを評価し、
発生確率と発生時の影響をめあわせします。

優先度の高いものに対して
事前対策と事後対策を決めます。
いったん決めたらあとは
定期的に見直しを行う
ですね。

けっこう高度なんですが、
これを形式ばらずにやれるのが
一番大事なことだったりします。

なお、正解病の人は
受容力がないので
ブレインストーミングが苦手です。
詳しくは説明せず、イメージの提示だけにしておきます。

フィードバックループ

フィードバックループとは、
一連の作業を結果が出たら終わり、
とするのではなく
その結果を次に活かすことを指します。
一番単純な表現のフィードバックループは
以下です。

自動車の運転における
認知・判断・操作
もフィードバックループですね。

MITダニエル・キム教授が提唱する
成功循環モデルもフィードバックループです。

あとはPDCAサイクルが有名なんですが、
実は万能ではありません。

方向性が定まっていないのに
PDCAサイクルを無理やり適用しても
回らないです。

では、方向性が定まっていない時にはどうするか？
観察⇒状況判断⇒意思決定⇒実行の
OODAループを回します。

フローチャート的に表現するとこんな感じです。

ソフトウェア開発プロセスで例えると、
左側：ウォーターフォール
右側：アジャイル
と思えばわかりやすいかな。。
そしてこれは入れ子構造です。

経営陣は市場の状況を観察して状況判断し、
プロジェクトの実行を決定します(OODA)。

経営陣からPMに任命されたマネージャーは
アジャイルプロセス(OODA)で遂行する
プロジェクト計画(PDCA)を立てます。
そして、プロジェクトメンバーは
顧客のざっくりとした要求を実装して
フィードバックを得ながらどんどん形に
していきます。

そして、経営陣は実行の結果を観察し、
状況判断し、次のアクションを決めます。

最後にバランスを取る

不具合対応などのトラブルは
解消しきれない場合があります。

その時に大事なのが
原因特定と目的志向の使い分け
です。

原因特定とは
トラブルの原因を特定して、
その原因に対して対策を打って
根本治療を行うやり方です。

目的志向は
本来どうあるべきだったか？
と、理想の姿に目を向けてそちらに沿うような形を目指す

ですね。

原因特定一本だと、
不具合解決の糸口が見つからないときに
行き詰ります。
特に、人に原因を見出そうとすると
ドツボにはまります。
そうした場合は、
目的志向(本来どうあるべきなのか？)
に視点を切り替えます。

それでは、不確実性、変動性の
個別の対策について述べます。

不確実性への対処

不確実性への対処は、
正解病を克服することです。
それだと身もふたもないので詳細化すると、
まずは

視野が狭いことに気づくことです。

それから

全体を見渡すこと
不安を受け入れ、
変化を楽しむこと
です。

そのためには、
加点主義という考え方があることを
知るとよいと思います。

加点主義で最も良い成果を発揮した事例は
小惑星探査機：はやぶさの
エピソードが参考になります。

いくつもの「世界初」を成し遂げ、
ほぼ不可能と言われていた
ミッションを達成しました。

はやぶさはイノベーションだらけ
なんですけど、

イノベーションをイノベーションと
認知できない人には
イノベーションにうつりません。

減点法に毒されている自分たちに
気づくことが一番の不確実性への
対処なんです。

でも、今の日本は無駄削減を訴え
かえって無駄を発生させる
残念な人だらけなのが実情です。

変動性への対処

もうここまでくるとあとは
大したことがありません。

変動性への対処は、

変動要素の単位の特定
入力想定を行ったうえでの
同値分割(正常、異常の区分けなど)

ですね。
どんな項目が変動要素なのか？
をまず特定します。

例えば気温が変動要素ならば
単位は摂氏や華氏などですね。

そのうえでどのような範囲の温度を
取りうるのか想定します。

想定の範囲の下限と上限を設定して、
その範囲の間で動作することを検証します。

検証して問題があることがわかったら
是正するか、もしくは保証対象外にすることで
対処します。

まとめ

単純に説明しているので
理解するのは難しいかもしれませんが、
そもそも外部要因が絡む問題で
簡単なことなどありません。
なので、まずはきっちり課題に対応する
ことをお勧めします。

※上位ページへ戻る