さらに回答者は、「私だけ、説教された。なぜ指示した人は知らない顔するのか、信じられなかった」と当時を振り返る。これは単純な操作ミスなのだろうか。問題は、スイッチを切った本人だけにあったのではない。誰が、どの設備を、どのタイミングで停止してよいのか。緊急時に誰が判断し、その判断に誰が責任を持つのか。そうしたルールが曖昧（あいまい）なまま現場が動けば、指示通りに操作した人が最後に責任を負うことになりかねない。情シスにとって怖いのは、正しい操作をしても、正しい結果になるとは限らない環境だ。

トラブル事例2：　削除コマンド1つで、他部署の環境まで消えた

　別の回答では、ログ容量不足への対応中に、過去ログを削除するつもりでコマンドを実行したところ、ログフォルダと同じ階層にあった他部署の環境まで削除してしまったという。

　コマンドの誤操作という意味では、典型的なヒューマンエラーに見える。だが、ここでも考えたいのは「もっと注意しましょう」で終わらせてよいのか、ということだ。例えば、本番環境での削除権限を誰が持っているのか。重要な操作に承認やダブルチェックは必要ないのか。削除対象を明示的に確認する手順はあるのか。人間が間違えることを前提に、間違えても被害が広がらない仕組みになっているか。この事例は、そんなことを考えさせられるケースだ。

トラブル事例3：　セキュリティ対策をしたら、社内ネットワークが止まった

　セキュリティ関連でも、胃が痛くなる事例があった。

　ある回答者は、社内で使用していた機器が外部へ定期的に情報を送信していることを把握。その通信を止めるため、ルーターのフィルタリング設定を変更した。ところが結果は、想定とは正反対だった。社内の全てのネットワークを使用できなくなった。

　セキュリティ対策そのものが間違っていたとは限らない。だが、本番環境への変更をどう検証するのか、影響範囲をどう限定するのか、問題が起きた際にどう切り戻すのか。こうした変更管理の仕組みがなければ、善意の対策であっても新たな障害を生み出してしまう。

トラブル事例4：　バックアップがない。そのとき全社員が徹夜した

　さらに深刻なのが、バックアップにまつわる事例だ。

　システムトラブルによって、当日の販売や仕入、受注の全データが消失した。バックアップが取られていなかったため、トラブル復旧後、全社員が徹夜でデータを再入力することになったという。

　回答者は当時について、「どこがトラブルの原因なのか全く不明で、全社からいつトラブル終了するのか、問い合わせが死ぬほど問い詰められた」と振り返る。バックアップは「取得しているか」だけではない。必要なときに、本当に戻せるのか。復元テストまでして初めて、バックアップは事業継続の仕組みになる。

トラブル事例5：　「前任者を呼ばないと直せない」システム

　今回の回答には、担当者のミスではなく、組織に蓄積された“過去のツケ”がトラブルオのきっかけとなったケースもあった。

　「古くて担当が居ないシステムが障害となり直せないと思った。過去の担当者（異動済）がなんとか思い出しながら復旧してくれた」担当者が異動、退職した途端に、誰も触れなくなるシステム。手順書がない。構成が分からない。なぜその設定になっているのかも分からない。こうしたブラックボックス化したシステムは、平常時には問題が表面化しなくても、障害が発生した瞬間に情シスを窮地へ追い込む。

　「ヒューマンエラー」ではなく「エラーしても止まらない仕組み」を今回の回答を横断して見ると、幾つかの事例には共通する構造がある。それは、1人の判断や操作に、大きな影響範囲が与えられていたことだ。もちろん、確認不足や操作ミスがトラブルの直接的なきっかけになることはある。だが、「人は間違える」という前提に立つなら、個人の注意力だけに頼る運用には限界がある。

　本番と開発環境を間違えない仕組み、重要操作を一人で完結させない仕組み、変更前に影響範囲を確認する仕組み、担当者がいなくても復旧できる仕組み、バックアップから実際に復元できる仕組み、緊急時に誰が判断するのかを決めておく仕組み。こうした「仕組み」があれば、同じヒヤリハットでも事故の規模を抑えられる可能性がある。

　逆に、こうした仕組みがなければ、次に同じ現場に立つのは別の担当者だとしても、同じ“地獄”が繰り返される。

　今回のアンケートで寄せられた声は、ただの「情シスの失敗談」ではない。自社のIT運用に、どこまで人が間違えることを織り込めているか。そのことを、あらためて考えさせられる事例だ。

　後編では、今回寄せられた回答から、「もう二度と同じ地獄を見ないために、情シスが実践している対策」に焦点を当てる。