「要求仕様のつくり方 ― 規制要求を“開発の言葉”に翻訳する」医療機器ソフトウェア開発の実践ガイド 第4回

はじめに：なぜ「要求仕様」でつまずくのか

医療機器ソフトウェアの開発において、
最もよく聞く悩みが「要求仕様書（SRS）をどう書けばいいのか」です。

「ユーザー要求と設計入力の違いがわからない」
「IEC 62304やFDAが言う“要求”はどれを指すのか」
といった質問は、スタートアップから大企業まで共通しています。

理由は単純で、“要求”という言葉が人によって意味するものが違うからです。

開発者にとっては実装仕様のこと、
QA担当にとっては規制への適合条件のこと、
そしてユーザーにとっては“こう使いたい”という希望のこと。

この三者のギャップを放置したまま進めると、リスクマネジメントもテストも後追いになり、最終的に「後戻りコスト」が跳ね上がります。

本稿では、この“要求のねじれ”をほどくために、要求仕様を3つの層で整理し、規制要求を開発が動ける言葉に翻訳する方法を解説します。

１. 要求を3つの層で整理する

IEC 62304やISO 13485、FDAのDesign Controlはいずれも「要求」という言葉を使いますが、意味の層が違います。
実務上は、次の3層構造で整理すると混乱を防げます。

ユーザー要求（User Needs）：医療現場・患者の課題を定義する
例：「誤挿入を防ぎたい」

規制要求（Regulatory Requirements）：安全性・有効性を保証するための法規・標準への適合
例：「IEC 62304 Class B以上に適合すること」

設計入力（Design Inputs）：開発が検証可能な形に落とし込む
例：「センサーの誤差は±2mm以内で表示されること」

要求は上から下へと具体化し、下から上へと検証される循環構造（V字モデル）で捉えるのがポイントです。

２. 書き方の原則：「開発が動ける言葉」で書く

要求仕様書を作る際の鉄則は、“開発者が迷わず設計し、テスト担当がYes/Noで判定できる文”にすることです。
そのために、医療機器版SMART原則（Specific, Measurable, Achievable, Relevant, Testable）を使います。

よくあるNG要求と改善例

ありがちな誤りは、意図は立派でも検証できない文になっていることです。

3. リスクとテストにつなげる ― トレーサビリティの実務

IEC 62304では、要求仕様はリスクコントロールとテストの接点に位置付けられています。
リスクを低減するための要求を設定し、その要求をテストで確認できていることが重要です。

こうした対応関係を1枚にまとめることで、審査官が追いやすい構造になります。

小規模チームにおすすめの「Lean-SRS」

スタートアップでは、SRSを完璧に書こうとすると開発スピードが止まります。
まずはExcelやGoogle Sheetsで「要求・リスク・テスト」の3列を持つ軽量版（Lean-SRS）から始め、1行に1要求を記載し、ステータスやコメントを追加する運用が現実的です。

Lean-SRSの狙いは、要求とリスクが切り離されないこと。
これが将来、正式なSRS文書の原型になります。

４.要求仕様レビューのチェックポイント

要求仕様は作って終わりではなく、レビューを行う必要があります。
IEC 62304の5.3.5でも「要求仕様の正当性を確認すること」と定められています。

まとめ：要求仕様は「翻訳」のドキュメント

要求仕様とは、
「規制」と「現場」、そして「開発チーム」の間の翻訳書です。

ユーザーの言葉を規制の言葉に、そして最終的に開発の言葉に変換する。
この翻訳がうまくいけば、リスクマネジメント、設計、検証のすべてが自然に流れます。

スタートアップが最初に身につけるべき品質文化は、この“翻訳力”です。

次回予告

次回（第5回）は、「設計検証と妥当性確認 ― テストで証明する品質」をテーマに、VerificationとValidationの違い、試験計画の立て方、小規模チームでも審査に通る証拠の作り方を解説します。

執筆・監修：酒井 由夫（Medical Software Consulting / xCAREエキスパート）

医療機器ソフトウェア開発コンサルタント／xCAREエキスパート
医療機器メーカーでのソフトウェア開発、規格対応支援経験を経て、外資系企業・医療スタートアップにて医療機器ソフトウェア（SaMD）の製品企画・規制対応・QMS運用の支援をはじめる。クラスII・III機器の開発～市販後に関するISO 13485、IEC 62304、ISO 14971、FDA対応、薬機法承認申請などの支援を専門とする。現在は医療機器ソフトウェア専門のコンサルタントとして独立し、国内外のスタートアップ・製販企業に対して、開発プロセス設計やチーム育成、技術文書の作成支援など、実行支援を提供中。

🔗 詳細プロフィール・個別相談をご希望の方は：
👉 酒井さんのコンサルティング会社サイトはこちら

医療機器ソフトウェア開発でお困りの方へ

「自社の開発体制、このままで本当に大丈夫だろうか？」
「海外規制も見据えた設計・文書化ができているか不安…」
そんな医療機器スタートアップ・開発チームの皆さまへ。
xCAREでは、実務経験豊富なエキスパートが並走し、後悔しない開発体制づくりを支援しています。
まずはお気軽に、現在の課題や懸念をお聞かせください。
👉 xCAREへのご相談はこちら（無料個別相談あり）

参考文献

IEC 62304:2006 + Amd.1:2015, Clause 5.2–5.3
ISO 13485:2016, Clause 7.3
FDA Design Control Guidance (1997)
IMDRF/SaMD N12: Application of Quality Management System