東証「システム開発では、一度コーディングすればドキュメントは不要！」　みずほ証券「おお、もう…」

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

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

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

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

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

もう、東証もねぇ

Rubyの教祖だっけ?

分かってねーな。ソースが仕様書なんだよ。
まったく現場が分かってない

ソースが一番正確なドキュメント
だから高級言語なんだろ

ソースと仕様書が合ってないぐらいならないほうがマシ

ドキュメントってソースから書き出すもんだろ

ソースが現実なのはわかるが、
日本語で詳細仕様を説明しているドキュメントは
運用で絶対必要だろう

コードは仕様書（ｷﾘｯ

ソースコードの修正時にそれに対応するドキュメントの修正を行っていなかった

ドキュメントとソースコードに相違があるから
修正の度にソースコード読み直すの？

東証

　「システム開発では、一度コーディングすればドキュメントは不要！」　　
http://hayabusa3.2ch.net/test/read.cgi/news/1365248433/

みずほ証券「おお、もう…」

そら世の中に存在しないもん売っちゃいけねえよな。
それができたら株価操作自由自在だぜ。

確か前に日立とNECのネットワークバグでオンラインダウンしてたよね

ソースと仕様書をあわせる努力ぐらいはしろよｗ

ただまあ大量誤発注はしたのが悪い

誤発注するほうが悪いんだろ、みずほはあきらめろよ

2010年ぐらいに納入されて、今動いてるarrowheadって富士通製のだよな
ジェイコム株でチョンボしたときのシステムも富士通製だったの？

■東証側
「重複する記述を含むプログラムはそうでないものと比べて信頼性が高い」
「コーディングが終了した後はドキュメントは不要」
==> いくらなんでもあり得ないコメント。

「バグは一定の割合で必ず発生する」
「バグを0にすることはできない」
==> これは、まあそのとおり。

■みずほ
「「たかだか2つ」のテストを実施するだけで 問題となっていたバグを容易に発見できた」
==> それは真実なんだろうが、これだけでは、普通のシステム開発ならば
　　　前もって発見された不具合かどうかについては判断できない。

>>2
いいセンスだ

>>10
普通は詳細設計所というコードレベルの仕様書を書いてソースを書く
ソース修正の場合には、ソース内にきちんと修正日、修正内容を記述することに加え、
影響がある設計書を書き直し、再テストを行う必要がある

「コーディングが終了した後はドキュメントは不要」なんていう発言は、もうムチャクチャ
車メーカーが「車作った後にドキュメントは不要」と言ってるのと同じ

買われてしまったら取り消しはできんだろ
個人だってそうやってんだし

でもこれって、業界のステマって説もあるけど
裁判してるってことは、本当のミスだったのかね

受け入れテストもやってねーのか？

>>6
全くだ。
ただ、何をどうするプログラムなのか、くらいは必要だが。

>>4
割とマジだから笑えない

ずっと担当者が変わらなくてドキュメントが不要なのか
無責任な外部のソフト会社がドキュメントを残さなかったのか
どちらかだな

>>19
コードレベルの仕様書なんてゴミの最たるものだろ。
コードと同じならコード見ろや。
どうせコード修正のたびに設計書修正漏れが積み重なって、
いずれ役に立たないどころか読む人を誤解させるだけのものになる。

仕様書は少し詳しい基本設計書程度で十分だ。

詳細設計書をかく工数＞＞＞＞＞＞コーディング工数

これをわかっていないクソ企業多すぎ

>>20
ステマで400億円も物故く企業があったらお目にかかりたい(´･ω･`)

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

後出しなら何とでも言えるわな
ところでソースって公開されてんだろうか

検証用のプロトタイプがそのまま製品になって納入されることもあるし
ソースに沿ったドキュメント作るとかザラだから>>4は笑えない
本当は絶対によくないけど、仕方がない

せめてソースにコメントかけや
マジで殺すぞ

>>19
コードレベルの仕様書というドキュメントを元にソースを
書くのが本来の手法って事か
でもこのスレだとソースが最も正確ってレスがあるねぇ

コードをそのまんまなぞるような仕様書やコメントはいらんわな。無駄だ。

a++; /* aに1を足す */

↑こんなの。

とりあえず動きゃいいんだよ
何かあったら頑張って直せばいい

東証の本音　「ソースもイラネーよ、バ〜カw」

>>25
それって、コーディングしたヤツが後付でソースを元に書いた仕様書のことだろ

きちんとしたコーディングできるヤツが書いた詳細設計を元に作られないから、
初心者プログラマが自分の思うように書いたクソみたいなソースができて、
あとで混乱するだけなんだが

コードと仕様書を１００％一致させたければ、仕様書をゆるく書くか
コードを自動生成するしかない

このスレを見るだけでも日本が国際標準規格を作れない理由が垣間見えるな
現場での間に合わせのコーディングのような「職人技」が横行する社会だから規格を作れないのだよ

ああ、初心者レベルの派遣IT土方の寄せ集めの会社じゃ仕方ないか。

ソースを解析できたって、ＪＡＶＡアプリかなんかかよ。

処理の目的ぐらいは書いてくれ
何も知らずに保守を渡されるほうは、
ソースコード読んでもなんのサブルーチンなのか、
わけわからんのだよ

コードレベルの仕様書とか言ってるの日本くらいだよ。
オフコン業務アプリ時代の名残やね。
IT土方に仕事させるためには仕方ないのかな。
だから生産性が悪いんだよね。

>>31
そりゃ当たり前、正確なのはどの分野でも成果物
どんな欠陥品でも、成果物に対して一番正確なのは成果物ｗ

そもそも誤発注を絶対にしない人間が入力すればいいじゃん

>>19
そんな仕様書が必要なのはよっぽど無能なプログラマ

基本設計書まであればいい。
詳細設計書とか、時間の無駄

ソースコードが正確ってあほかと
何を基準にその正確さをはかるんだよ
仕様書を基準にだろうが

>>4
真理だな。
アジャイルがドキュメントを極限まで削るのもそういうこと。
仕様書が必要なのはソース読めないカスPMとシステム納品はexcel方眼紙って考えしか頭にない糞POだけ。
証券取引だのの金融系の複雑なシステムは仕様書本体より外設が重要。
あとは動いてるものが正義でいい。
データフローやシステム相関図が抜けてたらキレていいが、コードを日本語にしただけの詳細設計を必死こいて更新する時間があるなら
その分テストケース消化したほうが品質は上がる。

どこまでが必要、不要なのかは知らないけど
現場でコード書いてる人間は必死そうだな、このスレ見てるとw

>>45
arrowheadのOS部分のソースなんて詳細設計書存在しないけど（笑）

このケースの場合はどっちが勝ちそうなの？

試しに国のシステムでそれやってみろよ。
簡単に損害賠償だから。

Linuxのカーネルにコードレベルの仕様書など無い。
コードをなぞるような仕様書が必要なのはIT土方が悪い。

>>46
日本のソフト開発は未だCOBOLの呪縛から離れてないなぁ
欧米だと余りドキュメントは書かない所まで事細かに買いて、中国に投げて喜んでいる人ばかり

>>35
クラスの単位や、共通関数程度ならドキュメント化した方がいい。
でもその中身の細かい書き方、一つ一つの変数の初期化の仕方や、
あらゆる条件分岐の書き方まで全部ドキュメント化しろ、なんて話になったら、
それは馬鹿としかいいようがない。
同じプログラムを日本語とプログラミング言語で二回書くなんて無駄もいいところだ。

これって人間が警告無視して「はい」連打してたって話じゃなかったっけ？

同じ処理が重複しているってソフトウェアの品質管理には規定されていなかったような気がする

でも間違いなく保守性が落ちると思うんだけどな

仕様書いらないって、何を基準にテストしてるんだってことなんだが・・

誤発注ぽい場合はポップアップで知らせるようなツールをみずほが使えばいいだけだろ
個人が使ってるやつみたいに。
みずほトレーダーのなんてその程度のレベルなんだから

>>40
それはコメントとメソッド名、クラス名の命名規約を整えたほうが早いね。
たまにDiffでめんどくなるからコメント書くなとか言うアホとadd-start　add-ennd-日付みたいなのを義務化する馬鹿がいるけど。
「カウンタをインクリメント」とか書いてる馬鹿をボコって処理目的書かせるのがPGチームのリーダの役目だわな。

>>45
「仕様書と相違していたので修正しました」って馬鹿のせいで鼻血垂らしながら徹夜したSEがそのセリフ聞いたら発狂するぞ。

なんだおまえらIT土方だったのかよｗｗｗ

ソースコードにコメント入力させることを義務づけたらいい

>>59
ち、ちゃうわ。
もうとっくに足洗ったわ！

>>59
書く内容から教育しないと>>58になる。

>「コーディングが終了した後はドキュメントは不要」と主張

頭沸いてるのか？

株なんてギャンブルで遊んでるのが悪いだろ
仕事しろよｗ

何が正しいかもわからないような奴がテストして、メッセージの文言が気に入らないとか意味不明な不具合報告を上げてくる

>>19
だっさw
VCS使えよ、21世紀だぞwww

>>56
>>1のは仕様書そのものが不要って意味だが、スレの流れとしてはコードレベルの仕様書って
意味だわな。んで、んじゃどうやって単体テストの妥当性を測るんだよって話なんだろうが、
関数レベルやクラスレベルの仕様書は否定してない。
単体テストはそのレベルでってことでそな。

>>52
どれほど詳細に書いてもオフショアで上がってきたブツが一発でコンパイル通ったことなどないぞ。
現実はそんなもの。
きちんとブリッジSEおいて向こうの現場も仕切ってるならちゃんと回るけどね。
「オフショア」という呪文を覚えたてのSI屋にはそこんとこが判ってない。

バグの責任認めたら影響範囲でかすぎだからみずほの負けだろうな

>>56
テストが目的なら、最初からテスト仕様書を作ればいいじゃない？
何も設計書を作ってからテスト仕様書を起こす、なんて二度手間は必要ない。

ソースだけではわからん事なんていくらでもあるのに、半可通が分かった風な事言っててワロスwww

いや笑えないな、日本のIT業界。

>>70
ソースだけで分からないことが詳細設計書で分かるわけがない

それでこのスレでは誰の言ってる事が一番妥当なのさ
開発者同士で盛り上がってないで教えてくれたまえ

>>56
金融系のシステムは設計書の分岐だけ洗ってテストすれば丸く収まるようなかわいい奴じゃない。
取引所のルール、協会のルール、金融庁のルール。
全部合わせてどんだけのテストケースになると思ってんだ？
600程度のテストケースってのは修正個所が局所だったから収まってる話。

みずほがたった2つのテスト、とか言ってるけど、テストエンジニアがそのたった2つを軽く1000を超えるケースから洗い出せる可能性はガン無視してるわ。

ソースしか無いのにどうやってテストするの？
それともテスト仕様書に正しい仕様が書いてあるの？

NTTデータってそういう会社なの？

>>75
それは内緒や

>>72
誰がバグってるかテストするからまずこのスレの仕様書を書いてくれ。

みずほ証券はなんで誤発注したの？

＞東証側は「バグは一定の割合で必ず発生する」「バグを0にすることはできない」などとして
＞免責を主張していた。

つまり東証の言い分は正しいのだ

OSSだってまともなプロジェクトはちゃんとドキュメント管理してんのにwww
バカだこいつらw

>>77
よしてくれ、俺は一般人だ
そんなもの書けないのさ

東証「ドキュメントの作成、保管、更新に関するコストは不用だ
　なぜならソースコードというオリジナル文書が存在するからだ
　ドキュメントに関するコストを削減する事で開発費は半分に抑えられる」
エコノミスト「素晴らしい！コスト削減に貢献する画期的発想だ！」

仕様書なんて適当でいい←老害

ITドカタなら一度やめとけって言っておいて
あとで困ったときにふっかける

>>71
システム作成に関わったことないか、関わったとしても、すげー末節の部分だけだろw

ビジネスロジックの部分なんてドキュメントなしで追える訳がない。
ソース見て何をしてるかはわかってもロジックの目的はまず分からん。

お前らソースがソースがって言うけどさ
そのソース作った奴へダメ出しとか修正させるとかできないの？
なんで？負け犬だから？

>>82
逆だろ。
老害ほど無意味に細かい仕様書を書かせたがる。

アジャイルとかリーンとかで開発してるとこと、金融系の総本山で開発してるとこを一緒くたにして議論するのは無理がある
噛み合うわけがない

ドキュメント作るも作らないも契約書次第だろ
その辺どうなってんの？

>>75
データは山ほど抱えたデー子に勘定系、金融系のエンジニアを山ほど抱えてる。
これまではそのエンジニアで食えていたが最近は厳しい。
理由は後継者を育成してないから。
SIチックに「ソース読めなくてもいいから業務要件まとめろ！」って奴と「業務とかいらねぇわ。鬼のようにライブラリ分解して理解しろ」って奴に分派してる。

>>74
金融系は素人がテスト仕様書書けない。
当然結合以降が前提になるけど、テスト仕様書書くのに必要な知識は証券六法と税務、会社法、金商法、協会の規程、取引所の規程、がある。
これ、詳細設計からあげられる奴いるわけない。

>>84
目的が知りたくて仕様書を見たら、ソースを日本語に直したものしか書いていない時の絶望感

設計書などのドキュメントがなかったり、ちゃんとメンテされてなかった結果、
特許庁のアレになったんだぞ。
おれらの血税５０億が、何の成果物もなしにパーになったんだぞ。

生産性や開発効率を考えるより、
システムのライフサイクルの観点から
長い視野で考えてモノ作らないと

ﾊﾞｶが書いた日本語でOKなﾄﾞｷｭﾒﾝﾄ

>>78
株数と値段の数字を逆に入れて売り発注
しばらくして誤りに気づき取り消し注文
取り消せなかったので同じ株数を買い発注
その間にBNFが大儲け

>>84
ビジネスロジックを詳細設計書に書くなんて言ってる時点で程度が知れてる

詳細設計所書くよりコメント目一杯書いて欲しいです

なんだよ
ドカタの愚痴スレかよつまんねえな

コメントを書いてDoxygenで集めれば完成です。

ソースを見ればわかる(キリッ！

ソースが間違ってたらどうすんだよwww

>>89
この手システムは法律知ってるかつシステム全体見れる
諸葛公明みたいな人がいないとね

>>86
そのわりには10年前に作られた仕様書がファイルだけあって中身白紙なんですが＾＾；

>>94
全く同意
同じようなレスしようと思ったとこだったわ（笑）

>>91
スレ読んでから来い。
特許庁がこけたのは業務要件を洗い出してUMLに置き換えるレベル。つまり基本設計部分。
今回問題になってるのは詳細設計。

SVNで全部管理しようず

どんなコメントでも無いよりまし
好きなだけどんだけでも長くかけw
今時のエディタはコメント非表示くらい簡単にできる。

老害は時間止まっちゃってるから、ソースが醜なるとか、くだらない因習を引きずるwww

東証のシステム担当部署なんて、どうせSIに「よ！頼んだよ〜」って電話かけるだけの仕事だろ。

>>98
じゃあ設計書を先に修正して
そのままｿｰｽにｺﾋﾟﾍﾟで転記とけよ

どうせﾄﾞｷｭﾒﾝﾄなんかだれも読まないだろ
ﾊﾞｶが書いた問題の発生しているｿｰｽを探すのが先になるだろうしな

仕様通りにｿｰｽが書かれてるなら
ご発注が取り消せないわけがない

つまり、ｵﾘｼﾞﾅﾙの基本仕様は間違ってない

>>100
あるある
でなんかのきっかけで仕様書起こすことになって、調べていくと新たなバグ発見

>>94
詳細設計書なんて一言も書いてないワロスwww

いや、ドキュメントの修正位してるわ（要求もされてる）
と別システムに関わってる俺が言ってみる。

それとは関係ないがこんな日本を代表する会社が
ギリギリコストカットしようとすんなよな…

案外ソースコード紛失したりして

つうかまともな組織ならドキュメントのメンテは専用のチームがやれよwww

>>78
存在してない現物株を売れるってシステムがまずおかしい
これが使えるなら空売り出来ない株も無限に空売る事が出来る


この部分の追求が無いってことはこの部分に関しては自分の利益として問題視してなかったという事になる
誤発注が取り消せないってのはちょっとおかしい
そもそも誤発注かどうかなんてのはシステム側で判断するものじゃないし
誤発注が取り消せないなら発注そのものが取り消せないはず

>110
証券関係とか書類保管期限短そうだもんなぁ

「たかだか2つ」のテストを実施するだけで判明するようなバグなら
類似の誤発注が相次いでないとおかしいだろ
バグの内容に合わせてテストを作るなんてカンニングみたいなことやってないか？

東証がまともなこと言ってて驚いたら
よく読んでみたら保身のためのだったｗ

プログラマー軽視の時代だな
そのうち見積り屋ばっかりになって
ふくいちの実作業者不足みたいになる

>>99
今でもいるにはいるよ。
javaだろうがCだろうが気合いで勘所だけ読んでバグを発見する業務SEとか。
年齢的にはすげーおっさんだけどね。

残念なことにそれだけの能力がある人が実は3次請のパートナーだったりする。

今の日本のITには「能力があるエンジニア」の再定義が必要だわな。
一口に能力と言ってもいろいろあるワケだし。
俺は業務SEには賛成してるが、最近の業務SEは「お客様に理解していただける資料を作れます！」とか「コミュニケーション能力には自信があります！」とか馬鹿みたいなことばっか言うし。
コミュ障でパワポかけないけど、法律、経理の知識があってソース読めます！って言う奴の方がよっぽど現場で役に立つんだけどな。

>>115
それ言ったらみずほだって保身の為だろ
アホな誤発注が発端なのに、難癖つけて金取り戻したいだけなんだから

>>113
知ったか乙。

法定帳簿は原則10年。
IPアドレスは今のところ3年。（この先もっと伸びる予定）

法定じゃなくても税務署、取引所、金融庁からの問い合わせに関しては10年超でもたいてい答えるよ。

株なんてポチっとなってしたら取り消せないのは当然に
思えるんだが。

>>112
機関投資家とディーリングは可能。
受け渡し日までに株券（今は電子だけど）をそろえれば問題なし。

>>119
バカじゃないのwww

>>120
その通り
これがバグ認定できる超能力があれば仕様書も要らないってさ

>>122
そう思ってるシステム屋は五万といる。
でもやるのが常識になってる狂気の世界だ。

セガだったか昔のゲームの復刻版を出したいのに昔のプログラムマーの変態技巧が凄まじくて
現在のフォームにコーデック出来なくて出せないってのがあった気がする
明らかに要らないプログラムがあるんだけどそこを修正するとまともに走らなくなるって訳のわからん事になってるらしい

重複したコードって要するにコピペコードだろクズじゃん

確認画面が出てたのに、みずほ証券が「はいはい」って見ないでOK押してたんだろ？
どっちもどっちだと思うわ…

>>122
違うわwww

だろうなあとしか言ってない相手に知ったか乙とか、お前が知ったかじゃねえかuzee

>>128は>>124なw

>東証「システム開発では、一度コーディングすればドキュメントは不要！」　


こんな○○○○が作ったシステムの上で日本の株式市場は動いていたのか・・・

建設の世界では、ちゃんと完成図書を出して仕事が終わる
ITってこんなに適当なのか・・・改修とかどうすんの？

でも結局納期までにシステム動かさないと洒落になんない事になるし
システム動いたら碌に確認もさせてもらえない位セキュリティ効かせてくるし
頑張って頼んでも「なんか不備に心当たりあんの？」って聞かれたら何とも言い様が無いし

>>131
普通のITは設計書も書くしシステムと一緒に設計書も納品するよ
そうしないと保守を請負う会社から連絡が来ちゃうこともあるし

土方と一緒の扱いなのがそもそもこの業界の最大の欠点だかんな
土方は建築士のスキルとかなくても指示通り作業できるが、
コード屋は全員が建築スキルもってないとまともなもの作れん

ソースコードってウイルスの事でしょ？ニュースで見たよ
東証はウイルス使って取引してるの？こわい

ソースの横にコメント書いとけばいいよ

文章が全く理解できないが

誤発注した時点で重過失じゃん。

なんで東証に責任押し付けてんの？

マルスで5年開発している俺に質問ある？

ご発注の取り消し機能が仕様に含まれてたのに
バグってて使えなかったとか、そういう感じの話だったりするのかな？これ

ドキュメントがないと困るけど
ドキュメントがいい加減だと更に困る。
ドキュメントの正誤を確認するために
結局ソースコードを見る羽目になってドキュメントの全く意味がない。

メンテがされてなくてクソみたいな資料しかないことが多いから
最初からソースコード見た方がマシなのは事実。

ν速にはIT土方が結構いるのねｗ

一般ユーザーは入札に0コンマ数秒とか遅らせる仕組みが有るから勝てないんだろw

>>125
じゃ必要なんだろその部分は
タイミングとるためにわざと要らないコード書いたりもするんじゃないの

お前らは何もわかっていない

仕様はコーディングの後に作られる

これが真理だ

基本設計はキチンとね!
それさえおさえておけばよいはず、

要件定義だけ

他社が改修出来ないする為の糞味噌テクニックって重要じゃね？

東証はどこに頼んだ？NTTデータ？

>>144
俺はそれでいいと思うけど、問題はコーディングの後に仕様が固まったのに
ドキュメントに起こさずに納品したり他人に引き継いだりするクズが多いことだろ

>>149
ｵﾏｴんとこ納品物を検収もしないの？

>>147
自社で出来なくなってたなんて落ちはいらない

>>143
まぁ、ある程度尾ひれが付いてるとか眉唾な部分も多分にあるんだが
記号で囲んであって題名だったりマクロ名書いてあったりするところあったりするじゃん？
そこですらいじったらダメらしい、一説には容量がちょっとでも変わると動かないんじゃね？
って意見が出る程謎プログラムになちゃってるとかなってないとか

>>19
え？詳細設計書って、ソース上げてから、
書くものじゃないの？？違うの？？

個人で開発してるんじゃないからさぁ

みずほは情報総研なんて自前で持ってるんだっけか

>>131
ソースコードがいわば図面なの。
図面を見て実際にする建築作業自体は、コンパイラが行ってくれてる。

詳細設計書は、図面を作るための設計資料とでも言えば良いか。

もやせ　もやせ　真赤にもやせ
いかる心に　火をつけろ
たおせ　たおせ　力のかぎり

>>137
「ああ確かに誤発注したさ、したけどさ、取り消せないとかひでーじゃん！」
って言ってる模様

仕様書なんて存在しないプロジェクトばっかだったなぁ
SEが夜逃げしたのもあったなぁ
そして８割炎上するかした現場で火消しする

足洗って良かったよ、ほんと

みずほ「ソース無ぇの？」
東証「そおすっね」

レビュー！レビュー！レビュー！

>>155
的外れwww

>>138
JRSの人？JEIS？

レビューまってたら終わらないんだ、よっぽどレビューやるやつが最後のデバッグテストしろと!

バグではないだろｗｗｗ　注文した通り売りに出されただろｗｗｗｗ

住友とJRな人じゃね？

>>125
ナーシャ・ジベリだろ
SEGAでも活躍してたが、どちらかというとFF3や聖剣２のが有名かもな
良くも悪くも

>>164
仕様で取り消せるようにしろって書いてあったら契約不履行で金払わなくていいレベルのバグだがな。
仕様に書いてないなら、追加費用払ってみずほが修正させればよい。
つか普通のシステム屋なら、要求仕様一言一句確かめるテストくらいすると思うんだか。

>>137
でも車でいえば、ブレーキとアクセル間違えてしまい慌ててブレーキを踏んだが止まらず、10キロ先の壁に激突したようなものだからな。

>>4
まあ時間がねぇから仕方ないという言い分も分かるが、必要なプロセスすっ飛ばしてバグ出した時にお客さんに説明つかないし、再発防止策とか報告するとなったら目も当てられない。
やると決められたことが出来なかったのに、徹底してやりますなんてお客さんに言った所で、次にソフト開発お願いしてもらえるとは思えないね。

>>162
外注です

>>161
全くわかってないのはお前の方だよ

こんなん裁判所判断できるの？
今後バグ出したら全部訴えられちゃうじゃん

>>67
責任の所在が曖昧だからそうなる。

仕様書に合わないものはPGのミス。現物が正義ならバグがあっても納品可能。

やらかしたオペレータとかはその後どうなったんだろうな

普通に派遣契約解消とかで終わりかね

操作手順書と運用手順書以外に個別のプログラムの仕様書は「別料金」ですなんて
業者普通にいるじゃん。

昔は仕様書をエンピツで手書きしてたって本当？

修正は二本線でって仕様書の初めに書いてあったよ

>>176
なんと請求書も住民台帳も手紙もな

doxygen使えよ

>>176
そんなに昔でもない
現在でも手書き仕様書が電子化（PDF）されて生きてる

修正時にwordで書き直してる

>>176
っとスマン手書きに反応した
さすがに住民台帳はない･･･と思う

>>19
富士通の仕様書工房でいいだろ


まだつくってるのかな

これを元に
もし、東証がまたやらかすと見越して
どの株を買って漬けとけば儲かるかね

東証のベンダーは富士通

>>1
＞東証側は「重複する記述を含むプログラムはそうでないものと比べて信頼性が高い」

この主張は酷いwww

この手の話題っていつも
モノの難度次第じゃねーの？と思うわ
簡単なモジュールはソースなんて言語知らない奴でも一瞬で読めるが
複雑だと言語熟知していてもソースだけじゃ気合入れてかからんとキツイし、時間もかかる
そこで初めて仕様書、設計書が活きて来るわけで・・・
仕様書あるなしでまとめるのではなく、需給に応じた柔軟性が重要

お前らもっとわかりやすく俺に説明できねーのかよ

最近、プロジェクトリーダーとか言って、仕事をするわけではなく
進ちょく管理だけをやって、威張っているのが増えてない。
業務知識も言語の知識もなく、金の管理もせず、
ただただ怒鳴りまくるだけという。

別にはなから詳細設計書作ってなかったわけじゃないだろ

リリース後の仕様変更、追加の時に納品物として修正した詳細設計書が求められてないから修正しませんでした
修正、追加箇所はソースコードに記載してあるからそれ見てね

普通にありえると思うが

設計書wwww
意味ねぇぇぇぇぇwwww
詳細設計wwwwwwwwwwww
設計書って言いたいだけやん

詳細設計書がないからといって失敗するとは限らないが
失敗するプロジェクトは詳細設計書が(他のドキュメントも)ｺﾞﾐ同然

よくあることよくあること

> これについて
> 「コーディングが終了した後はドキュメントは不要」と主張している。いっぽうのみずほ側は
> これについて「ソフトウェア工学の知見を無視する暴論だ」として、重大な過失

設計書でロジックを表現するのもSEの力量なんだがな
「ソース読め」はハラスメントなのに自覚してないやつ大杉

>>1
ドキュメント作るの面倒だしなw

>>4
こういうバカがいるから、いつまでたっても
ソフトウェア業界は底辺産業なんだよ

ソースが仕様書(キリッ っていうなら、契約時に言ってみろよ
アジャイルとかキチガイじみた宗教にはまってるバカがおおいよな、最近

プログラマー多いねww

業務の要求仕様やシステム要件に関わる部分なら別だろうが、
客によってはプログラムの詳細設計書なんて必要ないからな。

>>4
せめてソースにコメントで仕様を書け
つうか修正したらコメントも修正しとけよｗ

汎用機でドキュメントのメンテしないなんて無いだろ。

ソース
bb.watch.impress.co.jp/cda/static/image/2004/11/17/yc01.jpg

＞重複する記述を含むプログラムはそうでないものと比べて信頼性が高い
元プログラマとして、これだけは絶対に間違ってると断言できるわ

さすがパソコンの大先生達は違うとこのスレ見て感心しますた

そもそも証券会社が無限空売り出来るというこは問題にならんのか？

>>203
そそ、なんぼでも板厚くできるよなｗ

おまえらが
なに言ってるか
わからない
日本語話せ

字足らず

外仕はメンバーの意識あわせのために必要だが、内仕は要らんな
内仕とソースは１対１対応だからソース読めばいい

修正前のソースをコメントで残しておけば変更された履歴が分かって修正する意味が理解できる
でも目の前でバグが出ているのにじっくりソース見ている余裕なんてない

>>153の衝撃発言に驚いた

>>176
フローチャートを紙で書かされたよ

>>208
ギリギリまで仕様がかたまらないで二転三転するとそうなる

ドキュメントを用意するは甘え。
背水の陣で挑んでこそ一流。

企業のシステム室にいたから完成後にドキュメントをしっかり直す時間が取れたけど
ソフト会社じゃまず無理だろうな

>>193
読むのは出来るだろ。
「実装足らねェからお前も2本くらい書け」って納期間際に言われるのがハラスメント。
で、そんなハラスメントは結構ある。

>>195
契約の形態によるんじゃね？
著作権だのライセンスごと納品になるなら、むしろソース本体を納品でいいだろ。
著作権はベンダ側にあるならカスタムの仕様書納品になると思うけど。
あと、アジャイル基地外が多いってのは同意。
システムの規模と客の理解度を考えてから導入しないとWFよりも燃えやすいんだけどね。

>>189
ありえるというかありふれている位だけど、あったらイカン部類やろｗ
と思う運用の俺。

金融系だと最初のドキュメントは紙でその次に一太郎で、その次がＷＯＲＤとかざら
大規模開発やるときに修正対象のモジュールのドキュメントだけ
フォーマットが変化していくんだけど、修正対象外の奴は、以前のフォーマットのままで
次第にアンタッチャブルになっていってメンテナンス不可能になって行ったんじゃないされない？

基本的に東証とかのでかい金融系だと詳細設計の工数も込みで予算作られているはずだから
メンテナンスしてませんでしたは、まずい気がする

>>176
昔はソースコードも紙に書いたよ。
上司のハンコをもらってからコンパイルするため端末に打ち込む。

ソースってドキュメントから作るもんだろ

>>217
そのドキュメントが完璧じゃないから問題なんだろ

>>138
みどりーのまーどーのー
って、みんなで歌うの？

>>155
これが割りと正解

ついでにいうと詳細設計書はメモ程度でok
何だよ、詳細設計書の書き方のレビューってww

>>205
有るビルに、構造上の不具合が発生した。
調べてみると、設計段階で容易に解るミスだったが、
しかし、その設計図その物がなかった。現場で地面に描きつつ創ったらしい。
担当者に聞いたところ、「事件は会議室で起きてるんじゃない、現場で起きてるんだ！」
そう言い張り、そのビルに入居してた人々は頭を抱えてる。

多分この後、「だって偉大な先輩がこうやって創ったって伝説が！」そんな反論がある筈。

>>216
リソースが少なかったからねえ。
ただ、昔の方が品質は良かったかもね。

webアプリのテストケース実行にSeleniumを使ってるんだが、漏れのない、かつコンパクトなテストケース集を書くコツが分からねえ。
なんかオススメの本とかないかね？

バグって便利な言葉だね。昔、客先のサーバー落ちた時に調べてたらマザーボードとケースの隙間にカニが入ってた。こいつのせいかどうかは不明だったけど、おお、まさしくバグ、と思った。でも虫じゃなくてカニ。

>>144
ユーザー要件と齟齬があるとどうなるの？

仕様書読むユーザーがいないのか…

>>210
ドキュメント関係なく仕様が固まらないのに作成するなんて異常なんだけど

>>176
テンプレートと文字盤と字消板が3種の神器だった。
今、テンプレートとか持っている人はいるのだろうか？

東証って文系脳だったのか

文系とか理系とか無意味な区分けするやつほど馬鹿だよな

> 「コーディングが終了した後はドキュメントは不要」と主張している

これ、引き継ぎ社員や取引先がことごとく逃亡するパターン

苦し紛れに全然違う所からデータ引っ張ってきたりしたらドキュメントがないと絶対分からない

おれ現役SEだけど信用できるドキュメントなんて存在しない
結局ソース追うんだから不要っちゃ不要

>>224
今のサーバーって処理能力超えただけで落ちるもんな。
カニが入っちゃダメだなｗ。

処理速度の低下を防ぐためとして進んでスパゲッティー化を実施する馬鹿メーカーも日本には普通にあるわけで、
メンテナンス性を犠牲にする態度も今の日本のソフトウェア産業の信頼感が著しく損なわれている要因の
一端なんだよね。

ドキュメントが無いと探し続けて、
ようやく見つけたら3年前で更新が止まってるドキュメントだった時の切ない気持ち

>>19
MSIME特有の誤変換してんな

>>1
>「コーディングが終了した後はドキュメントは不要」と主張している。
最初からドキュメント無いならわかるけど、あるんなら修正は必須だろ
しかも金融関係という一番お堅いシステムなのに

つうかみずほが勝って俺のみずほ株を上げてくれ

>>221
ともかくこの例えが正確であるとしたら、現場がタコかっただけだな。
それを「先輩達はそんな事してなかった！」とか言うから切ないが。

単純に、先輩達より技術力が低かったがそれを認めてないって言うのが病根。

ソースと仕様書の二重管理なんて工数の無駄
ソースは常に正解だが仕様書があってる保障はどこにもない
なくて困るのぶん投げた先の底辺だけだし

>>227
PAD用のテンプレート売店にあったな

頼むから営業は病院と金融の仕事取って来るのやめてくれ

でもドキュメンが無いと作られた背景が分からんからメンテナンスの時困るじゃん？

処理の重複コードが散見してるってことはよほど設計から適当だったんだな
共通化は鉄則だろ
これに失敗したら取り返せない

>>239
ソースが常に正しいって事もない。
クソ業者だとバイナリだけ入れ替えてソースはそのままとかｗ

先週末、goto文使った。

金融系大手現役だけど
基設がしっかりしていれば詳設は不要に思う。
業務ロジックをどう実現してるかよりも
業務ロジックの目的の方が大事だし。
単体も業務よりのテストケースを
重視したほうが、障害おこりにくい。
ブラボとかホワボ的ケースなんていらん。

業務ロジックが一般の開発より複雑だから
同一視して議論すると噛み合わないよ。

基本設計書というか機能設計書は居るだろ
ソースを焼き直しただけの詳細設計書は不要

>>247
偉い人にはそれがわからんのです。

詳細設計書なんて誰も読まないのにwww

株なんて博打で遊んでないでちゃんと働け

何十年前の考え方してんだろね東証のバカ共は
さすが応答速度が2桁違ってても何とも思わない無能だわ

>>247
その通り
それら全てを一緒くたにして不要の訳がないって言う奴とは会話にならない

バグも何も入力者が数を間違えただけの話だろ？
これってシステム側の責任なわけ？

>>252
入力確認を促さなかったシステムが悪い、ってことにされる

>コーディングが終了した後はドキュメントは不要

納品物に指定されていなくて
問題が発生して後から要求したから
こんな回答なんだろ。これは発注側が悪い。

不要なんじゃなくて破棄しないと
コンプライアンス違反。

>248
偉い人同士の争いには
目に見える形での物量が必要なのだよ

>>253
確か警告無視してやっただろ
それを取り消せなかったのはバグとか頭おかしい

>>244
別の意味でソースが正しくないってのもあるけどなｗ
（ビジネスルール的にまちがった動作・データ操作をしているのだが、
ユーザー含めて誰も気付かないまま何年も動いていたというｗ）

そもそも入力ミスしたのが悪い
個人ならそれで終わりだから
みずほ証券は甘え

>>166
もしかしてナイツも作った人？

「仕様です」

>>256

違う。
東証のシステムに取消機能があるんだがバグで動作しなかった。
取消コマンド入力以降に発生した損失だけ賠償請求してる。

アロヘになる前の東証システムはたしかに糞すぎた
あんなにしょっちゅうシステム障害を起こしたらなぁ

おまえらクズに騙され過ぎ

・正しい作り方
　・外部設計
・内部背系
　・機能設計
　・詳細設計
等を適切に作成しプログラミングを行う

これをベースに現実問題としてソース修正の度に詳細設計を
書き直したりするのはコストがかかりすぎるのではないかとか
そもそもこれらを同期させられないから無駄になるとか
ソースと同じ内容を書く必要があるのかとか
機能の割にテストが増えすぎるとか
そういうのを状況に合わせて議論の後工夫したり削ったりするのが正解

つづく

ところがそれを↓みたいな現実でよくあるクズ発想でやるので

・SIとかSEごっこの若い奴
　・僕プログラムやりたくないです、僕が考えたすごいソフトを
　　他の人が作って手柄は僕の物にするのが仕事です。
　・僕プログラムやりたくないです、プログラムの事で手間がかかっても
　　プログラムやらない僕は困らないので仕様書とかどうでもいいです
　・僕プログラムやりたくないです。プログラムは底辺の仕事って聞いているので
　　やった事ないけどきっと誰でもできる簡単なお仕事なのできっと仕様書とかいらないです

・プログラマ
　・僕プログラマなんで管理とか面倒です、仕様書なんてなくても
　　僕が書いたソースなので中見ればわかります。
　　人が変わって引継される側が困っても僕は困らないので知りません。

・役員とか役職
　・問題が発生しました。本当の原因とかはどうでもいいので
　　責任を取らせる相手をまず選んでそいつの担当部分が原因です。
　　嘘がばれるとまずいので実際にそうだという事にします。
　　実際の原因とずれててまた同じ問題が起きても
　　だれか他の奴のせいにすればいいので知りません。
　・問題が発生しました。原因はなんとなく嫌いなあいつの担当部分に違いありません

・その他全般
　・他の人が困ってもどうでもいいので、俺が困らない分には知らんがな

つづく

東証アホ過ぎワロタw

結果として
・外部設計書は不要
　※馬鹿が書いたそんな近未来のすごいUIは現実では不可能なので
・機能設計書は不要
　※馬鹿が書いても無駄なので
・内部設計書は不要
　※馬鹿が書いても無駄なので
　※偉い人には役に立たないので
・詳細設計書は不要
　※馬鹿の仕様検討不足で度重なる変更が入って内容を合わせるのが無理なので
・テストは不要
　※めんどくさいのでやりたくないので
・原因調査は不要
　※どうせ嘘しか書かないので

みたいになってたまりにたまったクソの山があふれて手が付けられなくなったのを
さぼったり責任逃れがしたいので

「現代のソフトウェア開発の現場（※馬鹿以外は逃げた現場）では
　技術革新の波に合わせて臨機応変な対応（※さっき雑誌に○○が新しいって載ってた）を取るべく
　従来までのような仕様書（※無いので）を用いた
　ウォーターフォール的な開発手法（※計画的って事なので馬鹿には無理なので）から改め、
　先進的な手法（※だと都合がいい）であるアジャイル開発のスタイル（仕様書が無いので）
　を取ることにより、実際の状況に合わせた流動的（※無計画なので無能が仕様変更を乱発するから）な対応を行い、
　実際のプログラムやソフトウェアをベース（仕様書は無いしくプログラマが逃げたので）にした手法が適切である。」

とか言ってるだけ

結局のところ、発注者側が何をどうしたいってのを
開発者側にちゃんと正しく伝える方法が確立されていないのが
最大のネックなんだよな
ぶったけ、発注者側がやって欲しい事が正しく伝わってさえいれば
開発自体は実現方法も含めてどうでもいい、あとは納品物が
やって欲しいと伝えた物どおりか正しく評価できるかだけど

システムなんてたたけばいくらでもほこりが出る
結局トラブルがおきないことを祈るしかない

>>267
発注側も受注側もやりたいこと理解してないとか最悪だよなｗ
だからこそ双方の意識を合わせるために絵を描いたり表にしたりするのに、
その作業の方が楽だしかっこよく見えるし評価もされやすいから、そこだけやりたがる奴が出てくる。
そういう奴は発注側も受注側もどうでもいいからとにかく「それっぽい」けど使えない資料を作る。
ああ、うちの女SEだよ。

ドキュメント用意できる時間も資金出してないカスが
偉そうに要求してくるなっつーの。

＞分かってねーな。ソースが仕様書なんだよ。
＞まったく現場が分かってない
馬鹿だな。バイナリがあればソースなんていらねえ

うちの会社ではドキュメントを図書という

>>261
なら問題ないよね
ん？ということは、このスレの人達は何を騒いでるのか

ソースが仕様書とするならば
バグなんて概念あり得ないと思うよ

>>4
昔アルゴリズムの神様みたいな人の本にも書いてあったな

>>226
異常なんだけど、納期が延びないのに仕様が変わることがままある

>>224
カニはダメだろ、カニは

通信チップとかUSBがカニなだけでクズマザーだよ。

>>277
バカだなー
なにが元ネタかも知らずに言ってんだろうなあ

そもそも、「できない」と「やらない」を混同している仕様が多すぎて困る
ドキュメント書いてる時点で気付けよ、と

前の会社でソースが無くて実行形式だけで動いていたプログラムがあったな

バカッターとかで
「作るという事は人に使われる立場になるという事を自覚しなければならない」
とかドヤ顔で「おれにとってちょうつごうのいいはなし」をしてるペテン師とかに洗脳されてる馬鹿とか多いからな

反論としては
・人を使うって事はお金を払わなければならない事を自覚しなければならないという事でとりあえず金払えカスが
・作る人たちで考えてそのまま作ればいいんじゃないの？（ちなみに実際に考えようとするとわざわざ止めたり邪魔したりするｗ）
・そもそも世の中の99%は人に使われているのでは(社長クラスも顧客や取引先や資本家に使われている)
・システム視点では一般ニーズにあった物は難しいなら営業部とシステム部があればよくってお前はいらないんじゃ
とかその他色々あるけど

この手の洗脳で「うわーすごーい人を使える偉い人なんだ作る人は馬鹿なんだ」
って騙される馬鹿（選挙で言うところの票田ｗ）が増えると,
票田の力で実際に投入される資金が本来

「ペテン師1 企画3 設計3 作る人3 運用3」
のはずが
「ペテン師7 企画1 設計1 作る人1 運用1 」
とかになって
ペテンが7の資金と1の資金で働く奴隷を「本当に」ゲットすることになって
実際にペテン師が裕福＆人を使う立場になるってのがペテン師の筋書だからな。

当然1の資金で働く方がおかしいのでどんどん質が低下して行くんだけど、
ペテン師はその頃には会社辞めてもマンション買ったかららいいや位の資金を手に入れて左うちわですわｗ
（だってペテン師なので自分だけ儲かれば他が死んでもどうでもいいというかむしろ死んだ方がコキ使えるｗ）

という事で内部の仕様書とか頑張る暇があるなら、ホラついた方が得って事が広まって来てしまって
巷の本とかでも「あたまがちょういいひとのやりかた」とかでそういうペテンが載っているものが増えてきて
それを猿マネする奴が増えてきて、仕様とかそもそも無駄（ペテンにとって都合が悪いので）とかなって
クソの山になってるのが今の現状というか実は現行の老人のペテンでもあったりするｗ

>>281
そのおかげで日本のIT産業は韓国、中国、インドに潰されかけてるのにな。
単価安いから流れてんじゃねぇよ。日本にそんだけの物作る技術者がいないから流れてんだ。

しかも日本企業がオフショア出そうとするとウンコみたいな人材しか集まらない。
理由は簡単。
現地飛んだブリッジが頭パーだから足元見られてるだけ。
てかブリッジなんて分野も日本くらいしかいないしな。

SIもユーザ企業も「いかに技術者を使い倒すか」ってことしか頭にないから肝心の技術がすっからかん。

>>282
ああ、それブリッジの使い方が逆。
向こうの人間のうち、日本在留経験長い奴にこっち来させて逐一スカイプとかで指示させなきゃダメだ

個人的には処理の目的と概要、前提条件
インタフェース設計、編集条件、CRUD、計算式があれば十分だと思う

あとはせいぜい大項目レベルの簡易フローかシーケンス図くらいか。必須とは言わんが。

詳細な文章やプログラムレベルのフローは時間の無駄だな

極端な話、処理の目的と扱うデータの説明さえあればなんとかなる

逆に言うと、その目的やデータの流れが全く見えず
たらたらとコードを日本語に訳しただけの設計書ならいらない

けど量的にはこの手のドキュメントのほうがボリュームあるんで
なぜかお偉いさんにウケるという不思議な現象がある

無限空売りできるようなシステム使ってたみずほが糞
マジでメシウマだったわｗｗｗｗｗｗ

ソースコードがドキュメントだ！！！(・｀ω・´)

ソースに「おかしいけど、直すと動かなくなるから、このままにしておいて」と書かれてる。
そういうのって神のいたずらとしか思えん。

>>286
末端の営業が使うので空売りに残チェック入れてないようなシステムはさすがにない
今回のは上場初日だし、取引所に直接つながってる端末だろうな
その場合は基本的に残チェックは入れてない
つか、あえて入れない
自社システムが対応してない特殊な注文捌いたりシステム障害の時にリカバるためのものだからな

>>288
おまじないを量産する奴が炎上プロジェクトに大量投入されるのは確かに神のいたずらだな

あれ無限空売りのできる証券会社のズルだっていうバカが大量に発生したけど考える力がないのかね？
預かり等の裏付けがなくても「発注できる」っていうだけで「空売り」を無限にできるわけじゃないから