誤提出を防いだヒヤリハット報告票のひな形

このひな形を使う場面

ヒヤリハット報告は、誤りが起きそうになった状況と、どの確認で止まったかを学ぶための記録です。誰が注意不足だったかだけを結論にすると、同じ条件で再発する原因が残ります。事件情報の記載は調査に必要な範囲へ絞り、改善共有用には識別情報を省いた版を作ります。

以下はAILEX編集部による所内用の記入式ひな形です。裁判所指定の様式ではありません。空欄を推測で埋めず、確認できた内容と担当者の判断を分けて使います。

記入欄と使い方

転記して使う欄は「事例ID／発見日時／作業段階／起こりかけた事象／実際の影響／発見の契機／直前の条件／止めた対応／原因仮説／改善案／検証方法／共有範囲」です。各欄は一行一事項を基本とし、長い説明や添付資料は参照番号で対応させます。状態の欄には未着手、確認中、確認済み等の所内定義を付け、記入しただけで完了になる運用を避けてください。

架空の記入例

事例ID＝NM-002、発見＝10月10日、段階＝提出前のファイル選択、事象＝同一依頼者の別案件ファイルを選択しかけた、実際の影響＝送信前に停止、発見＝二次担当が所内番号を照合、条件＝似たファイル名が同じ作業領域にあった、対応＝対象一覧から再選択、仮説＝案件単位の領域分離が不十分、改善＝作業領域と命名を見直す、検証＝架空教材で再試行。

確認と差異への対応

送信前に止まったという事実も、操作履歴や担当者の確認に基づいて記載します。実際に外部へ送信された可能性がある場合は、単なる未遂の改善票だけで扱わず、所内の事故対応手順へ移します。原因は確定事実と仮説を分け、個人の記憶だけで技術的な不具合を断定しません。

保管と見直し

対策には実施担当と期限を付け、次の同種作業で効果を確認します。報告件数が増えたことを直ちに品質悪化とみなすと報告が抑制されるため、検知された段階や実害の有無も見ます。共有用の資料では当事者名、文書本文、認証情報を除き、工程上の問題を理解するために必要な情報に絞ります。