ニュース記事: 2006年2月アーカイブ
東証が誤発注を取り消せない不具合の調査結果を発表、「富士通にも責任がある」
きっと契約書や仕様書に『富士通の責任』を発見した担当者は、鬼の首をとったように喜んだことでしょう。
東証は富士通に損害賠償請求をすべきでしょうか？ メリット、デメリットをあげてみました。
【損害賠償のメリット】
・金銭的利益 (勝訴メリット)
・障害の東証責任が減少
・障害原因の追究がうやむやにならない
【損害賠償のリスク】
・訴訟費用 (敗訴リスク)
・訴訟に関わる社内リソースの投下
・システム不具合がいつまでも報道される
・ベンダーから東証プレミアムを高く設定される
メリットに比べてリスク要素が強く感じられます。リスクの中で特に強いのが、社内リソースの投下とベンダーからの東証プレミアムです。
訴訟が高裁までいくとして2年間の間、経営会議には毎度訴訟の進捗が報告される時間が費やされます。本来なら他の建設的な議題について検討できたはずの経営資源を裁判に投下することになります。きっと社員の中でもそれなり優秀な方が訴訟のためだけに数人割り当てられて働くことにもなるでしょう。
また、SIベンダーからは「東証との契約は損害賠償のリスクも加味して契約金額を定めよう」という雰囲気が生まれます。銀行システムが停止しても賠償請求が発生したという話は聞きません。あっても水面下でこっそりやっています。(「来期の保守料金は3か月分無料にしてよ、ははははっ」)
SIベンダーから怨まれるということの怖さを東証が理解しているのでしょうか。銀行システムよりも信頼性の高いシステムを(効率的な価格と期間で)構築できるベンダーは日本に数えるほどしかありません(100兆円、100年かけてよいのなら誰でもできます)。
ですから、「高すぎる、値引いてくれないなら他に頼む」と交渉する余地がないのです。今回の事件で富士通にしたように「東証は運営コストを半分にするから、これまでの半分の費用でシステム構築してくれ」と上から指定することができなくなってしまったことにまだ気づいてないのかもしれません。
以上のように対内的にも対外的にも大きなリスクがあります。東証が損害賠償請求を実施するか否かは、「支払う対内・対外コストに比してシステムの堅牢性を向上させることができるか」という軸で判断するのがよいでしょう。
システム堅牢性とは最終的には関わる人にたどり着きます。東証社員にもベンダーにも『第一にシステム堅牢』という意識が他の方法に比べて高くすることができるのなら損害賠償請求をおこなうべきです。これを判断できるのは東証内部の状態を知る経営陣だけです。
東証の鈴木義伯CIO
外部の仕事を請ける際に一番怖いのは納期です。
納期に遅れることは顧客に迷惑をかけ信用を失うばかりか、余計にかかった開発日数分のコストを背負うことになります。まともなプロジェクトマネージャならスケジュール管理を主軸にプロジェクトコントロールをするものです。
さて、東京ガスで60億円の開発失敗による特別損失が計上されました。
東京ガスは、同社とガス器具を販売・修理する協力企業の管理システムを統合する作業を２００３年に始めた。費用を削減するため、市販の汎用（はんよう）業務用ソフトを使って自社で進めてきたが、顧客情報の検索などに時間がかかりすぎて、システムが使いものにならなかった。 当初予定（３０億円）の倍の約６０億円を投じ、統合時期も０４年１０月から遅らせたが、最終的に自社開発をあきらめた。費用のうち他に転用可能な機器など１０億円分を除く約５０億円を、０６年３月期連結決算で特別損失として処理する。 顧客管理システム開発失敗、東京ガスが損失５０億円 （Yomiuri Online)
2年間で60億円！
200万円/月クラスのSEを125人雇えます。機器代金、ソフトウェアライセンス代金が2割必要としても100人のSEが参加できる規模です。失敗の原因はどこにあったのかわかりませんが、報道されている情報からひとつだけはっきり言える事があります。
自社開発を試みたことによる失敗
・・・です。東京ガスのIT業務は100％子会社のTG情報ネットワークによって管理されています。社員数約450人(出向者70名程度)の会社です。
当然ですが今回の案件もこの会社によって管理されていました。しかし、TG情報ネットワークの導入事例をみてみると、大規模な基幹システムって作ってないんですよ。まあ、報道発表したような案件以外を公開するわけにはいきませんから事例としてのらないかもしれませんが、正直あまりレベルが高いとはいえません。
さて、記事で『市販ソフト』とある点が気になります。最初はSAPのR/3かなぁ・・・と思っていたのですが、少ししらべてみるとSiebel のCRMらしいです。
この手のCRMパッケージは経験のない会社がつかえる代物ではありません。
機能を一通り把握するだけで軽く半年かかります。Siebelでの開発を10件程度つんだリーダー格のSEが5人くらいの中堅Siebel経験者を部下に持って設計する・・・というのでしたら安心して任せられますが、TG情報ネットワークのHPを見る限りSiebelはあまりお得意ではないように見えます。
「パッケージソフトの機能を使えば自社開発できる！」
と判断した東京ガスのCTOとTG情報ネットワークの営業担当が今回の戦犯と言えるのではないでしょうかパッケージを利用するかどうかの判断は実は相当難しいのです。理想論になりますが、業務分析をおこなって機能仕様を組み立ててからでないと、実装のために使うプラットフォームは選べません。暴論かもしれませんが、基本的なベストプラクティスに関する知識のある検討チームが機能仕様のインタビューに3ヶ月以上かかる案件では業務パッケージは使かわないほうが無難です。
一日に一部署インタビューをして、約60のステークホルダーがいるような案件にベストプラクティスがそのまま適用できるわけがありません。(60のステークホルダーにベストプラクティスにあわせた形に業務形態を変更するように強要できるのならよいのですが・・・)
会社の業務をIT化する最大の目的はコストの削減ですから、業務形態の見直しも含むのは当然なんですが、既存部署が全体としてのコスト削減意識がないと社内調整ができませんからね。こういうときに経営陣のお墨付きをもらった経営コンサルが社内調整をして、内外の開発部門が実施を担当するという構成になっていると目的軸がぶれないんですけどね。まあ後の祭りです。
ちなみにITコンサルはこの会社がどっぷりと入り込んでいるようですね。
この流れのOpenⅣにあたるのが今回の破棄プロジェクトなのではないかと、外部情報から推測しています。・・・・これ以上は友達をなくしたくないのであまり調べないことにします。
