※本記事には広告・アフィリエイトリンクを含みます。
「気をつけます」という言葉が、また会議で出た。
点検記録の承認欄が空白のまま次工程に流れていた。前回も同じことが起きた。担当者は謝り、管理職は「次から注意するように」と伝えた。
問題は注意量ではない。「見落とせる構造」になっていることだ。
「気をつけます」の翌日にまた起きる
私がいた現場では、こういう場面が定期的に繰り返されていた。
記録用紙の「確認者署名欄」が未記入のまま、そのファイルがキャビネットに収まっていた。だれかが気づいて戻すまで、3週間そのままだったこともある。
別の現場では、校正期限を過ぎた測定器が検査ラインで使われていた。担当者は「期限が来たら交換する」と認識していたが、その期限をだれも追いかけていなかった。
もう一つ。変更管理の文書に旧バージョンの仕様が残っていた。記入者は最新版のつもりだったが、参照元のExcelが更新されていなかった。
どれも「うっかり」ではある。だが、うっかりを引き起こしたのは仕組みの側だ。
なぜ精神論だけでは止まらないのか
人間は、確認しなくても先に進める状況では、確認を省く。
これは怠慢ではなく、認知の特性だ。忙しい状況で手順が多いほど、脳は「省略してよい手順」を無意識に選別する。そこに「空欄でも保存できるフォーム」「承認なしで進める運用」があれば、エラーは構造的に発生し続ける。
QMSの現場でよく見るのは、以下の3つの設計ミスだ。
入力を強制しない記録様式。 空欄でも完結できる設計は、記入漏れを恒常化させる。
フローが人の記憶に依存している。 「Aが終わったらBに回す」という手順が、口頭ルールや個人のメモでしか管理されていない。担当者が変わった瞬間にフローが止まる。
エラー発生後の対策が「注意喚起」だけ。 是正措置として「周知徹底」「再教育」を記録しても、次に同じ状況が来れば同じエラーが起きる。問題を起こした環境が変わっていないからだ。
→ 属人化した運用がどれだけ残業を生むかは、[こちらの記事](/maintenance-personalization-overtime-cause/)でも整理している。
放置すると何が崩れるか
エラーが繰り返されても「大事にならなかった」現場は多い。だからこそ、問題が静かに蓄積する。
一つ目は、記録の信頼性だ。空欄や転記ミスが慢性化した記録は、内部監査でも外部審査でも説明が難しくなる。「記録はある。でも内容が正しいかどうかわからない」という状態は、QMS運営上の大きなリスクと一般に考えられている。
二つ目は、引き継ぎコストだ。エラーの発生状況が担当者の頭の中にしかなければ、異動や退職のたびにノウハウが消える。新担当者が同じミスを経験してから学ぶサイクルが続く。
三つ目は、顧客・使用者への影響だ。医療機器の場合、品質上の問題が製品の信頼性に波及する可能性を否定できない。記録不備が発覚した段階で対応コストが跳ね上がることも、現場では繰り返し経験した。
→ 品質記録のばらつきが顧客対応にどう影響するかは、[この記事](/maintenance-quality-variation-customer-request-risk/)が参考になる。
仕組みで防ぐ——3つの設計アプローチ
ヒューマンエラーを構造的に減らすには、「エラーを起こせない設計」か「エラーを見逃さない設計」のどちらかに寄せる必要がある。
① 入力値の制限と必須化
紙帳票やExcelであれば、空欄を残せない様式設計にする。システムであれば、必須項目が未入力のまま次ページに進めないよう制御する。「書き忘れ」は、書けてしまう構造があるから起きる。
② 承認フローの二重化・可視化
「確認した」という事実を記録に残す構造にする。承認欄のある紙帳票なら署名を物理的に必要とする。システムなら承認アクションを完了しないと次工程に移行しない設計にする。承認をスキップできる経路をなくすことが目的だ。
③ チェックリストの強制化と記録化
口頭で確認している手順は、必ずリスト化して記録に残す。「やった」という記憶ではなく、「やったという証跡」が残る運用にする。特に手順が多い工程や、頻度が低くて忘れやすい作業に有効だ。
どこから始めるか——判断基準
全部を一度に変えようとすると止まる。優先順位をつけることが重要だ。
まだ手作業・口頭ルールでよい場合: 担当者が1〜2名で、手順が安定していて、記録の量も少ない。このレベルなら、様式の整備とダブルチェック運用で十分なケースが多い。
テンプレートと運用ルールで対応できる場合: チームが3〜10名規模で、手順の抜け漏れが散発的に起きている。チェックリストの標準化と承認フローの明文化で改善が見込める。
ツール・システム導入を検討すべき場合: 担当者の入れ替わりが多い、記録の量が多くて管理しきれない、同じエラーが繰り返し是正措置に上がってくる。このレベルになると、Excelや紙での管理には構造的な限界がある。
→ 一人担当者への依存リスクについては、[こちらの記事](/medical-device-maintenance-solo-dependency-risk/)も合わせて読んでほしい。
今日からできる改善3ステップ
Step 1:直近3か月のエラー・ヒヤリハットを洗い出す
是正措置報告書、不適合記録、口頭で処理されたトラブルを一覧にする。「どこで」「何を」「なぜ見落としたか」を並べると、エラーが集中している工程が見えてくる。
Step 2:エラーが起きた工程の「抜け道」を特定する
空欄のまま通過できる記録様式はないか。承認なしに進められるフローはないか。「こういう状況になると省略が起きる」という条件を洗い出す。1工程ずつ確認するだけでよい。
Step 3:1か所だけ「省略できない構造」にする
全体を変えなくていい。エラーが最も多い1か所に絞って、入力必須化・承認フロー追加・チェックリスト記録化のいずれかを入れる。1か月後に効果を確認し、次の1か所に移る。
おすすめの次アクション
まず自分の現場の記録様式を1枚手に取って、「空欄のまま承認が通せるか」を確認するところから始めてほしい。
それだけで、仕組みの穴が見え始める。
属人化した点検管理の全体像を見直したい場合は、[機器管理の属人化リスクをまとめたこちらの記事](/medical-device-maintenance-depersonalization/)が参考になる。機器の状態変化を見逃す現場の構造的な問題は、[こちら](/maintenance-quality-difference-machine-sound/)でも取り上げている。
—
よくある質問
「是正措置に『再教育』と書いてしまうのですが、何が問題ですか?」
再教育は「担当者の知識・意識を変える」アプローチだ。同じ担当者が同じ状況に置かれれば、同じエラーが起きる確率は下がらない。QMSで求められる是正措置は、一般に「根本原因への対処」とされている。エラーが起きた環境・手順・様式自体に手を入れることが、繰り返しを防ぐ上で有効だ。
「紙運用のままでも仕組み設計はできますか?」
できる。必須記入欄の追加、署名なしでは次工程に回せないルールの明文化、工程完了のスタンプや日付印の義務化など、紙でもエラーを起こしにくくする設計は実現できる。ただし、記録量が増えてきたり担当者が複数になってきたりすると、紙では管理の限界が早く来る。
「承認フローを増やすと、かえって作業が遅くなりませんか?」
遅くなることはある。ただ、「エラーが後工程で発覚して手戻りが発生するコスト」と比較する必要がある。承認のタイミングと内容を整理し、確認する項目を絞れば、負荷を最小化しながら機能させることは可能だ。すべての工程に二重承認を入れる必要はなく、リスクの高い工程に絞るのが現実的だ。
「QMS省令やISO 13485への対応として、どの程度の仕組みが必要ですか?」
規制要求の解釈と適合判断は、自社のQMS責任者や品質担当者が確認・判断する必要がある。一般に、リスクに応じた管理策と、その記録・根拠の維持が求められると考えられているが、具体的な要件への適合可否は監査対応も含めて専門家に確認してほしい。本記事は実務上の仕組み設計の考え方を示すものであり、規制解釈の根拠として用いることは想定していない。
—
ツール紹介
記録・承認フローのデジタル化に使えるツール
Googleフォームやkintoneのような入力フォームツールは、必須項目の設定・承認ステップの追加・記録の自動蓄積が比較的低コストで実現できる。Excelからの移行ステップとして選ばれるケースも多い。完全なQMS専用システムではないが、「入力を強制する」「フローを可視化する」という最初の目的には対応できることが多い。
導入前に、自社の規制要件への対応可否は品質担当者と確認しておくことを勧める。
チェックリスト管理・是正措置の記録に使えるツール
AsanaやNotionのようなタスク管理ツールは、チェックリストの記録・担当者の割り当て・完了の可視化に使える。是正措置の進捗管理に流用している現場も見てきた。専用QMSツールと比べると記録の形式に制約が出る場合もあるため、自社の文書管理要件と照らし合わせて判断してほしい。
この記事に関連するサービス・書籍
-
Google Workspace
Googleドライブ、ドキュメント、フォーム、スプレッドシートで、引き継ぎ書や手順書をチーム管理しやすい。紹介リンク経由で割引コードを利用できる場合があります。 -
小さな会社の〈人と組織を育てる〉業務マニュアルのつくり方
業務マニュアル作成の実践書。属人化解消の第一歩として最適。
※ 紹介リンク・アフィリエイトリンクを含みます


コメント