2005年11月02日
東証のシステム障害を考える。
久々のITネタでのエントリーです。昨日の東証のシステム障害ですが、日経新聞の論調は社説の下記の文章に集約されています。
（引用始）
『直接の原因は単純なプログラムミスでも、システムの処理能力の頻繁な増強が遠因とみる点で関係者の見方は一致している。』
（引用終）
本日の日経新聞でも詳述されているように、個人投資家からの注文増に対し、つぎはぎ的なシステム能力増強を東証が行ってきて、そうした頻繁なシステム能力増強がなければ、今回の惨事がおきなかったというのは、確かに事実です。しかし、では、例えば今後５年間の注文増に耐えうるほどのハードのアップグレードを行うことが、抜本的な問題解決となりうるといえるのでしょうか？そのようなソリューションは、５年後にまた同じ問題を繰り返させるだけです。
私は、東証が注文増に対してつぎはぎ的なシステム増強を繰り返してきたことが、問題の真因であるとは考えません。むしろ、つぎはぎ的な頻繁なシステム増強が、システム変更時のプログラム変更にまつわる問題を顕在化させたのであると考えています。では、システム変更時のプログラム変更にまつわる問題とは何なのでしょう。ここから以降は、私がアンダーセンコンサルティング在籍初年度に経験したプログラミングの経験をもとに推測する記述であるため、プログラミングの現場を離れて10以上経過した現状に必ずしも合致しない記述があるかもしれない点についてはご了承下さい。
プログラミングの実際を知らない方のために「比喩的」な説明をすると（したがってITの専門家の目から見れば若干不正確かつまどろっこしい説明になっている点をご了承下さい）、コンピュータ・プログラムとは①実際の処理を行うプログラムと②プログラムを動かすプログラムの２種類に大別されます。前者は、東証でいえば、顧客証券会社から受けた注文データをマッチングさせ、取引を成立させる、といった機能を担うプログラムのことです。実際、プログラマーの仕事の９割５分近くは前者のプログラムを書くことに費やされており、こうしたプログラムを正確にエレガントに、かつ素早く書き上げることは、プログラマーが食っていくための生命線であり、また、プログラマーが嬉々として取り組む仕事でもあります。
対して、後者の「プログラムを動かすプログラム」はどのようなものかといえば、前者のプログラムを作成したならば、必ずテストをしなければなりません。プログラムのテストは、当然のことながら「本番環境」では行えず、「テスト環境」で行うことになりますが、「本番環境のファイルではなくてテスト環境のファイルを読み込んで下さい」という指示が、「プログラムを動かすプログラム」に記述されることとなります。そして、日経新聞の記述を読むと、今回のプログラムミスは「プログラムを動かすプログラム」内の、読み込むべきファイルの場所に関して、エラー記述があったということが推察されます。
「プログラムを動かすプログラム」にまつわる問題点は２つあります。第一は、厳密なテストランができないという点です。「プログラムを動かすプログラム」の中には、イメージ的にいえば「IPアドレス」のような形で、読み込むべきファイル、書き出すべきファイルが記述されています。本番環境のファイルを指定してしまったら、本番環境のデータに影響を及ぼしてしまうため、厳密な意味でのテストランというのは不可能である、というのが最大の問題です。第二の問題は副次的ですが、プログラマーにとって書くモチベーションが湧かないという点です。「プログラムを動かすプログラム」にはエレガントなロジック構造などは要求されず、ひたすら「IPアドレス」のようなものを一字一句間違えないように記述することを要求される、神経だけが磨り減るいやな仕事なのです。
東証の頻繁なシステム能力増強によって、「プログラムを動かすプログラム」の仕様変更にまつわる問題点が顕在化してしまったというのが、今回の問題に対する私の見解で、したがって、ソリューションとしては「プログラムを動かすプログラム」の品質を向上させることを目的としなければ、的外れな対応となってしまいます。
こんなことは、ベンダーの富士通の現場の方には百も承知のことですが、新聞の論調や、トップマネジメントへと吸い上げられるコミュニケーションの過程で、昨今の急激な注文増が真因であるかのような議論のすりかえが起こってしまい、真の意味での抜本的な対応がなされなくなってしまうことを危惧します。
一方で、日経金融新聞では『障害頻発、問われる統治力』との見出しで、注文増よりは東証にとってシステムがブラックボックス化している点を問題点として指摘しており、こちらの方がより的確な議論であるように、私には思えます。