設計変更が現場に届かない——QMSに組み込む変更管理フローの実務設計

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

設計変更は、承認された瞬間に終わらない。

私がいた現場では、設計部門が変更を出してから半年経っても、点検手順書は旧バージョンのままだった。技術者は毎日その手順書を見て作業していた。誰も気づいていなかった。

図面は変わった。承認印も押された。でも、現場の棚にあるファイルは古いままだった。

これは担当者の意識が低いからではない。変更を「決定した後、現場まで届ける仕組み」がなかっただけだ。

よくある失敗

設計変更の管理でつまずくパターンは、だいたい決まっている。

1つ目は、変更履歴が設計部門の中だけで完結しているケースだ。設計変更管理システムには記録が残っている。でも、保守・修理を担当する部門には通知が飛ばない仕組みになっている。

2つ目は、変更の「反映範囲」が曖昧なままリリースされるケースだ。部品の仕様が変わったとき、点検手順・交換部品リスト・トレーニング資料のどれを直すべきか、誰も一覧化していない。結果として、点検手順だけ直して、部品リストは古いままになる。

3つ目は、緊急変更の記録が後回しになるケースだ。不具合対応で急いで設計を変えたとき、「とりあえず現場には電話で伝えた」で終わってしまう。QMS上の変更記録が、実際の変更より数週間遅れて作られる。

どれも、うちの現場でも起きていることだ、と感じた経営者は少なくないはずだ。

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

原因は、担当者の注意力ではない。変更情報の「置き場所」と「届け先」が設計されていないことだ。

多くの現場では、設計変更管理は設計部門の業務フローとして完結している。承認プロセス、記録、版管理――ここまではしっかりしている組織も多い。

問題は、その先だ。承認された変更を、保守・修理・トレーニング・顧客対応の各部門にどう「展開」するかというルートが決まっていない。

QMSの文書体系上、変更管理手順書は存在していても、「誰が」「いつまでに」「どの部門へ」通知するかという運用ルールが書かれていないケースが多い。手順書にルールがなければ、現場は個人の判断で動く。忙しい担当者が優先順位を間違えれば、そこで情報は止まる。

つまり、これは仕組みの穴であって、個人の怠慢ではない。同じ構造の問題は、[担当者ごとに手順がばらつく現象](/maintenance-personalization-overtime-cause/)にも見られる。情報が個人の頭の中にしかない状態は、変更管理でも点検業務でも同じリスクを生む。

放置すると何が起きるか

変更情報が現場に届かないまま業務が続くと、影響は段階的に広がる。

最初に出るのは、点検・修理の品質のばらつきだ。旧手順を使う技術者と、たまたま新しい情報を知っていた技術者とで、作業結果が変わる。この現象は[機械音の違いから見える品質差](/maintenance-quality-difference-machine-sound/)にも通じる。同じ機種でも、扱う人の情報量で仕上がりが変わってしまう。

次に出るのが、残業と引き継ぎの負荷だ。新しく入った担当者が旧手順書を正として学習してしまうと、後で全部やり直しになる。教える側も「どれが最新か」を確認する手間が増える。

さらに進むと、顧客対応にも影響が出る。顧客から仕様に関する問い合わせが来たとき、担当者ごとに答えが違う。これは[顧客対応のばらつきが引き起こすリスク](/maintenance-quality-variation-customer-request-risk/)と同じ構造だ。

最終的には、監査や内部点検の場面で「変更記録はあるが、現場への展開記録がない」という指摘につながりやすい。これは一般に、QMS運用の実効性そのものを問われる論点になり得る。適合するかどうかの判断は、最終的にQMS責任者や薬事・品質責任者が確認すべき事項であり、本記事では断定しない。

改善するための判断基準

すべての変更管理をシステム化する必要はない。組織の規模と変更頻度に応じて、判断基準を分けるべきだ。

手作業のメールと台帳管理でも回るケースは、変更件数が少なく、関係部門が数人規模で、口頭確認がすぐ取れる組織だ。ただしこの場合でも、「誰が受け取り、いつ現場に反映したか」を記録に残す運用は必須になる。

テンプレートで十分なケースは、変更の種類がある程度パターン化されている組織だ。変更通知テンプレート、反映先チェックリスト、展開完了の確認シートを用意すれば、属人化を防ぎながら手作業で回せる。

ツール導入を検討すべきケースは、変更件数が月に複数件あり、拠点や担当部門が分散していて、紙やメールでは展開漏れの検知が追いつかなくなっている組織だ。この段階では、変更の識別から展開完了確認までを一元管理できる仕組みが必要になる。

判断の目安は、「今、展開漏れが起きているかどうかを誰かがすぐ答えられるか」だ。答えられないなら、手作業の限界が来ているサインだ。

今日できる改善手順

いきなりシステムを導入する前に、今日からできることがある。

Step 1. 変更の「反映先リスト」を作る

過去半年分の設計変更を洗い出し、それぞれがどの部門・どの文書に影響したかを一覧化する。これだけで、抜けているルートが見えてくる。

Step 2. 変更通知のフォーマットを固定する

変更内容、影響範囲、反映期限、反映確認方法をひとつのフォーマットに統一する。フォーマットがバラバラだと、受け取った側が重要度を判断できない。

Step 3. 「反映完了」を記録する仕組みを1つ決める

台帳でもチェックシートでも構わない。重要なのは、「通知した」で終わらせず、「現場が実際に反映した」ことを確認する記録を残すことだ。この記録がないと、監査対応でも社内引き継ぎでも根拠を示せなくなる。

おすすめの次アクション

この3ステップを回してみると、次に必要なものが見えてくる。

反映先リストが複雑になってきたら、変更管理台帳のテンプレートを整備する段階だ。反映完了の確認が属人化しているなら、[属人化リスクの構造](/medical-device-maintenance-solo-dependency-risk/)を先に確認しておくと、どこから手をつけるべきかが整理しやすい。

すでに個人依存からの脱属人化に取り組んでいる組織は、[脱属人化の進め方](/medical-device-maintenance-depersonalization/)と変更管理フローを合わせて設計すると、二重の手間を避けられる。

よくある質問

Q1. ISO 13485では変更管理についてどこまで求められますか

ISO 13485は、設計変更の識別・文書化・評価・検証または妥当性確認・承認・記録を求める枠組みを示している。ただし具体的な運用方法までは規定していない。自組織のQMSにどう落とし込むかは、QMS文書の設計次第になる。適合の可否判断は、QMS責任者や監査担当者が個別に確認すべき事項だ。

Q2. 緊急変更の場合、事後の記録でも問題ないですか

緊急対応が必要な場面では、口頭連絡が先行することは現実にある。ただし、事後にどれだけ早く正式な変更記録を残せるかという運用ルールをあらかじめ定めておくことが望ましいと考えられる。運用ルールの妥当性は、QMS責任者の判断に委ねられる部分だ。

Q3. 変更管理台帳はExcelのままでも大丈夫ですか

変更件数が少なく、関係者が限られている組織では、Excel台帳でも運用できる場合がある。ただし、拠点や担当者が増えるほど、更新漏れや二重管理のリスクが高まる。件数や体制の変化に応じて、判断基準を見直す姿勢が必要だ。

Q4. 製造販売業として、委託先の変更管理はどこまで確認すべきですか

委託先で発生した設計・製造変更が、自社の製品品質にどう影響するかを把握する仕組みは重要だと考えられる。ただし、確認範囲や契約上の取り決めは個々の委託関係によって異なるため、一律の基準を示すことはできない。品質保証部門や薬事責任者と個別に確認することが望ましい。

変更管理フローを支えるツール

台帳とチェックリストだけでも運用は始められる。ただし件数が増えてくると、通知漏れや反映確認の抜けをExcelだけで防ぐのは難しくなる。ここから先は、変更管理を仕組み化するツールの出番になる。

変更管理・文書管理を一元化するQMSツール

設計変更の起票から承認、反映先への通知、反映完了の記録までを一つの画面で追えるQMSツールは、拠点や部門が分散している組織で特に効果を発揮する。誰が・いつ・何を反映したかが履歴として残るため、監査対応の準備工数も減らせる。

変更通知・タスク管理を回すワークフローツール

QMS専用ツールを導入する前段階として、汎用のワークフロー・タスク管理ツールで「変更通知」を1つのタスクとして扱う運用も有効だ。反映期限、担当者、完了確認を紐づけておけば、通知が届いたかどうかを可視化できる。まずは小さく始めて、運用が回ることを確認してから本格導入を検討するのが現実的な進め方だ。