写真●11月1日の東証システムダウンにより、株価が表示されない、当日午前の株価ボード
写真●11月1日の東証システムダウンにより、株価が表示されない、当日午前の株価ボード
[画像のクリックで拡大表示]
表●2005年に起きた証券取引所のシステム障害
表●2005年に起きた証券取引所のシステム障害
[画像のクリックで拡大表示]

東京証券取引所で11月1日、過去にない大規模障害が起きた。続く4日には名古屋証券取引所でもシステム障害が発生。いずれも午前の取引が完全停止した。単純作業における見過ごしが連鎖し、致命的な障害を生んでいる。役割分担が進んでいることが背景にある。

 11月1日の午前6時30分。東京証券取引所(東証)の売買システムの中核である「株式業務サーバー」の立ち上げ処理が途中停止した。結局、システムが復旧し、売買を再開できたのは同日の午後1時30分のことだ。

 この間、東証1部・2部とマザーズの上場株式2401銘柄に加え、転換社債型新株予約権付社債券(CB)、交換社債券のすべてが売買停止になった。「システム障害により全銘柄の売買が停止したのは初めて」(東証)。東証だけでなく、東証のシステムを利用している札幌、福岡の両取引所でも売買がストップした。

 株式市場が活況を呈している最中の大規模障害だけに、一般紙やテレビのワイドショーまでもが、トップ・ニュースで取り上げた。海外でもAP通信が速報したほか、英Financial Times紙は「ソフト・エラーが取引を停止させた。東証にとって史上最悪の出来事」と報じた。与謝野馨経済財政・金融担当相は同日、「極めて遺憾な事態だ」とし、苛立ちを隠さなかった。

 売買システムが起動しなかった直接の原因は、取引所に参加している証券会社とその端末コードを登録した「会員情報テーブル」と呼ぶデータを読み込めなかったこと。1日午後に開かれた東証の会見を受けた新聞など各メディアは一斉に、「10月8日から10日の3連休にシステム増強作業を実施した。その後、毎月末に実施しているディスク上のデータ記録位置を整理する処理により、会員情報データの格納場所が移動し、読み込めなかった」と報じた。

月末処理でプログラムが破損した

 しかし本誌の取材によれば、データの記録位置の変更が問題ではなく、データを読み込むための処理プログラムが壊れていたことが、そもそもの原因だった。東証の売買システムはCOBOLで記述されており、富士通のメインフレーム上で稼働する。そのCOBOLプログラムを構成するサブモジュール間の「呼び出し関係」が、10月31日夜に行われた月次処理の際、何らかの理由で破損したと見られる。

 その月次処理とは、東証が毎月末に実施している「コンデンス」のこと。ファイルの読み書きを繰り返して使用できなくなったディスク領域を解放するための作業で、パソコンではデフラグと呼ぶ処理に相当する。

 10月の3連休に実施したシステム増強作業は、売買取引能力を1日620万件から同750万件へと高めるのが目的だった。株式業務サーバーに接続している半導体ディスク装置の領域を再構成し、別の用途に使っていたディスク領域を売買プログラム用に追加で割り当てた。

 一方、コンデンス処理は毎月末のルーチン作業。過去にこの処理がプログラムを破壊したことは一度もない。それが、なぜ今回はサブモジュール間の呼び出し関係を破損してしまったのか。

 11月7日に東証が開いた記者会見で、「10月13日の作業で、必要な手順が抜け落ちていた。これが原因で、コンデンス処理を実行した際に、サブモジュール間の呼び出し関係を乱してしまった」ことが明らかになった。

 増強作業には東証のほか、開発・保守担当の富士通と、運用を担当する東証コンピュータシステム(TCS)の3社が参加していた。作業指示書の作成は富士通が担当、それを東証が承認し、TCSが実行した。

 3連休中のシステム増強作業に関して、東証は合計で4回のテストを実施しており、「問題は発見できなかった」とする。しかし、コンデンス処理を想定したテストは実施していない。「コンデンス処理などの月末処理は、富士通がOSと共に提供する標準ツールを使っており、それらが業務アプリケーションにまで影響を及ぼすとは誰も想定していなかった」(東証関係者)のが理由だ。

名証の障害も人的ミスが濃厚

 東証での障害原因追及が続く中、11月4日には名古屋証券取引所(名証)でもシステム障害が発生した。株価情報を証券会社などに配信する「相場報道システム」が起動せず、午前中の全取引を停止した。関係者の間では、「これでもし大阪証券取引所にシステム障害が起これば、テロによって日本の経済活動が停止した状況と変わらない」との指摘さえ飛び出した。

 障害の原因は、「データベースの起動時に読み込むシステム・ファイルを認識できなかったこと」(名証業務グループの平朋司グループ長)だ。相場報道システムは、富士通製UNIXサーバー上で稼働し、データベース管理システムにOracleを使用している。名証のシステムに携わるベンダーの関係者は、「対象のシステム・ファイルは通常、破損することは考えにくい。単純な人的ミスの可能性が高い」という。

 東証、名証と相次いだシステム障害を受けて金融庁は4日、全証券取引所にシステムの現状と管理・運営体制の一斉点検を指示。「一斉点検の結果次第では、システム監査を行政指導することもある」(金融庁市場課)との強い姿勢を示した。東証は11月4日までに一度、事情説明に出向いたものの、「納得できる内容ではなかった」(金融庁)として差し戻されている。

 金融庁の強い姿勢の背景には、証券取引所のシステム障害が続発していることがある([拡大表示])。ほとんどはパラメータの設定ミスや処理性能の設計に起因する問題など、やはり人的ミスが原因だ。だが障害の責任を人的ミス、つまり現場の組織や人に帰してはならない。バグを100%なくせない以上、障害が起きるのは「確率の問題」に過ぎない。重要なのはその確率をどれだけ減らせるか、万一の障害発生時に問題をどれだけ極小にできるかである。

危機に瀕する「現場力」

 東証のケースで言えば、リグレッション(影響)テストをどれだけやったのか、万一の障害に備えるデリバリ・マネジメントはきちんと実施されていたのか。そのための体制や人材、費用は手当されていたのか。

 証券取引システムなど、社会インフラを支えるシステムの開発・運用は本来、大きな責任と緊張を強いられる。短期開発やコスト削減に盲進する中で、やるべきことができない状況が生まれているとすれば、それこそが問題の根本だろう。この点で、金融庁が報告を求めるべきは、表面的なシステムの現状や管理・運営体制ではない。

 金融関連システムに詳しいベテランのSEは、一般論と前置きした上で「現場では個々の作業がチームごとに細分化され、全体を把握する人間がいなくなっている。しかも皆、自分の仕事をこなすだけで手一杯。昔は常識だったリグレッション・テストやデリバリ・マネジメントも、今は意味さえ知らないケースがある」と指摘する。

 サービス“継続”のための技術やノウハウ、さらには現場に身に付いていた“習慣”までを切り捨ててきた代償の大きさを、ユーザー、ベンダーともに改めて認識するべきだろう。