東京ガス、システム開発失敗で50億円損失 213
ストーリー by GetSet
失敗したでガス 部門より
失敗したでガス 部門より
gonta曰く、"Yahoo経由、共同通信より。東京ガスが、顧客情報システムの開発に失敗し、損失を50億円計上したと発表[PDF]していました。これにあたり、社長が報酬の一部を返上したとのこと。
開発を中止し”失敗”と述べた理由に「レスポンスが悪く、検索のレスポンスを目標値にするのにもう30-40億円かかる」「明確に不具合が解消できる見通しが立たない」といったことがあります。どこのSIベンダーが絡んでいたのか、自社独自開発だったのかは述べられていませんが、”失敗”とはっきり宣言し、損失を計上してしまうあたり、中の人は相当のデスマを経験したのではないでしょか？
古くはみずほのトラブルに始まり、航空管制システムダウンや、東証のシステムダウンなど、最近、トラブルの許されないところ・大手のところでのトラブルが非常に目立ちますね。原因はどんなところにあるとお考えでしょうか？ /.J諸兄のご意見をお伺いしたいところです。"
胃が痛くなる (スコア:5, すばらしい洞察)
開発の失敗を依頼主に報告しなきゃいけない人、
その失敗を聞いた人。
想像しただけで胃が。。
Re:胃が痛くなる (スコア:5, おもしろおかしい)
Re:胃が痛くなる (スコア:3, 興味深い)
>それとも、請け負っちゃったからやるしかないとか？
ってのが基本だと思います。何故か金額と納期だけが先に決まって、その後に設計が始まる。特にソフトウェアは設計をある程度やらないと見積なんて出来ないはずなのに、工事の見積と同じやり方で見積を出そうとするのがそもそも無理なような。...だとすれば設計と製作を分離すればいいと思うのですが、そうすると設計書だけ持ち逃げされるから嫌らしいです。
そもそもどうもこの業界、設計をないがしろにするらしく、SIやSEと名の付くどう見てもソフトウェア作成の素人の人が設計の中心になるようで、設計フェーズで半年１年もかけて何書いとんじゃ、というようなものが平気で製造部隊にまわってきます。設計の段階で、テストコード書いたりしないので、パフォーマンステストとか全く検証してくれません。
ちなみに設計は大手が、製造は下請けが（このくらいの規模だと末端は孫請けとかさらにその下が）やります。その頃には金額は３分の１以下になっています。
# エラクもなく、経験数年の新人にもダメっぷりが分かる
# この業界は想像以上に腐ってるんじゃなかろうかと。
Re:胃が痛くなる (スコア:3, すばらしい洞察)
他の工業製品で言う製造は、ソフトウェアではコピーに当たるわけで。
そう考えると、他の工業製品でいう、新製品の開発に当たるのが、
ソフトウェアで言うと(フルスクラッチの)製作全般と言うことになるわけで、
見積が難しいのも、ある程度仕方ない。
でも、それではビジネスにならないので…
頭の痛い話です。
Re:胃が痛くなる (スコア:3, すばらしい洞察)
設計以前に要件がまとまりません。
要件まとめは技術ではどうにもならず、業務知識と
コミュニケーションスキルが問われる部分です。
つまり、技術屋には向いてない。
要件定義をソフト屋がやる時点でかなり無理がある。
Re:胃が痛くなる (スコア:2, 参考になる)
設計できちんとお金をもらえれば、そこで持ち逃げされても痛くありません。ともすれば設計は顧客都合で期間がのびるけどそれもカバーできるし。
問題は、顧客側でまとめてナンボの抱き合わせ契約を求めてくることです。顧客側も、設計の重要さを認識してきちんと対価を支払うという意識がないと、結果的にリスクも大きくなるし、コストもかかるような場合があることを真剣に考えるべきです。
Re:胃が痛くなる (スコア:3, 参考になる)
仕事の種類を、店番・作業・問題解決の3つに分けて考えます。
店番は飲食店などの接客業で、営業時間が終われば仕事も終わります。
作業は引っ越しのアルバイトのような物で、
1単位の仕事をするのにn時間かかるとすれば、
m単位の仕事をするのにはn×m時間がかかります。
このように、店番と作業は仕事が完成する時間を見積もることが可能です。
問題解決とは、例えば数学の証明問題を解くような種類の仕事です。
解決方法を考えて、その方法を試してみて、
実際に解決できることを確認した時点で仕事が完了となります。
その方法で解決できなかったら最初に戻ってやり直し。
つまり問題解決においては、事前に完了時期を見積もることが出来ません。
# プロジェクトXに出てくるような仕事も問題解決に分類される物ですが、
# 「トロイダルCVTの強度不足解決にかかる時間を見積もれ」と言われても
# できないでしょ?
ソフトウェア開発は、特に設計とデバッグの段階で問題解決の要素を多く含むので、
完成時期を見積もるのが本質的に困難です。
# 開発費用はエンジニアの人件費に比例するので、
# 同様に見積もるのが困難です。
それでもビジネスとして開発する以上、
「完成時期は分かりません、開発費用も不明です。」
では通りませんから、勘と経験を頼りに見積もりを出します。
ところが発注者(素人)が値切り交渉をしてきたときに、
勘と経験を元にした見積もりでは説得力が不足して
押し切られることが多々あります。
それで「オレの勘と経験では絶対にこの期間じゃ出来ねぇよなぁ」と
いうことが発生するわけです。
Re:胃が痛くなる (スコア:3, 参考になる)
非道な独裁者なんかいなくてもデスマーチが起ることが解る。
部下の情状を汲み取りすぎて、計画中止の命令を出せなかったり、とか、
ろくな議論もなく、単に声が大きいヤツの意見が通ったりとか。
日本軍の失敗は、既に六十年も前のことだけど、
今の日本にも共通するところがないとは言えないところが…
Re:胃が痛くなる (スコア:3, 興味深い)
決定的に不足してるよねえ、日本の企業社会は。
コールセンターのシステム (スコア:4, 興味深い)
#現状では何秒かかっていたのだろう？
#Google使えば...（違
もうシステムに仕事を合わせちゃいなよ (スコア:3, すばらしい洞察)
顧客管理やら会計やら人事やらのソフトを作って、それを
みんなで使えばいいぢゃん。
それこそ、ワープロや表計算のソフトみたいに。
会社ごとに根本的に違うことをやってるわけでもあるまいに。
会社ごとにフルスクラッチでカスタムメイドを作らなくても・・・。
まあ言うは易し（ｒｙ、というやつなんだろうけど。
Re:もうシステムに仕事を合わせちゃいなよ (スコア:4, 参考になる)
顧客やら会計やらを人事やら処理するソフトはいろいろ [yayoi-kk.co.jp]あります [obc.co.jp] よ [pca.co.jp]
中小企業なんかだと、頼んでいる税理士事務所で使っているのと同じ会計ソフトの導入を強いられたりしますが、
それで会計情報の受け渡しが簡単にできるようになるので、結果的に経費削減にもなって結構便利ですね。
問題は、こういったソフトでは大企業の大規模な業務には荷が重いということでしょう。
「100万ページの文書を扱えるワープロが欲しい」とか、
「1000万行の表を扱える表計算ソフトが欲しい」みたいな話であり、
「それこそ、ワープロや表計算のソフトみたいに」などとは簡単には言えないかと思います。
Re:もうシステムに仕事を合わせちゃいなよ (スコア:2, すばらしい洞察)
ここで問題になってるのは顧客管理なわけですが、東京ガスくらいの規模の会社になると、蓄積される顧客情報ってのは数10万～数100万件の規模になります。さらにシステムそのものはコールセンターのシステムなので、問合せ履歴なんかはその数倍を蓄積しないといけなかったりとか。
東京ガスのコールセンターがどの程度の人員で運営されているか知りませんが、受付担当のオペレータはたぶん100人以上はいるかな？ その人数が、問合せを受付けるたびに顧客情報を検索したり、保存したりするわけですね。
親コメントで挙げられているソフトがその規模・負荷に耐えられるか、ということになると、ちょっとどころじゃなく心もとなかったりしませんか？
# その種のシステムに関わってるのでＡＣ
Re:もうシステムに仕事を合わせちゃいなよ (スコア:4, おもしろおかしい)
#おふとぴdane
Re:もうシステムに仕事を合わせちゃいなよ (スコア:2, 参考になる)
＃そこが重要な年齢につきAC
Re:もうシステムに仕事を合わせちゃいなよ (スコア:2, 興味深い)
と言うのは冗談としても、XMLで記述しとくのがいいのだろうか？
Wikiみたいなので書いて、後でマージ？うーん…
いずれにしても、100万ページなんて規模となると、
末端ユーザが何の教育も受けずに各自好き勝手に書いたのでは、
まともに作成・保守できるとは思えない。
いずれにしても、なんらかのルールなり、手順なりを
意識しなきゃいかんのではなかろうか。
Re:もうシステムに仕事を合わせちゃいなよ (スコア:3, 興味深い)
SAPやってますよ、っていってもビジネス自体のコンサルティングもできるくらいじゃないと意味無くない？
会社によってやり方が違うから、っていう本末転倒。
同じような意味で元請けのご用聞き＆丸投げのSIerとかはなくなって欲しい。
#某田園都市線沿いの会社とか。
各市町村のシステムなんかもう1個でいいよと時々思う。
まあ保険のために2、3個でもいいけど。
前に役所のやつにいたけどばかばかしいと思ってたのでAC。
Re:もうシステムに仕事を合わせちゃいなよ (スコア:2, 興味深い)
長崎県電子県庁システム・オープンソース [osvfn.com]ってのがありますな。
プロプライエタリなやつでも、一つ作ったら、別の自治体に展開、って普通にやってるのでは。
Re:もうシステムに仕事を合わせちゃいなよ (スコア:4, 参考になる)
>企業会計などが多くの会社で大きく違わないからで、一方日本ではその会社独自の様式でカスタマイズしないと適用できない部分が大きい
のではなく、日本企業がそれまでやってきた事務フローに固執しているのです。パッケージを使うなら、業務をそれに合わせる覚悟でやらないと大きな無駄が出ます。カスタマイズ費用は馬鹿にならないどころか、下手をすれば費用の7割8割まで行きます。できるだけ業務の方を合わせるつもりでやれば(それでも最低限のカスタマイズは必要かもしれませんが)半額以下になりますよ。
Re:もうシステムに仕事を合わせちゃいなよ (スコア:2, 興味深い)
なので、海外でも各会社が大きく違わなかったのではなく、導入した会社が、SAP に合わせて会社を変えたのです。
で、それによって会社組織内の無駄を無くせたと。
社内で SAP を適用できない部分を改めるのが、SAP導入の主たる意義なんです。
カスタマイズして導入するんじゃ入れる無意味ですよ。
５０億円のシステム規模は？ (スコア:3, 興味深い)
先日の６４００万円など吹っ飛ぶ久々の大事件ですな。
顧客管理システムということは、実顧客数は地域一帯の
世帯数＋会社数で数千万だろうけど、設計としては
億クラスの対象を扱えるシステムってことですね。
構築自体も中枢のシステム数箇所に加えて各拠点に
分散している所も含めれば市町村数＋αで1000システムの
連携とかそんなとこまでいくでしょうか（これらの数字は
すべて想像で封筒裏です）。
この中で課金体系、請求方法、設置機器の状態管理、
ワークフロー管理などの全てにおいて定型外の個別案件的な
ものが多数どころじゃなくあるだろうし、担当者の方の
苦労が伺われます。
規模自体の問題と会社間システムという緊密な連携が
取り難いプロジェクトでの舵取り失敗が原因でしょうか。
Re:５０億円のシステム規模は？ (スコア:2, すばらしい洞察)
> 4億件からの検索でも2秒以内に終わります。
2秒に1回のQueryならそれでいいでしょうが。
N Query/秒だと、どう捌きますか？
という問題。
さらに、引越しなんかでUpdateも発生する。
顧客からの問い合わせだけでなく、関連会社からの
社内利用も考えると、Nはどれぐらいなんでしょう？
参考 (スコア:3, 興味深い)
Re:参考 (スコア:2, おもしろおかしい)
fj.jokes出身:
答えは検索アルゴリズム？ (スコア:3, 興味深い)
ただ，全てディスク上にデータがあり，しかも，コールセンターなら複数の検索が同時にかかることになる．というのが技術的問題点でしょうか．
それでも，クラスタリングのような並列処理で解決できそうだけどどうなんでしょ．
Re:答えは検索アルゴリズム？ (スコア:2, 興味深い)
手元の検針票見ると4桁-3桁-4桁の番号
いくら1億レコードあったとしても、uniq indexなフィールドの検索に40秒ってそんなバナナって気がする。
- 既存システムとの連携のためテーブル構造の変更不可
- 新番号と旧番号の変換に変換テーブル使用
- マスターテーブルや変換テーブルの不整備により参照整合性が破綻、外部結合使用
- 外部結合を二重に使うので一旦一時的な検索結果を一時テーブルに保存してから再度検索
とかならそこまで遅いの納得するかもRe:答えは検索アルゴリズム？ (スコア:2, 参考になる)
ドコモショップや大手量販店などの全代理店を含むため、もっと多いです。
以下のURLが参考になるかと思います。
事例研究 - NTTドコモ [atmarkit.co.jp]
ALADIN - 顧客管理システム
DREAMS - 日次会計システム
元関係者だったけど、IDで。
I'm out of my mind, but feel free to leave a comment.
何を採用したかだが・・・ (スコア:3, 参考になる)
検索速度向上に30億って… (スコア:2, すばらしい洞察)
Re:検索速度向上に30億って… (スコア:2, すばらしい洞察)
まともなシステム開発の経験がないと理解できないのは仕方がないが、
知ったかかまして恥ずかしくないのかね。
ちなみに常時100人以上がフロア占領してると、賃料いれても10億/年いかねぇぞ。
何年かけて直すつもりだ？
＃こんなコメントに参考までついちゃうのはどうにかならんものか
Re:検索速度向上に30億って… (スコア:5, すばらしい洞察)
しかも顧客番号で検索して、現行システムより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秒以上
にだいたい合致するではないですか!!!
謎は全て解けた !!!!!
結論：このシステムを組んだ奴はデータベースの正しい使い方も知らないド素人
Re:検索速度向上に30億って… (スコア:2, すばらしい洞察)
過去の取引情報(数年分
設置してある設備情報(及び履歴
設備情報から故障履歴DB、販売DBとリンク
それ以外にも東京ガスのインフラを管理するシステムのようなもの接続していたりすればいくらでも情報は増えると思うけど。
これだけでも何十倍にも情報量が増えると思う。
Re:検索速度向上に30億って… (スコア:5, 興味深い)
前に社内の火消しを頼まれて顧客と設計の間に入った時に似たような話が…もともと大デスマーチ、遅れに遅れてなんとか納入したシステムだったのですが…
顧客の言い分
・ぜんぜん予定の性能が出てない、こんなの使えない
設計の言い分
・どう頑張ってもこれ以上の性能は望めない。良くて10％程度の性能向上案がありますが、かなりお金がかかります。
んー、なんでだろ、って事で顧客と設計を同席させて、いろいろヒアリングをしてみた結果、判明したことが…
・顧客は既存システムをWebシステムに乗り換えたかった
・既存システムはローカルなアプリケーションだった（これも使いにくかった）
・*操作性を変えたくない* のでローカルなアプリケーション的な仕様を要求していた（カーソルキー押したら次の入力フィールドへ、数値入れたら一覧表の中の数字や品目が随時更新される等。仕様を作っていたのは顧客のシステム部門）
・設計はその要求仕様を丸呑みにしてぐりぐり実装していた
「えーとですね、WebアプリケーションにはWebアプリケーションなりの利点があり、欠点があります。そこをお互い理解した上での改善案を出したいのですが」
と理解をしていただいた上で、大刷新（画面周りのみかるく修正（というか大量に削除）…バックエンド系は殆ど弄らず）させてもらったことがあります。
「顧客の本当の満足は何によってもたらされるか？」を理解したうえで、それに向かって説得するのもSEの仕事なんだがなぁ…自縄自縛というか、罠があるのにはまるの好きだよねぇ、うちの会社の人は、と…orz
意外とこんなとこかも…
Re:検索速度向上に30億って… (スコア:2, 興味深い)
開発コストを大きくする（見せる）必要があるのです。
Re:検索速度向上に30億って… (スコア:3, すばらしい洞察)
そこで機能と性能のバランスを見てうまく指導できるリーダがどれだけ居るかどうかが、下流レベルの品質につながるのではと。
まぁ上流の品質が悪ければ、下流でいくら頑張っても無駄ですがね。
Why good projects fail anyway (スコア:2, 参考になる)
---- 末は社長か懲戒免職 なかむらまさよし
バケツでウラン (スコア:2, すばらしい洞察)
たとえばJCOの事故だと、「バケツでウラン」というように原因が特定されて、それが広く報道されるけど、ITシステムの場合、こまかな原因が報道されることってあまりないですよね。そんなの報道したってほとんど誰も理解できないから、ってのもあるでしょうが。
でも、バケツ ウラン [google.co.jp]をぐぐるとまずC Magazine のページ [cmagazine.jp]が出てくるくらいですから、意外と根は一緒なのかもしれません。
東京ガス値上げ (スコア:2, おもしろおかしい)
つい先日、値上げが発表されたばかりでしたが・・・ま、まさか！
金額が… (スコア:1)
あまりにも巨大な金額なので無駄な計算をしてみた (スコア:5, おもしろおかしい)
1999年、MATRIXの日本での興行収入が50億円 [wikipedia.org]。
無駄遣いで有名な大阪市の塩楽荘の29年間で膨れ上がった赤字額 [mbs.jp]が50億円。
Re:続き？ (スコア:2, おもしろおかしい)
給料くれないとこもある
人経費以外の金額もかなりの額かも？ (スコア:4, 興味深い)
ハードウェア、ソフトウェア、開発時に利用するIDCなどなどの代金も
入っているのでは？と思ってみたり。
業務系のDBやパッケージソフトは高いので、実際の人経費は6-7割程度かな？と
予想してみると35億円の人経費。この金額だと社内開発でも
損失としてありえる金額に思えます。。
# どちらにしろすごい金額だ^^;;;
Re:金額が… (スコア:3, 参考になる)
共同通信社の記事に「自社で進めていた」と書かれていたことが元 AC の言う「自社開発」の根拠なのかしら? 自社の社員だけにすべての作業を担当させていたとはどこにも書かれていないわけだけんども。
これだけ大きな失敗事例ならそのうち日経BP かどっかが取材して詳細レポートまとめてくれるでしょう。
いずれにせよ SNT さんの示してくれた数字は目安として十分参考になるものだと思いますよ。まぁ、下っ端開発者はそんなに高くはないけんども。
むらちより/あい/をこめて。
_・)ノ (スコア:2, おもしろおかしい)
_・)ノ
屍体メモ [windy.cx]
Re:_・)ノ (スコア:4, すばらしい洞察)
下っ端開発者自身が受け取る報酬はそんなに高くはないけんども
Re:_・)ノ (スコア:4, すばらしい洞察)
安易なAC発言反対運動中
Re:バグについて (スコア:2, すばらしい洞察)
一定規模以上で自明であるプログラムなど普通存在しない ので、それだと大規模プロジェクトの失敗は避け得ないと いう結論で終わってしまい、話が先に進まないのでは。
これら失敗に欠けていたのはバグフリー性ではなくて、
- 将来に関する検討
- （将来に備えられるシステムの）実現可能性の調査
- （万が一実現に失敗した場合の）予備プランの用意
ではないでしょうか。みずほは２を無視して３を考慮せず 面子で突っ走ったケース。東証は１といえば１ですが、 単に独占の上に胡坐をかいて投資をケチっただけですかね。余談ですが、みずほは大失敗だが、それも必要なことを やろうとしてであるという点で救いがある一方、自社の 唯一の存在理由自体を忘れ、すべきことを劣っていた 東証はいらんという他はありません。
まあ、最初から大規模なシステムを作ったり、既存の 大規模システムをいじるのは小ミスが直ちに大規模障害に 直結してしまうので本質的に難しいんですよね。別に 技術に限った話ではなくて、社会制度についても特区とか そういうスモールスタート制度があるのはそのため です（これまた余談）。
Re:TG-INET (スコア:3, 興味深い)
Re:TG-INET (スコア:2, 参考になる)
相当数の人数がつぎ込まれていたけど、人数だけ増やしてもシステム開発は成功しないっていう、教科書通りの…（以下略
Re:フレデリック・Ｐ・ブルックス，Jrの (スコア:2, 参考になる)
説明を自分で考えるのが面倒なので、ぐぐって
「本と音楽のクロスオーバー情報サイト ＳＭＡＲＴ」 [ocn.ne.jp]のページ [ocn.ne.jp]より
適切そうな部分を引用。
>◆『ソフトウェア開発の神話』フレデリック･Ｐ･ブルックスJr著、
>山内正彌訳、企画センター、昭和52(1977)/３
>(本書は絶版であるが、原著発行20周年記念増補版として、下記の
>書名で再刊されている)
>◆『人月の神話――狼人間を撃つ銀の弾はない』滝沢徹ほか訳、
>ピアソン･エデュケーション発行、星雲社発売、1996/２