システム開発プロジェクトの7割が失敗するという昨今、「訴えてやる!」を回避するためには、どのような視点を持ち、何を行えばよいのだろうか。ベストセラー「なぜ、システム開発は必ずモメるのか?」の筆者であり、東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、実際のIT訴訟事例を例にとり、トラブルの予防策と対処法を解説する。
平成25年8月、東京高等裁判所において日本の証券業界、そしてIT業界から大きく注目を集める判決が下された。東京証券取引所(以下、東証)が会員向けに提供している取引システムにバグがあり、これを利用して取引を行ったみずほ証券が多大な損失を被った事件についての判決だ。これは「ジェイコム株誤発注事件」として広く知られ、多くの人々が判決に注目していた事件である。その金額の大きさにおいても、いわば金融業の聖地である証券取引所で事件が発生したことにおいても、人々の関心を集めた。
この事件は、ミッションクリティカルなシステムの開発や、それを利用したサービスの在り方、さらには、サービス契約について、多くの教訓を残すものとなった。今回は事件の概要、およびこうしたシステムの開発における検証活動のあるべき姿について、裁判所の判断も踏まえて述べ、後編(6月掲載予定)では「(人的なプロセスも含めた)システムを運用する責任」と「重過失」について解説する。
まずは、この事件がどのようなものであったのか、その一部始終を簡単に振り返る。
平成17年12月8日、東証の取引参加者であるみずほ証券の社員が、顧客からの依頼に基づきジェイコムの株式「61万円1株」の売り注文を出すべきところ、誤って「1円61万株」の売り注文を行ってしまった。
誤りに気付いたみずほ証券はその後、当該注文を取り消す注文を発したが、この際、東証のコンピューターシステムに瑕疵(かし)があったことにより、注文を取り消せず、また東証の担当者も売買停止措置などを取らなかったため、取り消せなかった。みずほ証券は、こうしたことに対応するため、約定した株式を自己勘定(自分の資金)で買い戻す措置を取らざるを止ず、結果として150億円以上の売却損を出すこととなった、というのが事件の経緯である。
多大な損害を被ったみずほ証券は、損害の責任は東証にあるとして以下を主張し、東京地方裁判所に訴えを提起した。
みずほ証券は東証に対し、売却損約150億円の他、取引参加料金、クリアリング機構清算手数料および弁護士費用相当額、合計約415億円の支払いを求めた。しかし第一審の東京地方裁判所は、「(東証には)人的な対応面も含めた全体としての市場システムの提供につき重過失があった(要約)」「(同じく東証には)ジェイコム株の売買を停止すべき義務が認められる(要約)」など東証に一定の責任があることを認めながらも、「取引システムのバグの存在は取引参加者契約にある重過失には当たらない」として、売却損の約150億円のうち、約107億円の賠償だけを東証に命じ、その他の支払いについては認めなかった。
この一審判決を不服としたみずほ証券は、東京高等裁判所に控訴し、第二審が行われた。しかし、そこで出された判決も第一審の判決をおおむね支持する判断であった、というのが裁判の経緯である。
前述した通り、この判決は証券業界、IT業界が今後の参考とすべき知見が多く含まれている。今回は本稿の読者層が主としてIT関連に多いことに鑑み、特に取引システムのバグについての裁判所の判断について述べることとする。
裁判所はシステムのバグについての責任をどのように考えるか、それに対して、システムを利用したサービスの提供者や開発ベンダーに求められる対応とはどのようなものかを考えることは、ITサービス提供や開発に携わる多くの人々の知見にもなると考える。
まず、本件システムの不具合とはどのようなものであったのかを振り返ってみたい。
「約定注文の取り消しができなかった」という今回の不具合は、プログラム上のミスが原因で発生した。通常、株式の取引は、ある価格で株式を売りたいという注文と、その株式を買いたいという注文をマッチングさせて行う。この際、買い手は通常、売値の動向を観察しながら注文するので、多くの場合買い注文の価格は売り注文の価格と同じか、それ以下になる。
しかし、ときとして買い手の示す価格が売り手の価格を上回るケースがある。取引のない時間帯に予約の買い注文を指値で入れたが、実際に取引が始まってみたら、市場の動向により低い価格で売りに出される場合などである。このような状態のことを業界では「逆転気配」と呼び、今回の不具合は、この「逆転気配状態にある株式の約定データの取り消しができなかった」というものである。
もう少し説明すると、本件システムは約定の注文があると「銘柄別板DB」というデータベースに会員番号と通番が書き込まれ、取消注文があった場合には、このデータベースを参照して、取消対象の注文が存在するかを確認するアルゴリズムになっている。このとき銘柄板別DBに取消対象の約定が無いと、処理はそこで終了し取り消しは行われない。これはサービス提供者の東証が意図した通りの動きではある。
しかし今回の場合、「別のプログラムがある処理をすると、約定データをゼロクリアしてしまう」という不具合があった。銘柄板別DBにあるのは、いわば約定データのインデックスのようなものであり、約定そのものは別のデータベースで管理されているため、注文はそのまま実行される。つまり、ユーザーが取り消しを入れても、銘柄板別DBにはデータが無いため、処理は終了し約定はそのまま実行されてしまうという事態が発生したのである。これがプログラムのミスであることは、東証も認めるところであり、この点について争いは無い。
Copyright © ITmedia, Inc. All Rights Reserved.