裁判になるシステム開発(2)


  2005年12月8日 9時27分
    証券会社から新規上場銘柄に「1円61万株」の売り注文が入った
      実は「61万円1株」のつもりであったが、誤入力してしまった
        警告メッセージが出たが、担当者は無視して先に進める

    証券取引所は注文を受け入れた

  2005年12月8日 9時28分30秒
    担当者は気付いて「売り注文」の取消処理を行った
      3回ともエラーとなり取り消せず
    証券取引所と直結システムで「売り注文」の取消を行う
      これもエラーとなり取り消せず
    急いで、反対売買によって買い戻すことを決定し、買い注文を出し続ける

みずほ
経過報告
 10分間で
61万株全てが約定する


  2005年12月8日 10時20分
    慌てて売る人、間違いだと気付いて買う人と乱高下を繰り返す
      ストップ高で取引停止となる
    1時間余りの間に、9万7千株余りの売買が成立する

  **************************************
    双方の問題点
      証券会社
        警告メッセージを出しているにも関わらず、安易に先に進めてしまった
        発行株数(約1万5千株)に対して異常な売り注文を許可した
      証券取引所
        取消注文が受け付けられなかったこと
          ※後日、原因は過去の修正ミスによるバグと判明
        即座に売買の停止が出来なかったこと
  **************************************

  2006年10月27日
    証券会社が証券取引所に415億円の損害賠償を求める

  2007年~2008年
    証券側
      取消し注文が処理されなかったのは「債務不履行」である
      誤発注にも関わらず、取引のマッチングを止めなかったのは「付合せ中止義務違反」である
      売買を停止出来なかったのは「売買停止義務違反」である
    東証側
      取引所の義務は、取引参加者を参加できるようにすることである
      個別の注文を処理する契約上の義務はない

  2009年12月4日
    東京地裁は107億円の賠償額を認定した
      証券取引所が誤発注を認識しても、売買システムを停止できなかった点を重過失とした
        ※システムが原因ではなく、人間系の業務不備と判断した模様
      証券取引所のシステムの不具合は重過失では無いとした

    2週間後に双方とも控訴する

  2012年2月
    ソースコードを開示して、バグを巡る争いになる

    遡る2000年2月に運用テストで発見された不具合を証券取引所は修正した
      その際に3箇所のソースコードを修正したが
        内の1箇所に「注文の取消」が出来なくなるような修正を施してしまった

    ソフトのバグは「重過失」となるか
      ・バグの作り込みは「過失」かどうか
        著しい注意義務違反として損害賠償の対象になるか?
          ※殆ど故意とみなされる様な行為は賠償対象となる
      ・(過失になるとして)開発者がどこまで賠償責任を負うのか?
        企業対起業の契約だと、免責事項等が用意されており、ある程度賠償責任を免れる
        だが、今回のような社会性のあるシステムだと「過失」の範囲を広げるかもしれない
          ※影響力が大きいと判断すればの話
      ・テストで発見できたかどうか
        証券取引所としては、テストでバグを出さないようにするのは無理と主張
        証券会社は修正点のテストもしくは回帰テストをすれば発見できたはずと主張
          ※前方での修正の結果、項目値が初期化され分岐条件に合致しなくなった
          ※後になってみれば、何故テストしなかったのかと悔やまれる様な場所
          ※別の要件で修正した際に、全ロジックの回帰テストをするとも思わない

証券会社  証券取引所
 バグは重過失に当たるか?  自動車事故の場合でも、運転手の過失と判断されることは有り得る  バグは一定の確率で発生し、開発者の過失を問うことは出来ない
 テストでバグを見つけ出すことはできたか?  ソースコードを見る限り、モジュールテストで発見されるバグである  回帰テストを行っても、バグをゼロにすることは出来ない
 ソースコードの変更は設計書に反映すべきか?  ソースコードの変更が設計書に反映されないことは有り得ない  全ての修正を設計書に反映させることは無い
 開発手法の違い  モジュール詳細定義書の修正を不要だとする開発は認められない  一旦、開発が完了したらドキュメントは修正せず、ソースコードを主体に切り替える


  2013年7月24日
    東京高等裁判所は1審を指示する
      ・誤発注が判明した後も東証が売買を停止しなかったことについて
        第一審と同じく東証の重過失を認定した
        過失の割合も東証が7割、みずほ証券が3割と変わらず、賠償金額に変更はない
      ・みずほ証券の売買システムのバグや債務不履行の考え方などについて
        第一審とは異なる判断が下された

    前提
      東証が取引先の証券会社に負っている債務は
        個別の注文に対して取消処理を行う義務はないものの
        「適切に取消処理ができる市場システムを提供する義務」はあったと認定した
          バグを含むシステムを提供していた点で「債務履行は不完全だった」とした
      システムを開発した富士通と、開発を委託した東証との関係については
        「富士通は東証の債務履行補助者だった」と認定した
          富士通に重過失があれば、信義則上、東証の重過失と同一視できる

    高裁の判断
      本件のバグが重過失に当たるかを検討した
        富士通によるバグの発見などが容易だったとすれば、東証が重過失を犯したことになる

      専門家の意見書が「相反する」ものであり
        いずれかの主張を一方的に採用することを避けた
      今回のバグが複数の条件の組み合わせで発生することから
        「本件バグの発見等が容易であることを認定することが困難であった」とした
      契約の免責条項について
        「東証側に故意、重過失がない限り、東証は取引所の利用に伴う損失の責任を負わない」
        東証に重過失があったかを立証する責任はみずほ証側にあるとした

        バグの発見などが容易だったと認定するのが難しい以上
          後知恵の弊に陥ることがないようにするが肝要、とした
          東証を重過失と認めることはできず、契約の免責条項はそのまま適用されるとした

      バグを含むシステムを提供した東証の債務履行は不完全だったものの
        免責規定により賠償義務は負わない、というのが裁判所の結論

    その後、双方とも控訴する

  2015年9月3日
    最高裁判所が上告を棄却する

    東京証券取引所の107億円の賠償額が決定する


投稿日

カテゴリー:

,

投稿者:

タグ:

コメント

“裁判になるシステム開発(2)” への1件のコメント

  1. […]      裁判の結果は「裁判になるシステム開発(2)」を参照 […]

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です