2010-01-30

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

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

安全性: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 にくっつけたのか未だにその真意を理解していない。いずれこのブログで話題にしたいと思う。

4 件のコメント:

あるがままよ さんのコメント...

部品の信頼性と全体の信頼性は違う、全体の信頼性が安全性になる。と言うことですか?

sakai さんのコメント...

全体の信頼性と全体の安全性も異なると思います。安全性を語るためには必ず想定されるリスクやハザードが必要でリスクコントロール手段を実装することが求められます。信頼性の高い個々の部品を組み合わせた場合でも、システムから見たリスク回避手段が設計されていれば安全性が高いと言えます。

完成度を高めた部品を下からの積み上げだけでは安全は実現できないことを言いたいがために、信頼性と安全性は区別すべきだと言っているのだと思っています。

この点は、システムにおけるソフトウェアの役割が大きくなってきたことで強調されてきているように感じます。

zacky さんのコメント...

横やり失礼,おぼろげな記憶を元に教科書的な補足をさせていただきます.

信頼性はイメージとしては,その製品が機能として有する範囲の仕様があったときに,その中でいかに網羅されているかが問題になると聞きました.つまり,既にある機能がちゃんと意図通りに機能するかを見るわけです.

それに対し安全性は,機能や製品・サービスの中に閉じた話ではなく,それらの外の世界からいかなることが起こっても,危険なことが起こらないですむかが問題になるそうです.網羅するというイメージではなく,防御するというイメージでしょうか.そういう意味ではセキュリティに近いのかもしれないですね.

ちょっとこれも裏をとってきます.しばしお待ちを.

zacky さんのコメント...

専門家の先生がいたので,もう少しちゃんと聞いてきました.

信頼性に対するイメージはさっきの僕のコメントでだいたいあっているそうです.既に仕様が明確に決まった後で,その仕様をシステムがどのくらい満たしているかが問題です.そういう意味で,verification の問題です.

それに対し,安全性は仕様通りにものを作ったとして,それが人に危害を加えないかが問題です.したがってシステム単独では完結せず,外の物理世界との相互作用も合わせて評価する必要があります.仕様をどう決めるかが重要で,validation の問題です.

その安全性に関する仕様を満たすためには,どういうシステムでなければならないかという問題は,仕様を満たすシステムを作るという意味で信頼性の問題でもあります.そのため,安全性と信頼性は密接な関連があると言えます.