【動かないコンピュータ】顧客情報検索が40秒余計に…東京ガス、顧客管理システム開発失敗　損失50億円

>>897
今回のケースがまさにそうですね。

瓦斯から天下りになってきた殿はお咎めなし。
現場で無茶だと知りつつなんとか部下をなだめてプロジェクトを率いていた生え抜きマネージャーが降格になったんだってさ。

すごく嫌になるよな。瓦斯ってこんなくそ会社だったんだな。


おれは今年からＦＣ東京サポータをやめることにしました。あー！！！本当に嫌だ。

869さま、885さま、886さまありがとうございます

とくに869さま、参考になります
がんがってみます（｀・ω・´）

これもう少し洗練させたら現代芸術になるんじゃね

60億もかけるなら外注でも良かっただろうーに

業務がシンプルならシステムもシンプルになる。

大きなテプコの
コンピュータ
お祖父さんのモデル
（略）

いまはもう 動かない コンピュータ

東京ガスから見たら６０億なんて
一般人でいう６００円くらいだろ

俺に任せれば、MySqlか桐でも使って格安で作ってあげたのになぁ。
つーか、とりあえず検索で40秒もかかるってどんなシステムなんだろう。

ケチらずにオラクルとMagic使えばいいんだよ。

出来もしない大法螺を吹いて顧客を騙す
システムインテグレーターにも困ったものだ。

>瓦斯から天下りになってきた殿はお咎めなし。
>現場で無茶だと知りつつなんとか部下をなだめてプロジェクトを率いていた生え抜きマネージャーが降格になったんだってさ。


あーあｗ

>>905
アナライズしたら直ったりして＞Oracleを使っているなら

>>907
耐震偽造やライブドアは氷山の一角で、長期デフレの弱肉強食は詐欺的商売を増やす。
統計的に立証できないので難しいが、野党はそのことを問題にしないといけない。
耐震偽造も無理なコスト削減、ライブドアもコスト削減の目的で赤字企業を安く買って粉飾した。

>>898
それは違うだろ。無茶だと知っていたのなら、一身を賭して計画の中止・全面的見直しを上司あるいは経営者に訴える
のがマネージャの仕事であり責任だろうが。
部下をなだめてとか云っても結果としてずるずると敗戦を引き延ばして会社への損害を拡大させただけだろ。
部下だって何をいってもマネージャが全部握りつぶすのでは士気も落ちるし組織への信頼も失う。
「苦労しました」が評価される時代じゃないんだ。結果が全てだ。
無茶だと知っていなくても、見込みがあるかどうか判断できなかったのなら無能だ。
全ての責任をマネージャに負わせて知らん顔している殿も糞だとしてもだ。
もし計画の中止を諫言したにもかかわらず受け入れられず、従順に推進したがやっぱり駄目で、
一人生贄にされたのなら、やはり組織人として無能なのだよ。
たとえ上司の業務命令だったとしても結果として会社への損害を拡大させたのなら
それはモラルハザード以外の何者でもない。姉歯と同じなのだ。
結局、自分の責任じゃないよと口実をもうけてずるずると流されていただけってことだろうが。

>>911
インパール作戦は下士官の責任ですか。

最新の遺伝子研究で、関東人は朝鮮民族であることが完全に証明されてます。

大和民族（＝神奈川県鎌倉・新潟より西の日本人）→中国渡来系を主とした民族、大和政権を樹立した。
蝦夷民族（＝関東人）→北朝鮮渡来の民族、征夷大将軍によって滅亡させられた。
　　　　　　　　　　　　　　　朝廷が後期渡来人（＝朝鮮人）をそのまま関東へ移住させた証拠文献・遺跡多数あり。

�@酒の強さは遺伝子で決まる
http://www2.athome.co.jp/academy/genetic/gen04.html
アジアにおいて、
大和民族と中国人は、N型遺伝子が少ない。
関東人と朝鮮人は、N型遺伝子が多い。

�A国立科学博物館　日本人はるかな旅展　遺伝子によるルーツ研究
http://www.kahaku.go.jp/special/past/japanese/ipix/5/5-26.html
B44-DR13は韓国最大集団→蝦夷民族（＝関東人）は、朝鮮渡来の民族

DNAでは西日本と中国との共通点が多く、関東は朝鮮半島との共通点が多い

�BB型も朝鮮と関東に多い

�C身長
韓国人と関東人で背が高く。中国人と大和民族で背が低い。
関東内でも、東に行けば行くほど、平均身長が高くなる。
http://www.toukei.pref.fukuoka.jp/plane/1022/gakko-hoken-gaiyo-2003-2.pdf

関東人は日本国籍を持っているだけの朝鮮人。
東京を作ったのも大和民族。東京を発展させたのも大和民族。
東京に巨大な税金を渡しているのも大和民族。
つまり、東京は大和民族の街。
関東人は、朝鮮半島へ（・∀・）ｶｴﾚ!

でも普通のERPならクラスタのノード50台単位で増やしていけば
爆発的にある程度処理を加速させることができるが
何をどうやったら40秒という遅延が生まれるのだろうか

>>911
ガス屋は完全に富士通病にかかってるよ。
意味のない若手マネージャー、女管理職の登用、人件費削減でしかない業績考課、
もう若手から中堅まで本来なら現場の最大の戦力となる奴らまで社内政治に夢中になってる。
負け組みは負け組みでやる気をなくし、掛け声だけ現場力なんていったって、そりゃダメだよ。

もうあほらしくて・・・

>>914
技術的な問題じゃなくて、業務整理ができてないんだよ。

>>916
あいつらに業務整理なんてできるわけないよ。
だって、アホなんだもん。
いかに今までの仕事を楽にやるかしか考えていない。
例えば、伝票に手入力していたのを自動入力にするのにはがんばるが、そもそもその伝票の要否なんて考えない。
目の前に与えられた仕事を何も考えずに、パソコン使って楽に何ねえかなぐらいしか考えてない。
そんなもんよ、リビなんて。

４０秒って書くとそんなもんかと思うかもしれないが
40,000[ms]って書くと�dでもない遅さだ

しかし不思議なのは何でこんなこと発表したんだろ？

理由がわからん？？？？？

なんか、CRMとERPを混同してる奴が混じってるな

俺がファイルメーカーーで作ってやるよ。

>>911
諫言して受け入れてもらえないなら、もうどうしようもないだろ。
一体どうしろと？

>>922


陰腹を切るしかないな

マネージャー降格は仕方ないが、上がのうのうとしているのは批判されてしかるべき

なんなら東京ガスは2chのグラマー板に金額を提示してオープンにシステム製作を依頼した方がいいもんできんじゃね？
（変なもん埋め込まれるだろうけど…）
で完成したらその額をどっかに寄付すりゃぁいい。

この責任者しってるよ　　　無能　　　なんと息子も無能

>>899
ガンガレ。
前派遣で似たようなのをやらされたことがあった。
Access→SQLServer

だけど、それがERPシステムで、ストアド権限が無い？
みたいなことになってた。
結局1分40秒に縮められただけだったよww

【気象】気象庁の予報はずれまくりなので新システムへ
http://news18.2ch.net/test/read.cgi/scienceplus/1138971102/


新たなる道路工事と並ぶばら撒き型の公共事業かな？

自社で2003年から始めたならほとんど人件費じゃねえか？
一人年間2000万かかるとして丸3年で60億だと100人規模の開発だね

>>929
なんでパッケージ導入でそんなにリソースかかるのか不思議。
一から作っても変わらないような・・・

シーベル入れるだけで３０億って上に書いてあった

自主的に返上なんてあまっちょろいことじゃくて
ちゃんと罰則で返上させろよ。それじゃ罰則なしとおなじじゃないか。
あますぎだよ

すごい低レベルな開発だった気がする…

元のソフトのレスポンスが悪かったか、
アドオン時にテーブル構成いじっちゃって
アパパパパになったんじゃねーの？

googleとかのサーチエンジンて一体どんな感じに組まれてるん。
どうやったら何十億？てページの中から0.001秒とかで、
しかも世界中からのリクエストを処理出きるのか皆目見当付かない。

ハードの力なの？

市販の凡庸（ぼんよう）業務用ソフトを使って自社で

どっちにしても騙される奴も馬鹿だから同情せん

途中で無理だと気づけよ
まあ、現場では気づいてたんだろうな…

ところで、５０億円の損失はどこから回収するの？

>>939
すまん、誤爆。

こんなのあったけど

システム投資の失敗は､インテグレーターにあります｡
売残りの目林フレームを強引に押しつけていましたから
若手のエンジニア達はブレードでWAS環境を推薦していました｡
この件は２００２年から新規フェイズでつくっていました｡
ところが､既存のデータを変換すればよいのに､データを変換しないでプログラムの改修と
１台ウン億円のメインフレームと一人１人月５０万円のコボルのエンジニアで
せこーくつくっていたのです｡
有能なエンジニアは単金が安いためにどんどんとやめていき､やがて５５才くらいの仕事のとろい
親爺さんばかりのエンジニアで構成されていきました｡断念したのは去年の９月頃です｡
何で発表が１月末になったか不明です｡
今日びLinuxのブレードシステムに大規模DB+webを構成すれば３０億円ほどで
もの凄い良いシステムができますことを一応補足しておきます｡
何でメインフレームに固執していたのかわかりません｡

http://messages.yahoo.co.jp/bbs?.mm=FN&action=m&board=1009531&tid=el5fea5aca59&sid=1009531&mid=5190

ブレードシステムじゃ期待出来るほどのレスポンス能力は、無いんだけどね...。
ごくフツウーのサーバで分散処理した方がマシなんだ。

ブレード化して失敗している所は結構有るけど、
大成功したと豪語してる所は....雀の涙ほどしか無い。

>>941
ヒント：メインフレーム、役員、賄賂

http://www.secu354.co.jp/gis/gis03122505.htm
ガス供給サービスの概要

東京ガスのガス供給区域は東京湾を囲む首都圏（３１００平方km）で、
顧客数は約９百万件、ガスパイプの総延長距離は約４１００kmとなっています。
パイプ内のガス圧力は高圧から低圧まで４段階あり、延長距離が最も長いのは
家庭に直接ガスを供給する低圧ガス導管で延べ４万km以上になります。

共同通信の記事
オペレーターが顧客番号を打ち込んでから、
顧客データが呼び出されるまでに現状より約４０秒長く時間がかかることが発覚。

900万件 顧客番号で検索 顧客データ表示まで４０秒以上か。
で50億円。

普通のクエリでそこまで時間がかかるというのが想像できないんだけど、もしかして、回線がショボイのかなぁ。

１．IBM
２．富士通
３．UNISYS

どこだろ。３が怪しい。

>>942
確かに。
WebサーバやAPサーバならともかく、東ガスみたいな大企業の顧客DBであれば
サーバ単体に高スペックが要求されるので、単体能力が圧倒的に劣るブレードで
作るわけないんだけどね。
検索だけじゃなく更新処理があったり、基幹システムの最新データをバッチ更新や
レポリケーションしている場合には高いI/O能力がいるのでメインフレームか
Unixなんて別におかしくない選択肢。
DB分割して並列処理なんかすると設計大変だし、必ずしも性能出るとも限らないし。

>>941は最近の小規模なシステムを設計したヤツにありがちな、
「PCサーバとWindows or Linuxを複数台並列にならべればどんな大規模システムでも可能」
という幻想にとらわれているのだと思われ。

ブレードにはブレードの、（PC SMP、Unix、メインフレームなどの）単体高性能型
サーバには単体高性能型サーバの向き不向きがあり、基幹システムがHTMLと画像と
スクリプトだけで出来ているならともかく、そんなわけないんだから子供みたいな
「並べれば出来る」的な馬鹿げた発想はやめるべき。