東証曰く、システム開発においてコーディング後にはドキュメントは不要 204
開発手法に関する議論に 部門より
2005年に発生した、「ジェイコム株大量誤発注事件」はみずほ証券に大きな損害を与えた。みずほ証券はこの損害の原因の1つに東証の売買システムのバグがあるとして、東京証券取引所（東証）に対し賠償を求める裁判を起こしていたのだが、この裁判が3月18日に結審した（日経ITpro）。これを受けて、日経コンピュータが「みずほ証券-東証裁判の争点を洗い出す」として争点をまとめている。
ここで興味深いのは、東証の開発手法やソースコードに対する姿勢だ。東証はソースコードの修正時にそれに対応するドキュメントの修正を行っていなかったそうなのだが、これについて「コーディングが終了した後はドキュメントは不要」と主張している。いっぽうのみずほ側はこれについて「ソフトウェア工学の知見を無視する暴論だ」として、重大な過失であると主張している。
また、ソースコードには著しい重複があったことが判明しているのだが、これについても東証側は「重複する記述を含むプログラムはそうでないものと比べて信頼性が高い」と主張しているのに対し、みずほ側は「品質が極めて低い」と主張、意見が対立している。
なお、問題とされているのは、「誤発注を取り消せない」というバグ。東証側は「バグは一定の割合で必ず発生する」「バグを0にすることはできない」などとして免責を主張していた。そのため、争点となったのはバグが単なる過失ではなく、「ほとんど故意に近い、著しい注意義務違反」である「重過失」であったかどうかだったそうだ。通常ソフトウェアのバグが重過失として認定されることはまずないが、今回の件は公共インフラのシステムが対象ということから、「免責条項の有効性をかなり狭く解釈する余地がある」という。
みずほ証券側はソースコードを解析した結果、「たかだか2つ」のテストを実施するだけで問題となっていたバグを容易に発見できたと主張。さらに、システムの開発手法も適切ではなかったと述べ、バグはこれらが原因の重過失であると主張している。
みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 興味深い)
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。
今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、
「重複する記述を含むプログラムは品質が極めて低い」
という指摘を甘んじて受けるつもりなんだろうか。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:4, すばらしい洞察)
ワインバーグの工学の第一法則
壊れてないものを直すな。
機能追加で動いている物に手を付けて綺麗に作りなおすのは担当者のエゴだと思う。
重複があろうと完全分離したほうが安心じゃないのかな？
株って株式取引所で人手の売買立会での誤発注も取り消しできない厳しい世界じゃなかったのか？
一瞬の判断ミスで破産する世界だろ。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:2, 参考になる)
明らかな誤発注の場合には、取り消せますよ。だからこそ、取り消し機能があったのですし。ついでに言えば、株の売買契約が成立する前なら、誤発注でなくても取り消せます。ジェイコムの場合、誤発注に気がついて、『まだ、買い手が気がついていない、契約も成立していない』状態、すなわち取り消すことができるのは当たり前の状態で、取り消しコマンドが機能しないという、株の売買をするソフトとして絶対にあってはならないバグだったのです。
で、みずほの誤発注者は、数回取り消しのコマンドを実行しようとしてうまくいかないので、東証にも連絡し、それでもらちがあかないので、非常手段として、本来は禁止されている『自分が出した売り注文に、自分で買い注文を入れて買い戻す』というやり方で、契約が成立していなかった残りの株を回収しています。最小からそうすれば、被害はもっと小さくなったかもしれませんが、自分で同時に売りと買いの出すのは、相場操縦を目的とした自作自演の不正行為と見なされる禁止事項なので、普通は『発注の取消』を実行します。
ところで、『壊れていないもの（正確に言えば不具合がまだ見つかっていないもの）を治すな』は、必ずしも絶対に守らなければならないルールではなく、今どきはリファクタリングという名称がついた、定常作業では？ それに、入力した数値の範囲チェックがなく、発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:2)
内情はしらんですけど大手銀行さんはたいていシステム開発子会社を持ってるし
経験も豊富なんで、それなりの経験と技術の蓄積はあるんでは。
# それでもコピペはあるでしょうけど
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 参考になる)
都市銀が統合再編される前（20年くらい前）の話ですが、
某都市銀の開発を請けおってた大手電気メーカーでは、
ドキュメントやソースコードは「原本」「複製」「テスト用」をプリントアウトした状態で管理してました。
「原本」は実機（銀行）で動いてるソースで鍵付きの棚に補完。
実機にパッチあてたりしてソースを変更した場合、上司の承認＆バージョン管理履歴残して赤書き。
赤書きってのは元のソースを赤ペンで修正すること。
「複製」は実機を書きかえる前の「実機修正予定」ソース。
原本が鍵付きなので、原本と同じソースをいつでも見れるようにするために用意した模様。
「テスト用」は文字どおり工場で再現・修正したソース。
赤書きではなく、200ページ1版、200ページ2版みたいな管理でした。
修正箇所が多いと差し込みが多く、かつ旧版を残しておくため、ページ増えすぎてカオス。
＃数年後にはデジタル管理（ファイル共有）になりましたけど、
＃アナログだろうとデジタルだろうと、コーディング終了＝ドキュメント不要はありえないなあ。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 参考になる)
8月28日富士銀行でオンラインが停止した。当時新人だった私はプリントアウトをえっちらおっちら運んだな。
RDSがハードウエア障害によりNull上書きされてしまい、あとはもうどうしようもならなくなったことはあまり知られていない。
その後、ポケプシーから設計者の大先生がお土産に干しアプリコットを持参して、何度も実験して成果を担いで帰っていった。
美味しい思い出である
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:3, おもしろおかしい)
15年ほど昔の話。
その頃の私は極めて遅れたものの、いい年であることを自覚
しつつプログラマに転身しようと心に決めて、とある小さな会社に入ったのですが。
入社後すぐに、とある下請けプロジェクトの打ち合わせ会議に
業界の雰囲気に慣れる為にも参加しました。
どうやら通信ログから料金を計算するプログラムらしいのですが、
コードの一部を見せてもらったらVBで殆ど同じ内容のIF文が延々と続いていて・・・。
絶句して『コレなんですか！？』と聞いたら料金計算の例外処理の
追加が多すぎて、アルゴリズムでエレガントに処理出来ないとの事。
追記が楽なIF文は最強らしい。
小手先の技工に拘るのは仕事として愚かでしょうけど、当時の
私にはとてもじゃないけど受け付けられない現実でした。 今でも厳しいですけど。
でも大手生え抜きであれ中小下請けであれ、技術ってそんなに差はないよね？
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
COBOLでコードクローン減らせとか……
#COBOLで開発したことないけどさ。
重過失は悪意と同視 (スコア:3)
昔、民法を勉強してた時はそう教わった。
ここでいう、「悪意」とは「ある事実を知っている」（法律用語としての悪意・善意 [wikipedia.org]）という意味なので、今回の場合、「バグがある」ことを東証はすでに知っていたという主張になると思うけど…これは無理筋では？
Re:重過失は悪意と同視 (スコア:2, 参考になる)
違いますよ。
重過失は「普通の感覚ではやるはずのない間違い」のこと。
商法では相手方が本当に知っていたかどうかは水掛け論になって益がないので重過失が悪意と同レベルの責任とみなされるだけです。
一方刑法では条文に書かれていなければ重過失と故意ははっきり分かれています。なので重過失を認定しても殺人罪にはならずに過失致死になります。
Re:重過失は悪意と同視 (スコア:3, 参考になる)
水掛け論だから、というのはちょっと違うかな。
商法は、当事者が商人でありその取引についての知識を持っているということを前提にしてます。だから、重過失をやらかした場合は「知らなかった」ではなく「知ってたけど放置した」という扱いになると。
今回の場合、争点は「品質保証に有効な手続きをきちんと取っていたか」という点でしょうから、重過失や悪意が関係するのは、品質保証手法を知っていたかどうかという部分でしょう。
その意味では、東証の言い分は、専門性を著しく欠くものであって重過失に相当するように思えるのですが……裁判官はどう判断するでしょうね。
#それはそれとして、バグの存在を知ってるなら、その検出に必要なテストの最小回数は、そりゃ1回とか2回だよねぇ。存在を知らないから山ほどテストするわけで、2回で見つけられるって主張に対しても、専門性の疑いを感じてしまう。
Re:重過失は悪意と同視 (スコア:2, おもしろおかしい)
> 酔って書いてるので
重過失だな
Re:重過失は悪意と同視 (スコア:2)
重過失、というのは、重大な過失のことで、故意（悪意）とは全く異なります（一歩手前、と説明すると分かりやすいでしょうか。）。契約違反があることを（実際に知ってたかどうかはともかく）普通なら知っているよね（＝故意（悪意）と同視し得る）、という理由で重過失が認定されることもありますが、他方で、普通なら絶対こんなことやらないのに何でやってんのよ（あるいは、普通なら絶対これをするのに何でやってないのよ）、という理由で、重過失が認定されることもあります。本件ではおそらく後者（のうち括弧に入れた方のパターン）の形で主張されているものと思われます。
コーディングとデバッグ (スコア:3)
「ソフトウェア工学」のなんたるかを理解してないんで、あれですが本質的な違いってあるんでしょうか？
Re:コーディングとデバッグ (スコア:5, おもしろおかしい)
コーディングはなにもない所からコードを作ることを、
デバッグはすでにあるものを消しながらコードを作ることを言います。
一般にコーディングよりもデバッグのほうが、BackSpaceやDeleteキーを押す頻度が高くなります。
# あるいは行削除とか範囲指定削除とか…
-----
コーディングは「ある一定の目的に沿う」プログラムを作ることを言います。
デバッグは「おめぇ、これ目的に沿ってねーじゃん」と呻きながらプログラムを作ることを言います。
-----
コーディングは朗々とやることです。
デバッグはコソコソとやることです。
-----
えー後何があるかな…
fjの教祖様
Re:コーディングとデバッグ (スコア:3, すばらしい洞察)
コーディングとはバグを作り込むこと、デバッグは混入したバグを取り除くこと
#品質管理において、です
Re:コーディングとデバッグ (スコア:2, 興味深い)
いいえ。
コーディングはデバッグです。
必要な機能が一切実装されていないというバグの。
Re:コーディングとデバッグ (スコア:2)
TDDからみたらそうなりますよねー。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:コーディングとデバッグ (スコア:2)
＞ #品質管理において、です
つまり現実においては、
「コーディングとはバグを作り込むこと。
デバッグは混入したバグを取り除きつつ、新たなバグを作り込むくこと。」
ということですね？
理想としては「取り除いたバグ１００に対し、新たに作り込んだバグ０」。
現実：取り除いたバグ ＞ 新たに作り込んだバグ
悪夢：取り除いたバグ ＜ 新たに作り込んだバグ
実際に悪夢の現場も度々あるから困る。
Re:コーディングとデバッグ (スコア:2, おもしろおかしい)
すごいね
じゃ「君の言う品質管理」の観点だと、コーディングなんかしないほうが良くなるんだね。
ソースコードの重複（コピペ）をみつけてくれるツール (スコア:3, 参考になる)
ソースコードには著しい重複があったことが判明している
サブルーチン [wikipedia.org]の呼び出しが負荷になるほどの処理だったとか？
サブルーチン（関数）のインライン展開ができない言語を使っているのかな。
で、ソースコードの重複（コピペ）をみつけてくれるツールって何を使ってます？
ぼくはRubyの場合はFlay [sadi.st]。
「そこは共通化が面倒くさいから目をつむってよ」って言いたくなるくらいのコピペまでみつけてくれます。
love && peace && free_software
t-nissie
バグも色々 (スコア:2)
東証側の「バグは一定の割合で必ず発生する」というのはかなり無理があるのでは。
そんな言い訳を通すのであれば、ネット証券会社の自動発注システムにバグがあって大量の誤発注があった場合、
「バグは一定の割合で必ず発生する」のだからこれはナシね、なんていう言い訳も当然通用しなければならなくなる。
＃もちろんそのときは東証は別の主張をしてくるでしょうが
つか、こんな主張をしてくる「ソフトウェア工学の専門家」ってどんな人なんでしょ。
バグっつーても、画面表示の誤字脱字レベルとブラックマンデーを引き起こしかねないレベルのものを
同じ確率で論じられないでしょうに。
＃むしろ「それはバグではなくて仕様」とか言い切ったほうが面白かったかもgesaku
Re:バグも色々 (スコア:3)
近代国家は過失責任主義ですので、損害の原因(この場合はバグ)を作りこんだとしても過失がなければ言い訳は認められるのですよ。しかもこの場合は明示的に軽過失の場合の免責条項まであるそうですから。
個人的には十分品質管理に注意していればバグが発生しないというレベルにソフトウェア工学は達してないと思うので、バグがある即ち過失とはならないと思います。ご指摘のようにインフラシステムでは注意義務のレベルが上がるにしてもです。
だからこそ重過失の有無が争点になってるわけです。
Re:バグも色々 (スコア:1, 興味深い)
バグは完全には防げないから、重層的な対応策を準備するのが東証のするべきことではないのかね
発行株式総数をはるかに上回る発注をスルスル通しちゃって、その後始末の処理もうまくいかないなんて、ちょっと酷いと思う
（いや、福島第一原発事故と同じで想定外の事態を発生させたみずほ証券が諸悪の根元だ！）
Re:バグも色々 (スコア:1)
重層的な対応策として
そっくりそのままのコードを複数置いて堅牢化しました…
かとおもいました。
Re:バグも色々 (スコア:1)
「バグは無くせない」と言うのはいいんだけど、バグ入りの製品を出荷されても困るんですよね。
「難しい」というのも自分にそれを扱う技術はないヘッタピの能力なしって言ってるのと同じ。
完成させられる技術も能力もないのに、出来ます! やります! では、同業者に迷惑をかけるだけなので
即時、辞めていただきたい。
壮絶な足の引っ張り合い (スコア:2)
＃東証のコメントは言い訳にしても苦しすぎる
程度問題なので難しいと思う (スコア:2)
中途半端な仕様書なら、危険というのも事実だから、コードを読めというのも、あるかもしれない。
ダラダラと書くのは、バグ検証が終わったコードを触らないという意味では、正しい部分もある
コーディングはいつ終わるの？ (スコア:2)
ドキュメントを書き終えたらね。
そりゃ、判って当然 (スコア:1)
>みずほ証券側はソースコードを解析した結果、「たかだか2つ」のテストを実施するだけで
>問題となっていたバグを容易に発見できたと主張。
ほかにもぞろぞろバグが発見できたならともかく
あらかじめ問題がどこにあるか判っていりゃ、あぶりだすテストも楽に設定できる罠。
まあ、ああいう巨大なシステムも間抜けはどこかにいるわけで。
ロケットだって爆発したわけだし。
他山の石としよう。
Re:そりゃ、判って当然 (スコア:1)
http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465908/ [nikkeibp.co.jp]
擁護する方がおかしいわ
履歴もいらんとな (スコア:1, フレームのもと)
dodongaです
コ～デイングが済んだらリポジトリもタグも要らないのかな。
怖くてそんなこと出来ません：
# 暴挙以外の何物でもないですね。
閑話休題
Re:履歴もいらんとな (スコア:2)
東証の主張は、
理想的にはドキュメントに反映させるべきだけれども、実際にコードが動くか否かが最も重要であって、ドキュメントは二の次だよ。
との意だと思うが。
T系？ (スコア:1)
「バグは一定の割合で必ず発生する」「バグを0にすることはできない」
これってもしかしてT系のチェックリストにありがちな、
「ソースnステップ辺りm個のバグを検出させること」を律儀にやった結果なんじゃ
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:T系？ (スコア:3)
小規模なプログラムで仕様通りの動作をして特にバグもなかったのだけど、担当者からバグ収束曲線に近似した形で推移してくれないと困るとか言われて、どうでもいいことをわざわざバグ認定してちょろっと直してを何度かやりました。
最初からバグが少ないと「それだと困る」と言われる世界を初めて知りました。
完成後かなり経ってから、通常あり得ない操作をやると本来あるべき動作にならないという仕様上のバグに気づいてしまったのは内緒。
Re:T系？ (スコア:2)
向こうの担当者もわかってくれているのだけど「なんとかお願いします」って。
「検出されないことも<あり得る>」なんてこと言ったらやぶへびです。
Re:T系？ (スコア:2)
お客さんも馬鹿を説得するよりそれっぽく数値を作った方が余計な手間がかからないということでこっちにお願いしてきているわけで。
品質管理部門も杓子定規に変な本の受け売りみたいなことに執着しないで、物事の本質を見てほしいものです。
Re:T系？ (スコア:1)
Tじゃなかった、Hだ。
お詫びして訂正します…
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:T系？ (スコア:1)
NだってFだってやってんじゃない？今はしらんけど
過去の話ならＩだってやってたし
充分重過失 (スコア:1)
リグレッションテストしてた記録が「もうありません」じゃね
うへー (スコア:1)
どっちにしても係りたいと思えない(第一印象)
つか実務品についての姿勢がどっちも変じゃね?
M-FalconSky (暑いか寒い)
法廷での主張、それ以上でも以下でもない (スコア:1, 興味深い)
修正後のドキュメントがないのも事実、ドキュメントを見ればあきらか。
重複箇所があることも事実、ソースを見ればあきらか。
その上で裁判を有利に進めるために、ソフトウェア工学上どうなんだとかとかみずほのシステムはどうなんだとかは完全に横において、関係者や弁護士のアドバイスに基づいて証言しているとしか...
だからどっちも本音じゃないし、ベストプラクティスじゃないと思いますよ。
Re:そもそもバグなの？ (スコア:5, 興味深い)
テスト項目に、６０万円の株を１円で売ろうとしたバカがいた場合、ストップ値に変換するっていう項目はあったんだよ。
そのテストを通したから、６０万円の株を１円で売ろうとしたバカを差し戻す手続きはテストする必要がなかったんだ。
しかしそのテストのあと、東証の開発のバカがプログラムをバグ版と挿し変えたためこんなことになった。
レベル低過ぎには同意。
そりゃ違うだろ (スコア:3, 参考になる)
そりゃ問題を引き起こした原因の半分だけだし、仕様通りで問題ない部分だ。
問題はキャンセルが仕様通りにちゃんと出来なかったことなんだよ。
変換して処理した後はキャンセル処理も1円をストップ値でちゃんと処理すべきだったし、
ストップ値で書き換えた注文は通常の注文とは違って処理中はキャンセルできないようになっていたらしい。
テスト後にバグ版に差し替えたんじゃなくて別のところが仕様に準拠してなかった。
仕様通りならちゃんとキャンセルできたから、被害がここまで拡大することはなかった。
バカバカ言う前にちゃんと調べるべきだろ。ストップ値に変換する処理はちゃんと動いてるし。
問題は、仕様と違ってストップ値でキャンセルしないといけなくなってたことだ。
ここもちゃんとストップ値に書き換えてキャンセルに行かなきゃ行けないから、テストをする必要は相変わらず残ってる。
レベル低すぎには同意。
Re:そもそもバグなの？ (スコア:1)
Re:そもそもバグなの？ (スコア:2)
Re:ISO9000の縛り (スコア:1)
弊社では関連規格であるUSO800にしたがいISO9000対応をしております。
じゃんじゃ？
#ベタ過ぎるのでACで。
Re:法律の縛り (スコア:2)
「泣く子と地頭…」なので消滅しないのでは？
Re:北の将軍は許してもいいから (スコア:2)
同様に「ドキュメントさえ作れば品質問題は解決する」という奴も死刑にすべき。
以下同文。
Re:ソフトウェア工学の誤用甚だしい (スコア:5, 参考になる)
> ドキュメントのメンテは”当然”の事
そもそもここに錯誤があって、元記事の1行まとめやタレコミが恣意的な誘導を行っているとしか思えないんだが、
東証がメンテしていないっていうドキュメントはごく一部のみなんだよね。
なのに、一読しただけでは、まるですべてのドキュメントをメンテしないように受け取れるように書いている。
このストーリーでも案の定、大量に釣られてる。
それもメンテしていないのは、ソースコードと1対1に対応する実装と等価レベルの詳細なやつ。
「a++」の代わりに「変数aに1を加える」といった類のもの。
ここの読者なら、書くことが馬鹿らしい、無駄って思えるものだろう。
でも、勘定系では敢えて書き、人も分けてチェック＆レビューのチャンスを一段増やしている。
まあ、さすがにテストが終わるとこのドキュメントはメンテしない。
東証でも、上位のドキュメントは、当然、業界標的な工数をかけてメンテしているし、
ドキュメントの階層に応じて更新のライフサイクルを定義して管理しているというのは、
元記事の中まで読むと、書いてある。
記事も読まずに感情だけで書く人間が多いというも悪いが、
それを利用して、さいしょの1行まとめにバイアスを入れた元記事はかなり悪辣。
で、みずほの主張が受け入れられると、今後国内のITコストがかなり跳ね上がることになるため、
国内ITベンダは一瞬得をするが、国内企業は総じて国際競争力を失うことになる。
アジャイルにも逆風。
いいこと無いよね。