安全側に倒す - エスカレーター事故に思う -

システムを設計する際の重要な概念に「安全側に倒す」というのがあります。システムに予想外の事象が発生しても、システムダウンなど重大な問題につながらないようにすることです。

簡単に言ってしまうとエラー系の処理をきちんと設計することですが、そもそも実現しなければいけないことは何かをしっかり考えて抜けがないように、と言うところがポイントではないかと思います。卑近な例で言うと、ループ処理ならきちんとループが終了するように、演算誤差を考慮してループカウンタの判定を＝でなく≦で判定するなどもそれに当たるでしょう。

東京ビッグサイトのエスカレーター事故(リンク先はスラッシュドット・ジャパン)の報道を見ていると、何か釈然としません。基準を満たした設計がされていて、基準以上の人が乗ったので使い方が悪いとのこと。システム設計としては、(1)(逆走など)人命にかかわるような問題が生じないようにブレーキがあった、(2)重量オーバーを検知してブレーキをかける仕組みがあった、という二つの仕組みがあったようです。そして、重量オーバーを検知してブレーキをかけたが、耐えきれずに逆走した。

変ですよね。なんか、メモリ不足を事前に検知する仕組みがあってワーニング(警告)をデータベースに出力できるようになっていたが、ワーニングの出力によってメモリが致命的に不足してシステムがダウンしたような感じです。こんなシステムを作ったらお客さんから怒られますよね「そんな負荷の高い出力は要らないからメモリーを食わないワーニング出力にしろ！」と。笑うに笑えません。そもそもメモリー不足とはどのような状況で、必要なのはどのようなことかを考えて、さらにメモリーを消費しないように設計しないといけません。

このように考えると、エスカレータの設計は間違いなくおかしいですよね。少なくとも上向きに動いていたのだから、きちんと止められないなら警告音を出しでそのまま動けと思ってしまいます。もちろん、ブレーキが耐えられる重量で、停止すればよいのですけどね)。

こんな間の抜けた設計なのに社会的責任を問われないなんて、ある意味うらやましくもあります。ソフトウェアの仕様を決める際に何でも入れすぎなのがいけないのかもしれません。でも、「XXレコードを超える検索はシステムがダウンします」なんて仕様は書けません。ソフトウェアの柔軟性が自らの首を絞めているのでしょうね。

結局、システムを設計するなら、機能を実現するだけでなく、予想外の事象が発生してもシステムが危機的な状況にならないように、安全側に倒す設計をして、身を守るしかないのでしょう。