パスワードを忘れた? アカウント作成
5958495 story
ソフトウェア

低品質のソフトウェアが世界を動かしている 95

ストーリー by reo
中長期的な費用対効果の問題 部門より

eggy 曰く、

Atlantic の記事によれば、サプライチェーンや金融システム、生産ラインを支えているソフトウェアの多くはクオリティーが低いとのこと。こうしたソフトェアはストレステストが充分に行われないまま使用されているため、不具合が起きたときに企業が大きな損失を被る可能性を孕んでいると指摘している。ミッションクリティカルなソフトウェアのなかでも特にクリティカルなのが金融システムのソフトウェアであるが、つい先週、ナイト・キャピタルがニューヨーク証券取引所で、自動取引システム障害による 4 億 4 千万ドルの損失を負うこととなった事件 (/.J 記事) も記憶に新しいだろう (The Atlantic の記事本家 /. 記事より) 。

ソフトウェアが誤作動を起こす可能性は無限に存在しており、不可能ではないにしても、起こりえるプログラムの誤作動をすべて予測するというのは非常に難しい。また、そのシステムで制御することのできない他のプログラムが絡んでくると更に困難を極める。こうした問題を解決するには、なによりも優秀でやる気のある開発者が必要であり、現場の開発者同士が互いの作業状況を頻繁に確認し合い、率直に意見を出し合える雰囲気が必要であるとしている。また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを優先させた方がいい、と理解できているマネジメントが必要であるとのこと。

プログラムの不具合はそう頻繁に起きることではないが、一旦起きてしまうと企業は非常に壊滅的な損失を被ることになるため、膨大な費用がかかったとしてもストレステストを行う必要がある。だが、こうしたリスクへの意識が低く、テクノロジーについて何一つ分かっていない金融機関は、短期的な視点で目先の利益を優先してしまい、ソフトウェアの品質に対する投資を怠ってしまうとのこと。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by iwakuralain (33086) on 2012年08月10日 13時06分 (#2209826)

    それも含めて仕様なんだよ

    って言う人みたことあるな。
    でも、そのときは確かに向こうの要求通りの内容での障害だったので間違ってはいなかったんだが・・・

    # 質の高いものを完成させるには、それなりの技術や経験そして期間が必要
    # 自分ところはプロジェクトに応じて変化はするけど往々にして期間が足りないことが多いかな

  • by rti (659) on 2012年08月10日 13時26分 (#2209836) ホームページ

    金を湯水のごとくつぎ込んで、
    複数の調査会社入れてコードやシステムをレビューしたり、
    別の担当者による複数のアルゴリズムで多数決したり、
    複数のデータセンターに冗長化された構成にしたり、
    することはできると思うけど、
    それにかかるコストと、まぁそこそこ動く安いヤツでの費用対効果でしょう。

    それでも心配というなら、保険でも作ればいいと思う。
    保険会社がコードやシステム、体制の調査して金額弾きだすんだろうけど。
    その保険に入るかどうかも、費用対効果だろうけどね。

    クソなものと良い物のどっちがいい?っていけば誰だって良い物が欲しいはずで、あとはコスト比較だと思うしね。
    あとはそのクソがどこまで容認できるかってのを決めるだけだろう。

    んで、そのどこに落とし所を持っていくのかをずばって決めるのが経営の仕事だと思うわー

    --
    by rti.
    • by epgrec (43527) on 2012年08月10日 15時06分 (#2209886)

      リンクされてるThe Atlanticの記事ではアルゴリズム取引なんかを例に出して
      プログラムエラーが途方も無い損失を引き起こしうるが、決定権を握っている人たち(男性ホルモンで
      行動してるトレーダーとか)はコストを重視しがちでリスクを過小評価しているというようなことを
      書いてるみたいです。つまり、

      >そのどこに落とし所を持っていくのか

      が上手くいかない構造がヤバいよね、みたいな話ですな。
      リスクを過小評価するってのは人間の性みたいなものじゃないかとも思いますけど。

      仮にエラーが起きる確率が10年に1度程度で、いくらかの損失が出るくらいなら、品質が悪くてもほうっておけ
      みたいな判断になるでしょうけど、10年に1度の確率で数億ドル、取引が複雑になるにしがって損失が増えると
      すると数百億ドル数千億ドルとふくれあがっていけばエラー一発で破綻という可能性も出てくるので、そうした
      リスクが正しく評価できてないというのはたしかに恐ろしいかもしれません。

      親コメント
      • by nim (10479) on 2012年08月10日 17時39分 (#2209975)

        投資銀行なんかは、プリンシパル=エージェント問題が典型的に出るところ
        (品質の低いプログラムでバグが出て会社が潰れても、最悪首になるだけ、
        もしも品質を犠牲にした開発ですごい利益が出たらボーナスたっぷり)
        なので、リスクの過小評価の一員になっているかもしれませんね。

        親コメント
    • by Anonymous Coward

      つまり、みずほは正しい

    • by Anonymous Coward

      費用対効果ならまだ理解できるけど
      コストバカ高いのに低品質な物があるからこそ問題だと思うけどな。
      安くて低品質、高くて高品質、なら費用対効果のバランスって言えるけど
      高くて低品質なら何の意味もない。
      大体有名所の仕事はそういうものだけど。
      なにせ有名所といっても直接してるわけじゃなく、自分達は高額で請け負って下請けにその半額とかで回すだけのことだし。
      その下請けが更に下請けに出して~~、で結局入札額の1/10みたいな開発費で底辺の所が行うだけのこと。
      あれ、じゃあやっぱり費用対効果はあってるのかw 最終的な一番最後の下請けの開発費でいえばw

      つまり中間マージンなくせば全て解決。
      流通でもなんでもそうだしな。

      • by rti (659) on 2012年08月10日 14時55分 (#2209878) ホームページ

        孫請けなどの多重下請けが問題かなー?
        それであれば、多重下請けなんてしていないで直接仕事を取りに行けばいいんじゃないの?
        それができない理由が多重下請である理由だと思うわー。
        そして、そこに価値があると思っているから、金額があがるんじゃないの?

        --
        by rti.
        親コメント
  • 問題を起こすシステムは起こした問題によって観測できるが、
    問題を起こさないシステムは観測できない(観測しづらい)という事ではなかろうか。

    --
    #存在自体がホラー
  • つまりこういうこと?

    開発に十分な開発期間や検証環境を与えず、運用で稼動系統を分けるなどのリスク分散を行わない。
    こういった局地的かつ近視眼的なマネージメント層によって世界が動かされている。
    人の特性を忘れて、速さと数字だけでマネージメントしちゃあかんよ。

  • 業界の構造 (スコア:1, 興味深い)

    by Anonymous Coward on 2012年08月10日 12時51分 (#2209811)

    他の国は知らないけど日本の場合は業界の構造がソフトウェアの低品質をもたらしているのでは。たとえば東証の新システムもあちこちが入札したけど、出来レースのように富士通が勝った。こういう「権威ある」システムを受注するところは技術力で選ばれるのではなく最初から決まっているのではないか。他にも日立とかNTTデータなんかも特定のお得意様から仕事を貰える構造。

    • by Anonymous Coward

      特許庁みたいに、ちゃんと入札して選んだつもりが、作り始める前にギブアップ、ということもあるけどね。
      実績がある、というのも技術力のうちかと。

    • by Anonymous Coward

      ・「出来レースのように」「最初から決まっているのではないか」と考える(想像する)根拠
      ・お得意様から仕事がもらえる構造がソフトウェアの低品質をもたらしていると考える根拠

      この二つが要るな。

      例として挙がっている東証の新システムは確かに少し前に障害を出した [nikkeibp.co.jp]のは例の一つとして提示できるかな。でもこの例は運用に問題があった [nikkeibp.co.jp]のも影響拡大の原因のようなので、これが「お得意様から仕事がもらえる構造」が原因なのかと考えるべきかどうか。

      • by Anonymous Coward

        最初から決まっている根拠が外部に漏れたら随意契約って叩かれるでしょ。表向きは公正な競争にしておかないと。

        お得意様から仕事がもらえる構造がソフトウェアの低品質をもたらしているのは、うちは某財閥系の孫会社だけど何となくわかる気がする。社員は最低限の基準さえ満たしていればどうせ上から仕事が降ってくるからって理由で無気力な人が多いよ。品質のいいソフトウェアを作ろうって気概がない。別に頑張らなくても仕事が保証されたらそうなるのは自然じゃないかな。

  • 日本だとやっぱりみずほですかねぇ・・・
    なんであんな納期でできると思ったんだろう・・・?

  • by CompuNEO (21886) on 2012年08月11日 4時17分 (#2210291)

    日本のシステムは過剰品質だと言われますが実際的な感覚としてどうなのか、気になっています。

    最近「ガラパゴス」と揶揄されるように、日本はデザインや少し前に流行ったUX、とにかくユーザに近いところを軽視しがちであることは経験的に認識しています。一方で、この記事にあるような、ミッションクリティカルシステムの欠陥数が世界標準と比して多いのか、少ないのか。

    5年ぐらい前、当時、仕事で出張することが多かったのですが、ドイツの国際空港(どこだったか忘れました)の掲示板にWindowsのシステムエラー画面が延々表示されて困ったことが印象に残っています。同じ時期、国内線も月に数回使っていましたが、掲示板にシステムエラーが表示されたことはありませんでした。

    ドイツと言えば、日本が色々なことをお手本としてきた国。その国の空港でWindowsのシステムエラーがふつーに表示されている。単に運が悪かったのか、要求される品質がそもそも違うのか。空港の掲示板がミッションクリティカルとは言えませんが、色々考えさせられました。

  • by YF19 (12943) on 2012年08月11日 12時15分 (#2210389) 日記

    この場合の「品質」って何を指してるんだろう?

    そもそも、不具合って何?

    議事録の内容すら「前任者の言う事なんか知りません」と突っぱねる人知ってますけど、そういう人にかかると、仕様通りに作っても、バグが無くても、不具合があると言う事になるんですが?

    --
    若者は老人が馬鹿だと推測するしかないが、老人は若者が馬鹿であることを経験で知っている
  • by Anonymous Coward on 2012年08月10日 12時16分 (#2209782)

    >また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを
    >優先させた方がいい、と理解できているマネジメントが必要であるとのこと。

    理解出来ても実行出来るとは限らん、というかムリだorz

    • by Anonymous Coward on 2012年08月10日 14時59分 (#2209880)

      偉い人たち(中間管理職ではなく、トップマネジメントの次の連中)は目の前のキャッシュフローしか興味ないですからね。

      ウチの場合、ロジックやエラー処理は一切抜きのデモUIのみの営業プレゼン用ソフトウェアを見て、
      「なんでこれが売れないんだ!このまま売れ!」とか怒り出す人たちですから理解なんて無理なんですよ。
      (指示する際も「とにかく顧客デモをやれ、その部分だけ作れ」という指示だったのだが、本人が忘れてる。)

      理解している上級マネジメント職も火の粉が降り掛かるのを嫌がって「お前ら、上からそのまま売れって
      言われてるんだから、言う通りにすればいいんだよ」って言い出す始末ですしね。

      親コメント
    • by Anonymous Coward

      納期破る判断って、マネジメントがそれを下すのはほんと難しいよね。
      一度認めると、下々がキツい時すぐそれを求めるようになるだろうし。
      一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。
      それだとなんだか別の問題も起きそうですし。

      もともとの納期だって、それほど確かな下地に基づいて切ってる訳でもないでしょうから。
      優等生理論でいくと、最初にマネジメントが下した「リソースの見極め+納期の切り」に失敗の原因がありましたごめんなさい、っていう反省文とセットで初めて成立しそう。→納期延長

      • by nmaeda (5111) on 2012年08月10日 13時49分 (#2209847)

        スーパープログラマは平凡なプログラマの10倍、100倍の能力があるとか、良く聞くし、実際にそうだとも思うけど、一定以上の規模の仕事の場合、彼/彼女ひとりに依存してしまうと、トラブルが発生したときに対応不能だよね。つまり、納期は彼の能力と気分次第ということになる。

        それよりは普通の能力の人を多く使った方が計画的に仕事が進むし、多人数の方が途中経過を正確に把握しやすい。特定の部分や特定の人の仕事が遅れていれば、それを強化することも容易。

        親コメント
        • スーパープログラマかどうかは知らんけど、一人のプログラマに過剰に負荷がかかった結果、ダウンしてしまって、品質維持どころじゃなくなった例も知っているし、一方でプログラマ増やしすぎて、どいつもこいつもバラバラな実装やらかした結果、品質維持が出来なくなった例も知っていますんで、単純に多く使えば良いとも言い切れないなぁ。

          多くの場合、プログラマよりも、旗振り役の方に高いスキルの人員が居ないと、プロジェクトはコケやすい気がする。

          --
          若者は老人が馬鹿だと推測するしかないが、老人は若者が馬鹿であることを経験で知っている
          親コメント
        • by Anonymous Coward
          >普通の能力の人を多く使った方が
          >計画的に仕事が進むし、多人数の方が途中経
          >過を正確に把握しやすい。
          上が「普通の能力」を持ってないと、いずれにしてもダメダメ。
          無計画に多人数にして、却って全体を制御できなくなる。
          ああ、さっさと抜けたい。
      • by Anonymous Coward on 2012年08月10日 13時13分 (#2209829)

        一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。
        それだとなんだか別の問題も起きそうですし。

        ファーストサーバ…

        親コメント
        • by Anonymous Coward on 2012年08月11日 6時19分 (#2210307)

          最近の会議では「ファーストサーバ」という単語が万能でありがたいわ。

          「オペレーションマニュアルの必要性を説くとき」
          「リカバリマニュアルの必要性を説くとき」
          「バックアップの有用性を説くとき」

          今のところ、これらのケースでは「ファーストサーバ」と呟くだけで事足りた。あの事件は風化しないで頂きたい。

          親コメント
      • by Anonymous Coward

        >下々がキツい時すぐそれを求めるようになるだろうし。

        なーに、キツくならないよう、最初から十分な余裕を持った納期を設定しておけば良いだけのことですよ。
        #やれるんならやっている!

        • by Anonymous Coward on 2012年08月10日 15時14分 (#2209894)

          ソフトウェアではないですが、設計レビューを十分やるために社内委託作業(社内の
          CAD設計担当部門への設計委託)で通常より5割長い納期(と費用)を設定した
          ことがあります。(担当部門要求4週間に対して6週間)

          結果、どうなったかというと、その分以上に前半でサボられて余計品質が悪くなりました。
          いつまでたっても初版のレビュー用データが出てこない。

          問い詰めると、こっちから金をとっておきながら、他の部門からも金を取って、違うことを
          していたらしい。結果、数百万の金を取られて、さらに外部での再設計と納期遅延で
          億に近い損失がでました。

          社外なら訴訟ものですが、社内だからどうにもならん。

          親コメント
          •  社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
             どちらかというと、「設計・レビューが~が理由でできない」というクレームが上がってきたときの対応のほうが重要なはず(それで遅れても許容する余裕もね)
            #発注側の余裕と、受注側の余裕はずらすといいですよw

            親コメント
            • by Anonymous Coward on 2012年08月10日 17時04分 (#2209954)

              > 社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。

              うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
              ダメダメだからレビューをしっかりやるスケジュールを立てたら余計にダメダメだった、ってことです。

              > #発注側の余裕と、受注側の余裕はずらすといいですよw

              社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
              モノ作りだと試作ラインの確保もしなきゃいけないですし。

              親コメント
              • >うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
                 他の部署にも影響してそうだから上にあげるべきですね。
                #社内にやらせるくらいなら、社外に出したほうが安くて早い!(とかw

                >社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
                 何言ってるんですか、隠せれないなら脳内予定を作っておけばいいんですよ(苦笑)
                 試作ラインの確保は・・・どうしようもないですね。自分の予定に別の予定を1週間程無理やり突っ込んでずらすとかくらいしか思いつきません><

                親コメント
        • by Anonymous Coward

          禿同!

          こんなあたりまえのことが通じないのが現実。
          始まる前からまともなら納期遅れになるのはわかっている。
          それを期日にまにあわせるには真っ当な方法ではむりなのはあたりまえ。
          水の多いコンクリートなら工期の短縮はできるようなもの。
          耐久性を問われても困ります。

          #納期が過ぎてから気合が入ります

  • by Anonymous Coward on 2012年08月10日 12時28分 (#2209794)

    そんな得にならない事を経営者がやらせるわけがない
    トラブルが起きたら補修費用が稼げるとか抜かす馬鹿さえいる
    ※責任問題や訴訟等は全然頭に無いらしい

  • 「ミッションクリティカルなソフトウェアのなかでも特にクリティカルなのが金融システムのソフトウェアである」と断定的に書かれてはいますが、金融機関やストレステストに限った話じゃないでしょう。

    根本的にはコストとの兼ね合いであって、社会全体に「俺はリスクを負いたくない(≒コストも負いたくない)」という風潮が蔓延している限り、状況は改善しにくいんじゃないですかね。
  • by Anonymous Coward on 2012年08月10日 12時43分 (#2209805)

    だって、コストカットの産物だし
    納期を過ぎてでも質の高い・・なんてのはただの妄言

    • by greentea (17971) on 2012年08月10日 21時35分 (#2210139) 日記

      もしトラブルが起こったらどれくらい被害が出るか、それを避けるためにいくらまで資金を出せるかを真面目に考えた結果、トラブルが起こりにくいけど高いソフトより、トラブルが起こる可能性高いけど安いソフトの方がいいと判断したんだったら、費用対効果の高いものを選んだってことになるけど。
      何も考えずに安いのを選ぶのは、費用対効果考えてることにならないよね。

      --
      1を聞いて0を知れ!
      親コメント
    • by Anonymous Coward on 2012年08月10日 13時48分 (#2209846)

      ソフトは人が作る
      人にかけるカネなんぞない

      そういうことでしょ。特に日本企業はその典型では。

      親コメント
    • by Anonymous Coward

      そもそも、コストカットできなければIT化する意味がない。
      (まったくないわけではないが、IT化する動機の主要な一部分が失われる)

      • by Anonymous Coward

        全体的なものを見越してコストカットするのに
        ITの部分で障害が出かねないぐらいのコストでやらなければならない時点で

        そんなものをIT化する必要性はない

    • by Anonymous Coward

      そんなもんですよ。企業インハウスアプリなんて、昔も今も作り捨て。
      昔はVBやExcelマクロ、Notesアプリ、今だとPHPやAdobeAIRなんかで書くのかな。

      大都市にはそういう仕事をこなす個人営業の「街のVB屋さん」がいて、大田区の中小工場がごとく簡単な仕事を任せてました。
      そういえば、かつてEUC(エンドユーザコンピューティング)なんて言葉が流行りましたよねぇ。

      • by Anonymous Coward

        中小企業の自前のアプリの場合、使う側も限界をわきまえているんじゃないでしょうか、
        あるソフトが、突然動かなくなっても、当然仕事の効率は落ちるものの、企業の存続に関わる
        大事にはならないような気がします。

        ある意味、ソフトとの適切な距離の取り方かとも思います。

        • by matlay (32743) on 2012年08月11日 1時01分 (#2210248) 日記

          >中小企業の自前のアプリの場合、使う側も限界をわきまえているんじゃないでしょうか、
          >あるソフトが、突然動かなくなっても、当然仕事の効率は落ちるものの、企業の存続に関わる
          >大事にはならないような気がします。

          中小企業だからこそ、ちょっとした事が致命傷な気もしますが。

          --
          #存在自体がホラー
          親コメント
  • by Anonymous Coward on 2012年08月10日 14時38分 (#2209869)

    いまさら気がつくのは新人です

typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...