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