全5655文字

 さらに根本的なことを指摘すると、当時の東証は業務仕様を十分に詰めず、富士通にプログラム作成など大半のシステム構築業務をほぼ丸投げ状態で任せていた。その結果、テスト段階においてテストケース漏れとなって、バグの存在を許した。

 事件はその後、みずほ証券が東証を提訴することとなり、前述のように私は、みずほ証券側で裁判を支援することとなった。その際、驚くべきことがあった。東証側から「東証は取引の場を提供しているにすぎず、そこにおけるシステムの正常稼働までを担保しているものではない」といった趣旨の学者の意見書が出てきたことだ。

 私はシステム化、ネットワーク化が進んだ現代の証券取引において、正しい業務処理システムを提供することこそが東証の役割であり、極論すれば、証券取引業務・情報サービス会社であるとさえ思っていたので、天地がひっくり返るほどびっくりした。さすがにこの理屈は東証側もまずいと思ったのか、早い時期に引っ込めたが。

 さらに驚きは続く。次には「バグのないシステムなどは作れないので、バグがあっても仕方がない。システム構築の現場でも、そんなことは常識だ」との論が登場したからだ。確かにそれは事実かもしれない。しかしそれをもって正論とするならば、すべての工業製品で「欠陥の無い製品は作れない。だからそれで事故が起きても仕方がない。」ということと同じではないか!

 既に製造業においてはPL(Product Liability:製造物責任)が知られており、1994年には製造物責任法が制定されている。製造物の欠陥により人の生命、身体または財産に被害が生じた場合、製品の欠陥を証明することにより、その製品の製造者に対して損害賠償責任を負わせることを定めた法律である。ソフトウエアがPL法の対象となるか否かについては議論があるところだが、「バグがあっても仕方がないのさ!!」的な主張をしているうちは、バグのないソフトウエアなど作れない。

 私は、もし「バグが存在する」論を認知するならば、そのバグなどによるトラブルが発生した状況を把握したら速やかにシステムの運用を止め、事態の修復を図るべきだと主張した。つまり、作ったシステムには欠陥があるかもしれないことを想定して、リスクマネジメントのためにフェイルセーフな運用体制を取る必要があるというわけだ。

 裁判所にはこの考え方が理解されたようで、2009年12月4日に東証に約107億円の支払いを命じる判決を言い渡した。判決では売買停止措置を取らなかったことについて東証の注意義務違反を指摘し、東証の過失を認定した。同時にみずほ証券側の過失も指摘し、東証とみずほの過失割合を7対3と認定した。みずほ証券は判決に不満で高等裁判所に提訴し、さらには最高裁判所まで争ったが、2015年9月3日に最高裁で上告を退けられ、地裁の判決が決定した。

 この事件を踏まえて、東証はNTTデータからCIO(最高情報責任者)を招へいし、業務仕様を自分たちで詰める体制に切り替え、2010年1月に新たな株式売買システム「arrowhead」を稼働させた。その後、東証はarrowheadを2度刷新している。今回、問題を起こしたシステムは、処理性能の向上はもちろん、業務系と運用系のネットワークを分離するなど耐障害性も高めてきたはずだった。

 しかし今回のシステムトラブルを見ると、15年前の「リスクマネジメントのために、フェイルセーフな運用体制を取るべきだ」という主張をまたも繰り返さねばならない事態になったと言わざるを得ない。質問2にも関わる話なので、質問2への回答として話を続けよう。