低品質のソフトウェアが世界を動かしている 95
中長期的な費用対効果の問題 部門より
eggy 曰く、
Atlantic の記事によれば、サプライチェーンや金融システム、生産ラインを支えているソフトウェアの多くはクオリティーが低いとのこと。こうしたソフトェアはストレステストが充分に行われないまま使用されているため、不具合が起きたときに企業が大きな損失を被る可能性を孕んでいると指摘している。ミッションクリティカルなソフトウェアのなかでも特にクリティカルなのが金融システムのソフトウェアであるが、つい先週、ナイト・キャピタルがニューヨーク証券取引所で、自動取引システム障害による 4 億 4 千万ドルの損失を負うこととなった事件 (/.J 記事) も記憶に新しいだろう (The Atlantic の記事、本家 /. 記事より) 。
ソフトウェアが誤作動を起こす可能性は無限に存在しており、不可能ではないにしても、起こりえるプログラムの誤作動をすべて予測するというのは非常に難しい。また、そのシステムで制御することのできない他のプログラムが絡んでくると更に困難を極める。こうした問題を解決するには、なによりも優秀でやる気のある開発者が必要であり、現場の開発者同士が互いの作業状況を頻繁に確認し合い、率直に意見を出し合える雰囲気が必要であるとしている。また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを優先させた方がいい、と理解できているマネジメントが必要であるとのこと。
プログラムの不具合はそう頻繁に起きることではないが、一旦起きてしまうと企業は非常に壊滅的な損失を被ることになるため、膨大な費用がかかったとしてもストレステストを行う必要がある。だが、こうしたリスクへの意識が低く、テクノロジーについて何一つ分かっていない金融機関は、短期的な視点で目先の利益を優先してしまい、ソフトウェアの品質に対する投資を怠ってしまうとのこと。
なに言ってんの (スコア:3)
それも含めて仕様なんだよ
って言う人みたことあるな。
でも、そのときは確かに向こうの要求通りの内容での障害だったので間違ってはいなかったんだが・・・
# 質の高いものを完成させるには、それなりの技術や経験そして期間が必要
# 自分ところはプロジェクトに応じて変化はするけど往々にして期間が足りないことが多いかな
費用対効果 (スコア:2)
金を湯水のごとくつぎ込んで、
複数の調査会社入れてコードやシステムをレビューしたり、
別の担当者による複数のアルゴリズムで多数決したり、
複数のデータセンターに冗長化された構成にしたり、
することはできると思うけど、
それにかかるコストと、まぁそこそこ動く安いヤツでの費用対効果でしょう。
それでも心配というなら、保険でも作ればいいと思う。
保険会社がコードやシステム、体制の調査して金額弾きだすんだろうけど。
その保険に入るかどうかも、費用対効果だろうけどね。
クソなものと良い物のどっちがいい？っていけば誰だって良い物が欲しいはずで、あとはコスト比較だと思うしね。
あとはそのクソがどこまで容認できるかってのを決めるだけだろう。
んで、そのどこに落とし所を持っていくのかをずばって決めるのが経営の仕事だと思うわー
by rti.
Re:費用対効果 (スコア:5, 興味深い)
リンクされてるThe Atlanticの記事ではアルゴリズム取引なんかを例に出して
プログラムエラーが途方も無い損失を引き起こしうるが、決定権を握っている人たち（男性ホルモンで
行動してるトレーダーとか）はコストを重視しがちでリスクを過小評価しているというようなことを
書いてるみたいです。つまり、
>そのどこに落とし所を持っていくのか
が上手くいかない構造がヤバいよね、みたいな話ですな。
リスクを過小評価するってのは人間の性みたいなものじゃないかとも思いますけど。
仮にエラーが起きる確率が10年に1度程度で、いくらかの損失が出るくらいなら、品質が悪くてもほうっておけ
みたいな判断になるでしょうけど、10年に1度の確率で数億ドル、取引が複雑になるにしがって損失が増えると
すると数百億ドル数千億ドルとふくれあがっていけばエラー一発で破綻という可能性も出てくるので、そうした
リスクが正しく評価できてないというのはたしかに恐ろしいかもしれません。
Re:費用対効果 (スコア:2)
投資銀行なんかは、プリンシパル＝エージェント問題が典型的に出るところ
（品質の低いプログラムでバグが出て会社が潰れても、最悪首になるだけ、
もしも品質を犠牲にした開発ですごい利益が出たらボーナスたっぷり）
なので、リスクの過小評価の一員になっているかもしれませんね。
Re: (スコア:0)
つまり、みずほは正しい
Re: (スコア:0)
費用対効果ならまだ理解できるけど
コストバカ高いのに低品質な物があるからこそ問題だと思うけどな。
安くて低品質、高くて高品質、なら費用対効果のバランスって言えるけど
高くて低品質なら何の意味もない。
大体有名所の仕事はそういうものだけど。
なにせ有名所といっても直接してるわけじゃなく、自分達は高額で請け負って下請けにその半額とかで回すだけのことだし。
その下請けが更に下請けに出して～～、で結局入札額の1/10みたいな開発費で底辺の所が行うだけのこと。
あれ、じゃあやっぱり費用対効果はあってるのかｗ 最終的な一番最後の下請けの開発費でいえばｗ
つまり中間マージンなくせば全て解決。
流通でもなんでもそうだしな。
Re:費用対効果 (スコア:1)
孫請けなどの多重下請けが問題かなー？
それであれば、多重下請けなんてしていないで直接仕事を取りに行けばいいんじゃないの？
それができない理由が多重下請である理由だと思うわー。
そして、そこに価値があると思っているから、金額があがるんじゃないの？
by rti.
高品質なシステムは観測できない (スコア:2)
問題を起こすシステムは起こした問題によって観測できるが、
問題を起こさないシステムは観測できない（観測しづらい）という事ではなかろうか。
#存在自体がホラー
低レベルのマネージメントが世界を動かしている (スコア:2)
つまりこういうこと？
開発に十分な開発期間や検証環境を与えず、運用で稼動系統を分けるなどのリスク分散を行わない。
こういった局地的かつ近視眼的なマネージメント層によって世界が動かされている。
人の特性を忘れて、速さと数字だけでマネージメントしちゃあかんよ。
業界の構造 (スコア:1, 興味深い)
他の国は知らないけど日本の場合は業界の構造がソフトウェアの低品質をもたらしているのでは。たとえば東証の新システムもあちこちが入札したけど、出来レースのように富士通が勝った。こういう「権威ある」システムを受注するところは技術力で選ばれるのではなく最初から決まっているのではないか。他にも日立とかNTTデータなんかも特定のお得意様から仕事を貰える構造。
Re: (スコア:0)
特許庁みたいに、ちゃんと入札して選んだつもりが、作り始める前にギブアップ、ということもあるけどね。
実績がある、というのも技術力のうちかと。
Re: (スコア:0)
・「出来レースのように」「最初から決まっているのではないか」と考える（想像する）根拠
・お得意様から仕事がもらえる構造がソフトウェアの低品質をもたらしていると考える根拠
この二つが要るな。
例として挙がっている東証の新システムは確かに少し前に障害を出した [nikkeibp.co.jp]のは例の一つとして提示できるかな。でもこの例は運用に問題があった [nikkeibp.co.jp]のも影響拡大の原因のようなので、これが「お得意様から仕事がもらえる構造」が原因なのかと考えるべきかどうか。
Re: (スコア:0)
最初から決まっている根拠が外部に漏れたら随意契約って叩かれるでしょ。表向きは公正な競争にしておかないと。
お得意様から仕事がもらえる構造がソフトウェアの低品質をもたらしているのは、うちは某財閥系の孫会社だけど何となくわかる気がする。社員は最低限の基準さえ満たしていればどうせ上から仕事が降ってくるからって理由で無気力な人が多いよ。品質のいいソフトウェアを作ろうって気概がない。別に頑張らなくても仕事が保証されたらそうなるのは自然じゃないかな。
関連リンクに多量にありますが (スコア:1)
日本だとやっぱりみずほですかねぇ・・・
なんであんな納期でできると思ったんだろう・・・？
要求品質の違い (スコア:1)
日本のシステムは過剰品質だと言われますが実際的な感覚としてどうなのか、気になっています。
最近「ガラパゴス」と揶揄されるように、日本はデザインや少し前に流行ったUX、とにかくユーザに近いところを軽視しがちであることは経験的に認識しています。一方で、この記事にあるような、ミッションクリティカルシステムの欠陥数が世界標準と比して多いのか、少ないのか。
5年ぐらい前、当時、仕事で出張することが多かったのですが、ドイツの国際空港（どこだったか忘れました）の掲示板にWindowsのシステムエラー画面が延々表示されて困ったことが印象に残っています。同じ時期、国内線も月に数回使っていましたが、掲示板にシステムエラーが表示されたことはありませんでした。
ドイツと言えば、日本が色々なことをお手本としてきた国。その国の空港でWindowsのシステムエラーがふつーに表示されている。単に運が悪かったのか、要求される品質がそもそも違うのか。空港の掲示板がミッションクリティカルとは言えませんが、色々考えさせられました。
品質って何？ (スコア:1)
この場合の「品質」って何を指してるんだろう？
そもそも、不具合って何？
議事録の内容すら「前任者の言う事なんか知りません」と突っぱねる人知ってますけど、そういう人にかかると、仕様通りに作っても、バグが無くても、不具合があると言う事になるんですが？
言うは易く行なうは難し (スコア:0)
＞また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを
＞優先させた方がいい、と理解できているマネジメントが必要であるとのこと。
理解出来ても実行出来るとは限らん、というかムリだorz
Re:言うは易く行なうは難し (スコア:1)
偉い人たち（中間管理職ではなく、トップマネジメントの次の連中）は目の前のキャッシュフローしか興味ないですからね。
ウチの場合、ロジックやエラー処理は一切抜きのデモUIのみの営業プレゼン用ソフトウェアを見て、
「なんでこれが売れないんだ！このまま売れ！」とか怒り出す人たちですから理解なんて無理なんですよ。
（指示する際も「とにかく顧客デモをやれ、その部分だけ作れ」という指示だったのだが、本人が忘れてる。）
理解している上級マネジメント職も火の粉が降り掛かるのを嫌がって「お前ら、上からそのまま売れって
言われてるんだから、言う通りにすればいいんだよ」って言い出す始末ですしね。
Re: (スコア:0)
納期破る判断って、マネジメントがそれを下すのはほんと難しいよね。
一度認めると、下々がキツい時すぐそれを求めるようになるだろうし。
一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。
それだとなんだか別の問題も起きそうですし。
もともとの納期だって、それほど確かな下地に基づいて切ってる訳でもないでしょうから。
優等生理論でいくと、最初にマネジメントが下した「リソースの見極め＋納期の切り」に失敗の原因がありましたごめんなさい、っていう反省文とセットで初めて成立しそう。→納期延長
Re:言うは易く行なうは難し (スコア:5, すばらしい洞察)
スーパープログラマは平凡なプログラマの10倍、100倍の能力があるとか、良く聞くし、実際にそうだとも思うけど、一定以上の規模の仕事の場合、彼/彼女ひとりに依存してしまうと、トラブルが発生したときに対応不能だよね。つまり、納期は彼の能力と気分次第ということになる。
それよりは普通の能力の人を多く使った方が計画的に仕事が進むし、多人数の方が途中経過を正確に把握しやすい。特定の部分や特定の人の仕事が遅れていれば、それを強化することも容易。
Re:言うは易く行なうは難し (スコア:1)
スーパープログラマかどうかは知らんけど、一人のプログラマに過剰に負荷がかかった結果、ダウンしてしまって、品質維持どころじゃなくなった例も知っているし、一方でプログラマ増やしすぎて、どいつもこいつもバラバラな実装やらかした結果、品質維持が出来なくなった例も知っていますんで、単純に多く使えば良いとも言い切れないなぁ。
多くの場合、プログラマよりも、旗振り役の方に高いスキルの人員が居ないと、プロジェクトはコケやすい気がする。
Re: (スコア:0)
>計画的に仕事が進むし、多人数の方が途中経
>過を正確に把握しやすい。
上が「普通の能力」を持ってないと、いずれにしてもダメダメ。
無計画に多人数にして、却って全体を制御できなくなる。
ああ、さっさと抜けたい。
Re:言うは易く行なうは難し (スコア:4, 参考になる)
一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。
それだとなんだか別の問題も起きそうですし。
ファーストサーバ…
Re:言うは易く行なうは難し (スコア:1)
最近の会議では「ファーストサーバ」という単語が万能でありがたいわ。
「オペレーションマニュアルの必要性を説くとき」
「リカバリマニュアルの必要性を説くとき」
「バックアップの有用性を説くとき」
今のところ、これらのケースでは「ファーストサーバ」と呟くだけで事足りた。あの事件は風化しないで頂きたい。
Re: (スコア:0)
>下々がキツい時すぐそれを求めるようになるだろうし。
なーに、キツくならないよう、最初から十分な余裕を持った納期を設定しておけば良いだけのことですよ。
#やれるんならやっている！
Re:言うは易く行なうは難し (スコア:2, 参考になる)
ソフトウェアではないですが、設計レビューを十分やるために社内委託作業（社内の
CAD設計担当部門への設計委託）で通常より５割長い納期（と費用）を設定した
ことがあります。（担当部門要求４週間に対して６週間）
結果、どうなったかというと、その分以上に前半でサボられて余計品質が悪くなりました。
いつまでたっても初版のレビュー用データが出てこない。
問い詰めると、こっちから金をとっておきながら、他の部門からも金を取って、違うことを
していたらしい。結果、数百万の金を取られて、さらに外部での再設計と納期遅延で
億に近い損失がでました。
社外なら訴訟ものですが、社内だからどうにもならん。
Re:言うは易く行なうは難し (スコア:2)
社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
どちらかというと、「設計・レビューが～が理由でできない」というクレームが上がってきたときの対応のほうが重要なはず（それで遅れても許容する余裕もね）
＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
Re:言うは易く行なうは難し (スコア:1)
> 社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
ダメダメだからレビューをしっかりやるスケジュールを立てたら余計にダメダメだった、ってことです。
> ＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
モノ作りだと試作ラインの確保もしなきゃいけないですし。
Re:言うは易く行なうは難し (スコア:2)
＞うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
他の部署にも影響してそうだから上にあげるべきですね。
＃社内にやらせるくらいなら、社外に出したほうが安くて早い！（とかｗ
＞社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
何言ってるんですか、隠せれないなら脳内予定を作っておけばいいんですよ（苦笑）
試作ラインの確保は・・・どうしようもないですね。自分の予定に別の予定を1週間程無理やり突っ込んでずらすとかくらいしか思いつきません＞＜
Re: (スコア:0)
禿同！
こんなあたりまえのことが通じないのが現実。
始まる前からまともなら納期遅れになるのはわかっている。
それを期日にまにあわせるには真っ当な方法ではむりなのはあたりまえ。
水の多いコンクリートなら工期の短縮はできるようなもの。
耐久性を問われても困ります。
#納期が過ぎてから気合が入ります
Re:言うは易く行なうは難し (スコア:2)
>#納期が過ぎてから気合が入ります
納期を細かく設定してずーっと気合を入れさせる手法をアジャイルとか呼ぶらしいな。
無理無理 (スコア:0)
そんな得にならない事を経営者がやらせるわけがない
トラブルが起きたら補修費用が稼げるとか抜かす馬鹿さえいる
※責任問題や訴訟等は全然頭に無いらしい
金融機関やストレステストに限った話じゃないでしょう。 (スコア:0)
根本的にはコストとの兼ね合いであって、社会全体に「俺はリスクを負いたくない(≒コストも負いたくない)」という風潮が蔓延している限り、状況は改善しにくいんじゃないですかね。
Re:金融機関やストレステストに限った話じゃないでしょう。 (スコア:1)
むしろ、それほど重大なシステムですら十分にテストしてないのに、
それ以外のシステムって・・・って話かと。
Re:金融機関やストレステストに限った話じゃないでしょう。 (スコア:2)
金融は原子力なんでしたっけ（笑）
Re:金融機関やストレステストに限った話じゃないでしょう。 (スコア:2)
いえいえ、もしかすると該当のEULAは金融はミッションクリティカルではないと想定している可能性はありますよ。
＃使用者がミッションクリティカルだと判断したら使えないんでしたっけ？
Re:金融機関やストレステストに限った話じゃないでしょう。 (スコア:1)
ライセンス元がミッションクリティカルではないと想定していたとしたら、それが一体なんだっていうの?
金融分野で使ってトラブルが起こったとき、ライセンス元が「金融はミッションクリティカルだと想定していなかった。これは我々の責任だ」と言うとでも?
1を聞いて0を知れ!
Re:金融機関やストレステストに限った話じゃないでしょう。 (スコア:2)
それ以外にどうしろと？
＃そういう場合は大抵訴訟沙汰になって、責任範囲がどうのとかで争うことになりそうですが
Re:金融機関やストレステストに限った話じゃないでしょう。 (スコア:1)
それってどれ？
1を聞いて0を知れ!
費用対効果 (スコア:0)
だって、コストカットの産物だし
納期を過ぎてでも質の高い・・なんてのはただの妄言
Re:費用対効果 (スコア:2)
もしトラブルが起こったらどれくらい被害が出るか、それを避けるためにいくらまで資金を出せるかを真面目に考えた結果、トラブルが起こりにくいけど高いソフトより、トラブルが起こる可能性高いけど安いソフトの方がいいと判断したんだったら、費用対効果の高いものを選んだってことになるけど。
何も考えずに安いのを選ぶのは、費用対効果考えてることにならないよね。
1を聞いて0を知れ!
Re:費用対効果 (スコア:1)
ソフトは人が作る
人にかけるカネなんぞない
そういうことでしょ。特に日本企業はその典型では。
Re: (スコア:0)
そもそも、コストカットできなければIT化する意味がない。
（まったくないわけではないが、IT化する動機の主要な一部分が失われる）
Re: (スコア:0)
全体的なものを見越してコストカットするのに
ITの部分で障害が出かねないぐらいのコストでやらなければならない時点で
そんなものをIT化する必要性はない
Re: (スコア:0)
そんなもんですよ。企業インハウスアプリなんて、昔も今も作り捨て。
昔はVBやExcelマクロ、Notesアプリ、今だとPHPやAdobeAIRなんかで書くのかな。
大都市にはそういう仕事をこなす個人営業の「街のVB屋さん」がいて、大田区の中小工場がごとく簡単な仕事を任せてました。
そういえば、かつてEUC(エンドユーザコンピューティング)なんて言葉が流行りましたよねぇ。
Re: (スコア:0)
中小企業の自前のアプリの場合、使う側も限界をわきまえているんじゃないでしょうか、
あるソフトが、突然動かなくなっても、当然仕事の効率は落ちるものの、企業の存続に関わる
大事にはならないような気がします。
ある意味、ソフトとの適切な距離の取り方かとも思います。
Re:費用対効果 (スコア:1)
>中小企業の自前のアプリの場合、使う側も限界をわきまえているんじゃないでしょうか、
>あるソフトが、突然動かなくなっても、当然仕事の効率は落ちるものの、企業の存続に関わる
>大事にはならないような気がします。
中小企業だからこそ、ちょっとした事が致命傷な気もしますが。
#存在自体がホラー
昔からそういうものです (スコア:0)
いまさら気がつくのは新人です
Re:この訳を読んで何か書く前に (スコア:4, 参考になる)
The Atlantic の記事と、本家 /. の話題は、少しずれているように感じますが、
私の語学力では、この記事は、本家の直訳ではありませんが、大きくずれているようにも見えません。
よろしければ、ポイントをお示しいただけないでしょうか？
「直訳」を使わず、The Atlantic の一部を混ぜるあたりは、わざとやっていることだと思います。
Re:低品質のタレコミが/.Jを支えています (スコア:1)
S/W開発の話ではありませんが、こんな記事が。
アニメ、アイドル、元気な中小企業…… 日本は「過剰品質」で突き進め！ [diamond.jp]
この記事の筆者は「過剰品質」の意味を誤解しているような気がしてなりません。
# 曲解でないと信じたい。
死して屍、拾う者なし。