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