リスクマネジメントとしての判断保留と、先送り

見た目は同じですが、全く異なるのがこれです。

リスクマネジメントとしての「判断保留」
責任回避としての「先送り」

今決めたくて心がざわついている時。
慌てそうなところを、判断保留するのは、リスクマネジメントです。
これは慌てているときは正常な判断能力を失っており、間違う可能性が極めて高いためです。
ITシステムのお守りをしていると、急にエラーや障害が発生して慌てることはしばしばあります。
こんな時にあらかじめ想定していた事象で無かった場合は、各必要な連絡先に連絡の上、何か変更をした直後ならその変更を元に戻す。障害箇所が限定されているなら、そこを良く理解している人や組織に解析を依頼する。
全般的におかしいのなら、いっそのことその処理過程全体を止める判断が必要になります。

これらのプロセスも、あらかじめ検討しておいたものを使い、想定外が発生した場合のプロセスも決めておきます。
その場の思いつきで操作をしてはいけません。
大体に於いてさらなる悲劇、二重障害、を呼びます。

あらかじめ想定された対応を取る、想定外の場合はどうするのか。
その基準は、お客様の業務にとって「Fail Safe」かどうかです。
決して自分の立場にとっての「Fail Safe」ではありません。
あくまでもお客様の業務にとって、どうかが基準です。

すなわち「最悪の事態であっても、最低限の機能を維持してお客様にご迷惑が掛かるのを最小限にする。」事が大事です。
エンジニアであれば原因究明を優先したくなりますが、本番系の場合は実務優先で、お客様への影響を最小限に食い止めることが優先です。

もちろん後日の解析の手がかりとして、ログや状況のバックアップが出来ればそれに越したことはありません。それでも、時限処理があるものなど、そのような悠長なことが許されない場合もあります。
その時は、お客様への影響度を最小限にするのが第一原則となります。
これがリスクマネジメントしての考え方です。

誰のリスクを最小限とするべきなのか。

これを定義しないで始めるリスクマネジメントは、ありえません。

ところが事象が発生したその時に、判断保留して「なにか安心してしまった場合」は、それは今、決めなければならない時です。
そのような「なにか安心してしまった場合」の判断保留は、リスクマネジメントではありません。
それは責任回避のための「先送り」です。
単なる自己保身に過ぎない場合がそうなります。

「お客様にとっての実害を最小限にするにはどうするべきか。」

これを忘れたところに、問題の「先送り」が発生します。

自分の心とは、概ね逆の行為が求められるのが、リスクマネジメントの現場の難しい所です。