ハザードを見つけるという点で，ソフトウェアはなかなかやっかいなものです．
他の分野には，実績ある手法を見つけることができます．例えば，FMEA（Failure Mode and Effects Analysis）がそうです．ボトムアップの手法で，構成部品の故障モードを最初に考えます．各故障モードが全体に対してどのような影響を及ぼすかを調べることで，ハザードとします．FMEAのポイントは，その名が示す通り，故障モードにあるのではと思います．例えば，機械であれば，摩耗／振動／溶接不良といった一般的な故障モードを考えることができます．これらを過去の経験から十分にリストアップできれば，網羅性を担保することができます．安全性は，個々の機能の十全性ではなくて，如何に危険源であるハザードを見つけるかに掛かっていますから，この網羅性が大事と云うことになります．
一方で，ソフトウェアは，（それ自体）物理法則に従うわけではありませんから，この故障モードを網羅的に選びだすことは，簡単にできそうにありません．
もちろん，できなくても構わないと考えることもできます．ソフトウェア自身が暴走したとしても（物理的に存在しているわけではないが故にそれ自身は）痛くはないので良いと考えることもできます．防御は，あくまで機械的／電気的に担保できれば良いと考えることもできます．しかし，システムの経済性やシステムに対して優雅なふるまいを期待するとなると，やはり考えなくてはいけなくなります．
ではどうするかです．もちろん，（消極的な解決策として）がんばって故障モードを列挙するという方法があります．機械とか電気とかに限定されない一般的な故障モードを考えます．例えば，「設計通り値が入力されない」といった一般的なモードを考える方法です．そういったものをひたすら列挙しようということは不可能ではありませんが，なかなか網羅性を主張するまでいかないだろうと思います．
他の方法で有力なものにHAZOP（Hazard and Operability Studie）があります．ボトムアップのFMEAやトップダウンのFTA（Fault Tree Analysis）の中間に位置するようなアプローチになります．網羅性は，時空間上のキーワードである「数が多い／少ない」，「時間が早い／遅い」というガイドワードと呼ばれるものによって担保します．ただ，今度は逆に抽象的故に，網羅性は担保されたとしても，そのままソフトウェアに適用するのはやはり難しいかと思います．
***
ここのところ，HAZOPを利用したソフトウェアのハザード分析ということを考えています．基本になるのは，ハードの人達が例えばFMEA解析に図面を使用するように，ソフトウェアの我々は（例えばUMLといった）設計図を使うという方法です．単純な操作としてハザード分析が（少なくとも）単なるHAZOPよりは簡単になります．空間上のガイドワードはER図やクラス図に適用でき，時間上のガイドワードは，有限状態機械図に適用することになります．すなわち，分析・設計されたものに対して，網羅的なガイドワードを適用する，これによってハザード分析ができるというアイデアです．これにより，ハードウェアにおけるFMEAと同じくらい，ハザードを見つける容易な手立てを手に入れることができるようになります．
***
しかしそれでもなお，まだ問題が残ります．実際にやってみると分かるのですが，上記においてもまだガイドワードからハザードを見つけ出すというのは，やはり難しいのです．そして，この難しさは，網羅性と云うよりハザードを見つけ出すということそのものにあります．ガイドワードに従って，例えば属性を操作する．その時に何がおきるかを考えると云うことは，どうしても思考の跳躍を必要とします．即ち，創造性を必要とする作業だということです．このことについては機会があればまた書いてみたいと思います．
（nil）