セーフウェアの解説その二

『セーフウェア』の解説その二として、【安全性と信頼性は別なものであって、混同してはならない】を説明しようと思う。

安全性：Safety と 信頼性：Reliability は異なる。異なるというよりは区別して考える理由がある。ナンシー・レブソンが言いたいのは、信頼性：Reliability を高めることで安全性：Safety が確保されると考えてはいけないということだ。

多くの人は「なぜ」って思い、ピンとこないかもしれない。でも、「このソフトウェアに何か問題があると、人を傷つける可能性がある」というソフトウェアを一度でも作ったことがある人には分かると思う。それだけ重要なソフトウェアであっても、問題を起こさないという絶対的な自信はなかなか生まれてこないのだ。責任感が強いエンジニアほど、この現実は辛い。テストをいくら積み重ねても、100%の安心にはつながらないことは直感的に分かる。ソフトウェアの規模が大きくなればなるほどエンジニア個人の無力さを感じると共に、個人の範囲を超えたときから「自分だけではどうしようもない」を考えるようになり責任感も薄れていく。

ソフトウェアの規模が大きくなると、完成度を高めても、悪意がなくとも誰も気づかないうちにプログラムが修正されてしまう危険もある。

ソフトウェアを部品と考え、十分に信頼性を高めたと思われる部品を結合したソフトウェアシステムは必ずしも安全ではないことは、このような経験から感じるのだ。

もちろん、ソフトウェアモジュールの信頼性を高めることは、ソフトウェアシステム全体の安全性を高めることに貢献する。しかし、それでもなおナンシー・レブソンが「安全性と信頼性は別なものであって、混同してはならない」と言うのは、信頼性の高いソフトウェア部品をつなぎ合わせて作ったソフトウェアシステムが、システムとしてのユーザーリスク、プロダクトリスクを分析して対処する、もしくは、リスクを制御するシステムアーキテクチャを採用していないのであれば、安全なシステムであるとはいえないからである。

そこには次のような具体的な要因が考えられる。

• AモジュールとBモジュールの制御判断が背反した場合のシステムとしての動作をモジュールは規定できない（部品の信頼性では解決出来ない）
• 検証が終わり信頼性を高めたモジュールが改変できなようにすることは難しい
• システム全体でリスクを軽減しようとしても、部品が完成してしまっていると実現しにくい。
• ソフトウェアを変更しないで再利用できるようにするためには、高度なスキルが必要であり、簡単ではない
• システム全体のリスクを分析してコントロールしようとしない者は、すでに存在するソフトウェア部品の組み合わせでシステムを構築しようとし、リスク低減よりもソフトウェアの早期リリースが優先する

開発効率やコストダウンを優先するあまり、信頼性の高いソフトウェア部品を組み合わせてシステムを構築したいと考える者は必ず存在し、その考え方が事故を誘発する。

このことが分かっているからセーフウェアには「安全性と信頼性は別なものであって、混同してはならない」と書かれているのだ。

これは手段が目的になってしまい、本来の目的が忘れ去れれてしまうこととよく似ていて、「物事の本質を見極めない」、「どうして今これをやらなければいけないのか」と考える習慣がないと陥る危険性のある心理的なトラップである。

「信頼性を高める」ことは手段だと思う。一方で「安全性を高める」とは目的だ。「安全」と言う言葉の後ろには、人や財産など失ってはいけない重要なものがはっきり見える。

「信頼」は誰のための「信頼」かがはっきりしない。クライアントがサプライヤーに求める「信頼」は、エンドユーザーの「信頼」であるとは限らない。例えば、産地偽装を指示したクライアントに対して、言われた通りにラベルを偽装したサプライヤーはクライアントの信頼を得るが、エンドユーザーの信頼は裏切っている。

安全は常にエンドユーザー（場合によってはオペレータも含まれる）が対象になる。安全は誰も裏切らないが、信頼は場合によってはだれかを裏切る可能性がある。

「安全性と信頼性は別なものであって、混同してはならない」の深い意味をお分かりいただけただろうか。『セーフウェア』を読む方はこの点について気にしながら読んでいただきたい。

P.S.

Dependability や Functional Safety ということばも最近 ISO規格の中で出てきており、

Wikipedia によると  Dependability は

Dependability is a value showing the reliability of a person to others because of his/her integrity, truthfulness, and trustfulness, traits that can encourage someone to depend on him/her.

とあり、 次の要素を含むとある。なんと Safety も Reliability も含まれている。

Availability - readiness for correct service
Reliability - continuity of correct service
Safety - absence of catastrophic consequences on the user(s) and the environment
Integrity - absence of improper system alteration
Maintainability - ability to undergo modifications and repairs

こうやって、いろいろな視点をまとめて体系化することで、特定のドメインにおける安全または実際に起きた事故の再発防止策が抽象化されてすべてのドメインに通用する銀の弾丸があるかのように思われることを自分は心配している。

また、Wikipedia によると Functional Safety は

Functional safety is the part of the overall safety of a system or piece of equipment that depends on the system or equipment operating correctly in response to its inputs, including the safe management of likely operator errors, hardware failures and environmental changes.

となっている。この Functional safety（日本語では機能安全）が、なぜ Functional を Safety にくっつけたのか未だにその真意を理解していない。いずれこのブログで話題にしたいと思う。