市場クレームをリスクマネジメントに戻す——苦情処理フローとリスクファイル更新の設計

※本記事には広告・アフィリエイトリンクを含みます。

苦情は、集めた瞬間に価値が半分になる。

「クレーム受付シートに記入しました」で止まっている現場を何度も見てきた。日付、症状、対応者。埋まっているのはそこまでだ。

原因分析の欄は空白か、「経年劣化」の一言で終わっている。リスクファイルに至っては、誰も開いていない。

これは担当者がサボっているわけではない。苦情処理とリスクマネジメントをつなぐ「仕組み」が、そもそも設計されていないだけだ。

よくある失敗パターン

現場でよく見る形はだいたい3つに分かれる。

1つ目は「受付止まり」。苦情を受けて記録するが、原因分析や是正処置の欄はテンプレートにあるのに毎回埋まらない。

2つ目は「個別対応止まり」。その1件を修理・交換して終わり、同種の苦情が過去に何件あったか誰も集計していない。3件目が来て初めて「あれ、前もあったな」と気づく。

3つ目は「リスクファイル孤立」。設計時に作ったリスクマネジメントファイルが棚に眠ったまま、市場からの情報が一切反映されていない。監査で「市販後情報はリスクファイルにどう反映していますか」と聞かれて答えに詰まる。

これは、[個人差が品質差になる](/maintenance-quality-difference-machine-sound/)問題や、[属人化によるリスク](/medical-device-maintenance-solo-dependency-risk/)とも根が同じだ。情報が個人の頭の中で止まり、組織の記録として流れていない。

なぜこの問題が起きるのか

原因は3つある。

まず、苦情処理とリスクマネジメントが別の担当・別の書式で運用されていること。品質保証担当が苦情を受け、設計担当がリスクファイルを持っている。この2つの間に橋がない。

次に、「原因分析」の定義があいまいなこと。テンプレートに欄はあっても、「どこまで書けば分析と言えるか」の基準がない。担当者の経験値に依存してしまう。

最後に、集計の仕組みがないこと。1件ずつはファイルに記録されていても、月次・年次で傾向を見る場がない。同じ不具合が3件続いても、誰も横串で気づけない。

これは努力不足ではなく、情報設計の不在だ。[個人化された運用が残業を生む構造](/maintenance-personalization-overtime-cause/)と同じで、仕組みがないところに個人の頑張りだけが積み上がっている。

放置すると何が起きるか

まず品質面。同種の苦情が繰り返され、根本原因にたどり着けないまま対症療法を続けることになる。

次に工数面。苦情のたびに一から調査し直すため、対応時間が毎回長くなる。過去の類似事例が検索できないからだ。

引き継ぎ面でも影響が出る。担当者が変わると、過去の苦情の背景や判断の経緯がゼロから説明し直しになる。

顧客対応にも波及する。「前も同じことを言いましたよね」という顧客の声に、記録が追いつかない。[対応のばらつきが顧客からの信頼を損なうリスク](/maintenance-quality-variation-customer-request-risk/)は、苦情処理の場面でも同じように起きる。

改善のための判断基準

すべてをシステム化する必要はない。まず現状を仕分けることから始めたい。

手作業で十分な場合：月間の苦情件数が数件程度で、担当者が固定されており、口頭でも情報共有が回っている段階。この場合は記録様式の統一だけで十分なことが多い。

テンプレートで足りる場合：件数が増えてきて、原因分析や是正処置の記入漏れが目立ち始めた段階。苦情受付から原因分析、是正処置、リスクファイル反映までを1枚のフォーマットに固定すれば、抜け漏れはかなり減る。

ツール導入を検討すべき段階：拠点が複数ある、担当者の異動が頻繁、過去事例の検索や傾向分析が手作業では追いつかない場合。この段階では、記録の一元化と検索性を確保する仕組みが必要になる。

なお、苦情処理体制がISO 13485やQMS省令の要求事項に適合しているかどうかは、一般論だけでは判断できない。最終的な適合性の確認は、社内のQMS責任者や国内品質業務運営責任者に委ねる前提で進めたい。

今日からできる改善手順

Step 1：直近1年分の苦情記録を並べ、「原因分析」「是正処置」「リスクファイル反映」の欄がどこまで埋まっているかを確認する。空欄が多いなら、それが現状の実態だ。

Step 2：苦情記録とリスクファイルを1つのフォーマットでつなげる。苦情番号をリスクファイルの該当項目に記載する欄を追加するだけでも、情報の断絶はかなり減らせる。

Step 3：月次で苦情の傾向を見る場を設ける。件数だけでなく、原因の分類ごとに集計し、同種の苦情が繰り返されていないかを確認する。この場に設計担当も同席させることが、リスクファイル更新につながる一番の近道だ。

おすすめの次アクション

まずは苦情処理フローとリスクファイル更新をつなぐテンプレートを1つ作ることから始めたい。

苦情の再発が個人の対応品質に依存している場合は、[属人化を解消する視点の記事](/medical-device-maintenance-depersonalization/)も合わせて読んでおくと、仕組み全体の設計がしやすくなる。

拠点や担当者が増えて手作業の限界を感じ始めたら、記録の一元管理ツールの検討に進む段階だ。

よくある質問

苦情とインシデント（不具合報告）の違いは何ですか

苦情は顧客や現場からの申し出全般を指し、そのうち安全性に関わるものが不具合報告の対象になり得る。どこまでを不具合報告として扱うかは、社内の判断基準と該当する法令・ガイダンスに照らして薬事・品質責任者が確認する必要がある。

リスクファイルはどのくらいの頻度で更新すべきですか

一般的には市販後情報が入るたびに見直しの要否を検討する運用が望ましいとされる。ただし更新頻度や範囲は製品のリスクレベルや社内規定によって異なるため、QMS責任者の判断に委ねるべき事項だ。

苦情件数が少ない会社でもリスクファイルとの連結は必要ですか

件数の多寡にかかわらず、市場からの情報をリスクマネジメントに反映する仕組み自体は必要と考えられる。件数が少ないうちは手作業のテンプレートでも十分対応できることが多い。

是正処置とリスクファイル更新はどちらを先にやるべきですか

順序を固定するより、両者を同じ記録の中でセットで扱う設計の方が抜け漏れを防ぎやすい。原因分析の結果を是正処置とリスクファイルの両方に同時に反映する運用が現実的だ。

ツール紹介

苦情処理フローとリスクファイルの連結は、最初は紙やExcelのテンプレートでも十分に始められる。ただし件数や拠点が増えてくると、記録の検索性や履歴管理が手作業の限界を超えてくる。

QMS文書・記録管理ツール

苦情記録、是正処置、リスクファイルを一元管理し、変更履歴を自動で残せるQMS向けの文書管理ツールは、監査対応の負担を軽減する選択肢の一つになる。導入前には自社の運用フローに合うか、無料トライアルで確認しておきたい。

品質データ集計・分析ツール

苦情の傾向を月次・年次で可視化し、同種の不具合の再発を早期に検知するための集計ツールも検討に値する。表計算ソフトの延長で使えるものから、BIツールと連携できるものまで幅があるため、自社の件数規模に合わせて選ぶとよい。