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

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

  • by Anonymous Coward
    だまされてるんじゃないの?
    • 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秒で帰ってくるのかしらん(笑)
            • 同意。

              あと、タレコミにあったニュースをちゃんと読んでれば自明のことだが、「40秒以上遅くなった」と言っているのは<b>運用テスト</b>でのこと。
              対してコメントなどで「2秒で終わる」ってのは、単体テストか、せいぜいが結合テストの話でしょ?

              最初っから前提が違ってるんじゃ、話がかみ合わないよね。
              • なんでそんなに必死なの?

                このシステムは1万人も同時アクセスするようなシステムじゃないし、
                運用テストでかかっている時間は、本来のα+40secであって、
                結合テスト以降のαの部分はそのままだよ。
        • RDBだと1000万ってのはざらにあって、ノウハウとかもたくさんあるでしょうが、
          オブジェクト指向DBとか、XMLDBとかだと、どうなんでしょうね。

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

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

          知ったかかまして恥ずかしくないのかね。
          • どこの世界に100万円/人月でPG雇うやさしいやさしいお方がいらっしゃるのでしょうか。
              #ん?単位は円じゃなくてウォンっすか?

            そもそも人月持ち出してるけど、破綻したプロジェクトに100人突っ込んだって(良いか悪いか別にして)100人分の金はもらえないのよ。
            開発用のHWやSWなんて全て用意してもらえると思ってるのかねぇ?
            あなた、小規模プロジェクトのマネージメントどころか、メンバーとしてすら参画したことないでしょ?

            知ったかかまして恥ずかしくないのかね。

犯人はmoriwaka -- Anonymous Coward

処理中...