スルガ銀行vs日本ＩＢＭ（２）

裁判にまで至った、日本ＩＢＭとスルガ銀行
　　開発現場の実態を開発業務を中心に整理する

２００４年に発表になった「新経営システム」の概要
　　投資額を１００億円弱にとどめる
　　勘定系と情報系と統合する
　　　　顧客に合わせて融資の利率や期間を柔軟に設定する
　　　　他行や証券・保険会社の金融商品を含む口座管理を行う
　　運用保守のコストを従来の４分の１にする

フィデリティ・インフォメーション・サービスの
　　勘定系パッケージソフト【Corebank】をカスタマイズする、ことが業務の中心となる

　　懸念事項
　　　　パッケージソフト導入プロジェクトの特殊性
　　　　　　既に標準的なシステム機能を実装したシステムがあるために
　　　　　　そのシステムをどう業務で使いこなしていくかという視点でプロジェクトを進めることになる
　　　　海外のパッケージを日本化する必要がある

　　パッケージソフトの導入は実際に動かしながら進めるのが普通
　　　　プロトタイプと呼ばれるパッケージソフトの初期設定バージョンを用いたり
　　　　パッケージ機能に精通した担当者がシステム機能を説明しながら、ユーザー側の業務に適合させるか

　　失敗の原因
　　　　・ベンダ側がパッケージ機能を熟知していなかった
　　　　　　開発を開始するに当たり【Corebank】の機能や充足度、その適切な開発方法等について
　　　　　　あらかじめ十分に検証又は検討したものとはいえない　と結論付けた

　　　　➀ユーザーの要求を理解できる業務知識と利用するパッケージの構造を熟知している者を
　　　　　　プロジェクトに参加させることが必要であるにも関わらず、技術者等の要員を配置していなかった
　　　　➁パッケージソフトについてカスタマイズが必要であるにも関わらず
　　　　　　ＩＢＭは【Corebank】の改変権を有していなかった
　　　　➂カスタマイズに関して【Corebank】の権利者との間で十分な協議が整っていなかったことを
　　　　　　ＩＢＭがスルガ銀行に説明していなかった

　　対応策はどうであったか
　　　　・ＩＢＭ側は提案するパッケージを知悉しておくべきことは必須であるが
　　　　　　そうでない場合は、リスクを開示し回避手段を策定・提案すべきであった
　　　　・ＩＢＭ側はパッケージの改変権を有していないことから
　　　　　　自由度がかなり制限されることを発注者に開示しておくべきだった
　　　　・スルガ側は自らリスク管理を行うべきであった
　　　　　　業務適合性、パッケージソフトの改変権、パッケージベンダーのプロジェクト参画等について
　　　　　　事前に評価基準を定めておき、それを元に評価・選択し、実現可能性を判断すべきであった
　　　　・スルガ側はリスク管理のスキルがない場合は
　　　　　　第三者の外部コンサルにＰＭのサポートを依頼してもよかった

　　
　　裁判の結果は「裁判になるシステム開発（１）」を参照