IT関連トラブルを検証する日経コンピュータのコラム「動かないコンピュータ」から、裁判に発展した事例を再録しました。本記事は、日経コンピュータ2012年6月7日号の「動かないコンピュータ」です。

なぜ10対0なのか―。実質的に日本IBMの全面敗訴となった「スルガ銀―IBM裁判」第一審判決の判決理由が明らかになった。東京地方裁判所の判断を左右したのは、両社幹部によるステアリングコミッティーの議事録だった。書面として残された証拠の重要性が改めて浮き彫りになった。

　勘定系システムの開発が失敗した責任を巡り、スルガ銀行と日本IBMが互いを訴えたスルガ銀―IBM裁判。2012年3月29日に東京地方裁判所が下した判決は、日本IBMの責任をほぼ100％認定する内容だった。本誌5月24日号で報じた通り、その理由を示す判決書が5月中旬にようやく公開された。

　日本IBMは「営業秘密を保護するため」として判決書の閲覧制限を申し立てていたが、東京地裁が「内容は営業秘密に当たらない」として申請を却下、判決書の全文公開に至った。

　約200ページの判決書から見えてくるのは、書面として残された証拠の重みだ。判決に先立つ「事実認定」では、スルガ銀と日本IBMの幹部によるステアリングコミッティーの議事録が証拠として多数引用された。一方で法廷における日本IBMの証言はほとんど採用されなかった。IT訴訟に詳しい弁護士は「両社の印が押された書面が大量にある以上、裁判所が証拠として優先して採用するのは当然だ。この事実認定に基づくなら、日本IBMは全面敗訴にならざるを得ない」と話す。

　東京地裁がなぜ日本IBMを「プロジェクトマネジメント（PM）義務に違反した」とみなし、スルガ銀は「協力義務に違反していない」と判断したのか。東京地裁が認定した事実を基に解説する。

リスクに見合った検証をせず

　東京地裁はまず、日本IBMがスルガ銀に提案した米フィデリティ・インフォメーション・サービス（FIS）の勘定系パッケージ「Corebank」には、二つのリスクが存在していたと指摘する。一つは、邦銀が基幹系システムに海外製パッケージを採用した例がなかったこと。もう一つは、日本IBMは製造業や流通業の分野ではパッケージベースの開発経験があるが、銀行システムではこの手法で開発した経験がなかった点だ。東京地裁は、日本IBMがITベンダーとして「慎重にパッケージの機能、開発手法、リスク等について検証または検討し、適切な開発方法を採用」する義務があったとした。

　では、日本IBMはなぜ「リスクの検証または検討」と「適切な開発方法の採用」を怠ったと判断されたのか。東京地裁が重視した事実は四つある。

　第一に、要件定義の迷走だ。日本IBMは当初、現行システムをリバースエンジニアリングする現行踏襲型のアプローチで要件定義書を作成した。だが、日本IBMはその後「開発手法に誤りがあった」として、パッケージベースのアプローチである2回目の要件定義を実施。だが、これも十分にパッケージベースの手法に沿っていないとし、FIS社員を交えたフィット＆ギャップ分析を軸とする三度目の要件定義を実施した。

　第二に、性能などの検証不足だ。日本IBMがプロジェクト終盤、スイスのテメノス製パッケージ「TCB」を採用する代替案を提示した際、「CorebankをJava化したもののパフォーマンスが悪いことが判明した」「Corebankについて日本の銀行の諸制度に合致させることが難しかったのは事実」などと述べていた。

　第三に、FISとの協力体制の整備不足だ。Corebankの改変権を持つFISとの協業が不可欠だったにもかかわらず、日本IBMはFISとの役割分担、作業量、費用などについて十分に検討した形跡がなかった。

　第四に、不十分な情報開示だ。日本IBMはCorebankの採用に関する上記リスクをスルガ銀に伝えていなかった。代替パッケージを提案する際にも完成時期や費用負担についてスルガ銀に説明できなかった。

　東京地裁は議事録を基に以上の事実を認定、日本IBMがPM義務に違反していたとした。さらに、スルガ銀が日本IBMに対して「強い疑念を抱いても不自然ではない状況が作り出された」とし、スルガ銀がTCBの提案を受けた段階でプロジェクトの中止を決断したことについては、「何ら非難に値するものではない」と認定した。