2008年3月、スルガ銀行は日本IBMを訴えた。システム開発頓挫の責任をベンダーとユーザーが押しつけ合う。ベンダーのマネジメント義務違反か、ユーザーの協力義務違反か。最高裁にまでもつれ込む訴訟から、我々は何を学ぶべきか。
本連載では、主にIT企業に関連する裁判例や近時のトピックを取り上げ、IT企業が法務面で留意すべき事項を指摘していく。第1回は、著名事件である「スルガ銀行 vs 日本IBM」事件の高等裁判所判決を見ていこう。本連載では紙幅の都合上、事案や判旨をかなり省略することが出てくるが、ご容赦願いたい。
2008年から今も続いている、スルガ銀と日本IBM（以下、IBM）の訴訟。一言で言えば両社が契約を結んだシステム開発プロジェクトが頓挫した原因がどちらにあるのかということを争い続けている。
スルガ銀はベンダーであるIBMが果たすべき義務、つまり高度な専門的知識と経験に基づいて開発作業をマネジメントしなければならない「プロジェクトマネジメント義務」の違反が原因と主張。対するIBMはシステム開発はあくまでもベンダーとユーザーの共同作業であり、ユーザーもまた開発に必要な協力をすべきという「協力義務」の違反が原因と主張している。
最初に訴えたのはスルガ銀だ。IBMに対して既に支払った業務委託料及び損害など、合計約115億円の支払いを求めて提訴した。これに対し、IBMは業務委託料の残代金など、合計約125億円の支払いを求めて反訴している。
第一審の判決では、スルガ銀の主張が認められた。IBMに対し、システムが完成していれば得られていたとする利益を除き、スルガ銀が支払った金額全額の約74億円の支払いを命じた。
そもそもプロジェクトが頓挫した原因は、本判決によれば「Corebank」というアプリケーションパッケージにあるようである。この製品は海外の銀行でこそ稼働実績があったものの、邦銀で使用されたことは無かった。
IBMはこのCorebankを用いた新システムをスルガ銀に提案し、スルガ銀もまたこれを了承した。だが、計画・要件定義が進むにつれ、暗雲が立ち込め始める。スルガ銀が現行システムに実装していた機能と、Corebankの持つ機能にギャップがあることが徐々に判明してきたからだ。
断念か、見直しか、継続か
最終合意締結のころには当初予定していた開発費用と開発スコープ、および開発期間内に収めてシステムを開発することが不可能であることが分かってきた。抜本的に開発計画を見直すか、開発そのものを断念しなければならない局面に陥った。だが、その後、両社はシステム開発を推進する最終合意書を締結。結果、プロジェクトは頓挫し、訴訟につながってしまった。
本判決はIBMが主張するスルガ銀の協力義務違反を一切、認めなかった。その上で、IBMが負うべき責任に関して二つの観点から見解を示した。
一つは、IBMがCorebankを用いた新システムを選択して提案した責任、もう一つは、計画・要件定義を進める中で抜本的な見直しが必要だった局面にもかかわらず、最終合意を締結してさらに進めようとした責任だ。
前者の責任についてはIBMの義務違反はないとされた。企画・提案の段階でもベンダーにはプロジェクトマネジメント義務がある。だが、ベンダーはユーザーの業務内容に精通しているわけではない。
こうした状況を考えれば、スルガ銀もまた自らリスク分析をすることが求められるべきで、かつ、軌道修正があり得ることは当然想定されていたことだと裁判所は判断した。
開発中止を提言すべきだった
一方、後者の責任についてはIBMの過失を認定した。裁判所は、ベンダーが負うべきプロジェクトマネジメント義務の具体的内容として、システム開発の遂行過程における「局面に応じて、ユーザーのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務を負う」とした。
その上で、両社が結んだ最終合意は、既に抜本的な見直しなどが必要な状況で締結されたため、IBMには「ベンダとして、この段階以降の本件システム開発の推進を図り、開発進行上の危機を回避するための適時適切な説明と提言をし、仮に回避し得ない場合には本件システム開発の中止をも提言する義務があった」と判断したわけだ。
IBMのプロジェクトマネジメント義務違反を認めた本判決は、最終合意締結以降にスルガ銀に生じた業務委託料および損害などの合計約41億円の支払いを命じた。現在、本件は最高裁判所に係属中だが、最高裁は原則として法律論のみを判断し、事実認定は行わない。事実認定が原則として本判決のままとなることからすれば、結論の大枠が変わる可能性は低そうだ。
このケースを冷静に見ると、銀行の役員が既存融資先に対する既存貸し付けが焦げ付いていることの発覚を恐れて、回収不能であることを認識しながら、さらに追加融資をしたという事案や、事業会社の役員が数年前に立ち上げたプロジェクトの失敗が明らかになることを恐れて、利益化の見込みが全くないまま事業を続けたという事案と類似している。こういった裁判例はあまた存在している。
こうした観点からこの事案を見れば、ベンダーは、局面を冷静に判断し、傷を広げないうちに、自らが提案した方針の転換を示唆する勇気を持たねばならない。本判決は、地裁判決とは異なり、結果的に適合しなかったアプリケーションを企画・提案の段階で選択し、提案したことについてベンダー側の責任を認めていない。裁判所は企画・提案の段階で、ベンダーが完全な提案ができないことについて、ある程度の理解を示している。ベンダーはこの点を認識しておくべきだ。
ユーザー側にとっての教訓は何か。本判決は、事実認定に際して、本件プロジェクトの進捗管理や協議などのために両社が開いた委員会組織の議事録の内容を多く引用している。協力義務の履行の証明には、日頃から、議事録を正確に記載したほうがよい。なお、本判決では議事録でIBMが謝意や謝罪的言辞を述べていることについて、落ち度があった事実を推認させる根拠にはならないとした。ビジネス上の関係性からすれば、ベンダーが、結果として円滑に進んでいないプロジェクトで謝意を示すことは当然。この点でも、裁判所は一定の理解を示したと言えるだろう。
弁護士／二重橋法律事務所
