「設計検証と妥当性確認 ― テストで証明する品質」医療機器ソフトウェア開発 スタートアップのための”後悔しない”実践ガイド第5回
はじめに
前回は、「要求仕様をどう“開発の言葉”に翻訳するか」をテーマに、規制要求とプロダクト要求のギャップをどう埋めるかを整理しました。
今回のテーマは、その要求を “本当に満たしている”ことを証明する方法――つまり設計検証（Verification）と妥当性確認（Validation）です。
スタートアップの現場ではよく、
- 「テストは時間が余ったらやるもの」
- 「リリースして不具合が出たら直せばいい」
- 「医療機器は厳しすぎる」
といった声を耳にします。
しかし医療機器においては、“後戻りコスト”が桁違い。
要求定義の誤りや検証不足が量産後に露呈すれば、リコール・市場対応・承認書変更 …といった“痛すぎる未来”が待っていることは、（第1回 記事）の事例からも明らかです。
第5回では、「最小チームでも運用できる」「Lean-QMSにも適合する」ことを前提に、無駄なく・漏れなく・後悔しない Verification ／ Validation をどう設計するかを解説します。
1. Verification（設計検証）と Validation（妥当性確認）
■ Verification（設計検証）：
「設計仕様（SDS: Software Design Specification）が、要求仕様（SRS: Software Requirements Specification）を満たしているか」を証明する活動。
確認する対象は“設計物”であり、
- 要求仕様
- アーキテクチャ
- モジュール設計
- コード
- テスト仕様書
など、開発プロセスのアウトプットが正しいかをチェックします。
■ Validation（妥当性確認）：
「最終製品が、ユーザーのニーズと Intended Use（意図する使用） を満たしているか」を証明する活動。
実環境または模擬環境で、ユーザー視点で評価します。
2. スタートアップが陥りがちな「V&Vの3つの罠」
罠①：テストとレビューを“作業”として捉える
罠②：テスト仕様が SRS をカバーしていない
罠③：Validation を「最終テスト」と誤解する
3. Lean-QMS 時代の「効く」Verification の進め方
4. SaMD における Validation の“本質”
- 臨床妥当性
- ユーザビリティ（IEC 62366-1）
- 実使用環境テスト
5. Traceability は“規制対応”ではなく“開発の武器”
SRS → SDS → テスト仕様 → 実施記録 → 不具合管理 → RMF まで一本でつながることが重要。
6. 実務テンプレ：Lean-QMS での V&V 最小構成
まとめ
Verification は設計が要求を満たしている証明であり、Validation はユーザーに価値を届けている証明。
Traceability は小規模チームこそ必須の武器。
最初から設計品質を作り込むことが、スピードと安全性を両立させる最短ルート。
■ 最後に ― スタートアップが後悔しないための小さな心得
医療機器ソフトウェア開発では、
「正しく作る」ことよりも「正しいものを作る」ことが圧倒的に難しい
――これは40年近く現場にいて強く感じたことです。
そのために、スタートアップの皆さんへ、実務からの小さなアドバイスをいくつか贈ります。
① 書類は“提出用”ではなく“開発チームの武器”
規制文書というと「提出のために書くもの」と思われがちですが、
良い SRS・良い SDS は、設計ミスや後戻りを劇的に減らします。
文書はチームを守る盾であり、議論を加速するエンジンです。
② テストは“品質を確認する作業”ではなく“誤りを早く発見する活動”
Verification/Validation は、後戻りコスト（rework cost）を最小にするための最も安い投資 です。
開発初期の誤りを潰すことに時間を使うほど、後半の修正コストは指数関数的に小さくなります。
③ 完璧を目指さなくていい。けれど、曖昧なまま進めてはいけない
Lean-QMS の思想でも同じですが、完璧主義は敵、曖昧さはもっと敵。
決められないことは無理に決めなくていい、
しかし “曖昧なまま設計を進めること” は必ず後悔を生みます。
④ “説明できる開発”を続けることが、結局は最強の品質保証
FDAでもPMDAでも、最終的に問われるのは
「なぜ、この要求になり、どう設計し、どう検証したのか？」
という“説明可能性（Explainability）”です。
小さなチームでも、シンプルなプロセスでも、説明可能性が担保されていれば規制は必ず通ります。
次回予告：
「リスクマネジメントの本質 ― “安全性”と“セキュリティ”を分けて考える」
執筆・監修：酒井 由夫（Medical Software Consulting / xCAREエキスパート）
医療機器ソフトウェア開発コンサルタント／xCAREエキスパート
医療機器メーカーでのソフトウェア開発、規格対応支援経験を経て、外資系企業・医療スタートアップにて医療機器ソフトウェア（SaMD）の製品企画・規制対応・QMS運用の支援をはじめる。クラスII・III機器の開発～市販後に関するISO 13485、IEC 62304、ISO 14971、FDA対応、薬機法承認申請などの支援を専門とする。現在は医療機器ソフトウェア専門のコンサルタントとして独立し、国内外のスタートアップ・製販企業に対して、開発プロセス設計やチーム育成、技術文書の作成支援など、実行支援を提供中。
🔗 詳細プロフィール・個別相談をご希望の方は：
👉 酒井さんのコンサルティング会社サイトはこちら
医療機器ソフトウェア開発でお困りの方へ
「自社の開発体制、このままで本当に大丈夫だろうか？」
「海外規制も見据えた設計・文書化ができているか不安…」
そんな医療機器スタートアップ・開発チームの皆さまへ。
xCAREでは、実務経験豊富なエキスパートが並走し、後悔しない開発体制づくりを支援しています。
まずはお気軽に、現在の課題や懸念をお聞かせください。
👉 xCAREへのご相談はこちら（無料個別相談あり）
