STAMP/STPA(※)の価値、意義、面白さについての個人的な理解。
※STAMP/STPA：MITのNancy Leveson教授が考案し、提唱しているシステムの安全性分析手法。参考資料（IPAサイト）
信頼性と安全性の違い
STAMP/STPAを理解するには、まず、「信頼性」と「安全性」の違いの理解が重要と思われる。
Nancy Levesonは、著書"Engineering a Safer World"や講演などで、「信頼性と安全性は、混同されがちであるが、違うものである」と繰り返し述べている。
どのように違うのか。例えば、JISを参照すると、次のように定義されている。
信頼性：機能単位が、要求された機能を与えられた条件のもとで与えられた期間実行する能力。（JIS X 0014）
安全性：システムが、規定された条件のもとで、人の生命、健康、財産又はその環境を危険にさらす状態に移行しない期待度合い。（JIS X 0134）
「信頼性」は、「要求された機能」に関心があり、機能が要求された通りに実行されることを指している。一方「安全性」は、「人の生命、健康、財産又はその環境」に関心があり、それらが危険な状態にならない度合いを指している。
関心の対象が異なるので、「信頼性が高いが、安全性は低い」とか「信頼性は低いが、安全性は高い」ということがあり得る。例えば、次のような例が考えられる。
- 「前方に人がいる状況で、自動車のアクセルを踏むと加速し、人に衝突する」
⇒「アクセルを踏むと加速する」という要求された機能が実行されているので信頼性は高いが、人が危険な状態になるため安全性は低い。 - 「駐車場から出るため、自動車のアクセルを踏んでも全く動かない」
⇒「アクセルを踏んだら加速する」という要求された機能が実行されないので信頼性は低いが、危険な状態にはなっていないので、安全である。
1.のケースから分かる通り、「信頼性が高ければ安全である」は成立しない。1.のケースでも、前方に人がいる状況ではなく、高速道路を走行中の状況であれば危険ではない。逆に2.のケースは、駐車場にいる状況だから危険ではないが、高速道路を走行中の状況であれば非常に危険である。
このように、システムの安全性は、システムが稼働する周囲の状況との組み合わせで考える必要がある。
信頼性と安全性の確認のしかた
上記のJISの定義に沿えば、信頼性は「要求された機能」が実行されることである。要求される機能、すなわち「機能要件」は、基本的に定式化可能で有限なものと考えられる。そうでなければ、機能の実装作業を誰かに委託する、契約する、ということが成り立たなくなってしまう。
したがって、実装された機能が、定式化された有限な「機能要件」をカバーすることを確認すればよいことになる。もちろん、「有限」とはいっても、現実には膨大な組合せ数の事象を確認する必要がある場合も多く、その確認は簡単ではない。しかし、形式手法のような数学を利用した方法や、事象の連続性に基づいたテスト技法など、納得性の高い確認を行うための手段が存在する。
一方、安全性は、「規定された条件のもとで、人の生命、健康、財産又はその環境を危険にさらす状態に移行しない期待度合い」である。「規定された条件のもとで」といっても、現実世界の全てを規定することは不可能だ。「規定された条件」つまり想定する条件の他に、何らかの状況が加わり、その作用によって事故が起きる場合も多い。
人命に関わるような事故が起きたとき、「その状況は想定外でした」といっても、「じゃあしょうがないですね」とはなりにくいのが現実である。システムを開発、提供する側は、「あらゆる状況」を想定しないと、真に安全なシステムを提供することはできないということになる。
上で、「システムの安全性は、システムが稼働する周囲の状況との組み合わせで考える必要がある」と書いた。しかし、システムの周囲の状況は、無限の可能性（状態空間）がある。
敢えて極端な言い方で対比をすると、「信頼性の確認は『有限』の事象を確認すること（それでも大変！）」であるのに対し、「安全性の確認は『無限』の事象を確認する必要がある」といえるのではないか。
無限の事象の確認をどうやって行うか
無限の事象の確認は、「無理」だ。しかし、無理だからといって最初から諦めることは許されない。システムの開発者、提供者は、「システムの安全性について、できる限りの努力を注いで確認した」ということを説明することが求められる。
その場合、「いろいろと思いついた危険事象に対して、対策を施しました」といっても納得性は低い。できるだけ網羅的で客観的な説明が必要になる。
STAMP/STPAは、システムの安全性をいかに確保したかについて、できるだけ網羅的で客観的な説明を可能とするためのツールとして位置づけられる。
具体的には、STAMP/STPAの以下のような特徴がそれに寄与していると考えられる。
- 複数の異なる分野の専門家による分析：無限の事象を考えるには、結局、人間の「想像力」が必要となる。想像力を高めるには、一人で考えるよりも、複数の人と会話しながら考える方が脳が活性化されるため、好ましい。それも、異なる発想をする人が複数集まって会話する場合の方が、広い範囲に想像が行き渡りやすい。
- 制御構造図：システムのハザードを防ぐことに関係する「要素間の制御関係」をモデル化し、可視化した図である。上記の「複数の専門家による分析」を行う際に、「対象のシステムをどのように見るか」を共有した上で議論ができるため、効率的で効果の高い分析が期待できる。
- UCAの識別：制御構造図上の「コントロールアクション」を１つずつ取り上げ、それに４つのガイドワードを順番に当てはめてUCA(Unsafe Control Action)を識別する。ハザードにつながる無限の事象を、思いつくままに、やみくもに挙げていったのでは「今どこまで考えたのか？まだ考えていないケースはどこか？」が分からなくなる。第三者の納得も得られにくい。UCAは、「システム全体で着眼すべきポイントを俯瞰的に洗い出したもの」とみなすことができる。UCAに沿ってハザードシナリオを考えていくことによって、網羅性や客観性への配慮を示すことができる。
- 定型化された分析手順と成果物：分析を行う各工程の作業内容と成果物が定められており、それらの成果物によって、分析を行った過程を第三者が理解することができる。
ここまでのまとめ
STAMP/STPAの意義、必要性について、ここまで書いたことをまとめると次のようになる。
- システムの安全性の確保は、システムが稼働する状況について無限の事象を考える必要があるため、非常に難しい。
- システムの開発・提供者は、システム安全性の確保をいかにして行ったか（＝無限の事象をどのように確認したか）について、第三者が納得できるように説明することが求められる。
- STAMP/STPAは、システム安全性の確保をできるだけ網羅的・客観的に行うための工夫が施された手法であり、第三者への説明責任を果たすために役立つ。
STAMP/STPAの面白さは他にもあるが、長くなるので、続きは次回に。
