プログラマの思索

第42回　SEA関西プロセス分科会に行って、松原友夫さんのセーフウェア、岸田さんのソフトウェア開発における美学原理の講演を聞いてきた。
感想をメモ。

【元ネタ】
第42回　SEA関西プロセス分科会のご案内

【告知】第42回SEA関西プロセス分科会「セーフウェア～システム安全とコンピュータ」: プログラマの思索

松原友夫さんは日立に長く勤められて、品質管理やソフトウェア工学を1960年代からずっと研究されている。
2005年のSEA関西の講演でも聞いたことがあり、それ以来尊敬している。
講演では声が小さくて聞き取りにくい部分もあったけれど、メモしながら色々考える所があった。

セーフウェアとは、システム安全には組織的な取り組みが必要であることを意味する著者ナンシーの造語であり、今回出版のタイトルでもある。
セーフウェアの本「セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)」は、600頁にものぼるが、付録の事例が200頁近くもあり、松原友夫さんによるとこの付録に価値があると言う。

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)の主張は、いくつかある。
一つは、ハインリッヒの法則が重視するオペレーションミスから有意義なノウハウは得られないという主張。
ハインリッヒの法則は、一つの重大な事故の背景には、多数の軽い障害のオペレーションミスがあるという事実を指摘し、軽い障害のオペレーションミスを改善することの重要性を示唆した。
しかし、「ヒューマンエラーは悪い」という結論は役立たないと言う。
何故なら、最近は、コンピュータが単なるオペレーションの自動化だけでなく、運用フローそのものを自動化しているため、オペレータに原因があるという仮説が成り立たなくなっている、と言う。
大規模な例は、原子力発電所やロケット、スペースシャトル、飛行機であり、身近な例では最近は車の制御装置が例になるという。実際、トヨタのプリウスを見ても、ハンドルもブレーキも組込機器のプログラムが自動制御していて、人間が操作できる限界を超えている。

問題は、ヒューマンエラーは悪いのではなく、人間とタスクのミスマッチにあるという仮定から、システム安全について考えるべきだ、ということ。

もう一つは、コンポーネントの信頼性が高くてもシステム全体の観点では安全ではない、という主張。
つまり、信頼性の範囲と安全性の範囲は、共通部分なら信頼性が安全性に関わっているが、それ以外の部分では影響しない。
例えば、事故はコンポーネントの故障の組み合わせで起きるわけではなく、想定していた信頼性境界を超えた部分で、色んな諸条件が組み合わさって事件が起きる、と。
故に、実際の障害分析は、非常に稀な条件が原因であることが多く、その検出は難しい、ということ。

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)で出てくる安全関連の概念として、独自性があるものは、ハザード。
ハザードとは、潜在危険とも訳され、システムの環境における他の条件とともに、必然的に事故をもたらし得るシステムの状態や組み合わせの条件を指す。
上記のように、信頼性のあるコンポーネントが多数結合されて初めて障害が起きる症状は、まさにハザードが隠れているのだろう。

松原友夫さんはセーフウェアの講演資料では、アメリカで発生したトヨタ問題に対して厳しい意見を書いている。
自動車がとてつもなく複雑な怪物に化けたことに、頭で分かっていても行動が伴っていないのではないか、と。
信頼性≒安全性と考えているのが間違っている、と。
安全性はシステムの属性、と理解しているのか、と。
ドライバー(オペレータ)のせいにしたがる文化が見え隠れしている、と。
数値化出来る現象の「見える化」ばかりに注目して、定性的なハザードや起こりうる事象の遷移についての深読みが軽視されていないか、と。

松原友夫さんは、システム全体をイメージすることの重要性を言っていた。
僕は、システムと操作する人も含めた運用フローで考えなければいけない、と理解している。

上記の話を聞いて思うのは、一つは、非機能要件のようにプログラミングの分割統治という手法が通用しない分野があること。
つまり、大規模で複雑なシステムを小さなコンポーネントに分解して信頼性の高いコンポーネントを作ったとしても、それらを結合したら、レスポンスが悪い、とか、特定の環境では使い物にならない、とか、非機能要件が出てくるのと同じ現象があること。
岸田さんは、数学のトポロジーのバナッハ-タルスキーの定理を持ち出していたが、部分の総和は全体と一致しないケースも現実世界ではありえる。

そして、我々の操作をシステムで自動化した場合、運用フローも含めて考えないと、予期しない副作用が起きること。
チケット駆動開発でも、Redmineというツールの特徴を知り尽くして運用フローをも考えておかなければ、実際に運用してみてもその改善効果をさほど得られないだろう。
システム化によって、人が不要になり、権限が明確になり、ワークフローが変わり、組織構造そのものも変わるからだ。

松原友夫さんは、「ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵」「デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか」など各種の優れた著作・翻訳があるので読んでおいて損はないと思う。