この本はコンピュータ制御システム及び、コンピュータ制御システムに携わるエンジニアのための本です。
私が関わる業務領域の中には、安全性のためだけにここまで論理を組み上げて品質を作りこむ必要がある領域というのはありませんでした。
業務系のシステムでは(要件が人の生死に関わらないという範囲において)品質や安全性は、コストに対してトレードオフさせるのが一般的です。そして、大抵の業務系システムの要件は人の生死には関わりません。私が携わってきたシステムの中にもそのようなものはありませんでした。おそらく、今後もないでしょう …ですが、ここまで知っておいて損することはないとも思います。
分析や設計をする際、その思考プロセスの根底に安全性や信頼性が横たわっており、それを見通しながら作業を進めることができるのと、そうできないのとでは、成果物のできあがりに明らかな差がでるように思えてならないからです。私は設計に品質を織り込みたい性格なので、存在を知った瞬間にこの本を即買いしました。
いわゆるSIerが取り扱うシステム・業務領域というのは、この本で対象にしているものとは違います。ですが、安全設計に係る考え方を知っていることは全く損にならないし、ここで学んだことをシステム構築に応用できたなら、それは素晴らしいことです。
◇どういう本か
コンピュータ制御システムなどの中に入っているソフトウェアが対象となっています。その中でも、システムのエラーが人の生死に直接的に関わるようなシステムに特化した内容になっています。なので、エンタープライズ・ビジネス系のそれとはだいぶ毛色が違います。
例として、信号の制御システムを考えて見ます。
車の運転中に全ての信号がいきなり真っ暗になったら困りますよね? で、交差点とか横断歩道を越える際にはものすごい神経をすり減らしながら走り、精神ががっつり削られたくらいにやっと家にたどり着いて、調べたら「初歩的なエラーでソフトが落ちたらしいんですが、原因が分からないんですよね。あの後に再起動したら、なんかうまく動いているので、しばらくはこのまま監視しようと思います。トラブル発生時のログなんてとってないし、まあ、再現したらそのときに調べますよ」とかいう話だったとします。今まで事故を起こさずやってこれたことに感謝すると同時に、明日からの自動車の運転に深く絶望し、同時にこのシステムに携わる全ての人間をぶっとばしてやりたい、という感じになりますよね?
そういったクリティカルなシステムをつかさどるようなソフトウェアを安全に構築するための理論や方法論までを包括的に述べたのがこの本です。
◇内容
人の生死に関わるようなシステムの設計方法を述べるだけあって、コンピュータ制御システムの安全について詳細に論じられています。大体、次のような感じです。
- リスクの概念をコンピュータに結び付ける。
- これをコンピュータにまつわる誤った神話に関連付け、解きほぐす。
- 事故の原因におけるシステムとヒューマンエラーの関係から、人間の役割について論じる。
- 工学的観点からシステム安全について述べる。
- システムを安全に作成・運用するためのプロセスについて論じる。
- ハザードを分析し、要求分析フェーズで検討するための手法について述べる。
- 安全性のための設計やインタフェースの設計について論じる。
◇付録
システムハザードを伴う10の重大事故のレポートが巻末に付録として収録されています。チャレンジャー号・ボパール・チェルノブイリといった有名なものから、Therac-25・セベソといったものまで多岐にわたります。
中でも、Therac-25のレポートは衝撃的です。この治療機器には、特定の条件下で起きるソフトウェアのエラーにより、致死量の放射線を患者に浴びせてしまうというハザードがありました。ですが、Therac-25の発売直後には誰もそんなことは知りませんでした。だから、致死量の放射線を浴びせたとしても治療者は気づきません。そして、致死量の放射線を浴びてしまった患者は、患部に強い痛みを感じたまま家に帰り、数日後に原因不明のまま死んでしまうのです。そうやって何人かの死者を出した後、一連の死者はシステムハザードの犠牲者であり、犯人はTherac-25、原因はソフトウェアのバグ、いうことが明らかになります。
患者が体調不良や違和感を訴える一方で、治療医や製造業者はシステムが抱えている危険を認識していなかったりします。認識不足、ちょっとしたミス、簡単な見落としや思慮不足が重篤事故に繋がり、人の生き死にに直結するのです。そう考えると、非常に恐ろしい話です。
◇最後に
この本の対象に業務系システムが含まれていないということは書きました。それはこの本の論旨からも明らかです。しかし、これは、この本がシステムの用途と人の生死がリンクするようなシステムについてしか取り上げていないだけ、という話であるとも考えます。
業務系のシステムの中には、「これ本当に運用設計したの? あと、この挙動バグじゃない? 問題ないの? これ、詳細設計とか書くようなプロジェクトじゃなかったっけ? ところで、テストの資料は? え? もう残ってないの? じゃあ、これが要件を満たしていることは誰が担保してるの? えー? それは…」という、いろいろと酷いシステムがあって、運用チームが神経をすり減らしながらだましだまし動かしているようなものだってあるわけです。ある意味で、人が緩やかに死んでいくようなシステムです。
そういうシステムを見ると悲しい気分になります。たしかに、業務系のシステムは要件的に人の命には直結しないものばかりですが、システムのライフサイクルと携わる人達全てにまで視野を広げれば、(例えこの本が私のようなエンジニアを視野に含めていないとしても)この本が私には無関係である、とは言い切れないのです。
私は、デベロッパー・プロダクトのオーナー ・ それからユーザー ・ その他もろもろの関係者が心穏やかにすごせるようなシステムを作りたいし、そのためには設計に品質を織り込むというアプローチは非常に有効だと考えているし、そのときにこの本の知識があれば役に立つんだろうな、と思っているわけです。
各章を読んでノートしていきます。
0 件のコメント:
コメントを投稿