システム開発が失敗する理由とは？
りばちゃん
「システム開発はなぜ失敗するのか？」について解説します。皆さんも、システム開発のプロジェクトで「思うように進まなかった」「失敗してしまった」といった経験があるのではないでしょうか？
今回は、特に大きく失敗した2つの事例をもとに、なぜ失敗したのか、そしてどうすればよかったのか私の考えを書きます。
事例①：駿河銀行 vs IBM 裁判
経緯
- 平成12年：駿河銀行がIBMに新経営システムの提案を依頼。
- 平成16年：総額95.5億円でプロジェクト開始、基本合意書を締結。
- 平成19年：IBMがパッケージソフト「コアバンク」の変更を提案。
- 平成20年：駿河銀行が東京地方裁判所にIBMを提訴。
- 平成24年：東京地裁がIBMに約74億円の支払いを命じる。
- 平成25年：東京高裁がIBMに約41億円の支払いを命じる。
- 平成27年：最高裁がIBMの上告を棄却し、判決が確定。
失敗の原因
- 海外製パッケージのリスク：日本の銀行が海外製パッケージを採用した前例がなかった。
- IBMの業界経験不足：IBMは製造業や流通業ではパッケージ開発の経験があったが、銀行システムでは未経験だった。
- プロジェクトマネジメント義務違反：IBMがパッケージの機能や開発手法を慎重に検討しなかった。
事例②：文化シャッター vs IBM 裁判
経緯
- 2015年1月：文化シャッターがIBMに新販売管理システムの提案依頼書の作成を依頼。
- 2015年3月：複数のベンダーから提案を受けた上でIBMを選定。
- 結合テスト50%の時点で770件の欠陥が発覚。
- IBMがカスタム開発を中止し、追加費用21億円と2年4ヶ月の期間延長を提案。
- 2017年11月：文化シャッターがIBMを提訴。
- 2022年6月：東京地裁がIBMに約19.8億円の損害賠償を命じる。
失敗の原因
- 旧システムにこだわりすぎた：文化シャッターが旧ホストコンピュータと同様の画面を維持しようとした。
- IBMの開発誘導ミス：標準部品への誘導が不十分。
- 要件定義の不備：設計・開発フェーズへと性急に進み、検証が不足。
失敗の共通点と教訓
1. パッケージベースの開発は慎重に
- 「業界特化パッケージ」があるからといって、自社に完全にフィットするとは限らない。
- 1%でもカスタマイズした時点で、もはやパッケージではなくなる。
- バージョンアップのたびにカスタム部分が動作するか検証が必要。
2. 開発誘導と合意形成が重要
- ユーザー側が「この機能が必要」と言っても、ベンダー側が安易にカスタマイズを引き受けると泥沼化する。
- パッケージ導入を決めた時点で「パッケージに合わせる覚悟」が必要。
3. 役員の鶴の一声は危険
- 役員同士の関係性で特定のベンダーが選定されるケースがある。
- システム選定は、知識や経験に基づいた合理的な判断が必要。
4. ユーザー側の理解と関与が不可欠
- ベンダーは業界の一般的な知識は持っているが、自社の業務プロセスを理解しているわけではない。
- ユーザー側が自社の業務や課題を正しく説明し、適切な提案を引き出すことが重要。
失敗を防ぐためにできること
1. ベンダー選びは「看板」ではなく「人」で判断
- 大手だから安心、ではなく、担当SEのスキルや経験を重視。
2. パッケージ導入時の覚悟を持つ
- 1%でもカスタマイズするなら、もはやパッケージではない。
- 「パッケージに業務を合わせる」覚悟を持つことが重要。
3. 役員の意思決定を見直す
- 役員の人脈や圧力で決まる選定は危険。
- システム選定は、現場の課題や将来のビジョンに基づくべき。
4. ユーザーが積極的に関与する
- ベンダーは業界知識は持っているが、各企業の業務の詳細は知らない。
- 自社の業務プロセスを整理し、適切な提案を受ける準備が必要。
まとめ
過去の失敗事例を振り返ると、最も重要なのは「ユーザーが主体的に動くこと」です。
近年はノーコードやローコードの技術が発展し、企業が自社でシステムを内製化することも可能になっています。「ベンダーに丸投げする」のではなく、自社の業務を理解し、最適なシステムを選定することが求められます。
