ヒューマンエラー対策を事務作業に取り入れる｜入力・確認・受け渡しの見直し例

こんにちは。バナナデスクです。

「次から気をつけます」で終えたのに、また取消済みの人へ案内を送ってしまう。同じミスが続く時は、注意する人を増やす前に、送信対象をどう作っているかを見たいところです。

たとえば、受付台帳には取消が反映されていても、昨日作った送信リストを使えば間違いは起きます。この場合、入力担当の集中力だけを問題にしても、受け渡しの古い情報は残ります。

今回は架空の講座受付を使い、事務業務のヒューマンエラー対策を考えます。事故や医療などの安全業務を扱う手順ではなく、記録と案内の小さな工程を見直す例です。

執筆：バナナデスク｜WEBビジネスの設計・集客・改善

「誰がミスしたか」から「どこでずれたか」へ戻す

英国HSEの人の失敗に関する解説は、誤操作や抜けと、判断の誤りを区別し、作業の設計や負荷などの条件にも目を向けています。安全分野の資料ですが、ここでは「本人の注意不足だけで説明を止めない」という考え方を、一般事務の例へ限定して使います。

画面の隣の行を選んだのか、取消の意味を知らなかったのか、正しい台帳から古いリストへ移したのか。表面の結果が同じ誤送信でも、直す場所は異なります。

点検する架空の受付記録8件

講座Aは一人一登録、連絡先が一致する再送は内容も照合して重複判定する想定です。以下は検証用に作った記録で、実在する連絡先へ送信しません。

誤った旧リストが「有効6件と取消済みR04の計7件を送信対象」としている状況を置きます。このままでは重複、取消、連絡先不足が混ざります。文字列がメールらしい形でも、実際に受信できることまでは保証できません。

見つけた不整合と、直す工程を対応させる

修正後の送信候補はR01、R02、R06、R08の4件です。R03は重複、R04は取消、R05とR07は保留として、記録自体は残します。「不要な行を消す」処理では、なぜ対象外になったのかを追えません。

この見本では、修正前後の検証用データを作り、ID集合と件数の照合を行っています。実際のメール送信、受信確認、利用者への聞き取りは行っていません。4件が正しく選べたことは、この定義とこの8件についての確認です。

対策を三つの役割に分ける

全部をチェックリストへ足すと、確認欄だけが増えます。重複しやすい転記を減らせるなら、まず工程を減らす。機械で照合できるIDや件数は計算に任せ、判断が必要な例外へ人の確認を残すようにします。

受け渡しに、版と抽出時刻を付ける

送信候補：講座A_10月21日18時抽出。参照：受付台帳の同時刻の状態。候補ID：R01、R02、R06、R08、計4件。除外：R03重複、R04取消、R05連絡先不足、R07参加条件確認中。抽出後に取消・変更が届いた場合は、送信前に候補を作り直す。

「最新版です」という名前だけより、いつの条件で作ったかが分かります。送り手と受け手が同じ人でも、作業を中断した後に古い情報へ戻る可能性があるため、記録は役立ちます。

対策後は、同じ間違いを見つけられるか確かめる

導入前に、重複・取消・必須不足を含むテスト記録を使って、期待する対象が出るか確認します。正常な記録まで全部止まる仕組みでは、現場で回避されやすくなります。通常の4件が進み、対象外4件が理由付きで止まることを両方確かめます。

運用後の記録には、ミスの件数だけでなく、処理した総件数、発見した段階、誤送信へ至ったかを残します。発見数が増えた時は、悪化した可能性も、以前は見えなかった不整合を見つけられるようになった可能性もあります。

この例から「ミスがゼロになる」とは言えません。まず一つの間違いを、入力・判断・受け渡しのどこで防ぎ、どこで見つけるかまで具体化する。その単位で工程を改善していきましょう。

関連記事：メルマガ配信前チェックリスト｜リンク・差し込み・宛先を確認する記録例