プランBを常に用意しよう

投稿者: | 2013年9月26日

以前、ソフトウェア技術者協会のメルマガ向けに書いたテキストが出てきたので、もったいないので載せておく。


先日参加したSEA Special Forumのパネルディスカッションでみずほ証券の株誤発注が話題になった。「61万円1株売りを間違えて1円61万株売と注文した」という世にいうジェイコム株大量誤発注事件である。みずほ証券は、誤発注を取り消すことができない東証システムの瑕疵に対し損失分404億円の損害賠償訴訟をおこし、東京地裁は東証に約107億円の支払いを命じる一審判決を下した。

最終的には発注後取り消せないという極めてわかり易いかたちで発現したバグであるが、伝え聞く所によると、そこに至までいくつものレアな条件が重なって始めて発生している。第三者的視点からみて、そうそう簡単には潰しきれないバグである。とはいえ、現実には400億円もの損失を出すバグが発生しているわけで、このインパクトは日本のソフトウェア史に影を落とすといってもいいだろう。

さて、これからの議論を進める上で、ここでバグに関して真実ともいえなくもない仮定をしたい。手短にまとめると、「バグはいつどこでどんなものが現れるかは、今の我々の技術ではコントロールできないし、リスクゼロのソフトウェアは存在しない」という仮定である。

なぜそんな仮定をするのかちょっと説明を加えたい。ソフトウェア中の潜在的バグの発見累積数はS字曲線(ロジスティック曲線)を描く。着目してもらいたいのは、ある一定の発見数を越えると、なかなか発見しづらくなるという部分である。そしてまたソフトウェア中のバグが少なくなるという意味でもある。そして密かに残るいくつかのバグを探し出すには極めてコストがかかるということを示唆している。またそのバグが引き起こす結果はどうなるかは事前には評価できないということも。

最近では脆弱性という言葉で我々の目の前に現れる。たとえば Remote Desktop Protocol(RDP)(MS12-020/CVE-2012-0002)は、先月(2012年3月)に出た脆弱性報告なのだが、これはリモートの攻撃側から簡単に標的のコンピュータをブルースクリーンにすることが可能である。ちなみに攻撃には特別な知識はいらず、世の中に出回っている攻撃ツールを使えばよい。グーグルがつかえ、少し英語が読めれば簡単に出来るレベルである。

このようなバグが日常的に現れるので感覚が麻痺しているが、コンピュータにとって致命的といえば致命的なバグである。この現象をパソコンだからといいたい人もいるかも知れない。次の例はどうだろうか。1980年代後半まで使われていた軍用機のフライ・バイ・ワイヤーのソフトウェア(操縦ソフトウェア)には、ゼロデバイド、つまり0で割ろうとする極めて初歩的なバグがあった。そのバグは失速した時点で操縦できなくなるという致命的な問題を引き起こす。このバグが発見されるまで現役の軍用機に使われ続けていた。開発期間も含めると25年近くソースコードの中に存在していた。

民間で使うソフトウェアからみると青天井ともいえるコストをかけることが可能の軍用システムのソフトウェアですらこのありさまである。起動時間が長くなると迎撃精度が落ちるというバグを持つ湾岸戦争で使われていた地対空ミサイル。宇宙空間で故障している人工衛星を回収しようとしたけれどバグで機材が使えず、結局、人間の手で回収するしかなかったスペースシャトルの制御システム。似たような話は色々とある。

さて、パネルディスカッションでのみずほ証券の株誤発注の話題に戻る。会場からは当然のように「ソフトウェアのテストを完全に行う」あるいは「もっとソフトウェア開発の技術を向上させて」というような発言があがってきた。極めて常識的な発言に聞こえるが、しかし、どんなにテストの精度をあげようと、開発技術を向上させようと、バグは残るし、いつどのような形で現れるかはわからない。

この完全なソフトウェアが理論上存在し、リスクゼロのソフトウェアを目指すというのを否定はしない。しかしリスクゼロのソフトウェアの構築という目的が段々と結果にすりかわり、ソフトウェアはリスクゼロであるべき、あるいはソフトウェアはリスクゼロとして扱わなければならない、という誤った認識に陥っていないだろうか。

東証のシステムも「システムは最悪な状態になる時はなるのである」という前提をおき、すべての手を尽くしてもどうしようもない最悪な状況になった場合、コンピュータでの売買を切り離し、売買停止にする、あるいは無効にする手順を事前に考えるべきだったのである。いわゆるプランBを用意し発動すべきだったのである。

しかし、少なくとも日本の文化においては、プランBを良しとしない。プランAがダメなら、プランA’。プランA’がダメならプランA”を用意しようとする。とことんプランAを突き詰めていく。「極める」という言葉は耳に心地よいが、実際には追い込まれていくような世界に入り込む、といった方がいいだろう。無限にプランAを拡張できるわけはないのだから、いつかは壁にあたり、その先に進めなくなる。問題は、その時にプランAをどうやって肯定するかを考え始める部分である。その時は、もう正常な判断ではいられなくなる。

今から260年ほど前に書かれたモンテスキューの『法の精神』に出てくる有名な日本における法の話を思い出してしまう。モンテスキューは「何でもかんでも切腹なので、それを回避するために真実を隠してしまう。よって法はその力を失う」といっている。これをこう置き換えてみよう。「プランAには限界があり、それを放棄しなければならない場面も発生する。しかし、それを認めるということは許されないことあり、よってプランAのまま突き進む」これの姿は第二次世界大戦から福島第一原子力発電所事故まで色々な所で顔を出す。本質的には260年前にモンテスキューが指摘した日本の法(ルール)に対する態度は変わっていない。

コンピュータシステムに関わらず「システム」というものがあり、それがクリティカルなシステムである場合、システムがまったく機能を果たさなくなった最悪の状態を想定し、その時に最悪な状態を回避するために異なったアプローチを常に用意し、ためらわず使うべきなのである。我々は常にプランBを考え、うまくいかない時は柔軟にブランBへ乗り換える、また、それを認める文化が必要なのである。