ヒューマンエラーを防ぐには？
スポンサーリンク
ヒューマンエラーとは
人間が原因となって生じるミスの事で、
JIS Z 8115:2000では、「意図しない結果を生じる人間の行為」と定義されています。
このヒューマンエラーの裏には、人がその行動をとった原因が存在します。
人がなぜ、その判断に至ったか、根本原因はデザインや認知科学の面から考察できそうです。
私の会社の業務
会社の業務で、私が携わるwebシステムには、以下の3つの環境(URL)が存在します。
①社外のお客様、及び社内の数百人のユーザーがほとんど日常的に操作している本番環境
②一部の社員が検証用に操作可能な本番前環境
③開発者が開発中の開発環境
通常、③開発環境で開発したデータのまとまりを、②本番前環境に配信してシステムを検証します。
そこでバグがあれば、③開発環境でデータの修正を行い、再び②本番前環境に配信します。
データのバグを修正し、品質的に問題ないようであれば、②本番前環境のデータを①本番環境に配信します。
さて、この配信ですが、②から①への配信は、ユーザーがいないシステムの稼働時間外にしなければなりません。
配信の作業上、システムが一旦停止するためです。
その際、システムにログイン中のユーザーは、強制的にログアウトします。
私の会社では、この②から①への配信業務を深夜に行っています。
対して、③から②の配信では、使用状況もかなり異なることから、日中に配信業務を行います。
実際に使われるデータが動くのではなく、会社の業務に直接影響を与えないためです。
更に、②の環境を使用するユーザーはほとんどおらず、使用するユーザーも限られています。
事前に関係者に連絡をして、〇時から〇時までシステムを停止する旨を伝えることも簡単にできます。
体験談
さて、ここからが体験談です。
新入社員と呼ばれていたある日の昼下がり、上記の③開発環境から②本番前環境への配信を行っていました。
既に何度か行ったこともあり、数ある作業内容もほとんど把握していました。
基本的には、ファイルを移動するような操作をスクリプトで行っています。
手順書に沿ってPCの画面上を操作していると、、、見慣れないエラーの文字が！
よくよく確認してみると、②から①へ配信するためのスクリプトが動いています。
そして、部内に鳴り響く電話・・・システムを止めてしまいました。。。
すぐに、スクリプトが行った内容と実行した時間を確認し、復旧作業を行いました。
結果として、30分ほどで対応が完了し、システムを復旧することができました。
顛末報告も終え、その後はかなり注意して作業するようになりました。
同様の事を繰り返さないために、このヒューマンエラーの原因を探り、対応策を練ってすぐに実用しました。
考えられるエラーの原因
確認不足
手順書の中には、確認をする手順の記載がありません。
手順書通りに進めればよいはずでしたが、作業者の判断が入る部分もあったようです。
更に、問題なく実施できていた実績があったことから、私の中にも「慣れ」がありました。
注意不足
上記の慣れにより、注意力が散漫になっていました。
対策した内容
システムによる事前確認
スクリプトを実行する前に、実行するか否か確認するフェーズを設けました。
具体的には、コマンド実行後、スクリプトを実行するか否か尋ねるようにシステムを変更しました。
これまでは、コマンドを実行すると有無を言わさずスクリプトが実行されていました。
改めて尋ねられることで、より意識して作業ができるようになりました。
見た目ですぐに気づく工夫
操作する画面は、いずれの配信も酷似した見た目でした。
配信先のサーバー名が異なるのみで、ぱっと見ではどちらの配信用の画面なのか分かりづらいです。
そこで、③から②の作業場所と、②から①の作業場所とで画面の背景色を変更しました。
これにより、今表示している画面がどちらの作業画面か、すぐに判別できるようになりました。
以下のような、文字の分かりにくさも原因となり得るため、取り除きたいですね。
その後は、現在に至るまで、同様のミスはありません。
上記対策が活かされているとは思いますが、他の業務でもヒューマンエラーが起こりそうな箇所を見直したいものです。
