【連載】QAが開発の最後に置かれると、なぜ失敗するのか——設計管理は、QAを最後に置けない構造になっている（第5回）

QAを「品質の最後の砦」と呼ぶ組織は少なくありません。多くの場合は敬意を込めた言い方ですが、この比喩は組織の構造を正確に言い当ててもいます。砦とは、敵がそこまで到達してから戦う場所です。つまりQAには、問題が全て作り込まれた後で、それを食い止める役割を負わされているのです。

この配置には、二つの前提が隠れています。一つは「品質は後から検査で確認できる」という前提。もう一つは「見つかった問題は、その場で直せる」という前提です。医療機器の開発では、この二つがどちらも成立しません。

前者については第2回で扱いました。ソフトウェアの不具合は系統的に発生するため、テストで全状態を確認することは原理的にできない。だから品質は測定するものではなく、プロセスとして作り込むものだという話でした。今回問題にしたいのは、後者です。

「不具合の修正コストは、後工程になるほど跳ね上がる」。バリー・ベーム『Software Engineering Economics』（1981年）に由来するこの経験則は、あまりにも有名です。ただし「10倍」「100倍」といった具体的な倍率については、根拠となるデータが限られており、鵜呑みにすべきではないという批判も繰り返しなされてきました。

医療機器の場合、この議論の決着を待つ必要がありません。倍率の推定以前に、後工程での設計変更が何を引き起こすかが、規制上あらかじめ決まっているからです。

設計を変更すれば、ISO 13485:2016 の 7.3.9（設計・開発の変更の管理）により、変更のレビュー、検証、妥当性確認、承認が必要になります。同項は、変更が「製品を構成する要素、および既に引き渡された製品に及ぼす影響」の評価を求めています。IEC 62304 も 7.4 では、変更に伴うリスクマネジメントの再実施が要求されます。

さらに市販前申請にまで届くことがあります。米国では、既存機器のソフトウェア変更が新たな510(k)を必要とするかどうかの判断枠組みが FDA ガイダンス「Deciding When to Submit a 510(k) for a Software Change to an Existing Device」（2017年10月）で示されています。日本でも、承認事項の変更は一部変更承認申請と軽微変更届出のいずれに該当するかの判断が必要になります。

一般のソフトウェア開発では、後工程の手戻りは「工数の損失」です。医療機器では、そこに「再検証」「リスク再評価」「場合によっては規制当局とのやり取り」が積み上がります。リリース直前に設計上の問題が見つかることは、スケジュールが数週間遅れるという話では済まなくなります。

だからこそ医療機器の規制は、問題を後で見つけて直す前提を捨て、そもそも後で見つからないようにする仕組みを、開発プロセスの構造として要求しています。それが設計管理（Design Controls）です。

FDA が1997年に発行した「Design Control Guidance for Medical Device Manufacturers」には、有名なウォーターフォール図が掲載されています。User Needs（利用者要求）からDesign Input（設計インプット）、Design Process（設計プロセス）、Design Output（設計アウトプット）へと下っていく流れの各段階に、設計レビュー（Design Review）が挟み込まれ、検証（Verification）と妥当性確認（Validation）がそれぞれ異なる段階に位置付けられている図です（図表1）。

ここで確認しておきたいのは、検証(Verification)と妥当性確認(Validation)の違いです。検証は「決めたとおりに作ったか」、妥当性確認は「作ったものが本来の使用目的を満たすか」を確かめる活動で、問いも実施段階も異なります。重要なのは、どちらも「最後の工程の名前」ではないということです。検証は各段階の出口で行われ、妥当性確認は使用者・使用環境という開発工程における上流の定義に対して行われます（図表1）。

ISO 13485:2016 の 7.3 は、この構造を次の条項として並べています。

7.3.2 計画、7.3.3 インプット、7.3.4 アウトプット、7.3.5 レビュー、7.3.6 検証、7.3.7 妥当性確認、7.3.8 移管、7.3.9 変更の管理、7.3.10 設計・開発ファイル

前回でも触れたとおり、米国ではQMSR（2024年2月2日公布、2026年2月2日施行）により  ISO 13485:2016 を引用する形に再編され、設計管理はこの枠組みに整理されました。

注目したいのは 7.3.5（設計・開発のレビュー）です。同項は、レビューの参加者に「レビューされる設計・開発段階に関係する機能の代表者」と「その他の専門要員」を含めることを求めています。旧 QSR の 21 CFR 820.30(e) は、これをさらに踏み込んだ表現で規定していました。参加者には「レビューされる設計段階に直接の責任を持たない者」を含めなければならない、と明記されていたのです。

つまり規制は、設計の各段階に「その設計をやった本人ではない目」を入れることを、制度として組み込んできました。これは事後検査の要求ではありません。工程の途中に、独立した確認者を配置せよという要求です。QAを最後に置く体制では、この構造をそもそも満たせません。

設計管理の中で、QAの立ち位置を最も強く規定しているのは、実は設計インプットの条項です。

ISO 13485:2016 の 7.3.3 は、設計・開発へのインプットが「完全であり、曖昧でなく、検証または妥当性確認が可能であり、相互に矛盾しないこと」を要求しています。この一文が意味していることは重いと言えます。要求仕様は、書かれた時点で「これをどう確かめるか」が言えなければならないからです。

IEC 62304 も同じ方向を向いています。5.2.6（ソフトウェア要求の検証）は、ソフトウェア要求が、リスクコントロール手段を実装しているか、システム要求と矛盾していないか、一意に識別できるか、トレース可能か、そして試験可能（testable）かを検証することを求めています。さらに 5.1.6（ソフトウェア検証の計画）は、検証の対象・方法・受入基準を、開発計画の中であらかじめ定めることを要求します。

これは、テストをいつ実施するかという話ではありません。要求を書く場に、「それは何をもって合格とするのか」を問う人がいなければならない、という話です。

QAが工程の最後にいる組織で最も頻繁に起きる失敗は、バグを見逃すことではありません。合否を判定する基準が存在しないままテストに入ってしまうことです。基準がないので、テストの結果は「動いた／動かなかった」になります。動いていれば合格とみなされ、動かなければ「仕様の解釈」を巡る議論が始まるのです。第3回で述べた「主張・論拠・証拠」の構造でいえば、証拠を集める段階に来て初めて、主張が定義されていなかったことに気付くわけです。

トレーサビリティも同じ運命をたどります。要求とアーキテクチャとテストの対応付けは、後からまとめて作ると、実態を写したものではなく体裁を整えただけのものになります。前回述べた「文書と実態の乖離」は、多くの場合、QAが遅れて参加したことの副産物です。

ここまでは効率の話でした。医療機器QAで本当に深刻なのは、次の点です。

ISO 14971:2019 の 7.1（リスクコントロール手段の選択）は、リスクコントロールの選択肢に優先順位を定めています。第一に、本質的な安全設計による対応。第二に、機器自体または製造工程における防護手段。第三に、安全に関する情報の提供と、必要に応じた使用者への訓練です。この順序は、推奨ではなく要求事項です（図表2）。

順序に意味があるのは、効果が違うからです。設計で危険源そのものを取り除けば、使用者が何をしても危害は起きません。防護手段は、危険源を残したまま、危害に至る経路を遮ります。安全情報は、使用者が読み、理解し、記憶し、その通りに行動して初めて機能します。人間の行動に依存する分、最も脆い。

ここで、QAが工程の最後にいる組織を想像してみてください。リリース直前、システムテストの終盤で、ある操作手順の組み合わせが危害につながり得ることが見つかったとします。ここで取り得る三つの選択肢を考えてみましょう。この時点で、アーキテクチャに手を入れるという第一の選択肢は、再検証と再申請の判断が発生するため、現実的に選べません。第二の選択肢として、大きな設計変更も第一の選択肢と同様に非現実的です。

結果として選ばざるを得ないのは、次の三の選択肢になります。それは、取扱説明書に警告を追記する、ラベルに注意書きを載せる、教育資料に一項目を足すといった対処です。規格上、これは違反ではありません。しかし ISO 14971 が最も効果が低いと位置付けた手段を、優先順位ではなく「発見した時期」の都合で選んだことになります。

これが、QAを最後に置く体制の最も見えにくい代償です。スケジュールの遅れは目に見えますが、選べたはずの安全設計を選べなかったことは、どの指標にも表れません。ISO 14971 が要求するリスクマネジメントは、ハザードの特定から始まり、設計に反映され、その有効性が検証される一連の流れです。この流れが機能するには、危険源が設計の余地が残っている段階で特定されている必要があります。

第1回で取り上げた Therac-25 も、この構造による問題でした。ハードウェアのインターロックという本質的な安全設計を、ソフトウェアによる制御に置き換えるという決定が、その妥当性を独立に確認されないまま通ってしまったことに起因しています。つまり、テスト工程で発見できなかったことよりも、設計の判断が設計の段階で問われなかったことのほうが、根の深い問題だったのです。

構造の問題は、組織の力学にも波及します。

工程の最後にいるQAが果たせる役割は、実質的に一つしかありません。出荷を止めるか、止めないかです。指摘は常に「もう直せない段階での指摘」になり、開発チームからは進行を妨げる存在に見えます。指摘の内容が正しいほど、対立は深くなります。

こうなると、組織は合理的に振る舞います。QAに情報を渡すタイミングを遅らせ、指摘が出にくい範囲だけを見せ、判断はQAの外側で済ませようとします。品質保証部門が独立しているのに影響力がない、という状態は、たいていこの経路で生まれます。

医療機器の規制がQAの独立性を「レビューの参加者」という形で要求してきたのは、この力学を避けるためでもあります。止めるためではなく、判断の質を上げるために独立性を使う、という設計です。

ここまでの整理から、QAをどこに置くべきかは自ずと決まります。QAが上流に関わる理由は、早くテストを始めるためではありません。

第一に、要求が検証可能かを問うためです。「使いやすいこと」は要求ではありません。何をもって満たされたとするかが言えない記述は、7.3.3 の観点では設計インプットとして不完全です。この問いを、要求を書いている場で出せるかどうかが分かれ目になります。

第二に、リスクコントロール手段を検証可能な形にするためです。IEC 62304 の 7.2・7.3 は、リスクコントロール手段をソフトウェア要求として定義し、その有効性を検証することを要求しています。「安全のためにこうする」という合意が要求仕様に落ちていなければ、検証のしようがありません。

第三に、受入基準を先に決めるためです。5.1.6 が求める検証計画とは、要するに「何を、どうやって、どうなったら合格とするか」を先に書いた文書です。これは開発を縛るためのものではなく、後で議論しなくて済むようにするためのものです。

近年よく言われる「シフトレフト」の本質も、ここにあります。テスト実行を前倒しすることではなく、合否の判断基準を前倒しすることです。アジャイル開発における Definition of Done も同じ思想の表れですし、AAMI TIR45:2023 が反復の中で文書と検証を段階的に成熟させる考え方を扱っているのも、区切りごとに判断基準を確定させるためです。

この点はAIの活用によってさらに重みが増しています。前回述べたとおり、生成AIは実装も文書作成も加速させます。しかし加速するのは「作る」側だけです。受入基準が定義されていない状態で生成量だけが増えれば、確認しきれない成果物が積み上がります。何をもって正しいとするかを先に決める仕事は、加速の恩恵を受けない代わりに、加速するほど価値が上がる仕事になりました（図表3）。

医療機器の設計管理が示しているのは、QAを工程表の一区間として扱う限り、それは「最後の砦」にしかなれない、ということです。規格が要求しているのは、レビュー・検証・妥当性確認という確認行為を、設計の各段階に構造として埋め込むことでした（図表4）。

この考え方は医療機器に限りません。要求を書く場に判定基準を問う人がいるか。設計判断の場に、その判断の当事者ではない目があるか。問題が見つかったとき、設計で直す選択肢がまだ残っているか。この三つがそろっている組織は、QAをどの部署に置いていようと、品質を構造として扱えています。

QAが最後に置かれると失敗するのは、QAの能力が足りないからではありません。最後に置かれた時点で、QAにできることが、止めるか通すかの二択に狭められてしまうからです。

あなたの組織で、QAは開発のどの段階から関わっていますか？

次回予告

第6回は「リスクマネジメントは机上の空論か？ 現場で起きる誤解」をテーマに取り上げます。ISO 14971 が要求するリスクマネジメントが、なぜ現場では書類作成に変質してしまうのか。ハザード、危険状態、危害という用語の関係と、現場で起きる典型的な誤解を整理します。

参考文献・規格

ISO 13485:2016 「医療機器―品質マネジメントシステム―規制目的のための要求事項」 7.3.2／7.3.3／7.3.5／7.3.6／7.3.7／7.3.9
IEC 62304:2006/AMD1:2015 「医療機器ソフトウェア―ソフトウェアライフサイクルプロセス」 5.1.6／5.2.6／7.2／7.3／7.4
ISO 14971:2019 「医療機器―リスクマネジメントの医療機器への適用」 7.1
21 CFR Part 820 Quality Management System Regulation（2024年2月2日公布／2026年2月2日施行）、および旧 21 CFR 820.30(e)
FDA "Design Control Guidance for Medical Device Manufacturers"（1997年3月11日）
FDA "Deciding When to Submit a 510(k) for a Software Change to an Existing Device"（2017年10月25日）
FDA "General Principles of Software Validation"（2002年1月）
AAMI TIR45:2023 "Guidance on the use of agile practices in the development of medical device software"
Barry W. Boehm, "Software Engineering Economics", Prentice Hall, 1981

参考サイト

ポータルサイト：https://www.medicalsoftwareconsulting.com/
規格解説動画：https://www.youtube.com/@MedicalSoftwareConsulting
医療機器ソフトウェア 規制・規格 知識データベース：https://watch.medicalsoftwareconsulting.com/

本文中で参照した過去回

第1回：https://www.veriserve.co.jp/helloqualityworld/media/20260603001/
第2回：https://www.veriserve.co.jp/helloqualityworld/media/20260708001/
第3回：https://www.veriserve.co.jp/helloqualityworld/media/20260817001/
第4回：https://www.veriserve.co.jp/helloqualityworld/media/20260909001/