障害、不祥事なにかと良くないことがあった際に謝罪と共に使われる使われる言葉
『原因を究明し再発防止に努めていきます。』
最近、聞くだけでめまいがするようになってきました。
ここからはSEの人為的ミスによる障害を想定して書きます。
システム障害の大半は人が何らかの手を加えた時に発生する。そうであれば、システムに手を加えなければ良いのではないか?当然、そう言うわけにもいかない。電子機器であるハードウェアは寿命が短いし、ソフトウェアはすぐに時代遅れになってしまう。システムがシステムとしての機能を維持し続けるには、常に人手による変更を加えながら運用していく必要がある。当然、人のやる作業なのでミスが発生する危険が至るとこに存在する。
用意した手順の通りに作業を実施しなかった。別の方法でも結果が同じだと思った。(やろうと思ったことが違った:ミステイク)
用意した手順の通りに作業を実施したつもりだった。しかし、結果的にできてなかった。(思ったような操作がてきてなかった、手がすべった:スリップ)
用意した手順を飛ばして実施した。実施し忘れた。(実施内容の漏れ)
用意した手順で作業が開始できなかった。(前提条件が違った、現状の調査不足)
設計時に正しい設計方針を理解できてなく、結果的にデタラメな設計だった。(やろうと思ったことが違った:ミステイク)
設計時に正しい値を記入できていなかった。転記したつもりだが実際は別の値が書き込まれてた。(思ったような操作がてきてなかった、手がすべった:スリップ)
設計時に設計対象箇所が足りてなかった。(実施内容の漏れ)
設計時に設計した値がすでに別用途で使われていた。(前提条件が違った、現状の調査不足)
ここでは、作業実行時と設計時のふたつの工程と、4つの失敗モードで例を考えてみた。
こんなイメージで、あらゆる工程でいろいろな失敗モードが発生する。
『そんな馬鹿な』
と思うかもしれない。
それでも実際に仕事と言う普段と違う精神状態の中では日常茶飯事である。
いずれにしても1人でやると絶対間違える(人間なので)。なので、2人で確認する。
それでも失敗したら・・・
3人で確認する?
それだと、コスト(人件費)に対して得られる効果が薄い。
人を責めずに仕組みを責めろと言うセオリーがあるというので、仕組化を行う?
作業のタスクリストや手順、チェックリストを整備することになるが、細かく具体的に書くと、ボリュームが増える割に、ピンポイントでの対策となり効率が悪い。すぐに類似の失敗が発生する。
逆に幅を持たせて抽象的に書くと、一部のメンバーが内容が理解できずチェックできなかったり、読み飛ばしたりしてこちらの場合でもすぐに類似の失敗が発生する。
そして失敗が発生する度に再発防止を考える。
仕組みの作り込みがある一定ラインに到達すると、再発防止を検討した結果、得られるものが非効率性だけに収束してしまうのかもしれない。
それでも、SEは失敗を振り返り再発防止策をたてなければならない。
それは答えの無い永遠の課題とも思える再発防止に取り組み、傷ついて、疲弊して、その結果でようやく仕組みの重要さや注意深さ、失敗の予感の感度が身に付くのだから。
あえて鋼の錬金術師から言葉を借りよう
『痛みを伴わない教訓には意義がない。人は何かの犠牲なしには何も得ることはできないのだから。』
人類はまだ痛みを伴わずに、自分のこととして教訓を得られる境地には到達できていないのではないかと思う。
※コメント投稿者のブログIDはブログ作成者のみに通知されます