2018-01-08

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

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

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

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

で,ソフトウェアの品質って何だろうと思う。ISO/IEC 9126 のソフトウェアの品質特性を持ち出して,これらだという人がいるかもしれないが,それは違うだろう。
これらの特性は作る側の尺度であって,ソフトウェアを使う側の価値と相対しているとは思えない。
  • 機能性(functionality)
  • 信頼性(reliability)
  • 使用性(usability)
  • 効率性(efficiency)
  • 保守性(maintainability)
  • 移植性(portability)
ユーザーが知りたいのは,ソフトウェア(製品)の価値ではないか。製品の価値には2種類あって,顕在的な価値と潜在的な価値がある。顕在的な価値は,最初の図で言えば,基本機能や基本性能,ユーザビリティなどがそれに当たる。潜在的な価値は,(商品としての)安全性や信頼性だ。顕在的な価値は,製品のカタログやWEBサイトの説明にたいだい書いてある。潜在的な価値は,その通りに動くのか,また,不具合なく動き続けるのかがポイントとなる。ユーザーはソフトウェア(製品)の価値が高いか低いかを知りたいのだろう。ソフトウェア品質とソフトウェア(製品)の価値には相関があるようでいて,実はそうではないという側面もある。ソフトウェア品質はソフトウェア(製品)の価値の1つの側面でしかなく,しかも,ソフトウェアの価値を間接的にしか見ていないように思う。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2017-10-22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2017-07-26

医機連から公開されたIEC 62304適用に関する質疑応答集(Q&A)

医機連(一般社団法人日本医療機器産業連合会)が2017年5月17日に厚労省から発出された『医療機器審査管理課長通知:医療機器の基本要件基準第12条第2項の適用について』の運用に関する留意点について,質疑応答集(Q&A)を公開した。

ようするに,IEC 62304(JIS T 2304)への適用に関する通知が5月17日に厚労省から出たが,その通知だけではよく分からない点があるので,業界の総意として質疑応答集(Q&A)を公開したということである。

医療機器審査管理課長通知:医療機器の基本要件基準第12条第2項の適用について』では,2017年11月25日から適用される医療機器の基本要件基準(平成17 年厚生労働省告示第122 号)の第12 条第2項の規定(プログラムを用いた医療機器に対する配慮)に適合するためには,基本的に JIS T 2304(IEC 62304)に適合することや,薬事申請時に JIS T 2304 への適合性を説明する資料の記載事例などが説明されている。

医機連から公開された 質疑応答集(Q&A)は,この厚労省通知だけでは,実運用上不明な点をクリアにするために作成された。

医機連(一般社団法人日本医療機器産業連合会)は保健・医療用の用具、機器、器材、用品等の開発、生産、流通に携わる事業者団体の参加のもと、1984(昭和59)年2月に設立された,医療機器系の業界団体の元締めである。

今回発行された質疑応答集(Q&A)は,医機連の法制委員会配下の医療機器プログラム対応WGで策定したものだ。

機能安全規格である IEC 61508 や IEC 26262 と IEC 62304(医療機器ソフトウェアーソフトウェアライフサイクルプロセス) の違いは,IEC 62304 は各国の医療機器規制に付随する基準の適合確認のために使用される点である。

そのため,企業から見れば,その規格に適合(当該規格への適合が絶対条件ではないが・・・)していないと商品を売れなくなるかもしれないため,規格の運用についても詳細なルールが必要だ。

2017年5月17日に発出された厚労省通知だけでは,その詳細な運用ルールが分からないところがあるので,通知の行間を埋める質疑応答集(Q&A)が必要となる。

例えば,IEC 62304(JIS T 2304)は IEC版では2006年版と2012年版があり,JIS では 2014年版と2017年版がある。初版と追補版の二種類が存在する。医療機器の基本要件基準第12条第2項では,「最新の技術に基づいたライフサイクルプロセス」への適用を求めているため,新しい方の規格の方に適合する必要がありそうだが,旧規格からの移行期間はあるはずだ。前述の厚労省通知には規格の版については何も書いていない。しかし,初版の移行期限はいつかがはっきりしないと運用ができない。

そこで,今回,質疑応答集(Q&A)で,移行期限は 2022 年 2 月 28 日までの移行を推奨とするという見解が示された。

また,本ブログでも取り上げた『汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない』についても,医機連の見解が下記のように示された。
Q02:医療機器に搭載する OTS(off-the-shelf、市販されている既製の)ソフトウェアについても、第 12 条第 2 項への適合を示す必要がありますか。
A02:基本要件基準第 12 条第 2 項は、プログラムを用いた医療機器に対する要求事項を規定したものであり OTS 等を含むプログラム全体として JIS T 2304 への適合を示すことが求められます。なお、医療機器を構成する個々のプログラムの構成要素(製造販売業者の開発品や OTS など)を個別に適合を確認することは求めていません。
これにより,医療機器が搭載するOTS(off-the-shelf、市販されている既製の)ソフトウェアに対して IEC 62304 の個別の適合は求めていないことがはっきりした。

なぜ,OTS(off-the-shelf、市販されている既製の)ソフトウェアが単独で IEC 62304 に適合することが規格の趣旨を逸脱している(規格が本質的に何を目指しているのかを理解していない)のかについては,『汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない』を読んでいただきたい。

IEC 61508 や IEC 26262 は各国の法規制の要件にはなっていないと思う。そのせいかもしれないが,これらの機能安全規格は OTSの開発プロセスに対する規格の適合を推奨している。

規格が規制に使われる場合,できているかいないかが,法に適合しているかどうかの判断材料になることがある。よって,規格の適合が努力目標では済まない場合もあるし,製造業者の法的な責務となるケースがある。

IEC 62304 の場合,医療機器製造販売業者に対する責務という側面があり,OTSソフトウェア供給者はその責務を直接負うことができないため,OTSソフトウェアの単独認証が意味がないという面もある。業界の構造やサプライチェーンのしくみが根本的に違うから,そういった相違が生まれるのかもしれない。

ちなみに,医薬品,食品,医療機器,化粧品などの分野でレギュレトリーサイエンスという分野の科学が検討されつつある。(レギュレトリーサイエンス学会のサイト

レギュレトリーサイエンスとは
レギュラトリーサイエンスとは我々の身の回りの物質や現象について、その成因や機構、量的と質的な実態、および有効性や有害性の影響をより的確に知るための方法を編み出し、その成果を用いてそれぞれの有効性と安全性を予測・評価し、行政を通じて国民の健康に資する科学です。
言わば規制の有効性や規制がもたらす安全性を科学しようという取り組みだ。医療や食品だけに有効な科学ではないだろうから,他の業界にも広がっていくのかもしれない。

いずれにせよ,医療機器ドメインでは医機連から質疑応答集(Q&A)が発行されたことで,今後は IEC 62304 への適合を単独で示すOTSソフトウェアは出てこないだろうと思う。