「Lean-QMSの完成 ― 持続的に成長する医療機器ソフトウェアチームへ」 医療機器ソフトウェア開発 スタートアップのための“後悔しない”実践ガイド最終回
はじめに：この連載で一番伝えたかったこと
10回にわたる連載の最後に、一番伝えたかったことを先に言わせてください。
医療機器ソフトウェアの規制対応は、「通すもの」ではなく「使うもの」です。
IEC 62304のライフサイクル管理も、
ISO 14971のリスクマネジメントも、
SBOMによる脆弱性対応も
――本来はすべて、より良い製品を作るための設計原則として生まれています。
しかし現実には、「規制をどうクリアするか」という発想が先行し、開発とQMSが分断され、審査が近づくたびに後付け文書の作成に追われる
――そんなチームを多く見てきました。
この連載が目指したのは、その構造を根本から変えることです。
規制を開発プロセスに埋め込み、品質とスピードを両立し、市販後まで安全性を維持し続ける。そのための実践的なフレームワークが、Lean-QMSです。
Lean-QMSの本質：軽くすることではない
「Lean」という言葉から、「文書を減らす」「簡略化する」という印象を持たれるかもしれません。
しかし本質はそこではありません。
Lean-QMSとは、規制要求を"開発プロセスに埋め込む"設計思想です。
• 後から文書を作るのではなく、最初から記録が残るようにする
• 規制対応を「作業」ではなく「仕組み」にする
• 開発・品質・薬事を分断しない
この思想が一貫していれば、結果として「無駄な文書」は減ります
――しかしそれは副次的な効果です。
Lean-QMSの全体構造：5つのレイヤーが統合されると何が起きるか
Lean-QMSは5つのレイヤーで構成されます。
重要なのは、各レイヤーが独立した「タスク」ではなく、互いに連動することで初めて機能するという点です。
① 開発プロセス（IEC 62304の実装）
要求 → 設計 → 実装 → 検証の流れを、トレーサビリティツールで自動的に維持します。
設計とテストが分離しない構造が鍵です。
統合の意味：
トレーサビリティが生きていると、変更の影響範囲が即座に可視化されます。
「どこを直せばどこに影響するか」が分かれば、リスク評価もドキュメント更新も的確に絞り込める。
これが後のレイヤーすべての前提になります。
② リスクマネジメント（ISO 14971の統合）
危険源ベースのリスク識別を行い、ソフトウェア故障・使用環境・サイバー脅威を統合的に評価します。
設計とリスクコントロールが直結していることが重要です。
統合の意味：
リスク評価が開発プロセスと連動すると、「リスクコントロールとしての設計判断」が自然に記録されます。
「なぜこの設計を選んだのか」が文書に残り、審査での説明が格段に楽になります。
③ セキュリティ・市販後対応（PSIRT / SBOM）
SBOMによる構成の可視化、
脆弱性情報の継続監視、
インシデント対応プロセス（PSIRT）
を整備します。
統合の意味：
ISO 14971のリスク評価とSBOMの脆弱性監視が連動することで、市販後の安全性管理が初めてクローズドループになります。
新たな脆弱性が発見されたとき、「これはリスクとして許容範囲か」「設計変更が必要か」の判断を、既存のリスク管理の枠組みで即座に行えます。
④ 変更管理（アップデート戦略）
変更の影響評価（リスク・性能・適合性）を行い、一変申請か軽微変更かを判断するロジックを整備します。
統合の意味：
①のトレーサビリティと②のリスク評価が整っていれば、変更管理は「毎回ゼロから考える作業」ではなくなります。
既存のデータを参照しながら影響範囲を特定し、申請要否を判断できる
――これがアップデートの継続的改善を可能にします。
⑤ ドキュメント戦略（グローバル展開）
審査官が理解しやすい構造、英語ベースの一次文書、QMSと技術文書の整合性を担保します。
統合の意味：
①〜④が機能していれば、ドキュメントは「プロセスの自然な出力」になります。
後から作るのではなく、開発の過程で記録が蓄積される。
その結果、グローバル展開時も「日本向けに作ったものを翻訳する」という非効率から脱却できます。
スタートアップにとっての現実解：どこから始めるか
「最初から完璧なQMSは不要」
――この原則は正しいのですが、「では何から始めるのか」が曖昧なままでは動けません。現実的な段階を示します。
一番重要なこと：
Phase 0で「思想」だけは確定させてください。
ツールは後から変えられますが、「開発と規制を分断する文化」は後から変えるのが最も難しい。
Lean-QMSがもたらすもの：因果の連鎖
Lean-QMSを実装したチームは、単に「規制に通る」だけではありません。
正しい設計により
手戻りが減り
→ 開発の意思決定が速くなり
→ チーム全体の認識が一致し
→ 審査での説明が明確になり
→ 結果として市販後のトラブルにも強くなる。
これが「負けない開発」の正体です。
個々の規制対応がバラバラに存在するのではなく、ひとつの統合されたシステムとして機能している状態です。
よくある失敗パターン（総まとめ）
本連載で一貫して警鐘を鳴らしてきた失敗を整理します。
❌ 後付けQMS 開発が終わってから文書を作る
→ 審査で破綻。根本原因は「規制対応を別タスク扱いにした設計思想」にあります。
❌ 規制の誤解（特に日米差） 日本は通ったから米国でも通ると思う
→ FDAで差し戻し。PMDA承認とFDA clearanceは要求の構造が異なります。
❌ セキュリティ軽視 SBOMなし、脆弱性対応なし
→ 市販後リスク増大。FDAは現在、市販後のサイバーセキュリティ対応を承認の前提として要求しています。
❌ 変更管理の不在 アップデートのたびに場当たり対応
→ 規制対応が破綻。変更管理はリリース後に最も問われる能力です。
最後に：規制は制約ではなく設計原則である
本連載の出発点は、「規制は開発の足かせなのか？」という問いでした。
結論は明確です。
規制は制約ではなく、優れた製品を作るための設計原則です。
• リスクマネジメント
→ 安全性の本質を問い続ける仕組み
• ライフサイクル管理
→ 品質を再現可能にする仕組み
• セキュリティ対応
→ 信頼性を市販後も維持する仕組み
これらを正しく理解すれば、規制はむしろ開発を加速させます。
おわりに
完璧なQMSを最初から作る必要はありません。しかし、本質だけは最初から外さないこと。
Lean-QMSは、その「本質を外さないための最小の設計」です。
この連載が、読者の皆様の開発を「後悔しないもの」にする一助となれば幸いです。
【次の連載へ】新シリーズのご案内
医療機器サイバーセキュリティ最前線―日米欧の規制ギャップと生き死にの戦略―
本連載「スタートアップのための実践ガイド」を引き継ぐ新シリーズでは、視点を「規制対応」から「規制戦略」へシフトします。
SBOM・PSIRT・AI SaMD変更管理など、現在業界で最も急造に重要度が高まるテーマを、経営戦略と接続する視点で解説します。
執筆・監修：酒井 由夫（Medical Software Consulting / xCAREエキスパート）
医療機器ソフトウェア開発コンサルタント／xCAREエキスパート
医療機器メーカーでのソフトウェア開発、規格対応支援経験を経て、外資系企業・医療スタートアップにて医療機器ソフトウェア（SaMD）の製品企画・規制対応・QMS運用の支援をはじめる。クラスII・III機器の開発～市販後に関するISO 13485、IEC 62304、ISO 14971、FDA対応、薬機法承認申請などの支援を専門とする。現在は医療機器ソフトウェア専門のコンサルタントとして独立し、国内外のスタートアップ・製販企業に対して、開発プロセス設計やチーム育成、技術文書の作成支援など、実行支援を提供中。
🔗 詳細プロフィール・個別相談をご希望の方は：
👉 酒井さんのコンサルティング会社サイトはこちら
医療機器ソフトウェア開発でお困りの方へ
「自社の開発体制、このままで本当に大丈夫だろうか？」
「海外規制も見据えた設計・文書化ができているか不安…」
そんな医療機器スタートアップ・開発チームの皆さまへ。
xCAREでは、実務経験豊富なエキスパートが並走し、後悔しない開発体制づくりを支援しています。
まずはお気軽に、現在の課題や懸念をお聞かせください。
👉 xCAREへのご相談はこちら（無料個別相談あり）
