ざっくり言うと
事故が起きたら、まず手を止めてください。慌てて直そうとするほど、戻せたはずのものまで戻せなくなります。
順番はこの4つです。
- 止める
- 記録する
- 戻す
- 共有する
この順に進めれば大丈夫です。
事故の直後は、とにかく早く元どおりにしたくなりますよね。でも、何が起きたか分からないまま操作を重ねると、上書きが上書きを呼びます。
最初に知りたいのは、細かい原因ではありません。どこまで影響が届いたかです。次の4つだけ分けてください。
- まだ動いている操作はないか
- 消えた、または変わったかもしれない場所はどこか
- 外へ出てしまった情報はないか
- 戻せそうな控えは残っているか
イメージ
正確には
事故の種類によって、最初の一手は変わります。
| 起きたこと | 最初にやること |
|---|---|
| ファイルを消した | 手を止めて、バックアップや履歴に控えが残っていないか探す |
| 上書きしてしまった | 変更前と変更後を見比べられる場所を探す |
| パスワードやAPIキーを貼った | そのパスワードやキーを使えなくして、新しく作り直す |
| 外から見える場所へパスワードや顧客情報を上げた | 消すだけで終わらせない。パスワードやキーは作り直し、顧客情報はまず責任者や情報管理担当へ必要最小限を共有する。顧客や取引先への連絡は、組織の事故対応手順に従う |
| 本番のサイトを壊した | 触るのをやめて、バックアップから戻す手順を確かめる |
| 外部へ送ってしまった | 送り先、送った中身、伝えるべき相手を書き出す |
戻す作業へ入る前に、まず何が起きたかを短く書き留めてください。書き留め方は、後ろの「事故メモは5行で足りる」で説明するとおりで十分です。
戻す先はどこにあるか
戻せる控えは、たいてい次の3つのどれかにあります。
- 作業前に自分でコピーしたフォルダ
- クラウドのバージョン履歴
- 共有フォルダやUSBに置いた別のコピー
それぞれの作り方は消える事故を防ぐバックアップと履歴の基本で説明しています。事故のあとに読むより、落ち着いているうちに1つ用意しておくほうがずっと楽です。
控えが見つかっても、いきなり上書きで戻さないでください。まず今の状態を別名でコピーして残します。戻す作業に失敗しても、そこからやり直せます。
自分でプログラムを書く人で、作業前にGitで記録していたなら、そこまで戻すのが一番早い道です。
パスワードの事故は、消すだけでは終わらない
AIへの頼み方を切り替える
危ないのは、「全部直して」「元に戻して」とだけ伝えることです。何が起きたか分からないまま、AIが新しい操作を重ねてしまいます。
安全なのは、まだ手を動かさせないことです。「まだ実行しないでください。削除、上書き、外部への送信、公開のどれが起きた可能性があるか整理してください」と頼みましょう。
注意点
事故のときにやりがちで、あとから困ることが5つあります。
- 原因を見ないまま、AIに何度も修正を頼む
- 変更の履歴を消す
- エラーの画面を閉じる
- パスワードや顧客情報の事故を黙っている
- 本番のサイトを直接いじり続ける
どれも「早く終わらせたい」気持ちから出てきます。だからこそ、先に手を止める順番が効くわけです。
事故メモは5行で足りる
早めに共有すると傷が浅い
最後は共有です。一人で抱えるほど、対応は遅れます。顧客の情報や取引先のデータが絡むときは、隠さずに早く伝えたほうが、結果として傷は浅く済みます。
伝えるのは、いつ、何が起きて、いま何を止めているか。この3つで足ります。原因の説明はあとからで大丈夫です。
やってみよう
そのうえで、次の6つを上から確かめていきましょう。手元にコピーして貼っておくと、いざというときに迷いません。
- いま動いている操作を止める
- 変わったかもしれない場所をメモする
- 消したり上書きしたりする前に、控えと変更前の状態を見る
- パスワードやAPIキーの事故なら、消すより先に使えなくする
- いまは触らない場所を決める
- 相談する相手と、伝える先を決める
事故対応で効くのは、速さより順番です。止める、記録する、戻す、共有する。この4つを守るほど、戻せる可能性は高くなります。