本番作業でヒヤリハット事例を起こしてしまったので、自分への戒めも兼ねて記事化します。
反面教師になれば幸いです。
守秘義務があるので、詳細な内容は書かず、一般論だけ書きます。
なお、このヒヤリハット事例については、既に対策（再発防止策）を策定しています。
【事例の内容】
開発者（私）は、本番環境でのテストを作業指示書でオペレータに作業指示を出すことで実施した。
作業指示書には、作業手順書と、作業時に使用するスクリプトが含まれているが、このスクリプトに誤った処理が記述されており、本番運用で必要なファイルが意図せず消えるようになっていた。
オペレータがスクリプトの誤りに気付き、訂正したことで、障害とはならなかった。
【作業ミスが発生した理由】
スクリプトは本番運用で使われているものを改変して作成したが、改変漏れがあった。
改変を手作業で実施していたため、作業が漏れてしまった。
【作業ミスを事前に発見できなかった理由】
開発環境で手順のリハーサルを実施していたが、作業開始から作業終了までの作業を通して実施していなかった。
スクリプト以外は過去に実績のある手順であるため、実績のないスクリプトのみ単独で動かしてリハーサルとしていた（処理が動くことのみを確認していた）。
後作業として本番運用で必要なファイルを使用する手順が存在していたが、通しでリハーサルを実施しておらずその手順をリハーサル時に飛ばしていたため、作業ミスに気付くことができなかった。
【類似の作業ミスの分析】
他のメンバーも本番環境での作業で類似の作業ミスを起こしていたため、チーム全体で分析を行った。
今回の事例では「作業ミスが発生した理由」として手作業でスクリプトを作成したことを挙げているが、類似の事例には当てはまらなかったり、当てはまったとしても対策が困難であったりした。
それに対して、「作業ミスを事前に発見できなかった理由」として挙げた「通しのリハーサルの未実施」は類似の事例にも概ね当てはまっており、本番環境で作業ミスを起こす主因として判断できるものであった。通しのリハーサルを実施することと、実施されたことを確認する仕組みを作ることで対策となるため、対策も比較的立てやすかった。
