設計管理とデザインレビュー
「良いものさえ作れば、設計管理の書類なんて後からついてくる」ーー技術に自信のある開発者ほど、こう考えがちだ。だが、医療機器の設計管理(デザインコントロール)は、良い設計の後始末ではない。良い設計を生み出すための仕組みである。
設計管理の骨格は、一本の流れでできている。まず何を満たすべきかという設計インプット(要求)を定め、それを具体的な設計アウトプット(仕様、図面、ソフトウェア仕様)へ落とし込む。次に、アウトプットがインプットを満たしているかを検証(ベリフィケーション)し、最後に、出来上がった製品が、あらかじめ規定された意図した用途及び使用者のニーズを満たすかを妥当性確認(バリデーション)する。要求から始まり、設計を経て、二段階で確かめるーーこの順序が崩れると、後工程すべてが揺らぐ。

ただし、設計管理はこの一本道だけではない。設計開発計画、リスクマネジメント、節目ごとのデザインレビュー(設計開発照査)、設計移管、設計変更管理が、この流れに絡み合う。骨格を貫くのは、要求から検証・バリデーションまでの追跡可能性であり、必要なら前の段階へ戻る覚悟である。
つまずきやすいのは「入口」である。設計インプットが曖昧なら、その先の検証は基準を持てない。「使いやすく」「十分な強度で」といった主観的な要求は、後から「満たしたかどうか」を判定しようがない。
要求は、漏れなく、曖昧でなく、互いに矛盾せず、そして客観的に検証・判定できる言葉で書かねばならない。ここを疎かにした設計は、ゴールの見えない競走のようなものだ。
デザインレビューの価値は「設計した本人だけでは見えないもの」を、節目ごとに複数の目で拾うことにある。人は自分の設計の欠陥には気づきにくい。慣れ親しんだ前提を、疑いようのない当たり前だと思い込んでしまうからだ。
だから規制は、審査対象の段階に関係する部門の代表者と、必要な専門知識を持つ者の参加を求める。要求、リスク、製造可能性、使用性を、異なる立場から突き合わせるためである。ここから先は、筆者の実務上の見解である。
審査対象の設計に直接責任を持たない者を加えると、客観性は一段上がる。外を知る者ほど、内側の異常に気づきやすい。「そもそもこの前提は正しいのか」という問いは、そういう立場からこそ出てきやすい。
ただし、独立したレビューアの参加を一律の必須要件とするかは、適用する法規制や社内手順によって異なる。旧21 CFR 820.30(e)は直接責任を持たない者の参加を明文で求めていたが、2026年2月2日施行のQMSRにその明文はなく、関係機能の代表者と専門要員の参加が要件となっている。要は、製品の複雑性と設計段階に応じて、意味のある検討ができる顔ぶれを選べということだ。
同じチームだけで回すなら、役割、評価基準、指摘事項とその処置を明確にし、形式的な追認に終わらせない工夫がいる。見落とされやすいのが、検証(ベリフィケーション)と妥当性確認(バリデーション)の役割の違いである。検証は「設計アウトプットが設計インプットを満たしているか」を確かめ、バリデーションは「最終的な製品が、あらかじめ規定された意図した用途及び使用者のニーズを満たすか」を確かめる。
仕様を完璧に満たしていても、その仕様自体が使用環境や使用者のニーズとずれていれば、期待された安全性や性能は出ない。図面どおりに作れたことと、患者や医療者にとって適切に使えることは、別の問いなのだ。しかも設計管理は、市販開始で終わらない。
設計変更を行うときは、機能、性能、安全性、使用性、法令適合性はもとより、構成部品、製造工程、すでに引き渡した製品、リスクマネジメントへの影響まで評価する。そのうえで、変更の実施前に照査し、検証し、必要に応じてバリデーションを行い、承認を得る。市販後のフィードバックが設計やリスク管理の見直しにつながることもある。
設計とは、承認を取った瞬間に凍りつくものではなく、変更と市販後情報に応じてライフサイクルを通じて管理し続ける対象なのだ。そして当局の調査で問われるのは、レビュー議事録の分厚さではない。定めた手順と計画のとおりに設計し、その判断と結果を客観的証拠として示せるかーー「Show me, don’t tell me」である。
これは規制文言ではなく、実務上の標語にすぎないが、要点を突いている。立派な設計思想を語るより、要求、リスク、設計、レビュー、検証、バリデーション、変更が、記録の上で一本につながっていること。それが、設計管理が機能している何よりの証なのである。
この分野の解説動画
この記事は参考になりましたか?

この記事へのコメントはありません。