コンピューター技術書の温故知新
第四回
大野典宏
●マーフィーの失敗法則
奇妙な話だが、この世に「マーフィーの法則」が二種類ある。
一つは成功法則と言われ、「良い思考は必ず実現する」という、とても前向きかつ都合が良すぎる話である。
もう一つは、「事態は必ず悪い結果を招く」という、とてもわかりやすい話である。
たいていの場合、にわか雨が降っている日に限って折りたたみ傘を持っていなかったり、絶対に勝てると思っている相手の前では凡ミスで完敗するものなのである。所得倍増とか経済成長、原発の電源喪失は起こりえないと発言した「安倍晋三の法則」とでも名付けたいのだが、まぁ似たようなものだと思っておけば良い。
そもそも、科学とか技術は懐疑論から始まる。科学者であり、哲学者でもあったデカルトやパスカルは徹底した懐疑論者だったし、事実と一致しないという点で突き詰められ、発見されたのがダーウィンの進化論であり、コペルニクスの地動説なのである。「こんな凄いものができましたよ」と言われるだけで勝手に虹色の未来を創造してしまうのは決して科学的では無いのである。
というわけで、勝手な外挿や想像をするのは個人の勝手なのだが、それを人に押しつけるのは良くない。
事実、本書の後にはAWS（Amazon Web Services）がダウンしてたいへんな事になったし、Facebookがダウンした際にはインドアロック（実際には電子ロックシステムも電源がダウンしてしまって入れなかったという話）をしてしまって復旧が遅れた。
そういうわけで、プロメテウスの悲劇は延々と繰り返されるのである。SFの起源とされるメアリー・シェリーの小説は『フランケンシュタイン、あるいは現代のプロメテウス』と名付けられている。考えてみれば、このフランケンシュタインの構造が、これまで何度となく繰り返されている。たとえば、リドリー・スコット監督の名作SF映画「ブレードランナー」や「プロメテウス」が同じテーマを扱っていることに気がつかないだろうか？
こういった話が語りかけてくる顛末を理解しているのなら、少しは「立ち止まって考えて、疑ってみる」という行為の重要性もわかることだろう。
――――――――――――――――――――――――――――――――――
書評 2009年3月 6日
完璧なシステムは作れないが，対策を講じる努力はしよう
『システムはなぜダウンするのか』
大和田尚孝著
日経コンピュータ監修
日経BP社
ISBN-10: 482228381X
ISBN-13: 978-4822283810
312ページ
2,400円（税別）
2009年1月
2009年になって「盤石の大帝国」と思われていたGoogleが2回もエラーを起こし，たいへんな騒ぎになりました．
まず，1月31日，検索結果のすべてに「このサイトはコンピュータに損害を与える可能性がある」という表示が出てしまいました．これは，悪意があるサイトを登録する際に，”/”というURLに必ず含まれる記号を入力してしまったために全部のWebサイトが対象だと表示されてしまったわけです．
また，2月24日にGmailにアクセスできないという不具合が発生しました．新しいプログラムのバグにより負荷の集中が起こり，それが連鎖してしまったとのことです．
これらの続いた不具合により，「Googleはいったい何をしているんだろう？」という不安を感じた人も多いかもしれません．特に，有料サービスのGoogle AppsでGmailを仕事で使っているユーザは大迷惑を被った訳ですから．
このような事故は，Googleだけに限ったことではありません．ATMが停止してしまったり，電車が止まってしまったり，株の誤発注があって損失が出たりと，システムの不具合により，社会的に大きな被害を与える可能性がある世界で我々は生活しているのです．
特に極端な例としては，枯れた技術を使い，何重にもバックアップ・システムを構築して安全を図っているはずのスペース・シャトルが何度も爆発したり，原子力発電所が緊急停止するという事故まで起こっている以上，ミスを取り除くことは不可能だと断言してしまっても過言では無いかもしれません．
ひょっとしたら，明日の朝には預金残高が0になっている可能性だって「絶対に無い」と保証できる人はいないわけです．
「失敗に達人というものはいない．人は誰でも，失敗の前には凡人である」というプーシキンの言葉の通り，みんな失敗しようとして何かを行っている人はいないのです．というか，そういう人がいたら，すぐに病院に行くべきでしょう．
また，「重大災害を1とすると，軽傷の事故が29，そして無傷災害は300になる」という統計事例が「ハインリッヒの法則」として知られています．
つまり，完ぺきなシステムというものを実現することが不可能である以上，いつでも1:29:300の比率，1/300の確率で重大事故に至るというわけです．
でも，「人は必ず失敗する」とか「失敗の前には凡人である」と言われても，それで損失を被るのでは安心して生活できません．そこで，過去の失敗を分析することによって，システムの設計時には予測できなかった何が起こったのか，それを解決するためには何に気をつけなければならないのかを知り，その後に反映させなければなりません．同じ事故を繰り返したら，マルクスの言葉にあるとおり，「歴史の事件や人物は，いわば2度現われる．1度目は悲劇として，2度目は喜劇として」なのです．
だいたい，大規模な事故の原因を探ると，後になって，「人の単純な勘違い」とか，「システム設計時における予測の甘さ」，「バグ」，「不慮の事故」に大別されます．最後の不慮の事故に対しては，そのような事故を想定して対策を講じておくしかないのですが，その他の三つは「起こってみない限り発覚しない」ので厄介です．システムのバグなどは，たとえばモジュールAは完ぺき，モジュールBは完ぺきだと証明されても，モジュールAとモジュールB間のデータ転送や数値変換の仕様が合っていて必ず動くという保証はないわけです．システムが大規模になり，モジュールが増えたら，「全ての組み合わせ」が天文学的な数値になってしまうようであれば，全部のテストをしている時間などあるわけがありません．
まあ，たいていの場合には，想定される組み合わせは限られるので，それで通常に動いている例の方が多いのですが，「ハインリッヒの法則」によって，あり得ないと思っていた組み合わせが起こって大事故に至る可能性はあるのです．
評者は別に読者を脅かしたいわけではありません．現実に，そういうリスクが存在する世の中で暮らしているということだけは忘れてはいけないという事実を述べているだけです．
さて，本書は，そういったミスの例を詳細にわたって紹介しています．かなり詳しく，事例も多いのでとても勉強になります．こういう前例があるということを知っていながらチェックを怠って失敗したら，マルクスが言ったとおり「喜劇」になってしまいます．
少なくとも，どこにミスが入りやすいのかを知っておくとか，どこを重点的にチェックするべきだとか，十分なマージンを持たせるとか，多重化しておくといった対策を立てなければ，1/300の事故を引き起こしかねない立場にいるのだという自覚は必要だと思います．
