安全ソフトウェアの教科書的な存在であるセーフウェアを読み始めた。656ページもある分厚い本なので、まずは30分くらいで斜め読みした。自分は約20年近くクリティカルデバイスの開発に携わってきたので、書いてあることがよく分かったが純粋なソフトウェアエンジニアにはピンとこないかもしれないとも感じた。
具体的な事故の事例も多く掲載されているので、取っつきやすいと思うがやっぱり解説が必要にも思える。
そこで、できるところからこの本に書いてあることの意味について解説してみようと思う。
どこがいいかざっと見ていたら、エピローグ「これからの展望」にいいことが書いてあったので、ここからいこう。
【『セーフウェア』エピローグ これからの展望 より引用】
- 安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである。
- 安全性と信頼性は別なものであって、混同してはならない。
- 確率論的リスクアセスメントに依存し過ぎるのは賢明ではない。
- システムに安全を組み込むことは、完成した設計に防護装置を加えるよりも、はるかに効果的である。安全が、開発プロセスのより早い段階で考慮されるほど、より良い結果が得られる。
- 進歩するためには、事故を単純化しすぎるのを止め、事故の、複雑で複数の要素がからんでいるという本質を認めなければいけない。根本原因に手を着けずに、症状だけを処置しても、事故の再発はほとんど防げない。問題の数少ない側面だけに集中しても、望ましい効果は得られない。特に、技術的問題だけに着目して、管理上や組織上の欠陥を無視したのでは、有効な安全プログラムは得られない。
- 単に人間をコンピュータに置き換えても安全問題は解決しない。人間の「エラー」は人間の柔軟性と創造性に不可避に結び付いている。人間をコンピュータに置き換えるのではなく、むしろコンピュータを用いて人間の能力を増強する方法に取り組むべきである。
- 安全はシステムの問題であるので、異なる分野の専門家が共同して働くことによってのみ解決することができる。特にソフトウェアは、システムの他の部分から独立していては、効率よく開発できない。ソフトウェア技術者は、システム安全の概念と技法を理解しなければならない。同時に、システム安全担当者は、より深くソフトウェア開発にかかわり、システム安全のプロセスにソフトウェアを取り込むようにしなければならない。
- そのソフトウェアが動作するシステムという状況の中でのみ、ソフトウェアの安全性を評価することができる。ソフトウェア単独で見るだけでは、一片のソフトウェアの安全性も評価できない。
- 自己満足はおそらくシステムで最も重要なリスク要因であり、それを最小にする安全文化が確立されなければならない。
- 事故につながる事象が予測できないからといって、事故が予防できないということにはならない。ハザードは、通常分かっていて、しばしば、除去され、かなり軽減される。必要な機能性や費用の低さのような、他の目標とのトレードオフが最も少ないために、（ハザードよりも）先行する事象を除去しようとする決定がしばしば下される。複雑な決定は科学を超越したものである。しかし、技術者には、上位の意思決定者のためにリスクを明らかにし、自己満足または他の要因、または圧力が、意思決定において当然の考慮されるべき工学上の問題またはリスクを妨害しないようにする義務がある。
- われわれは同じ過ちを繰り返さないよう、過去から学ばなければならない。
【引用終わり】
これらを全部解説していたら終わらないので、まずは『安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである。』から
【安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである】
「安全」と「シンプル」は親和性が高い。特にソフトウェアは見えにくいので単純か複雑化を見分けるのも難しい。だからこそ、クリティカルデバイスのソフトウェアエンジニアは常にシンプルなアーキテクチャを目指す必要がある。
単純の最大のメリットは何だろうか。単純なソフトウェアはテストケースを有限にできる可能性がある。テストケースが有限ならば、テストに漏れがないと言える確率が上がる。
ちなみに、仮にテストケースが有限でテストに漏れがなくても安全とは言えないということは『安全性と信頼性は別なものであって、混同してはならない。』の解説で述べたいと思う。
でも、シンプルなアーキテクチャである方がテストもしやすいし、より安全に近づけることが可能であることは直感的に分かると思う。
さて、「知的に処理できるシステムを構築することである」の意味は英語の原文が手元にないので絶対そうだとはいえないが、たぶんこういうことだろうと思う。
要するに、安全を実現するアーキテクチャ、別な言い方をすればリスクコントロール手段を実現するアーキテクチャがある＝きちんと設計されているということだと想像する。
世の中、ソフトウェア搭載デバイスへの要求はどんどん多様化している。車だってセンサが障害物を感知して自動でブレーキをかける時代はすぐそこにきている。しかし、便利と安全は少なからず背反する部分がある。便利にしようとすればするほど、ソフトウェアは複雑になりユーザーの安全を確保するのが難しくなる。
センサーが障害物を感知したからといって、自動でブレーキをかけるとかえって危ないケースをあなたは簡単に想定できるだろうか。（日頃から訓練しているとできるようになる）
例えば突然ボールが自分の車の前50mくらいのところに転がってきたとする。冷静なあなたはバックミラーを見て、後ろから来ている大型トラックがよそ見をしているのを確認した。ここで自分の車が急停車すると後ろのトラックからかなりのスピードで追突される可能性がある。この場合、あなたの車はブレーキをかけないでボールをはね飛ばすか踏みつぶす方がリスクが低い。
ユーザーはいろいろなシチュエーションを想像することもなく、安易に車が自動でブレーキをかけてくれる機能があるといいと言うが、上記のような複雑なシチュエーションでその自動システムが働きかえって事故が起こったりすると、「そんな事態も想定して対策しておくのがメーカーの役目であり、過失だ」と結果論でものをいう。高い金を払って買っているのだから、どんなに複雑でも安全にできていて当然だという論理だ。ちなみに、その考え方は正しい。安全はタダでは確保できない。安全には価値があり、その価値を実現するにはそれなりの対価が必要だ。安全の対価をユーザーからいただいたメーカーは安全を確保する責務がある。しかし、システムが複雑になればなるほど、当たり前品質を確保するのは難しくなり、安全を確保する技術が必要になってくる。
だからこそ、「知的に（安全を）処理できるシステムを構築すること」は価値がある。システムを複雑に作ってしまってから、後からとってつけたようにリスクコントロールのソフトウェアを付けることは、目的を果たせない穴ができる可能性がある。
リスクコントロール手段は、最初からきちんと分析設計されたものであり、かつ、できるだけシンプルなアーキテクチャであることがいいのだ。単純で分かりやすいアーキテクチャであれば、ソフトウェア変更時の影響範囲の分析や、テストのポイントも絞り込むことができる。総当たりでテストすればよいという考え方では必ず漏れがでる。構造をシンプルにして抑えるべきポイントを絞り込むことが有効である。
こんな感じで、今後も、機会があるごとにセーフウェアのエピローグを解説していこうと思う。
0 件のコメント:
コメントを投稿