PR

 みずほ証券によるジェイコム株の誤発注問題は、東証のシステム不具合が原因だった。社会インフラとしての面だけでなく、システム開発に対する問題点が改めて浮き彫りになった。



 「情報サービス産業は、効率の高い社会経済活動を実現するために、ITの実装という極めて重要な役割を担っている。生産者責任という視点で、システムの生産技術の向上に注力し、高い品質による信頼を回復しなければならない」──。情報サービス産業協会(JISA)会長を務める棚橋康郎新日鉄ソリューションズ会長は、JISA会員を集めた新年の懇親会の冒頭、2005年末に東京証券取引所(東証)が起こしたシステムトラブルを引き合いに出し、出席者にこう訴えた。

 昨年12月8日、みずほ証券によるジェイコム株の誤発注に端を発した問題は、産業界に大きな衝撃を与えた。誤発注そのものは、証券会社にとってそれほど珍しい事象ではなく、通常はそこで出た損失を証券会社が補填して処理されるという。ただし今回、誤発注による損失が400億円を超す膨大な金額に達したことで、大きな社会問題に発展した。その上、損失が拡大した原因が、東証のシステムの不具合にあったことが明らかになった。2005年11月のシステム障害による売買停止から立て続けのトラブルで、東証は市場の信頼を大きく損ない、その矛先はシステムを開発した富士通にも向けられた。今年1月18日には、システムの処理能力の限界を理由に、取引を全面停止するという前代未聞の事態まで起こった。

 誤発注問題の処理は、着々と進められている。日本証券業協会は1月17日、今回の誤発注問題で利益を得た証券会社が、利益を返上するための受け皿として、「証券市場基盤整備基金」を新設したことを発表した。集めた基金は、システム障害の未然防止や、災害時のバックアップシステムの整備などに使う方針だ。

 東証は金融庁からの業務改善命令を受け、1月31日までに改善状況を報告する。今回のトラブルが発生した原因を詳細に究明し、システム障害の発生防止のための改善策や、万一システム障害が発生した場合の迅速な対応のために、市場監理体制を見直すことなどが求められている。

 最終的なトラブルの原因や責任の所在については、東証、富士通の双方とも調査中として明らかにしていない。今後これらが明らかになれば、みずほ証券と東証との間で損害賠償問題に発展する可能性は高い。場合によっては、システムを開発した富士通と東証との間で、その損害の負担についての交渉が持たれるだろう。

 今回のケースは、まず社会インフラに対する重大なトラブルとして注目が集まった。しかし原因の所在を見ていくと、実は一般のシステム開発案件にも共通して内在する問題を、改めて浮き彫りにしたのである。

取り消し処理を受け入れず

 昨年12月8日に起きた誤発注問題の経緯を改めてまとめると、以下のようになる。  午前9時27分、みずほ証券は「61万円で1株」の売り注文を、誤って「1円で61万株」の売りとして発注した。その時点で67万2000円で売買が成立。その後も大量の売り注文が残っていたため、制限値幅いっぱいの57万2000円の売り注文として登録された。そして、大量に出された買い注文と、売買が成立(約定)していった。この過程で、みずほ証券は、誤発注に対する取り消しの注文を出したが、システムはこれを受け付けなかった。結果としてみずほ証券には、407億円もの損害が発生した。

 不具合は、システムが注文価格を下限値に自動的に修正して実行する「みなし処理」という特定条件下で、注文の取り消し処理を受け付けないプログラムになっていたというもの。東証の天野富夫前常務は辞任前の会見で「注文ができない、取り消せないというのは、本来ありえないシステムの作りだと思う」と責任を認めた。

仕様は誰の責任か

 今回の誤発注の件で、ユーザー企業とソリューションプロバイダの間でのシステム開発のあり方というという観点から、浮き彫りになった問題は大きく3つある。1つ目は、発注者と受注者側の間で交わす仕様のあり方だ。

 東証は、システムの仕様として、みなし処理のときに注文の取り消しや訂正が入ることは想定していた。ただし、みなし処理のときに、今回のような特殊な条件下でも、取り消し処理を受け付けることという詳細な仕様になっていたわけではない。「“仕事がきちんとできるように”というのに近いくらいの要件定義だった」(天野・東証前常務)という。

 原則、発注者である東証が、最終的な仕様を承認した責任がある。ただし、高石法律事務所の高石義一弁護士は「契約に基づいて仕様書を作るのであれば、場合によっては受注者であるソリューションプロバイダの側にも責任がないとはいえない」と指摘する。仕様を作る際に、富士通がどのような役割を果たしたのかや、契約のあり方についての検証がなされるだろう。詳細な原因はまだ不明だが、ユーザー企業とシステム開発を受け持つ受注者の間で、仕様の記述の厳密さや、仕様に対する責任の所在にあいまいさがあったことは間違いなさそうだ。

 もちろん、あらゆる事態を想定して詳細に要件を定義し、稼働テストでもすべてのパターンを検証するというのは、現実には不可能だ。結局、仕様を厳密に作る手法を取り入れるなど、品質向上のための地道な取り組みは避けられない。CSKホールディングスの有賀貞一取締役は「優秀なエンジニアが徹夜や残業をして品質を確保するのではなく、エンジニアリング的な取り組みが不可欠」と話す。CSKシステムズは現在、フォーマルメソッド(形式手法)を使って、厳密な業務仕様を策定する手法の導入に取り組んでいる。

 ユーザー企業の役割という点では、システムの運用を担う東証コンピューターシステム(TCS)の位置付けもあいまいだった。TCSの場合、既に東証の持ち株比率は3割強に過ぎず、現在は富士ソフトABCの子会社になっていることが、システムの信頼性がゆらいだことに影響したという声は少なくない。システムが企業活動のコアであるユーザー企業にとって、自前で保有するITスキルや要因を見直す契機にもなるだろう。

トラブルは必ず起きる

 そして最大の課題は、システムへの過度な依存をなくすための、ユーザー企業とソリューションプロバイダ双方の意識改革だ。東証は今回、システムの不具合に対する責任とは別に、市場監理者という役割上の不手際があったことは否めない。システムが取り消し処理を受け付けなかった時点で、売買停止などの対応が取れていれば、被害を小さくできただろう。

 東証の鶴島琢夫前社長は、辞任を発表した会見で「処理をするのはシステムだが、そのシステムの性能を最大限に発揮させ、事故のない運営を図っていくのは人間がやること。その上で考え方に甘さがあった」と話した。

 システムに依存しない仕組み作りは基本的にユーザー企業の責任だが、ソリューションプロバイダの側にも、システム障害のリスクを提示し、対処の仕組み作りを促す責任はあるはずだ。

 東証問題の後も、重要な社会インフラを担う情報システムの障害は、相次いで発生している。今後より一層、システムの役割が大きく複雑になる中で、ソリューションプロバイダが手をこまぬいていては、課題は大きくなるばかりだ。システムに完全はないという原則に立ち戻り、品質向上策や運用手法を見直す必要があるだろう。