再発防止の鍵は「当たり前」を疑うこと
～ フィッシュボーン図で真因をあぶり出せ ～
報告書を「整える」のではなく、現場に潜む「管理の欠陥」を特定しましょう。
分析の起点となる「事象の特定」が、改善の成否を分かちます。
1. 分析の原点は「3現主義」にあり
分析を始める前に、テンプレートを埋める作業に走ってはいけません。基本は「現場・現物・現象（実）」の3つの“現”を重視することです。
現場に行く
事故が起きた実際の作業環境を確認します。机の配置や周囲の騒音、導線に無理はありませんか？
現物を見る
ログ、設定ファイル、誤送信されたメールの実物など、加工されていない客観的な証拠を確認します。
現象を直視する
担当者の思い込みを排除し、実際に何が起きたのかという「事実」のみを時系列で整理します。
管理者の「こうなんだと思う」は排除する！
分析において最も危険なのは、現場を見ずに管理者が想像で書く「おそらく〜だろう」「うっかりしたのだと思う」という推測です。
「想像（Guess）」で埋めた報告書は、的外れな対策を生み、必ず事故を再発させます。 徹底して「事実（Fact）」だけを積み上げてください。
2. フィッシュボーンで「真因の候補」を絞り込む
再発事故が起きてしまうのは、前回の分析で「真因」が特定されず、的外れな是正が行われた証拠です。
事故報告書には「なぜなぜ分析」は1つしか書けませんが、その前にフィッシュボーンで原因を網羅的に洗い出し、最重要なポイントを特定する工程が絶対に必要です。
分析のブレを防ぐ手順
- 1 要因の列挙：4Mの切り口で、ミスの可能性を自由に書き出す。
- 2 重要度の判定：「これがなければ事故は起きなかった」という最重要ポイントに印をつける。
- 3 分析対象の固定：選んだ最重要ポイントを「なぜなぜ分析」の1問目に据える。
3. 「なぜなぜ分析」でシステムの欠陥を突く
重要なのは、「個人」を責めるのではなく「仕組み」を責めるという姿勢です。
「言い訳」を「分析」に変換しよう
なぜなぜ分析の回答に「忙しかったから」「知らなかったから」といった状況説明（個人の感想）を書いても再発は防げません。
「なぜ、その状況でミスを防ぐことができなかったのか？」という仕組みの不備に翻訳してください。
| 言い訳（NG：個人の感想） | 客観的分析（OK：仕組みの不備） |
|---|---|
| 「電話対応で忙しくて、忘れていた」 | 「高負荷時に業務を失念しないためのリマインド機能や、他者へのエスカレーションルールがなかった」 |
| 「ルールが周知されていなかった」 | 「改訂されたルールを担当者が確認したことを証明する、強制的な周知・承認フローが整備されていなかった」 |
| 「慣れない作業でミスをした」 | 「未経験者でも確実に作業を遂行できる、ナビゲート付きの手順書やシステムガード（誤入力防止）が導入されていなかった」 |
なぜ1
1人で大量の宛先を手動入力していた
なぜ2
システムに一括送信機能がなく、手順も未整備
Root Cause
改善のリソースが割り当てられていなかった（管理の欠陥）
過去の事例では、外部要因と思われていた事故の約70%が、実は「内部の不備や手作業への過度な依存」に起因していたというデータもあります。
引用元：JIPDEC（一般財団法人日本情報経済社会推進協会）
「ISMS認証取得組織における情報セキュリティ事象の分析報告書」
4. 分析の精度を高める「逆順チェック」
根本原因から事象まで、「だから（結果として）」という接続詞で逆に読んでみてください。
※論理がつながらない場合、その分析には「飛躍」や「思い込み」が含まれています。
4. 「分析・原因・対策」を一本の線で繋ぐ
「なぜなぜ分析」の結果と「是正対策」が乖離していませんか？
分析の最後に出た答えが、そのまま対策の裏返しになっているか確認してください。
なぜなぜ分析の終着点
特定された原因
是正対策
一致していない例：
分析の最後が「人員不足（リソース不備）」なのに、対策が「手順の再教育」になっている。これでは真因が放置されているため、確実に再発します。
事務局からのアドバイス
「体裁を整えただけ」の報告書は、真因を見落とし、将来の重大事故を招く「技術的負債」となります。事実を正しく把握し、リスクを隠さないことが何より重要です。
特に同種の事故が再発している場合、既存の対策や常識は通用していないと認識すべきです。フィッシュボーン図を用いた徹底的な要因分析を行い、これまでの「当たり前」に潜む構造的な欠陥をあぶり出してください。