設計管理はウォーターフォールモデルではない

設計管理はウォーターフォールモデルではない

医療機器の開発においては、ISO13485や米国FDAのQSR（Quality System Regulation）に基づく設計管理が不可欠である。しかし、これらの規制要件に基づく設計管理プロセスを「厳格なウォーターフォールモデル」と誤解している開発者は少なくない。今回は、ISO13485やQSRの設計管理の本質を解説し、なぜそれがウォーターフォールモデルに限定されないのかを明らかにする。

設計管理とは何か

設計管理（Design Control）とは、医療機器の設計プロセスを体系的に管理し、安全で有効な製品を開発するための枠組みである。ISO13485の7.3項および米国QSR（21 CFR Part 820.30）では、以下の要素が定義されている。

• 設計・開発の計画
• 設計インプット
• 設計アウトプット
• 設計レビュー
• 設計検証
• 設計バリデーション
• 設計移管
• 設計変更管理

これらの要素は一見、順序立てたウォーターフォールモデルを想起させるが、実際はそうではない。

Application of Design Controls to Waterfall Design Process

誤解の原因

多くの医療機器メーカーがISO13485やQSRの設計管理をウォーターフォールモデルとして実装してしまう主な理由は以下の通りである。

• 規制文書の図式化: FDAのDesign Control Guidance for Medical Device Manufacturersに掲載されている「ウォーターフォールダイアグラム」の影響
• 文書化の順序性: 設計インプット→設計アウトプット→検証という文書の作成順序
• 監査対応の容易さ: 直線的なプロセスは監査証跡が残しやすい

しかし、これらは規制の本質的な要求ではなく、実装の一例に過ぎない。

設計管理の本質

ISO13485もQSRも、特定の開発モデルを要求しているわけではない。要求しているのは以下の原則である。

• トレーサビリティの確保: 要求事項から実装、検証までの追跡可能性
• リスク管理の統合: 設計プロセス全体を通じたリスク管理活動
• 設計変更の管理: 変更の影響評価と適切な承認
• 客観的証拠の維持: 設計決定の根拠と結果の文書化

設計検証の反復的性質

設計プロセスを理解する上で重要なのは、各プロセスへのインプットがアウトプットに変換され、それが次のプロセスのインプットとなるという流れである。設計検証とは、このアウトプットがインプットの要求を満たしていることを確認する活動である。
この観点から、設計検証は単一の時点で実施される一回限りのアクティビティではなく、設計開発の様々な段階で繰り返し実施されるべきものである。例えば

• 仕様書に対するソフトウェアモジュールの検証
• 機構設計に対する部品図面の検証
• サブシステム間のインターフェース要件に対する統合結果の検証

このように設計検証を反復的に行うことで、早期に問題を発見し、手戻りを最小化できる。これは、ウォーターフォールの「最後に一括検証」という考え方とは根本的に異なるアプローチである。

現実的な制約に対応する段階的検証

医療機器開発においては、現実的な制約条件への対応も設計管理プロセスの柔軟性を要求する要因となる。

1. リードタイムの長い部品・モジュールへの対応: 特定の部品やモジュールは調達に数ヶ月かかる場合がある。このような状況では、設計の確定を待たずに先行して発注し、段階的に検証を進める「五月雨式」アプローチが必要となる。
2. 第三者認証・試験の時間的制約: UL認証などの安全性試験や電磁両立性(EMC)試験には相当の時間を要する。最終製品の完成を待たずに、試作機やサブシステムレベルでの先行評価が不可欠である。
3. 並行開発の必要性: ハードウェアとソフトウェアの並行開発やファームウェアの段階的リリースなど、複数の開発ストリームを同期させながら検証活動を行う必要がある。

これらの現実的制約に対応するためには、設計検証を固定的な一時点ではなく、開発全体にわたる継続的な活動として捉え、リスクベースで優先順位付けしながら実施することが重要である。このような柔軟なアプローチこそが、ISO13485やQSRが想定する実効性のある設計管理の姿である。
これらの原則は、ウォーターフォール、アジャイル、V字モデルなど、様々な開発アプローチと組み合わせて実現可能である。

アジャイル開発と設計管理の統合

医療機器開発においても、アジャイル手法を設計管理と統合することは可能である。その実践例を以下に示す。

1. インクリメンタルな設計インプット: ユーザーストーリーやプロダクトバックログを設計インプットとして段階的に詳細化
2. 継続的な設計レビュー: スプリントレビューを形式的な設計レビューとして活用
3. 進化的な検証: 継続的インテグレーションを通じた自動テストによる検証
4. 段階的なリスク分析: スプリントごとのリスク分析とハザード識別

AAMI TIR45:2012「医療機器ソフトウェア – アジャイル方法論のガイダンス」では、アジャイル開発と規制要件の整合について具体的なガイダンスが提供されている。

V字モデルとの親和性

設計管理と親和性が高いとされるV字モデルも、必ずしも厳格なウォーターフォールである必要はない。V字の各フェーズを反復的に実施することで、以下のメリットが得られる。

1. 早期のリスク発見と対応
2. 検証・バリデーション活動の分散と負荷軽減
3. フィードバックの迅速な反映

実践的なアプローチ

医療機器開発における設計管理を柔軟に実装するためのポイントは以下の通りである。

1. 目的重視の文書化: 形式ではなく、トレーサビリティと根拠の明確化を重視
2. リスクベースの計画: 製品リスクに応じた設計管理の厳格さの調整
3. 適応型プロセス: 製品の性質や開発段階に応じたプロセスの調整
4. ツールの活用: 要求管理ツールやALM（Application Lifecycle Management）ツールによる効率化

関連商品

[blogcard url=https://ecompliance.co.jp/qms-md/ title="QMS（手順書）ひな形　医療機器関連" ]

[blogcard url=https://shop.ecompliance.jp/product/el-027/ title=”【セミナービデオ】第一部：医療機器開発におけるマーケティングと出口戦略 第二部：医療機器開発における開発マネージメント” ]

[blogcard url=https://shop.ecompliance.jp/product/el-008/ title=”【QMS省令対応】設計管理規程・手順書・様式” ]

[blogcard url=https://shop.ecompliance.jp/product/qms-iso14971-001/ title=”【VOD】医療機器設計管理入門” ]

[blogcard url=https://shop.ecompliance.jp/product/book-md001/ title=”【書籍】【徹底解説】ISO 14971 医療機器リスクマネジメント” ]