フィールドデータから設計変更を起票する——PMS情報を設計部門へ渡す責任分界と申請プロセスの標準化

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

# フィールドデータから設計変更を起票する——PMS情報を設計部門へ渡す責任分界と申請プロセスの標準化

現場で同じ故障が三件続いた。

修理担当者は気づいている。でも誰も設計変更申請を書いていない。

これは担当者の記録力の問題ではない。情報が設計部門に届く仕組みがないだけだ。

よくある失敗

現場では、こんな場面がよく起きる。

一つ目は「個人の気づきで止まる」パターンだ。ベテラン修理担当者が「この部品、また割れたな」と気づく。でもそれはメモ帳か頭の中にしか残らない。退職と同時に気づきも消える。

二つ目は「苦情記録と設計変更が別世界」になるパターンだ。苦情処理はQMS文書としてきちんと残る。だが、その記録が設計部門の変更管理プロセスに自動的につながる経路がない。苦情担当者は「報告した」と思っている。設計者は「見ていない」と言う。

三つ目は「件数がないと動かない」パターンだ。重大な不具合の兆候があっても、社内ルールが「月次集計で傾向が出たら検討」としているため、個別の違和感が埋もれる。

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

これは担当者の努力不足ではない。情報の受け渡し先が設計されていないことが原因だ。

多くの現場では、フィールドデータ(修理記録・苦情・保守点検での異常)の収集ルートと、設計変更申請(デザインチェンジリクエスト)のルートが別の文書体系として走っている。苦情処理担当、サービス部門、設計部門がそれぞれ別のフォーマットで記録を持っていると、情報は「存在するが、つながっていない」状態になる。

さらに、誰が「これは設計起票すべき事案だ」と判断する権限を持つのかが明文化されていないことも多い。判断基準がないと、個人の経験と勇気に頼ることになる。声の大きい人の案件だけが上がり、静かに積もる不具合は見過ごされる。

放置すると何が起きるか

この状態を放置すると、品質・業務・顧客対応の三方向に影響が広がる。

品質面では、同じ不具合が形を変えて繰り返される。設計側は「初めて聞いた」と言うが、現場では三年前から知られていた、という状況が起きる。

業務面では、同じ故障の修理対応に毎回時間がかかる。属人化した判断が解消されないまま、特定の担当者だけが「あの型番はこうなりやすい」と知っている状態が続く。

顧客対応面では、同じ説明を繰り返すうちに、担当者ごとに言い回しが変わる。対応のばらつきが顧客の不信につながる。

改善するための判断基準

すべてをシステム化する必要はない。まず判断基準を決めることが先だ。

まだ手作業でよい場合は、発生件数が少なく、かつ単一拠点で収集できている状態だ。この段階では、記録フォーマットを統一するだけで十分に機能する。

テンプレで十分な場合は、複数拠点から情報が上がってくるが、件数自体はまだ管理可能な範囲にある状態だ。ここでは「起票判断の閾値」を明文化したテンプレートを使う。例えば「同一不整合が二件以上」「安全性に関わる可能性がある場合は一件でも」といった基準をあらかじめ決めておく。

ツール導入を考える段階は、拠点数が多く、情報が複数部門をまたいで動く場合だ。この場合、エクセルや紙の運用では追跡漏れが発生しやすくなる。

今日できる改善手順

まず三つのステップから始める。

Step 1として、フィールドで気づいた不具合・改善要望を記録するフォーマットを一つに統一する。発生日、発生状況、再現性、関連する部品・ロットを必須項目にする。

Step 2として、「設計部門に引き渡すべきか」を判断する閾値を文書化する。件数基準と重大度基準の両方を用意し、どちらか一方に当たれば起票対象とする。

Step 3として、引き渡し後の承認フロー(誰が受け取り、誰が設計変更の可否を判断するか)を一枚の図にして、関係者全員が見える場所に置く。責任の所在が曖昧なままだと、情報は途中で止まる。

おすすめの次アクション

この仕組みは一度作れば終わりではない。運用しながら閾値を見直す前提で設計する。

まず自社の記録フォーマットと、既存のQMS文書(苦情処理手順・変更管理手順)がどこでつながっているかを棚卸しすることをおすすめする。機械音の違いのような現場の気づきも、記録に残す仕組みがあれば設計データになる。

また、属人化した判断基準を言語化する作業は、残業の個人差の問題とも根が同じだ。合わせて見直すと効果が大きい。

よくある質問

Q1. フィールドデータはどの時点で設計変更申請に値すると判断すべきですか

一般的には、件数基準(同一事象の再発回数)と重大度基準(安全性や性能への影響可能性)の両方を事前に定義し、どちらかに該当した時点で起票を検討する運用が多い。最終的な基準の妥当性は、品質保証部門や設計管理の責任者が確認する必要がある。

Q2. 修理担当者個人の気づきを、どうすれば仕組みの中に残せますか

記録フォーマットを簡潔にし、気づいた時点でその場で入力できる状態にすることが有効だ。後でまとめて書く運用は、記憶が薄れるため精度が落ちやすい。

Q3. 設計部門が「情報が来ていない」と言う状態をなくすには何が必要ですか

情報の受け渡し先と受け取り責任者を文書上で明確にすることが出発点になる。誰が受け取るかが決まっていないと、情報は宛先不明のまま止まる。

Q4. QMS省令やISO 13485との関係で、このプロセスはどう位置づければよいですか

フィールドデータから設計変更へのつながりは、一般的に市販後情報の活用や変更管理の文脈で扱われることが多い領域だ。具体的な適合性の判断は、自社のQMS責任者や薬事・品質の責任者が個別に確認する前提で進める必要がある。

関連するツールを探す

ここまでの仕組みを手作業とテンプレートだけで回すのは、拠点数が少ないうちは現実的だ。ただ、記録数が増え、複数部門をまたぐようになると、情報の追跡漏れが起きやすくなる。そうなった段階で、記録・申請・承認を一元管理できるツールの検討が現実的な選択肢になる。

変更管理・文書管理を支援するQMSツール

苦情記録から設計変更申請までを一つのワークフローで追跡できるQMS系ツールは、拠点をまたぐ情報の取り違えを減らすのに役立つ。導入検討時は、既存の記録フォーマットをそのまま移行できるかを確認するとよい。

現場記録のテンプレート集

フォーマット統一から始めたい場合は、まず既存のテンプレート集を参考にするのも手だ。ゼロから設計するより、実務で使われている項目構成を土台にする方が、現場への定着が早い。