みずほのプログラムを組んだSEの責任は？

質問

システム障害を起こしたみずほグループですが、知り合いの元SEによれば、「ああいうシステムは数社合同のプロジェクトで作らてるし、関わったSEも100人じゃきかないだろうから、プログラマの責任は誰も問えないんじゃないか？」と言ってますが・・・
プログラムにミスがあったからああなったわけで、プログラムのその部分を組んだ（書いた）個人は何らかの責任を取らされてるハズだと想像してますが、具体的にはどう責められるのでしょうか？
他人事ながらかわいそうな気がします。

回答No.3

madman · ベストアンサー

基本的にプログラマに責任はありません。
システム全体で考えた場合、まず、要求を出した人がいます。（要求仕様）
要求仕様は顧客が作成します。
その要求を元に、どのようなシステムを作成するかの仕様書を作成します。
（上級ＳＥ及び顧客の担当者）
当然これらは、元の要求を出した方々に説明し、承認をもらいます。
次に、担当ＳＥが各プロセス単位でプログラム設計書に落としていきます。
（上級ＳＥ及びＳＥ）
プログラム設計書から、プログラム単位にプログラム設計書を作成します。
（ＳＥ）
プログラム設計を元に、プログラムの作成及び単体テストの実施。（ＰＧ）
プログラム設計書をベースに結合テスト絵を実施。
その後、システム仕様書を元にシステムテストを実施します。
これらテストは、テストする手法、実施手順などを詳細に記載した、テスト仕様書を作成し、承認を得ます。
プログラムにミスがある場合は、プログラマのミスは、テストでつぶれます。元々の設計書のミスがあった場合は、プログラマはミスと気付かずにプログラムを作成し、テストも間違ったまま実施されます。こうなった場合、プログラマ個人の問題にはなりえません。ほとんどの場合、個人ではなく受注した会社が責任を負います。

また、その設計書が仕様書に基づいて作られているため、仕様書にミスがあればシステム全体が正しく動作しません。この場合顧客にも承認を得ているので、顧客にも責任が発生します。

良くあるのが、要求仕様が二転三転したり、顧客の都合でスケジュールがずれたり、元々極端に短いスケジュールが組まれていたりで、テストが十分に行えないことがあります。そのような場合、顧客に承認を得てテストを端折ったり、項目を減らしたりしてテストを実施します。
そのような場合は、品質が著しく低下することがあります。

これら上記の内容をひっくるめてプログラムのバグと呼ばれたりします。
実際には設計書どおり、要求どおりのプログラムであったとしても...

まあ、設計手法については数々ありますので、全ての場合がこの手法に基づいているわけではありませんし、最終的にＧＯを出すのは顧客です。

明らかに、要求仕様に対して、設計が誤っていた。障害がわかっているのに黙っていたなどの場合は、開発受注側にも大きく責任を問われることがあります。

お礼

微に入り細を穿つ回答、ありがとうございます。
バグ発生個所がわかったとしても、少なくともそのプログラミングを担当した個人だけの責任にはならないんですね。
すると今回の場合、システムテストが不十分だったのでしょうか？ユーザー部門不在でテスト仕様書を作ったり、テストデータ作成からテストの評価までを開発部門だけでやってしまったとか。
なんにしても、責任の押し付け合いってな方向に話が進まないようにしてほしいもんです。

回答No.6

ranx

私も個々のプログラマの責任は問えないと思います。
プログラムのバグであったとしても責任が問えるかとなると微妙ですし、
今回の件、どう見ても単純なバグとは思えませんからね。
では、誰の責任かということになりますが、第一義的には、プロジェクト
マネージャの責任になると思います。プロジェクトマネージャは、ＳＥ
かもしれませんし、そうではないかもしれません。経営者かもしれないし、
そうではないかもしれません。このプロジェクト管理専任でやっていた
かもしれないし、他の仕事とかけもちでやっていたかもしれません。
いずれにしても、プロジェクトのスケジュールを決め、人やお金の配分を
決め、進捗状況を見ながら、予定を変更する必要があるかどうかを判断
していた人が居たはずです。経営者であればもちろんですが、そうでは
なかったとしても、責任を問われるのは避けられないと思います。

お礼

回答ありがとうございます。
>予定を変更する必要があるかどうかを判断していた人が居たはずです。
さて、それがたった一人かどうかでコトに大きな差が生じますよね？一個人が負えるような責任ではないはずですので、そんな不幸には見舞われたくないですよね。

回答No.5

noname#21649

商取引の原則を思い出してください。
発注して．購入した（プログラムの問題は指摘されていたが開店した）わけですから．この時点で．仕様書（注文書）に応じた製品は送られていたはずです。
ぷろぐらまーの責任というよりも発注者の仕様の方に問題があったのではありませんか。

ニュース報道では伝票上での間違いにソフトが対応できなかったためとしているので。
一般に．A５紙1枚あたり2-3個所の間違いがあるのが普通です（誰かのプログラミングの本に書いてあった内容）。したがって手入力伝票100枚に1枚ぐらいは間違いがあるのが普通です。
送金取り扱いは元々知っていたはずですから．このくらいの間違いに対応できる仕様書を指示しなかった経営側の問題でしょう。

あと．１つの処理で2割処理時間が増えると遅延時間は全体で2-5倍に増えます。多分．導入した信号ぷん敗コンヒューターの処理能力が極端に遅いのでありませんか．昔のコンヒューターでは1割処理時間を遅くすると倍ぐらい価格が安くなりますから。機種選定に問題があったとすると．機種選定をした経営者の責任になります。

お礼

朝早くにありがとうございます。
>プログラマーの責任というよりも発注者の仕様の方に問題があったのではありませんか。
そうですね。機種選定を含めて、最終的には経営サイドの責任だってのが最も正しいような気がします。

回答No.4

ARC

今回の場合は、時間不足によるテスト不十分が原因かと思いますけどねぇ。
実際のデータを使ったテストを何度も何度も真剣に繰り返していれば、今回のような事態は防げたんじゃないかと思います。

「思いつく限りのパターンのデータを用意した」だけでは、絶対に漏れがでてきますからね。
自分もプログラマですが、細心の注意を払って作成し、慎重に慎重を重ねてテストしたにも関わらず、テストチームからバグ票と共に突き返されてきた経験が何度もありますよ。
「コレなら絶対に大丈夫や。」って思って作った部分が、凄く特殊なデータが通ったときに破綻してしまったりとか…

↑のような話の後では言い訳じみて聞こえますが(汗)、大規模なシステムの場合は、個人のミスによる障害を極力防ぐ為、仕様担当、開発担当、テスト担当、などの複数のチームの協力体制によって品質管理が行われています。
誰だってミスはするわけですから、一人がミスを、チームがカバーするような体制をあらかじめ作っておくわけです。
ということですので、#3,madmanさんが仰ったように、一人のＰＧに「直接」裁定が下されることはありません。

…とはいえ、今回のような重大なミスを犯してしまった場合、どの部分にミスがあったのかが詳しく特定され、その部分に携わった人間には「何らかの」措置がなされるんじゃないかなぁ。

お礼

回答ありがとうございます。
「何らかの」が気にかかるところです。プログラミングにミスがあったとしても、テストが不十分ならミスも表面化しないわけでしょうし、かといってテスト部門がすべて悪いとは言えないでしょうし・・・
で、結局責任のなすりあいになるような気がして、プログラマには気の毒でなりません。

回答No.2

imogasi

プログラムその他の不適当でシステムが止まったり、結果が間違ったケースについて、思いつくままにあげてみると、
　　（１）結果が間違っている。（例金額１０００円が１００００円と印字。）
　　　　ディスクに書いた結果が誤っていて、後処理で使って誤った
　　　　。一番単純なケース。
　　（２）前のプロセスでの処理（サインやコードの）が間違っていた
　　　　ので、結果として私のプログラムのところで間違った。
　　　　仕様書には書いてない。
　　（３）稀なある組み合わせ（同時的な時と前後的な時あり）で間違　　　　いになる。そんなデータはくるとはありえないはずとかこの組み　　　ありえるがその組み合わせのテストデータは作れなかった。
　　　テスト部門の責任は。
　　（４）量的にそんな大量にデータが来るとは予想しなかった。
　　　　それであるアルゴリズムで組んだルーチンが処理時間がかか　　　　って全体として停止状態的になった。量的なことはプログラマ　　　　ーの知ったことではない。
　　（５）量的にそんな大量にデータが来るとは予想しなかった。
　　　　ディスクのエクステントの割り当てがオーバーフローし
　　　　第２、第３のオーバーフローエリアに繋ぐために時間が
　　　　かかって全体として停止状態的になった。またはシステム
　　　　が停止した。
　　（６）データが入っているディスクのファイル指定や磁気テープ
　　　　のＶＯＬＳＥＲ番号を指定し誤った。金をかければ、また都銀
　　　　では自動化が進んでいると思うが、口座振替のように、外部か　　　　ら入る（を集めた）データを考えると、ありえなくはない。
　　（７）マシン（メインフレームだけでなく通信制御装置、記憶装置
　　　　などもふくめ）の不調。
　　（８）プリンターバッファーなどのバッファーエリアやエラー分を
　　　　書き出すエリアの見積り不足。そんなにエラーデータがあると　　　　は。
　　新聞では（６）や（８）らしきものが報道されています。上記の単純
　　な例から想像しても、誰の責任かは簡単には断定できません。
　　個人的意見として、今回の件は、不幸な例ですが、２度と起こせ　　ない（見られない）大規模システムに関する国民的財産（経験）だ　　と思います。米国の軍事専門家までも注目しているのではないで　　しょうか（サリン事件が米国で注目されたように）。多分不可能でし　　ょうが、今後原因が責任論とは別見地から究明され、オープンに　　され、今後の、金融機関をはじめあらゆるシステム関係者の、他　　山の石になるべきではないでしょうか。

お礼

詳しい回答ありがとうございます。
辞書を引きながら読ませていただきました。
簡単に断定できないだけに、最終的に責任の所在もうやむやになって、誰かが辞職することで終わりにされてしまいそうな気もします。
おそらく徹夜続きで頑張ったプログラマはやりきれない気持なんでしょうね。

回答No.1

noname#8250

プログラマの責任とは断言できないのでは？聞くところによると合併前のそれぞれの会社でシステムが違い、そのシステムをそれぞれ使いたいと主張したそうです。
そのため実際のプログラミングが遅れてしまったのでしょう。
合併の期日は決まっているのにプログラミング、バグ取りやテストがほとんどできていなかったそうです。プログラムは作ってしまえばすぐに運用できるというものではないそうです。テスト、バグ取りを繰り返してはじめて使えるものになるんです。

そのテストをしない、またはできないようなスケジュールで運営できると判断した経営者やその周りの人間の方に大きな責任があるのではと思います。
プログラマはきっとこの状況を苦々しく思っていると思います、「テストもしないでうまくいくはずがない」って。
実際に見切りをつけ、辞めてしまったプログラマさんもいるそうですよ。

ご質問の答えにはならないと思いますがプログラムを完全なものにできないようにさせた者が本当に責めを受けるべき人だと思います。

お礼

早速の回答ありがとうございます。
>完全なものにできないようにさせたヤツ
そうですね。っていうかそうあるべきだとワタシも思います。
しかしまた新たな疑問が・・・今回の場合、その個人は特定できるものでしょうか？「経営者」は「俺プログラマぢゃないもん、わかるわけないぢゃん」と開き直られる気がしますし、そのすぐ下の役職者も同じように責任を下に押し付け、最後にプロジェクトチームの最高顧問あたりに責任を押し付けて・・・いや、でも責任の取りようがないだろうし、最後はどうなるんでしょう？