スルガ銀行がIBMに対し，次期情報システムの開発を委託したが，プロジェクトが中止に至ったとして，多額の損害賠償を請求し，それらの請求の大部分が認められた事件。
事案の概要
簡単に事実経緯を整理すると次のとおり。
- 平成12年ころから，スルガは次期システムの要件洗い出し作業に着手し，途中からIBMが加わった。IBMは，システムの一部に金融系パッケージのCorebankを適用する方向で検討した。
- 平成16年3月，IBMは，スルガに対し，Corebankを活用したシステムを提案した。スルガは，他のベンダからも提案を受けたが，IBMの提案がよいと考えた。
- 平成16年9月，スルガは社内で初期費用約95億円（スルガ内人件費含む。）とするなどの予算で，次期システムの開発についての意思決定を行った。
- 平成16年9月，スルガとIBMとの間で「基本合意書」が交わされた。その基本合意には，「IBMの提案に基づいて95億円にて稼働を実現するよう確約する」などという内容が含まれていた。平成17年5月には最終合意が締結されることが予定されていた。
- 同日，計画・要件定義#1フェーズの契約が締結され（金額：約7億円，期間3カ月），正式にプロジェクトがスタートした。
- 平成16年12月，計画・要件定義#2フェーズの契約が締結された（金額35億円，期間9カ月）。このフェーズでは，現行システムとCorebankとのFit&Gap分析などが行われた。
- 平成17年9月，最終合意書が交わされた。その骨子には次の内容が含まれていた。
- 第1次経営システムとしてIBMに支払う総額で約90億円
- 損害賠償
- 損害賠償額の上限は，よくある個別契約の代金相当額を限度とすること
- 故意・重過失があるときは，個別契約の支払済み累計額とすること
- 個別契約が締結されるまでは，本合意に基づいて法的義務を負わない
- サービスイン予定 平成20年1月4日
- 平成17年10月，計画・要件定義#2の完了評価が行われ，制御・基盤の２つのグループについては*1，ほぼ当初のスケジュールどおりに進行した。
- 平成17年12月，IBMは，安定・成功裏にサービスインするためにはスコープの見直しが必要であるなどと申し入れた。
- 平成18年3月，残る業務グループの計画・要件定義#2の完了が確認された。その後，BRDと呼ばれる要件定義の実質的なやり直しが行われた。
- 平成18年9月になって，基本設計工程が開始された。
- 平成18年11月以降，IBMは，開発スコープの削減と，追加費用負担の提案を行い，当初スコープの実現には，追加で127億円，削減したスコープを前提として34億円の提案を行った。
- その後，平成19年5月ころにかけて，稼働時期を順次遅らせる提案や，追加費用を減少させる交渉などが行われた。途中で，IBMはCorebank以外のパッケージを採用する代替案も提案した。
- 結局，平成19年7月，スルガは最終合意と個別契約を履行不能による解除する旨の意思表示を行った。
- 平成20年3月，スルガは，IBMに対し，約111億円の支払を求めて提訴し*2，8月にはIBMから反訴請求（最終的に120億円余り）を行った。
ここで取り上げる争点
- 最終合意の拘束力
- プロジェクトが頓挫*3したことの責任の所在
- 賠償すべき損害の額
裁判所の判断
最終合意の拘束力
スルガは，最終合意書において，約90億円で本件システムを開発すると約束したのに，その義務を果たさなかったとして，この合意の債務不履行または不法行為を主張していた。そこで，最終合意書に記載されているスルガからIBMへの支払総額約90億円が，両者に法的拘束力を有しているかという点で問題となった。
この点につき，裁判所は，基本合意8条但書の，
各個別契約（第１条記載の個別将来契約を含むがこれらに限定されない。）が締結され、各関連個別契約の中で両当事者の各局面における義務が規定されるまでは、いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。
という記載に基づいて，個別契約が締結されることを前提として，支払総額の法的拘束力が生ずるとした。ただし，最終合意書には，将来締結される予定の個別契約（システムテスト等）が掲げられていたが，その大半が未締結であったことから，支払総額が法的拘束力を有するともいえず，これを前提とするスルガの主張は退けられた。
なお，最終合意に記載された90億円の意義については，
上記支払総額の規定が設けられたのは両当事者が目標とする重要な指針を定める趣旨であることは疑いのないところであり、本件最終合意書が交わされた平成１７年９月３０日の時点において、被告は、本件システム開発のコスト見積りの前提となる基礎数値を確定させて原告の支払金額を決めたものであることなどからすれば、上記支払総額の規定された本件最終合意書が交わされたとの事情が、被告の信義則上ないし不法行為上の義務違反の有無を考慮するに当たり意味を有し得るものであることを否定するものではない。
としており，最終合意書を交わしただけで「90億でシステムを完成させる義務」が即座に発生するわけではないが，信義則・不法行為上の義務を判断するにあたって意味を有することを示唆した。
プロジェクトが頓挫したことの責任の所在
スルガの主張の骨子は，IBMはシステム開発業者として，プロジェクトマネジメント義務を負っていたにもかかわらず，それを尽くさなかったために頓挫したというところにある。
そこで，裁判所はまず，本件のようなパッケージベースのシステム開発について，
本件のように、ベンダとユーザとの間でパッケージ型システム開発が行われる場合、パッケージの選定は、開発の対象となるシステムの根幹を成すものであり、その適切な選定、開発方法の採用は極めて重要な課題である。システム開発の専門家であるベンダは、パッケージの選定に当たり、パッケージの機能・性能、設定・導入の容易性、導入実績、パッケージの提供者の導入実績、経営の安定性、技術力、カスタマイズへの積極性その他関連する諸事情を考慮して、ユーザが構築しようとしているシステムに最適のパッケージを選定した上、これに適した開発方法を採用しなければならず、そのために、ベンダは、ユーザへの提案前に様々な観点からパッケージの機能、開発手法、リスク等について十分に検証又は検討しなければならないものというべきである。
加えて、それまで日本の銀行の基幹系のシステム開発において海外のパッケージが用いられたことはなかったのであり、しかも、被告は、製造業や流通業でのパッケージ・ベース・アプローチの経験はあるが、銀行のシステムをこの手法で開発した経験がなかったのであるから、被告としては、本件システム開発に当たって、より慎重に、パッケージの機能、開発手法、リスク等について検証又は検討し、適切な開発方法を採用しなければならないものというべきである。
と，ベンダであるIBMは，特に，銀行基幹系のシステムで海外パッケージを用いるというプロジェクトの特殊性に鑑み，パッケージの選定，リスクについて慎重な検証，検討する義務があるとした。
そして，パッケージ型システム開発では，パッケージのメリットを享受するために，要件定義の段階からパッケージの機能をベースに業務での実現を検討し，不可能な部分をギャップとしてアドオン開発するのが合理的であるところ，実際にIBMが要件定義で採用した手法は，現行システムの機能を基礎にして要件定義を進めたために，Corebankの利点を十分に享受できず，「ギャップ開発の量が不必要に増大してしまうことが避けられない」とした。そして，途中で，現行ベースの要件定義から，パッケージベースの要件定義にやり直しを行ったことなどから，「（IBMは）Ｃｏｒｅｂａｎｋを利用した場合の適切な開発方法についてあらかじめ十分な検証又は検討をしていたものということはできない」とした。
さらに，
- IBMのG専務がステアリングコミッティで「Corebankでどこまでやれるのか，IBMは分かっていなかった」と発言したこと
- IBM作成の書面に，コスト増大の要因として「Corebankの成熟度の見誤り」と記載されていたこと
- 平成18年になってからCorebankをJava化したものの，パフォーマンスが悪いことが判明したこと
- G専務が，スルガの専務に対し，プロジェクト頓挫の時期に「Corebankは日本の銀行諸制度に合致させるのは難しかった」「勘定系はCorebankでは難しい」などと説明したこと
- IBMの社長作成の書面やG専務の発言に「準備が不十分だったことは認識しています。開発手法の選択を誤ったのは事実です」旨があったこと
などから，
被告は、本件システム開発を開始するに当たり、Ｃｏｒｅｂａｎｋの機能や充足度、その適切な開発方法等についてあらかじめ十分に検証又は検討したものとはいえないし、また、本件システム開発を遂行するに際し、適切な開発方法を採用したものということもできない。
とした。ほかにも，IBMは，Corebankの改変権を有しておらず，パッケージベンダであるFIS社との間で十分な体制を気づいていなかったことや，IBMがそのような事実をスルガに適切に説明していなかったことが，スルガの信頼を損なうものであったとした。
また，プロジェクトマネジメントのその他の観点では，
- 最終合意書の約90億という金額は，IBMの「（見積の前提となるオンライン取引数やバッチジョブ数等が）ほぼ確定に近づいた」という経過報告に基づいて決定されたこと
- 最終合意締結後も，しばしばスルガとIBMとの間で，予算，期限は守れるのかといった話題が出たが，平成18年8月末時点までにおいて，特に異論は出ていなかったこと
- その間，スルガはIBMに対し，個別契約等に基づいて順次代金を支払っていたこと
に照らし，
原告としては、本件最終合意が締結された時点において、被告が提案した開発手法に従ったシステム開発に問題があるとは認識していなかったし、本件最終合意書で定められた原告の支払金額には相応の根拠があると信頼していたものというべきである。また、本件最終合意書が交わされた後、被告の提案した開発手法に誤りがあるとしてこれを変更する提案がされ、旧ＢＲＤ及び新ＢＲＤが行われたとしても、その経緯の中で、被告は、原告に対し、本件最終合意書の内容は両者間の合意であり、これを実現する方向で開発を進めるなどと述べ、本件最終合意書の内容を尊重する姿勢を表明していたのであるから、原告は、少なくとも、平成１８年８月に被告からサービスインの時期の修正について提案がされるまで、平成２０年１月に一斉切替えによるサービスインを行うことが無理であるとは考えていなかったし、また、同月に被告から追加費用の負担についての申出がされるまで、原告において追加費用の負担を考慮する必要はないと考えていたのである。そして、そのような認識の下で、上記各現行契約及び個別将来契約に基づく代金を支払ったものである。
と述べた。IBMが最後の最後になって，Corebankではなく，韓国IBMが開発したパッケージ「TCB」を提案したことについても，
被告がＣｏｒｅｂａｎｋによる基幹系のシステム開発を別のパッケージソフトウェアを利用して行うという代替案を提案する以上、その代替案は、完成時期や費用負担について十分な検証を行って成算がある、ないしは原告にとっても利益があるという確かな見通しが持てるようなものでなければ、原告にとって受け入れ難いものであることは明らかである。そうであるにもかかわらず、被告は完成時期や費用負担について十分な検証を済ませないままＴＣＢによることを原告に提案したのであり、そのこと自体、原告との信頼関係を失わせる根拠になるものということができる。
とされた。その結果，次のとおり，IBMのプロジェクト・マネジメント義務違反が認められた。
以上によれば、被告には、本件システム開発のベンダとして適切にシステム開発を管理することなどを内容とするプロジェクト・マネジメント義務の違反があるものというべきである。そして、上記の各事情に照らして考えれば、原告が、被告からＴＣＢの提案を受けた段階で、被告に対して本件プロジェクトを白紙に戻したいと伝えて本件プロジェクトを中止する決断をしたことについては、何ら非難に値するものではないし、むしろ、相応の根拠があるものということができる。そうすると、被告のプロジェクト・マネジメント義務違反により本件プロジェクトが頓挫したものであり、被告はこの点について責任を負わなければならないというべきである。
他方，ベンダが負うべき「プロジェクト・マネジメント義務」と対となる義務である，ユーザの「協力義務」については，
- スルガが資料すら満足に提供しなかったなどの証拠はなく，プロジェクト頓挫とは関連しない
- スルガが商品類・帳票類の削減を行わなかったということも認められない
などと，ことごとくIBMの主張は退けられ，最終合意記載の金額から一切妥協しなかったという点についても，
８９億７０８０万円という上記支払金額については、前記３（２）オのとおり、これが両当事者を法的に拘束するまでの効力を有しないとしても、両当事者が目標とする重要な指針を定める趣旨であることは疑いを入れないものというべきであり、しかも、被告は、旧ＢＲＤ及び新ＢＲＤを行っていた際、原告に対して本件最終合意書の内容を尊重する旨を述べ、原告から現行契約に基づく代金を受領していたのである。そうすると、そのような状況の下で、原告が本件最終合意書で記載された原告の支払金額８９億７０８０万円を強く主張したとしても、特段非難に値するものではなく、このことが原告の協力義務違反の根拠となるものとはいい難い
として，スルガにおいて「協力義務違反があった」という主張は退けられた。結局，責任の所在については，
本件システム開発が頓挫したことの責任はもっぱら被告にあるのであり、そのことについて、被告は原告に対してプロジェクト・マネジメント義務違反の責任を負うものというべきである。
と，IBMに責任の所在があるとした。
賠償すべき損害の額
最終合意書4条の，
各個別将来契約において、原告が被告の責に帰すべき事由に基づいて救済を求める全ての場合において、被告の損害賠償責任には契約責任、不法行為等の請求原因を問わず、（a）被告は、現実に発生した通常かつ直接の損害に対してのみ、損害発生の直接原因となった各関連する個別将来契約の代金相当額を限度額とし、かつ（b）被告は、いかなる場合にも、被告の責めに帰すことのできない事由から生じた損害、被告の予見の有無を問わず特別の事情から生じた損害、逸失利益、データ・プログラムなど無体物の損害、及び、第三者からの損害賠償請求に基づく原告の損害については、責任を負わない。」とされている。))。
金銭賠償の限度額にかかわらず、第１条記載の各個別将来契約の下で被告に故意又は重過失が認められる場合、第１条記載の各個別将来契約の下でのあらゆる請求ないし請求原因に係る被告による損害賠償総額は、損害発生時点において締結済みの現行契約及び個別将来契約における原告の支払済みの累計料金相当額とする。ある時点での賠償総額は、その時点までの各個別契約の下での支払総額に限定され、また、被告が既に賠償をしていた場合には、損害賠償総額からその支払額を差し引くものとする。
という責任限定条項については，法的拘束力を有するということが前提として確認された。
そして，スルガに生じた実損害のうち，IBMに支払った金銭について，
- 個別契約について支払った約49億円
- ハードウェア，ソフトウェア資産関係で支払った約37億円から，現にスルガが使用している資産の額を除いた約17億円
の合計をベースに，約65,5億円がスルガの損害だとした。
これに加えて，スルガが本件プロジェクトに関連して他のベンダに支払った金額から約8.6億円の損害も認めた。
なお，逸失利益約42億円の請求も行われたが，こちらは認められていない。
これらの損害に対し，IBMは損益相殺の主張として，再利用可能な成果物の客観的価値相当額の減額を求めたが，「要件定義書」「システム設計書」については，いずれも「客観的価値な価値を有するとはいえないものというべきである」などとして，減額の主張は認められなかった。
その結果，IBMはスルガに対し，不法行為に基づく損害賠償債務として約74億円の支払義務があるとし，IBMからの反訴請求はすべて棄却された。
若干のコメント
膨大な事実関係が記載されているので，そのすべてについて理解したわけではないのですが，結論だけ見ると，かなり一方的な印象を受けています。
平成16年東京地裁判決などにおいて認められてきた，ベンダの「プロジェクト・マネジメント義務」とユーザの「協力義務」については，当然の前提とされていますが，これまで債務不履行の文脈で用いられたことはあっても，本件のように不法行為として認められたケースは，私の知る限り，他にはありません。
本件で出てきた金額入りの「最終合意書」を締結するケースはあまり多くありません。多くの場合「基本契約」「個別契約」の組合せで進められますが，基本契約は，単なる契約条件の共通的なものを抽出してまとめただけであり，本件における「最終合意書」とは本質的に異なります（経産省のモデル契約も，ここでいう「基本契約」にあたります。）。私も，以前から，一定規模以上の開発を行う際には，本件のような全体金額，全体スケジュール等の要素を盛り込んだ「基本合意書」の締結をするようにアドバイスしていますが，今回，裁判所が，
支払総額の規定された本件最終合意書が交わされたとの事情が、被告の信義則上ないし不法行為上の義務違反の有無を考慮するに当たり意味を有し得るものであることを否定するものではない
と述べたことは心強く思っています。このような最終合意などで全体金額を記載しておくことは，ユーザのリスクヘッジだけでなく，プロジェクトのスコープを明記しておくことによって，ベンダ側も無用にスコープを拡大させられるリスクをヘッジできると考えられます。
本件で，重要視された事実としては，結局，日本で実績のなかったと思われるCorebankを銀行の勘定系に適用するというチャレンジングなプロジェクトであったにもかかわらず，パッケージの思想と離れた要件定義を行い，何度もやり直す羽目になった，という点にあるといえます。これまで，プロジェクト・マネジメント義務は，未決事項の管理・解決や，追加要望のコントロールの場面でよく出てきましたが，本件のように「パッケージの選定・検証」の場面でも適用されました。本件のようなプロジェクトが頓挫した事例におけるプロジェクト・マネジメント義務についての判断事例が一つ追加されたといえます。
本件を読むと，90年代にERPパッケージのブームが起きて，各主要ベンダが，海外の著名ERPパッケージを担いで導入を提案し，なかなかうまくいかず，ベンダ・ユーザともに痛手を被ったことが思い出されました。そうした失敗が積み重なったものの，結果として，今では大手企業の基幹業務システムにはほとんどERPパッケージが導入されていますが。
