医療機器に搭載するソフトウェアの品質保証 �潟Cーコンプライアンス

医療機器に搭載するソフトウェアの品質保証

筆者がコンサルテーションを実施する中で、いつも驚くのは、医療機器企業におけるソフトウェア開発の未熟さである。
多くの医療機器企業では、新製品の納期に追われ、十分な検証やテストを実施せずに出荷しているケースがみられる。
また、ソフトウェア開発会社（ソフトウェアベンダー）に比べて、ソフトウェア開 発に携わる人数が極端に少ない。
さらにソフトウェア要員も適切な教育を受けていない場合が多く、不慣れ（未熟） なまま開発を行っている実態をよく目にする。

米国におけるFDAにかかわる年間の回収数（全品目）は9,000件前後にも上る。
そのうち医療機器に関しては、2014年度は1,283件の回収イベントで2,706品目が回収されている。
医療機器の場合、回収の原因のうちその過半数が設計問題である。
またそのうち8割以上がソフトウェアの欠陥によるとされている。

FDAは、医療機器の回収数を如何に減少させるかという課題に立ち向かっている。
また、医療機器企業においては、経営の健全化を図るためにCOPQを重要視しなければならない。
COPQとは、Cost Of Poor Quality の略であり、低品質や品質不良、欠陥、エラー のために生じる無駄なコストのことのことである。
例えば、設計変更、製品検査、回収、患者への補償、訴訟費用、計画変更やサイクルタイムが延びることで起こる売上機会損失、ブランド価値低下などの潜在的なものまで含めた余計な手間やコストのことである。
通常、企業では日常的に売り上げの25%〜30%の損失を発生させているといわれている。
ソフトウェアのライフサイクルにおいて、欠陥の発見がリリースに近いほど費用がかかる。
ライフサイクルの後期に発見された欠陥は、開発者による作業のやり直しが必要になることが多く、必然的にソフトウェアのリリースが遅れる。
この段階でエラーを修正するコストは、開発段階の100倍にもなる場合がある。
医療機器がが市場に出てからエラーを修正するコストは1000倍にもなりかねない。

品質を改善することは、余分に多大な時間と費用がかかると思いがちである。

品質活動に必要なコストは、活動人件費が大きいが、実際には費用を上回る効果が 実現出来る。
欠陥をを減少させる事によりCOPQは大きく改善されるのである。

Google社は、膨大なソフトウェアを提供し、かつ日々新しい機能を開発・リリース しているが、不具合がほとんどないことで知られている。
その理由は、テスト戦略にある。
「テストファースト」によるエンジニアリング生 産性の向上を図っている。
（参考文献：グーグルのテスト開発 日経BP社刊）

FDAは、医療機器に含まれるすべてのソフトウェアの詳細なベリフィケーションとバリデーション（V&V）を実施するよう医療機器企業に要求している。
一般的にソフトウェアのテストは、通常プログラムを実行させて実施するが、すべ ての条件分岐を検査することは不可能である。
システムテストで見つける欠陥の60%以上が、コーディングエラーに起因しているといわれる。
開発者がユーザの要件を単純に解釈してコーディングするためである。
システムテストをより短期間で効率的に実施するためにどうやってコーディングエ ラーを減少させるかが問題である。
従来の単体テストやソースコードレビュでは、多くの不具合が見落とされてきた。
これまでは、ベリフィケーションとバリデーション（V&V）は人手によって実施されてきた。
つまり、従来はプログラムのすべての条件分岐をチェックする唯一の方法は、手作業によるソースコードのレビュであった。
しかしながら、手作業によるソースコードレビュでは、担当者の力量に大きく依存 してしまう。
また、手作業によるソースコードのレビュやテストだけでは、ソフトウェアに起こりうる欠陥をすべて発見するという保証がない。
さらに膨大なソースコードを完全にレビュすることも不可能である。

一般的に、ソフトウェアが複雑なほど、潜在的なエラーが含まれている可能性が高 くなる。
FDAは、2010年4月に「Infusion Pump Improvement Initiative」（輸液ポンプの改 善に関する方策）というガイドラインを発行している。
このガイドラインの中でFDAは、上記のような不完全なソフトウェアのテストを補完するために、静的解析ツールの使用を推奨している。
最新の輸液ポンプには何万行というソースコードが含まれているが、これほどの規模のソースコード上で、欠陥をチェックするのは、至難の業と言える。
将来的にネットワークを介して、手術データや患者情報をリアルタイムで転送する ようになると、さらに問題が発生するする可能性がある。
これらのシステムのソフトウェアの欠陥を最小限に抑えるには、安全確保のための 新しい基準が必要になることは明確である。

用語集

• ア行
• カ行
• サ行
• タ行
• ナ行
• ハ行
• マ行
• ヤ行
• ラ行
• ワ行
• A
• B
• C 　
• D 　
• E 　
• F 　
• G 　
• I 　
• J 　
• M 　
• N 　
• O 　
• P 　
• Q 　
• R 　
• S 　
• T 　
• U