パスワードを忘れた? アカウント作成
8167450 story
プログラミング

東証曰く、システム開発においてコーディング後にはドキュメントは不要 204

ストーリー by hylom
開発手法に関する議論に 部門より
insiderman 曰く、

2005年に発生した、「ジェイコム株大量誤発注事件」はみずほ証券に大きな損害を与えた。みずほ証券はこの損害の原因の1つに東証の売買システムのバグがあるとして、東京証券取引所(東証)に対し賠償を求める裁判を起こしていたのだが、この裁判が3月18日に結審した(日経ITpro)。これを受けて、日経コンピュータが「みずほ証券-東証裁判の争点を洗い出す」として争点をまとめている。

ここで興味深いのは、東証の開発手法やソースコードに対する姿勢だ。東証はソースコードの修正時にそれに対応するドキュメントの修正を行っていなかったそうなのだが、これについて「コーディングが終了した後はドキュメントは不要」と主張している。いっぽうのみずほ側はこれについて「ソフトウェア工学の知見を無視する暴論だ」として、重大な過失であると主張している。

また、ソースコードには著しい重複があったことが判明しているのだが、これについても東証側は「重複する記述を含むプログラムはそうでないものと比べて信頼性が高い」と主張しているのに対し、みずほ側は「品質が極めて低い」と主張、意見が対立している。

なお、問題とされているのは、「誤発注を取り消せない」というバグ。東証側は「バグは一定の割合で必ず発生する」「バグを0にすることはできない」などとして免責を主張していた。そのため、争点となったのはバグが単なる過失ではなく、「ほとんど故意に近い、著しい注意義務違反」である「重過失」であったかどうかだったそうだ。通常ソフトウェアのバグが重過失として認定されることはまずないが、今回の件は公共インフラのシステムが対象ということから、「免責条項の有効性をかなり狭く解釈する余地がある」という。

みずほ証券側はソースコードを解析した結果、「たかだか2つ」のテストを実施するだけで問題となっていたバグを容易に発見できたと主張。さらに、システムの開発手法も適切ではなかったと述べ、バグはこれらが原因の重過失であると主張している。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 銀行の勘定系なんてコピペの嵐だろうに。JCLとか。
    今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、
    「重複する記述を含むプログラムは品質が極めて低い」
    という指摘を甘んじて受けるつもりなんだろうか。

    • by Anonymous Coward on 2013年04月05日 21時50分 (#2357785)

      ワインバーグの工学の第一法則
              壊れてないものを直すな。

      機能追加で動いている物に手を付けて綺麗に作りなおすのは担当者のエゴだと思う。
      重複があろうと完全分離したほうが安心じゃないのかな?
      株って株式取引所で人手の売買立会での誤発注も取り消しできない厳しい世界じゃなかったのか?
      一瞬の判断ミスで破産する世界だろ。

      親コメント
      • by Anonymous Coward on 2013年04月06日 10時21分 (#2357982)

        明らかな誤発注の場合には、取り消せますよ。だからこそ、取り消し機能があったのですし。ついでに言えば、株の売買契約が成立する前なら、誤発注でなくても取り消せます。ジェイコムの場合、誤発注に気がついて、『まだ、買い手が気がついていない、契約も成立していない』状態、すなわち取り消すことができるのは当たり前の状態で、取り消しコマンドが機能しないという、株の売買をするソフトとして絶対にあってはならないバグだったのです。
        で、みずほの誤発注者は、数回取り消しのコマンドを実行しようとしてうまくいかないので、東証にも連絡し、それでもらちがあかないので、非常手段として、本来は禁止されている『自分が出した売り注文に、自分で買い注文を入れて買い戻す』というやり方で、契約が成立していなかった残りの株を回収しています。最小からそうすれば、被害はもっと小さくなったかもしれませんが、自分で同時に売りと買いの出すのは、相場操縦を目的とした自作自演の不正行為と見なされる禁止事項なので、普通は『発注の取消』を実行します。

        ところで、『壊れていないもの(正確に言えば不具合がまだ見つかっていないもの)を治すな』は、必ずしも絶対に守らなければならないルールではなく、今どきはリファクタリングという名称がついた、定常作業では? それに、入力した数値の範囲チェックがなく、発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。

        親コメント
    • 内情はしらんですけど大手銀行さんはたいていシステム開発子会社を持ってるし
      経験も豊富なんで、それなりの経験と技術の蓄積はあるんでは。

      # それでもコピペはあるでしょうけど

      親コメント
      • by Anonymous Coward on 2013年04月06日 0時01分 (#2357856)

        都市銀が統合再編される前(20年くらい前)の話ですが、
        某都市銀の開発を請けおってた大手電気メーカーでは、
        ドキュメントやソースコードは「原本」「複製」「テスト用」をプリントアウトした状態で管理してました。

        「原本」は実機(銀行)で動いてるソースで鍵付きの棚に補完。
        実機にパッチあてたりしてソースを変更した場合、上司の承認&バージョン管理履歴残して赤書き。
        赤書きってのは元のソースを赤ペンで修正すること。

        「複製」は実機を書きかえる前の「実機修正予定」ソース。
        原本が鍵付きなので、原本と同じソースをいつでも見れるようにするために用意した模様。

        「テスト用」は文字どおり工場で再現・修正したソース。
        赤書きではなく、200ページ1版、200ページ2版みたいな管理でした。
        修正箇所が多いと差し込みが多く、かつ旧版を残しておくため、ページ増えすぎてカオス。

        #数年後にはデジタル管理(ファイル共有)になりましたけど、
        #アナログだろうとデジタルだろうと、コーディング終了=ドキュメント不要はありえないなあ。

        親コメント
        • by Anonymous Coward on 2013年04月06日 2時34分 (#2357909)

          8月28日富士銀行でオンラインが停止した。当時新人だった私はプリントアウトをえっちらおっちら運んだな。

          RDSがハードウエア障害によりNull上書きされてしまい、あとはもうどうしようもならなくなったことはあまり知られていない。

          その後、ポケプシーから設計者の大先生がお土産に干しアプリコットを持参して、何度も実験して成果を担いで帰っていった。

          美味しい思い出である

          親コメント
      • by Anonymous Coward on 2013年04月06日 2時11分 (#2357900)

         15年ほど昔の話。
         その頃の私は極めて遅れたものの、いい年であることを自覚
        しつつプログラマに転身しようと心に決めて、とある小さな会社に入ったのですが。
         入社後すぐに、とある下請けプロジェクトの打ち合わせ会議に
        業界の雰囲気に慣れる為にも参加しました。
         どうやら通信ログから料金を計算するプログラムらしいのですが、
        コードの一部を見せてもらったらVBで殆ど同じ内容のIF文が延々と続いていて・・・。
         絶句して『コレなんですか!?』と聞いたら料金計算の例外処理の
        追加が多すぎて、アルゴリズムでエレガントに処理出来ないとの事。
         追記が楽なIF文は最強らしい。
         小手先の技工に拘るのは仕事として愚かでしょうけど、当時の
        私にはとてもじゃないけど受け付けられない現実でした。 今でも厳しいですけど。

         でも大手生え抜きであれ中小下請けであれ、技術ってそんなに差はないよね?

        親コメント
    • COBOLでコードクローン減らせとか……

      #COBOLで開発したことないけどさ。

      親コメント
  • by marute (13883) on 2013年04月05日 19時19分 (#2357680) 日記

    昔、民法を勉強してた時はそう教わった。
    ここでいう、「悪意」とは「ある事実を知っている」(法律用語としての悪意・善意 [wikipedia.org])という意味なので、今回の場合、「バグがある」ことを東証はすでに知っていたという主張になると思うけど…これは無理筋では?

    • by Anonymous Coward on 2013年04月05日 19時34分 (#2357697)

      違いますよ。
      重過失は「普通の感覚ではやるはずのない間違い」のこと。
      商法では相手方が本当に知っていたかどうかは水掛け論になって益がないので重過失が悪意と同レベルの責任とみなされるだけです。
      一方刑法では条文に書かれていなければ重過失と故意ははっきり分かれています。なので重過失を認定しても殺人罪にはならずに過失致死になります。

      親コメント
      • by SAN0 (45971) on 2013年04月05日 21時26分 (#2357775)

        水掛け論だから、というのはちょっと違うかな。
        商法は、当事者が商人でありその取引についての知識を持っているということを前提にしてます。だから、重過失をやらかした場合は「知らなかった」ではなく「知ってたけど放置した」という扱いになると。

        今回の場合、争点は「品質保証に有効な手続きをきちんと取っていたか」という点でしょうから、重過失や悪意が関係するのは、品質保証手法を知っていたかどうかという部分でしょう。
        その意味では、東証の言い分は、専門性を著しく欠くものであって重過失に相当するように思えるのですが……裁判官はどう判断するでしょうね。

        #それはそれとして、バグの存在を知ってるなら、その検出に必要なテストの最小回数は、そりゃ1回とか2回だよねぇ。存在を知らないから山ほどテストするわけで、2回で見つけられるって主張に対しても、専門性の疑いを感じてしまう。

        親コメント
    • 重過失、というのは、重大な過失のことで、故意(悪意)とは全く異なります(一歩手前、と説明すると分かりやすいでしょうか。)。契約違反があることを(実際に知ってたかどうかはともかく)普通なら知っているよね(=故意(悪意)と同視し得る)、という理由で重過失が認定されることもありますが、他方で、普通なら絶対こんなことやらないのに何でやってんのよ(あるいは、普通なら絶対これをするのに何でやってないのよ)、という理由で、重過失が認定されることもあります。本件ではおそらく後者(のうち括弧に入れた方のパターン)の形で主張されているものと思われます。

      親コメント
  • 「ソフトウェア工学」のなんたるかを理解してないんで、あれですが本質的な違いってあるんでしょうか?

    • by okky (2487) on 2013年04月05日 22時00分 (#2357791) ホームページ 日記

      コーディングはなにもない所からコードを作ることを、
      デバッグはすでにあるものを消しながらコードを作ることを言います。

      一般にコーディングよりもデバッグのほうが、BackSpaceやDeleteキーを押す頻度が高くなります。
      # あるいは行削除とか範囲指定削除とか…

      -----

      コーディングは「ある一定の目的に沿う」プログラムを作ることを言います。
      デバッグは「おめぇ、これ目的に沿ってねーじゃん」と呻きながらプログラムを作ることを言います。

      -----

      コーディングは朗々とやることです。
      デバッグはコソコソとやることです。

      -----

      えー後何があるかな…

      --
      fjの教祖様
      親コメント
    • by Anonymous Coward on 2013年04月05日 19時57分 (#2357717)

      コーディングとはバグを作り込むこと、デバッグは混入したバグを取り除くこと
      #品質管理において、です

      親コメント
  • ソースコードには著しい重複があったことが判明している

    サブルーチン [wikipedia.org]の呼び出しが負荷になるほどの処理だったとか?
    サブルーチン(関数)のインライン展開ができない言語を使っているのかな。

    で、ソースコードの重複(コピペ)をみつけてくれるツールって何を使ってます?
    ぼくはRubyの場合はFlay [sadi.st]。
    「そこは共通化が面倒くさいから目をつむってよ」って言いたくなるくらいのコピペまでみつけてくれます。

    --
    love && peace && free_software
    t-nissie
  • by gesaku (7381) on 2013年04月05日 19時36分 (#2357701)

    東証側の「バグは一定の割合で必ず発生する」というのはかなり無理があるのでは。
    そんな言い訳を通すのであれば、ネット証券会社の自動発注システムにバグがあって大量の誤発注があった場合、
    「バグは一定の割合で必ず発生する」のだからこれはナシね、なんていう言い訳も当然通用しなければならなくなる。
    #もちろんそのときは東証は別の主張をしてくるでしょうが

    つか、こんな主張をしてくる「ソフトウェア工学の専門家」ってどんな人なんでしょ。
    バグっつーても、画面表示の誤字脱字レベルとブラックマンデーを引き起こしかねないレベルのものを
    同じ確率で論じられないでしょうに。

    #むしろ「それはバグではなくて仕様」とか言い切ったほうが面白かったかもgesaku

    • by gnaka (17369) on 2013年04月06日 0時30分 (#2357877) 日記

       近代国家は過失責任主義ですので、損害の原因(この場合はバグ)を作りこんだとしても過失がなければ言い訳は認められるのですよ。しかもこの場合は明示的に軽過失の場合の免責条項まであるそうですから。
       個人的には十分品質管理に注意していればバグが発生しないというレベルにソフトウェア工学は達してないと思うので、バグがある即ち過失とはならないと思います。ご指摘のようにインフラシステムでは注意義務のレベルが上がるにしてもです。
       だからこそ重過失の有無が争点になってるわけです。

      親コメント
    • by Anonymous Coward on 2013年04月05日 21時20分 (#2357773)

      バグは完全には防げないから、重層的な対応策を準備するのが東証のするべきことではないのかね
      発行株式総数をはるかに上回る発注をスルスル通しちゃって、その後始末の処理もうまくいかないなんて、ちょっと酷いと思う
      (いや、福島第一原発事故と同じで想定外の事態を発生させたみずほ証券が諸悪の根元だ!)

      親コメント
    • by Anonymous Coward on 2013年04月05日 21時27分 (#2357776)

      「バグは無くせない」と言うのはいいんだけど、バグ入りの製品を出荷されても困るんですよね。

      「難しい」というのも自分にそれを扱う技術はないヘッタピの能力なしって言ってるのと同じ。
      完成させられる技術も能力もないのに、出来ます! やります! では、同業者に迷惑をかけるだけなので
      即時、辞めていただきたい。

      親コメント
  • まあこれで億単位の金が動くだろうからどっちも譲れないんだろうけど・・・

    #東証のコメントは言い訳にしても苦しすぎる
  • タイトルだけ読むと、初心者系プログラマ/SEを投入してワケのわからないコードになっている印象だが、、どうなんだろう

    中途半端な仕様書なら、危険というのも事実だから、コードを読めというのも、あるかもしれない。

    ダラダラと書くのは、バグ検証が終わったコードを触らないという意味では、正しい部分もある
  • ドキュメントを書き終えたらね。

  • by Anonymous Coward on 2013年04月05日 19時15分 (#2357676)

    >みずほ証券側はソースコードを解析した結果、「たかだか2つ」のテストを実施するだけで
    >問題となっていたバグを容易に発見できたと主張。

    ほかにもぞろぞろバグが発見できたならともかく
    あらかじめ問題がどこにあるか判っていりゃ、あぶりだすテストも楽に設定できる罠。
    まあ、ああいう巨大なシステムも間抜けはどこかにいるわけで。
    ロケットだって爆発したわけだし。
    他山の石としよう。

  • 履歴もいらんとな (スコア:1, フレームのもと)

    by dodonga (4178) on 2013年04月05日 19時23分 (#2357684) 日記

     dodongaです

     コ~デイングが済んだらリポジトリもタグも要らないのかな。
     怖くてそんなこと出来ません:

    # 暴挙以外の何物でもないですね。

    --
    閑話休題
  • 「バグは一定の割合で必ず発生する」「バグを0にすることはできない」

    これってもしかしてT系のチェックリストにありがちな、
    「ソースnステップ辺りm個のバグを検出させること」を律儀にやった結果なんじゃ

    --
    一人以外は全員敗者
    それでもあきらめるより熱くなれ
    • by BlueRain (37857) on 2013年04月05日 23時39分 (#2357848)
      ああ、似たようなことを言われたことがあったな。

      小規模なプログラムで仕様通りの動作をして特にバグもなかったのだけど、担当者からバグ収束曲線に近似した形で推移してくれないと困るとか言われて、どうでもいいことをわざわざバグ認定してちょろっと直してを何度かやりました。
      最初からバグが少ないと「それだと困る」と言われる世界を初めて知りました。

      完成後かなり経ってから、通常あり得ない操作をやると本来あるべき動作にならないという仕様上のバグに気づいてしまったのは内緒。
      親コメント
    • Tじゃなかった、Hだ。
      お詫びして訂正します…

      --
      一人以外は全員敗者
      それでもあきらめるより熱くなれ
      親コメント
      • by Anonymous Coward on 2013年04月05日 19時31分 (#2357694)

        NだってFだってやってんじゃない?今はしらんけど
        過去の話ならIだってやってたし

        親コメント
  • by Anonymous Coward on 2013年04月05日 19時45分 (#2357707)

    リグレッションテストしてた記録が「もうありません」じゃね

  • どっちにしても係りたいと思えない(第一印象)

    つか実務品についての姿勢がどっちも変じゃね?

    --
    M-FalconSky (暑いか寒い)
  • by Anonymous Coward on 2013年04月05日 20時44分 (#2357747)

    修正後のドキュメントがないのも事実、ドキュメントを見ればあきらか。
    重複箇所があることも事実、ソースを見ればあきらか。

    その上で裁判を有利に進めるために、ソフトウェア工学上どうなんだとかとかみずほのシステムはどうなんだとかは完全に横において、関係者や弁護士のアドバイスに基づいて証言しているとしか...
    だからどっちも本音じゃないし、ベストプラクティスじゃないと思いますよ。

typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...