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

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

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

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

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