はじめに
業務設計においてエラーハンドリングを盛り込むのは基本ですが、
実務においては、それをすり抜けるミスが発生してしまうのが現実です。
- 入力を間違える
- 更新対象を誤る
- 不要な行を削除する
- 手順を飛ばす
重要なのは、
ミスが起きたかどうか ではなく、
起きたあとに業務が止まってしまうこと です。
この回では
失敗したときに復旧できるか という点を判断軸として扱います。
1. 結論：戻せない仕組みは、業務では使い続けられない
「気をつける」「注意する」「確認を増やす」。
これらは事故防止策ではありますが、
事故対応策ではありません。
業務では、ミスが起きたあとにどうなるかが全てです。
2. Excel運用が事故に弱い理由
Excelが問題になるのは、
計算ができないからでも、遅いからでもありません。
事故が起きたとき、
- どこを間違えたか分からない
- どの状態が正しいか分からない
- 部分的に戻せない
- ファイル全体を巻き戻すしかない
つまり
回復手段が「ファイル単位」しかない ことが問題です。
3. 「バックアップがある」は日常リカバリにならない
よくある安心材料がこれです。
毎日バックアップを取っている
しかし実務では、
- 昨日に戻すと、今日の正しい作業も消える
- どこまで戻すのが正解か分からない
- 他の人の作業を巻き込む
バックアップは
非常用の復旧手段 であって、
日常的な事故対応手段ではありません。
4. 業務で本当に必要なのは「差分単位の回復」
業務で求められるのは、
- 何が
- いつ
- どう変わって
- どこが誤りだったか
を特定し、
- その変更だけを無かったことにできる
ことです。
これができない仕組みでは、
ミス1件で業務全体が止まりかねません。
5. リカバリ可能な構造の基本
リカバリできる仕組みには、共通点があります。
- 変更前の状態が残っている
- 変更の履歴が積み上がる
- 元に戻す操作が想定されている
考え方は単純です。
- 「今の状態」を持つデータ
- 「変化」を記録するデータ
を分けること。
6. 設計イメージ（リカバリ前提）
-- 主テーブル
-- 「今の正しい状態」だけを持つ
主テーブル：orders
order_id -- 業務上の識別子（主キー）
amount -- 現在の金額
status -- 現在の状態
updated_at -- 現在状態の最終更新日時（最新のみ）
-- 履歴テーブル
-- 「変更の事実」をすべて積み上げて残す
履歴テーブル：order_change_log
log_id -- ログID（主キー）
order_id -- 主テーブルとの紐づけ
changed_at -- 変更が行われた日時
field_name -- 変更された項目名（例：amount）
old_value -- 変更前の値
new_value -- 変更後の値
この構造があるだけで、
- 誤った変更を特定できる
- 変更前の値に戻せる
- 他の正しい変更に影響しない
戻せるかどうかの差 が生まれます。
7. リカバリできない仕組みが現場に与える影響
回復できない仕組みでは、現場でこうなります。
- ミスを報告しづらくなる
- こっそり直そうとして被害が広がる
- 作業が止まる
- 特定の人しか触れなくなる
結果として、
「触らないのが一番安全」
という、
業務が萎縮する状態 が生まれます。
8. 結論：事故は避けられない、戻せるかが分かれ目
- ミスは起きる
- 事故は避けられない
- だからこそ回復手段が必要
判断軸はこれです。
失敗したとき、業務を止めずに元に戻せるか？