株式会社アイシーアイ

プロジェクト失敗の法則

2017年12月8日、京都市議会(京都市会)は門川大作市長名義で提出された京都市の基幹系システム刷新プロジェクト(COBOLのバッチ処理のマイグレーション)の遅延に対する訴えの提起を全会一致で可決した。

これによりITベンダーのシステムズ(東京・品川)は損害賠償など8億円の返還を求められる。この訴訟に対して、システムズ社は未払い作業費2億円の支払を求める訴訟を起こした。このIT訴訟ではベンダー側は「プロジェクトマネジメント(PM)義務」に、ユーザー側はベンダーに協力する「協力義務」に違反する行為がなかったかが争点になる。

入札にはNEC,キャノンITソリューションズなどが参加しており、京都市はもともと予定価格13億9719万6000円を見込んでいたが、その約79%に当たる大幅に安い11億376万円でシステムズ社が落札した。

このような開発プロジェクトでは、ベンダーのプロジェクトマネジメント能力の不足か、ユーザーのプロジェクトへの参加意識の欠如かが争われ、裁判に至らないものも含めると、しばしば起こるものであるが、裁判となると結審までに数年はかかる。

例えば、2008年にシステム開発プロジェクトの中止で損害を受けたとして、スルガ銀行は日本IBMに111億円の支払を求める訴訟を起こし、2015年に東京高等裁判所で日本IBMに42億円の賠償を命じた判決が確定した。こちらもスルガ銀行の基幹系システムを再構築すれば400億円かかる見通しであったものを、IBMが既存のパッケージシステムを手直しすることで、100億円で提案したものであった。

このような、ユーザーの思惑とベンダーのマネージメント能力不足の食い違いは避けられないものか。
下表にプロジェクトの失敗要因と対策を示す。

プロジェクト失敗の要因 ⇒ 対策・教訓
① 甘い見積り ⇒ 余裕を持ったスケジュールと見積り
② 途中経過での楽観的見通し ⇒ 定常的で冷徹な現場のレビュー
③ ユーザーのベンダー任せ ⇒ ユーザーを巻きこんだプロジェクト推進
④ 抜き差しならない時まで現状が把握できない ⇒ 白旗を揚げるの(悪い状態報告)は早めに
⑤ 現場と経営の情報乖離 ⇒ 経営は良い情報ほど疑う
⑥ ユーザーの要望をすべて受入れ ⇒ ユーザーの細かい要望は出来るだけ削る
⑦ 大雑把な契約内容 ⇒ 細かいところまで規定した契約

ほとんどのプロジェクトの失敗の原因と症状はよく似ているのである。それに早く気づいて手を打てるかが成否を決める。