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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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