医療機器ソフトウェア（SaMD）のQMS対応——ISO 13485に沿った開発プロセスと文書整備の実務

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

リリースノートはある。でも設計変更の理由を書いた文書がない。

私がQAとして関わったSaMD開発の現場では、こういう状態がよく起きていた。コードは動いている。テストも通っている。でも「なぜこの仕様にしたか」「どのリスクを想定して検証したか」がどこにも残っていない。

これは開発者の怠慢ではない。ソフトウェア開発のスピード感と、QMSが求める文書化の粒度が、仕組みとしてかみ合っていないだけだ。

よくある失敗——設計文書が「後付け」になる現場

パターンは大体3つに集約される。

1つ目は、設計開発計画書を作った後、実際の開発がアジャイルに進んでしまい、計画書だけが置き去りになるケース。スプリントごとに仕様が変わるのに、計画書は初版のままだ。

2つ目は、検証（Verification）とバリデーション（Validation）の区別が曖昧なまま記録を残すケース。「要求仕様通りに作ったか」の確認と「意図した使用で安全に機能するか」の確認が、同じテスト結果でまとめて処理されている。

3つ目は、リスクマネジメントファイルが開発の最後に一括で作成されるケース。本来は設計の初期段階から更新し続けるはずのものが、監査直前にまとめて書かれる。

どれも「うちもそうだ」と思った経営者は多いはずだ。

なぜその問題が起きるのか——QMSが「作業の結果」になっている

根本原因は、QMS文書が開発プロセスの「副産物」として扱われていることにある。

開発チームはコードを書くことに集中する。文書化は別タスクとして後回しにされる。結果、誰かが思い出しながら文書を再構成する作業になる。これは個人の記憶力や几帳面さに依存した運用だ。

IEC 62304が求めるソフトウェアライフサイクルプロセスと、ISO 13485が求める設計管理プロセスは、本来は開発と並走するように設計されている。しかし多くの現場では、この2つが別々の担当者、別々のタイミングで動いている。情報の受け渡し設計がないまま、人の記憶と善意でつないでいる状態だ。

これは属人化の問題と構造が同じだ。特定の担当者しか経緯を説明できない状態は、点検記録でもソフトウェア開発でも同じ形で現れる。

放置すると何が起きるか

監査やサーベイランスの直前になって、トレーサビリティマトリクスの穴が見つかる。要求事項とテストケースがひも付いていない箇所が複数出てくる。

そこから担当者が過去のチャットログやメール、Gitの履歴を遡って文書を再構成する作業が始まる。これに数週間かかることも珍しくない。

残業が増えるだけでは済まない。担当者が異動や退職をした場合、経緯を知る人間がいなくなり、次の変更管理がさらに重くなる。顧客や規制当局から変更の根拠を問われたときに、即答できない状態が続く。これは引き継ぎの属人化と同じ構図で、放置期間が長いほど復旧コストが跳ね上がる。

改善するための判断基準

すべてをツール化する必要はない。判断軸は3つある。

まだ手作業でよいのは、開発規模が小さく、変更頻度が低い初期フェーズだ。設計開発計画書とリスクファイルを、担当者2〜3人で目視更新できる範囲なら、無理にシステムを入れる必要はない。

テンプレで足りるのは、文書の種類と粒度がある程度固まっている場合だ。設計検証記録、バリデーション記録、変更管理記録のフォーマットを標準化し、誰が書いても同じ構造になるようにする。これだけで後からの再構成作業は大幅に減る。

ツール導入を考えるべきは、複数の開発チームや外部委託先が関わり、トレーサビリティの手動管理が限界を迎えている場合だ。要求事項・設計・テスト・リスクを一元管理できる仕組みがないと、変更のたびに整合性確認が属人的な作業になる。

なお、ISO 13485やIEC 62304への適合可否、監査での評価は、一般に個別の製品特性や開発体制によって判断が分かれる。最終的な適合判断はQMS責任者や薬事・品質責任者の確認に委ねる前提で、ここでは実務上の整理の目安として読んでほしい。

今日できる改善手順

Step 1. 現在進行中の開発案件について、設計開発計画書の最終更新日を確認する。3ヶ月以上前なら、現状の開発内容と乖離がないか突き合わせる。

Step 2. 検証とバリデーションの記録フォーマットを分ける。同じテンプレートで両方を記録している場合は、目的欄を分離するだけでも違いが明確になる。

Step 3. リスクマネジメントファイルの更新タイミングを、設計変更のたびに行うルールとして明文化する。監査前の一括更新をやめる第一歩になる。

おすすめの次アクション

まずは自社のトレーサビリティマトリクスを1つの案件で作り直してみるとよい。要求事項・設計仕様・テストケース・リスクコントロールの4列を並べるだけで、抜け漏れが可視化される。

品質のばらつきが複数の担当者間で起きている場合は、機械音や判断基準の個人差に関する記事も参考になる。基準のない判断が積み重なる構造は、ソフトウェア開発でも保守点検でも共通している。

よくある質問

Q1. ISO 13485の認証を取得すれば、SaMDとして安全性が保証されますか？

一般に、QMS認証はプロセスの管理体制を評価するものであり、製品そのものの安全性を保証するものではないと考えられる。安全性の確認は別途、リスクマネジメントや臨床評価などのプロセスを通じて行う必要がある。

Q2. アジャイル開発とQMSの文書化は両立できますか？

両立は可能と考えられるが、スプリントの区切りと文書更新のタイミングを事前に設計しておく必要がある。開発後にまとめて文書化する運用は、乖離を生みやすい。

Q3. 小規模チームでもトレーサビリティマトリクスは必要ですか？

規模に関わらず、要求事項とテスト結果の対応関係を追える状態は必要と考えられる。ただし管理方法は表計算ソフトで十分な場合もあり、必ずしも専用ツールが必要とは限らない。

Q4. 外部委託先が開発したモジュールのQMS文書はどう扱えばよいですか？

委託先との役割分担と、どちらが設計検証記録を保持するかを契約段階で明確にしておくことが望ましいと考えられる。最終的な文書の整合性確認は、自社のQMS責任者が担う体制が一般的だ。

ツール紹介

文書管理やトレーサビリティの手作業に限界を感じ始めたら、専用のQMS支援ツールや文書管理システムの比較検討に進むタイミングかもしれない。

品質管理文書のテンプレート集を確認する

設計開発計画書やリスクマネジメントファイルの標準フォーマットを一から作るのは負担が大きい。市販のテンプレート集や書籍を参考に、自社用にカスタマイズする進め方が現実的だ。

トレーサビリティ管理ツールを比較する

複数案件・複数チームでの開発が常態化してきたら、要求事項・設計・テストを一元管理できるツールの比較検討を始めるとよい。導入前に、自社の文書構造を整理しておくと選定がスムーズになる。