かつてのようにITベンダーが赤字覚悟で開発を請け負い、保守で赤字を取り返すという商習慣はなくなり、プロジェクト単体で採算性を求めるようになった。そうである以上、発注者側も受注者側も厳格な要求定義や工程管理、品質管理等のプロジェクト管理が求められるようになっている。決して目立たないが、ITに関わる訴訟は増え続けている。その原因はどこにあるのか、防止のためには何を行うべきか、また実際にトラブルになりそうな場合、なった場合には何をすればいいのか。シリーズ企画として、その対策を検討していく。第1回は、スルガ銀行と日本IBMの訴訟判決を取り上げる。
2012年、スルガ銀行とIBM訴訟判決(東京地判平24・3・29金法1952号111頁)がIT業界で話題になった。判決は日本IBMがスルガ銀行に対して74億円あまりの支払義務があることを認める、ほぼスルガ銀行の要求どおりの内容だ。
しかし、これは金銭面の話で、システム開発・稼働の遅れを取り戻せるわけではない。今回は、この訴訟から、企業が学ぶべき対策について述べる。
問題となったプロジェクトは、日本IBMが米フィデリティ・インフォメーション・サービス(FIS)の勘定系パッケージソフト『Corebank』を日本市場向けにカスタマイズする提案を行い、スルガ銀行がその採用を決断してスタートした。
その後、「要件定義」フェーズがスタートしたが難航。数回のやり直しを経た後、日本IBMが開発スコープの大幅削減提案や代替パッケージの採用と追加費用要求を行い、スルガ銀行が損害賠償を求めて訴訟に発展した。
ここでポイントになるのが、パッケージソフト導入プロジェクトの特殊性である。スクラッチ(手作り)開発の場合であれば、通常は、発注者側がどんな業務を遂行したいかを定義し、そのために必要なシステム要件を定義するという流れになる。
しかしパッケージソフトの場合は、すでに標準的なシステム機能を実装した“システム”があるため、そのシステムをどう業務で使いこなしていくかという視点で進めることになる。今回の場合さらに特殊なのは、海外のパッケージを今後日本国内に展開するために、ベンダー自らも投資して日本化したものを採用した点にある。
パッケージ機能を業務でどう使いこなしていくかを分析する工程は、周知のとおり「Fit&Gap」と呼ばれる。プロトタイプと呼ばれるパッケージソフトの初期設定バージョンを用いるか、あるいはパッケージ機能に精通した担当者がシステム機能を説明しながら、ユーザー側の業務に適合するかを検討したり、実際に業務遂行をシミュレーションしたりして進めていく。
パッケージソフトを導入するメリットのひとつは、標準的な機能を実装したシステムを採用することにより、稼働までの期間とコストを削減することにある。当然、それは業務とパッケージの機能がある程度”Fit(適合)”していることが前提となる。もともと海外で展開されていたパッケージソフトを国内に持ち込んだ今回のケースは、相当のGap(不適合)があることを想定に入れておく必要があったはずである。
この点に関して、IBMは当初、現行業務とシステムをそのままパッケージで実現する方向での検討から、その後、パッケージ標準機能に合わせるように方向転換している。“Gap”(不適合)がかなり大きかったからであるが、結局、この方向転換はうまくいかず、代替パッケージの採用と追加費用の要求がIBMから出された。この要求は、スルガ銀行の想定と異なっていた。
●Next:見解の大いなる相違、根本の原因はどこに?
会員登録(無料)が必要です
- 1
- 2
- 3
- 次へ >
- 訴訟事例から学ぶパッケージソフト導入時の注意点(2014/09/19)
- 簡易なシステムのリスク回避(2014/07/07)
- システム開発会社のスキル不足にどう対処すべきか(2014/06/13)
- ベンダーによるオーバーコミット(過剰な提案)と 発注者の“相手任せの姿勢”が訴訟を招く(2014/01/15)
- データ移行の失敗で、業務システムが使い物にならない!(2013/11/21)