2017-04-23

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

ソフトウェアの変更容易性は最大のメリットだが,最大のデメリットでもある。信頼性の高いソフトウェアを苦労して作り上げても,たった一行の変更で,とんでもないバグを作り込んでしまうことができる。

仕上げたソフトウェアに対してシステムテストをどれだけ繰り返してもなかなか不具合は収束しないし,非常に分かりにくい問題が残ったまま出荷されることもある。

だからこそ,ソフトウェアの品質を高めるためにソフトウェアの開発プロセス,保守プロセスを管理する方法が研究され,実践されてきた。近代のソフトウェア品質論の歴史はソフトウェア開発プロセス研究の歴史といっても過言ではないだろう。

しかし,クリティカルなシステムにとっては次のことが成り立つ。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

もしも,明確な危害を防ぐリスクコントロール対策が講じられるのならば,そのリスクコントロール対策を確実にすることを優先した方がよい。

極端なことを言えば,ソフトウェア開発プロセスが十分でなくても,リスクコントロール対策が確実であれば安全な場合はある。ハードウェアによるリスクコンロールが確実に効いていて,ソフトウェアの不具合があっても安全が確保されることはある。

例えば,ソフトウェアが何らかの出力エネルギーを制御していても,過大なエネルギーの出力のみを防げば危害に至らないのであれば,ハードウェアのリミッタがリスクコンロール手段になりうる。

ところが,問題がエネルギーが過大かどうかではなく,出力の信号波形がだったりするとハードウェアのリスクコンロールでは難しい。電気メスの出力を凝固のパルスにしたつもりが切開のパルスになってしまうようなケースだ。

この場合こそ危害に結び付かないためのソフトウェアによる安全設計を行い,その設計が有効になっていることを確かにするためのプロセス管理を行う必要があるのだ。

ここで強調しておきたいのは,ソフトウェア品質を高めるのにプロセスアプローチは有効だが,製品やシステムの使用に対する安全を確保するために優先すべきはリスクコントロールであるということだ。

それを逆転して考えては絶対にダメだ。「ソフトウェアの開発プロセスがキチンと管理されていれば,システムは安全だ。」などと考えるのは愚の骨頂だ。

ちなみに IEC 62304(医療機器ソフトウェアーソフトウェアライフサイクルプロセス)は,プロセスアプローチとリスクベースアプローチの組合せだから,単純なプロセス管理ではない。

何が違うかと言えば,プロセス管理をする前にリスク分析を行い,危害に至らないようなリスクコントロールを行い,主にリスクがコントロールされていることを管理するアプローチとなっている。

だから,極端な話,ソフトウェア開発プロセスが規格要求通りにできていなくても,想定した危害がリスクコントロール手段で対策できていれば,規格の本質的な趣旨としてはよいと言える。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

なのはそのためだ。そのことを忘れで,規格に適合することばかり考えていると,本末転倒のことが起こる。IEC 62304 に適合しているのに,危害が発生してリコールになってしまうとか,意図する使用が確定しておらずどんなリスクが想定されるのか分からないままOTS(汎用の市販ソフトウェア)の開発プロセスが IEC 62304 に適合していると言ったりする。

ソフトウェア開発プロセスを生業としている人々は,いったいなんのためにソフトウェア開発プロセスを管理しているのか,その活動が開発者やエンドユーザーにどんな価値を生み出しているのかを考えてみるとよいと思う。

IEC 62304 は一般のソフトウェア開発で行われている ソフトウェア開発プロセス管理 とは別に,ソフトウェアリスクマネジメントプロセス を持っている。これは,危害の一因となりうるソフトウェアアイテムやリスクコントロールに関わるソフトウェアのプロセス管理(要求定義,検証,トレーサビリティ,変更管理)を実施することだ。

リスク低減に関するソフトウェアのプロセス管理があることが,一般的なソフトウェア開発プロセスと異なる。更に言えば,IEC 62304 はソフトウェアプロジェクト管理の際に,重要視される予算管理や日程管理の要求がない。

医療機器ソフトウェアやヘルスソフトウェアのソフトウェアプロセス管理の第一目的はリスク低減なのだ。

それを理解しておかないと,ソフトウェア開発のプロセスを管理するという手段が目的になってしまう。

それって,医療機器ソフトウェアの世界の話だけじゃないんじゃないかと思う。ソフトウェア開発プロセスの管理能力の向上が,開発者やエンドユーザーにとってどんな価値を生み出すのかなぜなぜ分析してみるとよいのではないだろうか。


P.S.

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

をレビューワ-が意識するかしないかでソフトウェアレビューの内容も変わってくる。意識していれば,危害が発生しないか,発生しないためのリスクコントロールがキチンと管理されているかに重点が置かれるが,意識していないと,プロセス要求の一つ一つに適合しているかどうか重箱の隅をつつくことになる。

対象となるソフトウェアやソフトウェアが搭載されるシステムがどのように使われるのかをよく知らない,知りたいと思わないレビューワ-ほど,重箱の隅をつつくことに一生懸命になり,指摘が多くなればなるほど,自分が規格に詳しいことに対して鼻高々になるようだ。

ソフトウェア開発プロセス管理 < 危害を防ぐリスクコントロール対策

を理解しているレビューワ-はどうしたら危害を防げるのか,リスクコントロールが効いている状態を保てるのかを開発者と一緒になって考えるし,プロセス管理の甘さがどうして危害につながる可能性があるのかを指摘し,説明することができる。

2017-04-15

「ブレーキを踏むのを我慢してください」で自動車運転死傷行為処罰法違反

2016年11月に自動ブレーキ機能を備えた日産自動車の試乗車が前方の信号待ちをしていた車に衝突し,30歳代の夫婦に軽傷を負わせ,運転手が自動車運転死傷行為処罰法違反(過失運転致傷)容疑で千葉地検に書類送検された。

「ブレーキ我慢を」と指示…自動運転車で追突(YOMIURI ONLINEより)

状況としては,試乗車に同乗した自動車販売会社の社員が自動ブレーキ機能を体験させるために「ブレーキを踏むのを我慢してください」と指示し,当時,暗くて雨が降っている状況で前方の車を検知できず衝突してしまったらしい。ちなみに,試乗車の運転手に誤った指示をした日産自動車販売店の営業社員(28)と店長(46)も業務上過失傷害容疑で書類送検された。

この事件は,今後来るであろう自動運転社会において発生する事故の責任問題を予見させる。

今回のケースでは,現在の法律(自動車運転死傷行為処罰法)において運転手の過失が問われた。

では,自動ブレーキが当たり前になってきた昨今,自動ブレーキ機能を信頼してたユーザーがブレーキを踏むのが遅れたために,衝突事故を起こした場合も運転手サイドに100%の過失が問われるのだろうか。それとも,自動ブレーキを搭載している自動車メーカーにも製造物責任が問われるのだろうか。

医療機器の世界では,リスクマネジメントの事例でこれと同じような問題を考える。

ポイントはユーザーの行為が誤用なのか正常使用なのかの判断だ。製造業者が意図する使用(Intended Use)の通りにユーザーが使用したのであれば,正常使用だし,そうでなければ誤用というのが基本だ。

ISO 14971(医療機器−リスクマネジメントの医療機器への適用)では合理的に予見可能な誤使用(Reasonably Foreseeable Misuse)に対するリスクコントロールは製造業者側が講じることになっている。

しかし,合理的に予見可能かどうかの判断は,メーカーサイドの見解とユーザーサイドの見解では異なる。

一般的に,メーカーが異常使用と考えていても,ユーザーはあり得る使用と考える部分がある。このギャップは人間工学設計で埋めていくことになるが,基準が曖昧であると製造者側の主張が通るようになり,現実には危ないケースも出てくるため,近年,患者や使用者のリスク低減を目的にユーザビリティの規格が規制に使われるようになってきた。(IEC 62366-1, Medical devices - Part 1: Application of usability engineering to medical devices, 医療機器-第1部:医療機器へのユーザビリティエンジニアリングの適用)

ユーザビリティエンジニアリングを適用するにしても,機器の使用に関して,製造業者側が 意図する使用(Intended Use)をキチンと定義していなければ,合理的に予見可能な誤使用かどうかの判断はできない。

冒頭の例でいれば,自動車メーカーは自動ブレーキについて意図する使用(Intended Use)をどう定義しているのかということだ。

おそらく,自動車メーカーは自動ブレーキを運転手がブレーキを踏むという行為に対して遅れや誤使用(例えばブレーキの代わりにアクセルを踏むなど)があった場合の補助,サポート機能と定義していると思う。

そうであれば,冒頭の例は,ブレーキを踏めば踏めたのに踏まなかったので基本的には誤使用となる。ただし,合理的に予見可能な誤使用であれば,製造業者側にも責任が生じる可能性がある。合理的に予見可能かどうかは,ユーザーサイドが「いざというときに自動ブレーキが動作するのは当たり前」と考えているかどうかにもかかってくる。

「当たり前に動作するはず」の機能が動作せずに事故になったなら,ユーザーはその事故の責任は製造業者側にあると考える。雨天などの状況では「動作しないことがある」のであれば,雨天でも自動ブレーキが動くはずと考えて自動ブレーキに頼ることは,合理的に予見可能な誤用となる。この場合,製造業者はこの合理的に予見可能な誤用に対して,リスクコントロール手段を講じなければいけない。

取扱説明書に「自動ブレーキは雨天では動作しないことがあります」という注意文を掲載することは,リスクコントロール手段にはならないと考えた方が良い。なぜなら,ユーザーはそんな注意文は読み飛ばしてしまい,記憶に留めることはないからだ。

よって,リスクコントロール手段としては,例えば,ワイパーを動かしているときは,「自動ブレーキが効かないかもしれないランプ」を点灯させるなどして,運転手に自動ブレーキを頼れないことを分からせるようなことをする。

このようなリスク分析を行うには,自動ブレーキの意図する使用を製造業者側できっちり定義できていないとうまくいかない。ユーザーの行為が誤用なのか,正常使用なのかよく分からなくなってしまうからだ。意図する使用がはっきりしていないと,警告文や注意文を作っていても,それが製造業者の保身のためなのか,本当に危ないからやめさせないといけないのか訳がわからなくなってくる。

意図する使用(Intended Use)を曖昧にしておいて,取扱説明書には山ほど禁忌禁止事項が書いておくという方法は,実際にはユーザーがその禁忌禁止事項を守っておらず,その状況を製造業者が黙認していると判断されると裁判で負けることもある。

製造業者側の言い訳を注意文で主張しておいて,実際にはリスクに対するリスクコントロールを行っていない状況では,製造業者サイドの責任は回避できないこともある。

実際,機器の開発者が,製造物責任を逃れるために,過剰に禁忌禁止や注意を取扱説明書に書いておきながら,セールス部門がそれらを十分に理解せずに,本来はやってはいけないことをユーザーにアピールしてしまうということはある。

セールスは他社より優れいてる機能や性能をアピールして売り上げを上げたい訳だから,それも無理はないように思えるが,それが「安全」に関係する機能や性能である場合は,特に慎重になる必要があるし,「安全」を宣伝するのは,後でしっぺ返しが来る。

製品を売りたいがために開発者側が「やってはいけない」としていることについて「取扱説明書にはダメって書いてありますが,他のお客さんはやってますよ」などとセールスに言わせてはダメだ。

今回の試乗車の自動ブレーキが動作せずに衝突してしまったのもその例の一つだろう。

リスクマネジメント的に言えば,やってはいけないことがあるのであれば,それはユーザーにキチンと伝えなければいけないし,実際にユーザーがそのリスクを認識している状態になっていなければ意味がない。

今国会で成立した民法の改正でも,消費者側の権利が見直され,契約において消費者に一方的な不利な条項は無効となった。

自動ブレーキは自動車各社ともCMで盛んに宣伝しているが,その結果,消費者に自動ブレーキはいざというときに動作し,危険を回避できるという認識が,一般常識となったら,いくら取扱説明書で免責を書いても,製造業者側の責任は問われるであろう。

自動車メーカーが自動ブレーキを宣伝した後,一瞬,免責事項を出しているが,あれは消費者が内容を認識して,理解していなければ意味がない。

ちなみに,自動ブレーキの動作不良による事故が多発するようになると,今度は国が基準を作って認可をすることになるかもしれないが,その場合,認可をした国にも責任が生まれる。

認可したのに自動ブレーキが動作せずに事故が起こったら,認可した側の責任が問われる可能性もあるのだ。

安全を売り物にするな」という記事が以前書いたが,そうすると自分自身にしっぺ返しがくるからだ。安全は,当たり前にできていることが基本で静かに粛々と実装した方がよい。

2017-03-12

汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない

汎用ソフトウェア製品(製品開発プロセス)は IEC 62304(JIS T 2304) に適合できない。その根拠を JIS T 2304:2017 の箇条7 で説明したいと思う。

そもそも,IEC 62304 は医療機器製品のライフサイクルプロセスに適用し,医療機器のソフトウェアに起因する危害(特に患者に対する危害)を医療機器のライフサイクルプロセスを管理することで低減することを目的に作られている。

ライフサイクルプロセス規格といっても,医療機器製品の Intended Use(意図する使用)や使用目的,使用環境が定まっていることを前提にしている。

また,箇条3 によって,医療機器リスクマネジメント規格である ISO 14971 が引用規格になっており,対象となる医療機器のリスク分析が必須となっている。

したがって,何の医療機器に使うのか特定されていない汎用のソフトウェア製品では,どんな医療機器に搭載されるのかが定まっていないため,危害を想定することができない。

その点を頭に入れながら,IEC 62304 の箇条7 を見ていく。

7 ソフトウェアリスクマネジメントプロセス
7.1 危険状態を引き起こすソフトウェアの分析
7.1.1 危険状態の一因となるソフトウェアアイテムの特定
 製造業者は,JIS T 14971に規定した医療機器のリスク分析を行い,危険状態及び危険状態を引き起こす可能性のあるソフトウェアアイテムを特定する(4.2参照)。(クラスB,C)

注記 危険状態は,ソフトウェアの故障が直接の原因となる場合,又はソフトウェアに実装したリスクコントロール手段の故障が原因となる場合が考えられる。

→医療機器の Intended Use(意図する使用)や使用環境,医療機器の基本機能,基本性能が定まれば,リスク分析を行うことができ,想定される危害や危険状態を想定することができる。そして,危険状態を引き起こす可能性のあるソフトウェアの障害や,その障害の原因となるソフトウェアアイテムが特定できる。

7.1.2 危険状態の一因となるソフトウェアアイテムの潜在的原因の特定
 製造業者は,7.1.1で特定した危険状態の一因となるソフトウェアアイテムの,潜在的原因を特定する。

→医療機器のリスク分析がないと,危険状態の一因が特定できない。そのため,危険状態の一因となるソフトウェアアイテムが特定できない。汎用で重要なソフトウェアなのでソフトウェアアイテムすべてが危険状態の一因となりますとか,潜在的要因はあらゆることを考えていますといったスタンスをとろうとするなら,それは規格の前提条件である「完璧なソフトウェアなどあるはずがない。したがって,その医療機器の使用において想定される危害とリスクを重要度の高いところから優先的に低減する」という概念が理解されていないことになる。

製造業者は,必要に応じて,次に挙げるような潜在的原因を検討する。(クラスB,C)

a) 誤った又は不完全な機能仕様
b) 特定したソフトウェアアイテムの,機能におけるソフトウェア不具合
c) SOUPに起因する,故障又は予期せぬ結果
d) 予測できないソフトウェア動作を引き起こす可能性のある,ハードウェアの故障又は他のソフトウェアの欠陥
e) 合理的に予見可能な誤使用

7.1.3 公開されたSOUP異常リストの評価
 SOUPに起因する故障又は予期せぬ結果が,危険状態の一因となるソフトウェアアイテムの潜在的原因になっている場合,製造業者は,当該医療機器に使用しているSOUPアイテムのバージョンに関係する,SOUPアイテムの供給者が公開している異常リストを最低限度として評価し,既知の異常のいずれかによって,危険状態の原因となる可能性がある一連の事象が生じるかを判断する。(クラスB,C)

7.1.4 潜在的原因の文書化
 製造業者は,危険状態の一因となるソフトウェアアイテムの潜在的原因を,リスクマネジメントファイルに文書化する(JIS T 14971参照)。(クラスB,C)

→リスクマネジメントファイルは医療機器製造業者が作成するものであるから,汎用のソフトウェア製品の製造業者が「潜在的原因の文書化」をしても意味がない。

7.2 リスクコントロール手段
7.2.1 リスクコントロール手段の選択
 製造業者は,リスクマネジメントファイルに文書化した,ソフトウェアアイテムが危険状態の一因となるケースのそれぞれについて,JIS T 14971に従ってリスクコントロール手段を選択し,文書化する。(クラスB,C)

注記 リスクコントロール手段は,ハードウェア,ソフトウェア,動作環境又は取扱説明書において実施できる。

→医療機器と Intended Use(意図する使用)を特定しなければ,危害や危険状態を推定できないため,リスクコントロールしようがない。医療機器によっては,障害が発生したときに,すぐに停止した方がよい場合もあれば,停止せずに最低限の機能で機器を動かし続けなければいけない場合もある。例えば,リスクコントロール手段として,メモリ保護があるとか,エラーが発生したときにリセットがかかるといった一見,何にでも有効そうなリスクコントロール手段は,搭載する機器の Intended Use によってはリスク低減に有効ではないこともある。


7.2.2 ソフトウェアに実装するリスクコントロール手段
 リスクコントロール手段をソフトウェアアイテムの機能の一部として実装する場合,製造業者は,次の事項を実施する。(クラスB,C)

a) リスクコントロール手段をソフトウェア要求事項に含める。
b) リスクコントロール手段の実施に寄与する各ソフトウェアアイテムに対して,そのリスクコントロール手段によってコントロールしているリスクに基づいて,ソフトウェア安全クラスの分類を行う(4.3 a)参照)。
c) 箇条5に従ってソフトウェアアイテムを開発する。

注記 この要求事項は,JIS T 14971のリスクコントロールの要求事項を詳細にしたものである。

7.3 リスクコントロール手段の検証
7.3.1 リスクコントロール手段の実施の検証
 7.2で文書化したリスクコントロール手段を全て実施していることを検証し,その検証結果を文書化する。製造業者は,リスクコントロール手段をレビューし,それによって新たな危険状態に至ることがないか判断する。(クラスB,C)

7.3.3 トレーサビリティの文書化
 製造業者は,次のソフトウェアに関連するハザードのトレーサビリティについて,適宜文書化する。
(クラスB,C)

a) 危険状態からソフトウェアアイテムまで
b) ソフトウェアアイテムから特定のソフトウェアの原因まで
c) ソフトウェアの原因からリスクコントロール手段まで
d) リスクコントロール手段からリスクコントロール手段の検証まで
注記 JIS T 14971参照。

7.4 ソフトウェア変更のリスクマネジメント
7.4.1 医療機器ソフトウェアの安全性に関わる変更の分析
 製造業者は,医療機器ソフトウェア(SOUPを含む。)の変更内容を分析して,次を確認する。(クラスA,B,C)

a) 危険状態の一因となる潜在的原因が新たに生じていないか。
b) 新たなソフトウェアリスクコントロール手段が必要でないか。

7.4.2 ソフトウェア変更が既存のリスクコントロール手段に与える影響の分析
 製造業者は,ソフトウェアの変更(SOUPの変更を含む。)を分析して,ソフトウェアの修正が既存のリスクコントロール手段の妨げとなる危険性がないかを確定する。(クラスB,C)

7.4.3 分析に基づくリスクマネジメントアクティビティの実行
 製造業者は,これらの分析に基づき,7.1,7.2及び7.3で定義した当該リスクマネジメントアクティビティを実行する。(クラスB,C)

→汎用のソフトウェア製品の製造業者は,医療機器の Intended Use を知らないので,ソフトウェアの変更がどのような危険状態の一因となるのか想定ができない。

このように,IEC 62304 の箇条7 を見れば,汎用のソフトウェア製品の開発プロセスに IEC 62304 が適合できない(適合する意味がない)ことが分かる。