2020年の医療機器ソフトウェアに求められる要件の予想

前回のブログ記事『ソフトウェア製品の認証は可能か？』で，医療機器では「基礎安全，基本機能，基本性能」「リスクマネジメント」「ソフトウェアライフサイクル」「ユーザビリティ」の4つについて正当性を示すことが規制当局から求められると書いた。

適合が求められる規格でこのことを表すとこの図のようになる。

専用のハードウェアにソフトウェアを搭載する医療機器の場合は，製品安全規格として IEC 60601-1 と，ソフトウェアライフサイクルプロセス規格として IEC 62304 が求められる。汎用のITプラットフォーム上で動作する医療機器ソフトウェアの場合は，製品安全規格として，IEC 82304-1と ソフトウェアライフサイクルプロセス規格 の IEC 62304 が求められる。（IEC 82304-1 は規制要件になるかどうかはまだ決まっていない）

IEC 82304-1 は 2018年3月1日に JIS T 82304-1 として日本語で参照できるようになった。この規格の目次は次のようになっている。

JIS T 82304-1 目次

1. 目的及び適用範囲
2. 引用規格
3. 用語及び定義
4. ヘルスソフトウェア製品の要求事項
5. ヘルスソフトウェア－ソフトウェアライフサイクルプロセス
6. ヘルスソフトウェア製品のバリデーション
7. ヘルスソフトウェア製品の識別情報と附属文書
8. ヘルスソフトウェア製品の市販後活動

箇条5 は IEC 62304 を参照しているので，IEC 82304-1 がソフトウェアライフサイクルプロセスの要求として IEC 62304 を呼んでいる形になっている。

ようするに，ライフサイクルプロセスの要求に加えて，製品の要求事項を明確にした上で，バリデーションの計画，実施，報告を行い，製品の識別情報や附属文書への記載内容を指定し，さらに，市販後の活動も行うことでヘルスソフトウェア製品の安全を実現しようとしている。

なお，IEC 82304-1 は規制対象と規制対象外の両方のヘルスソフトウェアを対象としているのに対し，現在の IEC 62304 Ed.1.1は規制対象の医療機器ソフトウェアのみがスコープとなっている。そこで，IEC 62304 は Ed.2 において，IEC 82304-1 と同様に，規制対象と規制対象外のヘルスソフトウェアにスコープを拡大しようとしている。

どちらの規格も製品安全やリスク低減を目的としているのだが，今や規制対象のヘルスソフトウェアだけでなく，規制に至らないヘルスソフトウェアに対しても必要な要件があるという考え方だ。

IEC 62304 Ed.2 は現在検討中であり，2000年までには策定されると予想される。そこで，2020年時点でのヘルスソフトウェアの規格体系を予想してみると次のようになる。

IEC 82304-1 は ヘルスソフトウェアのソフトウェアライフサイクルプロセス規格である IEC 62304 Ed.2 を箇条5で呼んでいる。IEC 62304 が Ed.2 になると一般要求事項として 品質マネジメント，リスクマネジメント，ユーザビリティを要求するようになると予想される。

品質マネジメントは規制対象の医療機器の場合は，ISO 13485（ISO 13485 は ISO 9001の医療機器版で文書化要求などが強化されている） を 規制対象外の場合は，ISO 9001でもよしとし，リスクマネジメントは ISO 14971 を，ユーザビリティは IEC 62366-1 で適合を示してもよいという方向性が検討されている。

ちなみに，ユーザビリティは 使いやすさを目的にしたユーザビリティではなく，ヘルスソフトウェア製品の使用に伴うリスクを特定しコントロールすつためにユーザビリティエンジニアリングを要求している。また，セキュリティに関してもヘルスソフトウェアの安全に影響する脅威を特定，評価し，対策することを求めている。

医療機器ソフトウェアについては 2020年に向けて「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」を求めることで，医療機器ソフトウェアの製品安全を確立しようとしている。

このブログで繰り返し主張しているように，ソフトウェアのプロセス要求だけで，ソフトウェアの製品安全を示すことは出来ず，いろいろな確度から安全について証明していく必要があるということだ。

セキュリティはソフトウェア製品がネットワークで他のソフトウェアとつながるようになって，また，ユーザビリティはユーザインタフェースがリッチになるに従って，使い方を間違うことで危害に至ることが増えてきたことが背景にある。

また，バリデーションやリスクマネジメントが重要視されてきたのは，システムを構成する個々のソフトウェア部品の信頼性を高めることでは，システム全体の安全性や信頼性を確保できないほど，ソフトウェアは大規模・複雑化していることを示している。

「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」ひとつひとつが規格に適合しているしていないということに着目するのではなく，そのシステムに対してどの要求がどのように安全に寄与しているのかをよく考えて，全体として安全を確かなものにするにはどこを強く抑えると効果的かを考えることが求められるようになる。

規格適合は過程であって目的ではない。このことを忘れてはいけない。

ソフトウェア製品の認証は可能か？

先日，某所から「ソフトウェアの認証を行うとしたら，何を試験すればいいのか」という質問を受けた。まず，医療機器に搭載するソフトウェアや，そのものが医療機器となるソフトウェアのケースを説明し，その後，一般的なソフトウェアだったらどうなるのかと考えてみた。それが，この図だ。

規制対象となっている医療機器の場合，薬事申請する際にその医療機器の種類によって，基礎安全，基本機能，基本性能について申告をし，それらが規格を満たしていることの証明を提出しなければならない。それに加えて，リスク分析とその評価結果，リスクコントロール手段とそれを実施してエビデンス，ソフトウェアライフサイクルに関する要求，ユーザビリティに関する要求などを満たしていることを示し，最終的に妥当性の確認を行う。

ここで改めて，なぜソフトウェアを認証したいのかについて考えてみよう。そう聞かれるとおそらく，「ソフトウェアの品質を可視化したいから」とか「ユーザーが安心して使える指標にしたいから」という答えが返ってくるのではないかと思う。

で，ソフトウェアの品質って何だろうと思う。ISO/IEC 9126 のソフトウェアの品質特性を持ち出して，これらだという人がいるかもしれないが，それは違うだろう。
これらの特性は作る側の尺度であって，ソフトウェアを使う側の価値と相対しているとは思えない。

• 機能性（functionality）
• 信頼性（reliability）
• 使用性（usability）
• 効率性（efficiency）
• 保守性（maintainability）
• 移植性（portability）

ユーザーが知りたいのは，ソフトウェア（製品）の価値ではないか。製品の価値には2種類あって，顕在的な価値と潜在的な価値がある。顕在的な価値は，最初の図で言えば，基本機能や基本性能，ユーザビリティなどがそれに当たる。潜在的な価値は，（商品としての）安全性や信頼性だ。顕在的な価値は，製品のカタログやWEBサイトの説明にたいだい書いてある。潜在的な価値は，その通りに動くのか，また，不具合なく動き続けるのかがポイントとなる。ユーザーはソフトウェア（製品）の価値が高いか低いかを知りたいのだろう。ソフトウェア品質とソフトウェア（製品）の価値には相関があるようでいて，実はそうではないという側面もある。ソフトウェア品質はソフトウェア（製品）の価値の1つの側面でしかなく，しかも，ソフトウェアの価値を間接的にしか見ていないように思う。

ソフトウェア品質論の歴的推移を説明するときに毎度この図を使わせてもらっている。

そもそも，昔はソフトウェアについても不具合はゼロにしようという目標で品質論が語られてきたが，今ではそれは無理ということが分かってきたので，ソフトウェアの開発プロセスを管理することで，間接的にソフトウェアの品質を高めることが主流となってきた。

それでも，特に日本では価値や顧客満足を評価指標としてソフトウェアの品質が評価されることもあった。それが「当たり前品質」や「魅力的な品質」といった評価指標だ。

そもそも，ソフトウェア起因の障害は Systematic Failures/Faults （決定論的原因故障/障害）と呼ばれ，ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率率の予測が難しい故障/障害，出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。

とてもやっかいな障害だ。そして，Systematic Failures/Faults （決定論的原因故障/障害）は開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去するしかないというのが，一般的な考え方らしい。

だから，ソフトウェアの理想的なプロセスを定義して，その通りのソフトウェアが開発されたかどうか，また，ソフトウェアの開発組織が定義したプロセスに対して，どれくらい成熟しているかを図ることが主流となっている。ソフトウェアの場合，ドメイン知識を持たない者が客観的に評価しようと思ったら，結局のところ開発プロセスが定義どおりに行われているかどうかを見るしかなかったのだろう。

しかし，ソフトウェア製品の評価の図をもう一度見て欲しい。ライフサイクルプロセスの評価はソフトウェア製品の評価の一部でしかない。しかも，間接的な評価指標だ。

基本機能や基本性能を評価せずして，ライフサイクルプロセスの評価だけを行って，ソフトウェア製品の価値が計れるはずがない。ソフトウェアが意図する機能や性能をテストせず，開発プロセスだけを評価して，ソフトウェア製品の価値が計れるはずがない。ソフトウェア開発プロセスの完成度，成熟度が高いということは，相対的に「ソフトウェア品質が高いだろう」と予想できるといっているに過ぎない。実際に，そのソフトウェアの性能が高い，機能が期待通りかとうかを直接証明している訳ではない。それらを証明するためには，そのドメイン，その製品に特化したテストとテストのエビデンスが必要となる。「テスト計画を立てること」「テストを実施すること」「テストカバレッジが高いこと」は間接的な評価であって，「何のテストをしたのか」「設定した評価指標は正しいのか」「テストケースの境界値は合っているか」といった機能や性能の直接的な評価ではない。

前者がソフトウェアの開発プロセスの適合を検査するときの間接的な品質検査であり，後者がソフトウェアの直接的な品質検査だ。ソフトウェアの価値を知るためには，どちらも必要でどちらもやった方がいいが，より重要なのは直接的な検査だと思う。

電気的な安全性や機械的な評価などとは異なり，ソフトウェアを評価するのは難しい，こうなっていれば安全とか，こうなっていれば価値が高いと断定できるような，評価指標がない。だからといって，何の評価指標もないとユーザーがそのソフトウェアを選んでいいのかわからないという問題がある。しかし，生死に関わるようなソフトウェアでなければ，問題が発覚したら，アップデートするという解決策がある。

クリティカルなソフトウェア製品をライフサイクルの評価でユーザーにアピールするケースがあるが，それだけでは本当に本質を示していないと思う。基本機能や基本性能，どのようなテストを行ったのかなど，顕在的な価値や潜在的な価値を推し量るための材料はいろいろあるはずだ。賢いユーザーはそういった指標によって，ソフトウェア製品を評価するのだと思う。

ちなみに，ソフトウェアの評価に，基本機能や基本性能のテストを含めてしまうと，ドメイン知識がない認証機関はその指標が本当に正しいのかどうか判断がつかない場合がある。特にソフトウェアの場合は，難しいだろう。

だから，第三者認証を商売にしたい者は，ソフトウェアの基本機能や基本性能のテストをやりたがらないし，そこを評価したくないのだ。ソフトウェアの開発プロセスの認証なら，ドメイン知識がなくてもできるので，そればかりやりたがる。

ソフトウェアの認証は基本，自分で評価基準を決めて，自己認証し，その内容に嘘がないかどうかだけを見るようにすればいいのだ。誰かにお墨付きをもらうと考えること自体に無理があると思う。

ソフトウェア（製品）については，ドメイン知識があるものしか評価できない側面が多いと思った方がよい。だから，第三者がソフトウェア（製品）を評価する際には，その製品の開発者がどのようなテスト計画やバリデーション計画を立てているのか，その戦略やコンセプトはどのようなものか，テストケースは適切か，エビデンスに虚偽はないかといった点を見る必要がある。それは標準的なソフトウェア開発プロセスに従って開発を行っているかどうかという視点とはちょっと違う。

ソフトウェア（製品）の評価者はそのソフトウェア（製品）は価値が高いのか低いのかという視点を持って評価する必要がある。商品の価値は「意図する使用=Intended Use」を理解しないと分からない。

そして，ソフトウェア（製品）の開発者は，ソフトウェア（製品）の真の価値を評価できるのは第三者認証機関ではなく，自分達だということを認識すべきだろう。

第三者認証機関が評価できるのはあくまでもソフトウェア（製品）の価値の一面でしかなく，全体を見渡して評価できるのは，ドメイン知識を持った自分達だということだ。

「ASIL-Dを達成しています」の怪

最近，「ISO 26262 の ASIL D を達成しています」という汎用OSやソフトウェア部品の宣伝をネット上で見かける。

このような広告を見るたびに首をかしげたくなる。

左の図は，GHS（ヘルスソフトウェア推進協議会）のリスクマネジメントトレーニング講座で毎回使っているスライドだ。

Intended Use（意図する使用）が決まらないとリスク分析ができないという説明に使っている。

左の細長い木の棒は何に使うのでしょうか？という問いに対して，上がアイスキャンディーの棒で，下が医師が喉の奥を診るために使う舌圧子になるという説明だ。

ようするに，同じ形状，材料であっても，使用目的が変わるとアイスキャンディーの棒になったり，舌圧子（医療機器：電子機器でなくても Medical Device になる）になったりすることを説明している。

アイスキャンディの棒も舌圧子も滅菌はしているだろうが，医療機器とする場合は，法規制上のハードルも高くなる。舌圧子の場合，病気にかかっているかもしれない子供の口の中に入れるため，滅菌，包装，表面のなめらかさなどの要求が厳しくなる。裏返せば，「舌圧子が原因で菌に感染するリスク」「舌圧子が原因で口の中を傷付けるリスク」が想定され，そのリスクを受容するために求められる機能や性能を達成しないとリスクが残留してしまうということだ。

左の木の棒がソフトウェアだったらどうだろう。ソフトウェアは変更が容易なため，ソフトウェアを変更することによって Intended Use（意図する使用）が変わってしまうということはある。現在あるソフトウェアをユーザーの求めに応じて「使いやすくしたい」「より性能を高めたい」「より多くの機能を追加して付加価値を高めたい」と考え，実行することは良いことだが，それによってIntended Use（意図する使用）が変化し，予想していなかったリスクが潜在してしまうかもしれないことを考えているだろう。

例えば放射線治療器 Therac-25 は1980年台に死傷者6名を出すソフトウェア起因の事故を起こした。これらの事故の原因の１つに，コンソール画面上で各種の設定を行っている際に，途中で最初のモード選択が間違っていることに気付いたら，気付いた時点で修正をかけられるようにして欲しいという要望がユーザーからあった。その求めに応じて，ソフトウェアを変更したところ，コンソール上の設定値と，実際の機器の設定に不整合を発生させる不具合が生じて事故に至った。（IEC 62304 実践ガイドブック 2.1.2章で解説）

これは，ユーザインタフェースをソフトウェアで改善しようとしたところ，想定外の大きな新たなリスクを作り込んでしまった事例だ。

ソフトウェアシステムは規模が増大し，複雑化する一方だ。そのため，アーキテクチャ設計の重要性が再認識されているが，ソフトウェアの構造は見えにくいだけに，ぐちゃぐちゃなソフトウェアもたくさんある。

だからこそ，ソフトウェアの個々の部品の信頼性を積み上げて，システムの安全性を担保しようとすることには無理がある。ソフトウェアの個々の部品の信頼性を高める努力をしつつも，そこにも不具合があるかもしれないとい疑いを持って，システムが安全になるような設計をしなければならない。

だから，汎用のOTS/SOUPを取り上げて，それを使えばシステムが安全であるかのような主張はおかしいと思う。

なぜなら，その汎用部品が何に使われるのかによって，リスクは変わるからだ。リスクが変われば，リスクコントロール手段も変わる。システムにとって万能なリスクコントロールはない。

だから，汎用のOTS/SOUPができることは信頼性を高めることであって，安全性を高めることではない。

「想定した使用通りにちゃんと動きます」「こういった異常を想定した機能や性能を備えています」とは言えても，「このコンポーネントを使えば安全です」とは言えるはずがない。

信頼性が高いと自慢するOTSのテストのエビデンスを見せてもらったことも何度からある。確かに，大量のドキュメントを作っていることは分かる。しかし，テストシナリオが無限にあるようなOTS（例えばRTOS）では，テストの量だけならいくらでも増やせる。

問題は，テストケース，テストシナリオの質であったり，テスト設計者のテストに対するコンセプトが重要なのだ。OTSを使用する際に，ここは危ないとか，ここは注意しないといけないというケースをテストケースに組み入れているかどうかを見ないといけない。

だから，「OTSの設計プロセスが規格を満たしている」とか，「基準に適合している」と主張する会社の商品はかえって怪しいと思った方がよい。

それよりは，どんなテストをしているのか，どんなコンセプトでテストをしているのかといった，信頼性の根拠の中身を説明してくれる会社の製品を選んだ方がよいと思う。

自動車業界がこのことを身にしみて分かるようになるのは，おそらく2030年ごろではないかと予想している。その頃になると，電気自動車や水素自動車が普通になり自動運転だけでなく，さまざまな便利な機能が自動車に組み込まれるようになって，新規参入する企業も増え，汎用部品を組み合わせてアセンブリするだけの製造業者も増えるだろう。

そんな，機能がごちゃごちゃに組み合わさった状態では，「ASIL D の部品でござる」を主要な部分に使うだけではシステム全体の安全は確保できない。システムとしてどうやってリスクの高い部分と低い部分を分離するか（凝集度を高めて，結合度を下げるか）を考え，想定したリスクに対するリスクコントロール手段を実装するかが重要になるはずだ。

ようするに個々の部品の信頼性を高める個別最適の発想から，システム全体で安全を確保する全体最適の発想に考え方をシフトしていかないと，市場で発生するインシデントやアクシデントの追いつかなくなるのだ。

自動車業界は機械部品や電気部品の信頼性を高めることでシステムの安全性を担保する1960年台からある Zero-defect 的なやり方を2000年以降のソフトウェア開発にも無理矢理適用しようとしているように見える。「バグは１つでもあっては許さん！」「潔癖なソフトウェアを納品せよ！」といった感じ。

ソフトウェア技術者はもうとっくに限界に来ているやり方を無理強いされてさぞ苦労していると思う。その苦労もあと10年経つと限界だということが自動車メーカーも分かってきて，根本的に考え方を個別最適から全体最適の発想にシフトしないと安全は確保できないことが分かるようになると思う。