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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


P.S.

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

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

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

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

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