スルガ銀行が日本IBMに対し，開発を委託した情報システムが完成しなかったとして損害賠償を求めた事件の控訴審判決。
事案の概要
前提となる事実は，ほぼ原審どおりなので，そちらを引用するとして，おおざっぱにまとめると次のとおりである。
スルガとIBMは，スルガの銀行業務全般を処理する「新経営システム（本件システム）」の構築に関する基本合意及び個別契約を締結して，本件システムの開発を目指したが，途中で中止となった。
本訴は，スルガが，IBMに対し，開発中止になったことについて，IBMに
- (1) Corebankを使用して平成20年1月までに総額約90億円で本件システムを開発させる義務違反があった，
- (2) プロジェクト・マネジメント義務違反があった，
- (3) 説明義務違反があった，
- (4) 個別契約はいずれも錯誤により無効であった，
と主張し，請負契約の債務不履行又は不法行為に基づく損害賠償請求権（(1)ないし(3)），あるいは不当利得に基づく原状回復請求権（(4)）を請求原因として総額約115億円の支払いを求めた事案である（反訴請求については割愛する。）。なお，スルガの主位的主張は不法行為に基づく損害賠償請求であり，予備的に債務不履行責任等を主張するよう，控訴審において請求原因が整理された。
原審（東京地判平24.3.29）では，スルガの本訴請求を不法行為に基づく損害賠償責任として，74億円余りの支払いを認容した。これは，逸失利益等を除外したものの，スルガからIBMに支払われた委託料のほぼすべての返還を認容するものだった。
ここで取り上げる争点
（１）不法行為上のプロジェクト・マネジメント義務違反の成否
（２）契約上のプロジェクト・マネジメント義務違反の成否
（３）スルガの損害額，損益相殺，過失相殺
裁判所の判断
議事録に基づく事実認定について
原審もステアリング・コミッティの議事録に基づいて作業・交渉等の経緯が認定されていたが，この点について，IBMは「議事録の記載内容はスルガから修正を加えられたものであり，作業等の実態を必ずしも反映していない」と批判していた。この点について裁判所は，
ステアリング・コミッティは，本件システム開発の上級マネジメントレベルでの意思決定を行う目的で設定されたものであり，スルガ及びIBMの双方から本件システム開発の実施責任者が参加し，その総合評価，スケジュール・作業進捗の実績・課題の共有，重要課題の意思決定等を行うものであった。そして，そこで議論された要点については，会議の翌々営業日の午前中までにIBMが議事録を作成し，議事録データベースに登録し，同議事録によって会議の最終的な決定事項を記録化することとされていた。
（略）
特にIBMはシステム開発を業とする者であり，このような議事録作成の意義と方法を当然熟知していたものといえる。したがって，確定した議事録は，ステアリング・コミッティの作業実態を反映するものとして取り扱うのが相当である
と，本件で議事録を重視して事実認定するという方針に変わりはなかった。Business Law Journal 2013年7月号にて拙稿「システム開発プロジェクト推進中の法的留意点 会議の運営とその記録の保存を中心に」が掲載されたが，そこでも会議体の位置づけ，議事録確定までのプロセスが重要であると述べた。控訴審判決でも，その点が確認されている。
不法行為に基づく請求と債務不履行に基づく請求との関係について
原審では，不法行為に基づく損害賠償責任という構成で多額の損害賠償責任を認めた。システム開発紛争という契約関係を前提とした紛争で不法行為責任を認めることにつき，詳細な説明もなかったことから違和感があったが，この点について控訴審では次のように述べた。
本件においては，前記のとおり，IBMとスルガの間には，各基本合意及び各個別契約が締結されているから，損害賠償責任の成否及びその範囲を考えるに当たっては，まず契約内容を合理的に解釈することを要するというべきである。また，訴訟においては，当事者の主張の構成に沿ってその当否を判断すべきものであり，本件のスルガのように，両立しうる請求権について順序を付けている場合においては，その主張の構成に沿ってその当否を判断するのが相当である。そこで，当裁判所は，損害賠償を求めるスルガの請求原因の構成に沿って，契約締結前においては，契約がないことを前提に，契約締結後については，不法行為を主張する請求は不法行為規範に照らし，契約責任を主張する請求は当事者間で締結された契約内容及び契約法理に照らし，それらの責任の成否及び範囲について検討することとする。
（略）
IBMは，契約当事者間において不法行為責任が生じるのは，契約の有効性が否定されるような自己決定権の侵害があった場合，詐欺のように相当程度の違法性がある場合等に限定されるとし，本件においては契約責任を前提として審理判断されるべきである旨主張する。しかし，契約当事者間においても，損害賠償責任の根拠として，実体法上，契約責任と不法行為責任が競合し得るものであり，この場合に，IBMが主張するような違法性があるときに限って不法行為責任が成立するとの実体法上の根拠はなく，また，そのように不法行為責任の成立が限定されると解することはできない。
と，あくまで請求権競合の問題として，当事者の判断にゆだねる立場に沿って審理判断することとしている。
争点に対する判断枠組みについて
裁判所は，本件の判断にあたり，本件システム開発の経緯が次の4段階に分けられるとして，それぞれの段階におけるプロジェクト・マネジメント義務違反の存否について判断している。
I 企画準備から本件基本合意?締結前の段階（企画・提案）
II 本件基本合意?締結から本件基本合意?締結前の段階（計画・要件定義）
III 本件基本合意?締結から本件最終合意締結前の段階（計画・要件定義）
IV 本件最終合意締結から本件システム開発終了の段階（計画・要件定義，実装）
Iの段階におけるプロジェクト・マネジメント義務違反の有無について
裁判所は，Iの段階では，不法行為は成立しないとした。その理由は，かなり長くなるが引用する。
?の段階においては，IBMが，自社が提案するシステムの特徴等を説明し，競合する他社のシステムと比較した優位性を強調するなどして，スルガから受注を取り付け，開発に関する契約を締結しようとする段階といえる。
企画・提案段階においては，プロジェクトの目標の設定，開発費用，開発スコープ及び開発期間の組立て・見込みなど，プロジェクト構想と実現可能性に関わる事項の大枠が定められ，また，それに従って，プロジェクトに伴うリスクも決定づけられるから，企画・提案段階においてベンダに求められるプロジェクトの立案・リスク分析は，システム開発を遂行していくために欠かせないものである。そうすると，ベンダとしては，企画・提案段階においても，自ら提案するシステムの機能，ユーザーのニーズに対する充足度，システムの開発手法，受注後の開発体制等を検討・検証し，そこから想定されるリスクについて，ユーザーに説明する義務があるというべきである。このようなベンダの検証，説明等に関する義務は，契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務として位置づけられ，IBMはベンダとしてかかる義務（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる。もっとも，ベンダは，システム開発技術等に精通しているとしても，システム開発の対象となるユーザーの業務内容等に必ずしも精通しているものではない。企画・提案段階における事前検証を充実させることにより，システム開発構想の精度を高め，想定外の事態発生の防止を図り得ると考えられるが，受注が確定していない段階における事前検証等の方法，程度等は自ずと限られ，ユーザー側の担当者等から得られる情報や協力にも限界があることは明らかである。そのため，プロジェクトが開始され，その後の進行過程で生じてくる事情，要因等について，企画・提案段階において漏れなく予測することはもとより困難であり，この段階における検証，説明等に関する義務も，このような状況における予測可能性を前提とするものであるというべきである。その意味では，ベンダとユーザーの間で，システム完成に向けた開発協力体制が構築される以前の企画・提案段階においては，システム開発技術等とシステム開発対象の業務内容等について，情報の非対称性，能力の非対称性が双方に存在するものといえ，ベンダにシステム開発技術等に関する説明責任が存するとともに，ユーザーにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ，システム開発について自らリスク分析をすることが求められるものというべきである。
このようなことからすると，企画・提案段階におけるシステム開発構想等は，プロジェクト遂行過程において得られるであろう情報，その過程で直面するであろう事態等に応じて，一定の修正等があることを当然に想定するものといえ，企画・提案段階の計画どおりシステム開発が進行しないこと等をもって，直ちに企画・提案段階におけるベンダのプロジェクト・マネジメントに関する義務違反があったということはできない。すなわち，企画・提案段階におけるIBMのプロジェクト・マネジメントに関する義務違反の存否については，前記説示した点を考慮して検討することを要するものというべきである。
すなわち，ベンダとして，企画・提案段階においても各種説明義務等を含むプロジェクト・マネジメント義務を負うとしつつも，ベンダ自身もユーザについて十分な情報を得ていないことから，当該義務にもおのずと限界があることを示している。
そして，本件への当てはめについては，次のような事実を骨子として，義務違反はないとした。
- 本件システムは，これまでの邦銀の勘定系システムとは異なる特徴を有するパッケージソフトであるCorebankを勘定系に用いるというもので，試行錯誤が生じ，軌道修正もあり得ることが当然に想定されていたこと
- IBMは，スルガに対して本件システム開発を提案する2年以上前から日本にCorebankを普及させるためのJapanization作業を進め，本銀システムとしての充足度を高めてきたこと
- 本件システム開発が中止されるに至った原因は，Corebankの機能と，スルガが求める機能との間のギャップが大きく，調整が困難となったからであり，Corebank自体が邦銀勘定系システムとしての性能をおよそ備えていなかったとまでは認められないこと（現に住信SBIネット銀行においてCorebankが導入，稼働されている）
- IBMが当初提案したカスタマイズベース・アプローチは，スルガから「スルガは独自性を大事にしており，事務の標準化について，現状からダウンすること，顧客に影響を与えることは許されない。」などの要請を受けたものであって，このアプローチを採用したこと自体は「許容することができない手法選択の誤り」とは認められないこと
- Corebankの改変に関しIBMとFISとの開発体制には円滑とはいいがたい点が存していたが，開発・提案段階における許容しがたい不備とまでいうことはできないこと
- （プロジェクト開始後かなり経った後に）IBMがCorebankに代えてTCBを提案したことは，「確かに，いかにも唐突であって」「プロジェクト・マネジメントの不足を如実に示すもの」だが，企画・提案段階において適応力に欠けるパッケージソフトを提案した義務違反があったとは認められないこと
もっとも，最後の点（最後になってTCB採用提案を持ち出したこと）については，
前記ＴＣＢ採用の提案の態様は，本件システム開発の経緯に照らすと，極めて唐突なものである上，その内容も本件システム開発進行の打開方策としては粗雑なものといわざるを得ず，重要プロジェクトを担うベンダとして不見識，無責任とのそしりを受けてもやむを得ない。
と，手厳しい批判が添えられている。
IIないしIVの段階におけるプロジェクト・マネジメント義務違反等の有無について
まずは，前提となるIBMの義務について，プロジェクト・マネジメントの義務と，その一内容として説明義務があるとした。
IBMとスルガとは，本件システム開発において，IBMが，事業・業務要件定義，要件定義，外部設計工程，内部設計工程，プログラミング工程（実装工程），総合テスト，システムテスト，運用テストの全てを担当し，本件システム開発の完成まで受任することとして，３つの基本合意と１６個の個別契約を締結した。IBMは，前記各契約に基づき，本件システム開発を担うベンダとして，スルガに対し，本件システム開発過程において，適宜得られた情報を集約・分析して，ベンダとして通常求められる専門的知見を用いてシステム構築を進め，ユーザーであるスルガに必要な説明を行い，その了解を得ながら，適宜必要とされる修正，調整等を行いつつ，本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである。
また，前記義務の具体的な内容は，契約文言等から一義的に定まるものではなく，システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。すなわち，システム開発は必ずしも当初の想定どおり進むとは限らず，当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり，想定していた開発費用，開発スコープ，開発期間等について相当程度の修正を要すること，更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから，ベンダとしては，そのような局面に応じて，ユーザーのシステム開発に伴うメリット，リスク等を考慮し，適時適切に，開発状況の分析，開発計画の変更の要否とその内容，更には開発計画の中止の要否とその影響等についても説明することが求められ，そのような説明義務を負うものというべきである。
続いて，裁判所は次のように述べ，計画・要件定義＃１（IIの段階），計画・要件定義＃２（IIIの段階）を経て，IBMは本件最終合意締結のころには困難な状況にあることを認識しつつも，スルガに対して説明する義務があったとしている。
IBMは，業界屈指のベンダとして，システム開発に関する知識・経験が豊富であるから，それらに基づき前記の点を十分に認識し得たといえるほか，本件最終合意の内容からも前記の点を認識していたことがうかがわれるところである。
（略）
これらに照らすと，IBMは，スルガと本件最終合意を締結し，本件システム開発を推進する方針を選択する以上，スルガに対し，ベンダとしての知識・経験，本件システムに関する状況の分析等に基づき，開発費用，開発スコープ及び開発期間のいずれか，あるいはその全部を抜本的に見直す必要があることについて説明し，適切な見直しを行わなければ，本件システム開発を進めることができないこと，その結果，従来の投入費用，更には今後の費用が無駄になることがあることを具体的に説明し，ユーザーであるスルガの適切な判断を促す義務があったというべきである。また，本件最終合意は，前記のような局面において締結されたものであるから，IBMは，ベンダとして，この段階以降の本件システム開発の推進を図り，開発進行上の危機を回避するための適時適切な説明と提言をし，仮に回避し得ない場合には本件システム開発の中止をも提言する義務があったというべきである。
しかし，そのような状況で進行した中で締結された最終合意書において，当初の企画・提案段階で想定していた開発スコープを抜本的に変更するものではなく，延長線上に位置づけられており，IBMからスルガに対して，その後の開発に伴う危険について具体的な不利益の告知もなかった。
そして，本件最終合意締結後の経緯については次のように述べる。
IBMは，グローバルＩＢＭのＳＩ部門の参加を得て，本件システム開発全体のレビューを行い，旧ＢＲＤ，新ＢＲＤを通じ軌道修正を図った。しかし，本件最終合意において想定された構想に沿い，スルガとの調整の実現が見込まれる軌道修正をすることができず，平成１８年１１月１３日には，４段階サービスイン（平成２０年１月，同年５月，同年１０月及び同年１２月）を提示し，平成１９年３月１９日には，更に後退した内容の５段階サービスイン（平成２０年１月，同年１０月，平成２１年５月，同年１０月，平成２２年１月）を提示し，平成１９年４月１８日には，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋの導入に代替して，ＮＥＦＳＳ／ＴＣＢの採用を提案するに至った。本件最終合意を締結した後，間もなく始まった一連の軌道の修正・変更経過は，スルガにとって予期しがたいものであり，また，この間におけるIBMの説明は十分とはいいがたい上，その内容も変遷するなどしたため，スルガはIBMに不信感を抱くようになり，更には信頼を喪失し，本件システム開発は中止に至ったといえる。
IBMは，これに対し，スコープ削減等の協力を果たさなかったスルガ側に責任があると主張したが，裁判所は，
本件システム開発は，開発当初の段階から，現行システムの分析結果によっては，前記予算内で想定した開発スコープを完成させることが難しくなることも予想し得たといえる。もとより，システム開発は，技術的には実現が可能であっても，費用対効果を考慮すると実現が不可能又は到底困難とされることがあることはいうまでもない。現行システムの分析を通じて，現行システムのボリューム及び特質とＣｏｒｅｂａｎｋの持つ機能との間のギャップが判明し，当初想定していた開発費用，開発スコープ及び開発期間内にシステムを完成させることが不可能又は到底困難であることが明らかになれば，その段階で，IBMは，ベンダとして，その状況について根拠を示して説明するとともに，具体的な方針の変更等を提案する必要があったというべきである。
と，適切な説明がなかったIBM側の責任だとした。
これらの経緯に照らすと，IBMは，かなり初期の段階（平成17年5月頃）からスルガの求める予算，納期を満たして開発することは困難で，プロジェクトが中断してしまうこともあり得ると認識していたにもかかわらず，スルガに対しては，その判断に資する説明，提言等を十分にしてこなかったとされた。
そして，IVの段階において，IBMにはプロジェクト・マネジメント義務違反があるとしつつ，故意または重過失の程度があったとはされなかった。
以上のとおり，本件システム開発においては，少なくとも，本件最終合意を締結する段階において，本件システムの抜本的な変更，または，中止を含めた説明，提言及び具体的リスクの告知をしているとは認めがたいから，IBMに義務違反（プロジェクト・マネジメントに関する義務違反）が認められるというべきである。
しかし，その義務違反の程度については，スルガが，IBMに本件最終合意締結の締結を迫る一方で，重過失があった場合に累計料金相当額までIBMに損害賠償責任を負わせる旨の交渉をしてこれを合意書に盛り込ませるなど，本件システム開発の帰趨に不安を覚えつつも，IBMとの交渉を通じて本件システム開発の完成を目指そうとしていたこと，IBMは，スルガの了承を得て，当初の計画になかった旧ＢＲＤ，新ＢＲＤを行い，その作業を通じて開発スコープの見直しを図る試みを行ったこと，本件最終合意を締結する段階において，もはや手段が尽きて本件システム開発を完成させることが不可能であったとはいいがたいこと等に照らすと，IBMが，ベンダとして果たすべきプロジェクト・マネジメントに関する義務違反につき，故意，あるいは故意と同視されるような重過失の程度のものがあったということはできない。IBMの義務違反は，それに至らない過失の程度のものにとどまるというべきである。
損害の額について
裁判所は，IVの段階において不法行為が成立するとされたことから，IないしIIIの段階で締結した各契約に基づいて支出した費用については，損害賠償する義務は認められないとしつつ，本件最終合意締結後に支出した費用についてはIBMの義務違反により必要としない費用の支出を強いられたものであるとして，損害賠償義務を負うとしている。
スルガが主張する損害のうち，IBM以外の第三者に支払ったものと，逸失利益については，責任限定条項の適用が問題となった。前者については「現実に発生した通常かつ直接の損害」に当たりつつも「個別将来契約の代金相当額」を超過するのではないかという点が問題となったが，これらは免責の対象にならないとされた。ただし，逸失利益については責任限定条項の適用により，請求できないものだとされた。
その結果，損害の額は，41億余りと，原審の認定額と比べると約6割程度に減少した。
損益相殺・過失相殺について
システム設計書については，原審同様に，客観的価値を有するものとは認められなかった。
計画・要件定義＃２の成果物である要件定義書については，
トーマツの報告書によれば，要件定義書等の価値の評価についての実務慣行はなく，評価に一定の方式も存しないとされている。前記各報告書においては，評価に当たりサンプリング手法を用いているが，サンプリングが全体を代表するものとなっており，かつ，正確性を持つことが明らかとされていない。また，本件システムは，従来の邦銀システムとは異なる顧客中心のシステムの構築を目指したものであるから，別のシステムを構築する場合に設計思想が異なるなどすれば，その再利用を試みたとしても限界があるものと推認される。
としつつも，もともと計画・要件定義＃２に係る支払金額の大部分はスルガが負担すべきものであることから，損益相殺を要しないとされた。
過失相殺の主張も出されているが，認められなかった。
本件システム開発が中止されたことについて，スルガに債務不履行ないし不法行為責任を認めることはできない。また，本件システム開発が中止されるに至った経緯等に照らすと，損害の公平な分担の見地からスルガに斟酌すべき落ち度があったとは認めがたく，本件最終合意締結後の支払額に限ったIBMの損害賠償額から過失相殺をすべき事情があるということはできない。
反訴請求についてもすべて棄却されている。
若干のコメント
膨大な事実認定が前提となっているため，これだけ長く判決文を引用してもなおわかりにくい部分があったかと思われます。
原審と同様に，IBMにおいて「プロジェクト・マネジメント義務違反」があったことは認めつつも，その違いは，どの段階において義務違反が生じたのかということを細かく認定した点にあります。すなわち，義務違反が生じた時点を明らかにすることにより，それ以前（義務違反がなかったとされる期間）に生じた費用については損害の対象から外すという処理が行われた結果，原審の認容額から大幅に減額されることとなりました。
ただし，義務違反が生じた時点は，必ずしもプロジェクトが頓挫する直前とは限らず，初期の段階からプロジェクト・マネジメント義務違反が生じていながら，ずるずると進行して結果的に完了しなかったという場合には，損害の額も大きくなるといえます。
プロジェクト・マネジメント義務の内容として，主に説明義務が取り上げられています。そして，本判決の特徴の一つとして，契約締結前の企画・提案段階においても，抽象的にはベンダにおいてプロジェクト・マネジメント義務があるということを明示したところにあります。いい加減で実現困難な提案をして，その結果，ユーザがそれを信じて契約締結して多額の支出を強いた，ということになると，その全額が損害ということになり得るということです。
現時点において，本件が確定するかどうかは不明ですが，原審に引き続き，大規模システム開発案件に対して大きな影響を与えるものとなるでしょう。
