パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

東京ガス、システム開発失敗で50億円損失」記事へのコメント

  • by Anonymous Coward on 2006年02月02日 1時01分 (#875296)
    だまされてるんじゃないの?
    • by Anonymous Coward on 2006年02月02日 1時34分 (#875336)
      まーさーかー、カーソルをループ回して頭から最後まで自前のコードで舐めてるんじゃなかろうな。
      親コメント
    • 最初から作り直しってことではないかと.

      親コメント
    • そうおもいます。
      • by Anonymous Coward on 2006年02月02日 1時28分 (#875329)
        これで30億いくかは疑問だけど、

        • 検索対象のデータ種が死ぬほど多岐に渡る
        • 検索対象のデータ量も死ぬほど多い
        • 各種のデータが検索可能な形で保持されていなかった
        • 後からOLAP的な高度な絞込み・照合機能のサポートが要求された
        などなどが積み上がって、データ自体を再構成する必要が出てきた結果、それら作業を含めて30億になってしまったとか・・・

        親コメント
    • by Anonymous Coward
      http://www.tokyo-gas.co.jp/Annai/index.html [tokyo-gas.co.jp]顧客数約964万件だからね。
      大阪府の人口より大きな数字ですよ。

      実際の話30億が無茶に高いなんておもえませんな。

      大規模開発の経験ないと安く見積もってしまうんだろうなぁ・・・
      100人以上のSE部隊で1フロアびっしり埋め尽くされた中でのシステム開発なんて大規模なものを一度でも経験してみりゃ人件費考えただけでも桁の違いに気づくでしょうね。
      • by Anonymous Coward on 2006年02月02日 8時01分 (#875404)
        1000万件程度のDBってショボショボですが。

        まともなシステム開発の経験がないと理解できないのは仕方がないが、
        知ったかかまして恥ずかしくないのかね。
        ちなみに常時100人以上がフロア占領してると、賃料いれても10億/年いかねぇぞ。
        何年かけて直すつもりだ?

          #こんなコメントに参考までついちゃうのはどうにかならんものか
        親コメント
        • by calc (16044) on 2006年02月02日 8時52分 (#875421) ホームページ 日記
          > 1000万件程度のDBってショボショボですが。

          しかも顧客番号で検索して、現行システムより40秒以上て・・・

          顧客番号といったら普通ユニークキーなわけで、どうやったらユニークキーによる検索でそれだけの時間がかかるような糞システムを作れるのかさっぱり理解できませんね。

          インデックスを全てオンメモリで処理できるだけのメモリをサーバに積むとして、顧客番号が12桁の文字型と仮定しても1000万件でたったの120MB、かなり余裕を見てメモリを256MBも増設したとして、今時256MBのメモリなんてサーバ用の高級品でも10万円もしないでしょう。
          読み込むのも今時のHDDだと120MBのデータをHDDから全て読み出したとして5秒もかかればかなり遅い方なわけですから、
          基本設計がまっとうに行われていたら10秒もあれば応答するシステムが作れますね。

          ちなみに、私が仕事で顧客情報のDBを作った時が氏名50桁住所100桁くらいだったから諸々の属性情報を多めに見積もって顧客一件300byteと仮定したら
          1000万件で3GB、
          端末とサーバは1000Baseで結ばれているとして3GBの転送にかかる時間は
            3000*8/1000 = 24秒
          実際には帯域の半分くらいしか使えないとすると48秒

          48秒ということは
          > 顧客番号で検索して、現行システムより40秒以上
          にだいたい合致するではないですか!!!

          謎は全て解けた !!!!!

          結論:このシステムを組んだ奴はデータベースの正しい使い方も知らないド素人
          親コメント
          • by Anonymous Coward on 2006年02月02日 12時21分 (#875575)
            顧客管理ってのは顧客テーブルを画面に表示する機能を言ってるわけじゃないでしょ。
            過去の取引情報(数年分
            設置してある設備情報(及び履歴
            設備情報から故障履歴DB、販売DBとリンク
            それ以外にも東京ガスのインフラを管理するシステムのようなもの接続していたりすればいくらでも情報は増えると思うけど。
            これだけでも何十倍にも情報量が増えると思う。
            親コメント
            • > これだけでも何十倍にも情報量が増えると思う。

              それは個々の顧客を選択してから「詳細情報」として引っ張り出してくるなどの遅延処理を行って無駄なクエリーは発生させないのが普通でしょう。
              適切なインデックスが設定されていれば顧客に付随する情報を顧客コードを指定して取ってくるなんてのはたいして時間がかかる話ではありませんので。
              親コメント
              • > 適切なインデックスが設定されていれば顧客に付随する情報を顧客コードを
                > 指定して取ってくるなんてのはたいして時間がかかる話ではありませんので。

                ○○機器を使っていて、故障が発生していて、まだ未対応で、なおかつ空いている
                工事担当者が担当できそうな地域エリア、の顧客一覧を知りたいなどの要件を
                要件定義時にばっさり切り捨てられる交渉スキルがあれば、「必ず顧客コードを
                指定してください」っていうシンプルなシステムを作れるでしょうね。

              • by Anonymous Coward on 2006年02月02日 13時57分 (#875647)
                いやちよつとおちっけ

                Yahoo! ニュースの記事では
                > しかし運用テストの結果、オペレーターが顧客番号を打ち込んでから、
                > 顧客データが呼び出されるまでに現状より約40秒長く時間がかかることが発覚。

                これだと顧客番号だけで検索してるっぽいぞ。
                親コメント
              • >○○機器を使っていて、故障が発生していて、まだ未対応で、なおかつ空いている
                >工事担当者が担当できそうな地域エリア、の顧客一覧を知りたいなどの要件を

                それはコールセンタが使うシステムではありませんね。

                  #なぜごめんなさいの一言がいえないのか
            • by Anonymous Coward
              もしかして、中の人ですか?
              あなたが作ったから、情報量が増えたら検索速度が遅くなるような糞システムが出来上がったんですか?
              RDB触ったことあるのかなぁ?
              過去の取引情報数年分って、今回のシステムは何のためのシステムなのか理解してますか?

                #こんなのにすば洞つけんなよ、晒し意図か?
            • いってることはわかりますけど、

              ・ちゃんとインデックスを張ってあってその辺の関連情報を取ってくるviewをきちんと作ってある
              ・viewを使って検索するやつが間抜けなリニアサーチ

              とかね。見積りとしては結構いい感じじゃないのかな。てかさー、そういう発言しちゃうって事はあんたviewとかしらんし複数人で開発とかもしたことないでしょ。
          • by Anonymous Coward on 2006年02月02日 9時06分 (#875425)
            元々持っていた顧客DBにユニークキーが付いてなかったとか?

            某社のRoHS対応請け負いましたが、各部品にユニークキーが無く、惨憺たる開発でした。
            親コメント
          • by calc (16044) on 2006年02月02日 9時22分 (#875436) ホームページ 日記
            妙なテンションで書き散らかしてしまいましたが要するに

            > まーさーかー、カーソルをループ回して頭から最後まで自前のコードで舐めてるんじゃなかろうな。

            そのまさかの可能性がきわめて高い、ということです。

            そんな腐れコードをたった40秒かそこらでこなしてしまう今時のハード事情ってすごい。。。
            親コメント
          • 最初に断っておきますが、私は中の人ではありません
            (中の人だったら確実に「中の人なのでAC」してる)

            リンク元の記事によると

            > 同社は顧客対応を迅速化するため、03年から60億円を投じて、コールセンターでの問い合わせ内容などを管理するシステムと、販売代理店が行う機器の販売、修理などの情報を管理するシステムの2つを統合する作業を自社で進めていた。
            >  しかし運用テストの結果、オペレーターが顧客番号を打ち込んでから、顧客データが呼び出されるまでに現状より約40秒長く時間がかかることが発覚。

            ということですが、私の発言は全て上記引用からの推測です。

            ・二つのシステムの統合なんだから、中身がわからなくても新システムの応答時間は常識的に現状システム+αになるだろうと推測できる。
            ・普通、減価償却の関係でこういったシステムは3年とか5年とか10年とか使われる。つまり現行システムのハードは少なくとも3年前の代物。
            ・ムーアの法則によるとCPUの性能は2年で倍になる。システム全体の性能も2年で倍、とはいかないが3年だと確実に倍にはなっている。
            ・初期予算30億、追加予算30億の時点でDBサーバが一台こっきりの予算しかないなんてありえない。
            ・既存システムのアップグレードに際しての性能見積は新規開発の場合に比べるとはるかに簡単。

            既存システムのアップグレードという非常に性能見積がやりやすい状況で、予算も潤沢にあり(初期予算30億はいいとして追加で30億とれるって何?)、しかも年々ハードウェアの性能は向上している、なのに「現状より約40秒長く時間がかかる」なんておかしいだろ、ということです。
            新規システムで応答時間が40秒だったら私だってここまで馬鹿にしません。

            #で、個人的な経験則として、こういう場合は誰かが信じられないミスを犯しているケースである確率がかなり高い、といったあたりから親コメントのような結論に
            親コメント
          • by Anonymous Coward
            ネックがユニークキーだ、オンメモリだ、帯域だなんて言い出す時点で、
            複雑な業務系にたずさわったことがないのがバレバレですな。

            現実的な話、1000万件の顧客情報を 1000万レコードで管理できると思ってる?

            世の中、サルでもできる EC サイト構築ばかりじゃあないんですよ。
            • by Anonymous Coward on 2006年02月02日 10時15分 (#875482)
              顧客要件として1000万件の顧客情報があること、
              そこが検索処理のボトルネックになることがわかっているとすれば、
              1000万レコードで管理できるように設計するものじゃないの?
              親コメント
            • でもですね。
              30億は大企業の基幹システムとして高すぎるとは思いませんが、それでも地銀、中堅証券クラスの投資じゃないですか。
              ガスのシステムってどのあたりがそれほど複雑なのでしょうか。

              金融システムに比べると、顧客と外部の会社との取引や顧客間の取引というものが(あまり)ないという時点でかなり楽なシステムですよね。
              証券口座や銀行口座は一つのDBにしないと厳しいところがありますが、こういうのは比較的簡単に顧客番号でディスパッチしてDBを分散できそうです。
              親コメント
            • じゃあ、どこがネックになってるの?
            • by Anonymous Coward
              > 現実的な話、1000万件の顧客情報を 1000万レコードで管理できると思ってる?

              1000万件の顧客情報に全体で何億、何兆のレコードを費やそうが、
              それの管理(Index)は1000万レコードで出来ないと困ります。
              どうやらそこが貴社の開発チームのネックみたいですね...。
            • by Anonymous Coward
              >複雑な業務系にたずさわったことがないのがバレバレですな。

              あなたが触った(≠携わった)のは複雑な業務系じゃなくて、腐った業務系なだけでしょ。
              顧客情報周りの扱いがどういうものなのか理解できてないからそんな発言が出るんだよ。

            • >ネックがユニークキーだ、オンメモリだ、帯域だなんて言い出す時点で、
              >複雑な業務系にたずさわったことがないのがバレバレですな。

              >現実的な話、1000万件の顧客情報を 1000万レコードで管理できると思ってる?

              >世の中、サルでもできる EC サイト構築ばかりじゃあないんですよ。
              なぜかマイナスモデされているが、私も同意。

              あくまで一例ですが、コアなテーブル同士なのになぜか複数サーバに分かれていて通信コストを考えないとかいう設計をすると簡単にパフォーマンスは落とせます。

              「コアなテーブルなのになぜか複数サーバに分かれて」なんてクレージーだ?
              まぁある意味そうなんだ
          • > 顧客番号で検索して、現行システムより40秒以上
            1000万件程度のDBでよほどアホな問い合わせしても、通常そんなかからん。
            DBの問い合わせ使ってないか、使い方間違ってるんだろね。
          • CSV+正規表現ですよ。

            ソンナバカナ・・・
          • 業務ロジックも分からないのによくここまで書けるなとある意味感心です。
            関係者の話によると完全にはずれです。
            誰かが推察してますがCRM関連ですね。
            1000万行のテーブルの検索だけで済んだら楽なモンです。
            1000万行あるって事はそれに見合った負荷や付属情報があるっことくらいてすぐに分かりそうなモンだけど
            DBのみに原因を帰結させるって分散処理が一般化して
            十数年経つのに未だにプロセス指向的にしかシステム見れない人が
            多いって事なんだろうか?
            • >誰かが推察してますがCRM関連ですね。
              えーっと、つまり、
              「顧客の夢いっぱい、機能満載の動かないコンピュータ」
              というパターンでしょうか?
              技術を知らない営業がよく作るという。

              ほんとうは契約ができた時点で失敗することが確定しているのだが、
              技術を知らない営業はそれを理解する能力がないし、責任者は
              責任をとりたがらないから問題はひたすら先送りにされる。

              その結果が30億の損失なら、まだ安い方じゃないかな。

              #ちなみにこの損失には過労死や自殺者に支払われる生命保険や
              #何かは含まれておりません。
          • あなたたちの言い分は、数人のデータ登録、数人のデータ検索の場合の話。 件数どうのこうのより、アクセス数考えてませんね。。 1秒で返答がある仕組みに1万人がアクセスした場合、果たして全員が1秒で帰ってくるのかしらん(笑)
        • RDBだと1000万ってのはざらにあって、ノウハウとかもたくさんあるでしょうが、
          オブジェクト指向DBとか、XMLDBとかだと、どうなんでしょうね。

          そのあたりのデータベースを無理矢理使って、やっぱRDBだよねー。
          で、作り直し。といったパターンもあるかも。
          親コメント
        • 単純に工数だけにしてみても
          100人x100万(人月)で12億ですね
          しかもかなり大雑把な単価ですし、
          工数は人月積み上げだけじゃないですよね
          あとフロアに100人いる場合は大抵外にも…
          もちろんHW、SW抜き…

          仮定にたいしてあれこれ言うのは意味がないですが、
          これが言いたかったんですよ。

          知ったかかまして恥ずかしくないのかね。
      • by Anonymous Coward on 2006年02月02日 2時17分 (#875352)
         検索の応答速度の話に限ると、予算がどうこうより、検索条件の仕様次第だと思うのですよね

         964万件は、大手ベンダから見れば、まだまだ中の上の規模といったところではないでしょうか?
         以前、700万顧客のシステムを担当したときは、検索条件を限定することで、レスポンス3秒未満を確保した経験があります

         検索条件の自由度が高すぎると、30億が300億であろうと理論的に実現不可能だと思います

        親コメント
        • ここらにぶら下げてみる…

          前に社内の火消しを頼まれて顧客と設計の間に入った時に似たような話が…もともと大デスマーチ、遅れに遅れてなんとか納入したシステムだったのですが…

          顧客の言い分
          ・ぜんぜん予定の性能が出てない、こんなの使えない

          設計の言い分
          ・どう頑張ってもこれ以上の性能は望めない。良くて10%程度の性能向上案がありますが、かなりお金がかかります。

          んー、なんでだろ、って事で顧客と設計を同席させて、いろいろヒアリングをしてみた結果、判明したことが…

          ・顧客は既存システムをWebシステムに乗り換えたかった
          ・既存システムはローカルなアプリケーションだった(これも使いにくかった)
          ・*操作性を変えたくない* のでローカルなアプリケーション的な仕様を要求していた(カーソルキー押したら次の入力フィールドへ、数値入れたら一覧表の中の数字や品目が随時更新される等。仕様を作っていたのは顧客のシステム部門)
          ・設計はその要求仕様を丸呑みにしてぐりぐり実装していた

          「えーとですね、WebアプリケーションにはWebアプリケーションなりの利点があり、欠点があります。そこをお互い理解した上での改善案を出したいのですが」

          と理解をしていただいた上で、大刷新(画面周りのみかるく修正(というか大量に削除)…バックエンド系は殆ど弄らず)させてもらったことがあります。

          「顧客の本当の満足は何によってもたらされるか?」を理解したうえで、それに向かって説得するのもSEの仕事なんだがなぁ…自縄自縛というか、罠があるのにはまるの好きだよねぇ、うちの会社の人は、と…orz

          意外とこんなとこかも…
          親コメント
          • by Anonymous Coward on 2006年02月02日 13時04分 (#875603)
            上司の満足度を上げる為には、顧客満足度を犠牲にしてでも
            開発コストを大きくする(見せる)必要があるのです。
            親コメント
          • by Anonymous Coward on 2006年02月02日 14時57分 (#875686)
            「操作性そのままに出来る?」
            「非常に大変ですし、お勧めできませんが出来なくは無いですねぇ」
            「出来るならやってよ、うちはその方がいいからさ」
            「(うわ。ちょっとヤバイかも)わかりました。」
            みたいなノリかと(笑

            もっとも仕事を受ける前段階での打ち合わせで「できません」とか「しないほうがいいです」とかは言えないよね・・・・
            親コメント
            • 確かにそういうシーンはよくありますが、
              言うべきことは言わないと、えらい目にあうのは自分たち(&部下)です・・
              大昔、上の人間の受けた無茶のせいでどれだけ会社に泊まらさせられたか・・

              私の場合はそれに加えて

              「可能か不可能かといわれれば可能ですが、
              本来の動きからかなり無理した作りになるので
              操作性はそのままでも、動作速度・レスポンス等かなり低下する可能性があります。
              後、手間もかかるのでその分工数が増えて費用が上がりますがよろしいですか。」
              と、これぐらいはいいますね。
              「それでもいいからやって」と言われた場合、
              記録も残しておけば、後でもめたときに顧客は文句言えませんから。

              第二第三業者と競ってるようなシーンだと、上記の費用云々はなかなか言いがたいですが
              少なくとも速度面に関しては注意としていいますね。
              親コメント
              • >確かにそういうシーンはよくありますが、
                >言うべきことは言わないと、
                言うべき事を言うと、首になりませんか?

                なにしろ、そういう経験があるもので...

                >えらい目にあうのは自分たち(&部下)です・・
                「えらい目に遭うのは部下だけだから全然OK」
                という上司の方が多いかも。
            • あるあるwwww

              これで失敗した経験でもない限り、これ以上の議論には踏み込めないですよね。
              本当に顧客にとっていいのはどっちなのか、ということだと思うのですが。
              こういうところで経験の差がでるんですかね。
        • by Anonymous Coward on 2006年02月02日 2時45分 (#875360)
          どこからどこまでのレスポンスかというのも重要ですね。
          自分が想像したのは検針している人が持ってる無線端末です。
          あれで行って帰って3秒は厳しいですよね。
          あとは携帯電話からとか。ま、想像ですが。
          親コメント
        • 色々原因はあるかと思いますが、
          検索条件が大きな原因のひとつになってると思います
          例えば問合せ履歴の問い合わせ内容までを含んだ全文検索をゆるしているとか…

          顧客番号をユニークキーにすれば2秒とかって言ってる人いますが、
          顧客番号のみで検索できるシステムなんて利用者側からしてみれば
          ありえなくないですか?

          あーけどやっぱりありますね、契約番号とか
          某電話会社の料金センターだと、契約電話番号を言わないと情報の照会等が
          できないみたいです。名前とか住所でも駄目らしく…
          ユーザの立場からすると切れそうになりますが
      • by Anonymous Coward on 2006年02月02日 2時29分 (#875356)
        で、30億円をその100人以上のSE部隊とやらに注ぎ込むと、
        何がどうなって検索レスポンスが改善するんですか?
        95人ぐらい手持ちブタさんになりそうですが...。

        もしも、根っこの設計ミスで丸々作り直しと言う話であれば、
        50億円掛けたものを一から作り直して30億円と言うのはありそうな話ですが、
        親コメント

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

処理中...