裁判にまで至った、日本ＩＢＭとスルガ銀行
１．経緯
開発現場の実態を時系列で整理する
・ＮＥＦＳＳ／Corebank・・・次世代金融サービス・システム
Corebank・・・フィデリティ・インフォメーション・サービス（FIS）の
勘定系パッケージソフト
顧客単位で複数の口座を管理する
金融商品を組み合わせて素早く開発できる
・ＢＲＤ・・・BusinessRequirementDefinition（要件定義）
| 日本ＩＢＭ | スルガ銀行 | その他の情報 | ||
| ２０００年 | ９月 | 次期システムのあるべき姿を共同でまとめる | スルガ銀行からＩＢＭに対し、次期基幹系システムの提案を依頼する | |
| ２００３年 | ７月 | ＲＦＰを提示する 日本ＩＢＭ、富士通、日本ユニシス | ||
| ２００４年 | ９月 | 要件定義を開始する | 日本ＩＢＭ案を採用する ＮＥＦＳＳの導入決定 | ９５億円の基本合意書を締結する ２００８年１月のサービスインに向けてプロジェクトがスタートする |
| ２００５年 | ２月 | 不正会計が明るみに出る | ||
| ５月 | 最終合意書を取り交わす予定であった ＩＢＭの強い要望で９月に延期する | |||
| ９月３０日 | 最終合意書を取り交わす 開発コスト（８９億７千８十万円）、稼動時期（２００８年１月） | 駿河平にて | ||
| １２月 | 制御系と基盤系の要件定義は完了 業務系の要件定義は未完了 ＢＲＤの実施を提案する | ＢＲＤ実施を了承する | ||
| ２００６年 | ２月 | １回目のＢＲＤを開始する （実質は要件定義のやり直し） | ||
| ５月 | ２回目のＢＲＤを開始する （実質は要件定義の再度やり直し） | システム化の対象範囲が変わらないことを条件に了承する | ||
| ８月 | スケジュール変更を提案する （２００９年１月からの段階的稼動） | 拒否する | ||
| ９月 | スケジュール変更を提案する （２００９年５月までに４段階稼動） | 拒否する | ||
| １１月 | スケジュール変更を提案する （２００８年１２月末までに４段階稼動） | 了承する | ||
| １２月 | システム化対象範囲の大幅な削減と 追加費用４４億円を要求する | 拒否する | ||
| システム化対象範囲の削減量を減らし 追加費用２０億円を要求する | 拒否する | |||
| ２００７年 | ４月 | 勘定系パッケージソフトの変更を提案する | 拒否する | |
| ５月 | プロジェクトを白紙に戻すことを通知し 開発費用の返還を要求する | |||
| ７月 | 個別契約を債務不履行により 解除することを通知する | |||
| ２００８年 | ３月 | 反訴する 約１２５億５千万円 | 提訴する 合計１１５億８千万円 | |
| ＜裁判 継続＞ | ＜裁判 継続＞ | |||
| 争点１ | 合意書は法的契約ではない 確定額でシステム構築の 請負契約は結んでいない 個別契約を結び、全て履行している | 合意書に金額と納期が明示されている 請負契約であり、履行されていない | ||
| 争点２ | 開発すべき機能の確定はユーザー 最後までユーザが決め切れなかった ３０年以上前の固執し パッケージに合わせた業務改革を拒否した 現状を把握しておらず 把握作業に非協力的であった | |||
| 争点３ | 追加の選択肢を提案しただけ 一方的に契約を破棄した | 別のパッケージを提案したので 契約を破棄する | ||
| ２０１２年 | ３月２９日 | 提案・企画段階でのＰＭ義務違反を指摘される | 東京地方裁判所での裁判 IBMが控訴する | |
| ２０１３年 | ９月２６日 | 最終合意書を交わした段階でのＰＭ義務違反を指摘される | 東京高等裁判所での裁判 両者とも控訴する | |
| ２０１５年 | ７月９日 | 敗訴 ４１億７千万円及び遅延損害金を支払う | 勝訴 | 最高裁判所での裁判 両者の上告を棄却する |
２．裁判所での争点
東京地方裁判所では
ＩＢＭに対し、約７４億１千４百万円並びに遅延損害金の支払いを命じる
ＩＢＭのＰＭ義務違反を指摘する、
プロジェクトの企画・提案段階での機能検証が不足
これを見逃したとした
東京高等裁判所は
第一審判決を変更し、
ＩＢＭに対し４１億７千万円及び遅延損害金の支払いを命じる
ＩＢＭのＰＭ義務違反は
提案・企画段階ではなく、
要件定義を経て両社が最終合意書を交わした段階とした
賠償額を約４２億円に減額する
２００５年の段階で、
当初の開発範囲や期間では完成できないとＩＢＭは認識していた
開発を継続するなら、
開発費用、スコープ、期間のいずれかを抜本的に見直すか
開発そのものを断念するかを決定すべきだった
ＩＢＭがこの段階で抜本的な変更、
又は中止を説明・提言・リスクの告知をしていない
これがＰＭ義務違反に当たるとした
ＩＴベンダーには
ユーザーに対してＰｊｔの抜本的な見直し、
又は中止を提言する義務を負う
ユーザーに対して適切にリスクを説明するのは義務とした
３．裁判での双方の言い分
ＩＢＭ側からの言い分
・ＩＴベンダーだけにＰＭ義務を負わせるのは不当
ユーザー企業にも十分なリスク分析能力がある場合、といった前提で
スルガ銀行は優秀なＩＴ部門を持ち、
Pjt遂行に関わるリスクを分析する能力を備えていた
Pjtが危機的局面にあるという認識は両社で共有していた
・ＰＭ義務等を課される条件が曖昧である
最終合意書が締結された段階でPjtは危機的局面にはあったが
抜本的な見直しや中止の提言が必要な段階ではなかった
要件定義で明らかになった開発スコープの拡大は、
ＩＢＭの費用負担で賄える範囲だった
スルガ側からの言い分
・最終合意書の前に支払った費用も賠償額に認めるべき
ＰＭ義務違反など
ＩＢＭの不法行為が、プロジェクト失敗の原因と認めている
Pjt失敗が原因でスルガ銀の全支払い額が損失になった以上
不法行為とスルガ銀の全損害には、
賠償が認められるだけの因果関係がある
・パッケージ適用の問題
技術的にCorebankを邦銀に適用する事は可能とした点
大規模なカスタマイズなどで技術的に可能であるとしたことは
費用対効果を含めて可能であるとは限らない
教訓
見直し・中止の手続き整備を行う
想定と実態に大きな乖離があることが明らかになった際
すみやかに抜本的な見直しや中止を視野に入れた協議に入ることを
ＩＴベンダーとユーザー企業があらかじめ定めておく
４．裁判で明らかになった内容
２００４年に発表になった「新経営システム」の概要
投資額を１００億円弱にとどめる
勘定系と情報系と統合する
顧客に合わせて融資の利率や期間を柔軟に設定する
他行や証券・保険会社の金融商品を含む口座管理を行う
運用保守のコストを従来の４分の１にする
フィデリティ・インフォメーション・サービスの
勘定系パッケージソフト【Corebank】をカスタマイズするが業務の中心
懸念事項
パッケージソフト導入プロジェクトの特殊性
既に標準的なシステム機能を実装したシステムがあるために
どう業務で使いこなしていくかという視点で進めることになる
海外のパッケージを日本化する必要がある
パッケージソフトの導入は実際に動かしながら進めるのが普通
プロトタイプと呼ばれる初期設定バージョンを採用する
パッケージ機能に精通した担当者がシステム機能を説明しながら、
ユーザー側の業務に適合させる
失敗の原因
・ベンダ側がパッケージ機能を熟知していなかった
開発を開始するに当たり【Corebank】の機能や充足度、
その適切な開発方法等について、
あらかじめ十分に検証又は検討したものとはいえない、と結論付けた
・ユーザーの要求を理解できる業務知識と
利用するパッケージの構造を熟知している者を
プロジェクトに参加させることが必要であるにも関わらず、
技術者等の要員を配置していなかった
・パッケージソフトはカスタマイズが必要であるにも関わらず
ＩＢＭは【Corebank】の改変権を有していなかった
・カスタマイズに関して【Corebank】の権利者との間で
十分な協議が整っていなかったことを
ＩＢＭがスルガ銀行に説明していなかった
対応策はどうであったか
・ＩＢＭ側は提案するパッケージを知悉しておくべきことは必須であるが
そうでない場合は、リスクを開示し回避手段を策定・提案すべき
・ＩＢＭ側はパッケージの改変権を有していないことから
自由度がかなり制限されることを発注者に開示しておくべき
・スルガ側は自らリスク管理を行うべきであった
業務適合性、ソフトの改変権、ベンダーのプロジェクト参画について
事前に評価基準を定めておき、
それを元に評価・選択し、実現可能性を判断すべき
・スルガ側はリスク管理のスキルがない場合は
第三者の外部コンサルにＰＭのサポートを依頼してもよかった
５．結論
日本ＩＢＭ全面敗訴の深層
書面として残された証拠の重要性が浮き彫りになる
ＩＢＭは「営業秘密を保護するため」として判決書の閲覧制限を申立てる
東京地裁が「内容は営業秘密に当たらない」として却下、全文公開に至る
約２００ページの判決書から見えてくるのは、書面の証拠としての重み
双方の幹部によるステアリングコミッティーの議事録を証拠として引用
一方で法廷における日本ＩＢＭの証言はほとんど採用されなかった
東京地裁がなぜ日本ＩＢＭを「ＰＭ義務に違反した」とみなし、
スルガ銀は「協力義務に違反していない」と判断したのか
「Corebank」の採用に際してリスクに見合った検証をしなかった点
・邦銀が基幹系システムに海外製パッケージを採用した例がない
・日本ＩＢＭは他の業種ではパッケージベースの開発経験があるが、
銀行システムではこの手法で開発した経験がなかった
ITベンダーに
パッケージの機能、開発手法、リスク等について検証または検討し、
適切な開発方法を採用する義務があった
「リスクの検証または検討」と「適切な開発方法の採用」を怠った
・要件定義の迷走
日本IBMは当初、現行システムをリバースエンジニアリングする
現行踏襲型のアプローチで要件定義書を作成した
日本IBMはその後「開発手法に誤りがあった」として、
パッケージベースのアプローチである２回目の要件定義を実施
これも十分にパッケージベースの手法に沿っていないとし、
ＦＩＳ社員を交えたフィット＆ギャップ分析を軸とする
３度目の要件定義を実施する
・性能などの検証不足
プロジェクト終盤、
テメノス製パッケージ「TCB」を採用する代替案を提示した際、
「CorebankをJava化したもののパフォーマンスが悪いことが判明
「Corebankについて日本の銀行の諸制度に合致させることが
難しかったのは事実」などと述べていた
・ＦＩＳとの協力体制の整備不足
改変権を持つFISとの協業が不可欠だったにもかかわらず、
ＦＩＳとの役割分担、作業量、費用などについて
十分に検討した形跡がなかった
・不十分な情報開示
日本ＩＢＭはCorebankの採用に関する上記リスクを
スルガ銀に伝えていなかった
代替パッケージを提案する際にも
完成時期や費用負担について説明できなかった
東京地裁は議事録を基に以上の事実を認定、日本IBMがPM義務に違反していた
「強い疑念を抱いても不自然ではない状況が作り出された」とし、
スルガ銀がTCBの提案を受けた段階で
プロジェクトの中止を決断したことについては、
「何ら非難に値するものではない」と認定する