【連載】テストしても、品質は保証できない ——「価値を高めること」こそが品質保証の本質（第2回）

品質という概念の歴史を少し振り返ってみましょう。

20世紀初頭、品質管理は製造業から始まりました。統計的品質管理の時代です。「不良品の数を統計的に把握し、できる限り不良率をゼロに近づける」という発想が主流でした。

1960年代にはZD（Zero Defect）運動が広がります（図表1）。「最初からゼロ欠陥を目指せ」というスローガンのもと、工程における不良品の作り込みをなくすことが品質の定義とされました。

この考え方がソフトウェアの世界に持ち込まれると、「バグゼロを目指す」という目標に変換されます。テストは「バグを見つけてつぶす」ための活動として位置付けられ、カバレッジを上げることが品質向上の指標となりました。

しかし、ここに根本的な問題があります。ソフトウェアのバグは、ハードウェアの製造不良とは性質が違うからです。

ハードウェアの故障は確率論的に発生します。部品の劣化や製造上のばらつきを統計的に扱えるため、不良率を推定できます。ところがソフトウェアのバグは「系統的（決定論的）に」発生します（IEC 61508ではSystematic Failures/Faultsと呼ばれます）。特定の入力、特定の状態、特定のタイミングが重なったときにだけ顔を出すのです。（図表2）

Therac-25のバグがまさにそうでした。25.6秒に一度ゼロになる内部カウンターの瞬間に、熟練したオペレーターが素早くキー操作をしたときだけ発生する。このようなバグの発生確率を事前に統計的に推定することは、原理的に困難です。

現代のソフトウェアはTherac-25による事故当時より、さらに複雑です。数百万行のコードが絡み合い、クラウドやネットワーク、他システムと連携し、ユーザーの操作パターンは無限に近い。「全ての状態をテストで確認する」ことは、もはや不可能です。

この現実に直面したとき、ソフトウェアに対して品質工学の世界は方向転換を迫られました。「バグをゼロにする」から「バグが生まれにくいプロセスを作り、生まれたバグを早期に発見できる仕組みを作る」へ。テストは品質の「測定」手段ではなく、品質活動の一つの工程として再定義されていきます。これが「プロセスアプローチ」です。

一方で、日本の品質論は別の角度から重要な概念を生み出していました。

1980年代に提唱された狩野モデルは、品質を「充足していて当然の品質（当たり前品質）」と「充足されると顧客が喜ぶ品質（魅力的な品質）」に分けました。当たり前品質は、満たされていなければ顧客は不満を持ちます。しかし満たされていても、特別な満足は生まれません。魅力的な品質は、充足されると顧客は喜びますが、欠けていても不満にはつながらない。

この二分法は、品質の議論に重要な視点を加えました。「品質とは欠陥をなくすことではなく、価値を高めることである」という発想です。

医療機器の規制はこの考え方と深く共鳴しています。『IEC 60601-1医用電気機器－第1部：基礎安全及び基本性能に関する一般要求事項』が要求する二つの概念を見てみましょう。

基礎安全（Basic Safety）とは、機器が患者や使用者に直接の危害を与えないことです。これはまさに「当たり前品質」に対応します。人工呼吸器が誤作動して患者が呼吸できなくなる、放射線治療装置が過剰照射する——これらは起きてはならない。満たされていなければ製品として認められない、最低限の条件です。

基本性能（Essential Performance）とは、その機器が意図する目的（治療・診断・予防）を正しく果たすために欠かせない動作が確保されることです。これは「魅力的な品質」に近い概念です。患者に価値をもたらすための性能であり、これが担保されなければ医療機器としての存在意義がなくなります。

この構造が示していることは明快です。バグをゼロにすることは目的ではない。「この機器が患者にもたらすべき価値を、最大限に実現できているか」が問われているのです。

商品やサービスを使い続けてもらうには、カタログに掲載されるような「顕在的価値」（氷山の上に出ている部分）だけでなく、安全に使える、壊れてもすぐに直してもらえるといった「潜在的価値」も高くなければなりません。（図表3）

狩野モデルでは「魅力的な品質」は「なくても不満にならないが、あると嬉しい」という意味合いで使われます。医療機器において基本性能は、患者に治療・診断の価値を届けるために欠かせない要素であり、本来は「なくてよい」ものではありません。ここでは「顕在的な価値」つまりカタログに載り、選ばれる理由になる性能として位置付け、「潜在的な価値」である基礎安全と対比させています。製品やサービスが選ばれ続けるためには、どちらも欠かすことができません。（図表4）

だからこそ、商品やサービスの価値を高めるためには、ソフトウェア開発に対して何をすべきかを常に考えながら行動することが重要なのです。

では、医療機器において最も根幹となる価値である「安全」とは、そもそも何を意味するのでしょうか。

ここで、医療機器QAの根幹にある概念を確認しておきましょう。

ISO 14971（医療機器のリスクマネジメント）は、安全（Safety）をこう定義しています。

安全とは、受容できないリスクがないこと（ISO/IEC Guide 63）

この一文を、よく読んでください。「リスクがないこと」ではありません。「受容できないリスクがないこと」です。

ISO/IEC Guide 51:1999（Guide 51 は 2014年に改訂されていますが、あえて1999年版の説明を参照しています。）はこの定義について、さらに4つの重要な原則を示しています。

自動車を例に考えてみましょう。かつて、自動車にABS（アンチロック・ブレーキング・システム）は存在しませんでした。急ブレーキ時にタイヤがロックして制御を失うリスクは、当時は「やむを得ないもの」として受容されていました。技術的に解決する手段がなかったからです。ABSが開発されると、実装コストが下がり、その有効性が証明されると、状況が変わりました。「ABSを搭載しないことで生じるリスク」はもはや受容できないものとなり、今日では標準装備として当たり前の品質になりました。

これはまさに、安全の「見直し」が起きた例です。技術革新によってリスク低減が可能になったとき、それを採用しないことは受容できなくなる。かつては「魅力的な品質」だったものが、時代とともに「当たり前品質」へと移行するのです。

コストをかければかけるほど強固なリスクコントロールを実現できるかもしれません。しかし、製品やサービスにおいて無限にコストをかけることはできません。リスクが許容可能かどうかは「利用者の利便性」「目的適合性」「費用対効果」などの諸要因のバランスで決定されるのです。(図表5)

安全は、一度達成すれば終わりではありません。技術と社会の変化に応じて、何が受容できて何が受容できないかを問い続ける必要があります。医療機器QAが市販後監視（Post-Market Surveillance）を義務としているのは、まさにこの理由からです。

では、「どこまでリスクを許容するか」という判断は、実際にどのような考え方で行うのでしょうか。

その判断の枠組みとして医療の世界で確立されているのが、「ベネフィット・リスク分析」という考え方です。

医薬品の世界ではなじみの深い概念です。副作用があっても薬効が高い薬は承認されます。リスクが残っていても、その医薬品がなければ患者が受けられない治療があるなら、残留リスクは許容される。これは「価値の判断」です。バグがあるかないかではなく、「トータルで患者にとって価値をもたらすか」を問うのです。

この発想は、医療機器に限りません。ソフトウェアサービスにおいても、不具合ゼロのサービスを目指すより、「このサービスがユーザーにもたらすベネフィットがリスク（不具合・障害の影響）を上回っているか」を常に問うことが、品質保証の本質です。しかし、このようなトータルの価値判断は、個々の機能をテストして不具合を潰していくだけでは実現できません。テストには、もうひとつの本質的な限界があるからです。

安全設計の世界には、個別最適と全体最適という二つの発想があります。（図表6）

フォールト・アボイダンス（個別最適の発想）は、個々のコンポーネントの信頼性を高め、バグや故障をゼロに近づけようとする設計思想です。テストを増やしてバグをつぶす、コードレビューで品質を上げる——これはフォールト・アボイダンスの延長にあります。

一方、大規模・複雑なシステムでは、個々の信頼性を積み上げるだけでは安全は確保できません。全体最適の発想はここから生まれます。フェール・セーフは「コンポーネントが故障しても、システム全体が安全側に落ち着く設計」、フォールト・トレランスは「障害が起きても冗長性で機能を維持する設計」、エラー・プルーフは「操作を間違えても危険が生じない設計」です。

これらに共通するのは、「バグや故障は起きることを前提とする」という思想です。問題をゼロにすることではなく、問題が起きたときにシステム全体がどう振る舞うかを設計するというアプローチです。

テストは本質的にフォールト・アボイダンスの活動です。バグを見つけてつぶすだけでは「全体として患者を守る仕組み」にはなりません。ISO 14971が要求するリスクマネジメントは、この「全体最適の発想」を、設計段階から組み込む仕組みです。

ここまでの議論を踏まえると、テストの目的が変わります。

従来の目的である「バグをゼロにすること」ではなく、「この製品が意図する価値を提供できることを確認すること」になります。この転換は、テスト戦略に直接影響します。

医療機器QAでは、IEC 62304がソフトウェア安全クラス（Class A / B / C）を定め、クラスに応じてテストの厳格さを変えています。これはリスクベースのテスト戦略です。患者に与える危害の可能性が高い機能（Class C）には厳格なテストを、影響が限定される機能（Class A）には最小限のテストを。全機能に同じ深さでテストに労力をかけることは非効率であり、リスクの高いところに工数を集中させることが求められます。

この発想はあらゆるソフトウェア開発に応用できます。

• 当たり前品質（基礎安全に相当）を守るテスト：これが崩れると製品の存在意義が失われる。障害時の安全動作、データの整合性、セキュリティの基本要件、こういったことへ妥協なく工数を投じる。
• 魅力的な品質（基本性能に相当）を高めるテスト：ユーザーに価値をもたらす機能の正確さ、パフォーマンス、使いやすさに対して集中することで製品の競争力を生む。

限られた時間と工数の中で何をテストするかを決める判断軸は、「バグの数を減らすこと」ではなく「製品がもたらす価値を最大化すること」であるべきです。そのためには「このテストは、どの価値を守るためのものか」を常に問いながらテスト設計する必要があります。

ソフトウェアの品質向上施策（図表7）にあるように、ソフトウェアの品質を高めるためには、プロセスアプローチとともに、不具合を作り込まない努力や不具合を摘出する努力、個々のプロセスに対するベリフィケーション、ユーザー要求を満たせているかどうかを確認するバリデーションなど、さまざまな活動が必要です。

AIが台頭してきた現在、コード生成やテスト自動化など個々の作業はAIの助けを借りて効率化できるようになりました。だからこそ、製品やサービスの価値を高めるために何をすべきかを問い、その結果を確認する責任は、人間が担い続けなければなりません。

医療機器QAが長年向き合ってきたのは、まさにその問いです。「バグがないこと」ではなく、「この製品が患者にとって価値をもたらしているか」。プロセスアプローチとリスクベースアプローチの組み合わせは、その問いに体系的に答えるための仕組みです。

バグゼロは幻想です。しかし、価値の最大化は追求できます。その追求は、医療機器であれ、一般のソフトウェアサービスであれ、根本的には同じ問いから始まります。
「あなたは今、なんのためにそのテストを実施していますか？」

次回予告

第3回は「FDAは何を見ているのか？」をテーマに取り上げます。規制当局が製品審査で求める「証拠の構造」とは何か。「テスト結果を提出する」ことと「安全性を証明する」ことは、どう違うのか。FDA（米国食品医薬品局）と日本のPMDA（医薬品医療機器総合機構）が見ている視点を解説します。

参考文献・規格

医療機器の基本要件基準（厚生労働省告示）第12条
IEC 62304:2006/AMD1:2015 「医療機器ソフトウェアーソフトウェアライフサイクルプロセス」
ISO 14971:2019 「医療機器ーリスクマネジメントの医療機器への適用」
ISO/IEC Guide 63 「医療機器規格への安全性側面の組込みに関するガイド」

参考サイト

ポータルサイト：https://www.medicalsoftwareconsulting.com/
規格解説動画：https://www.youtube.com/@MedicalSoftwareConsulting
医療機器ソフトウェア 規制・規格 知識データベース：https://watch.medicalsoftwareconsulting.com/