「営業支援」に関する裁判例(75)平成24年 3月29日　東京地裁　平２０（ワ）５３２０号　損害賠償請求本訴事件・請負代金等請求反訴事件　〔IBM 対 スルガ銀行事件・第一審〕

「営業支援」に関する裁判例(75)平成24年 3月29日　東京地裁　平２０（ワ）５３２０号　損害賠償請求本訴事件・請負代金等請求反訴事件　〔IBM 対 スルガ銀行事件・第一審〕

裁判年月日 　平成24年 3月29日　 裁判所名 　東京地裁　 裁判区分 　判決
事件番号 　平２０（ワ）５３２０号・平２０（ワ）２４３０３号
事件名 　損害賠償請求本訴事件・請負代金等請求反訴事件　〔IBM 対 スルガ銀行事件・第一審〕
裁判結果 　本訴請求一部認容、反訴請求棄却　 上訴等 　控訴　 文献番号 　2012WLJPCA03296002

要旨
◆被告との間で、原告の銀行業務全般を司る次期情報システムの構築に関する基本合意及び同システム開発における個別契約を締結した原告が、本件プロジェクトが中止に至ったことにつき、被告の義務違反を主張して、損害賠償を求めるなどした（本訴）のに対し、被告が、同個別契約の残代金の支払、原告の協力義務違反を理由とする本件プロジェクト中止に係る損害賠償を求めるとともに、ソフトウェア使用料金の支払を求めた（反訴）事案において、本件プロジェクトが頓挫した責任は、専らベンダとして適切にシステム開発を管理しなかった被告のプロジェクト・マネジメント義務違反にあるなどとして、被告に約７４億１３７０万円の支払を命じて本訴請求を一部認容する一方、被告の同義務違反により最終合意及び個別契約を解除した原告に契約代金の支払義務はなく、また、本件ソフトウェア中の未使用部分に係る既払料金は不当利得に該当するとして、同不当利得金とソフトウェア使用料金との相殺を認めるなどして、反訴請求を棄却した事例

裁判経過
上告審 平成27年 7月 8日 最高裁第二小法廷 決定 平２６（オ）２００号・平２６（受）２６０号 損害賠償・請負代金等反訴請求事件　〔IBM 対 スルガ銀行事件・上告審〕
上告審 平成27年 7月 8日 最高裁第二小法廷 決定 平２６（オ）２０１号・平２６（受）２６１号 損害賠償・請負代金等反訴請求事件　〔IBM 対 スルガ銀行事件・上告審〕
控訴審 平成25年 9月26日 東京高裁 判決 平２４（ネ）３６１２号 損害賠償・請負代金等反訴請求控訴事件　〔IBM 対 スルガ銀行事件・控訴審〕

評釈
桶田大介・NBL 977号4頁
小林秀之・金法 1952号52頁
生田敏康・福岡大学法学論叢 59巻3号527頁
滝澤孝臣・リマークス 47号18頁
浅井弘章・銀行法務21 756号34頁
浅井弘章・銀行法務21 750号58頁
小林秀之・銀行法務21 745号8頁
松島淳也・ビジネス法務 12巻8号83頁（上）
松島淳也・ビジネス法務 12巻9号82頁（下）
一木孝之・法セ増（新判例解説Watch） 12号87頁
藤谷護人・情報ネットワーク・ローレビュー 12号139頁

参照条文
民法４１５条
民法５０５条１項
民法６３２条
民法７０３条
民法７０９条

裁判年月日 　平成24年 3月29日　 裁判所名 　東京地裁　 裁判区分 　判決
事件番号 　平２０（ワ）５３２０号・平２０（ワ）２４３０３号
事件名 　損害賠償請求本訴事件・請負代金等請求反訴事件　〔IBM 対 スルガ銀行事件・第一審〕
裁判結果 　本訴請求一部認容、反訴請求棄却　 上訴等 　控訴　 文献番号 　2012WLJPCA03296002

平成２０年（ワ）第５３２０号損害賠償請求本訴事件
平成２０年（ワ）第２４３０３号請負代金等請求反訴事件

静岡県沼津市〈以下省略〉
本訴原告（反訴被告） スルガ銀行株式会社
同代表者代表取締役 Ａ
同訴訟代理人弁護士 久保利英明
同 上山浩
同 西本強
東京都中央区〈以下省略〉
本訴被告（反訴原告） 日本アイ・ビー・エム株式会社
同代表者代表取締役 Ｂ
同訴訟代理人弁護士 牛島信
同 井上治
同 石川拓哉
同 影島広泰
同訴訟復代理人弁護士 吉田正毅
同 藤村慎也

主文

１ 　本訴被告（反訴原告）は，本訴原告（反訴被告）に対し，７４億１３６６万６１２８円及びこれに対する平成１９年７月１８日から支払済みまで年５分の割合による金員を支払え。
２ 　本訴原告（反訴被告）のその余の本訴請求を棄却する。
３ 　本訴被告（反訴原告）の反訴請求をいずれも棄却する。
４ 　訴訟費用は，本訴反訴を通じ，これを６分し，その１を本訴原告（反訴被告）の負担とし，その余は本訴被告（反訴原告）の負担とする。
５ 　この判決は，第１項に限り，仮に執行することができる。

事実及び理由

第１ 　請求
１ 　本訴
本訴被告（反訴原告）は，本訴原告（反訴被告）に対し，１１５億８０００万円及びこれに対する平成１９年７月１８日から支払済みまで年６分の割合による金員を支払え。
２ 　反訴
(1) 　反訴被告（本訴原告）は，反訴原告（本訴被告）に対し，１３億７４８４万１６５０円及びうち２億５５１５万円に対する平成１８年８月３１日から，うち１１億１９６９万１６５０円に対する平成１９年４月７日から各支払済みまで年６分の割合による金員を支払え。
(2) 　反訴被告（本訴原告）は，反訴原告（本訴被告）に対し，１１０億５７１０万２５５３円及びこれに対する平成１９年１１月３０日から支払済みまで年５分の割合による金員を支払え。
(3) 　反訴被告（本訴原告）は，反訴原告（本訴被告）に対し，１億２００４万０６２０円及びこれに対する平成２２年２月２６日から支払済みまで年６分の割合による金員を支払え。
第２ 　事案の概要
１(1) 　本訴は，本訴原告（反訴被告。以下「原告」という。）と本訴被告（反訴原告。以下「被告」という。）との間で，原告の銀行業務全般をつかさどる次期情報システムである「新経営システム」の構築に関する基本合意（以下，上記システムの開発を「本件システム開発」といい，これに係る原告被告間のプロジェクトを「本件プロジェクト」という。）を締結するとともに，本件システム開発での個々の局面の権利，義務を規定した個別の契約（以下「本件個別契約」という。）を締結したが，結果として本件プロジェクトが中止するに至ったことにつき，原告が，①被告は，上記基本合意や本件個別契約に基づく本質的義務に従って履行すべき義務があったにもかかわらず，債務の本旨に従った履行をしなかった，②本件プロジェクトが中止するに至ったのは，被告にプロジェクト・マネジメント義務違反があったことによるものである，③被告には本件プロジェクトに関して説明義務違反があったなどと主張し，被告に対し，請負契約の債務不履行又は不法行為に基づく損害賠償を求め，あるいは，④本件プロジェクトに関して原告には要素の錯誤があったので，本件個別契約はいずれも錯誤により無効であると主張し，不当利得に基づく原状回復を求める事案である。
(2) 　反訴は，被告が，原告に対し，①本件システム開発の過程において被告と原告との間で締結された本件個別契約に定められた代金の一部が未払となっていると主張して，同契約に基づく残代金の支払を，②本件プロジェクトが中止するに至ったのは原告の協力義務違反が原因であると主張して，不法行為に基づく損害賠償をそれぞれ求めるとともに，③本件プロジェクトにおいて導入されたソフトウェアのうち被告と原告との間で締結されたエンタープライズ・スペシャル・オファリング契約が適用されるものの使用について，同契約に基づき，使用料金の支払を求める事案である。
２ 　前提事実（証拠を掲記しない事実は，当事者間に争いがなく，その他の事実は，各項に掲記した証拠及び弁論の全趣旨により認められる。）
(1) 　当事者
ア　原告は，預金又は定期積金の受入れ，資金の貸付け又は手形割引及び為替取引その他銀行法，担保付社債信託法，社債等登録法その他の法律により銀行が営むことができる業務を目的とする株式会社である。
イ　被告は，コンピュータ・システムの開発，運用，管理，搬入及び保守サービスを業とする株式会社であり，汎用コンピュータ・システム，サーバー等のハードウェア及びこれに付随するシステム・ソフトウェア等の販売等も行っている。
(2) 　本件プロジェクトに関する前提知識
ア　ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋ
本件プロジェクトは，「次世代金融サービス・システム（Ｎｅｘｔ　Ｅｖｏｌｕｔｉｏｎ　ｉｎ　Ｆｉｎａｎｃｉａｌ　Ｓｅｒｖｉｃｅｓ　Ｓｙｓｔｅｍｓ。以下，単に「ＮＥＦＳＳ」ということもある。）」を利用して，原告の銀行業務全般をつかさどる次期情報システムたる「新経営システム」（本件システム）を構築するものである。
Ｃｏｒｅｂａｎｋは，本件システムのうち基幹系システムにおいて用いられたＦｉｄｅｌｉｔｙ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｒｖｉｃｅｓ社（米国）（以下「ＦＩＳ社」という。）のアプリケーション・パッケージである。
イ　システム開発の一般的作業工程
（ア）　事業・業務要件定義
事業・業務要件定義では，経営の方針や事業部門からの業務上のニーズあるいはシステムの課題など事業及び業務上の要求（課題）を分析し，実現すべきビジネスモデルを検討・決定し，それに合わせてシステム化の方向性を決定する。
（イ）　要件定義
要件定義とは，システムの設計・開発行為に入る前にシステム化のための要件を全て洗い出し，確定する工程である。具体的には，開発するシステムの満たすべき要件を決定し，システムの目的，機能（業務内容），費用対効果，開発スケジュールなどをまとめる。
（ウ）　外部設計工程
外部設計では，システムのユーザや周辺システムから見える部分の設計を行う。具体的には，画面設計，帳票設計，周辺システムとのインターフェース，論理的なデータベースなどをまとめる。
（エ）　内部設計工程
内部設計では，システムの内部構造や仕組を設計する。具体的には，プログラムの詳細な機能や物理的なデータベースの仕様の詳細などをまとめる。
（オ）　プログラミング工程（実装工程）
プログラミング工程では，内部設計工程で機能が確定されたプログラムの設計を行い，実際にコード化し，プログラムを作成する。完成したプログラムの単体テストも行う。
（カ）　結合テスト
結合テスト工程では，サブシステムのプログラムを結合してテストを行う。
（キ）　システムテスト
システムテストでは，主にサブシステム間のインターフェースをテストする。
（ク）　運用テスト
運用テスト工程では，ほぼ実際の運用に近い形でテストを行う。開発工程はこの工程で終了である。
ウ　本件プロジェクトにおける作業工程
本件システム開発に際しても，事業・業務要件定義→計画・要件定義→設計→実装（プログラミング）→結合テスト→システムテスト→システム切替え→システム稼動という上記とほぼ同様の開発過程を経る予定とされていた。また，本件システム開発は，原告の業務全般のシステムに関するもので，非常に広範囲かつ膨大な作業が必要となることから，実際の開発作業は，①預金や融資などの基幹業務及び口座振替等の周辺業務といった銀行業務に関するシステム開発を担当する「業務グループ」（Ｃｏｒｅｂａｎｋ関連は本グループの担当であった），②外部との通信システム及びアクセスハブ等の制御システムの開発を担当する「制御グループ」，③システムの運用・管理，セキュリティ，災害対策等に関する基盤システムの開発を担当する「基盤グループ」の三つのグループに分けて進められた。
しかし，本件プロジェクト開始から約２年６か月以上かけて実際に行われたのは，本件システムで最も重要な部分である基幹系システム（上記業務グループ担当部分）については，実質的には，計画・要件定義の工程及び外部設計の途中までであり，制御及び基盤システムについては，設計作業が終了し，一部，プログラミング作業に入ったところまでであった。本件システム開発の作業は，本件プロジェクトの頓挫により中断した。
(3) 　本件プロジェクト開始に至る経緯
ア　原告は，昭和４６年１０月に導入した基幹システムの老朽化が進んできたこと等の理由から，その刷新を図るため，平成１２年ころ，当時既に３０有余年にわたり原告のシステムの管理，運用の支援，ＯＳの保守等を行ってきた被告に対し，オープンプラットフォームによる基幹系システム構築の提案及び同システムの運用，開発に係るトータルコストの削減に関する検討を依頼した（甲１２５，証人Ｃ）。
イ　原告は，同年９月，被告と共に，原告の事業戦略上実現すべき業務内容，次期システムの在るべき姿及びその要件等の洗い出し作業を開始した。
ウ　被告は，平成１４年１月，次世代の勘定系ソリューションの一つとして，「ＮｅＦＩＳ」（Ｎｅｘｔ　Ｇｅｎｅｒａｔｉｏｎ　Ｆｉｎａｎｃｉａｌ　Ｓｅｒｖｉｃｅｓ　Ｓｙｓｔｅｍ（次世代金融サービス・システム）の略。ＮＥＦＳＳと改称される前の名称。以下，改称の前後にかかわらず，「ＮＥＦＳＳ」という。）を企画，開発するためのチームを立ち上げた。
被告は，ＮＥＦＳＳの内部で銀行の勘定系システムをどう組み込むかを検討したところ，開発コストや開発に要する期間，さらにはＩＢＭグループとしての戦略の観点から，米国Ａｌｌｔｅｌ　Ｃｏｒｅｂａｎｋｉｎｇ　Ｓｏｌｕｔｉｏｎｓ，ＬＬＣ．（ＦＩＳ社の前身。以下，まとめて「ＦＩＳ社」という。）が権利を保有していたＣｏｒｅｂａｎｋをＮＥＦＳＳの部品として採用する方向で検討を開始した。
被告は，Ｃｏｒｅｂａｎｋを用いて邦銀の勘定系システムを構築する場合に大きなギャップとなりそうなところが解決できるか，また，次世代の金融システムとしてアドバンテージとなるべき機能が実装できるのかを検討するとともに，ＣＯＢＯＬを使用していたＣｏｒｅｂａｎｋを，ＮＥＦＳＳの開発言語として使用する予定のＪａｖａ（Ｊ２ＥＥ）にコンバート（Ｊａｖａ化）する必要があると考えた。そして，平成１５年３月には，ＮＥＦＳＳプロジェクトはいよいよ開発を始める段階に至った（乙１７７，証人Ｄ）。
エ　平成１２年９月から実施された原告，被告による洗い出し作業（上記イ）の結果，平成１５年７月，原告が導入する次期システムによって実現すべき事業要件が「変革のテーマ」と題する文書としてまとめられた。
オ　原告は，平成１４年９月から平成１５年１２月ころにかけて「ｅプロジェクト」を実施し，被告はそれに協力した。被告は，この中で，原告が次世代の勘定系システムの在るべき姿を見定めることの手伝いをするとともに，そのような勘定系システムの開発に要する費用や期間等についての大まかなイメージを示した（乙１７６，１７７，証人Ｄ）。
カ　被告は，Ｃｏｒｅｂａｎｋの日本化（Ｊａｐａｎｉｚａｔｉｏｎ）の作業が順調に進んだと考えたことから，平成１６年３月１２日，原告に対し，同日付け「「顧客中心」・「迅速・柔軟な商品・サービス提供」・「オンデマンド」を可能とする次世代金融サービスシステムのご紹介」と題する書面を交付した。
その中の「「次世代金融サービスシステム」業務機能の実装」と題する頁には，「以下の観点よりＵＳの先進パッケージ（Ｆｉｄｅｌｉｔｙ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｒｖｉｃｅｓの‘Ｃｏｒｅｂａｎｋ’）を有効活用します。」，「「次世代金融サービスシステム」の目標である「顧客中心」の商品・サービスを「プロダクトビルド」（自由設計）できる機能を実現するためには，先行している欧米のパッケージの有効活用が優位である。」，「短期間でパッケージを構築するには，ゼロからの開発ではなく実績のあるパッケージを有効活用して開発する方が優位である。」と記載されている。また，「基本方針」として，「先進パッケージ機能と，２００２年初めより実施してきた日本の銀行商品・サービスのモデル化とを融合させます。」，「パッケージのコンポーネント（部品）を「Ｗｅｂ　Ｓｐｈｅｒｅ」上の「Ｊａｖａ」にコンバージョン」，「日本の銀行の商品・サービスを追加」と記載されている（甲１６，乙１７７）。
キ　原告は，被告のほか，複数のシステム開発業者から提案されたシステムを比較検討した結果，被告による提案の内容が最も好ましいものと考え，平成１６年９月２１日，①原告の基幹系オンラインシステムを被告が提供するＮＥＦＳＳバンキングシステムを基に全面的に改良し，新経営システムを構築すること，②上記費用として，初期費用約９５億円，保守費用として約６億２０００万円（年額）を支出することを決めた。
なお，同日の原告取締役会に提出された議題に添付された原告作成の資料には，「プロジェクトのスケジュール」として「合意書／支援サービスの締結によって計画・要件定義＃１を開始，計画・要件定義＃２終了までに要件をまとめ，その内容に基づいた最終合意書（請負）を締結する。」，「総費用の概算内訳」として「ステップ１では上限を設定」とした上で計９５億円と記載されている（甲２０，２１）。
(4) 　「新経営システム」構築に関する基本合意（以下「本件基本合意①」といい，その合意書を「本件基本合意書①」という。）の締結（甲３）
同月２９日，原告と被告との間で本件基本合意書①が交わされ，本件プロジェクトは開始された。本件基本合意書①には，概要下記アないしエのとおり記載されている。なお，この時点においては，原告と被告との間で，平成１７年５月末に本件プロジェクトに関する最終合意が締結される予定であった。
ア　原告と被告は，被告提供のＮＥＦＳＳを利用した原告の「新経営システム」構築に当たり，以下のとおり合意した。
イ　原告の目標である「開発スコープ」（平成１６年９月２１日付け資料：「新経営システムご提案概要」）の実現を前提とした「新経営システム」構築に当たり，以下①②③の全てが実行されることを条件として，被告は９５億円（原告側要員費用含む）にて稼働を実現するよう確約する。
役割分担合意に伴う被告の管理下での原告側要員費用については，両者協議の上，工数及びスケジュール等の観点で管理を実施するものとする。
①　原告と被告の役割分担の両者による合意及び原告管理下のワークロード・費用の確定がされること
②　原告の商品・取引・帳票等に対する「ＢＰＲ・標準化」による合理化・効率化の合意が両者によりされること
③　上記①の役割分担合意に伴う，当該プロジェクトを遂行する上で必要な原告の協力がされること
ウ　「新経営システム」構築プロジェクトの計画・要件定義局面終了までに，以下の項目を含む外部設計局面以降に関して合意することを目標に両者は作業を進めるものとする。
（ア）　開発機能・スコープの詳細
（イ）　稼働までの初期費用総額の詳細及び支払計画
（ウ）　プロジェクト期間中及び稼働後のランニング費用
（エ）　ハードウェア構成・ソフトウェア構成と前提キャパシティ
（オ）　プロジェクト遅延及び不履行時の取り決め
本条に定める合意までの間に，プロジェクトの大幅な延期や中止せざるを得ない状況が発生した場合，あるいは，本条に定める合意に至らなかった場合には，両者は真摯に協議の上，互いに誠意を持って損害賠償等の措置を含む適切な対応をするものとする。
エ　計画・要件定義局面の契約として，以下の内容を含む「ＩＢＭ支援サービス契約書」（金額：７億２３１９万９０００円）につき平成１６年９月２９日を目標に締結すべく，両者協議の上，進めるものとする。
（ア）　「新経営システム」構築の計画・要件定義フェーズ＃１　ご支援作業
（イ）　「ＮＥＦＳＳパッケージ」（「コアバンク」及び「次世代金融サービス・システムライブラリー」）
(5) 　本件プロジェクトの開始～計画・要件定義＃１の経過
ア　原告は，同月２９日，被告との間で，次の内容のＩＢＭ支援サービス契約を締結した（甲５の２）。
（ア）　サービス名
「新経営システム」構築（計画・要件定義＃１）
（イ）　サービス内容
ａ　「新経営システム」構築の計画・要件定義＃１支援作業
（a）　プロジェクトスコープの確認
（b）　プロジェクト計画の立案
（c）　「ＮＥＦＳＳ」，「Ｃｏｒｅｂａｎｋ」の要件定義作業の方針検討・策定
（d）　現行システム分析
ｂ　以下のプログラム（既存資料）の提供
（a）　「コアバンク（Ｖｅｒｓｉｏｎ４．２）」
（b）　「次世代金融サービス・システム　ライブラリー（現行版）」
（ウ）　サービス料金
確定料金合計７億２３１９万９０００円（消費税別）
（エ）　サービス期間
平成１６年９月３０日より同年１２月２８日まで
イ（ア）　同年９月３０日から本件プロジェクトが正式に開始された。
（イ）　本件プロジェクトにおいては，原則として毎月１回，原告及び被告の現場の開発担当者から役員までを出席者として会議（以下「ステアリング・コミッティ」という。）を行うこととされ，このステアリング・コミッティは，同年１１月５日に第１回目が開催されて以来，平成１９年３月まで合計２７回開催された。
ステアリング・コミッティの目的は，「スルガ銀行及びＩＢＭ間の上級マネジメントレベルでの意思決定を行う」ことであるとされ，その主な内容として「プロジェクトの総合評価」，「スケジュール，作業進捗の実績，課題の共有」，「重要課題の意思決定，重要事項の報告」（なお，「重要事項の報告」のみ改訂版で追加された。）が規定されていた（甲４９の１及び２）。
ウ　計画・要件定義＃１（同年９月３０日～同年１２月２８日）においては，本件プロジェクトの目標，開発対象となるシステム及び開発スケジュールの明確化，開発方法の検討などが行われ，被告は，原告に対し，計画・要件定義＃１の成果物として，同月２１日付けプロジェクト管理計画書（以下「ＰＭＰ」という。）を作成した（甲５の３の２，乙２６１）。
(6) 　「新経営システム」構築に関する基本合意書＃２（以下「本件基本合意②」といい，その合意書を「本件基本合意書②」という。）の締結
原告は，同月２９日，被告との間で，本件基本合意書①のコスト（本件システムの稼動後におけるランニング費用）に関する条項等を変更し，同日以降の作業を行うための個別契約を締結すべく協議すること等を定めた本件基本合意②を締結した（甲４）。
(7) 　計画・要件定義＃２の開始
ア　原告は，平成１６年１２月２９日，被告との間で，計画・要件定義＃２（計画・要件定義＃１で作成されたＰＭＰを踏まえた要件定義等の作業）を対象とした次の内容のＩＢＭシステム・インテグレーション契約を締結した。計画・要件定義＃２は，平成１７年９月末までの予定とされていた（甲４・添付－３，甲５の３の１）。
（ア）　作業範囲
被告は，本件プロジェクトの要件定義（計画・要件定義＃２）を請け負う。
（イ）　成果物
ａ　要件定義書
ｂ　ＰＭＰ（更新版）
（ウ）　契約金額
確定金額３５億円（消費税別）
イ　原告と被告は，平成１６年１２月２９日，計画・要件定義＃２を開始した。この計画・要件定義＃２においては，本件システムにおいて実現すべき「変革のテーマ」等をどのように実際に具現化していくかについての方法の検討，本件システムに継承すべき現行システムが有する機能の分析，原告の現行システムとＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを用いたシステム上の処理との差異の分析（ＦＩＴ／ＧＡＰ分析）などが行われた。
なお，原告の現行システムが有する機能を分析し，それをベースとして，Ｃｏｒｅｂａｎｋが有する機能を利用できればそれをそのまま利用するが，Ｃｏｒｅｂａｎｋが有しない機能（ギャップ）については個別（カスタム）のプログラムを作成することでシステムの開発を進めるという手法（以下「カスタマイズ・ベース・アプローチ」又は「現行踏襲型アプローチ」という。）が採用されていた。
ウ　平成１７年５月末に締結予定であった最終合意について，開発範囲・機能の合意に時間を要することなどを理由に，締結が同年６月末に延期されたが，更に同年９月末に再度延期された（甲４７の１及び２）。
(8) 　「新経営システム」合意（以下「本件最終合意」といい，その合意書を「本件最終合意書」という。）の締結
ア　原告は，同年９月３０日，被告との間で本件最終合意書を交わした。本件最終合意書には概要次のとおり定められている（甲５の１）。
（ア）　第１条（新経営システム）
両当事者（原告及び被告を指す。以下同じ。）は，両当事者が合意する作業範囲，価格，支払条件及びその他の契約条件を規定する次の個別将来契約が両当事者により締結されることを条件として，本件システムの構築を被告への支払総額８９億７０８０万円（消費税別。現在締結されている次の現行契約に基づく代金（消費税別）を含む。）で被告が行うことに同意する。
ａ　個別将来契約
（a）　ＩＢＭシステム・インテグレーション契約書（基盤，制御，業務に関する外部設計局面～統合テストａ局面のサービス契約）
（b）　ＩＢＭシステム・インテグレーション契約書（ＮＥＦＳＳ周辺システムのパッケージ・ソフトウェアのライセンス契約）
（c）　ＩＢＭシステム・インテグレーション契約書（ｅＭｕＳＣに関する外部設計局面～統合テストａ局面のサービス契約）
（d）　ＩＢＭシステム・インテグレーション契約書（統合テストｂ局面～システムテスト局面のサービス契約）
（e）　ＩＢＭ支援サービス契約書（現行システムに対するＴｉｖｏｌｉを用いたホストシステム運用改善のためのサービス契約）
（f）　ＩＢＭオープン・インフラストラクチャー・オファリング契約書（平成１６年１２月２９日締結済）に対する将来の通知書１１億６３１４万７０００円分（ただし，現在見積金額）
ｂ　現行契約（原告と被告との間で，本件プロジェクトの初期段階に関して，合意された次の契約をいう。）
（a）　ＩＢＭ支援サービス契約書（平成１６年９月２９日締結。計画・要件定義局面＃１）
（b）　ＩＢＭシステム・インテグレーション契約書（同年１２月２９日締結。計画・要件定義局面＃２）
（c）　ＩＢＭオープン・インフラストラクチャー・オファリング契約書（同日締結）及び同日付けの通知書（５億２０５０万４０００円分）
（d）　ＩＢＭ支援サービス契約書（平成１７年２月１４日締結。ｚ／ＯＳ総合移行サービス）
（e）　ＩＢＭ支援サービス契約書（同日締結。災害対策（ＢＲＳ）システム構築支援サービス）
（f）　ＩＢＭシステム・インテグレーション契約書（同年７月２６日締結。ｅＭｕＳＣ移行）
（イ）　第４条（損害賠償責任）
１．両当事者が第１条記載の各個別将来契約を締結した場合で，各個別将来契約において，原告が被告の責に帰すべき事由に基づいて救済を求める全ての場合において，被告の損害賠償責任には契約責任，不法行為等の請求原因を問わず，（a）被告は，現実に発生した通常かつ直接の損害に対してのみ，損害発生の直接原因となった各関速する個別将来契約の代金相当額を限度額とし，かつ（b）被告は，いかなる場合にも，被告の責めに帰すことのできない事由から生じた損害，被告の予見の有無を問わず特別の事情から生じた損害，逸失利益，データ・プログラムなど無体物の損害，及び，第三者からの損害賠償請求に基づく原告の損害については，責任を負わない。
２．本第４条第１項（a）記載の金銭賠償の限度額にかかわらず，第１条記載の各個別将来契約の下で被告に故意又は重過失が認められる場合，第１条記載の各個別将来契約の下でのあらゆる請求ないし請求原因に係る被告による損害賠償総額は，損害発生時点において締結済みの現行契約及び個別将来契約における原告の支払済みの累計料金相当額とする。ある時点での賠償総額は，その時点までの各個別契約の下での支払総額に限定され，また，被告が既に賠償をしていた場合には，損害賠償総額からその支払額を差し引くものとする。
３．本条第２項で，故意とは，原告に損害が生ずることを認識して被告が意図的に各個別将来契約に反する行為を行った場合を意味する（ただし，被告が原告の損害が拡大することを防止するために意図的に行った場合を除く。）。また，重過失とは，原告に損害が生ずることを認識しつつも注意義務の著しい懈怠による各個別将来契約の義務違反があった場合を意味する。
（ウ）　第７条（添付案）
原告と被告は，以下の項目に関して本日に至るまでの協議に基づく案を添付し，今後さらに協議をして，最終化することに合意する。
ａ　構築要件
ｂ　新システム基盤
ｃ　切り替え方針
ｄ　プロジェクト計画
ｅ　前提条件
ｆ　商品統廃合検討結果報告
ｇ　権利関係
ｈ　今後締結予定の契約内容
ｉ　サービスイン後の保守体制
（エ）　第８条（本合意書の性質）
原告の新経営システム構築プロジェクトとＮＥＦＳＳは両当事者にとって戦力的に重要であることをここに再度確認する。また，両当事者は，新経営システム及びＮＥＦＳＳの横展開可能成果物の開発を共同で行うこととする。両当事者は，各関連個別契約の締結により，本契約及び既に締結した「新経営システム」構築に関する基本合意書２通（本件基本合意書①及び同②）は，各関連個別契約に順次置き換えられることを認識し，全ての個別契約の合意に達するべく速やかに協議を行い，かつ，この協議を当事者の合意に基づき成功裡に完了することとする。
ただし，各個別契約（第１条記載の個別将来契約を含むがこれらに限定されない。）が締結され，各関連個別契約の中で両当事者の各局面における義務が規定されるまでは，いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。両当事者の書面による合意がある場合を除いては，本第８条は有効とする。
イ　本件最終合意書には，「「新経営システム」構築に関する基本合意書（添付）」と題する本件最終合意書７条に規定された案が添付されている。同案には次の記載がある。
（ア）　構築要件
「ｅプロジェクトパイロット３」（平成１４年１０月～平成１５年６月）にて検討した変革テーマを元に４４のグループにグルーピングを実施した。更に，平成１７年１月から３月にかけて営業店等でのヒヤリングを実施し，結果を４４のグループに分類した。４４グループに属さない案件を変革テーマグループＮｏ．４５として定義した。「新経営システム」においては，４５グループを実現すべき変革テーマとして位置付ける。
（イ）　採用パッケージソフトウェア一覧
基幹システム・ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋ
（ウ）　サービスイン予定日
平成２０年１月４日
（エ）　前提条件
ａ　基礎数値
以下の数値は，原告と被告との間の協議に基づいた初期的段階の見積りであって，両当事者の今後の協議及び同意に基づいて確定されるものとする。
ｂ　商品グループ数
現行商品のシステムビューの商品グループ数：融資２１９グループ，預金８８グループの計３０７グループ
ｃ　印刷帳票数
４６１７帳票（平成１７年４月１５日報告）。今後の作業の中で帳票数を削減する。平成１７年７月時点での見込み数は１６１８帳票（プログラムベース）（原告提示の削減見込み数（２５２６）から被告にて同一帳票などを削減試算した結果）。
ｄ　トランザクション数
現処理フロー数１４０７本（平成１７年８月３１日）。今後の作業の中で，上記フローを標準化し削減することを検討する。平成１７年７月時点での見込み数は，８１３取引数（被告にてＮＥＦＳＳ　ＡＰＩ群をベースに試算した結果）。
ウ　原告と被告は，同日，プロジェクトの基本的な運営に関する覚書を締結した。そこには次のとおり定められている（乙１）。
（ア）　両者は共同開発パートナーとしての精神に基づき，プロジェクトの管理運営に一致協力していく。
（イ）　両者は従来型の発想にとらわれることなく，革新的なアプローチを柔軟に取り入れるよう対応する。
（ウ）　プロジェクト推進に当たっては，両者はプロジェクトの中心となるビジネス目標達成を核とするという共通認識に立ち，ビジネス変革の効果を訴求する。
（エ）　実装手段の詳細については両者は互いを信頼し，現行システム及びその手順との親和性要件に伴う制約（例えば端末の画面・インターフェースなど）を可能な限り取り除いて，ソリューションの最大限の効果を引き出すような柔軟な対応を進める。
（オ）　システムの実現方式として，パッケージ・ソリューション適用の基本を共通に認識し，カスタマイゼーションを最小限にとどめるよう対応する。
（カ）　原告の現行のプロセスの改善に努め，かつそれに伴うプロセスの変更にも柔軟に対応する。システムの効果を最大化するために，事務取扱手順の変更等を含めた案を両者で検討する。
（キ）　プロジェクト推進に当たっては，進捗管理の指標として業務要件の実現適否を中心にし，プロジェクトの進捗に影響を与えるような文書化などの作業を低減，ないし最適化する。
(9) 　本件最終合意締結後の経過
ア　平成１７年１０月５日に開催された第１２回ステアリング・コミッティにおいて，制御グループ及び基盤グループによる計画・要件定義＃２の完了評価が行われ，両グループの担当部分については，同月よりシステムの設計工程に入ることとされた。この制御グループ及び基盤グループの計画・要件定義＃２は，ほぼ当初のスケジュールどおり進行した。
しかし，業務グループ担当部分の計画・要件定義＃２は，平成１７年１２月末が終了予定時期とされた。
イ　被告は，同年１２月１２日，原告に対し，平成２０年１月の安定的・成功裡のサービスインのためには，開発手法及びスコープの見直しが必要であるなどとして，開発方法及び開発内容の変更を提案した（乙５）。
その後，平成１８年３月からＢＲＤ（Ｂｕｓｉｎｅｓｓ　Ｒｅｑｕｉｒｅｍｅｎｔ　Ｄｅｆｉｎｉｔｉｏｎ。以下，同月から同年５月まで行われたＢＲＤを「旧ＢＲＤ」という。）が開始された。旧ＢＲＤでは，パッケージソフトであるＣｏｒｅｂａｎｋが有する機能をベースとして，原告の業務プロセスを可能な限りＣｏｒｅｂａｎｋに合わせて変革し，カスタマイズは必要最小限に抑える手法（以下「パッケージ・ベース・アプローチ」という。）が採られた。
ウ　業務グループの計画・要件定義＃２は，いったん延期された平成１７年１２月末という期限を超え，結局，平成１８年３月８日に開催された第１６回ステアリング・コミッティにおいて終了したことが確認された。
エ　同年４月５日に開催された第１７回ステアリング・コミッティにおいて，制御グループ及び基盤グループの担当につき，設計工程が一応完了し，これらのグループ担当の部分については，実装工程（プログラミング工程）を開始することが承認された。
オ　同年３月から旧ＢＲＤが行われていたが（上記イ），同年６月から，ＦＩＳ社の担当者がより深く関与する形に体制が改善された形でＢＲＤ（以下「新ＢＲＤ」という。）が実施され，同年８月３１日まで行われた。
なお，同年４月に開始された制御グループ及び基盤グループの実装工程作業（上記エ）は，新ＢＲＤでは，システムの根幹部分にメスを入れるため，いろいろなところに影響があるとして作業は中断されることになった。
カ　被告は，新ＢＲＤが同年８月３１日に終了したことを踏まえ，同年９月前半から中旬ころ，業務グループ担当の基幹系システム部分につき，本件システムの基本設計工程作業を開始した。新ＢＲＤ開始に伴い中断されていた制御グループ及び基盤グループの実装工程作業は，業務グループの基本設計工程の開始に伴い再開された。
キ　原告と被告は，同年１１月１３日に開催された第２３回ステアリング・コミッティにおいて，次のスケジュールで本件システムを稼動させるという基本的な方向性について合意した（甲６の２３）。
（ア）　平成２０年１月：外為関連の新商品の提供に関するシステム稼動
（イ）　同年５月：本件システムによる一部サービスの開始
（ウ）　同年１０月：全営業店における基幹系システム稼動
（エ）　同年１２月末：本件システムの全面稼動
ク　被告は，平成１８年１１月以降，原告に対し，開発スコープの削減と開発費用の追加負担に関する提案を行っていたところ，同年１２月１１日，当初の計画どおりの開発スコープを実現するためには，追加費用として１２７億円を要すことを示した上，開発スコープの削減及びそのスコープを前提とした追加費用３４億円の支払を提案した（甲７，乙８３，３１０，３１２）。
ケ　同月１３日，原告のＥ代表取締役副社長（以下「Ｅ副社長」という。）と被告のＦ取締役・専務執行役員（肩書は当時。以下「Ｆ専務」という。）との間で，開発スコープ及び開発費用についての打合せが行われた（乙１１２）。
コ　被告は，同月２２日，原告に対し，原告の追加負担費用額を２０億円に減少させた案を提案した。
サ　その後，原告と被告の間で，開発スコープや追加の開発費用について合意ができない状態が続いたが，被告は，平成１９年３月１９日，原告に対し，平成２２年１月までに５段階に分けて全面稼動させるスケジュールを提案した（甲８０，乙８）。
シ　被告は，平成１９年４月１８日，原告に対し，Ｃｏｒｅｂａｎｋに代えて，Ｔｅｍｅｎｏｓ社の基幹系パッケージソフトであるＴＣＢを採用する代替案を提案した。なお，ＴＣＢは，韓国の銀行において，韓国のＩＢＭがベンダとなって開発したシステム上で稼動しているパッケージソフトであるが，勘定系にメインフレームと呼ばれるシステムを使用し，プログラム言語は４ＧＬ（４ｔｈ　Ｇｅｎｅｒａｔｉｏｎ　Ｌａｎｇｕａｇｅ）及びＣＯＢＯＬであった（甲９，弁論の全趣旨）。
ス　原告は，同年５月９日，被告に対し，本件プロジェクトをいったん白紙に戻す旨を記載した書面を交付した（甲３１）。
セ　原告と被告は，本件プロジェクトに関する話合いを継続したが，合意に達せず，原告は，同年７月１８日，同月１７日付け内容証明郵便により，被告に対し，本件最終合意及び本件個別契約を債務不履行（履行不能）により解除する旨の意思表示を行った（甲１５の１）。
(10) 　反訴請求（ただし，不法行為に基づく損害賠償請求（請求の趣旨２項に係るもの）を除く。）に係る事実関係
ア　被告と原告は，本件プロジェクトに関し，次の契約を締結した。
（ア）　被告と原告は，平成１８年３月３１日，本件プロジェクトに関する「制御」及び「基盤」の設計局面＃２（アクセスハブ設計作業，新対外システム設計作業，「新経営システム」システム基盤設計作業，「新経営システム」運用システム設計作業）に関する請負契約であるＩＢＭシステム・インテグレーション契約（以下「本件未払個別契約①」という。）を締結した。成果物は，システム設計書（ＣＤ－ＲＯＭ）一式であり，納入期限は同年３月３１日，代金額は２億５７２５万円（消費税込み）で，支払期日が同年８月３０日とされた（甲５の８の２）。
（イ）　被告と原告は，同年９月２９日，基幹系基本設計の実施，周辺システム基本設計の実施，基盤環境構築作業，制御実装作業，移行基本設計の実施に関する請負契約であるＩＢＭシステム・インテグレーション契約（以下「本件未払個別契約②」という。）を締結した。成果物は，基幹系・取引機能マトリックス（ＣＤ－Ｒ）一式等であり，納入期限は同年１２月１日，代金額は１１億１９６９万１６５０円（消費税込み）で，支払期日が平成１９年４月６日とされた（甲５の８の５）。
イ　被告は，本件未払個別契約①所定の成果物である「システム設計書（制御編・基盤編）」を納入予定日である平成１８年３月３１日付けで原告に対して納品し，同日，原告による受領，受入検査を完了した。
原告は，本件未払個別契約①所定の代金額支払期日である同年８月３０日を経過した現在においても，その代金の一部である２億５５１５万円（消費税込み）を支払っていない。
ウ（ア）　被告は，原告に対し，本件未払個別契約②所定の成果物である「基幹系・取引機能マトリックス」等（ただし，後記（イ）記載の一部を除く。）を納入予定日である平成１８年１２月１日に原告に対して納品し，原告の受入検査を経て，同月２６日に上記の更新版を納品して，原告による受領，受入検査を完了した。
（イ）　ただし，本件未払個別契約②所定の成果物である「設計・実装局面作業計画」については，いまだ原告による受領，受入検査がされていない。
（ウ）　原告は，本件未払個別契約②所定の代金額支払期日である平成１９年４月６日を経過した現在においても，その代金額１１億１９６９万１６５０円（消費税込み）を支払っていない。
エ（ア）　被告と原告は，平成１６年１２月２９日，本件プロジェクトにおけるハードウェア，ソフトウェア等の導入，リース及び保守等に関し，オープン・インフラストラクチャー・オファリング契約（以下「ＯＩＯ契約」という。）を締結した（甲５の４の１）。
ＯＩＯ契約は，ハードウェア及びソフトウェアを広く対象とするものであるが，そのうち，乙３７２・１４ないし１７頁の「製品名称」欄記載のソフトウェアについては，ＯＩＯ契約と一括して締結されたエンタープライズ・スペシャル・オファリング契約が適用される（以下，この契約を「ＥＳＯ契約」といい，これが適用されるソフトウェアを「ＥＳＯ契約対象ソフトウェア」という。）。
（イ）　ＥＳＯ契約対象ソフトウェアの使用料金の合計に関しては，一定の上限値が定められ，当該使用料金の上限値を超えた場合には，原告は，被告に対し，上限値の超過金額を支払う義務を負う。そして，平成２０年度及び平成２１年度における使用金額の上限値は次のとおりである。
平成２０年度　２億３０１９万７６００円（消費税抜き）
平成２１年度　１億５７７６万０４００円（消費税抜き）
（ウ）　平成２０年度及び平成２１年度における原告のＥＳＯ契約対象ソフトウェアの使用料金実績金額は，次のとおり使用料金上限値を超過した。
平成２０年度　１７８３万４０００円（消費税抜き）
平成２１年度　９６４９万０４００円（消費税抜き）
（エ）　被告は，原告に対し，平成２２年２月２６日，上記使用料金超過額に消費税を付加した次の金額を請求した。
平成２０年度　１８７２万５７００円（消費税込み）
平成２１年度　１億０１３１万４９２０円（消費税込み）
（オ）　原告は，被告の上記請求に対し，いまだに支払をしていない。
３ 　主たる争点
(1) 　本件本質的義務の法的拘束力及びその不履行の有無（本訴，反訴）
(2) 　本件プロジェクト中止の原因及びその責任の所在（本訴，反訴）
(3) 　本件個別契約の債務不履行解除の成否（本訴，反訴）
(4) 　説明義務違反の有無（本訴）
(5) 　錯誤の有無（本訴，反訴）
(6) 　原告の損害（本訴）
(7) 　反訴請求の可否（反訴）
４ 　主たる争点に対する当事者の主張
(1) 　争点(1)（本件本質的義務の法的拘束力及びその不履行の有無）について
（原告の主張）
ア　請負契約の締結
（ア）　原告及び被告は，本件基本合意書①及び同②により，被告がＮＥＦＳＳを利用して，原告の銀行業務全般をつかさどる次期情報システムたる本件システムを報酬額９５億円にて構築を請け負うことに関し，基本的事項の合意を行った。
（イ）　原告と被告は，平成１７年９月３０日，本件基本合意書①及び同②を受けて，本件最終合意を締結し，作業範囲，価格，支払条件及びその他の契約条件を規定する将来の個別契約（以下「本件将来個別契約」という。）の締結を前提として，被告が本件システムを開発，構築し，その結果（完成物）に対し，原告が８９億７０８０万円を支払う旨の請負契約を締結した（本件最終合意書１条）。
イ　本件最終合意書の法的拘束力
（ア）　本件最終合意書８条ただし書及び同１条は，関連する個別契約の締結を前提として本件最終合意書が法的拘束力を有することを定めたものである。そして，個別将来契約（本件最終合意書１条）は，個別将来契約(4)「ＩＢＭシステム・インテグレーション契約書」を除き，全て締結済みである。
また，本件最終合意書８条ただし書記載の「各個別契約」は，本件最終合意書１条の「個別将来契約」の記載から明らかなように，本件最終合意の締結以降に実施すべき各工程に関するものである。本件システムを完成させるためには当然これらの工程の実施が不可欠であり，それに関する個別契約の締結も必要になる。しかしながら，仮に原告が，個別契約の締結を合理的理由がなく拒んだ場合にも，被告が本件システムを完成させる請負契約上の義務を免れないとすることは不合理である。本件最終合意書８条ただし書及び同１条は，このような不都合を避けることを趣旨として規定されたものである。そして，未締結の個別将来契約(4)「ＩＢＭシステム・インテグレーション契約書」が締結されなかったのは，当事者が不合理に締結を拒絶したことによるものではなく，この契約が対象とする「システムテスト」工程に入る前の段階で被告の故意又は重過失により本件プロジェクトが頓挫したためである。この個別契約は，仮に本件プロジェクトが順調に進行していれば，当然締結されていたはずのものであり，締結されなかったのは被告の故意又は重過失によるものであって，この契約が締結されなかったことに原告の帰責性は一切ない。
したがって，本件最終合意書が法的拘束力を持つと解釈しても，本件最終合意書８条ただし書及び同１条が懸念したような上記不都合は生じない。以上からすれば，本件最終合意書は，その文理及び趣旨に照らして，法的拘束力を有することが明らかである。
（イ）　被告は，本件最終合意書８条第３文をも本件最終合意書の法的拘束力を否定する根拠としている。本件最終合意書８条第３文には，「両当事者は，各関連個別契約の締結により，本契約および既に締結した『新経営システム』構築に関する基本合意書２通は，各関連個別契約に順次置き換えられることを認識し・・・」と記載されている。この本件最終合意書８条第３文と同条ただし書を併せ読むと，本件基本合意書①，同②及び本件最終合意書は，各関連個別契約の締結を前提として法的拘束力を有するが，各関連個別契約に個別に規定された部分については，個別契約が優先するということになる。すなわち，本件最終合意書８条第３文は，本件最終合意書の法的拘束力を否定するものではなく，むしろ本件最終合意書の該当部分が，各関連個別契約に「置き換えられる」としていることからすると，本件最終合意書の法的拘束力を大前提としている規定と解するのが自然である（本件基本合意書①及び同②にも法的拘束力があることが前提とされている。）。したがって，本件最終合意書８条第３文を根拠として本件最終合意書の法的拘束力を否定しようとする被告の主張は失当である。
（ウ）　さらに，契約書に規定された内容を合理的に意思解釈する場合，その文言自体もさることながら，契約に至る経緯や契約締結後の当事者の履行状況その他関連する事実を総合的に考慮して当事者の合理的意思の内容は決定されるべきである。
本件最終合意が締結されたのは，平成１６年９月に本件プロジェクトが開始してから１年後のことである。この間に開催された１１回のステアリング・コミッティの議事録を見れば，かなり詳細な検討がされた上で，本件最終合意書において請負の報酬額を８９億７０８０万円という確定金額として定め，本件システムのサービスイン時期を平成２０年１月と定めたことが明確に理解できる。
また，本件最終合意の締結は，被告側の理由により，当初の締結予定時期（平成１７年５月）から大幅に遅れて締結された。これは，本件基本合意書①においては「概算見積り」を合意し，本件最終合意書においては「確定金額」を合意するという「２段階の合意」が当初からの予定であり，これが原告及び被告双方が認識していた本件基本合意書①及び本件最終合意書の位置付けであり，それゆえ，計画・要件定義作業の実施により最終合意書に規定する内容（特に本件本質的義務の内容や別添資料に盛り込むべき業務要件定義の内容）を具体的に確定するのに時間を要した。
加えて，被告は，本件最終合意書の履行の過程においても，終始一貫して本件最終合意書に法的拘束力があることを前提とする言動を行っており，本件最終合意書に法的拘束力が認められないという趣旨の言動をしたことは一度たりともない。被告も，本件最終合意書の効力に関して自らがいかなる言動をとってきたかを冷静に振り返れば，この点は否定しようがないはずである。本件最終合意書の履行の過程からしても，原告のみならず被告も本件最終合意書が法的拘束力を有するとの認識があったことが分かる。
以上からすれば，当事者の率直な意思からしても，本件最終合意書に法的拘束力が認められることは明白である。
（エ）　仮に，本件最終合意書の法的拘束力が全ての個別契約の締結という停止条件に服していると解釈されても，被告は，故意又はこれと同視すべき重過失によりこの停止条件の成就を妨害したのであるから，民法１３０条により，この停止条件は成就したものとみなされる。
また，被告は，個別将来契約(4)「ＩＢＭシステムインテグレーション契約書」以外にも個別契約が締結される予定であり，かかる個別契約も締結していないのであるから，本件最終合意書は法的拘束力を有していない旨主張する。しかし，本件最終合意書１条において締結することが「条件」とされた「個別将来契約」のうち，未締結のものは個別将来契約(4)「ＩＢＭシステム・インテグレーション契約書」のみである。加えて，仮に被告がいうとおり，個別将来契約(4)「ＩＢＭシステム・インテグレーション契約書」以外にも個別契約が締結される予定であったとしても，かかる個別契約は，全てＣｏｒｅｂａｎｋを採用したのでは本件システムを完成できないことが明らかとなって，本件プロジェクトが頓挫した以降の工程に関するものであり，被告の故意又は重過失により締結されなかったものである。
その他，被告の主張は，本件プロジェクトにおける自らの言動を翻し，過度に一般論にのみ依拠した「後付けの論理」に終始しているばかりか，本件における事実関係及び客観的証拠に一切基づかないものであり，極めて失当である。
ウ　本件本質的義務の法的拘束力
（ア）　被告は，上記ア，イのとおり，「次世代金融サービス・システム（ＮＥＦＳＳ）」を利用した本件システムを完成させるべき請負契約上の義務を負っているが，その具体的義務として少なくとも次の義務（以下，総称して「本件本質的義務」という。）を負っている。
ａ　ＦＩＳ社のアプリケーション・パッケージ（基幹システム）であるＣｏｒｅｂａｎｋを採用し，Ｃｏｒｅｂａｎｋに，日本の銀行特有の基幹業務の機能を追加して，本件システムを構築する義務
ｂ　銀行業務全般をカバーし，「変革のテーマ」（本件基本合意書①（甲３）の添付資料「『新経営システム』プロジェクト新業務・機能要件に対する開発方針」と題する文書）に記載の業務を実現するシステム（基幹系，周辺系，基盤系，制御系システムの全てを含む。）を開発対象の範囲（以下「開発スコープ」という。）とし，本件システムを構築する義務
ｃ　平成２０年１月までに，請負代金を８９億７０８０万円として，本件システムを完成・納入し，稼動させる義務
（イ）　被告が本件本質的義務を法的拘束力があるものとして負っていることは，本件本質的義務の内容が，本件最終合意書と一体のものとしてこの一部を構成する添付資料「『新経営システム』構築に関する基本合意書（添付）」に明示的に記載されている（同資料９頁以下）ことから明らかである。
なお，本件最終合意書によると，上記添付資料は，「本日に至るまでの協議に基づく案」であり，「今後さらに協議をして，最終化することに合意する」とされている（本件最終合意書７条）。しかし，少なくとも，上記（ア）ａないしｃの事項については，本件最終合意の締結時点においては確定的な合意事項として最終化されていた。これは，本件最終合意の締結に至る経緯のみならず，次の事情から明らかである。
すなわち，上記（ア）ａないしｃの事項（基幹システムに関する事項（いかなるアプリケーション・パッケージを採用するか），開発スコープに関する事項並びに構築したシステムのサービスイン時期及び費用に関する事項）が合意されなければ，システム開発に関する契約はその成立要件を満たさない，つまりいかなるシステムをいつまでにいくらの費用で構築するのかが決まらなければ，システム開発の委託につき合意されたとはいえない。また，上記（ア）ａないしｃの事項は，請負の報酬金額を見積もる上で必要不可欠な事項であるところ，本件最終合意書では請負の報酬額が確定金額として定められている。さらに，被告は，その作成に係る平成１８年１２月１１日付け「『新経営システム』構築プロジェクトの今後の進め方に関するご相談」と題する文書において，「合意書時点の計画」として，原告及び被告が，上記（ア）ａ及びｃ（サービスイン時期）の事項を本件最終合意の締結時点で合意した事項として明示的に確認している。
加えて，被告は，本件基本合意①締結直後の平成１６年１０月２０日に行ったプレスリリースにおいても，上記（ア）ａ及びｃ（サービスイン時期）の事項は被告が行う事項として明記している。
以上からすれば，本件最終合意書添付資料が案であるとしても，少なくとも上記（ア）ａないしｃの事項については本件最終合意の締結時点において「最終化」されており，本件本質的義務は，法的拘束力のある義務として原告及び被告により合意されたことが分かる。
（ウ）　Ｃｏｒｅｂａｎｋを基幹に据えて本件システムを構築する義務
ａ　被告は，法的拘束力のある本件基本合意書①及び本件最終合意書において，Ｃｏｒｅｂａｎｋを基幹に据えて本件システムを構築する義務を負っている。
そもそも，パッケージ型システム開発においては，基盤となるパッケージソフトが開発費用，開発スケジュール，稼動時期（サービスイン時期），開発手法，開発体制などの「プロジェクト全体計画」策定の基礎となるものであり，同時にハードウェア構成，ソフトウェア構成といった構築システムの根幹を決定するものでもある。すなわち，パッケージ型システム開発においては，パッケージが決定されないことには，開発も開始することができない。この意味で，パッケージ型システム開発において，パッケージの選定は，最終的に開発する対象となるシステムの根幹を決定するものであり，プロジェクトの大前提であって，かつ，その適切な選定は最重要課題の一つというべきものである。
したがって，システムに用いるパッケージは，システム開発の開始以前の段階において確定されなければならない。本件システムにおいては，Ｃｏｒｅｂａｎｋが採用されることが前提とされていたが，パッケージ型システム開発においては，システムに用いるパッケージが決まらないことにはシステムの開発作業が開始できないのであるから，本件プロジェクトが開始された段階，すなわち本件基本合意①が締結された平成１６年９月２９日には，当然，原告及び被告において確定的に合意されていた。
ｂ　また被告は，本件基本合意書①及び本件最終合意書に加え，法的拘束力を有することに全く争いのない本件個別契約においても，Ｃｏｒｅｂａｎｋを採用して本件システムを構築することを合意している。
したがって，万が一，本件基本合意①を締結した時点ではＣｏｒｅｂａｎｋを採用して本件システムを構築する義務が最終化していなかったとしても，法的拘束力のある本件個別契約を締結した時点では，かかる義務は最終化し，本件個別契約上の法的義務となったといわざるを得ない。
ｃ　また，本件プロジェクト開始以降，約２年もの期間を費やして実施された計画・要件定義＃１，計画・要件定義＃２，旧ＢＲＤ，新ＢＲＤにおける検討作業の大半がＣｏｒｅｂａｎｋと本件システムのＦＩＴ／ＧＡＰ分析作業であった。
ｄ　さらに本件プロジェクトの遂行過程においても，被告は，Ｃｏｒｅｂａｎｋは，本件システムの根幹である旨を終始一貫，繰り返し強調し，原告もその被告の説明を信頼していた。それのみならず，被告は，当初から終始一貫してＣｏｒｅｂａｎｋの採用を大前提とした書面での報告を繰り返し行っている。
ｅ　また，被告は，Ｃｏｒｅｂａｎｋが本件システムの基幹部分を構成する最重要部分であったことから，わざわざ原告を北欧にまで連れて行き，Ｃｏｒｅｂａｎｋを実際に採用したシステムの稼動状況を視察させている（平成１７年１０月３１日～同年１１月４日）。
ｆ　上記のような揺るぎない証拠の存在にもかかわらず，被告は，訴訟になって，「実はＣｏｒｅｂａｎｋの採用も『最終化』されていなかった」などと主張している。つまり，被告は，パッケージ型システム開発を行うとしながら，その基幹となるパッケージも当事者間で最終的には合意していなかったと主張しているのであるが，このような主張は，単に失当であるのみならず，システム開発業者としては非常識かつ無責任極まりない。それとも被告は，本件システム開発において，約７９億円もの大金を受け取っておきながら，プロジェクトの最重要事項の一つであるパッケージの種類についても，法的義務を終始一貫負っていなかったとでもいうのであろうか。このような極めて不合理な主張が失当であることは明白である。また，被告は，業務要件を充たしさえすれば，パッケージはＣｏｒｅｂａｎｋでもＴＣＢでも何でもよかったのであるという旨主張しているが，これは暴論以外の何ものでもない。さらに，被告は，「Ｃｏｒｅｂａｎｋの採用が本件プロジェクトにおいて原告，被告間で前提とされていたこと」については訴訟においても明示的に認めておきながら，「Ｃｏｒｅｂａｎｋの採用が本件プロジェクトにおける前提となっていたことと，Ｃｏｒｅｂａｎｋの採用が当事者間において法的拘束力を有する合意であるかどうかは別論である」などと主張している。被告は，原告から客観的証拠に基づき，被告がＣｏｒｅｂａｎｋを採用して本件システムを構築する義務を負っていたことを主張され，かつ，この原告の主張に反論できないことから，この主張に対して正面から反論せずに上記のような苦し紛れの主張をしているのであろうが，このような論理はせいぜい「言葉遊び」にすぎず，到底採用できるものではない。加えて，被告は，Ｃｏｒｅｂａｎｋの採用の「提案」を行ったのではなく「紹介」を行っただけであると主張するが，かかる主張は極めて不当な詭弁である。
被告がこのように不合理で，到底本気で行っているとは思えない主張を行わざるを得ないことからすれば，被告も，自らがＣｏｒｅｂａｎｋを採用して本件システムを構築する法的義務を負っていたことを実質的には認めているというべきである。
ｇ　以上からすれば，被告がＣｏｒｅｂａｎｋを採用して本件システムを構築する法的義務を負っていた事実は揺るがない。
（エ）　開発費用，開発スケジュール及び開発スコープ
被告は，本件本質的義務のうち，８９億７０８０万円という開発費用，平成２０年１月のサービスイン時期及び開発スコープに関しても法的義務を負っていた。
ａ　そもそも，大規模なシステム開発をベンダに委託する際に，システム開発全体に要する開発費用を何ら合意することなく，全て各フェーズの個別契約に委ねるということは非現実的であり，通常，契約当事者の合理的意思とはいい難い。
もとより企業が大規模な投資を行う場合，その対象がシステム開発であろうと他の案件であろうと必ず投資効果分析を行い，投資を上回る効果が得られると判断できて初めて投資の意思決定が可能となる。投資効果の評価を行うことなく投資を意思決定するなどということは，経営の常識に照らしてあり得ない。仮にそのような経営判断をしたとすれば，経営者は重大な経営判断の誤りを犯したと評価されることになることに議論の余地はなかろう。そして，投資効果分析を行うためには，総投資額（あるいは上限）が明確になっていることが必須である。しかし，開発費用について上限を定めず，プロジェクトの進行に伴って随時，個別契約により業務委託費用を決めていくこととすれば，開発費用は，歯止めがなくなり，際限なく増大してしまうおそれが高く，青天井となってしまう。そして，開発費用がユーザの当初想定を大きく上回る事態になれば，プロジェクトは頓挫することになる。このような結果は，ユーザだけでなく，ベンダにとっても大きなデメリットである。プロジェクトが失敗に終われば，ユーザとの信頼関係は崩れ，ベンダはユーザから委託費用を円滑に回収することも困難になりかねないし，プロジェクトを失敗させたというレピュテーションリスクも背負うことになるからである。開発費用にあらかじめ上限を設けないことは，一見するとベンダにとっては赤字に陥るリスクを回避できる点でメリットのみがあるように思えるかもしれないが，開発費用の上限を定めない場合，予算の抑制が効かず業務委託費用が際限なく増える確率も高まり，結果としてプロジェクトが失敗する確率が高まることから，ベンダにとっても望ましくないのである。
したがって，システム開発全体に要する開発費用を何ら合意することなく，全て各フェーズの個別契約に委ねるということは，ユーザはもちろんベンダにとっても合理的意思とはいえない。
そこで，原告は，開発費用が「青天井」になることを避けるために，平成１２年９月から，被告と共に約４年の年月をかけて，原告の事業戦略上，実現すべき業務内容，次期システムの在るべき姿及びその要件等の洗い出し作業を実施して，本件基本合意書①においては「概算見積り」を合意し，本件最終合意書においては「確定金額」を合意したのである。より具体的にいえば，平成１２年９月から，原告は，被告と共同で，「Ｅ－Ｐｒｏｊｅｃｔ　パイロット３　新システム予備検討」と題して原告の次世代システムの検討を行い，平成１５年７月からは「ＮＥＸＴ　予備検討」と題して更に検討を進めた。
また，被告は，これらの検討結果を受け，平成１６年４～６月，原告と共同で，次世代システムの機能要件（「変革のテーマ」。これは本件基本合意書①に添付され，同合意書の内容にもなっている。），投資費用，運用費用及びシステムデザイン等を作成した。こうした詳細な検討を経て本件基本合意①が平成１６年９月２９日に締結され，本件プロジェクトが開始された。さらに，本件最終合意は，プロジェクトが開始されてから約１年間かけて業務要件定義工程を実施した後に締結されたのである。
このように，被告は，平成１２年９月からの上記の諸検討によって，開発費用の見積りに必要な基礎データを十分に把握した上で，本件最終合意書において８９億７０８０万円という開発費用を合意したのである。本件プロジェクトのように，約５年もの時間をかけた極めて入念な事前検討を経て，開発費用や開発スケジュールが具体的に合意されることは，システム開発においても非常にまれである。被告は，これだけの事前検討を入念に行っていたのであるから，極めて精緻な見積りと開発スケジュールの策定を行うことが可能であったはずである。
このようにして最終的に合意された８９億７０８０万円という開発費用が法的拘束力のある確定金額であることに疑念の余地はない。
ｂ　また，被告自身も，この８９億７０８０万円という開発費用は，本件システムを構築するための開発費用の確定的な総額であるとの理解に立っていた。
被告は，本件訴訟において，本件プロジェクトの遂行過程における自らの言動とことごとく矛盾する主張を行っているが，かかる主張に説得力がなく，無意味なものであるのは明白である。
ｃ　なお，確かに，システム開発の案件によっては，被告が主張するとおり，開発費用の総額を確定的に合意することなく，個別契約において各フェーズの業務委託費用を合意していくケースもある。
実際に，被告も，他のシステム開発案件においては，通常，プロジェクト開始時点の「基本契約」で具体的なシステム開発費用について合意しない。
しかし，本件プロジェクトにおいて，原告と被告は，このような被告の通常のプラクティスとも全く異なり，本件基本合意①を締結するまでに４年，本件最終合意を締結するまでに５年もの歳月をかけて業務要件等を共に検討した上で，８９億７０８０万円という開発費用を明確に合意している。しかも，その金額は１０００万円単位のようなおおざっぱな定め方ではなく，１０万円単位の詳細な額で定められている。この精度は実に０．００１％（１０万円÷８９億７０８０万円）という極めて高い精度であり，この事実も，８９億７０８０万円という金額が上述の詳細な分析・検討の結果提示されたものであって，単なる「目安」のような抽象的な金額でないことを示している。
ｄ　上記の開発費用に関する議論は，開発スコープに関する事項及びシステムのサービスイン時期についても同様に当てはまる。すなわち，これらに関する事項が合意されなければ，そもそもシステム開発に関する契約はその成立要件を満たさない。
ｅ　また，被告は，法的拘束力を有することに全く争いのない本件個別契約においても，本件最終合意書における開発スコープに関する事項及び構築したシステムのサービスイン時期を大前提として合意している。
したがって，万が一，本件基本合意書①では開発スコープに関する事項及び構築したシステムのサービスイン時期が「最終化」していなかったとしても，法的拘束力のある本件個別契約を締結した時点では，かかる義務は「最終化」し，本件個別契約上，被告の法的義務となったといわざるを得ない。
エ　本件本質的義務の債務不履行
（ア）　履行不能（Ｃｏｒｅｂａｎｋを基幹に据えた本件システムの開発が不可能になったこと）
被告は，①ＧＡＰ開発の役割分担，開発スケジュール，更には開発費用等についてＦＩＳ社との間で合意することができず，結果，Ｃｏｒｅｂａｎｋのカスタマイズが行えない状況となったこと，②本件システムの開発費用が現実的な水準を越え，かつ，開発スケジュールにおいても本件システムがいつ完成するか分からない状態になったこと，③「Ｃｏｒｅｂａｎｋの技術的な問題」（Ｊａｖａ変換後のパフォーマンスの悪さ）が存在し，本件システムへの採用に耐え得る状態ではなかったこと，更には，④本件プロジェクトが正式に開始され，約２年７か月もの間，Ｃｏｒｅｂａｎｋの採用を大前提として膨大な費用と労力をかけて開発が進められてきた中で，被告がＴＣＢの採用という「代替案」を提案せざるを得なくなったこと，及び⑤その「代替案」の提案自体の内容も極めて杜撰（検証不十分）で提案と呼べるものではなかったにもかかわらず，被告がこの段階で，極めて不合理な提案を行わざるを得なかったことなどからすれば，Ｃｏｒｅｂａｎｋを基盤に据えて本件システムを構築することが不可能であったことは極めて明白である。したがって，本件本質的義務（Ｃｏｒｅｂａｎｋを採用して本件システムを構築する義務）が履行不能となったことに疑念の余地はない。
（イ）　債務の本旨不履行（被告がＣｏｒｅｂａｎｋの採用を断念したこと）
また，被告は，Ｃｏｒｅｂａｎｋの採用が不可能となったことから，これを断念し，平成１９年４月１８日にＣｏｒｅｂａｎｋの代替案としてＴＣＢの採用を提案するに至ったことは明白であり，したがって，被告は，本件本質的義務の本旨に従った債務の履行をしなかったことも明白である。
（ウ）　さらに，Ｃｏｒｅｂａｎｋを基盤に据えて本件システムを構築することが不可能となり，被告が本件プロジェクトを頓挫させたことからすれば，本件本質的義務のうち，サービスイン時期に関する義務（原被告の合意により変更された平成２０年１２月に全面稼動させる義務）及び合意された開発スコープを実現した本件システムを構築する義務も本旨不履行及び履行不能となったことは明白である。
（被告の主張）
ア　本件最終合意書の法的拘束力
（ア）　本件基本合意書第８条ただし書には，本件最終合意書が法的拘束力を有しないと明記されている。原告の主張は，本件最終合意書の規定に明確に反する解釈論であって，全く容れるところがない。
本件最終合意書第８条は，本件最終合意書が，その締結時点及び個別契約が全て締結された時点のいずれにおいても法的拘束力を有しないことを極めて明確に規定している。「各関連個別契約の中で両当事者の各局面における義務が規定されるまでは，いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする」と明確に規定され，「本第８条は有効とする」とされているにもかかわらず，なぜ第１条に記載された８９億７０８０万円でシステムを完成させる「法的な義務」を負うと考えるのか，理解に苦しむ。
（イ）　原告は，本件最終合意書で締結が予定されている各個別契約は個別将来契約(4)を除き全て締結済みであるとする。しかし，原告が唯一未締結であると主張する個別将来契約(4)「ＩＢＭシステムインテグレーション契約書」は，「統合テストｂ局面～システムテスト局面」を対象とするものであるところ，本件では，これ以外にも，本件最終合意書第１条に規定する個別将来契約(1)「ＩＢＭシステムインテグレーション契約書」のうち，「業務」に関する外部設計・内部設計・開発・テスト局面，並びに「制御」及び「基盤」に関する開発・テスト以降の局面に関する個別契約のほとんど，すなわち，個別将来契約(1)の大半が未締結である。
（ウ）　また，原告は，締結していない個別将来契約は被告の故意又は重過失により締結できなかったものであるため，本件最終合意書の趣旨に照らし，本件最終合意書が法的拘束力を有するなどと主張する。しかし，これらの個別契約が締結されなかったのは，被告が，要件定義・ＢＲＤ終了後に行った見積りを基に，平成１８年９月から１２月ころにかけて現実的な開発スコープ及び開発費用の負担額等に関して積極的な提案を行ったにもかかわらず，原告被告間に契約がなくなった同年１２月１８日以降も原告がこれに応じず，被告が契約を締結するよう強く要請した平成１９年１月に至っても原告がこれを締結しなかったからである。したがって，これらの個別契約が被告の故意又は重過失により締結されなかったなどという事実はなく，むしろ，原告が，交渉において，法的拘束力のないことが明らかな開発スコープや８９．７億円等に固執するなど不合理に強硬な姿勢を貫き，結局これらを締結しなかったというのが真実である。
（エ）　さらに，原告は，本件最終合意書８条本文第３文の解釈につき，「本件基本合意書①，同②及び本件最終合意書は，各関連個別契約の締結を前提として法的拘束力を有するが，各関連個別契約に個別に規定された部分については，個別契約が優先する」と主張する。したがって，原告の上記解釈によっても，「関連する個別契約の締結を前提として本件最終合意書が法的拘束力を有する」以上，本件最終合意書が締結されたときから個別契約が締結されるまでの間は，本件最終合意書に法的拘束力がないことには争いがない。
そして，原告は，「各関連個別契約に個別に規定された部分については，個別契約が優先する」とするところ，個別契約のうち請負契約に該当する「ＩＢＭシステム・インテグレーション契約」には，（ⅰ）契約金額，（ⅱ）作業予定及び成果物の納入予定日，並びに（ⅲ）作業範囲及び作業項目が，また，個別契約のうち準委任契約に該当する「ＩＢＭ支援サービス契約」には，（ⅰ）サービス料金，（ⅱ）サービス期間，及び（ⅲ）サービス対象範囲が，いずれも例外なく記載される。したがって，原告の解釈を前提としても，少なくとも，本件最終合意書記載の（ⅰ）開発費用のうち原告の負担分，（ⅱ）開発スケジュール，及び（ⅲ）開発スコープについては，本件最終合意書の規定内容は，同一の項目を規定する法的拘束力を有する個別契約が「優先する」ことになる。
よって，個別契約締結後も，上記（ⅰ）～（ⅲ）の点について，本件最終合意書が法的効力を有することはない。
（オ）　原告は，本件最終合意書８条第３文につき，「本件最終合意書の法的拘束力を否定するものではなく，むしろ本件最終合意書の当該部分が，各関連個別契約に「置き換えられる」としていることからすると，本件最終合意書の法的拘束力を大前提としている規定と解するのが自然である」などと根拠のない解釈論を展開するが，法的拘束力がない合意書が法的拘束力のある個別契約に「置き換えられる」ことに何ら不自然な点もないし，そもそも，原告の上記主張は，あたかも個別契約により置き換えられる本件最終合意書が，「置き換えられる」より前の時点，すなわち個別契約締結以前の時点で法的拘束力を有していることを前提とするかのようであって，個別契約締結までは本件最終合意書に法的拘束力がないことを認める自らの主張と完全に矛盾している。
（カ）　履行を強制し，あるいはその不履行について損害賠償請求をすることのできる法的拘束力を持った契約であるためには，合意の内容が特定されていなければならないことはいうまでもない。
本件最終合意書においては，原告の費用負担額については第１条及び第８条により確定していないことは明らかであるし，開発スコープ及びサービスインの時期についても第７条において「今後さらに協議をして，最終化する」としており，その時点では「最終化」していないことが明らかである。つまり，費用負担額，開発スコープ及びサービスインの時期について，今後要件定義等を通じて「何を作るのか」が決まる過程で，交渉等を経て決定されることが予定されていた。
したがって，本件最終合意書は，履行を強制し，あるいはその不履行についての損害賠償を請求することができるものではない，すなわち請負契約としての成立要件を満たさない。
（キ）　原告は，本件最終合意書に至る経緯や契約締結後の当事者の履行状況その他の事情を「当事者の合理的意思」などとして本件最終合意書の解釈に影響を与えるかのように主張する。しかし，当事者の意思解釈とは，条文の趣旨が不明確なときにその解釈について補充的に行われるべきものであって，本件最終合意書第８条ただし書のように，法的拘束力を有しないことが一義的に明確な場合に当事者の意思解釈を持ち込む余地はない。しかも，本件最終合意書は，東証一部に上場する銀行である原告と世界的なＩＴ企業である被告という大企業同士がその文言について十分検討を行なって締結したものであるから，「当事者の合理的意思」の解釈という名の下に，文言に反する効果を発生させるべき事案ではない。仮に，原告の主張するように，企業間の取引において，協議の上で一義的に明確な文言を定めたにもかかわらず，それに一見して反する解釈を「当事者の合理的意思」などと称して公然と行うことになれば，契約書や合意書の文言を信頼して日常的かつ大規模に行なわれる企業間の取引が，その信頼の基盤を失い，大きな支障を来すことは必定であり，経済社会に与える影響は図りしれない。本件においては，原告の主張するように文言を逸脱した解釈を行うことは断じて認められるべきではないのである。
（ク）　加えて，原告が「当事者の合理的意思」の基礎として主張する各事実は，いずれも失当である。
ａ　まず，本件最終合意書が平成１７年９月に締結された経緯は，原告の主張するようなものではなかった。当時，要件定義における現行の業務・システムの分析が遅滞していたこと，ＢＰＲにおける商品，取引，帳票等の削減等に対する非協力的態度に象徴されるように，原告が自分たちは９５億円以上支払うことはないから「あとは何から何まで全部被告にやらせてしまえばよい。ベンダである被告が何とかすべきだ」という非協力的な態度に終始していたこと等から，コストが増加することが明らかとなっていた。そのため，本件プロジェクトにおける開発費用等がいずれも未確定であって法的拘束力を持ったものではないことを改めて明確にする趣旨で，本件最終合意書を締結した。
ｂ　次に，原告は，甲４７の１の記載から，本件基本合意書①においては「概算見積り」を合意し，最終合意書においては「確定金額」を合意するという「２段階の合意」が原告及び被告双方が認識していた本件基本合意書①及び本件最終合意書の位置付けであったなどと主張する。しかし，被告もプロジェクト開始前に合意した本件基本合意書①の時点においては，「最終合意書」と称する本件最終合意書と性質の異なる合意書を交わすことができると考えられていたことについて争っているわけではない。被告は，そのような当初の見通しとは異なり，計画・要件定義＃１において「現行分析」ではなく「現行分析の準備」を行うことになってしまったこと，計画・要件定義＃２においてヒアリングをベースとして現行分析を行ったが現行の業務及びシステムを書面化するに十分な知識を持った者が原告にいなかったことから平成１７年５月からリバース・エンジニアリング等により現行を分析することとなったこと，ＢＰＲにおいて開発対象を絞り込むことができていなかったことなどから，当初「最終合意書」の締結を予定していた平成１７年５月ころには，いまだ，開発スコープ，開発費用及び開発期間を確度の高い形で見積もり，合意に至ることが不可能な客観的状況にあったことを指摘しているのである。そして，このような状況にあったことは，甲４７の１に，「業務要件の開発範囲・機能が５月末には概要レベルで合意でき，昨年９月時点の見積りコスト内に納められると予測しておりました」，「「ＢＰＲ」による開発対象基礎数値（目標値）の確定と合意が未済」などと記載されていることからも証拠上明らかである。
原告は，このような被告の客観的な状況に関する証拠に基づいた主張に何ら反論できていない。
この点につき，原告は，被告は契約締結のための膨大な時間と費用を掛けて「概算見積り」を２回もしようとしていたというのであろうかなどとも主張する。しかしながら，そもそも，本件最終合意書における８９億７０８０万円という金額は，本件基本合意書①における９５億円という金額から原告側において直接支出すべき費用（原告管理下での原告側要員費用，原告が富士通から購入するＳＭＩＬＥ端末費用及び同じく三菱東京ＵＦＪ銀行から購入するＭＢＡ費用）を差し引いたものにすぎない。すなわち，実質的には本件基本合意書①における９５億円をそのまま記載したにすぎないのであって，「見積り」を行ったものではないから，原告の主張はその前提を欠いている。
（ケ）　以上のとおり，本件最終合意書の法的拘束力に関する原告の主張はいずれも失当であり，本件最終合意書はその第８条に明記されているとおり，法的拘束力を有しないものであることは明らかである。
イ　本件本質的義務の法的拘束力
（ア）　本件最終合意書が法的拘束力を有しないものである以上，原告が主張する本件最終合意書に基づく本件本質的義務も法的拘束力を有しないものであることは明らかである。これは，これらの事項が「最終化」（本件最終合意書７条）しているか否かに関わらない。
すなわち，第１条における８９億７０８０万円という金額やその添付における「構築要件」（開発スコープ）及び「プロジェクト計画」（開発スケジュール）その他の記載を含む本件最終合意書全体につき，本件最終合意書８条において，原告と被告は明示的に「いずれの当事者も本合意書に基づき何らの法的義務を負わない」と合意した事実は動かないのであって，これにもかかわらず，原告の主張する本件本質的義務なるもののみが本件最終合意書に基づいて法的拘束力を有することなどあり得ない。
（イ）　原告は，パッケージ型システム開発においては，パッケージが決定されないことには，開発も開始することができないなどとし，システムに用いるパッケージは，システム開発の開始以前の段階において確定されなければならないことを，専門家の意見書を引用して主張し，Ｃｏｒｅｂａｎｋの採用は変更し難い「不可侵」の部分であったとしている。このような原告の主張及び原告側の専門家の意見書は，いずれも，「パッケージ」には様々な種類のものが存在することを一切捨象し，完成した既存のパッケージを適用するシステム開発を行うことを前提としたものとなっている。しかしながら，そもそもＣｏｒｅｂａｎｋ自体が完成したパッケージであるという前提自体が誤っている。Ｃｏｒｅｂａｎｋは，銀行の勘定系システムのプログラムを開発するための「部品」であるＡＰＩ及びデータベースの集合体にすぎない。
そして，ＮＥＦＳＳとＣｏｒｅｂａｎｋの関係を整理すれば，ＮＥＦＳＳというパッケージの中でＣｏｒｅｂａｎｋという部品が呼び出される関係にある。その結果，ＮＥＦＳＳというパッケージからみると，部品を他パッケージへ変更したり，Ｕｓｅｒ　Ｅｘｉｔと呼ばれる金融機関独自のプログラムを外付けで作成したりすることが可能である。
このように，ユーザからみれば，原告が主張するパッケージに該当するのはＮＥＦＳＳなのであり，ＣｏｒｅｂａｎｋはＮＥＦＳＳ内部で呼び出されている単なる部品にすぎない。
被告は，被告が販売するパッケージ（ソリューション）としての「ＮＥＦＳＳ（ＮｅＦＩＳ）」を，本件プロジェクトが開始された平成１６年９月よりも２年以上前である平成１４年６月ころから開発してきていた。そして，本件プロジェクトは，ＮＥＦＳＳの第１号案件であり，本件プロジェクトを通じてＮＥＦＳＳ／Ｃｏｒｅｂａｎｋという横展開可能なパッケージを完成させることが企図されていた。だからこそ，本件プロジェクトは，被告の投資案件として，被告からも多額の投資を行うものとされていたのである。
したがって，「Ｃｏｒｅｂａｎｋ」という完成されたパッケージを導入するプロジェクトであるという前提の上に立った原告の主張及び意見書は，①本件プロジェクトを通じてＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを完成させるという前提，及び②ＣｏｒｅｂａｎｋはＮＥＦＳＳの内部で呼び出されるＡＰＩ（部品）にすぎず，原告のいう「パッケージ」「ひな型」に該当するのはＣｏｒｅｂａｎｋではなくＮＥＦＳＳであるという前提をいずれも欠いているために，あるいは少なくともこれらの前提についての検討がなされていないために，無意味なものとなってしまっているのである。
以上のとおり，ＣｏｒｅｂａｎｋはＮＥＦＳＳの内部で呼び出される部品（ＡＰＩ）にすぎないことから，ＥＲＰパッケージ等の完成度の高いパッケージとは異なり，同様の機能を有する「部品」，例えばＴｅｍｅｎｏｓ社のＴＣＢであっても，ユーザからみたパッケージである「ＮＥＦＳＳ」において同等の機能を提供されていれば，目的を達成することができるものなのである。
したがって，本件プロジェクトにおいて，仮にＣｏｒｅｂａｎｋが使用されなかったとしても，原告の業務要件が実現される限り，どのＡＰＩを使用するかについて被告が法的な責任を負うものではない。被告が「Ｃｏｒｅｂａｎｋ」の採用が本件の非本質的部分であり，被告の法的義務を構成するものではないと主張するのはかかる意味においてであり，原告の上記主張は，この点に対する有効な反論となっていない。
（ウ）　原告は，本件プロジェクトにおいてＣｏｒｅｂａｎｋの採用が当事者間において前提とされていたことをるる主張する。しかし，被告においてもＮＥＦＳＳにおける勘定系構築の部品としてＣｏｒｅｂａｎｋを採用することを前提として莫大な投資を行ってきたのであり，争いがあるのは，Ｃｏｒｅｂａｎｋの採用が被告にとって法的拘束力のある義務であり，Ｃｏｒｅｂａｎｋの採用を義務の履行として強制することができるか否かという点である。
この点，そもそも，原告がＣｏｒｅｂａｎｋの採用を法的義務をもって定めたと主張する本件最終合意書自体に法的拘束力がない以上，原告の主張が失当であることはいうまでもない。
また，仮にこの点を措くとしても，前述のとおり，ＣｏｒｅｂａｎｋはＮＥＦＳＳ内部で呼び出されるＡＰＩの集合体であって，ユーザの業務要件を実現することができれば，プロジェクトの状況に応じて，より適切なパッケージの採用の検討を提案することができるものである。
（エ）　さらに，原告は，被告の主張について，「パッケージも当事者間で最終的には合意していなかったと主張しているのであるが，このような主張は単に失当であるのみならず，システム開発業者としては「非常識」かつ「無責任」極まりない」などと非難した上で，「システムに用いるパッケージは，システム開発の開始以前の段階において確定されなければならない」と断言する。しかしながら，本件システムの周辺サブシステムについても多数のパッケージが使用されているが，プロジェクトの開始時点では採用するパッケージが未確定のものがほとんどであり，要件定義の過程において使用するパッケージを確定していったのである。この客観的に明確な事実一つをもってしても，原告の「システムに用いるパッケージは，システム開発の開始以前の段階において確定されなければならない」という主張がＩＴシステム開発における常識とかけ離れたものであることは明白である。このように，要件を定める過程でパッケージを定めることはあり得ることであり，要件に合わなければパッケージを変更することもしばしば見られることなのである。
（オ）　仮に，原告が主張するように本件最終合意書に法的拘束力が認められるという前提をおいたとしても，本件最終合意書の第７条には，スコープ等は本件最終合意書時点では定まっておらず，後に「最終化」することが明記されている。すなわち，本件最終合意を締結した時点では，本件最終合意書に添付された「『新経営システム』構築に関する基本合意書（添付）」（以下「本件最終合意書添付資料」という。）に記載された事項は，全ていまだ確定したものではなく，これから「最終化」するものであったことは疑う余地がない。そして，本件最終合意書添付資料には，開発スコープ及びサービスインの時期についてそれぞれ記載されている。
したがって，開発スコープ及びサービスインの時期が，本件最終合意の時点において確定しておらず，「今後さらに協議をして，最終化」するものであったことは一見して明白である。原告が，本件最終合意書締結時点において，開発スコープ及びサービスイン時期について確定的なものとして請負契約上の義務であったと主張することは，「今後さらに協議をして，最終化する」ものがその時点で既に「最終化」していたと主張していることになるであって，被告にはその不整合を合理的に理解することができない。
この点，原告は，被告の主張について，「システムが完成するまでは，開発スコープに関する合意は「最終化」しないとでもいうのであろうか。システム開発の専門業者たる被告が，システム開発を行うスコープに関して，システムが完成するまで一切法的義務を負わないなどという極めて無責任な主張が認められてはならない」などと論難する。
しかし，本件プロジェクトは，超上流工程である要件定義が終わった後，設計・開発に入る前に，費用負担，開発スコープ及びサービスインの時期について協議している途中で頓挫したものである。原告の主張は，本件プロジェクトが「システム開発に被告が失敗した案件」であるかのごとき印象を与える言い回しをしているが，実際には「どのようなシステムを作るのかといういわば『入り口』のところで原告被告間の協議が決裂し，システム開発に着手できなかった案件」であるという客観的事実に反している。また，被告は，要件定義と外部設計が終わらなければ費用もスコープも期間も確定できないという一般論を前提に，本件最終合意が締結された時期は要件定義が始まったばかりの時期であった以上，費用，スコープ及び期間が確定できる客観的状況にはなかったこと，及び要件定義が終わった後である平成１８年９月以降，費用，スコープ及びサービスイン時期について協議が続けられていたことから，それらが確定した事項ではなかった，という当たり前の主張をしているのである。
したがって，原告が，被告が「システムが完成するまでは，開発スコープに関する合意は『最終化』しない」などと一見して不合理な主張をしているかのごとき印象を与えた上で，被告の主張が不合理であると非難してみても，全く無意味である。
（カ）　次のａないしｄのとおり，本件最終合意書に記載された開発費用は，いかなる意味でも原告の主張するような法的拘束力を有するものではない。
ａ　原告は，システム全体の開発費用を何ら合意することなく，全て各フェーズの個別契約に委ねるということは，ユーザはもちろんベンダにとっても，合理的意思とはいえないなどと主張する。しかし，かかる主張は，本件最終合意書の記載はおろかシステム開発の実務を無視するもので，完全に失当である。
そもそも，上述のとおり，本件最終合意書８条は，「いずれの当事者も本合意書に基づき何らの法的義務を負わない」と規定して，明確に法的拘束力がない旨を定めており，一流の大企業同士である原告及び被告が明示的にこのような合意をした以上，当事者の合理的意思の解釈と称して文言に反する解釈をすることは許されない。
仮にこの点を措くとしても，システム開発の局面ごとに個別契約を締結して契約関係を積み重ねていくという多段階契約の形式は，システム開発において一般的な実務となっている。特にある程度以上の規模のシステム開発においては，委託料，作業期間及び納期，成果物等を個別契約において定めるのが一般的であり，かかる実務は経産省モデル契約においても採用されている。
システム全体の開発費用を基本合意書等で合意することなく，各開発工程の個別契約においてそれぞれ委託料を定めるという多段階契約の方式は，ベンダのみならずユーザにとっても大きなメリットが存する。原告は，開発費用の上限を定めない場合は，予算の抑制が効かず業務委託費用が際限なく増える確率も高まり，結果としてプロジェクトが失敗する確率が高まることから，ベンダにとっても望ましくないなどと主張するが，これは，言い換えれば，プロジェクトの初期に不確定な見積りに基づき開発費用を確定額として合意した場合，プロジェクトの進展に伴って不可避的に生ずる開発費用の増額を全てベンダに負担させればいいというユーザ本意の一方的な契約解釈であり，このような解釈をされることこそがベンダにとって望ましくないから，特に大規模なシステム開発において多段階契約の方式が採用されるのであり，本件でも本件最終合意書が法的拘束力を有しないことを改めて確認するものとして締結されたのである。
ｂ　一般に「一括契約」といっても，それはあくまでも要件定義後の開発についての一括契約であるという点に留意する必要がある。原告も，プロジェクト開始前に締結された本件基本合意書①又は同②によって一括契約が成立したと主張しているのではなく，要件定義が９か月行われた後に締結された本件最終合意において，以後の開発作業について一括契約が成立したと主張している。
要件定義が終了（原告の主張では完全に終わらないまでも実質的に終わった段階であれば足りるとするようである。）する前に一括請負契約が締結されることは全く想定されていないのである。つまり，原告も，要件定義前の「見積り」が確定見積りでないことは争っておらず，本件では，本件最終合意書の段階で行われた見積りは「確定見積り」であって，拘束力があるものであると主張しているにすぎない。そうすると，この点に関する争点は，結局，①客観的状況において要件定義が実質的に終わっており「確定見積り」といえる状況であったかどうか，②仮に要件定義が実質的に終わっている客観的状況にあったと仮定して，それが法的な拘束力を持つ「確定見積り」として合意されたかの２点である。
ｃ　本件最終合意書が締結された平成１７年９月末の時点では，現行分析の作業の最中であり，要件定義の作業は同年９月初めから開始されたばかりであったことは一目瞭然である。この点に関し，原告は，「２段階の合意を行う予定であった」とするばかりであり，当初の予定と異なり要件定義の作業が遅れ，見積りを行う客観的状況になかったことについて，有効な反論をなし得ていない。
また，原告は，平成１２年から行われた原告の予備的検討から本件基本合意①及び本件最終合意の締結に至るまでの経緯から，被告が「開発費用の見積りに必要な基礎データを十分に把握した上で，本件最終合意書において８９億７０８０万円という開発費用に合意した」旨主張する。しかし，原告が行った本件プロジェクトに至る予備的検討の中で，被告が原告の作業に関与していたのは，原告が導入する次期システムにおいて新たに実現すべき項目（「変革のテーマ」）の洗い出しの検討に当たっての戦略的コンサルティング作業が中心であった。そして，その検討については，被告は原告から対価を一切受領していないのであって，被告としては，原告の次期勘定系システムの構築においてベンダとなれるよう営業活動の一環として関与していたにすぎない。また，かかる「変革のテーマ」において現行のビジネス及びシステム上の業務・機能の要件についてはほとんど検討の対象とされなかったのが現実である。そして，このような原告の現行のビジネス及びシステム上の業務・機能要件の調査に莫大な時間と労力を要し，また，原告が現行のビジネスの変革に消極的態度を示し，また現行システムの機能に固執した結果，本件システムの開発規模，開発費用等も大幅に増加することとなった。
このような経緯にかんがみれば，本件プロジェクト開始時において締結された本件基本合意①はもちろん，いまだ現行システムの分析の最中であった本件最終合意の締結段階においても，被告において開発費用の見積りに必要な基礎データを十分に把握していたといえる状況にないことは明白であり，原告の主張は前提を欠くのである。
ｄ　前記ア（ク）に記載のとおり，本件最終合意書における開発費用の額が法的な拘束力を持つ「確定見積り」として合意された事実はない。
（キ）　原告は，本件最終合意書において，あるいはプロジェクト開始当初から，被告が本件本質的義務として本件システムの開発スコープ及びサービスイン時期についても法的義務を負っていたと主張するが，この点についても，上記の開発費用と同様の議論が妥当し，原告の主張が失当であることは明らかである。すなわち，原告の主張は，①本件最終合意書において開発スコープ及びサービスインの時期が「今後さらに協議をして，最終化する」と合意されていること，②乙３１において，平成１８年１２月に，原告と被告の担当者がスコープの調整について協議を重ねていたという事実が存在すること等を無視したものであり，それこそ「後付け」の議論にすぎない。
また，甲７号証には，①「合意書時点の計画」「合意書時点での対象業務」として本件最終合意書添付資料に記載されたサービスイン時期及び開発スコープが記載され，②そして，それについてＢＲＤを経た後に行った費用の見積りが記載され，③当該見積りを踏まえての現実的な開発スコープ及び費用負担額が記載されている。かかる記載から，甲７号証は，本件最終合意書７条で「今後さらに協議をして，最終化する」と合意されたサービスイン時期及び開発スコープを記載した上で，その「協議」の一環としての「最終化」案を提案したものであることは一見して明らかである。
ところが，原告は，②をもって「本件プロジェクトが開始されて約２年が経過した時点でもなお，開発スコープは，本件最終合意書において合意した開発スコープと『変わらず』としている」から，ＢＲＤ終了後においても被告が開発スコープを本件最終合意書締結時点と「変わらず」と認識していたなどと主張するのであって，証拠の評価を誤っていることは明白である。むしろ，甲７号証によれば，費用負担額，開発スコープ及びサービスインの時期について「協議」が行われていたことが明らかなのであって，開発スコープ及びサービスイン時期が本件最終合意書締結時点で「最終化」した確定的な合意ではなかったことを雄弁に物語っている。
（ク）　原告は，被告が本件最終合意書のみならず，本件個別契約に基づき本件本質的義務を負う旨主張する。しかし，本件個別契約それぞれにおける被告の債務の内容は，本件システムを完成させるべき請負契約上の義務とは全く異なるものであり，失当である。
ウ　本件本質的義務の債務不履行
Ｃｏｒｅｂａｎｋの採用が不可能になったこと，及び被告がＣｏｒｅｂａｎｋの採用を断念したことに関する原告の主張はいずれも全く理由がない。
プロジェクト開始当初に予定されていたとおり，要件定義により何を作るのかが決まったところで見積りを行い，それに従って両者が協議し，費用の一部負担（９５億円＋２０億円），周辺系に関するスコープ調整及びサービスイン時期について原告の協力が得られていれば，あと１年から１年半でＣｏｒｅｂａｎｋを採用し本件システムを構築することは十分可能であった。そうでなければ，被告が，平成１９年１月に，２０億円の負担をすれば開発ができるから契約を締結するように要求したはずがないし，その時点で契約が締結されていれば，システムは完成していた。
ＴＣＢの提案は，原告が，被告によるこれらの提案に対し誠実に交渉に当たらず，不合理に強硬な姿勢で「交渉」を行い全く協力する姿勢を見せなかったことから，何とか本件システムを完成させるための別のソリューションとして，Ｃｏｒｅｂａｎｋとの選択的な追加提案として行われたものである。
原告は，ＴＣＢの提案をもって被告がＣｏｒｅｂａｎｋの採用を断念したという仮定の上に立ち，プロジェクトが開始され約２年７か月が経過した後に，突然，Ｃｏｒｅｂａｎｋを採用することはできないと言われ，被告に対する信頼を完全に失ったとか，システム開発において最も重要なベンダたる被告とユーザたる原告との間の『信頼関係』が完全に崩壊したなどとする。
しかし，「信頼関係」が崩壊したというのであれば，原告は，被告が本件プロジェクトによりＮＥＦＳＳを完成させられることを前提に１００億円を超える巨額の投資を行っていることを知って，「何らの法的義務を負わない」と明記され，「今後さらに協議して，最終化する」と明記された費用負担額，開発スコープ及びサービスイン時期に拘泥し，既に契約がなくなっていて被告としては開発体制を維持することができなくなっているにもかかわらず，不合理に強硬な態度をとり続けて被告に全てを押しつけようとしたものであって，平成１９年１月に被告が強く要請した契約の締結ができなかった時点で，「信頼関係」が崩壊し，実質的に本件プロジェクトは頓挫していた。
(2) 　争点(2)（本件プロジェクト中止の原因及びその責任の所在）について
（原告の主張）
ア　Ｃｏｒｅｂａｎｋの無謀な選択
システム開発委託契約を締結する際，システム開発の専門業者（ベンダ）は，発注者（ユーザ）の要望にかない，かつ，実際にシステムの実装段階で採用することが可能なアプリケーション・パッケージを選択し，それをユーザに提案しなければならない。システム開発の専門業者たるベンダが，実際にシステムに採用することが不可能なアプリケーション・パッケージを選択し，それをユーザに提案して，開発委託契約を獲得することが許されないのは至極当然のことである。
被告は，システム開発専門業者である以上，欧米で利用されているＣｏｒｅｂａｎｋの機能がどのようなものであり，Ｃｏｒｅｂａｎｋは，特有の業務が多々ある日本の銀行業務を支えるシステムのパッケージ足り得るのかなどを十分に吟味，検討し，Ｃｏｒｅｂａｎｋの著作権を保有するＦＩＳ社との権利関係を適切に処理し，結果，Ｃｏｒｅｂａｎｋを採用することが確実に可能であることが確認できた段階で初めて，Ｃｏｒｅｂａｎｋを選択し，ユーザである原告に提案しなければならなかった。
それにもかかわらず，被告は，この吟味，検討を十分に行わず，かつ，ＦＩＳ社との権利関係の処理も行うことなく，「見切り発車」的にＣｏｒｅｂａｎｋを選択し，原告に対しては採用することが可能なものとして積極的に提案した。
そして結局，本件プロジェクトが開始されて約２年半が経過した後に，Ｃｏｒｅｂａｎｋの採用が事実上不可能であることが明らかとなり，本件プロジェクトは頓挫した。
以上からすれば，被告は，Ｃｏｒｅｂａｎｋを採用することができない可能性があることを認識しながら，それを原告に提案したのであり，かかる提案は「杜撰かつ無謀」なものといわざるを得ず，被告は，結果（損害）の発生を少なくとも未必的に容認していたといわざるを得ない。この意味で，被告には（未必の）故意が認められる。また，被告は，情報システム開発の専門業者であるにもかかわらず，システムに採用できないかもしれないという事情を認識しながらあえてＣｏｒｅｂａｎｋを選択し，提案して，結局，Ｃｏｒｅｂａｎｋの採用ができなかったのであるから，少なくとも重過失が認められる。
イ　プロジェクト・マネジメント義務違反
（ア）　システム開発業者は，専門業者として，自らが有する高度の専門的知識と経験に基づき，ユーザとの合意に従って，システムを構築し，完成させる義務を負う。
したがって，システム開発業者は，納入期限までにシステムを完成させるように，ユーザに提示し，ユーザとの間で合意された開発手順や開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務を負う。そして，システム開発は，ユーザと打合せを重ねて，その意向を踏まえながら行うものであるから，開発業者は，ユーザのシステム開発への関わりについても，適切に管理し，システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユーザに働きかける義務（以下，これらの義務を総称して「プロジェクト・マネジメント義務」という。）を負っている。
（イ）　次の事実によれば，本件において被告にプロジェクト・マネジメント義務違反が認められるのは明白である。
ａ　本来，計画・要件定義＃２においてパッケージ・ベース・アプローチを採用し，Ｃｏｒｅｂａｎｋを有効活用するとともに，邦銀標準となり得るシステムの要件定義を完成させることが被告の義務であったにもかかわらず，被告はこれに失敗した。被告は，計画・要件定義＃２では誤った開発手法である現行踏襲型アプローチ（カスタマイズ・ベース・アプローチ）を採用してしまい，グローバルＩＢＭの指摘によりパッケージ・ベース・アプローチで旧ＢＲＤを実施するよう命ぜられた。
それにもかかわらず，被告は，旧ＢＲＤも現行踏襲型アプローチになっているとの指摘を再度グローバルＩＢＭから受けてしまい，再度ＢＲＤのやり直しが必要になって新ＢＲＤの実施を余儀なくされた。被告は，上記のような開発手法の誤りにより，要件定義作業のやり直しを都合３回にわたって行うことを余儀なくされ，本件プロジェクトを迷走状態に陥れたのであるから，被告がプロジェクト・マネジメント義務に違反したことに疑念を容れる余地はない。
ｂ　被告は，①被告とＦＩＳ社との契約交渉が難航しているのであれば，可及的早期に合意が形成できるよう対処し，②それに関してユーザである原告が決定すべき事項があれば具体的に課題と期限を示し，③複数の選択肢がある場合は利点と課題を示し，原告が必要な時期までに決定できるように導く義務を負っていた。
しかしながら，被告は，旧ＢＲＤの開始時も，また４段階サービスインを申し入れてきた平成１８年８月以降も，原告に対してＦＩＳ社との関係については一切具体的な説明をせず，事後的に謝罪をして新ＢＲＤを実施せざるを得ないことを承諾させたり，サービスイン時期や開発スコープの見直しについて度重なる申出を繰り返したにすぎない。
これでは，原告としては，本件プロジェクトが混迷している真の原因を知らされていないのであるから，挽回策の検討も協力もしようがない。その結果，本件プロジェクトは頓挫することを余儀なくされたのである。
したがって，被告は，少なくとも平成１８年２月以降，ＦＩＳ社との役割分担及び開発スケジュール等に関する交渉が難航していたにもかかわらず，この事実を原告に対して適時に開示して，当該リスク情報を共有し，原告と共同して当該リスクに対処しなかったことは明らかである。被告の当該行為は，プロジェクト・マネジメント義務の懈怠に当たる。
ｃ　プロジェクトマネージャーは，一般に組織の資源をプロジェクト活動に使用する権限を与えられ，プロジェクト達成の責任を持つ，プロジェクトの要となる要員である。プロジェクトマネージャーはプロジェクトの初期に任命され，プロジェクトが終結（完了）するまでその任に当たる。プロジェクトの遂行には困難が伴い，開発期間全体で首尾一貫してマネジメントしてゆく必要がある。
しかし，本件プロジェクトにおいては，プロジェクトマネージャーが度々交代し，特に新ＢＲＤ以降は頻繁に交代した。特に，被告の開発手法の誤り（本件プロジェクトはパッケージ型システム開発であるにもかかわらず「カスタマイズ・ベース・アプローチ」の開発手法を適用してしまったこと）が失敗であるとグローバルＩＢＭにより指摘されてから以降は，グローバルＩＢＭが突如として開発に参画してくるようになり，被告とグローバルＩＢＭ間での責任分担が不明確になって，適切なプロジェクト・マネジメントが実施できない状況に陥ったと考えられる。
また，システム開発は，ユーザがシステムで実現したいことやユーザの業務内容をベンダの開発担当者に対して説明し，「知識の移転」を行う作業である。そのため，開発要員に交代があると，再び最初から説明を実施する必要があり，開発上非効率である。特に，開発開始から時間がたてばたつほど，多くの知識を再度短時間で移転させることが必要になるため，要員の交代は作業効率を著しく損なうことになる。要員調達は，必要な要員が必要な時期に投入され，作業が終了したら離任するというのが基本である。上記のようなシステム開発の特性から，要員の交代は開発の遅れや費用の増加を招く。
被告は，この点でもそのプロジェクト・マネジメント義務に違反した。
ｄ　本件プロジェクトのように大規模なパッケージを用いた基幹システムの開発プロジェクトにおいては，パッケージのカスタマイズに関する作業量，作業期間，費用が大きなものとなるため，カスタマイズ作業を適切に実施できる体制が整えられているか否かがプロジェクトの成否に直結する重要なポイントである。開発プロジェクトの中心的な，かつ最も難易度が高い作業は，パッケージのカスタマイズ作業だからである。
汎用的に作られているパッケージを特定の企業向けに適合させるには，対象となるパッケージについての相当なノウハウの蓄積が必要となる。パッケージ全体について，企業に適合するように機能の組合せを決めるときには，パッケージを熟知している優秀なＳＥでも矛盾を避けられないことが多い。このため，パッケージを活用してシステム構築を行う場合には，対象となる業務及びパッケージを熟知しているパッケージ業者がプロジェクトに参加することが絶対条件となる。
したがって，本件プロジェクトにおいても，平成１６年９月のプロジェクト開始当初から，本件プロジェクトの主要メンバーとしてＦＩＳの要員を本格的に参画させておくべきであった。このような適切な体制を組むことも，システム開発のプロであるベンダがプロジェクト・マネジメント義務の一つとして負う義務である。
Ｃｏｒｅｂａｎｋを最もよく知るＦＩＳ社の要員がプロジェクトの当初から本格的に参画する体制が組まれていれば，Ｃｏｒｅｂａｎｋの機能を考慮することなく，原告の現行システムのリバースエンジニアリングを実施し，著しく詳細な現行システム調査を行ってまでカスタマイズ・ベース・アプローチを採用するという基本的かつ致命的な過ちを犯すことは避けられた。
Ｃｏｒｅｂａｎｋに真に精通した者が参画していれば，被告が採用した開発手法で作成される要件定義書の内容がＣｏｒｅｂａｎｋと著しく乖離したものになることは容易に予想できることであり，それよりもＣｏｒｅｂａｎｋのカスタマイズ量を極力削減することが可能なパッケージ・ベース・アプローチを採用したであろうことが蓋然的だからである。
以上からすれば，被告がカスタマイズ・ベース・アプローチという誤った開発手法を採用してしまったのは，被告の本件プロジェクトに参画したメンバーにＣｏｒｅｂａｎｋに精通した者がほぼ皆無だったことによると考えられる。Ｃｏｒｅｂａｎｋの機能を熟知していなければ，Ｃｏｒｅｂａｎｋの機能を前提として，それとユーザの要望とに係るＦＩＴ／ＧＡＰを分析する作業などできようはずがないからである。
よって，この点でも，被告にはプロジェクト・マネジメント義務違反が認められる。
なお，被告は，ＦＩＳ社の要員がプロジェクト開始当初から参画しなかった問題について，本件プロジェクトはＮＥＦＳＳプロジェクトの一部の個別プロジェクトにすぎず，そのためＦＩＳ社の要員を参加させないのは当然のことであったと主張している。
この主張が本件訴訟のための後付けのものでなく，本件プロジェクトの当時からこのように考えていたとすれば，それこそが本件プロジェクトを頓挫に導いた最も重要な原因というべきである。被告は，本件プロジェクトとは別個独立のプロジェクトとしてＮＥＦＳＳプロジェクトなるものが存在し，本件プロジェクト以外にもＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを用いるプロジェクトが存在していたかのごとく主張しているが，事実に反している。本件プロジェクトこそが邦銀標準の勘定系パッケージとしてＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを完成させるための唯一のプロジェクトであった。したがって，本件プロジェクトにＦＩＳ社の要員を参画させなければ，他に参画させる場などなかったのである。そして，被告が現行踏襲型アプローチという誤った開発手法を採らざるを得なかった原因は，Ｃｏｒｅｂａｎｋに精通した者が本件プロジェクトに参画していなかったという点にある。ＦＩＳ社の要員が参画せずに行われた旧ＢＲＤがグローバルＩＢＭの指摘により中止を命ぜられ，ＦＩＳ社の要員を参画させて新ＢＲＤをやり直さざるを得なかったことから明らかなように，パッケージ・ベース・アプローチで行うためには，本件プロジェクトの開始当初からＦＩＳ社の要員を参画させておくことが必要不可欠だったのである。
ｅ　本件プロジェクトにおいては，米国製のＣｏｒｅｂａｎｋという海外パッケージを邦銀初の試みとして採用することとされた。そのため，Ｃｏｒｅｂａｎｋと邦銀の業務との間にはビジネス（業務プロセス）の考え方にかなり相違があること，邦銀の業務に対するＣｏｒｅｂａｎｋの乖離（ＧＡＰ）がかなり大きいことは必然であり，大規模なカスタマイズが必要となることは事前に分かり切ったことであった。
このような状況にあっては，ベンダである被告には，コーザである原告及びＦＩＳ社などの利害関係者との利害関係を調整し，かつ協力して本件プロジェクトを推進させるという高いマネジメント力及び折衝力が求められる。しかも，本件プロジェクトにおいては，被告には改変権がなく，ＦＩＳ社のみがこれを有していたのであるから，ＦＩＳ社との利害調整をうまくマネジメントすることは必須の条件であった。ＦＩＳ社との役割分担等の調整がうまくいかず，ＦＩＳ社がカスタマイズを行わないという状態に至れば，Ｃｏｒｅｂａｎｋを採用することができず，本件プロジェクト自体が頓挫するという事態に至るからである。
しかるに，被告は，開発手法の誤りによる度重なる迷走などによって原告との間の「信頼関係」を崩壊させ，ＦＩＳ社との間の役割分担等の協議も失敗し，その結果，本件プロジェクトを頓挫させた。被告は，原告及びＦＩＳ社との役割分担等の協議，調整に失敗し，本件プロジェクトを頓挫させたのであるから，被告にプロジェクト・マネジメント義務違反が認められ，その責任を負わなければならないのは当然の帰結である。
ｆ　被告がＣｏｒｅｂａｎｋの改変権を有していないこと及びＣｏｒｅｂａｎｋがＦＩＳ社という海外ベンダの提供によることに起因して生じるリスク（ＦＩＳ社との協議が失敗すればプロジェクト自体が頓挫してしまうリスク等）を原告に対して一切説明しなかったことも，重大なプロジェクト・マネジメント義務違反を構成する。すなわち，システム開発プロジェクトにおいては，リスクマネジメントもプロジェクト・マネジメントに含まれるところ，被告は，上記のリスクを原告に開示し，これに対する適切な対応策を講じること（リスクマネジメント）を一切しなかった。そして，結局，このリスクが顕在化して本件プロジェクトは頓挫したのである。この点が被告の説明義務違反を構成するのと同時に，重大なプロジェクト・マネジメント義務違反をも構成するのである。
また，被告は，本件プロジェクトが頓挫する直前になってＦＩＳ社等の「外部依存関係の評価」を行い，ＦＩＳ社の開発能力に疑問を呈している。これは，本件プロジェクトが開始される前にＣｏｒｅｂａｎｋの提供者であるＦＩＳ社に関するリスクを検討していなかったことを明確に示しており，リスクの高い海外パッケージの採用を予定していた本件プロジェクトにおいては，致命的な過ちである。
ｇ　以上のとおり，被告には重大なプロジェクト・マネジメント義務違反が認められ，その結果，本件プロジェクトが頓挫に至り，原告に多大な損害が生じたのは明らかである。
ウ　協力義務違反の不存在
原告には本件プロジェクトについての協力義務違反があるという被告の主張については争う。この点に係る被告の主張，反論は，断片的な証拠を誇張ないし誤用して作り上げたフィクションにすぎない。
（ア）　２０億円の追加負担の交渉に関する協力義務違反
本件最終合意書の変更契約をめぐる交渉の経緯からすれば，原告は，被告のいうように「強硬な姿勢で交渉を続ければ被告は必ず折れる」などと考えて交渉していたわけでもなければ，Ｃ代表取締役専務（肩書は当時。以下「Ｃ専務」という。）らの「責任回避」のために交渉を行っていたわけでもない。原告は，ときにはハードに交渉しながらも，本件プロジェクトを何とか軌道に乗せようとする一念で誠実に交渉を行っていた。
仮に，被告が，「原告が追加して２０億円を支払えば，本件システムが完成する（２０億円以上追加負担が発生しない）」ということを合理的な根拠をもって説明していれば，原告は喜んで支払うと言ったはずである。しかしながら，被告が開発手法を誤り，かつ，自らの約束を簡単に反故にするなどして本件プロジェクトが混迷を極めていた当時の状況にあっては，原告からすれば，「もはやＩＢＭの言うことは容易には信じられない」「ＩＢＭの提案を鵜呑みにすれば，再び失敗を繰り返すことになるのではないか」と考えざるを得ない状況にあった。
これは，それまでの被告の態度に照らせばやむを得ないことであり，原告がこのように考え，慎重に２０億円の追加負担についての根拠を検討する姿勢をとったことをもって原告に協力義務違反という法的責任を負わせるのは，明らかに公正を欠くものである。
（イ）　商品数，帳票数の削減に関する協力義務違反
原告は，本件最終合意を締結する際に９５億円という金額の前提とされた商品数（融資は８９８商品，預金は１９商品）まで，ＢＰＲにおいて削減を行ったし，新ＢＲＤの結果，新たにＣｏｒｅｂａｎｋには機能がないと判明した商品やサービスについて，廃止したり，Ｃｏｒｅｂａｎｋの機能に沿うように変更したりした。
また，原告は，帳票数についても，９５億円という見積りの前提とされた数（１６１８個）まで，これを削減した。
（被告の主張）
ア　Ｃｏｒｅｂａｎｋの無謀な選択について
Ｃｏｒｅｂａｎｋの選択に関する原告の議論は，ＮＥＦＳＳとＣｏｒｅｂａｎｋを混同したものであり無意味であるし，被告には，Ｃｏｒｅｂａｎｋの選択に関する義務に違反した事実がないことは，前記(1)（被告の主張）欄ウ記載のとおりである。
イ　プロジェクト・マネジメント義務違反について
（ア）　計画・要件定義＃１・２の後，旧ＢＲＤ及び新ＢＲＤを実施したが，それは要件定義をやり直したものではない。すなわち，それぞれの作業を極めて簡略化していうと，要件定義は，現行の業務及びシステムをベースに，どのようなシステムを作るのかを定義したものであり，ＢＲＤは，まず邦銀標準の業務フローが何かを確定し（旧ＢＲＤ），その業務フロー及び要件定義書とＣｏｒｅｂａｎｋとのＦＩＴ＆ＧＡＰの作業を行ったもの（新ＢＲＤ）であって，繰り返しが行われていないことは客観的に明らかなのである。
当初平成１７年９月あるいは１２月までに終了する予定であった要件定義の作業が，平成１８年３月末まで，ＢＲＤまで含めれば同年８月末までかかったことは事実であるが，やり直しをした事実はないのであって，原告の認識はこの点において根本的に誤っている。
（イ）　本件プロジェクトの開始当初は，原告の現行の業務及びシステムを前提に本件システムを開発し，その中から邦銀標準を抽出する形で横展開することを想定していた。ところが，商品数や帳票数が当初の予定より大幅に増加するなど原告がプロジェクト推進に非協力的な態度を見せたことや，リバース・エンジニアリングを行ったりしたこと等が原因で見込まれるコストが大きく増加したことから，先に「邦銀標準」を確定し，それになるべく合わせる形で本件システムを開発することで，被告として投資できる額を大きくし，原告の費用負担額を抑えようとした。これを被告のプロジェクト・マネジメント義務違反と称することなどできないことは明らかである。
そもそも，要件定義を行う前に，現行分析を時間と費用をかけて行う必要が生じたのは，原告に現行の業務及びシステムについての資料も知識もなかったからであって，現行分析を行わざるを得なくなったことについて，原告が被告を非難するのは全くの筋違いである。
（ウ）　そもそも，本件プロジェクトにおいては，平成１８年３月末までに要件定義の作業が終了し，同年８月末にはＢＲＤが終了している。そして，原告は，プロジェクトが頓挫した原因は，被告がＦＩＳ社との権利関係の調整ができなかったこと，あるいはＣｏｒｅｂａｎｋが使い物にならないものであったためにＣｏｒｅｂａｎｋを使用したシステム構築が不可能になったことにあると主張している。そうであるとすれば，ＢＲＤ終了までに要件定義を３回繰り返したという原告の主張は，それを前提としてもプロジェクトを頓挫させた原因ではないことになるのであって，仮に，要件定義及びＢＲＤが完了するまでの過程で，被告のプロジェクト・マネジメントには全く一貫性がなかったという前提の上に立ったとしても，要件定義及びＢＲＤの作業の過程自体から生じた独自の損害があれば別論，そうでない以上，これを不法行為であるとして損害賠償請求することはできないのであって，原告の主張はそもそも失当である。
（エ）　原告は，ＦＩＳ社との交渉が難航していた事実を適時に開示し，原告と共同してリスクに対処しなかったとか，ＦＩＳ社との役割分担等の協議に失敗したことがプロジェクト・マネジメント義務違反を構成するなどと主張する。
しかし，後記ウ（イ）記載のとおり，原告は，ＮＥＦＳＳに莫大な投資を行っている被告が後に引けないことを知悉して，スコープについても費用負担額についてもいったんは合意するそぶりを見せながら，これを覆し，不合理に強硬な交渉態度に終始し，被告が要請する平成１８年１２月あるいは平成１９年１月の契約締結を拒否して本件プロジェクトを頓挫させたのであり，上記主張は無意味である。
（オ）　被告側の体制に，様々な人材が投入されているのは，何とかプロジェクトを成功させようとする被告の努力の表れであり，キーとなる人材のほとんどが留任しつつ追加の人材が投入されていることからもそれは明らかである。
本件プロジェクトは，要件定義が進むにつれ，当初の想定よりも主としてコストの点に大きな問題を抱えていることが分かった。そこで，ＩＢＭ　ＡＰ（アジア・パシフィック）及び米国ＩＢＭの専門家がレビューを行い，被告と解決策を検討し，必要な人材を次々投入して成功させようとしていたのである。トラブル・リスクの予兆があれば，社内あるいはその上位組織のレビューが入ることはあらゆるベンダにおいて行われていることであり，そこでプロジェクトを停止したりせず，世界中から人材を投入したことをもって，プロジェクト・マネジメント義務を果たしていると評価されることはあっても，かかる義務の違反を指摘される道理はない。
（カ）　被告においては，本件プロジェクト開始よりも２年以上前からＮＥＦＳＳプロジェクトが進行しており，原告の本件プロジェクトは，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを使用した第１号案件であった。被告としては，銀行業を生業とする原告の勘定系システムの構築プロジェクトを通じて具体的な要件をＮＥＦＳＳ／Ｃｏｒｅｂａｎｋに取り込み，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを「横展開」可能なパッケージ・ソリューションとすることが企図されていた。そして，それにより，原告は，開発費用の一部のみを負担することでシステム構築が可能になるという利益を享受していたのである。
したがって，ＮＥＦＳＳ内部で呼び出すＣｏｒｅｂａｎｋについては，ＮＥＦＳＳプロジェクトにおいて，ＦＩＳ社担当者と極めて密接に連絡を取り合ってＪａｐａｎｉｚａｔｉｏｎ等を行っていたのであって，個別プロジェクトである本件プロジェクトに，ＦＩＳ社の担当者を参加させないことは当然のことであった。しかし，要件定義を行う過程で，想定よりもコストがかかることが見込まれたため，まずＮＥＦＳＳ／Ｃｏｒｅｂａｎｋで実現する「横展開」可能な「邦銀標準」を確定し，それとＣｏｒｅｂａｎｋの機能とのギャップを開発の中心とすることとしたため，その段階から，個別プロジェクトである本件プロジェクトにも，ＦＩＳ社の担当者を直接関与させた方がよいと判断した。
したがって，当初からＦＩＳ社担当者が本件プロジェクトに直接関与していないことがプロジェクト・マネジメント義務違反を構成することはない。
（キ）　Ｃｏｒｅｂａｎｋの改変権については，改変権がないとしても改変を行うに適切な体制が組まれていたし，そもそもＣｏｒｅｂａｎｋの改変権がないことがプロジェクト頓挫の要因ではないから，原告の主張はその前提を欠く。
ウ　原告には重大な協力義務違反がある
（ア）　システム開発の作業は，ユーザとベンダの共同作業なのであって，ベンダがプロジェクト・マネジメント義務を負うことに対応して，ユーザにおいても，システム開発のために必要な協力を行うべき協力義務がある。
まして，本件プロジェクトは，被告が平成１４年から１００億円以上の投資を行いＮＥＦＳＳの開発を進めていたところに，そのＮＥＦＳＳの第１号案件として始まったものであり，本件プロジェクトを通じてＮＥＦＳＳを「横展開」可能なレベルの商品とすることにより，原告は本件プロジェクトにおける開発費用の一部のみを負担することで足りるという利益を享受していた。そうでなければ，平成１８年１２月に費用負担の提案をした際に，２０億円を原告の負担とし，１００億円を被告の負担とすることなどあり得ない。このような性質を有する本件プロジェクトは，原告と被告の共同作業としての色彩は極めて強いのであって，原告の協力義務も，一般的な「システム発注者としてのユーザ」と「システム開発受託者としてのベンダ」という関係におけるユーザの協力義務より，高度なものが課せられていた。そして，このことを原告もよく承知していた。
（イ）　それにもかかわらず，原告は，単なる「お客様」としての原告と「出入り業者」としての被告という程度を越え，本件プロジェクトが成功裡に終わらなければ１１０億円ものＮＥＦＳＳへの莫大な投資が全て無駄になってしまうという弱みにつけ込んで，何でも被告に押し込むことで，何かを勝ち取ったかのような勘違いを続けていた。
具体的には，①要件定義の前提として必要な現行の業務及びシステムの分析の必要性を認めようとせず，資料すら満足に提供せず，②ＢＰＲにおいて商品数・帳票数の削減を行わず，③ＢＲＤの過程においても現行の業務に固執して帳票数の削減すら拒み，④現行の業務・機能に固執して開発スコープの調整等に応じなかった挙げ句，⑤「何らの法的義務を負わない」（第８条）ことが明記されており「今後更に協議」（第７条）をするとされている本件最終合意書の８９．７億円という負担額，開発スコープ及びサービスイン時期に固執し，「自分たちはそれ以上払う事はないから何から何まで被告の作業に押し込んでしまえばよい。あとはベンダである被告が何とかすべきだ」などという不合理に強硬な態度に終始して，一切の妥協をしなかった。
そして，⑥要件定義終了後の見積りにより総開発費用が算出された際に，被告は，１０７億円分をスコープ調整等やスケジュールの変更等によりコスト削減した上で，被告が１００億円を，原告が２０億円をそれぞれ負担する案を提案した。当時，平成１８年１２月１８日以降は原告被告間に契約が存在しなくなり，プロジェクトの開発体制を維持するためには，被告は回収できるのかの見通しもない中で下請会社の要員の費用の支払等毎月数億円の負担をしなければならない状況にあったのであり，原告もそのことは承知していた。それにもかかわらず，原告は，ＮＥＦＳＳに莫大な投資を行っている被告が後に引けないことを知悉して，スコープについても費用負担額についてもいったんは合意するそぶりを見せながら，これを覆し，不合理に強硬な交渉態度に終始し，被告が要請する平成１８年１２月あるいは平成１９年１月の契約締結を拒否した。この点について，被告より提案された２０億円の追加負担について拒絶したことなど一度もないとする原告の主張は明確に事実に反している。
原告は，常に被告と対峙する姿勢を見せ，例えば，被告が資料を要求すればそれが必要ではない旨を延々と論じて提供を拒否したり，現場で事実上合意ができたことをステコミに上程すると不合理にも拒否したり，ステアリング・コミッティに被告が提案をしただけでなぜそのようなものを突然持ち出すのかなどと被告を非難するなど，常に「どちらが悪いのか」という発想で物事を捉え，必ず責任が被告にあることを認めさせようとしていたのである。このような姿勢では，ユーザとベンダの共同作業であるシステム開発がうまくいくはずがない。
被告が主張するユーザの協力とは，このような原告の姿勢をいっているのであって，「顧客」である自分が強硬なポジションで交渉をすれば，「業者」でありＮＥＦＳＳに莫大な投資をしており原告が本件プロジェクトから降りればその投資が水泡に帰すことになる被告は必ず折れると原告が信じていたのだとすれば，それ自体が違法行為であったと評価されるべきものである。
（ウ）　以上のとおり，原告には，協力義務違反が認められるから，プロジェクト頓挫についての帰責性を論ずるとすれば，それは原告の責めに帰すべき事由による。
本件プロジェクトは，要件定義及びＢＲＤの作業により何を作るのかが定まった後で，当初から予定されていたとおり見積りを行い，スコープ，費用及びサービスインの時期について協議をしたが，原告がこれを頑として受け入れず，設計・開発作業を被告に発注しなかったために頓挫したのである。
なお，原告は平成１９年４月１８日に被告がＣｏｒｅｂａｎｋの代替案としてＴＣＢの採用を提案し，Ｃｏｒｅｂａｎｋを採用して本件システムを完成することができなくなったことをもって本件プロジェクトが頓挫したと捉えているが，本件において，同日当時Ｃｏｒｅｂａｎｋの採用は可能であり，現在においても可能であって，原告の主張には理由がない。
エ　定量的分析による本件プロジェクトの頓挫原因
（ア）　ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋの機能の充足度
ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを被告が提案した際に，原告のいう邦銀の勘定系システムにとって必要な機能を充足しない「使い物にならない」パッケージであり，被告がＮＥＦＳＳ／Ｃｏｒｅｂａｎｋの機能充足度を見誤っていた旨の主張は，仮に妥当するとしても，わずか１５．４％についてのものにすぎないのであり，したがって，使い物にならないパッケージであり，被告がＮＥＦＳＳ／Ｃｏｒｅｂａｎｋの機能充足度を見誤っていたという結論を導くような割合ではないのであるから，これがプロジェクトの頓挫原因であるとするのは，全くの誤りである。
（イ）　開発フェーズのコストの見積りが増大した原因
本件プロジェクトは，開発フェーズに係るコストの見積りが１０５億円から２２６億円に増加した原因について，定量的分析をすると，邦銀標準のパッケージを作るための費用の増加が被告側，銀行によって内容が異なる要件及び原告独自の要件を開発するための費用の増加が原告側という，本来在るべき分類によれば，原告側に原因があるものが９１．９６億円（８２．８５％），被告側に原因があるものが１９．０４億円（１７．１５％）となる。そうすると，８２．８５％という圧倒的な割合で，原告側の原因によって見積りが増加しているし，仮に，本件最終合意書締結後に新たに判明した要件のみが原告側の原因によるものだという前提に立ったとしても，なおも５６．３２％という過半の割合が，原告側の原因によって開発フェーズのコストの見積りが増加したためである以上，本件プロジェクトが頓挫した責任がもっぱら原告にあることは明らかである。開発フェーズのコストの見積りが増大した原因の責任の一部が仮に被告側にあったとしても，原告に責任があるか，被告に責任があるかという意味では，本件プロジェクト頓挫の責任は被告にはなく，原告にある。
しかも，極めて重要なことに，Ｃｏｒｅｂａｎｋの機能の充足度の不足なるものは，１９．０４億円のことをいっているにすぎない。原告は，見積り全体のわずか８．８１％，見積りの増加額でいっても１７．１５％にすぎない要因を指して，これがコスト増加の最大の要因でありプロジェクトが頓挫した本質的原因であるなどと主張し，客観的な事実に反する事実認定を求めていることになる。
(3) 　争点(3)（本件個別契約の債務不履行解除の成否）について
（原告の主張）
前記前提事実(9)セ記載のとおり，原告は，平成１９年７月１８日，被告に対し，被告の債務不履行を理由として，本件最終合意書及びこれに関連する全ての本件個別契約を解除する旨の意思表示をした。
（被告の主張）
原告は，Ｃｏｒｅｂａｎｋの採用に関する善管注意義務違反，説明義務違反及びプロジェクト・マネジメント義務違反に基づき，本件個別契約全部の解除を主張している。
しかしながら，契約の目的を達成するのに必須とはいえない付随的義務の違反が契約の解除原因とはなり得ない。すなわち，かかる付随義務の不履行があったとしても，本来的かつ主要な債務の履行が完了していれば，本旨履行が行われている以上，契約を解除することはできない。
これを本件についてみるに，各本件個別契約は，それぞれ，本来的かつ主要な債務として独自の成果物の納入義務やサービスの提供義務を定めており，これらの債務こそが各本件個別契約の契約金額と対価性を有するものであり，これらの義務が被告により履行され，原告が検収を終えていることは争いがない。
したがって，本件各個別契約の解除は認められない。
(4) 　争点(4)（説明義務違反の有無）について
（原告の主張）
ア　専門業者とそうでない者が契約を締結する際，専門業者は，相手方当事者の知識，経験，能力等に応じて，当該取引により生じ得る利害得失を判断するのに必要かつ適切な情報（リスク情報も当然含む）について説明する信義則上の義務を負う。これは，高度かつ複雑な専門知識及び技術が必要となるシステム開発についても等しく当てはまることであり，システム開発業者は，専門家として，システム開発において生じ得る利害得失を判断するのに必要かつ適切な情報（リスク情報も当然含む）を，ユーザに対して説明する信義則上の義務を負う。
そして，システム開発の専門業者たるベンダは，パッケージを用いたシステム開発に際しては，パッケージの選定に当たって，パッケージの機能，性能，設定・導入の容易性，導入実績，パッケージの提供者（パッケージベンダ。本件でいえばＦＩＳ社。）の導入実績，経営の安定度，技術力，カスタマイズへの積極性その他関連する諸事情を総合的に考慮して，ユーザが構築しようとしているシステムに最適なパッケージを選定し，提案しなければならない。仮に選定したパッケージが，ユーザの構築しようとしているシステムに適合しなければ，それを前提とした費用，スケジュール，開発体制その他一切の開発計画が無意味なものとなる。したがって，ベンダは，ユーザに対する提案前に様々な観点から十分なリスク分析を含めた検討を行う必要がある。
ベンダは，このような検討を行った上で，リスクについて十分にユーザに説明し，リスクの存在及び内容を理解させた上で，ユーザに最終的に当該パッケージを採用するかを判断させなければならない。ベンダはシステム開発のプロであり高度の専門的知見を有するのに対し，ユーザはこの点では素人であり，特にパッケージの機能等に関する予備知識がほとんどないことが通常だからである。
すなわち，ベンダは，ユーザに対して，導入の可否に関する判断の機会を与えるために，専門家として，当該パッケージの選定のリスクに関する説明義務を契約上の責任として負うのである。
イ　大規模なパッケージを用いた基幹システムの開発プロジェクトを行う場合で，かつ，日本において導入実績がない海外のパッケージを初めて日本において導入するような場合，ベンダは，改変権の有無，（改変権がない場合には）パッケージベンダが自ら行うカスタマイズに協力的か否か，パッケージベンダの能力，評判，開発拠点の分散の有無その他パッケージに関する諸事情を総合的に検討して，慎重にリスク分析を行い，リスクに対する対応策を検討しなければならない。
そして，これらの検討を経た上で，ベンダは，当該海外パッケージに関連するリスクをユーザに対して十分に説明して対応策を協議し，当該リスクを十分に理解させた上で，ユーザに当該パッケージを採用するかどうかの意思決定をさせなければならない。仮に，ベンダが，改変権を有しておらず，パッケージの改変はパッケージベンダに依存せざるを得ない状況であるにもかかわらず，ベンダが，ユーザに対して，当該リスクを説明し，十分理解させ，かつ，リスクへの対応策を協議した上で，ユーザに当該パッケージの採用を意思決定させてプロジェクトを開始しなかった場合，当該ベンダは，当然，説明義務違反の責任を負わなければならない。
ウ　以上を本件についてみるに，Ｃｏｒｅｂａｎｋは，これまで日本において導入実績がなく，かつ，海外のパッケージベンダであるＦＩＳ社から提供を受ける予定であった。また，開発の対象となるシステムが邦銀の基幹システムという極めて大規模なものであったことから，Ｃｏｒｅｂａｎｋに加えるカスタマイズの規模は大規模なものが予定されていた。
それにもかかわらず，Ｃｏｒｅｂａｎｋについて改変権を有するのはＦＩＳ社のみであって，被告はＦＩＳ社にＣｏｒｅｂａｎｋの改変を「要求」することができるのみであった。かかる状況にあっては，Ｃｏｒｅｂａｎｋのカスタマイズは，ＦＩＳ社に対して全面的に依存せざるを得ないのであり，ＦＩＳ社が承諾しなければＣｏｒｅｂａｎｋの改変を一切実行することができない。
したがって，被告とＦＩＳ社との間で役割分担や開発スケジュール等についての交渉や調整が不調となった場合，Ｃｏｒｅｂａｎｋのカスタマイズができないということになり，これを基盤に据えて本件システムを構築することが不可能となって本件プロジェクト自体が頓挫するという重大なリスクが存在した。加えて，ＦＩＳ社が海外のベンダであることに伴うリスク及びその開発拠点もコペンハーゲンその他２か所に分散していたことに伴う開発の困難性，非効率性，不確実性といったリスクも存在していた。
Ｃｏｒｅｂａｎｋの採用には，このような幾つもの重大なリスクが存在していたのであるから，被告は，ユーザである原告に対して，当該リスクを少なくとも本件プロジェクトが開始された本件基本合意①の締結前に十分に説明し，これを理解させ，万全な対応策を立てた上で，Ｃｏｒｅｂａｎｋの採用を意思決定させなければならなかった。
仮に，被告がこのような説明をしていれば，原告としては，ＦＩＳ社も契約当事者として三社契約を締結して，原告に対する法的義務をＦＩＳ社に直接負わせたり，本件プロジェクトの当初からＦＩＳ社が主体的に参画する体制の整備を被告との間の契約条件としたり，原告もＦＩＳ社との間で交渉したりするなど，リスクを低減する方策はいくらでもあったのである。
それにもかかわらず，被告は，原告に対して本件基本合意①を締結する前に一切の説明もせずに，原告をしてＣｏｒｅｂａｎｋの採用につき意思決定をさせたのであるから，被告が説明義務違反の責めを負わなければならないのは当然である。
そして，結局，上記リスクが現実化して本件プロジェクトが頓挫したことからすれば，被告の説明義務違反は極めて重大であり，その責任は重いといわざるを得ない。
（被告の主張）
ア　Ｃｏｒｅｂａｎｋのようなパッケージ・ソフトにおいては，ソース・コードを改変する権利がパッケージベンダから第三者に付与されることは一般的ではなく，原告も，（「ＮＥＦＳＳ」ではなくＮＥＦＳＳを構成する「部品」の一つである）ＣｏｒｅｂａｎｋはＦＩＳ社が改変していることは認識しており，それが両当事者の当然の前提となっていた。被告に改変権がないことを知らなかった，ひいてはそれについての説明義務違反があるなどという主張は，それこそ後付けの主張である。
イ　一般論として，「大規模なパッケージを用いた基幹システムの開発プロジェクトを行う場合，プロジェクトにおいて中心的でかつ最も難易度が高い作業は，パッケージのカスタマイズ作業である」とする原告の主張は誤りである。
もっとも，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋは，本件プロジェクトを含む平成１４年からの一連のＮＥＦＳＳプロジェクトを通じて「パッケージ」として横展開可能なものを作ろうとしていたものであって，実際，被告とＦＩＳ社が協力してＣｏｒｅｂａｎｋの「Ｊａｐａｎｉｚａｔｉｏｎ」（日本化），すなわちカスタマイズを進めていた。しかし，ユーザである原告から見えるのは，ＮＥＦＳＳというパッケージなのであって，ＣｏｒｅｂａｎｋはＮＥＦＳＳの内部で呼び出される部品の一つにすぎない。
したがって，Ｃｏｒｅｂａｎｋで実装できなければ，被告が，ＮＥＦＳＳライブラリとしてあるいは原告オリジナルのプログラムとして開発すればよい。単に，Ｃｏｒｅｂａｎｋの機能を追加・修正して実装することと，被告が実装することのどちらが技術的・経済的に優れているかに基づいて，振り分けが行われるだけの問題である。
よって，そもそも，ＦＩＳ社との関係が上手く調整できてＣｏｒｅｂａｎｋが改変できるかどうかは，ＮＥＦＳＳを使用した本件システムの構築を不可能にならしめるようなリスクではない。
ウ　ＣｏｒｅｂａｎｋではなくＮＥＦＳＳで考える必要があるという点をひとまず措き，原告が主張するＦＩＳ社との関係について考えたとしても，次のとおり，原告が主張するような「リスク」が存在しなかった。
すなわち，①Ｃｏｒｅｂａｎｋは元々ＩＢＭが開発を開始したソフトであり，かつ，被告は，原告にＣｏｒｅｂａｎｋを紹介する約２年前からＡｌｌｔｅｌ　ＣＳ社（ＦＩＳ社）と共同でＣｏｒｅｂａｎｋのＪａｐａｎｉｚａｔｉｏｎの作業を順調に行うなど，被告は，Ｃｏｒｅｂａｎｋについて十分な検討を行い，Ｃｏｒｅｂａｎｋについて十分理解した上で原告にＣｏｒｅｂａｎｋを紹介した，②ＮＥＦＳＳ内部においてＣｏｒｅｂａｎｋの機能の追加・修正を行うか，ＮＥＦＳＳ側の開発を行うかは自由に決定できる事柄であること，③住信ＳＢＩネット銀行において，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋの勘定系システムが稼動していること，④被告とＦＩＳ社の間の権利関係や役割分担は適切に調整されていたこと，⑤ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋの開発体制は最良のものであったこと，⑥ＦＩＳ社が新ＢＲＤから前面に出るようになった開発体制は極めて妥当な体制であったのであり，リスクは存在しなかった。
エ　以上のとおり，本件プロジェクトにおいては，Ｃｏｒｅｂａｎｋの採用に関するリスクなど存在しなかったが，仮にこの点を措くとしても，本件プロジェクトは，原告がスコープの調整や追加の開発費用の一部負担を不合理に強硬な交渉態度に終始して拒絶し続けた結果頓挫したのであって，原告が主張するように，ＦＩＳ社との権利関係等の調整ができないというリスクが現実化したために頓挫したものではない。
(5) 　争点(5)（錯誤の有無）について
（原告の主張）
ア　本件個別契約の全ては，Ｃｏｒｅｂａｎｋの採用を大前提として締結されたものである。したがって，実際にはＣｏｒｅｂａｎｋの採用が不可能であったということは，契約の重要な要素について錯誤があったことを意味する。
仮に，本件個別契約の締結に先だってＣｏｒｅｂａｎｋの採用が不可能であることを原告が認識していたならば，Ｃｏｒｅｂａｎｋの採用を大前提とする本件個別契約を締結することなどあり得なかったのは，議論の余地なく明白である。
イ　被告がＣｏｒｅｂａｎｋをカスタマイズする権利を有していないということは，原告からすれば，約９０億円もの巨額の委託料を支払って開発を委託する相手方が，自らはそのプロジェクトの核となるパッケージのカスタマイズを行う権限を有しておらず，契約外の第三者たるＦＩＳ社にこれを全面的に依存せざるを得ないということにほかならない。そして被告とＦＩＳ社が役割分担やスケジュール等につき合意できなければ，Ｃｏｒｅｂａｎｋを本件システムに採用することができなくなり，本件プロジェクトは頓挫するという帰結が待っている。この状況は，原告にとっては，本件プロジェクトの成否が被告とＦＩＳ社の協議の成否という原告自身では全くコントロールできない事情によって左右されることを意味するのであって，何らの契約上の手当てなしには到底取ることができないリスクである。このような極めて重要なリスクがある中で，９０億円前後にも上る巨額のシステム投資の意思決定をすることなどできようはずはないのである。
このように，被告がＣｏｒｅｂａｎｋをカスタマイズする権利を有しているかという事情は，本件プロジェクトの成否と直結する極めて重大な事実であり，本件基本合意①，同②，本件最終合意及び本件個別契約の「要素」に当たる。
仮に，本件基本合意①の締結時点又は遅くとも本件最終合意の締結時点において，原告が上記のような重要な事実，すなわち被告自身はＣｏｒｅｂａｎｋの修正作業を行う権限を有しておらず，ＦＩＳ社のみがこれを行うことができるという事情を知っていれば，本件基本合意①，同②，本件最終合意及び本件個別契約を（少なくとも締結した内容で）締結していなかったことは明らかである。
ウ　したがって，本件個別契約の全ては，要素に錯誤があったものであり，民法９５条により無効である。
エ　よって，原告は，錯誤無効に基づく原状回復請求権として，後記(6)（原告の主張）欄ア記載の６５億５３４１万０８４７円の返還を求める。
（被告の主張）
ア　Ｃｏｒｅｂａｎｋを採用して本件システムを構築することは可能であり，また，Ｃｏｒｅｂａｎｋの採用は本件個別契約の要素ではないこと等から，本件個別契約について，Ｃｏｒｅｂａｎｋの採用の可否に関する錯誤など存在せず，この点にかかる原告の主張は失当である。
イ　ＦＩＳ社が改変権を有することは，原告被告間で当然の前提とされていたのであって，改変権がないことを知らなかったという原告の主張は「後付け」の主張であって，原告には錯誤などというものは存在しなかった。
また，仮にこの点を措くとしても，原告の主張は，Ｃｏｒｅｂａｎｋの改変権を被告が有しないことがリスクであるとするものであるが，そもそも，パッケージを用いたシステム開発において，システムベンダがパッケージの部分を改変するということは，一般的ではないのであって，原告の主張はその前提が誤っている。むしろ，被告が，Ｃｏｒｅｂａｎｋのアーキテクチャに最も通じたＦＩＳ社に対し，日本における銀行業務・商品に必要な要件を伝えて，ＦＩＳ社がこれを実装するという開発形態が最も優れた体制であった。実際，ＮＥＦＳＳプロジェクトにおいて，被告は，ＦＩＳ社と協力してＣｏｒｅｂａｎｋのＪａｐａｎｉｚａｔｉｏｎ等を進めていた事実が存在するのであり，原告のいうリスクは存在しなかった。
(6) 　争点(6)（原告の損害）について
（原告の主張）
原告の損害は，次のアないしウを合計した１１５億８０２２万１３０２円であり，本訴においては，このうち１１５億８０００万円の損害賠償を求める。
ア　実損害①　６５億５３４１万０８４７円
本件システムを構築するための費用として被告に対して支払った金額のうち，原告が現に使用している製品等の対価を控除した金額であり，詳細は次のとおりである。
（ア）　システム・インテグレーションに関する個別契約に基づく支払相当額４９億１３１０万４８３０円
原告が本件プロジェクトの要件定義や基本設計その他のシステム・インテグレーションに関する各個別契約に基づき被告に対して４９億１３１０万４８３０円を支払った。
（イ）　オープン・インフラストラクチャー・オファリング契約（以下「ＯＩＯ契約」という。）に基づき支払った金額のうち，未使用資産に係る金額　１７億１９５８万１０１７円
原告は，ＯＩＯ契約締結以後，平成２２年３月末日の間，被告に対し，同契約に基づき３７億３２１８万３６５８円を支払った。そのうち，原告が現に使用している資産に関するリース料等の金額である２０億１２６０万２６４１円を控除した１７億１９５８万１０１７円が損害額となる。
（ウ）　上記（ア）及び（イ）の損害のうち，「アセットアロケーション／最適商品選定システム」及び「ライフプランニングシステム」については，別件プロジェクトで利用可能であり，その対価相当額である７９２７万５０００円は実損害を構成しないので，（ア）及び（イ）の合計額６６億３２６８万５８４７円から上記７９２７万５０００円を控除した６５億５３４１万０８４７円が損害額となる。
イ　実損害②　８億６０８１万０４５５円
本件システムを大前提として，本件システムで使用するソフトウェアやハードウェアの調達，設備の改造等を行うに際し，被告以外の者に対して１５億９８４７万７０５５円を支払った。そのうち，原告が現に使用している物の金額を控除した８億６０８１万０４５５円が損害額となる。
ウ　逸失利益　４１億６６００万円
原告は，本件システムの平成２０年１月の稼動開始が不可能となったことにより，本件システムが予定どおり稼動開始していたならば，その新機能の活用により得られたはずの利益を得ることが不可能となった。この逸失利益は，被告の債務不履行により生じた損害であり，その額は，少なく見積もって２年分の逸失利益だけでも４１億６６００万円を下らない。この逸失利益の金額は，原告が本件システム導入を検討していた平成１５年３月に，被告が「本件システムを導入すればこれだけの利益が得られる」として原告に対して提示した金額である。
（被告の主張）
ア　損害に関する原告の主張については争う。
イ　原告が主張する実損害①及び同②は，本件個別契約に基づき支払われた代金であり，各本件個別契約が定める成果物や対象サービスについては，被告がサービス又は成果物を納入し，原告は適切に検収や受領を完了しているのであるから，これらが損害を構成するものでないことは明らかである。
ウ　本件最終合意書８条ただし書による法的義務の排除
本件最終合意書８条ただし書は，「ただし，個別契約（中略）が締結され，各関連個別契約の中で両当事者の各局面における義務が規定されるまでは，いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。両当事者の書面による合意がある場合を除いては，本８条は有効とする。」と規定する。ここで，本合意書に基づく法的義務とは，本件最終合意書１条の８９．７億という金額や，７条にいう「本日に至るまでの協議に基づく案」である「添付」（甲５の１）を含んでいる。「添付」には，本件プロジェクトの構想全体が記載されているのであるから，上記８条ただし書によって，原告と被告は，本件プロジェクトの開発スコープ，金額，スケジュール等について，８条の予定する個別契約に基づく責任のほか，何らの責任を負わないことを合意しているのである。
よって，本件最終合意書を交わした後に，要件定義作業が終了し，そこで定義された要件を積み重ねて「確定見積り」（乙２・９頁）を行った際に，開発スコープ，金額，スケジュール等が想定から外れていることが判明した場合であっても，被告は，本件最終合意書に基づく開発スコープ，金額，スケジュール等について，契約上の義務はもちろんのこと，信義則上の義務も負うことはない。
なお，８条ただし書の規定について，被告が不当に責任を免れる意図を有するものでないことは明らかであるから，上記の規定は，被告に故意が認められる場合でない限り有効に適用されることになる。
エ　個別契約の責任制限条項
本件最終合意書の交渉経過からも明らかなとおり，本件における法的義務の発生根拠となり得るのは本件個別契約のみであるところ，本件個別契約には，それぞれ責任制限条項が存在するため，原告が個別契約に基づいて支払った代金を被告に対して返還請求することができるのは，次の場合に限られる。これらの点について，原告の主張及び立証はされていない。
（ア）　個別契約のうち，原告が各個別契約に基づいて支払った額を累積した額の損害賠償を否定する旨の責任制限条項が規定されているものにおいては，原告が被告に対して損害賠償請求できるのは，それぞれの個別契約に基づく被告の作業が，それぞれ，損害発生の「直接の原因」となったこと，及びそれぞれの個別契約における代金の支払が，原告の主張する被告の契約違反又は不法行為による「通常かつ直接の損害」であることを主張，立証した場合に限られる。
（イ）　個別契約のうち，故意・重過失ある場合に累積的な損害賠償を認める旨の責任制限条項が規定されているものにおいては，それぞれの個別契約における代金の支払が，原告の主張する被告の契約違反又は不法行為による「通常かつ直接の損害」であることを主張，立証した場合に限られる。
オ　本件最終合意書４条による原告の逸失利益の損害賠償請求の排除
本件最終合意書４条によれば，各個別将来契約について，原告が被告に逸失利益の賠償を求めることはできないとされている。
カ　損益相殺
次の（ア）ないし（ウ）については，損益相殺により，原告の損害から控除されるべきである。
（ア）　再利用可能な成果物の客観的価値相当分　４２億３９２１万６２０１円
被告が本件個別契約に基づき原告に納入した成果物の大部分は，本件プロジェクトが開発フェーズに入らずに頓挫したとしても，すなわち，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを使用せずに被告以外のベンダと開発を行ったとしても利用可能であり，成果物の客観的な価値相当分は，原告における損害を構成しないというべきである。なぜなら，仮に，プロジェクトが頓挫して原告の支払が損害となったとの原告の主張を前提としたとしても，それにより，原告は，当該客観的価値に相当する利益を得ているからである。すなわち，原告の本件個別契約に基づく支払は，被告との間の本件プロジェクトが頓挫した時点において，全く無意味な支出となったとはいえず，①要件定義書（インターネットバンキングの要件定義も含む。），②システム設計書，③他社製パッケージソフトウェア（ＳＡＰ社パッケージソフトウェア関連も含む。）の客観的価値相当分として，原告が支払った金額のうち，少なくとも４２億３９２１万６２０１円は，原告における損害を構成しない。
（イ）　原告の本件未払個別契約①及び同②に基づく未払金（反訴請求の趣旨１項に係る請求分と同じ）　少なくとも１３億６９６０万１４９３円
ａ　本件未払個別契約①及び同②の反訴請求は，その全額（１３億７４８４万１６５０円）が認められるべきであるが，仮にこれが認められない場合には，プロジェクト頓挫により原告は同額の債務を免れる結果となるから，原告の損害から１３億７４８４万１６５０円を控除するべきである。
ｂ　仮に，本件未払個別契約②所定の成果物のうち，原告による受領，受入検査がされていない「設計・実装局面作業計画」に該当する部分の対価が請求できないとしても，本件未払個別契約①及び同②の対価の合計１３億７４８４万１６５０円から，本件未払個別契約②の対価の０．４６８％（「設計・実装局面作業計画」の作成に係るワークロード（人月）が本件未払個別契約②所定の１５の成果物に占める割合）に当たる５２４万０１５７円（消費税込み）を控除した１３億６９６０万１４９３円は，仮に本件未払金反訴が認められないとすれば，原告がプロジェクトの頓挫によって同債務を免れる結果となるから，そのような不当な結果を導かないために，原告の損害から控除するべきである。
（ウ）　暫定的合意書（以下「ＬＯＩ」という。）に基づく債務　２億３１００万円
原告は，本件未払個別契約②の期間が終了した後，平成１８年１２月１８日から平成１９年１月１５日の期間の作業の対価２億２０００万円（消費税別）について，被告に対して支払う旨を書面で合意した。この２億２０００万円（２億３１００万円（消費税込み））は，本件不法行為反訴請求（反訴請求の趣旨２項に係る請求）に含まれるべきものであるが，仮に同請求が認容されないとすれば，原告はプロジェクトの頓挫により同額の債務を免れる結果となっているから，原告の損害から控除するべきである。
キ　相殺
仮に，本訴請求のうち，①請負契約の債務不履行に基づく損害賠償請求，②個別契約の債務不履行解除による損害賠償請求又は③個別契約の錯誤無効による不当利得返還請求のいずれかが認容される場合には，被告は，次の債権をもって，次の（ア）から（ウ）の順に従って，原告の上記本訴請求債権とその対当額で相殺する。
（ア）　本件未払個別契約①及び同②に基づく未払金請求権１３億７４８４万１６５０円及びうち２億５５１５万円に対する平成１８年８月３１日から，うち１１億１９６９万１６５０円に対する平成１９年４月７日から各支払済みまで年６分の割合による金員（反訴請求の趣旨１項に係る請求分と同じ）。
（イ）　ＥＳＯ契約に基づく未払金１億２００４万０６２０円及びこれに対する平成２２年２月２６日から支払済みまで年６分の割合による金員（反訴請求の趣旨３項に係る請求分と同じ）。
（ウ）　不法行為に基づく損害賠償請求権１１０億５７１０万２５５３円及びこれに対する平成１９年１１月３０日から支払済みまで年５分の割合による金員（反訴請求の趣旨２項に係る請求分と同じ）。
（原告の反論）
ア　責任限定条項について
債務者に故意又は重過失がある場合，責任限定条項は無効であるから，故意又は重過失により本件プロジェクトを頓挫させた被告に，本件最終合意書４条の責任限定条項は適用されない。
イ　損益相殺の主張に対する反論
（ア）　再利用可能な成果物の客観的価値相当分について
被告は，原告は本件成果物の客観的価値に相当する利益を得ているから，本件成果物の客観的な価値相当分が損害を構成しないとして，損益相殺に基づく主張をする。しかしながら，次のとおり，被告の上記主張はその前提を欠いている。
ａ　被告は，本件成果物のうち，本件プロジェクトが頓挫したとしても依然として利用可能な部分として，①要件定義書（インターネットバンキングの要件定義も含む。），②システム設計書，③他社製パッケージソフトウェア（ＳＡＰ社パッケージソフトウェア関連も含む。）の客観的価値相当分が損害を構成しないと主張する。
しかしながら，これらの成果物のうち，③他社製パッケージソフトウェアの一部である株式会社キャピタル・アセット・プランニング製の「アセットアロケーション／最適商品選定システム」及び「ライフプランニングシステム」（以下「アセットアロケーションシステム等」と総称する。）を除き，別件プロジェクトで利用可能な部分は存在しない。
（a）　要件定義書について
①被告が原告に納入した要件定義書は失敗作であって，Ｃｏｒｅｂａｎｋを前提とした場合でさえグローバルＩＢＭが指摘した問題（パッケージの特性を生かせないなどの問題）があるのに，他ベンダのパッケージを用いるプロジェクトにそのような要件定義書を用いることなど到底できないこと，②要件定義書のレベル５（「現新論理モデル対比表」及び「新処理機能記述」の２つの文書から構成される。）及びその添付資料である「現行処理記述」は，平成１６年当時の現行システムの約４分の１についてしか作成されていない未完成なものであり，かつ，レベル５に至ってはレベル４との整合性も確認できない代物にすぎないし，「現行処理記述」はとても利用に耐えない品質であること，③平成１８年１月から３月にかけて被告から納入された要件定義書は，新規開発又は改訂の内容を一切反映していないのであって，その内容が完全に陳腐化しており，不完全な内容となっていること，④別件プロジェクトでは，当然のことながらベンダは被告ではなく，パッケージもＣｏｒｅｂａｎｋではないところ，要件定義は，ベンダごとにそのやり方が全く異なるし，要件定義書の内容，形式も全く異なるのであるから，被告が作成した要件定義書を別件プロジェクトにおいて利用することは不可能であること，⑤要件定義書を転用する場合，他のベンダは，膨大な要件定義書を完全に理解，検証し，不備などを是正しなければならないところ，本件成果物の要件定義書は前述のとおり陳腐化してしまっているため，これらの作業はより大変な作業となるし，原告が被告と裁判で争っている以上，他のベンダは，被告から必要な引継ぎを受けることもできないし，要件定義書に関して不明な事項があったとしても，被告に問い合わせることすらできないのであるから，転用のための上記作業を行うには莫大な時間とコストが必要となるのであり，このような作業を行うのであれば，他のベンダが最初から要件定義を行う方が早いしコストも低く抑えられることからすると，要件定義書は別件プロジェクトで利用できない。
また，本件要件定義書につき損益相殺を認めることは，被告を不当に利し，原告に不当に犠牲を強いるものであって，公平性を著しく欠く。すなわち，本件要件定義書のうち，Ｃｏｒｅｂａｎｋに依存する部分が別件プロジェクトで利用できないのはもちろんのこと，そうでない部分，つまり平成１６年１０月当時の本件処理フローを整理した部分も，これを利用することは著しく非効率であり，これをあえて別件プロジェクトで利用することは，開発費用の面でも，納期（開発期間）の面でも，品質の面でも，原告にとって莫大な負担を強いられることになるほか，上記のような状況下にある以上，本件要件定義書を別件プロジェクトで利用しなければならないとする被告の主張は，どう考えても不合理であり，公平性を欠く。
また，原告は，本件プロジェクトが頓挫したことによって，別件プロジェクトを実施せざるを得なくなり，原告に支払った開発費用に加え，別件プロジェクトにおいても莫大な費用負担を強いられている。仮に，本件要件定義書が利用可能であるとして損害額が差し引かれるような事態となれば，原告は，莫大な開発費用の二重の負担を強いられることになるのであり，著しく公平性を欠くことは明白である。
（b）　計画・要件定義＃１の作業について
計画・要件定義＃１は成果物がなく，計画・要件定義＃１の作業で再利用可能なものなど物理的に存在しない。
また，仮に計画・要件定義＃１の成果が計画・要件定義＃２の成果物たる要件定義書に反映されているとしても，この要件定義書を別件プロジェクトで利用することはできない。したがって，原告が計画・要件定義＃１の支援作業に対する対価として支払った７億５９３５万８９５０円（消費税込み）のうち，８３．０９％は再利用可能とする被告の主張は失当である。
（c）　システム設計書について
被告から納入されたシステム設計書は，当然のことながら，本件プロジェクトで採用することが予定されていたパッケージ又は製品を用いることが前提とされている。しかしながら，別件プロジェクトでは，本件プロジェクトで採用することが予定されていたパッケージ又は製品は利用されない。
（d）　ＳＡＰ社パッケージソフトウェア関連
ＳＡＰ社パッケージソフトウェア関連（以下「ＳＡＰパッケージ」という。）は，本件プロジェクトにおいて，本件システムの一部を構成するものとして採用が決定されたものである。ＳＡＰパッケージは，多数のユーザに使用許諾されている製品ではあるものの，大規模な業務パッケージであることから，本件プロジェクトが頓挫した場合に他に容易に流用が可能なものではない。また，使用許諾契約上，原告が第三者に使用権を譲渡することもできない。
それゆえ，当該ＳＡＰパッケージは，本件プロジェクトが頓挫したことにより，その時点で利用価値を失い，その対価が原告の損害となった。しかしながら，原告においては，別件決算処理システムプロジェクトで同一のパッケージを使用することになったので，損害を減少させるため，当該ＳＡＰパッケージの使用権を流用しようと考え，ＳＡＰ社及び被告と交渉を行った。それにもかかわらず，被告がこの交渉を不合理に拒絶したことから，原告は購入済みのＳＡＰソフトの流用を諦め，ＳＡＰソフトを新規に購入せざるを得なくなった。これにより，当該ＳＡＰパッケージの対価は，原告の被った損害を構成することとなった。
（e）　イーディーエス・ジャパン・エルエルシー社製のＣＲＭパッケージ（以下「ＣＲＭパッケージ」という。）について
ＣＲＭパッケージも本件システムの一部を構成する目的で採用されたものである以上，本件プロジェクトが頓挫した時点でその対価が損害を構成することとなった。
ｂ　原告は，既に複数の他のベンダに委託をして，新経営システムの構築に着手している（別件プロジェクト）。しかしながら，原告は，別件プロジェクトにおいて，本件成果物を一切使用することなく要件定義工程から全てやり直し，再度，要件定義についての費用も全て負担している。つまり，原告は，本件成果物を一切利用しておらず，本件成果物による利益など全く享受していない。このように，客観的事実として，原告が本件成果物による利益を受けていない状況にあって，損益相殺的な考え方により，損害の額が減縮されるようなことになれば，原告は，莫大な開発費用の負担を二重に強いられることになり，極めて不合理である。この意味でも，被告の損益相殺に基づく上記主張は失当である。
（イ）　原告の本件未払個別契約①及び同②に基づく未払金について
本件未払個別契約①及び同②に基づく未払金請求権が存在しないことは，後記(7)（原告の主張）欄に記載のとおりである。そうすると，被告の主張は，存在しない未払金請求権相当額を損害から控除すべきと主張しているに等しく，失当である。
また，被告は，本件未払個別契約②の納入物のうち，「設計・実装局面作業計画」の作成に必要な作業量（人月）の割合は「０．４６８％」にすぎないなどとして，本件未払個別契約①及び②の対価のうち，総額１３億６９６０万１４９３円は原告の損害から控除しなければならないとも主張する。しかし，「設計・実装局面作業計画」とは，「本件システムの設計及び実装にいかなる作業が必要となるか」「誰が」「いつまでに」「いかなる作業を」「いかなる方法で」行っていくかといった事項が「作業計画」として詳細にまとめられるものである。「設計・実装局面作業計画」がなければ次フェーズ以降の作業を実施することができない。
このように，「設計・実装局面作業計画」は極めて重要な納品物なのであって，これが納品されなければ，本件未払個別契約②の目的は達成されない。
以上からすれば，「設計・実装局面作業計画」の作成に必要な作業量（人月）の割合によって契約金額の大部分の控除を求める被告の上記主張が無意味で，かつ失当であることは明らかである。
（ウ）　ＬＯＩに基づく債務
被告は，原告と被告との間のＬＯＩに記載された２億３１００万円（消費税込）は，原告における損害から控除されるべきものであると主張する。しかし，原告は，そもそもＬＯＩに記載された金額については，本訴請求において損害として被告に対して請求していない。仮に，原告が，ＬＯＩに記載された金額を被告に対して支払っていれば，それも実損害①を構成するものとして本訴請求の請求金額に含めていたところである。
また，ＬＯＩは，Ｃｏｒｅｂａｎｋを基幹に据えて本件システムを構築することを目的とする本件最終合意書に関連する個別契約と位置付けられるところ，原告は，被告の債務不履行及び不法行為を理由として平成１９年７月１７日付けでこれを解除しており，ＬＯＩに基づく債務を負っていない。
(7) 　争点(7)（反訴請求の可否）について
（被告の主張）
ア　本件未払個別契約に基づく請求（反訴請求の趣旨１項に係るもの）
（ア）　原告と被告は，本件プロジェクトに関し，本件未払個別契約①及び②を順次締結した。
（イ）　被告は，本件未払個別契約①所定の成果物である「システム設計書（制御編・基盤編）」を納入予定日である平成１８年３月３１日付けで原告に対して納品し，原告による受領・受入検査も同日完了した。しかるに，原告は，本件未払個別契約①所定の代金額の支払期日である同年８月３０日を経過した平成２０年８月２９日現在においても，被告に対し，本件未払個別契約①の代金の一部である２億５５１５万円（消費税込み）を支払っていない。
（ウ）ａ　被告は，原告に対し，本件未払個別契約②所定の成果物である「基幹系・取引機能マトリックス」等（ただし，後記ｂ記載の一部を除く。）を納入予定日である平成１８年１２月１日に納品し，原告による受入検査を経て，同月２６日に上記成果物の更新版を納品し，原告の受領，受入検査を完了している。
ｂ　なお，本件未払個別契約②所定の成果物である「設計・実装局面作業計画」については，いまだ原告による受領・受入検査がされていない。
「設計・実装局面　作業計画」は，基本設計フェーズ後の本件プロジェクトの作業計画であるから，本件プロジェクトのスケジュールや開発スコープ等について，原告と被告との合意の下，方針がまとまることを前提とするものである。そして，被告は，要件定義・ＢＲＤを踏まえた現実的なスケジュール等について原告と協議を行い，共通理解を醸成し，これに基づく提案を行うなど，原告との間で上記方針がまとまるよう努力すると同時に，平成１８年１２月末には，当該方針がまとまりさえすれば納入可能なＷＢＳ（Ｗｏｒｋ　Ｂｒｅａｋｄｏｗｎ　Ｓｈｅｅｔ。作業の詳細を記載したもの）等の「設計・実装局面　作業計画」の作成を完了していた。
それにもかかわらず，原告が，本件プロジェクトの基本設計フェーズ後の現実的な作業計画について，被告との間で方針をまとめ，上記「設計・実装局面　作業計画」を受領することを拒絶したまま，本件プロジェクトを一方的に中断したため，上記の成果物は，原告による受領及び受入検査が未了となっている。
すなわち，原告は，原告の現行システムの機能や本件プロジェクト初期の概略的見通しに基づくスコープ，代金額等に固執するなどして，本件プロジェクトの進行に対し非協力的な態度をとり，本プロジェクトの基本設計フェーズ後の現実的な作業計画（具体的には，サービスインのスケジュールの点や開発スコープの調整に基づく作業内容及びこれらに伴う開発費用負担等）についての方針をまとめるための協力を行ってこなかった。それにもかかわらず，原告は，平成１９年４月１９日に被告がプロジェクトを進行するために行ってきた原告との協議やこれに基づく共通理解や提案を覆す態度をとり，また，被告がＣｏｒｅｂａｎｋの代替案として行ったＴＣＢに関する提案を何ら検討することなく即刻拒否し，本件プロジェクトをいったん白紙に戻すと宣言し，さらには，平成１９年７月１７日付けの原告代理人による被告宛通知書（甲１５の１）において，本件未払個別契約を含む本件個別契約全部の債務不履行に基づく解除又は錯誤無効を主張するに至った。
このような原告の態度は，本件未払個別契約②所定の成果物の一つである「設計・実装局面　作業計画」の作成に不可欠である本プロジェクトの現実的なスケジュールや開発スコープ等に関する方針をまとめるために必要不可欠な協力を拒否し，被告からの成果物の受領を拒絶する意思を明確にするものである。このように，被告の「設計・実装局面　作業計画」の納入義務は，専ら原告の責めに帰すべき事由により履行ができない状態となった。
したがって，本件未払個別契約②所定の成果物のうち，被告が納入済みの成果物について原告が代金額の支払義務を負うのはいうまでもなく，上記原告が未受領の成果物についても，原告は被告に対して本件未払個別契約②に基づき代金額の支払義務を負う。
（エ）　原告は，本件未払個別契約②所定の代金額の支払期日である平成１９年４月６日を経過した平成２０年８月２９日現在においても，被告に対し，本件未払個別契約②の代金額である１１億１９６９万１６５０円円（消費税込み）を支払っていない。
（オ）　よって，被告は，原告に対し，本件未払個別契約①（平成１８年３月３１日付け「ＩＢＭシステム・インテグレーション契約書」）に基づき請負代金の一部である２億５５１５万円及びこれに対する平成１８年８月３１日から支払済みまで年６分の割合による遅延損害金の支払を，本件未払個別契約②（平成１８年９月２９日付け「ＩＢＭシステム・インテグレーション契約書」）に基づき，請負代金１１億１９６９万１６５０円及びこれに対する平成１９年４月７日から支払済みまで年６分の割合による遅延損害金の支払をそれぞれ請求する。
イ　不法行為に基づく請求（反訴請求の趣旨２項に係るもの）
（ア）　原告は，前記(2)（被告の主張）欄記載のとおり，プロジェクト開始当初から，①ＢＰＲを行わず，②報告や議論についてそれが存在しなかったかのごとき虚偽の資料をあえて作成させ，③ことあるごとに責任論を持ち出してプロジェクトを遅延させた上，④原告の副社長自身が提示した現実的な条件を反故にして，実現不可能な要求を突きつけて，交渉とも呼べない交渉を行うなどして，プロジェクトを頓挫させた。
原告は，これにより，被告が少なくとも１１０億５７１０万２５５３円にのぼる莫大な投資をして開発してきたＮＥＦＳＳ／Ｃｏｒｅｂａｎｋの横展開を不可能にし，被告の投資を水泡に帰せしめた。原告のこのような行為が不法行為に当たることは明らかである。
（イ）　したがって，被告は，原告に対し，不法行為に基づき，ＮＥＦＳＳ構築のために費やしてきた投資相当額の損害金１１０億５７１０万２５５３円及びこれに対する不法行為の後である平成１９年１１月３０日から支払済みまで年５分の割合による遅延損害金の支払を請求する。
ウ　ＥＳＯ契約に基づく請求（反訴請求３項に係るもの）
（ア）　原告と被告は，平成１６年１２月２９日，本件プロジェクトに関するハードウェア，ソフトウェア等の導入，リース及び保守等に関し，ＯＩＯ契約を締結した。
（イ）　ＥＳＯ契約対象ソフトウェアには，次の４つの課金方式のいずれかが適用される。
ａ　変動式ワークロード使用料金（ＶＷＬＣ。使用したプロッセッサ能力（ＭＳＵ）で決まる変動月額料金）
ｂ　定額式ワークロード使用料金（ＦＷＬＣ。固定月額料金）
ｃ　ティア料金（Ｔｉｅｒ　Ｐｒｉｃｉｎｇ，ＬＶＴＲ。プリンタ等を制御するソフトに適用されるもので，プリンタ等の周辺機器の構成で決まる固定月額料金）
ｄ　固定料金（Ｆｌａｔ　Ｐｒｉｃｉｎｇ，ＦＬＡＴ。古くからある固定月額料金。）
ＥＳＯ契約対象ソフトウェアは，いずれも，メインフレームと呼ばれる大型コンピュータで動作するソフトウェアである。メインフレームは，同時並行的に多数のソフトウェアを動作させることができる高性能なコンピュータである。原告は，このメインフレームを使用して，本件プロジェクトの当時から現在に至るまで，継続して，現行システムを稼動させて業務を行っている。なお，メインフレームは，内部のプロセッサの使用量を記録する機能を有している。上記ａの料金は，この使用量を元にした，いわば「使った分だけ支払う」という従量制の料金である。メインフレームで使用するソフトウェアは，ＥＳＯ契約により，この従量制の料金と上記ｂ，ｃの固定制の料金を組み合わせる方式で，代金を支払うことになっている。
これらのＥＳＯ契約対象ソフトウェアの使用料金の合計に対しては，一定の上限値が定められ，当該使用料金の上限値を超えた場合には，原告は被告に対し，上限値の超過金額を支払う義務を負う（ＥＳＯ契約５条２項）。
かかるＥＳＯ契約上のソフトウェア使用料金の上限値は，ＥＳＯ契約５条２項に定められているが，これは平成１７年１２月３０日付け通知書において変更されており，平成２０年度（第４年度。平成２０年１月１日～同年１２月３１日）における使用料金の上限値は２億３０１９万７６００円（消費税抜き），平成２１年度（第５年度。平成２１年１月１日～同年１２月３１日）における使用料金の上限値は１億５７７６万０４００円（消費税抜き）である。
（ウ）　平成２０年度（第４年度）における原告のＥＳＯ契約対象ソフトウェアの使用料金実績金額は２億４８０３万１６００円（消費税抜き），平成２１年度（第５年度）における同金額は，２億５４２５万０８００円（消費税抜き）であった。
したがって，原告のＥＳＯ契約対象ソフトウェアの使用料金実績金額は，平成２０年度（第４年度）においては１７８３万４０００円（消費税抜き），平成２１年度（第５年度）においては９６４９万０４００円，ＥＳＯ契約（平成１７年１２月３０日付け通知書による変更を含む。）に定める使用料金上限値を超過した。
（エ）　被告は，平成２２年２月２６日，原告に対し，上記使用料金上限値超過金額に消費税を付加した金額（平成２０年度分については１８７２万５７００円，平成２１年度分については１億０１３１万４９２０円）を請求した。
（オ）　それにもかかわらず，原告は，上記の被告の請求に対し，協議を申し入れ，いまだに支払を行っていない。
したがって，被告は，原告に対し，ＥＳＯ契約に基づき，ＥＳＯ対象ソフトウェアの使用料金上限値超過金額として，金１億２００４万０６２０円及びこれに対する平成２２年２月２６日から支払済みまでの年６分の割合による遅延損害金の支払を求める。
（原告の主張）
ア　被告の上記アの主張について
（ア）　原告と被告が本件未払個別契約①及び②を順次締結したこと，被告が，本件未払個別契約①所定の成果物を平成１８年３月３１日に原告に対して納品し，原告による受領，受入検査を完了したこと，被告が，本件未払個別契約②所定の成果物のうち，「設計・実装局面　作業計画」を除く「基幹系・取引機能マトリックス」等を同年１２月２６日まで原告に対して納品して，原告による受領，受入検査を完了したことについては，いずれも認める。
（イ）　債務不履行解除
本件未払個別契約①及び同②は，いずれも被告の債務不履行を理由に解除したことは，上記(2)及び(3)の原告の主張欄に記載のとおりである。
（ウ）　錯誤無効
本件未払個別契約①及び同②は，いずれも錯誤無効であることは，上記(5)の原告の主張欄に記載のとおりである。
（エ）　変更の合意に基づく弁済
被告は，被告が平成１８年９月２６日付けで作成した「ＳＣＳ殿要員の発注に関して」（以下「本件支払変更依頼書」という。）において，新ＢＲＤに関して被告が負担すべきであったＳＣＳ社の人件費の一部の支払方法を被告から（Ａ＆Ｉ社という第三者を通じて）ＳＣＳ社に対して支払うのではなく，原告から直接ＳＣＳ社に対して支払ってほしいとの依頼をした。そして，原告がこれを承諾したことから，被告は，原告に対し，本件個別契約①の契約金額である２億４５００万円（消費税別）から２億４３００万円（消費税別）を差し引いた残額２００万円に消費税１０万円を加えた金額２１０万円を「最終お支払い」として請求書を発行し，原告はこれに応じて支払った。
さらに，原告は，上記合意に基づき，新ＢＲＤに関するＳＣＳ社の人件費をＳＣＳ社に対して支払った。
以上からすれば，原告及び被告との間で，本件未払個別契約①の支払方法等に関し変更する合意がされ，原告は，当該合意に基づき，本件未払個別契約①の弁済を行ったことは明らかである。
（オ）　同時履行
被告は，本件未払個別契約②に基づく成果物の一部を納品していないのであるから，原告が，本件未払個別契約②に基づく支払を行う必要がないのは当然である（同時履行の抗弁）。
イ　被告の上記イの主張について
否認ないし争う。
本件プロジェクトが頓挫したのは，被告の責めに帰すべき事由によるものであり，それについての原告の主張は，上記(2)の（原告の主張）欄記載のとおりである。
ウ　被告の上記ウの主張について
（ア）　不当利得に基づく返還請求権による相殺
ａ　原告は，本件プロジェクトが頓挫したことを受け，平成１９年１０月以降，本件システム用のソフトウェアについては，ＥＳＯ契約の対象から外し，被告に対してソフトウェアを返却するべく交渉を重ねてきたが，被告は，平成２２年３月に至るまでこれを拒否し続けた。
仮に，本件システム用のソフトウェアについては，ＥＳＯ契約の対象から外し，被告がソフトウェアの返却に応じていれば，平成２０年については，「対象プログラム使用実績値」が「使用料金上限値」を超えることはなかったし，平成２１年については，「対象プログラム使用実績値」は「使用料金上限値」を超えていたが，その金額は３８１４万１７７５円にすぎなかった。
したがって，被告の原告に対するＥＳＯ契約に基づく金銭支払請求権は，３８１４万１７７５円である。
ｂ　他方，原告は，平成２０年分に関して４４３０万０８６５円を支払ったが，これは，将来的にも使用しないことが確定していたソフトウェアの返却に被告が応じていれば支払う必要のなかった無意味な金額であり，当該金額は，被告の不当利得に該当するから，原告は，被告に対し，４４３０万０８６５円の不当利得返還請求権を有している。
ｃ　原告は，上記不当利得返還請求権とＥＳＯ契約に基づく金銭支払債務を対当額にて相殺する。
（イ）　債務不履行に基づく損害賠償請求権による相殺
ａ　使用料金の算定の基礎となる「対象プログラム使用実績値」の算出方法の詳細は原告に開示されておらず，被告が「対象プログラム実績値」を算出して原告に報告しない限り，原告には「対象プログラム使用実績値」が「使用料金上限値」を上回る状況にあるか否かを知る術がない。そこで，ＥＳＯ契約では，被告が四半期ごとに原告の「対象プログラム使用実績値」を原告に対して報告するものとし（ＥＳＯ契約５条２項），被告は，原告の使用状況に応じて料金を変更するものとされている（ＥＳＯ契約と一体のものとして適用されるＩＢＭプログラムのご提供条件６条１項）。
しかしながら，被告は，この四半期ごとの「対象プログラム使用実績値」の報告を平成２２年３月に至るまで一度も実施していないし，原告の使用状況に応じて料金を変更することもしていない。
ｂ　後に原告からの要求に応じて被告からされた報告によれば，平成１７年度から平成２０年度における原告の「対象プログラム使用実績値」は，「使用料金上限値」を大幅に下回っており，この４年間で３億０３９４万６１２５円もの金額について，対象プログラムを全く使用していないにもかかわらず，無意味に支払を強制された。
仮に，被告が原告に対して「対象プログラム使用実績値」の報告を行い，原告が対象プログラムの使用状況を見直す機会を付与されていれば，原告は使用状況に応じて料金を変更したのであるから，これにより３億０３９４万６１２５円の支払を免れることができた。
ｃ　したがって，原告は，被告に対し，ＥＳＯ契約５条２項及びＩＢＭプログラムのご提供条件６条１項違反という債務不履行に基づき，３億０３９４万６１２５円の損害賠償請求を有している。
仮に，上記（ア）の抗弁が認められず，被告が原告に対するＥＳＯ契約に基づく１億２００４万０６２０円の金銭支払請求権を有していたとしても，原告は，上記損害賠償請求権と同金銭支払請求権を対当額で相殺する。
（ウ）　信義則違反，権利濫用
ＥＳＯ契約に基づく被告の請求は，上記（ア），（イ）の事情にかんがみると，信義則違反，権利濫用にも当たるものであるから，被告の同請求は，この意味でも認められる余地はない。
第３ 　当裁判所の判断
１ 　認定事実
前記前提事実に加え，証拠（甲１１９，甲１２０，甲１２３，甲１２５及び甲１５１並びに証人Ｇ，同Ｈ及び同Ｃのほか，後掲の証拠）及び弁論の全趣旨を総合すれば，次の事実が認められる。
(1) 　本件最終合意の締結に至るまでの経緯等
ア　本件プロジェクト開始に至る経緯
（ア）　原告は，平成１２年９月，被告と共に，原告の事業戦略上実現すべき業務内容，次期システムの在るべき姿及びその要件等の洗い出し作業を行い，その結果，平成１５年７月，原告が導入する時期システムによって実現すべき事業要件が「変革のテーマ」と題する文書にまとめられた（前記前提事実(3)イ，エ）。
（イ）　また，原告は，平成１４年９月から平成１５年１２月ころにかけて「ｅプロジェクト」を実施し，被告はこれに協力した。被告は，この中で，原告が次世代の勘定系システムの在るべき姿を見定めることの手伝いをするとともに，そのような勘定系システムの開発に要する費用や期間等についての大まかなイメージを示した（前記前提事実(3)オ）。
（ウ）　被告は，平成１６年３月１２日，原告に対し，同日付け「「顧客中心」・「迅速・柔軟な商品・サービス提供」・「オンデマンド」を可能とする次世代金融サービスシステムのご紹介」と題する書面を交付した。
その中の「「次世代金融サービスシステム」業務機能の実装」と題する頁には，「以下の観点よりＵＳの先進パッケージ（Ｆｉｄｅｌｉｔｙ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｒｖｉｃｅｓの‘Ｃｏｒｅｂａｎｋ’）を有効活用します。」，「「次世代金融サービスシステム」の目標である「顧客中心」の商品・サービスを「プロダクトビルド」（自由設計）できる機能を実現するためには，先行している欧米のパッケージの有効活用が優位である。」，「短期間でパッケージを構築するには，ゼロからの開発ではなく実績のあるパッケージを有効活用して開発する方が優位である。」と記載されている。また，「基本方針」として，「先進パッケージ機能と，２００２年初めより実施してきた日本の銀行商品・サービスのモデル化とを融合させます。」，「パッケージのコンポーネント（部品）を「ＷｅｂＳｐｈｅｒｅ」上の「Ｊａｖａ」にコンバージョン」，「日本の銀行の商品・サービスを追加」と記載されている（前記前提事実(3)カ）。
（エ）　平成１６年４月１２日に行われた原告と被告との間の打合せにおいて，原告のＣ専務は，「スルガ個社の事を考えずに，（ＮｅｆｉｓのＳｅｌｌｉｎｇ　Ｔａｌｋ通り）次世代のシステムのあるべき論からスタートし，現実解を求めたい。このことはスルガとしてかなり思いきったことを言っている。過去のスルガの文化とかプライドとかを全て捨てても良いと思っている。必要であれば事務フロー／プロセスも変更する。社内の軋轢にもＴＯＰ自ら号令をかけて実行したい。（ＩＢＭも腹をくくって対応して欲しい。）スルガＴＯＰ（社長／副社長／専務）の意向である。」，「システム化するにあたり，捨てるものを決める必要がある。全く別のものになった場合移行コストが膨大であることは理解している。選別し捨てる覚悟はある。」などと述べた（乙２１）。
（オ）　原告は，被告のほか，複数のシステム開発業者から提案されたシステムを比較検討した結果，被告による提案の内容が最も好ましいものと考え，同年９月２１日，①原告の基幹系オンラインシステムを被告が提供するＮＥＦＳＳバンキングシステムを基に全面改良を行い，新経営システムを構築すること，②上記費用として，初期費用約９５億円，保守費用として約６億２０００万円（年額）を支出することを決めた。
なお，同日の原告取締役会に提出された議題に添付された原告作成の資料には，「プロジェクトのスケジュール」として「合意書／支援サービスの締結によって計画・要件定義＃１を開始，計画・要件定義＃２終了までに要件をまとめ，その内容に基づいた最終合意書（請負）を締結する。」，「総費用の概算内訳」として「ステップ１では上限を設定」とした上で計９５億円と記載されている（前記前提事実(3)キ）。
イ　本件基本合意①の締結
（ア）　原告は，同月２９日，被告との間で，本件基本合意①を締結し，本件プロジェクトは開始された。本件基本合意書①には概要次のとおり記載されている。なお，この時点においては，原告と被告との間で，平成１７年５月末に本件プロジェクトに関する最終合意がされる予定であった（前記前提事実(4)）。
ａ　原告と被告は，被告提供のＮＥＦＳＳを利用した原告の「新経営システム」構築に当たり，以下のとおり合意した。
ｂ　原告の目標である「開発スコープ」（平成１６年９月２１日付け資料：「新経営システムご提案概要」）の実現を前提とした「新経営システム」構築に当たり，以下①②③の全てが実行されることを条件として，被告は９５億円（原告側要員費用含む）にて稼働を実現するよう確約する。
役割分担合意に伴う被告の管理下での原告側要員費用については，両者協議の上，工数及びスケジュール等の観点で管理を実施するものとする。
①　原告と被告の役割分担の両者による合意及び原告管理下のワークロード・費用の確定がされること
②　原告の商品・取引・帳票等に対する「ＢＰＲ・標準化」による合理化・効率化の合意が両者によりされること
③　上記①の役割分担合意に伴う，当該プロジェクトを遂行する上で必要な原告の協力がされること
ｃ　「新経営システム」構築プロジェクトの計画・要件定義局面終了までに，以下の項目を含む外部設計局面以降に関して合意することを目標に両者は作業を進めるものとする。
（a）　開発機能・スコープの詳細
（b）　稼働までの初期費用総額の詳細及び支払計画
（c）　プロジェクト期間中及び稼働後のランニング費用
（d）　ハードウェア構成・ソフトウェア構成と前提キャパシティ
（e）　プロジェクト遅延及び不履行時の取り決め
本条に定める合意までの間に，プロジェクトの大幅な延期や中止せざるを得ない状況が発生した場合，あるいは，本条に定める合意に至らなかった場合には，両者は真摯に協議の上，互いに誠意を持って損害賠償等の措置を含む適切な対応をするものとする。
ｄ　計画・要件定義局面の契約として，以下の内容を含む「ＩＢＭ支援サービス契約書」（金額：７億２３１９万９０００円）につき平成１６年９月２９日を目標に締結すべく，両者協議の上，進めるものとする。
（a）　「新経営システム」構築の計画・要件定義フェーズ＃１　ご支援作業
（b）　「ＮＥＦＳＳパッケージ」（「Ｃｏｒｅｂａｎｋ」及び「次世代金融サービス・システムライブラリー」）
（イ）　また，本件基本合意書①に添付された被告作成の平成１６年９月２１日付け「新経営システムご提案概要」には「計画・要件定義局面＃１の進め方」として，次のとおり記載されている（甲３）。
ａ　計画・要件定義＃１での作業工程
（a）　「プロジェクトスコープ」の確認
（b）　プロジェクト計画の立案
（c）　ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋ要件定義作業の方針検討と策定
（d）　現行システム調査（情報の整理・ドキュメント整備）
ｂ　計画・要件定義＃１の作業主体
現行システム調査（情報の整理・ドキュメント整備），具体的には，現行システム取扱い商品性の調査，現行システム取引フローの調査，現行システム処理フローの調査，現行システム事務フロー，業務フローの調査等は，原告が責任作業を実施し，被告が責任作業への支援をする。
ウ　計画・要件定義＃１
（ア）　原告は，同月２９日，被告との間で，計画・要件定義＃１に係るＩＢＭ支援サービス契約を締結した（前記前提事実(5)ア）。
（イ）　上記（ア）のＩＢＭ支援サービス契約に基づき，同年９月３０日から本件プロジェクトが正式に開始された。同日，キックオフ・ミーティングと称する打合せが開催され，その際の被告作成資料には，次の記載がある（前記前提事実(5)イ（ア），乙２２）。
ａ　計画・要件定義＃１の作業項目のうち，現行システム分析準備は，原告が主体となり作業を実施する（乙２２・２４頁）。
ｂ　現行システム分析準備として，①既存資料の収集ポイント整理（ただし，この作業は被告が主担当），②既存資料の収集，③既存資料の充足度合い確認，④不足情報の対応策検討を行う（乙２２・３９，４３頁）。
（ウ）　原告と被告は，同年１０月５日，週次進捗会議を開催した。被告は，本件基本合意書①で実施することが合意されたＢＰＲについての説明を行った。ＢＰＲのアプローチとして，①フェーズ１として，原告経営戦略・商品の収益性，他行事例等から，廃止又は現行商品に統合する商品を決定し，現行商品群から廃止又は統合される部分を差し引いた部分がＮＥＦＳＳ移行対象商品とする，②フェーズ２として，各商品の取引フローを標準化することにより，フロー数を集約，統合し，ＮＥＦＳＳ移行対象商品から，フロー数を集約，統合されたものを差し引いた部分が，ＮＥＦＳＳに実装される取引フロー（概要レベル）となると説明した（乙２３）。
（エ）　同年１１月５日に開催された第１回ステアリング・コミッティにおいて，原告が１２月末までに計画・要件定義＃２の契約，来年５月に本契約を目指すという認識でよいかと質問したのに対し，被告は，１２月末までの計画・要件定義＃２の契約について早急に対応するとともに，来年５月の最終合意に向けてスケジュールを調整すると答えた（甲６の１）。
エ　計画・要件定義＃２の開始
平成１６年１２月２９日から，計画・要件定義＃２が開始された。その目的は，「新経営システム」構築に対する「要求」を調査，分析し，システム化の対象を絞り込み，最終的な「システム化要件」を定義することであるとされていた。計画・要件定義＃２を実施する過程で，平成１７年４月８日開催の第６回ステアリング・コミッティにおいて，現処理フローの作成の必要性が確認されたが，現処理フローを記した原告側の資料がない部分については，いわゆるリバースエンジニアリングの方法により現処理フローが作成されることとなった。その結果，同年５月１１日開催の第７回ステアリング・コミッティにおいて，計画・要件定義＃２の完了を同年１２月末まで延期することとされた（甲６の２，甲６の６，甲６の７）。
オ　本件最終合意の締結の延期
被告は，「Ｃｏｒｅｂａｎｋ等のパッケージを最大限に活用した効率的開発手法」の確立及びそれを前提とした見積り方法の確立が未済であること，商品のＢＰＲ（統廃合とグルーピング）による開発対象基礎数値（目標値）の確立と合意が未済であることを理由として，原告に対し，平成１７年６月３０日付けの「「新経営システム」構築プロジェクトにおける「最終合意」締結延期に関するご報告と今後の対応」と題する書面を交付して，同年５月末から同年６月末に締結が延期されていた最終合意を同年９月末に締結することを目標とすることを申し出た（甲４７の１）。
原告のＩ常務は，同年７月６日に開催された第９回ステアリング・コミッティにおいて，いろいろな事情があったかとは思うが，合意書締結が遅れたことは遺憾である，経営者間での取り決めについては必ず守るということを強くお願いすると述べた（甲６の９）。
カ　本件最終合意の締結まで
（ア）　被告は，同年８月３日に開催された第１０回ステアリング・コミッティにおいて，最終合意の最終版作成に当たり，基礎数値の見直しについては原告の協力をいただき収束の状況にある，ほぼ固まった状況で被告社内において確認を行っているところである旨を報告した。この報告で用いられた被告作成の資料には，「システム開発コスト見積もりの前提となる基礎数値（オンライン取引数，帳票数，リンクデータ数，バッチジョブ数）については，スルガ様ご協力のもとほぼ確定に近づいた　現在は生産性の検証と見直しおよび見積もり開発工数の再確認を行った上でのコスト確定とプロジェクト開発計画の承認を受けるための準備処理を実施中」（資料の３－１頁）との記載がされていた（甲６の１０）。
（イ）　また，同年９月７日に開催された第１１回ステアリング・コミッティにおいて，被告は，最終合意書について一つだけ大きな課題が残されていて，鋭意対応中であるので，今しばらく時間をいただきたいと述べた。これに対し，原告は，同月中に締結できるようにお願いしたい旨述べた。そして，計画・要件定義＃２の成果物である要件定義書については，被告から原告に対して同年１２月末までに納入される予定であることが報告された（甲６の１１）。
原告と被告は，その後である同年９月３０日，本件最終合意書を交わした（前記前提事実(8)）。
(2) 　本件最終合意の締結後から平成１８年１２月末までの経緯等
ア　旧ＢＲＤ実施までの経緯等
（ア）　平成１７年１０月５日に開催された第１２回ステアリング・コミッティにおいて，被告は，計画・要件定義＃２の全体作業状況として，現モデルの作成，変革テーマの取り込み，システム全体概要の検討，ＮＥＦＳＳ差異分析及びシステムの定義を継続実施中であること，システム全体概要の検討では，同年９月からＬｅｖｅｌ５（サブシステム（新システムにおける取引レベル）の検討及び文書化（Ｌｅｖｅｌ４の新処理フローを骨格として，取引フローの集約，統合及び変革テーマの取り込みを実施し，新システムでの取引仕様を検討，文書化したもの）の作業を開始したことを報告した。
被告の担当者は，課題及び依頼事項として，①ＩＢＭアジア・パシフィック，ＦＩＳ社を含めたチームにより，今後の進め方についてレビューと最適な（実情にあった）開発手法の検討を実施中であり，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋ関連部分の開発手法の再確認とそれによる開発生産性の向上，作業範囲の確認，周辺システム（パッケージ主体部分）の開発手法に沿った最適な開発スケジュールの確認等，業務中心に全体の見直しも視野に入れた検討タスクの組成を予定していること，②その中で横展開の資産としてのコア部分と原告固有部分の分離を検討する予定であること，③マネジメント体制の見直しも含め，継続的な対応と管理を実施する予定であること，④業務の要件定義については同年１２月末で完了予定であるが，融資稟議と外為については一部未済項目が残ることが見込まれることなどを報告した。
また，被告は，原告に対し，①被告の都合で，合意書の提示時期が同年５月予定が９月末まで延びて御迷惑をお掛けした，②原告に無理を申し上げた，③基本は信用を裏切らないようにすることと認識しているなどと話した。
一方，原告のＣ専務は，被告に対し，当初お約束いただいた①期限は守られるのか，②費用は予算内に収まるのか，③日本の銀行の標準機能として持つべき機能は実現されるのか，この３点につき，当初の計画どおり対応してほしいと話した（甲６の１２）。
（イ）　同年１１月１１日に開催された第１３回ステアリング・コミッティにおいて，被告が，前回のステアリング・コミッティで報告したとおり，被告，ＩＢＭアジア・パシフィック，ＦＩＳ社を含めたチームにより最適な開発手法の検討を開始したと報告したのに対し，原告は，プロジェクトを遅延させない，サービスインの期限を守る，本件最終合意書で約束したことを守っていただく上で効率化を図るための提案であれば承認すると述べ，被告はこれを了解した。
また，被告は，①ＦＩＳ社との検討会は，被告内でもこのままこのプロジェクトを進めてよいかという意見もあり，ＦＩＳ社のアドバイスをきちんと受けて，これから先を確実に進めていくために実施したものである，②プロジェクトにある前提条件を変えることは考えていないと述べた（甲６の１３）。
（ウ）　被告は，同年１２月１２日，原告に対し，開発方法及び開発内容の変更を提案した。その提案書である同日付け「貴社「新経営システム」構築プロジェクト　プロジェクト見直しのご提案」と題する書面には，次のような記載がある（前記前提事実(9)イ，乙５）。
ａ　ご提案の背景
（a）　これまでの本件プロジェクトの進め方は，Ｃｏｒｅｂａｎｋ機能の理解及びＣｏｒｅｂａｎｋ機能を最大限活用する開発手法の確立が不十分であったため，現行機能をベースとした機能要件をＣｏｒｅｂａｎｋを使って開発するという「現行踏襲型アプローチ」となっていた。
（b）　Ｃｏｒｅｂａｎｋ開発元であるＦＩＳ社及びＩＢＭアジア・パシフィックのパッケージ・ベース・アプローチ有識者によるプロジェクト・レビューの結果，現在の進め方では，①Ｃｏｒｅｂａｎｋパッケージ機能を最大限活用できなかったことにより，柔軟性，拡張性及び品質の確保ができない，②平成２０年１月の安全的・成功裡なサービスインに対して，開発ボリュームが適正値を超えている，③原告，被告両者の投資金額の上限を超える可能性があるという三つのリスクが内在することが判明した。
ｂ　ご提案の骨子
（a）　Ｃｏｒｅｂａｎｋ機能の最大限の活用
①　ＦＩＳ社の実績ある開発手法（パッケージ・ベース・アプローチ）の採用により開発リスクの最小化を図るとともに，Ｃｏｒｅｂａｎｋ機能及びＦＩＳ社の実績，経験を最大限に活用することによりパッケージ機能を最大限に享受する（ＦＩＳ社メンバーを直接プロジェクトに参画させる。）。
②　要件をパッケージ機能と追加開発で実現するのではなく，パッケージ機能が存在するエリアの中に要件を収束させることにより拡張性，柔軟性を確保すると同時に横展開可能なシステムとする。
（b）　開発ボリュームの適正化
「開発ボリューム＝スコープ×品質」の考え方において，「品質」を維持しつつ平成２０年１月の安定的，成功裡なサービスイン（＝「開発ボリュームの適正化」）を実施するためには，次のとおり開発スコープの見直しを実施する。
①　ビジネス目標達成のための業務要件の実現にフォーカスし，開発スコープを縮小する。
②　既存システム対応も含めた原告，被告双方合わせた全体最適の観点及び個別業務要件ではなく最終的なビジネス目標達成の観点から，安定したサービスインを迎えるための最適ソリューションを検討する。
（c）　サービスイン後の保守容易性の確保とスキル移管の促進
①　サービスイン後のメンテナンスを効率化するために，カスタマイズ，作り込みを極小化する。
②　ＳＣＳメンバーの再配置による原告体制下での開発実施により，サービスイン後の保守容易性を確保する。
（エ）ａ　平成１８年１月１１日に開催された第１４回ステアリング・コミッティにおいて，被告のＦ専務は，「１月以降の作業計画について」と題する資料により原告に対する提案をした。Ｆ専務は，基本的な作り方についてのコンセプトとして，できるだけ手作りをやめてパッケージの機能を利用することで，変革のテーマを始めとする新要件・機能を実現しつつ，開発スピードを上げる，保守性を高める，ＮＥＦＳＳユーザ拡大時の自由度を高めることがねらいであること，平成２０年１月に本番稼動を迎えるために，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋのソリューション機能をどのように活用すればいいのか，開発内容全てをテーブルに上げて整理させていただきたいということがこの提案の主旨であると説明した。
これに対し，原告は，被告作成の上記「１月以降の作業計画について」と題する書面の中で「③２００８年１月の確実なサービスインへ向けた開発量の適正化」と記載されている点について，①これが要件の削減を意味しているのであればこの提案を受けることはできない，②本件プロジェクトの目的は，変革のテーマを実現することにあり，変革のテーマを削減して単なるオープン系システムに作り替えるということではプロジェクトを行う意味がない，③開発量の最適化については，あくまでも合理的な提案であれば受け入れる余地はあるが，単なる削減では受け入れることはできないなどと述べた。また，原告は，以前約束していただいたとおり変革のテーマについては，全て実現すると言っていただきたいと伝えたところ，被告は，業務要件を削減することはしない，深さについては相談させていただきたい，あくまでも平成２０年１月本番稼動をうまくいかせるためにどうするかという観点で合理化案について検討させていただきたいと答えた。さらに，原告は，ＢＲＤを実施することのメリット，リスク，ＢＲＤを実施しないことのリスクなどを明確にしていただき，原告として判断できる提案書を提示いただきたいと述べた（甲６の１４）。
ｂ　被告は，上記ステアリング・コミッティにおける原告側からの意見を踏まえ，平成１８年１月２６日，原告に対し，「貴社「新経営システム」構築プロジェクトにおける１月作業のご報告とご提案」と題する書面を交付し，平成２０年１月のサービスイン，「プロジェクト憲章」の「プロジェクトの目的」を達成するシステムの構築を目的として，開発計画の見直しの提案をした。この提案では，１４週間のスケジュールを予定するＢＲＤの進め方の方針として，ＩＢＭ傘下にＦＩＳ社を入れ，ＦＩＳ社のスキルを有効に活用するためＦＩＳ社の方針で進めていくこと，ＢＲＤは現在の要件定義書をベースに合理的なソリューションの検討を行うことが挙げられていた（乙１９８）。
また，現状の開発手法における問題点として，次のような指摘がされていた。
（a）　Ｃｏｒｅｂａｎｋの優位性が十分活かされないシステム
現状の開発手法は，現行のシステム機能の分析結果をベースに変革のテーマ等の新規要件を組み込む形態をとっており，Ｃｏｒｅｂａｎｋの最も顕著な優位性である柔軟な商品開発や新商品の迅速な展開という側面において，Ｃｏｒｅｂａｎｋのメリットを十分発揮でき得るシステム形態とならない懸念がある。
現行の原告の事務・システム機能をベースとしてＣｏｒｅｂａｎｋの機能の適合性を検証するというアプローチを採用し要件定義を実施したため，Ｃｏｒｅｂａｎｋの持つポジティブ・ギャップ（現行システムには存在しないが，Ｃｏｒｅｂａｎｋが製品として保有する機能）を有効に活用する検討が十分されていない懸念がある。
（b）　Ｃｏｒｅｂａｎｋスキルの欠如
Ｃｏｒｅｂａｎｋのパッケージ仕様に精通した要員がプロジェクトに参画していないことから，Ｃｏｒｅｂａｎｋの適合性判断における品質について懸念がある（製品知識が十分でない部分があるため，特に明確なＦｉｔ，明確なＧａｐ以外のグレー部分における判断においてＣｏｒｅｂａｎｋを利用した代替策等の検討が不十分な箇所があると認識）。
Ｇａｐの実現方式がＣｏｒｅｂａｎｋのコンセプトやアーキテクチャーと整合性がとられた方式であるということの技術的な検証が不十分であり，後続局面（開発やテスト）で問題として発覚する懸念がある。
（c）　システム複雑度合いの増大
Ｃｏｒｅｂａｎｋを有効に利用できずＧａｐの作りこみが大きくなることが結果としてＣｏｒｅｂａｎｋの外側に作りこむプログラムの増大につながり，システム全体の複雑度合いが増大する結果となる懸念がある。
開発するシステムが複雑になるほど，開発要員のコントロール，テストケースの複雑さの増大等につながり，プロジェクトの品質と成功裡なサービスインに影響を与え得る懸念がある。
（d）　サービスイン後の保守
Ｃｏｒｅｂａｎｋ機能の利用を前提とせず，大きな作りこみを多数することにより，将来的にパッケージの機能拡張の際にスムーズに製品のバーション・アップ等が図れなくなる懸念がある。
（オ）　平成１８年２月９日に開催された第１５回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の１５）。
ａ　被告は，グローバルＩＢＭのＳＩ部門のレビューメンバーが来日して，本件プロジェクト全体のレビューを実施したことを報告した。被告は，上記レビューにおいて，①計画・要件定義＃２で基幹系について現在作成されている要件定義書を基にそのまま設計・実装を進めた場合，ⅰ）新処理フローの記述において，Ｃｏｒｅｂａｎｋに整合しないフローとなっている可能性があり，実装段階でその不整合が顕在化するリスクがある，ⅱ）Ｃｏｒｅｂａｎｋ機能及びメリットを十分に享受できないシステムとなる可能性がある，ⅲ）横展開可能な「邦銀標準」としてのシステムとならない可能性がある，②システム化対象範囲が基幹系だけでなく，ＣＲＭ，ＤＷＨ，投信ほか極めて多数のコンポーネントの一斉サービスインとなっているが，安全かつ確実なサービスインに向けての検討が不十分であると指摘を受けた。
ｂ　被告は，上記指摘を受けて，従前提案していた全面的なＦＩＳ社（ＩＢＭ傘下）方式による１４週間のＢＲＤではなく，被告主導によりＦＩＳ社のＣｏｒｅｂａｎｋスキルを十分に活用した上で，邦銀標準を確立すべくＢＲＤ作業を実施し，併せて，安全かつ確実なサービスインへ向けての切替の検討作業を優先的に実施したいと考えていることを原告に伝えた。
ｃ　そして，被告は，上記①のリスクを回避する目的で旧ＢＲＤ作業を，上記②のリスクを回避する目的でシステム切替検討作業をそれぞれ実施したいと提案した。旧ＢＲＤ作業の実施内容の概要として挙げられたものは次の（a）～（e）であり，システム切替検討作業の実施内容概要として挙げられたものは次の（f）～（h）である。
（a）　原告の新業務フローの作成（被告及び原告）
原告の要件定義書及び事務取扱要領を基に新業務フロー（代表的な業務及び変革テーマにより変更される業務を中心）を作成。
（b）　邦銀標準の抽出（固有部分の特定）（被告及び原告）
他行事務との比較をし，邦銀標準プロセスを抽出，原告固有部分を特定。
（c）　Ｃｏｒｅｂａｎｋとの整合性確認（被告及びＦＩＳ社）
ＦＩＳ社と協業して，業務フローを基にＣｏｒｅｂａｎｋとの整合性の確認及びポジティブ・ギャップの抽出を実施。
（d）　原告要件と邦銀標準との差異（被告及び原告）
邦銀標準と異なると判断される部分については，邦銀標準に極力合わせるよう原告で検討をお願いしたい。その際，ユーザインターフェースの変更や業務プロセスの変更を伴う場合がありますが，検討，協力をお願いしたい。検討の結果，原告にて合理的と判断された場合には，邦銀標準への適合をお願いしたい。変革のテーマなど原告固有の要件については個別に設計，実装する。
（e）　ＢＲＤ結果を基にＣｏｒｅｂａｎｋの特性を反映した設計工程の作成（被告，ＦＩＳ社）
ＦＩＳ社と協業して後続工程（設計作業）を作成。
（f）　サブシステム間の相互依存関係の分析（被告）
要件定義書を基にサブシステム間の相互依存関係を分析し，サブシステム間の関連を明確にする。
（g）　テスト計画の作成（被告及び原告）
サブシステム間依存度を考慮したサービスインまでのテスト計画を作成する。
（h）　段階切替の検討（被告及び原告）
サブシステム間の依存関係を基に段階切替（先行リリース，後続リリース）の案を提示し，安全かつ確実なサービスインの実施を検討する。
ｄ　被告は，原告に対し，①カスタマイズをどれだけ抑え，その上で原告の要件をいかに満たすかが大きな課題と認識している，②他行の事例でも過去に大量の工数をかけカスタマイズを行ってきたシステムを，カスタマイズしたがゆえに複雑になりすぎて保守できない，保守要員を確保できないといった理由から，現在は本来のパッケージの姿に戻そうという動きになっている，③被告としては，全力を挙げて取り組み，何が何でも乗り越えるつもりであるなどと伝えた。
ｅ　原告は，被告に対し，事務の標準化について，原告は独自性を大事にしている会社であり，現状からダウンすること，あるいはお客様に影響を与えることは許されないこと，この点については譲れないと考えていることを伝えた。
これに対し，被告は，現実には変えていかないといけない事項も出てくると考えていること，そのときに短期間で決めていくためのルール作りも必要と考えていることを伝えた。
ｆ　被告は，原告に対し，旧ＢＲＤはこれをやっていくしかない本流の作業として考えていると伝えた。
ｇ　原告と被告は，被告から提案があった旧ＢＲＤ作業とシステム切替検討作業を実施することを決定した。
イ　旧ＢＲＤから新ＢＲＤまでの経緯等
（ア）　同年３月８日に開催された第１６回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の１６）。
ａ　被告のＦ専務は，①これまで手作り開発になれてきたこともあり，パッケージをベースとした開発をうまく推進できず，業界標準からずれた形の成果物となり，プロジェクトの進捗にも影響を与えたことに関してはお詫び申し上げる，②しかし，良いシステムを早く作る，そのためには品質を確保する必要があり，ＢＲＤとシステム間相互連携を意識した検討は必須と考えており，この作業を通して全体のデザインを見直し，日本の銀行の標準システムをＣｏｒｅｂａｎｋを活用して構築したいと考えている，③現在，被告だけでなく，グローバルの力を結集して進めており，不安を感じている方もおられるかしれないが，平成２０年１月にＣｏｒｅｂａｎｋで動かすということで進めているのでよろしくお願いしますなどと挨拶した。
ｂ　被告は，原告に対し，旧ＢＲＤとシステム切替検討実施に至った背景として，①平成１６年１０月の本件プロジェクト開始以降，被告においてパッケージベースの開発方法論を確立できず，計画・要件定義局面において現行機能ベースの開発を前提とした作業となってしまったため，Ｃｏｒｅｂａｎｋ機能の最適活用と横展開可能な標準化が推進できていなかったこと，②被告において一斉サービスイン（全店全業務一斉移行）のリスク評価を要件定義期間中に実施できなかったことがあったと報告した。
ｃ　被告は，旧ＢＲＤの作業計画について，平成１８年２月１６日以来打合せを実施した結果，同年３月３日までに，次のとおり予定していた作業及び合意事項が達成したことを報告した。
（a）　ＢＲＤ作業計画（ＢＲＤ実施の目的，ＢＲＤ作業を進めるに当たっての方策，ＢＲＤ作業内容，スケジュール）を確認，合意
（b）　対象業務フロー選定について検討，協議合意
（c）　新業務フローの策定上の指針
ｄ　旧ＢＲＤの作業概要は，次のとおりとされた。
（a）　方針策定
新業務フロー策定上の指針案，対象業務案についてのたたき台は被告が作成し，原告と協議・検討の上，確定させる。
（b）　業務フローの検討
①現行要件定義書，業務手続（Ｐａｌｅｔｔｅ）をベースに新業務フローを作成する，②新業務フローの見直し案については，ＦＩＳ社要員，邦銀業務精通者を交え，被告にて作成する，③新業務フローの見直し案の提示に当たっては，メリット，デメリットを合わせて提示し，原告と協議，検討の上，決定する。
（c）　商品定義の検証
①１０～２０程度の商品選定のたたき台は被告が作成し，原告と協議，検討の上，確定させる，②ＦＩＳ社にて要件定義書を基に商品定義を実施し検証する，③直しが必要な場合，原告と協議，検討の上，決定する。
（d）　アクティビティー図の修正
見直しとなった業務フローを基に修正が必要なアクティビティー図（Ｌｖ５）を特定し，修正する。
（イ）　平成１８年３月８日，第１６回ステアリング・コミッティで旧ＢＲＤ作業計画が承認されたことを受け，旧ＢＲＤ作業が開始された（前記前提事実(9)イ，甲６の１６）。
（ウ）　同年４月５日に開催された第１７回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の１７）。
ａ　被告のＦ専務は，旧ＢＲＤ，切替・移行計画検討もおおむねスケジュールどおり進んでいる，一部ＦＩＳ社との作業分担を詰める事項が残っており，遅れているものがあるが，キャッチアップ可能と考えていると話した。
ｂ　被告は，原告に対し，旧ＢＲＤの作業について，商品定義検証作業にてＦＩＳ社との作業調整がつかず遅延が発生していること，当初３月２１日の週から２１商品に関して実際にＣｏｒｅｂａｎｋ上に商品定義作業を実施予定であったが，個別に商品定義作業を実施する以前に，全商品定義に関し，商品定義の粒度及び要件定義局面で識別されているＧＡＰについて影響度（制度対応，顧客影響，事務影響）及び独自性（邦銀標準，原告固有）の観点から分類作業が必要と判断し，同作業をＦＩＳ社と共同で実施中であること，個別の商品定義の作業については４月から順次着手予定であることを報告した。
ｃ　原告は，被告に対し，制御グループ，基盤グループの作業に関して，ＢＲＤ実施後にマスタースケジュール見直しとあるが，旧ＢＲＤによりスケジュールが遅延するとは認識していないし，ＢＲＤ実施を原告が了解した条件は，スケジュールが遅延しないことであった，ＢＲＤを実施してもスケジュールは遅延しないという認識でよいかと質問した。これに対して，被告は，原告に対し，ここでのスケジュール見直しは，旧ＢＲＤの結果により作るものや作り方が変わった場合，その変更内容を反映するというものであるとか，平成２０年１月の一括サービスインに変更はなく，切替・移行計画検討はあくまでコンティンジェンシープラン策定タスクとして検討をしていると答えた。
原告は，被告に対し，平成２０年１月に一斉切替を行うことは契約済みの事項であることは再認識していただきたいと述べたところ，被告は，了解していると答えた。
ｄ　原告は，切替・移行計画の検討について，コンティンジェンシープランというのは，あくまでも平成２０年１月に本番稼動することを前提としてのコンティンジェンシーという認識でよいかと質問したところ，被告は，結構であると回答した。
（エ）　平成１８年４月１１日に開催されたプロジェクト進捗会議において，次のようなやりとりがされた（甲１３９）。
ａ　被告は，ＢＲＤ作業におけるＦＩＳ社の参画スケジュールについて遅延が生じており，商品定義検証作業とＣｏｒｅｂａｎｋの観点からの業務フローの見直し案作成について未着手となり，５月末のＢＲＤ作業完了に懸念が生じていると報告した。
ｂ　原告は，被告に対し，ＦＩＳ社との契約は何について合意できない状態なのかと質問したところ，被告は，作業内容や費用面の条件で折り合いがつかなかったと答えた。
ｃ　原告は，ＦＩＳ社の参画なしでＢＲＤは進められるのかを質問したところ，被告は，ＦＩＳ社の参画は必須であり，ＢＲＤも進める，ＦＩＳ社に参加してもらうことで社内で動いていると答えた。
ｄ　原告は，現在のＢＲＤの方向性はこれでよいのか，当初の目的として工数削減があったと思うが，現時点での検討結果を見ると，工数面ではむしろより良いものを開発することで工数が増えていると思われると質問したところ，被告は，横展開の観点から，追加費用及び原告側工数増加は発生しないため問題はないと答えた。また，原告は，邦銀標準の観点からも，もっと大幅な見直し提案があってもよいのではないかと考えていると提案した。
（オ）　被告は，第１６回ステアリング・コミッティにおける旧ＢＲＤ作業計画承認に基づき，①Ｃｏｒｅｂａｎｋ機能を最適活用する（業務フローのＣｏｒｅｂａｎｋの観点からの見直し及び商品定義の検証），②マーケット価値を訴求できる（他行に横展開可能な）日本標準の業務を標榜し，要件定義書を洗練するという二つを目的に旧ＢＲＤ作業を実施してきたが，ＩＢＭスペシャリストの検証により，旧ＢＲＤのアプローチでは十分にパッケージ・ベース・アプローチに沿っていないため，作業の変更が必要と判断するに至った。
そこで，被告は，平成１８年４月１４日，原告に対し，上記スペシャリスト検証を踏まえ，①本件プロジェクトは原告のみならず被告にとっても最重要であること，②当初の計画に基づいて本件プロジェクトを継続することでは成功裡にサービスインを遵守することは難しいこと，③本件プロジェクトの複雑さを考慮し，成功裡なプロジェクト完遂のために新しいアプローチが必要であること，④新しいアプローチの最初のステップが新ＢＲＤとなり，これはパッケージ・アプローチに準拠することを報告した上，新しいアプローチの新ＢＲＤに移行したい旨を説明した（甲６の１８）。
（カ）　被告は，同月２８日，ソリューション設計の簡素化及びＣｏｒｅｂａｎｋの最大活用を目的として，被告の実績あるパッケージ導入アプローチを適用し，原告，被告及びＦＩＳ社の３社の参画によりプロジェクト体制を再編成した上，「要件定義の再利用評価」，「棚卸し及びＣｏｒｅｂａｎｋとの対比」，「Ｃｏｒｅｂａｎｋ適合化」並びに「計画とスコープ」から成る新しいＢＲＤの実施を原告に対して提案した（甲６の１８，乙２３０）。
（キ）　同年５月１０日に開催された第１８回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の１８）。
ａ　被告のＦ専務は，①これまで古い方式で作成した要件定義書を基に作業を進めてきたが，日本の銀行システムの標準を作るという点から新たなやり方を模索してきた結果，ビジネス要件を満たすためには新ＢＲＤが最適であるとの結論に至った，②新ＢＲＤでは，グローバルＩＢＭからパッケージ・ベース・アプローチや銀行業務に精通した要員が参加するなどと述べた。
また，被告のＪ常務は，①昨年９月よりＣｏｒｅｂａｎｋを有効活用するためにパッケージ・ベース・アプローチで進めるということできたが，開発手法が固まらないまま進めてきてしまった，②Ｃｏｒｅｂａｎｋの位置付けも定まらないまま，２回ほど進め方も変更し，また，今回新ＢＲＤとして仕切り直しをお願いすることについて大変申し訳ない，③新ＢＲＤについては本件プロジェクトを正しい軌道に乗せるベストの方法と考えている，④本件プロジェクトではこれまでパッケージベースと言ってきたが，やり方を間違えていた，⑤被告においては，製造業や流通業でのパッケージ・ベース・アプローチの経験はあるが，銀行システムをパッケージベースで開発するという経験がないため，グローバルＩＢＭからＣｏｒｅｂａｎｋを熟知している者，パッケージ・ベース・アプローチの専門家を集めている，⑥昨年９月の合意書については，費用，スケジュール，スコープを含めて原告の要件が記載され，扱いについても会社間で合意したものと認識している。新ＢＲＤの中で合意書に記載されたビジネス要件をパッケージ・ベース・アプローチでいかに実現するか検討を進めていきたい，平成２０年１月にどういう形で実現できるか，原告のリクエストを聞きながら進めたいなどと述べた。
ｂ　被告は，原告に対し，旧ＢＲＤの状況として，①商品定義検証作業，Ｃｏｒｅｂａｎｋの観点からの見直しについては，ＦＩＳ社との契約の関係上実施できなかったこと，②この点については当初計画していた実施方法ではなく，新ＢＲＤの中で実施予定であること，③当初予定した３タスク（業務フローの見直し，商品定義検証，アクティビティー図修正）のうち，現時点では業務フローの見直しのうち現行要件定義をベースとした業務フロー作成及び邦銀標準の観点による見直し案作成については完了したが，Ｃｏｒｅｂａｎｋの観点による業務フローの見直しについては実施できなかったこと，④邦銀標準の観点からの見直し案については，原告側で検討を実施していることを資料に基づいて報告した。
これに対して，原告は，①なぜＣｏｒｅｂａｎｋの観点からの見直しが実施できなかったのか，なぜ新ＢＲＤではできるのか説明されたい，②契約上の関係とはどういうことか，③旧ＢＲＤでは後半の契約ができなかったということは，最終的な契約ができないのに旧ＢＲＤの実施を提案したのか，④新ＢＲＤでも６月になって契約ができずにやめたということはないのか，⑤新ＢＲＤでは大丈夫だということをどう信じればいいのかなどと述べた。
被告は，①契約ができなかったことは，旧ＢＲＤのやり方が間違っており，社内の承認が下りなかったためである，②旧ＢＲＤは，要件が決まったものを主としてパッケージに合わせるという考え方であったが，新ＢＲＤは，パッケージを主として合わせるものと，独自のものを切り分けるという考え方である，③旧ＢＲＤのままでは，どれくらいの開発ボリュームになるか分からない状況であったなどと答えた。
ｃ　さらに，被告は，原告に対し，新ＢＲＤの概要として次のとおり報告した。
（a）　新ＢＲＤの目的は，①Ｃｏｒｅｂａｎｋを最大活用し，ビジネス要件をＣｏｒｅｂａｎｋ機能に極力合わせる，②邦銀標準の銀行基幹系システムを確立する，③安全な切替・移行計画を策定するという３点である。
（b）　上記目的を達成するための方策として，①ＢＲＤフェーズではＩＢＭの実績あるパッケージ導入アプローチを適用する（ビジネス要件を理解する，ビジネス要件の優先順位付けを実施する，戦略要件の実現のためのギャップ（差異）を特定する，戦略要件以外のエリアは業務プロセスをＣｏｒｅｂａｎｋに合わせる，原告業務担当者とＦＩＳ社との参画により実施する），②旧ＢＲＤの業務フローをインプットとし，検討未済分については，邦銀標準精通者の参画により補う，③旧切替・移行検討タスクでのアウトプットをインプットとし，ＩＢＭスペシャリストを交えてソリューション設計の簡素化を含めて検討するという点が挙げられる。
ｄ　原告は，被告に対し，新ＢＲＤの目的について，ビジネス要件をＣｏｒｅｂａｎｋ機能に極力合わせるとあるが，これはビジネス要件をＣｏｒｅｂａｎｋ機能に極力合わせて実現するということでよいか，と質問したところ，被告は，御指摘のとおりであると回答した。
また，原告は，新ＢＲＤの目的は本件最終合意書の実現であり，そのために旧ＢＲＤと同様にＣｏｒｅｂａｎｋ機能の活用や邦銀標準の確立を目指し，新ＢＲＤはあくまでもその手段であるが，具体的な作業方法を提示されていないため，今後作業内容を協議，合意した上で実施するということでよいかと質問した。これに対し，被告は，①そのとおりであり，考え方，基本方針は変わらない，ビジネスニーズも変わらない，プロセスや作りが変わるものである，②パッケージの機能に合わせるものについては細かなレベルでは変わる可能性はあるが，ニーズそのものが変わることはない，③今までの現行機能をベースとしたものではなく，パッケージベースとなるので，要件定義書のＬｖ．５のような実現方式については変更となる，また，合意書についても，ビジネス要件だけではなく，実現方式について記載されている部分もあり，その部分は変更となるなどと答えた。
さらに，被告は，パッケージに合わせることを検討する際には，①銀行システムの基本となるもの，②邦銀標準となるもの，③原告が他行との差別化のために独自に有するものの三つに分けて進めるものであるところ，戦略的なものについては作るが，極力パッケージに合わせて使ってもらえないかと考えている，海外のパッケージが扱っていない商品，サービス，機能だからといって，それらを削ることはないなどと話した。また，被告は，要件定義書については，実装するときのＶａｌｉｄａｔｉｏｎ用資料となること，そこで記載された要件は，場合によっては手作業になったり，機能レベルで実装されないものが出てくる可能性があるが，銀行との合意なしに勝手に削ったりはしないなどと話した。
ｅ　原告と被告は，新ＢＲＤを実施することについて合意した。
（ク）　平成１８年６月２日に開催された新ＢＲＤキックオフ・ミーティング（第１９回ステアリング・コミッティの代替）において，被告のＪ常務は，①新ＢＲＤの検討では，１年半掛けて分析，設計を行ってきたこれまでの成果を踏まえ，原告のこれからの２０年，３０年の経営を支えるシステムを作っていく，②実装の仕方は変わるかもしれないが，何をやるか，実現すべき要件は，新ＢＲＤになっても変わらない，③ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋを最大限活用するために開発のやり方を変更するものであり，本日のキックオフ・ミーティングはその方針確認に対する参加者の意識を揃えることが目的である，④ＢＲＤにより，ⅰ）いかにパッケージに合わせて要件を実現するか，ⅱ）サービスインについてどういう形でやるのが確実か，この２点を明らかにするなどと挨拶した。
また，同会議において，新ＢＲＤプロジェクトの目的，プロジェクト体制，検討範囲及び会議体が決定された（甲６の１９）。
（ケ）　被告のＦ専務は，同月２９日，Ｅ副社長及びＣ専務と打合せを行った。Ｅ副社長は，最初からパッケージベース開発ができると思ってＩＢＭにお願いしていたにもかかわらず残念であると述べた上で，平成２０年１月にサービスインができるのかを尋ねたところ，Ｆ専務は，現時点では分からない，いかにパッケージ／邦銀標準に合わせられるかが鍵であると答えた。また，Ｅ副社長は，初期費用に関して追加費用を要求するのかを尋ねたところ，Ｆ専務は，「現時点では分からない。ビジネス要件は基本的に実装するが。ＩＢＭも７０億近い投資を予定しており，ＢＲＤでこの投資内に収めるようにしたい。」と答えた（乙２８５）。
（コ）　平成１８年７月５日に開催された第２０回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の２０）。
ａ　被告は，原告に対し，Ｃｏｒｅｂａｎｋ業務チーム・ディスカバリーステージの結果について，資料に基づき次のとおり報告した。
（a）　ディスカバリーステージの期間中，業務チームは現在の原告の商品，業務プロセス及び変革のテーマについての検討を行った。業務チームは，現在の原告の機能，業務プロセスがＣｏｒｅｂａｎｋが提供する機能やプロセスと異なる部分についての特定を実施した。これら特定された項目は，Ｇａｐとして個々のチーム（預金，融資，顧客）のセッションの中でリスト化され管理されている。
（b）　ＦＩＳ社及び被告の業務チームは，現在これらのＧａｐを調査し，Ｇａｐの妥当性の確認及びどのような変更がＧａｐを解決するために必要とされるかという点についての分析を行っている。この分析の一環として，ＦＩＳ社及び被告から，原告に対し，銀行の業務プロセスや業務手順の変更を行うことが可能と思われるもののリストを提示する予定である。この作業を支援する位置付けとして，現在原告の業務チームメンバーがＧａｐ内容を分析し，Ｇａｐのカテゴリー分けと優先順位付けを実施している。カテゴリー分けによる分類は，①法定に起因するもの，②既存のお客様に影響のあるもの，③現行の業務プロセスに影響のあるものに分類する予定である。
ｂ　原告は，被告に対し，①マル優など以前から分かっているＧａｐではないか，これではゼロからギャップ分析を行っているようなもので，新ＢＲＤは手戻りであり時間の無駄ではないのか，②新ＢＲＤ以前に担当されていたメンバーを戻してやった方が効率的ではないのか，Ｃｏｍｐｉｌａｔｉｏｎステージは，過去担当していたメンバーや投入することも含めてもっとやり方を考えるべきである，③以前のＦｉｔ＆Ｇａｐ結果の資料や人材の有効活用についてはこれまでもお願いしてきた事項であるなどと意見を述べた。
これに対し，被告は，①ギャップについて，その理由や必要性をＦＩＳ社が認識できたことは，今後ＦＩＳ社がギャップの解消方法を検討していく上で有意義であったと考える，②過去担当してきた者ということでは，全員ではないがキーマンを残している，③以前のＦｉｔ＆Ｇａｐ時の成果物は英訳し，活用していくなどと回答した。
ｃ　また，原告は，被告に対し，話を聞いているとＣｏｒｅｂａｎｋに合わせろと言っているように聞こえるが，原告は，他の銀行よりも柔軟に対応することで生き残っている銀行であり，原告独自の機能の実現は必須であるし，同時に日本の銀行として当然備えるべき機能も実現する必要があるから，Ｇａｐのカテゴライズにある①法定に起因するものについては「ねばならないＭＵＳＴの機能」であり，②既存のお客様に影響のあるものについても同様に「ＭＵＳＴ」である，③業務プロセスに影響のあるものについては，もっとディスカッションを行う必要があるなどと述べた。
これに対し，被告は，Ｃｏｒｅｂａｎｋは，①顧客志向のシステムであること，②商品定義を柔軟に行えること，③商品のパッケージ化が容易であること，④経営の意思決定判断のために必要な情報を提供していることといった特徴を持っており，原告の要望におこたえできるパッケージソフトであることをお伝えしたいと述べた。加えて，被告は，①カテゴライズのうち法定に起因するものについてはＦＩＳ社と被告で対応する，②業務のプロセスについては，きちんとした分析をすべきであり，その上で原告への影響が小さいことが分かればＣｏｒｅｂａｎｋの仕様に合わせてもらうことを推薦することもある，③独自性を保持するために必要なものは当然変える余地はないなどと答えた。
原告は，業務プロセスについては具体的なものが出てきていないので判断できないが，合理的な提案であれば変えることも考える，日本の銀行で標準的にやっているものについては実現していただくということでよいかと尋ね，被告は，結構であると答えた。
ｄ　新ＢＲＤ局面において発見されたＣｏｒｅｂａｎｋグループのギャップの解決策やｎｏｎ－Ｃｏｒｅｂａｎｋ／Ｔｅｃｈｎｉｃａｌグループの合理化案について，被告とＦＩＳ社において作成し，それを原告に提案するということとなった。
（サ）　同年８月９日に開催された第２１回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の２１）。
ａ　被告のＦ専務は，①パッケージに合わせることについては，原告の協力に感謝する，②無駄を多く省くことができたと認識している，③ＢＲＤを実施して良かったことは，開発スケジュールがどのようになるか具体的に見えてきたことである，④平成２０年１月の一斉切替については，全面切替は厳しいが，どういった形でできるのか，現実解としてもどこにも迷惑をかけない健全な方式を決めるために議論を進めていきたいなどと挨拶した。
また，被告のＪ常務は，①１７４件のギャップが洗い出され，うち４６件については，いかにＣｏｒｅｂａｎｋに適用させるか検討させていただいた，うち２０件について代替策を導き出した，②ｎｏｎ－Ｃｏｒｅｂａｎｋ，テクニカルについては，提案内容の６割から７割程度を採用いただき，前向きな協力に感謝する，③切替・移行計画におけるスケジュールの短縮については特別な効果を導き出せておらず，現在，技術的に詰めた二つの案を担当者間で議論させてもらっているが，原告の平成２０年１月からのビジネスニーズと突き合わせしながら，開発のフィージビリティも考慮し，現実的な案をまとめていきたいなどと挨拶した。
ｂ　被告は，原告に対し，切替・移行計画について，当初の一括切替案について，ＦＩＳ社と被告の技術者が細かな検討を行ってきたが，全員一致で，全てのことを一度に行うことは正当化できないリスクがあることが分かった，一括切替を平成２０年１月に行うことは無理で，本日提示する二つのオプションこそ，リスク面，機能面等を考えた中で最もバランスの取れた案と考えると述べた。
原告は，ＢＲＤ開始時に平成２０年１月のサービスインに間に合わせるための唯一の道だと説明を受けたが，結果としてそうならなかった理由を明確にしていただきたいなどと述べた。これに対し，被告は，①Ｃｏｒｅｂａｎｋがどこまでできるのか，これまで被告は分かっていなかったが，ＢＲＤにより肌で感じることができた，②これから立案するスケジュールは実現性が高いものと考える，③ＢＲＤ実施前後を比較すると，当時思っていた以上にリスクがあることが分かった，④スケジュール短縮の期待はあったが，Ｃｏｒｅｂａｎｋだけでなく，周辺も含めて考えると，２案以外にないのではないか，⑤ＢＲＤを実施する前に比べて見積り精度が上がっており，これならできるという担当者の納得も，Ｃｏｒｅｂａｎｋの活用の確信度合いも違うなどと述べた。
Ｃ専務は，メンバーが不安に感じている，被告は最初からなぜＢＲＤをやらなかったのか，遅れることによる出費，要員確保などをどうするのか，そもそもこれまで原告は被告に従ってプロジェクトを進めてきた，遅れたことの原因と責任が被告にあることについて，原告として譲る気はない，したがって，追加費用が発生しても原告は一切負担しない，被告のプロジェクトの進め方に問題があったのではないか，Ｃｏｒｅｂａｎｋについて被告は十分理解していなかったのではないか，だからＦＩＳ社を入れてＢＲＤを実施したのではないかなどと発言した。
被告のブロッシュは，責任の所在については被告の責任もある，どの部分が被告の責任か，また今後どう対応していくのかについて，別途打合せの機会を設けてほしいと述べた。
ｃ　被告は，原告に対し，切替・移行計画として，リスク，投資，機能充足度等について検討した結果，二つの代替案を提示した。一つは，ＦＩＳ社が提供するオンラインシステムと主要な周辺を先行してリリースし，後続においてバッチ及び残りの周辺を移行するという基幹系先行案であり，平成２１年１月に先行部分リリース予定とされた。もう一つは，ＦＩＳ社のパッケージの基本的な機能を使って戦略的な新商品を提供するもので，ビジネスの成長が期待できるとされた新商品先行案であり，機能，範囲が少なく時間短縮が可能なため，平成２０年１月に先行部分リリースが可能とされた。
原告のＣ専務は，経営サイドとしては本日の案は受け入れ難いが，週末に新たな案を被告から出してもらえるということなので，それを拝見した上で議論させていただきたいと述べた。
ｄ　原告と被告は，平成１８年７月２５日に打合せがされた次の３点の合意事項について承認した。
（a）　現行要件定義書をベースとしてＢＲＤ成果物を追加する。
（b）　ＢＲＤ成果物は現行要件定義書を代替するものではない。
（c）　新ＢＲＤでは現行要件定義書を修正しない。
（シ）　被告は，新ＢＲＤでＣｏｒｅｂａｎｋとのギャップとして識別された１７４件のうち，現在実施している方式を継続するために必然的に発生してしまうギャップ若しくはＣｏｒｅｂａｎｋのシステム機能根幹に関わるギャップとして識別された４６件について，被告及びＦＩＳ社がＣｏｒｅｂａｎｋに合わせた業務的な代替回避策を検討した上で原告に提示した。原告は，検討した結果，平成１８年８月１７日，そのうち２０件について業務的代替回避策を採用することを決めたが，２４件については業務的代替回避策の採用を不可と判断したので，Ｃｏｒｅｂａｎｋを中心としたテクニカル・ソリューション（システム対応）によって対応することが決定した（甲４４，６９）。
（ス）　被告のＫ代表取締役社長（肩書は当時。以下「Ｋ社長」という。）は，同月３１日，原告のＡ代表取締役社長（以下「Ａ社長」という。）に対し，新ＢＲＤの終了を報告した上で，ＢＲＤの結果，平成２０年１月のサービスインが難しい状況と判断していること，サービスインの時期が平成２０年１０月になる可能性が高いことを伝えた。これに対し，Ａ社長は，Ｋ社長に対し，平成２０年５月にはサービスインを実現してもらいたい旨伝えた。また，Ｋ社長は，Ａ社長に対し，ＢＲＤの結果，コストも大幅に増えており，被告も先行投資をしていくが，原告にも費用面での今後御協力をお願いしたいと伝えた（乙１５５）。
（セ）　平成１８年８月３１日に開催されたＢＲＤ最終報告会において，次のようなやりとりがされた（甲２６）。
ａ　同会議で配付された被告作成の「「新経営システム」構築プロジェクトＢＲＤ局面最終報告エグゼクティブ・サマリー」と題する書面中「ＢＲＤの概要」のＢＲＤの主要目的の一つとして，(4)項に「当初想定投資の再見積りを行う」旨の記載がされていた点について，原告は，①後付けで目的を追加することは認められないので削除されたい，②追加した理由も最終合意を破棄するためであるのかなどと指摘した。これに対して，被告は，①プロジェクト推進にとって重要な事項であり，健全なプロジェクト運営とするために必要な事項ということで追記した，②本件はあくまで被告内部において再見積もりしたもので，ＢＲＤ実施により，明確になったということを報告したかった，③ＢＲＤ開始時点で目的として原告には提示していなかったが，ＢＲＤを通して作業工数を正確に理解することは被告としてＢＲＤ実施目的であった，④ＢＲＤを実施したからこそ，より正確に理解することができるようになり，これからどうプロジェクトを進めていったらよいか理解が深まったなどと述べた上で，上記の項目は，被告内部の事項であり，当初設定した目的にはなかったことなので，削除することとされた。
ｂ　被告のＪ常務は，当初のＢＲＤの目的，期待値に対してできていないこともあることは認識しているが，基盤としては詳細なものができたと考えているし，本件プロジェクトが当初想定よりも複雑だということも認識できたなどと述べた。
ｃ　原告と被告との間において，ＢＲＤはこの最終報告会をもって完了し，９月から設計フェーズに入ることが決定された。
ウ　新ＢＲＤ終了後から平成１８年１２月末までの経緯等
（ア）　被告のＦ専務は，平成１８年９月７日，原告のＥ副社長と打合せを行った。Ｅ副社長は，サービスインについて，平成２０年５月に全てやってくれとは言わないが，なんとしても平成２０年５月のサービスインを実現してほしいと伝え，Ｆ専務は，どうすれば可能になるのか最大限の努力をして検討していると答えた。また，Ｆ専務は，Ｅ副社長に対し，期間が延びることによる追加コストについては相談したいと伝えた（乙１５６）。
（イ）　原告と被告は，平成１８年９月１日以降，切替・移行計画の案について集中検討を行っていたところ，同月１２日に開催されたプロジェクト進捗会議においては，原告と被告のプロジェクトレベルで同月１５日までに切替・移行案について合意形成できる見通しであったが，原告の経営陣に承認されるかは原告プロジェクトメンバーにも不明であった。その後，被告は，同月１９日，原告に対し，４段階リリース案（平成２０年１月から４段階に分けてサービスインをし，平成２１年５月に全面稼動）を提案した。しかし，同案については，移行の最終段階（Ｓｔｅｐ４）として計画していた口振，法定帳票，ＤＷＨ，バッチ帳票のサービスイン時期（平成２１年５月）について，原告の経営陣は了承しなかった（甲６の２２，乙１０５）。
（ウ）　平成１８年９月２５日に開催された第２２回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の２２）。
ａ　原告は，同月１９日に提案された切替・移行計画案について，平成２０年１０月，遅くとも同年１２月までにフルスコープを実現していただきたい，現時点では平成２１年５月については合意していないことをお伝えするなどと述べた。
ｂ　被告は，平成１８年９月１９日に提案した切替・移行計画案から最終段階（Ｓｔｅｐ４）として計画していた口振，法定帳票，ＤＷＨ，バッチ帳票のサービスイン時期について，前倒しの可能性を探ってきた結果として，口振と法定帳票についてはＳｔｅｐ３に前倒しすることを前提に今後の作業を進める予定であるが，ＤＷＨ，バッチ帳票については現時点では前倒しができるとは申し上げられず，基本設計作業の中で見極めていきたいなどと述べた。
これに対し，原告は，前倒しについて言及できないのはおかしい，検討漏れがあったのかなどと質問したところ，被告は，ＢＲＤで注力したのは業務要件の確認であり，中心はＣｏｒｅｂａｎｋとのギャップを明らかにすることであった，帳票，ＤＷＨについてはもう少しＤＢ構造や各データソースを調べてから見極めたい，極力前倒しができないかということを検討したが，現時点ではそれに至っていないなどと答えた。
原告は，今まで十分な要員を投入せず十分な検討もされていない状況で，平成２１年５月まで本番稼動が延びることは納得できないなどと述べたところ，被告は，原告，被告双方のメンバーでバッチ帳票のスペック，構築のスケジュールを２，３日で集中検討することを提案したいがいかがかと話した。これに対して，原告は，これまで被告の要望に沿って５０００の帳票を大幅に減らしてきた，そのために小会議を繰り返してきたが，過去の経緯を軽視しすぎていないのか，新ＢＲＤの３か月間で帳票について具体的な検討がされてこなかったのが不満であるなどと述べた。
ｃ　また，原告は，サービスインの時期については，平成２０年１２月でなければ到底受け入れられない，どのように説明を受けようと平成２１年５月リリースであるというのであれば原告としては協力できない，原告としては全体の完了が平成２０年１２月であり，段階的に進めていって全体の完了が平成２１年以降になることは認められないなどと述べた。被告は，平成２０年１２月までにどこまでやるのかを今後検討させていただきたいと返答した。
ｄ　Ｓｔｅｐ４のＤＷＨと還元帳票については，平成２０年１２月本番稼動を目指して，どのようにすれば実現できるのか，１か月間の期間で検討を継続することとされた。
（エ）　被告のプロジェクトレベルのメンバーは，平成１８年１０月２４日，原告のプロジェクトレベルのメンバーに対し，総額で１億１０００万ドルの追加費用が必要で，そのうちの３０００万ドルを原告で負担してほしい旨を申し入れた。原告のプロジェクトレベルのメンバーは，追加費用について，プロジェクトレベルで受け入れる余地はないと拒否した上で，Ｃ専務に上記申入れがあったことを報告した（甲１４６，乙１０３の１，３０７）。
（オ）　原告と被告は，同年１１月９日に打合せを行い，そこで開発スコープの削減や追加費用負担についての話合いがされた（甲１５３，乙８３）。
（カ）　原告と被告は，同月１３日に開催された第２３回ステアリング・コミッティにおいて，次のスケジュールで本件システムを稼動させるという基本的な方向性について合意した（前記前提事実(9)キ）。
ａ　平成２０年１月：外為関連の新商品の提供に関するシステム稼動
ｂ　同年５月：本件システムによる一部サービスの開始
ｃ　同年１０月：全営業店における基幹系システム稼動
ｄ　同年１２月末：本件システムの全面稼動
（キ）　被告のＦ専務，Ｊ常務らは，平成１８年１１月２１日，原告のＥ副社長及びＣ専務に対し，本件プロジェクトのコストが大幅に増加していることを説明した上，スコープの削減と共に追加費用の負担についての提案を行った。具体的には，平成１７年９月時点の見積もりが１４７億円（原告６８億円，被告７９億円）であったのが，現在３１６億円となっていること，見積増加分の１６９億円の内訳として，①有効活用が困難と思われる部分が５４億円，②原告の現行システムへの対応で予想していなかったものが４５億円，③コスト削減を予定していたが実現できなかった部分が１０億円，④サービスイン時期延長によるものとして１５億円，⑤想定以上に詳細設計以降のワークロードがふくらんだ部分として４５億円であることを示した上で，二つのスコープ削減案とそれぞれの追加費用についての案を示した。しかし，原告が，上記提案内容は全く納得できないとの考えを明らかにしたため，提案内容についてのお互いの理解のすりあわせ，原告のコスト増加を含めたトータルコストの検討を原告と被告で至急実施することで合意した（乙３１０，３１１）。
（ク）　被告のＦ専務らは，平成１８年１１月３０日，原告のＣ専務らと打合せを行った。その中で，Ｆ専務は，被告に対する支払以外に原告で必要となるコストについても検討したとして，被告に対する支払以外に非常に大きなコストがかかる状況であることを説明した。また，Ｆ専務は，開発スコープを勘定系に絞ったケースを想定すると，被告に対する追加費用約４４億円のうち，１０億円は被告が追加投資するので，３４億円は契約してもらいたいこと，３４億円に対しては，コミッション方式（ペイバック方式）を検討することを提案した。
原告と被告は，同年１２月末までに現実的なスコープとコストを決めていくこと，方向性について社長同士のミーティングを持つことで同意した（乙２９４，３１２，３１３）。
（ケ）　同月１日，更新版要件定義書１式を含む基本設計に係る品物が，被告から原告に対して納品された（甲６の２４）。
同月６日に開催された第２４回ステアリング・コミッティにおいて，被告のＪ常務は，基幹系詳細スケジュールについては同月１５日に原告に納得していただける内容のものを提示したいと述べた。これに対し，Ｃ専務は，このプロジェクトは次世代のバンキングシステムを作るということで，大いに期待している，次世代にふさわしい良いシステムを作っていただきたいと述べた（甲６の２４）。
上記ステアリング・コミッティと同じ日に，Ｃ専務とＦ専務は面談する機会を持った。Ｃ専務は，Ｆ専務に対し，被告側から出されている追加費用の負担の申出について，本件最終合意書の金額は被告から持ち出されて決めたものであり，被告が間違えたとか，Ｃｏｒｅｂａｎｋを知らなかったからといって，費用をユーザの負担とするのは納得できないと告げた。これに対し，被告のＦ専務は，原告のＣ専務に対し，「普通の地方銀行が１０年でやることを短期間で，しかもあの金額でやれるのか，無謀な計画で突っ走って来てしまった。」などと述べた。また，Ｆ専務は，最善の方法は，やめるわけにはいかないので，負担部分を一時原告に負担してもらい他の顧客がついたら被告から原告に返すというようなペイバック方式を確固たるものにすることであるなどと述べた（甲１２８）。
（コ）　被告のＦ専務は，同月１１日，原告のＣ専務に対し，スコープ削減，追加コストのお願い等の提案をした。被告作成に係る同日付け「「新経営システム」構築プロジェクトの今後の進め方に関するご相談」と題する書面には次のとおり記載されている（甲７，乙２９５）。
ａ　本件最終合意書での計画が継続できなくなり，ＢＲＤを実施しなくてはならなくなった理由について，①パッケージ・ベース・アプローチが徹底されておらず，現行機能からの積み上げで要件定義を行ったため，パッケージ機能に整合しない仕様になっている可能性があり実装段階でその不整合が顕在化するリスクが認識されたこと，また，パッケージ機能及びメリットを十分に享受できないシステムとなる可能性が生じたこと，②システム化対象範囲が基幹系だけでなく極めて多くのコンポーネントに及び，かつ一括リリースとなっていたため，安全かつ確実なサービスインへ向けて多大なリスクが認識されたことが挙げられた。
ｂ　ＢＲＤ実施後，再度プロジェクトの経過を見直す必要が出てきた理由として，ＢＲＤの成果自体は，期間短縮，工数削減に寄与したが，ＢＲＤの検討結果を踏まえて改めて計画策定，コスト見積もりを実施した結果，本件最終合意書時点での想定は，スケジュール，コストともに大幅に過少に見ていたことが判明したとされ，①スケジュールに関しては，残念ながら当初目標であった平成２０年１月の一括サービスインが実現不可能であることが明らかになり，４段階リリース案を提案した，②ＢＲＤの検討結果を受けてコスト見積りの精緻化を行った結果，本件最終合意書締結時点の想定を大幅に超過することが判明し，開発規模（ピーク時の要員数等），両社の投資余力の観点から，フォーカススコープでの提案をせざるを得ない状況となった。
ｃ　今後原告に追加で発生する総費用は，全スコープを実現する場合には，被告に対する支払費用１２７億円，それ以外に掛かる費用（サービスイン延期に伴う費用）約３８億円を合計した約１６５億円である。また，今回提案しているスコープ（①金・公共債，端末管理，口振は原告が開発，②ＣＲＭ，バッチ（帳票，法定帳票，リンクデータ）は現行システムを活用，③投信，ＤＷＨ，外為，顧客営業支援は開発範囲見直し）の場合，被告に対する支払費用４４億円，それ以外に掛かる費用（サービスイン延期に伴う費用，現行システムとのブリッジ開発にかかる費用，現行システムを残存させることに伴うＩＢＭハード・ソフト費用，現行システムを残存させることに伴う他社ソフト費用）約６６億円を合計した約１１０億円である。
ｄ　今回提案したスコープで本件プロジェクトを実施することを承認していただきたい。
ｅ　被告に対する追加費用として約３４億円，残存及び追加ハードウェア，ソフトウェア費用（約１９億円。サービスイン後５年間と想定したもの。）を平成１９年１月中旬をメドに契約していただきたい。
（サ）　原告のＥ副社長と被告のＦ専務との間で，平成１８年１２月１３日，開発スコープ及び開発費用について打合せが行われた。
Ｆ専務は，これまでの経緯を説明した上で，開発スコープは勘定系以外のスコープは全て削減し，その上で追加費用３４億円の支払をしてもらいたいこと，この場合，被告以外への費用を含んだ原告の追加費用総額は約１１０億円以上となることなどを伝えた。これに対し，Ｅ副社長は，①当初の約束が全て反故にされたこと，②現行システムを残した二重オペレーションは費用，効率，サービス品質の観点から受け入れられないこと，③提案が受けられないならプロジェクトをストップするとの被告の発言によって被告への信頼が壊れたことを挙げて，このようなひどい提案は受けることができないので，これならもう本件プロジェクトをやめようなどと述べた。
Ｆ専務は，Ｅ副社長の説得を行い，原告から見た本件プロジェクトを続けるための条件を質問したところ，Ｅ副社長は，①二重オペレーションは受け入れられない，②周辺システムを実現すること，③追加費用は最大でも２０億円であること，④平成２０年１０月又は周辺システムができたときに支払を行うなどと話した（前記前提事実(9)ケ，乙１１２）。
（シ）　被告は，平成１８年１２月２２日，原告に対し，同月１３日にＥ副社長と話し合ったことを踏まえて，開発スコープを同月１１日の提案より拡大し，原告の追加負担費用額を２０億円に減少させた案を提案した（前記前提事実(9)コ，甲２８）。
（ス）　原告のＣ専務は，同日，被告のＦ専務に対し，電話を掛けた。その中で，Ｃ専務は，Ｅ副社長に同日の被告からの提案（上記（シ））を伝えたところ，Ｅ副社長からの課題として，フルスコープのソリューションを開発するケースでは，被告は，前回１２７億円を提案していたが，本日の提案では２０億円の追加となったのであり，そのようになった合理的な説明とギャップを詳しく知りたいなどと申し入れた（乙３２０）。
（セ）　原告のＨは，同日，被告に対し，本件プロジェクトの費用負担に関してメールを送ったところ，被告は，原告の追加費用が大きいこと，トータル費用が被告の投資よりも大きくなることも認識していると回答した（甲１４４）。
また，Ｈは，同月２３日，被告に対し，「結果として当社の投資が御社より多いことに納得性が保つことが理解できない」，「あまりにも当社の負担が増大しリスクテイクしている現状であります」などと記載したメールを送った（乙２１０）。
（ソ）　原告のＨは，同月２６日，被告に対し，Ｃ専務からの伝言として，「費用について」「①当社の交渉が甘すぎた　２０億の追加はしない」「②たかだが１０日足らずの検討でここまで削減できるのならなぜＢＲＤ中に人員カットして検討しなかったのか」「③そもそも提示された金額がでたらめなものでありでたらめなまま当社経営にまで提示した責任はないのか」と記載したメールを送った。また，同メール内で，Ｈは，「資料見ましたが　あれだけの指摘にも関わらず　意図的な虚偽の資料を作成しているのはＩＢＭの投資の少なさを隠している悪質的な所作の結果と考えますので　ここに通知します。具体的には　再三無視しているので記入しますが　ハードウェアや追加投資他のＮＥＦＳＳ関連投資をグラフ上に記入せず　誤った判断をクライアントにさせようとしているということです」とも記載した（乙１０３の２）。
（タ）　原告のＨは，Ｃ専務からの伝言として，「①たかだか数週間の検討の前と後の比較説明資料を提出してください」，「②２０億は無しで進めてください。２億の話ですべて当社の中ではリセットされています。逆説的ですが１２０が２０に簡単になったのですから検討すべきことはしましたので　残りは御社の負担でどうぞお願いします」と記載したメールを送った（甲９２）。
(3) 　平成１９年１月以降の経緯等
ア　ＴＣＢの提案まで
（ア）　原告は，被告からの２０億円の追加負担の提案について検討した結果，当初の提案から１０７億円も削減できた正確な理由は被告に確認しないと分からないものの，①原告への作業移転，②被告作業自体の効率化であると思われ，被告が提案のあった２０億円を負担としたとしても，原告の方が負担が大きいのではないかと考えていた（甲１４３）。
（イ）　原告は，平成１９年１月５日，被告に対し，合意書案を来週月曜までに提示するように求めるとともに，これについて，①原告が追加費用として２０億円を目処にするということはなく，この点をＣ専務と交渉しても無駄だと思うこと，②４６億円の内訳の詳細を表示することが前提となることを伝えた（甲９４，９５）。
（ウ）　被告は，同月１２日，原告に対し，支払総額を１０９億７０８０万円（本件最終合意書の金額に追加費用額２０億円を加算した額）とする合意書のドラフトを提示した（甲９６）。
原告が，被告に対し，２０億円の内訳，根拠を提示することなどの要望を伝えたところ，被告において，検討して修正案を提示することとなった。
同日，被告は，原告に対し，上記２０億円の追加費用のほか，ＳＣＳへの委託料１０億円及び追いつき案件の対応に要する費用１０億円の合計２０億円を負担するように求めた（乙２３８）。
（エ）　同月１８日に開催された第２５回ステアリング・コミッティにおいて，次のようなやりとりがされた（甲６の２５，甲５０）。
ａ　Ｈは，被告から提案されたスコープについて，これまでのステアリング・コミッティで説明も受けていない，また承認も得ていないようなものがなぜ突然出てくるのか，内容も結論のみ記載されており，なぜスコープ削減を行わなければいけないのか，その理由，目的，検討の経緯といった内容がない，きちっとした説明が必要であるとなどと述べた。また，Ｃ専務も，本件は契約に関わる根幹的な事項である，内容を見ると当初の合意内容を大きく覆すもので，この場で決定できるようなものではない，スルガは，これまで業務の見直しや帳票の削減等，コスト削減を図ってきた，ＢＲＤ，新ＢＲＤについても同様であり，すべてＩＢＭの要望に応えてきた，その上で現在の状況にあるのは進め方が悪かったのではないかなどと発言した。
ｂ　これに対し，ランドルトは，指摘のあった資料は，決定したものではなく現在の状況を説明するものであるとした上，実現可能なプロジェクトにするには作業の見直しが必要である，ＢＲＤを実施したが，時間，スコープの観点からみてデリバリ可能な状況ではなかった，契約と著しく異なっていることは認識しているが，本プロジェクトを実現可能なものにするには，真のインフラを築く必要がある，今回作業レベルでは，ソリューションについてスルガと前向きな検討ができたことを感謝すると述べた。また，Ｎは，当該資料は現場レベルでの技術的な検討結果をまとめたものであると指摘した。
ｃ　これまでの発言を受けて，Ｃ専務は，現場の作業を否定するものではない，本件はＩＢＭの経営としてどう責任を取るかという経営マターである，本資料については，見直しの上，目的，理由，経緯等のコメントを付することをお願いすると発言し，これに対し，Ｎは，了解したと返答した。
（オ）　被告は，平成１９年１月２４日，支払総額を１０９億７９８０万円とするなど本件最終合意書の内容を変更する「新経営システム」合意書の案（甲９７の１，２）を，改めて原告に提示した。なお，被告は，原告に対し，同日，ＣＲＭに関する追加費用（額は未定）及びｅＭｕＳＣ（インターネットバンキング）のパッケージライセンス料７億円などを追加負担することを求めた（甲９８）。
これに対して，原告は，支払総額を従前のとおり８９億７９８０万円とする合意書の案（甲９９の１，２）を原告に提示した。
その後も，原告は，被告に対し，引き続き，２０億円の根拠を示してほしいとの申入れをした（甲１００，甲１２２の１）。
（カ）　Ｆ専務は，Ｃ専務に対し，同年１月３１日，ＣｏｒｅｂａｎｋについてＦＩＳ社のデリバリーが遅れる可能性が大きく，サービスインのスケジュールが現に合意している平成２０年１月から平成２１年５月になるリスクが大きいことから，「今月末までにスルガ様に結論を出すことをお願いしていた新ＭＯＵ締結につき，その結論の期日を２月半ばまで延期させていただきたい」と申し入れた。これに対し，Ｃ専務は，ＩＢＭの責任でプロジェクトが迷走したにもかかわらず，なぜ原告に全ての責任を押しつけるのか，なぜもっとＦＩＳ社を早期からプロジェクトに入れなかったのか，平成２０年１０月のサービスインは平成１８年１０月に合意したことであり，これが平成２１年５月になることは受け入れられないので，なんとしても平成２０年１０月にできるように検討，推進してほしい，ＦＩＳ社は被告の管理下という位置付けであり，被告はＦＩＳ社を管理しているはずである，追加費用の支払について原告内部で承認を得るためには，当初プランよりも良いことが原告にあるという前向きのロジックが必要であるなどと話した。Ｆ専務は，Ｃ専務に対し，資料を準備の上，説明することを約するとともに，過去の約束を離れて被告の新しい提案を聞いてほしい旨依頼した（乙２４６）。
（キ）　平成１９年２月１７日，Ｃ専務は，Ｆ専務と面談し，被告から提案のあった追加費用２０億円の負担について，①ＮＥＦＳＳ－Ｃｏｒｅｂａｎｋのシステムが他行に売れる度に，ＩＢＭとの共同開発の版権料として２０億円に達するまでは１行当たり５％，それ以降は２．５％を支払う，②２０億円の支払はシステム納入後の一括払とするとの条件を提示した（甲１２６，甲１２７の１，２）。
（ク）　同月１９日に開催された第２６回ステアリング・コミッティにおいては，遅延タスクについて，プロジェクトの週次進捗会議で進捗状況を管理し，早期解決を図ることとされた。なお，ステアリング・コミッティの席上，被告のＬから，ＧＡＰ開発についてＦＩＳ社と検討してきたが，まだ継続検討中である，ＧＡＰによる追加機能について，Ｃｏｒｅｂａｎｋに何を作り，外に何を作ればよいのか，詳細を検討する必要があったため時間がかかっている，これが確定した時点でスケジュールも確固たるものとなると発言した（甲６の２６）。
（ケ）　同年３月８日に開催された第２７回ステアリング・コミッティにおいては，被告側から，詳細設計の開始に向けた準備状況，先行開発に向けた作業内容等の説明がされた。その中で，Ｌは，ＦＩＳ社との役割分担について，最終的な決着がついていないと発言した（甲６の２７）。
（コ）　同月１９日，被告は，原告に対し，「「新経営システム」構築プロジェクトに関して」と題する書面を交付した。同書面には，要件定義及び現時点までの設計を進める過程でＣｏｒｅｂａｎｋパッケージとの間で多くのギャップの存在が顕在化し，その２００を超えるギャップが原告にとって不可欠のものであること，パッケージ開発元のＦＩＳ社と被告で開発の最適化を行った場合でも２年以上の開発期間を要することが判明したこと，特に融資系のギャップ解決に大きな時間と工数を要することなどの理由から，平成２０年１月から平成２２年１月までの５段階の段階的移行を内容とするサービスイン方式を提案する旨が記されていた（甲８０，甲１２２の２）。
原告は，受け入れられる内容ではないとして，この提案を拒否した（甲１２５）。
（サ）　被告が平成１９年３月２７日に作成した週次進捗報告書（甲１２９の１ないし４）には，ＦＩＳ社と被告との間でギャップ作業分担スコープ調整を行っており，ギャップスケジュールを作成中であると記載され，同じく同年４月３日作成の週次進捗報告書（甲１３０の１ないし４）には，ＦＩＳチームがギャップ開発スケジュールを見直し中であり，取引実装チームにおいては，ギャップ作業スコープは確定したが，スケジュール調整は継続中であると記載され，同じく同月１７日作成の週次進捗報告書（甲１３３の１ないし４）には，ＦＩＳチームがギャップ開発スケジュール見直し中（２２件分のみスケジュール確定）であるとの記載がされている。また，上記の各週次進捗報告書を含めて，その頃に作成された週次進捗報告書（甲１２９，１３０，１３２ないし１３４の各１ないし４）の遅延タスク一覧の遅延状況の欄には，取引実装のギャップ対応チームについて，「昨年１０月よりＷＢＳ確定を依頼してきたが，ＩＢＭ－ＦＩＳ間の調整が完了せず，現時点でも確定していない状況」と記載されている。
（シ）ａ　被告は，平成１９年４月１８日，原告に対し，検討は初期段階であり更なる精査が必要になることに留意されたいとした上で，本件プロジェクトの代替案として，Ｃｏｒｅｂａｎｋに代えて，Ｔｅｍｅｎｏｓ社の基幹系パッケージソフトであるＴＣＢを採用する案を提案した。その際に原告に示された被告作成に係る同日付け「「新経営システム」構築プロジェクトに関するご相談」と題する文書には，新ソリューションの採用により原告がメリットを享受し得る可能性について検討した項目中に次の記載がある（前記前提事実(9)シ，甲９）。
（a）　開発規模及びスケジュールの観点からリスクとなっている「融資のＧａｐ開発」において，ベンダへの依存度が低減するため，開発スケジュールの前倒しの可能性がある。
（b）　簡易言語（４ＧＬ）による開発のため，スキルの習得が容易であり，開発，保守の生産性に寄与できる可能性がある。
（c）　生成されたＣＯＢＯＬコードにより，品質の向上，生産性の向上に寄与できる可能性がある（ＦＩＳ社のＣｏｒｅｂａｎｋの場合はＡＰＩ（部品）のみ提供されるため，ＡＰＩの受け入れテスト及び取引としての実装，テストが必要）。
（d）　コストについては，現在見積もりを実施しており，追加の負担に関しては別途説明予定。
（e）　新ソリューションを採用することにより，潜在的なリスクの発生を抑制できる可能性がある。
ｂ　この時点において，Ｆ専務は，ＦＩＳ社と共にＣｏｒｅｂａｎｋを使って本件システム開発をすることは候補から落ちたものと考えていた（証人Ｆ）。
（ス）　被告のＦ専務は，同日，全体の会議でＴＣＢの採用に係る上記提案を行う前に，原告のＣ専務と打合せを行った。その際，Ｃ専務は，Ｆ専務に対し，①同日の被告の提案は，原告として従来の提案内容から大幅な変更であるとの認識であり，プロジェクトチーム内で方針決定する範囲を超えた提案と判断する，過去に被告からの提案どおり（ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋ採用，ＢＲＤの適用，スケジュール変更等）実施してきた経緯を考えても，今回は継続プロジェクトの位置付けとは考えにくい，②正式に企業と企業とで検討する内容であると判断するので，Ｋ社長名でＡ社長宛に，一週間以内に，ⅰ）現状の認識，ⅱ）現状の課題，ⅲ）今後の進め方を文章で提出されたい（若しくは提案内容を具体的に。），③ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋパッケージで３年以上進めてきたプロジェクトについて，銀行業務の基幹となる勘定系の部分を新たなパッケージで即刻進めることを何ら技術的，業務的な事前検証作業なしで進めることはできない，同じパッケージ方式での開発の誤りを銀行として二度と繰り返すことはできない，④原告として，正式な機関決定は必要であるが，本件プロジェクトをいったん白紙に戻したい，先回までの検討課題であった追加資金２０億円の話も白紙に戻してくださいなどと述べた（乙３３３）。
（セ）　同日に開催された会議において，被告作成の同日付け「「新経営システム」構築プロジェクトに関するご相談」と題する書面が提出され，原告と被告間で次のようなやりとりがされた（甲３０，１２２の３）。
ａ　被告の提案について，原告から次の意見が出された。
（a）　本日の提案は，ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋで新バンキングシステムを構築するという前提を覆す新たな提案と認識する，これまでのプロジェクトを一度ゼロにするものである。
（b）　海外のパッケージは日本のバンキングには適さず日本化することが大変という理由であるにもかかわらず，なぜ今回も海外のパッケージを提案するのか疑問である。
（c）　今回の案が適しているのならば，なぜ当初からこの案を選択しなかったのか，被告はＣｏｒｅｂａｎｋを選択したのではないのか。
ｂ　これに対し，被告は，次のとおり回答した。
（a）　新バンキングシステムとしてＮＥＦＳＳを構築するというコンセプトに変わりはない，その中心となるシステムが変更になるだけである。
（b）　ＦＩＳの解決策が見つかればこのような提案にはならない。
（c）　Ｃｏｒｅｂａｎｋと違うのは，ソースコードが公開されている点である，Ｃｏｒｅｂａｎｋはブラックボックスだったが，今回は被告がコントロールできるため，スケジュールの主導権をとれることが大きく相違している。
（d）　業務要件を実現することを考えると，Ｃｏｒｅｂａｎｋより今回のほうが優れていると考える。
ｃ　そして，被告としては，原告の意向が把握できたため，被告から再度提案を行うこととした。
イ　ＴＣＢ提案後の経緯等
（ア）　被告は，平成１９年４月２６日，原告に対し，次の内容の同日付け「貴社「新経営システム」構築プロジェクトについて」と題する書面を交付した（乙３３）。
ａ　ここ数か月間においては，プロジェクトの進展が芳しくなく，多くの未解決の重要事項（ＳＣＳへの過去作業分の支払とＳＣＳの今後の取扱い，貴社から弊社への未払金，周辺システムに関するスケジュール，提供機能及び費用等の問題）が存在している。
ｂ　被告としては，ＦＩＳ社製ソリューションは依然として有効なソリューションであると考えている。
ｃ　未解決の問題の重大性に鑑みると，Ｔｅｍｅｎｏｓ社製のコアバンキング・パッケージを含めた代替ソリューションを検討の対象として，可能性のあるオプションを両社で協議し，適切なソリューション，作業範囲，価格及び条件について，両社で検討，合意することを提案する。
ｄ　代替手段を検討するとともに，現在の本件プロジェクトにおける被告の作業を一時中断することを提案する。作業中断により，コストを削減することが可能となり，また，代替手段の検討に一層注力することが可能と考えている。
（イ）　原告は，同年５月９日，被告に対し，①原告の判断としては，同年４月１８日の被告の提案は，本件最終合意書による本件システムを現在の被告の技術力では実現できないことの意思表明と認識している，②原告は，現況が本件最終合意書による本件システムの完成の見込みはないとの理解で，本件プロジェクトをいったん白紙に戻すこととし，原告が支払済みの開発費及び原告側の要員費用など原告が負担した費用全額について速やかに返還していただきたい旨を通知した。また，本件プロジェクトについて被告がどう対処するのかを，同年５月３１日までに書面で回答するよう求めた（甲３１）。
（ウ）　被告のＦ専務は，同月１６日，原告のＣ専務に対し，現行システムの抱える課題を整理し，現勘定系システムを拡張しながら原告の経営課題の解決と市場の要求に迅速に対応するためのソリューションの検討及び本件プロジェクトに関する契約関連の課題解決の検討を９０日間で実施することを提案した。しかし，Ｃ専務は，①本件プロジェクトの契約の整理を終えて，現行システムの延命の議論に入るべきで，同時提案は受け入れ難い，②今は巻き返しを急ぐ時期と考えている，③新経営システムの構築を諦めたわけではないなどと述べて，同提案資料をＦ専務に返却した（甲３２，乙２６０）。
（エ）　被告は，同月３１日，原告に対し，上記（イ）の回答として，同日付け「貴社「新経営システム」構築プロジェクトについて」と題する文書（Ｋ社長からＡ社長に宛てた書簡）で，上記（ウ）の案を正式に提案した（甲３３）。
（オ）　原告のＣ専務と被告のＦ専務は，同年６月１日，打合せを行った。そこでは，次のようなやりとりがされた（甲２９）。
ａ　Ｆ専務が，今の原告の要望に合わせると，サービスインが平成２２年になってしまう，コストを低減するためにも代替案を検討するに至ったと述べたところ，Ｃ専務は，原告独自のものでなくて良いと何度も言ったはずである，他行に売れる邦銀の標準的なものを構築したいと言ったはずであるなどと述べた。
ｂ　Ｃ専務が，「Ｃｏｒｅｂａｎｋのことを分からず進めてきたことが誤りですよね」と質問したところ，Ｆ専務は，「全部理解はしていました。ただ，日本の銀行の諸制度に合致させることが難しかったのは事実です。現実解としてパフォーマンスの問題が出ることが分かりました。もちろん最初からは分かっていませんでした。世の中が変わったため，難しくなってしまったのです。」と答えた。
また，Ｆ専務は，「機能の中身を，貴社が求めている機能と合わせてみると，パフォーマンス上の問題が露呈したのは事実です。」と述べた。
ｃ　Ｃ専務が，開発費用とスケジュールが何とかなれば，本件システムはデリバリーできるのかと質問したところ，Ｆ専務は，「はるかに大きくなると予想されますが。」と答えた。これに対し，Ｃ専務が，それはＦＩＳ社がＣｏｒｅｂａｎｋの内容を開示しないからであるのか問うたところ，Ｆ専務は，ＣｏｒｅｂａｎｋはＦＩＳ社のプロパティであり，被告はどうこう言える立場にないと答えた。さらに，Ｃ専務が，「何でそんなパッケージを勧めたのですか。それを知らなかったのですか。」と質問したところ，Ｆ専務は，「提案した当初は銀行の業務には一番合っていると思いました。最良の検証も実施しました。結果として検証が足りなかったということです。」と答えた。
ｄ　Ｃ専務が「どちらに責任があったのでしょうか。当社が悪かったのでしょうか。」と尋ねたところ，Ｆ専務は，「このような状況に陥った責任は感じています。」と返答した。また，Ｆ専務は，勘定系はＣｏｒｅｂａｎｋでは難しいのは事実ですと述べた。
ｅ　Ｃ専務が，「コアバンクは選択ミスだったのですか。」と質問したところ，Ｆ専務は，「結果としてそうなってしまいました。システムの真ん中はそうなってしまいましたが，周辺は生かしたいと思います。」と返答した。これに対し，Ｃ専務が「それでは，途中でなぜ分からなかったのですか。ＢＲＤのとき，何で提案してくださらなかったのですか。Ｃｏｒｅｂａｎｋに問題があると言ったのはＦさんですよ。」と質したところ，Ｆ専務は，「そのとおりです。自分でチェックはできませんでした。技術側から何とかなるだろうと言われ，ＢＲＤを進めました。真実は話したとおりです。勘定系はだめでした。」と述べた。
（カ）　原告は，同月８日，被告に対し，原告と被告との間で事実関係について認識の相違があることから，被告の同年５月３１日付け文書（上記（エ））を返却し，再度本件プロジェクトにおける事実関係についての被告の見解を明記の上回答するよう求めた（甲３４）。
（キ）　被告は，同年６月２５日，原告に対し，同日付け「貴社「新経営システム」構築プロジェクトについて」と題する文書を交付した。同文書には，被告が認識する本件プロジェクトが一時中断に至った原因について，次のとおり記載されている（甲３５）。
ａ　Ｃｏｒｅｂａｎｋを有効に活用するための準備が不十分であったこと
本件プロジェクト開始時において，Ｃｏｒｅｂａｎｋの機能の充足度や開発手法の検証が不十分であった。
ｂ　プロジェクトの初期の段階で開発手法の選択を誤ったこと
パッケージをベースとする方法でなく，Ｃｏｒｅｂａｎｋ部品をベースとしたカスタム開発手法を採った。
ｃ　原告の要件に対する認識不足，また，ともに投資をし，リスクを共有するパートナーとしての意識が不足していたこと
新業務要件を明確にし，パッケージに合わせるために要件を絞ることが必要であったが，要件定義局面では現行機能のドキュメントがなく，その作成に多大なワークロードを要すとともに，当初の想定以上に現行機能が複雑であることが判明した。また，要件決定に当たっては，現行機能の踏襲に固守した部分が多く，結果，要件の絞り込みが不十分なものとなった。
ｄ　ＳＣＳを本件プロジェクトにおける被告のビジネスパートナーとして活用することができなかったこと
ＳＣＳが他のビジネスパートナーと同様にプロジェクトに参画すると想定していたが，実際には銀行としての立場で参画することが多く，十分に活用できなかった。
ｅ　開発手法についてはプロジェクト期間中に軌道修正したが，見直し後のスケジュール，費用の観点で合意に至ることができず，プロジェクトは一時中断せざるを得ない状況となった。
（ク）　原告のＣ専務と被告のＦ専務は，同日，打合せを行った。そこでは，次のようなやりとりがされた（甲３６の１）。
ａ　Ｃ専務は，同日付け書面（上記（キ））について，被告に責任があったと認識していると理解してよいのか質問したところ，Ｆ専務は，パッケージの選択の誤りといった一つの原因だけではないが，準備が不十分だったことは認識している，また本件プロジェクト当初に開発手法の選択を誤ったのは事実であると答えた。Ｃ専務が，被告に責任があると認識されているのですねと質問したところ，Ｆ専務は，上記（キ）ａないしｅの複合原因で今の状況に陥ったと認識していると答えた。
ｂ　Ｆ専務は，Ｃｏｒｅｂａｎｋの中身を邦銀標準に合わせる共同作業をＦＩＳ社に申し入れたが，ＦＩＳ社サイドから自分たちが開発するとのレスポンスがあったので，それをブラックボックスと表現したと述べた。
ｃ　Ｆ専務は，ＢＲＤを開催した理由について，原告の業務が分からない，どうやって対応するのか分からない，ＦＩＳ社が持っているＣｏｒｅｂａｎｋの機能にどうやって銀行業務を合わすのか，又はパッケージをどのように合わせていくのかを機能的に精査していかなければならないといった問題を解決するために実施したと答えた。また，ＢＲＤの中で１００を超える機能のうち，いくつかが駄目で，いくつかが大丈夫かを報告会で報告させてもらったが，その中の対応ができない事項をどうやって開発するかの交渉の中で難易度が分かってきたと述べた。
これに対し，Ｃ専務は，「そこが「貴社がＣｏｒｅｂａｎｋを分かっていない」と指摘している点なのです。今さらですが，新ＢＲＤはその程度の目的で実施されたんですか。改めて４月の段階でカスタマイズの難しさの説明をされましたが，プロジェクト開始当初から分かっていたのではないのですか。銀行業務が分からないと言っても，少なくとも日本の銀行のシステムをずっと手掛けてきている御社スタッフがＢＲＤに参加していたわけですから，新ＢＲＤで業務を理解する段階ではないのではないですか。」と返答した。
ｄ　Ｃ専務は，追加費用について，当初の作業量の見積りが間違っていたのかと質問したところ，Ｆ専務は，パッケージをベースにしなかったことに問題があった，現行機能の踏襲が必要であり，パッケージだとその機能が落ちてしまうとまずいとの議論の中から，提示の金額に行き着いてしまったと述べた。また，「見積り相違であり，運営の仕方の相違であり，また我々自身の努力不足でした。いろいろな要因があります。両社が要件がこんなに大きくなるとは予想しなかったのも一つの原因です。」とも述べた。
（ケ）　原告は，同年７月１８日，同月１７日付け内容証明郵便により，被告に対し，本件最終合意及び本件個別契約を債務不履行（履行不能）により解除する旨の意思表示を行った（前記前提事実(9)セ，甲１５の１）。
２ 　本件最終合意書に記載された原告の支払金額等の拘束力
(1)ア 　原告は，被告は，本件最終合意書において本件システム開発を８９億７０８０万円で構築する旨約したにもかかわらず，その義務を尽くさなかったので被告には債務不履行又は不法行為が成立する旨主張する。そこで，本件最終合意書１条に規定されている原告から被告に対する支払総額８９億７０８０万円の金額が，両当事者に対して法的拘束力を有しているのかどうかについて検討する。
イ 　本件最終合意書の内容は，前記前提事実(8)ア記載のとおりであるが，その中で，①本件最終合意書１条では，原告及び被告は，原告及び被告が合意する作業範囲，価格，支払条件及びその他の契約条件を規定する同条記載の個別将来契約が両当事者により締結されることを条件として，本件システムの構築を被告が８９億７０８０万円で行うことに同意した旨規定し，②同７条は，原告と被告は，構築要件，新システム基盤，プロジェクト計画などを記載した本日（本件最終合意の締結日）に至るまでの協議に基づく案を添付し，今後さらに協議をして，最終化することに合意する旨規定し，③同８条ただし書は，「ただし，各個別契約（第１条記載の個別将来契約を含むがこれらに限定されない。）が締結され，各関連個別契約の中で両当事者の各局面における義務が規定されるまでは，いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。両当事者の書面による合意がある場合を除いては，本第８条は有効とする。」と規定している。
上記のとおり，本件最終合意書１条及び８条ただし書によれば，本件最終合意書に記載された原告の支払金額の法的拘束力については，原告と被告との間で本件プロジェクトの各局面における義務を定めた個別契約が締結されることを前提条件として生ずるものとされていると解すべきである。
そして，本件最終合意書１条記載の個別将来契約のうち，ＩＢＭシステム・インテグレーション契約書（統合テストｂ局面～システムテスト局面のサービス契約）が締結されていないことは当事者間に争いがない上，証拠（甲５の８の１ないし５）及び弁論の全趣旨によれば，ＩＢＭシステム・インテグレーション契約書（基盤，制御，業務に関する外部設計局面～統合テストａ局面のサービス契約）について，業務に関する外部設計・内部設計・開発・テスト局面，並びに制御及び基盤に関する開発・テスト以降の局面に関する個別契約の大半が未締結であることが認められる。
そうすると，上記支払総額が法的拘束力を有するに至る程度に条件が充たされているとはいえないので，被告の債務不履行又は不法行為の成立をいう原告の上記主張は採用することができない。
ウ 　なお，上記８条ただし書の規定は，各個別契約の中で両当事者の義務が規定されるまでは，いずれの当事者も本件最終合意書に基づく法的義務を負わないものとしたにすぎない。後記３(2)オのとおり，上記支払総額の規定が設けられたのは両当事者が目標とする重要な指針を定める趣旨であることは疑いのないところであり，本件最終合意書が交わされた平成１７年９月３０日の時点において，被告は，本件システム開発のコスト見積りの前提となる基礎数値を確定させて原告の支払金額を決めたものであることなどからすれば，上記支払総額の規定された本件最終合意書が交わされたとの事情が，被告の信義則上ないし不法行為上の義務違反の有無を考慮するに当たり意味を有し得るものであることを否定するものではない。
(2) 　また，本件最終合意書７条によれば，開発スコープ及びサービスインの時期についても，「今後さらに協議をして，最終化する」ことが予定されていたものと解されるから，これらが本件最終合意書によって直ちに法的拘束力を生ずるに至るものであるということはできない。
(3) 　上記の点について，原告は，仮に，本件最終合意書の法的拘束力が全ての個別契約の締結という停止条件に服していると解釈されても，被告は，故意又はこれと同視すべき重過失によりこの停止条件の成就を妨害したのであるから，民法１３０条により，この停止条件は成就したものとみなされるなどと主張する。しかし，後記３で判示する本件プロジェクトが頓挫した原因について，被告の故意又はこれと同視すべき重過失があったとまではいえないから，原告の上記主張も採用できない。
３ 　本件プロジェクトが頓挫したことについての帰責事由（争点(2)）
本件プロジェクトが中止するに至ったことについて，原告は，被告はＣｏｒｅｂａｎｋに関する知識に乏しく，開発工程が混迷を極め，結局，Ｃｏｒｅｂａｎｋによる開発を断念せざるを得なくなったために，本件プロジェクトが頓挫したなどと主張するのに対し，被告は，原告が主張する本件プロジェクトの中止に至る事実経過はいずれも客観的事実に反するものであり，むしろ，被告が本件プロジェクトを成功に導くためあらゆる手を尽くしたにもかかわらず，原告が必要な協力をせず，責任を一方的に被告に押しつける態度に終始したために，本件プロジェクトは頓挫したものであるなどと主張する。
そこで，本件プロジェクトが中止するに至ったことについて，どちらにどのような責任があるのかについて検討することとする。
(1) 　まず，前記１の認定事実によれば，本件プロジェクトが頓挫するに至ったのは，平成１９年５月ないし６月であるということができる。すなわち，被告が原告に対して同年４月１８日にＴＣＢの提案をしたが，原告がこれを受け入れず，同年５月９日に本件プロジェクトをいったん白紙に戻したいと被告に通知した上，さらに，被告が原告に対して同年５月３１日付けの書簡により現状の課題の整理とその解決の検討を提案したのに対し，原告は，同年６月８日，これをも返却して，その提案を受け入れなかったのであり（前記１(3)ア（シ）ないし（セ），イ（ア）ないし（カ）），この時点においては，本件プロジェクトは頓挫したものということができる。
この点について，被告は，本件プロジェクトが頓挫したのは平成１９年１月であると主張する。しかし，前記１の認定事実によれば，この時点においては，原告及び被告共に，本件システム開発をいつまでに，どのような範囲で，また，いくらの費用で行うかについての交渉を続けていたのであり，本件プロジェクトが上記時点で頓挫したなどということはできない。
なお，被告が，本件訴訟の当初，本件プロジェクトは原告がＴＣＢによる代替案を拒絶して本件プロジェクトを白紙に戻すこととする旨を一方的に宣言したことで頓挫したと主張していたことは当裁判所に顕著である（答弁書１９頁，４２頁）。
(2) 　原告が主張する被告の責任原因の有無
原告は，被告は，システム開発業者として，自らが有する高度の専門的知識と経験に基づき，納入期限までにシステムを完成させるようにユーザに提示し，ユーザとの間で合意された開発手順や開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務や，ユーザのシステム開発への関わりについても適切に管理するなどの行為をすべき義務（これらの義務を総称したものとしてのプロジェクト・マネジメント義務）を負っていたにもかかわらず，この義務を尽くさなかったのであり，本件プロジェクトは，被告がＣｏｒｅｂａｎｋに関する知識に乏しく，開発工程が混迷を極め，結局，Ｃｏｒｅｂａｎｋによる開発を断念せざるを得なくなったために頓挫したものであるなどと主張するので，この点について検討する。
ア　Ｃｏｒｅｂａｎｋの機能や開発手法についての検証，検討等
（ア）　本件のように，ベンダとユーザとの間でパッケージ型システム開発が行われる場合，パッケージの選定は，開発の対象となるシステムの根幹を成すものであり，その適切な選定，開発方法の採用は極めて重要な課題である。システム開発の専門家であるベンダは，パッケージの選定に当たり，パッケージの機能・性能，設定・導入の容易性，導入実績，パッケージの提供者の導入実績，経営の安定性，技術力，カスタマイズへの積極性その他関連する諸事情を考慮して，ユーザが構築しようとしているシステムに最適のパッケージを選定した上，これに適した開発方法を採用しなければならず，そのために，ベンダは，ユーザへの提案前に様々な観点からパッケージの機能，開発手法，リスク等について十分に検証又は検討しなければならないものというべきである（甲７６ないし７８，甲８８ないし９０）。加えて，それまで日本の銀行の基幹系のシステム開発において海外のパッケージが用いられたことはなかったのであり（甲７６，７８），しかも，被告は，製造業や流通業でのパッケージ・ベース・アプローチの経験はあるが，銀行のシステムをこの手法で開発した経験がなかったのであるから（甲６の１８），被告としては，本件システム開発に当たって，より慎重に，パッケージの機能，開発手法，リスク等について検証又は検討し，適切な開発方法を採用しなければならないものというべきである。
（イ）　ところで，パッケージ型システム開発は，既製のプログラムを最大限そのまま利用することで新規開発量を削減し，それにより開発コストの削減と開発スケジュールの短縮を実現することを重要な目的としているから，システムベンダは，業務要件定義の段階からパッケージの機能をベースとして，ユーザが実現を望んでいる機能をパッケージの既存機能で実現する方法を検討し，既存機能では実現不可能な部分をギャップとして新規開発（カスタマイズ，アドオン）する方法を採るのが合理的である。しかし，被告が計画・要件定義＃１及び２で採用した現行踏襲型アプローチは，ユーザの現行システムの機能を基礎にしてそれに新システムで必要な機能を積み上げるという手法であり，これでは，パッケージソフトウェアであるＣｏｒｅｂａｎｋの利点を十分に享受することができず，ギャップ開発の量が不必要に増大してしまうことが避けられないというべきである（この点について，甲７７を参照）。現に，被告は，上記のとおり，Ｃｏｒｅｂａｎｋについて当初は現行踏襲型アプローチの開発手法を採用して要件定義書を作成するまでに至ったが，その開発手法に誤りがあるとして旧ＢＲＤを行ったのであり，さらに，旧ＢＲＤは十分にパッケージ・ベース・アプローチの手法に沿っていないので変更が必要であるとして，新ＢＲＤを実施するに至ったものである。上記のように開発方法について基本的なやり直しをしなければならなかったのであるから，被告は，Ｃｏｒｅｂａｎｋを利用した場合の適切な開発方法についてあらかじめ十分な検証又は検討をしていたものということはできない。
（ウ）　また，上記のとおり，被告はＣｏｒｅｂａｎｋの開発方法の点において基本的なやり直しをしなければならなかったという事情のほか，①Ｆ専務は，平成１８年８月９日開催の第２１回ステアリング・コミッティにおいて，「Ｃｏｒｅｂａｎｋがどこまでできるのか，これまでＩＢＭは分かっていなかった。ＢＲＤにより肌で感じることができた。」と述べていたこと（甲６の２１），②被告作成に係る平成１８年１２月１１日付け書面に，本件プロジェクトのコストが増大した理由の一つとして，被告による「Ｃｏｒｅｂａｎｋの成熟度の見誤り」との記載がされていること（甲７・４頁），③平成１８年になってから，ＣｏｒｅｂａｎｋをＪａｖａ化したもののパフォーマンスが悪いことが判明したこと（証人Ｌ），④被告が平成２２年１月の全面稼働というスケジュールを示した際に原告に提示した平成１９年３月１９日付け書面には，外部依存関係の評価として，「ＦＩＳ社等ベンダーの開発能力および，リスクの評価を実施したところ想定以上に課題が確認された」と記載されていること（甲８０・３頁），⑤被告は，原告に対し，平成１９年４月１８日，Ｃｏｒｅｂａｎｋによる基幹系のシステム開発に代えてＴｅｍｅｎｏｓ社のＴＣＢによる開発という代替案を提案したが，その際に，「ＦＩＳでは妥当な結果が出ない」，「ＦＩＳがブラックボックス」，「Ｊａｖａのパフォーマンスが悪い」などと説明したこと（甲９，甲３０，甲１２２の３），⑥Ｆ専務は，平成１９年６月１日に行われたＣ専務との面談において，Ｃｏｒｅｂａｎｋについて，「日本の銀行の諸制度に合致させることが難しかったのは事実です。現実解としてパフォーマンスの問題が出ることが分かりました。もちろん最初からは分かっていませんでした。」，「勘定系はＣｏｒｅｂａｎｋでは難しいのは事実です。」などと述べたこと（甲２９），⑦Ｋ社長作成の平成１９年６月２５日付け書簡には，本件プロジェクト中断の原因として，「プロジェクト開始時において，Ｃｏｒｅｂａｎｋの機能の充足度や開発手法の検証が不十分であった」，「プロジェクトの初期の段階で開発手法の選択を誤った」などと記載されており，Ｆ専務は，同日に行われたＣ専務との面談において，本件プロジェクトが中断した原因について，「パッケージの選択といった一つの原因だけではありません。ただ，準備が不十分だったことは認識しています。またプロジェクト当初に開発手法の選択を誤ったのは事実です。」と述べたこと（甲３５，甲３６の１）等の事情が認められる。
これらの事情によれば，被告が，原告との間で本件プロジェクトを開始するに当たり，基幹系のパッケージソフトウェアとしてＣｏｒｅｂａｎｋを採用する上で，その機能や充足度についてあらかじめ十分な検証又は検討をしたものということはできない。
（エ）　さらに，パッケージ型システム開発においては，パッケージにはパッケージベンダしか分からない部分があるので，システムベンダは，パッケージベンダからの支援を受けることが必要であるが（甲７７），被告は，新ＢＲＤの段階に至るまで本件プロジェクトにＦＩＳ社の社員を関与させてはいなかった。しかも，本件プロジェクトのような場合，システムベンダ自身において，ユーザの要求を理解できる業務知識と利用するパッケージの構造を熟知している者をプロジェクトに参加させることが必要であるが，被告がＣｏｒｅｂａｎｋによるシステム開発について知識や経験のある技術者等の要員を本件プロジェクトのメンバーとして配置していたことを認めるに足りる証拠はなく，かえって，これを配置していなかったとの事実が認められる（甲６の１６）。
そうすると，被告としては，本件システム開発を遂行するに当たり，Ｃｏｒｅｂａｎｋを利用した適切な開発方法を採用したということはできない。
（オ）　以上のとおり，被告は，本件システム開発を開始するに当たり，Ｃｏｒｅｂａｎｋの機能や充足度，その適切な開発方法等についてあらかじめ十分に検証又は検討したものとはいえないし，また，本件システム開発を遂行するに際し，適切な開発方法を採用したものということもできない。
イ　ＦＩＳ社の関与による開発体制の整備等
本件のように，大規模なパッケージを用いた基幹開発のプロジェクトにおいては，パッケージのカスタマイズがその中核となり，かつ，難易度の高い作業であって，カスタマイズに関する作業量，作業時間，費用が一般的にかなり大きなものとなるため，カスタマイズ作業を適切に実施できる体制が整えられているか否かがプロジェクトの成否に直結する重要なポイントであるというべきである（甲７６ないし７８，甲８８ないし９０）。したがって，上記プロジェクトを行うシステムベンダとしては，上記の体制を整えておくことが不可欠である。
前記のとおり，被告は，Ｃｏｒｅｂａｎｋの改変権を有しておらず，その改変はＦＩＳ社によって又はＦＩＳ社の承諾に基づいて行わなければならなかったのであり，また，被告は，本件システム開発において，新ＢＲＤの段階になる前はパッケージベンダであるＦＩＳ社を参画させることがなかったのである。それ以前に，被告が本件システム開発においてＣｏｒｅｂａｎｋをカスタマイズするために要する役割分担（例えば，被告がＣｏｒｅｂａｎｋを利用せずに外付けで開発するのか，又はＦＩＳ社がＣｏｒｅｂａｎｋを改変して開発するのかなど），作業量・作業時間，費用等について十分に検討したことや，ＦＩＳ社との間でこの点を協議するなどして，カスタマイズ作業を適切に実施できる体制を整えていたことを認めるに足りる証拠はない。特に，被告がＣｏｒｅｂａｎｋの改変についてＦＩＳ社の承諾が得られなかったり，同社との交渉が難航したりするような場合には，パッケージのカスタマイズが行えないことによって開発の遅延や中止を迫られることになるのであるから，被告としては，このような開発の阻害要因に対処するため，あらかじめ，ＦＩＳ社との間でカスタマイズ作業の作業分担や費用負担について合意が得られるようにするか，あるいは，合意が得られないような事態に対処する方法を準備するなどしておく必要があったものというべきである。
現に，新ＢＲＤが終了した段階において，原告と被告との間で平成１８年９月２９日にＩＢＭシステム・インテグレーション契約（甲５の８の５）が締結されたことにより，被告は，ＦＩＳ社との間でＧＡＰ開発の役割分担やスケジュールなどを協議し，その結果に基づいて設計・実装局面の作業計画を作成して，これを平成１８年１２月１日までに原告に納品することとされていたが，その期限になっても，被告とＦＩＳ社との協議は整わず，上記作業計画が原告に対して提示されることはなかった。その後，ようやく平成１９年３月２７日ころまでに，被告とＦＩＳ社との間で融資のギャップについての振り分けが完了したにすぎない。この時点に至っても，上記作業計画が原告に提示されることはなかったのである（なお，この点について，被告は，「設計・実装局面　作業計画」は，基本設計フェーズ後の本件プロジェクトの作業計画であるから，本件プロジェクトのスケジュールや開発スコープ等について，原告と被告との合意の下，方針がまとまることを前提とするものであるが，原告が被告との間で上記の方針をまとめることを拒絶したなどと主張するが，その主張に係る事実を認めるに足りる証拠はない。）。
このように，被告は，本件システム開発において，Ｃｏｒｅｂａｎｋの改変権を有しているＦＩＳ社との間で協議をするなどしてＣｏｒｅｂａｎｋのカスタマイズ作業を適切に実施できる体制を整えていたとはいえないのであり，このことが本件プロジェクトにおいて作業の遅延や費用の増大を招いたものであるということができる。そして，このことにより，被告がＣｏｒｅｂａｎｋを利用して本件システム開発を完成できるのかについて，原告が強い疑念を抱いても不自然ではない状況が作り出されたものというべきである。
ウ　被告の原告に対する説明
本件のように，パッケージの改変権を有していないシステムベンダがそのパッケージを用いて大規模なシステム開発を行う場合，パッケージベンダの対応いかんが開発上の重大な阻害要因になり得るのであるから，この点に関する事情は，システム開発を行う上での重要なリスクに関連するものとして，ユーザが契約関係に入るかどうかを決定する上で重要なものというべきである。なお，本件システム開発が，海外のパッケージソフトウェアであるＣｏｒｅｂａｎｋを利用して邦銀の基幹システムを開発する大規模なものであることからすれば，被告においては，相当に大規模なカスタマイズをする必要があるということはあらかじめ知り得るところであったものということができる。
ところが，被告は，原告に対し，本件基本合意書①を交わした平成１６年９月２９日の時点においても，また，本件最終合意書を交わした平成１７年９月３０日の時点においても，被告がＣｏｒｅｂａｎｋの改変権を有していないことが本件システム開発において作業の阻害要因になり得ること，Ｃｏｒｅｂａｎｋを改変するために必要とする役割分担，作業量・作業時間，費用等に関して被告とＦＩＳ社との間で十分な協議が整っていないことなどの事情について，これを説明してはいなかった。
上記のとおり，被告が上記の事情をあらかじめ原告に伝えていなかったことは，原告の信頼を損なうものということができる。
エ　サービスインの時期の延期
前記認定のとおり，本件システムのサービスインの時期について，本件最終合意書では平成２０年１月とすることとされていたが，原告と被告は，平成１８年１１月１３日，新ＢＲＤの結果をも踏まえて，平成２０年１月，同年５月，同年１０月及び同年１２月の４段階によるサービスインを行うことに合意した。しかし，被告は，原告に対し，平成１８年１２月６日に開催された第２４回ステアリング・コミッティにおいて同月１５日までに提示することを約していた基幹系詳細スケジュール（甲５の８の５の個別契約により原告に納品すべきもの）をその後においても提示しなかった上（甲６の２４，甲７１の１ないし１８），上記の合意から３か月も経過しない平成１９年１月３１日，ＣｏｒｅｂａｎｋについてＦＩＳ社のデリバリーが遅れる可能性が大きく，サービスインのスケジュールが現に合意している平成２０年１月から平成２１年５月になるリスクが大きいと告げた。さらに，被告は，平成１９年３月１９日，原告に対して新たな提案をし，Ｃｏｒｅｂａｎｋパッケージとの間で多くのギャップの存在が顕在化したため，ＦＩＳ社と被告で開発の最適化を行った場合でも２年以上の開発期間を要することが判明したことから，平成２０年１月から平成２２年１月までの５段階の段階的移行を内容とするサービスイン方式を提案したものである。
本件最終合意書によりされたサービスインの時期の定めが法的に確定したものではないと解されるとしても，平成１８年１１月１３日にされたサービスインの時期に関する合意は，既に要件定義もＢＲＤの作業も終了した時点でのものであり，その合意に至る経緯からしても，原告と被告との間で確定的な合意をしたものと解さざるを得ない。それにもかかわらず，被告がこのように合意したサービスインの時期すらも遵守することができず，サービスインがそこから大幅に遅れる見通し（本件最終合意書で記載されていたサービスインの時期からは２年，平成１８年１１月１３日の合意の時期からも１年以上の遅れ）となってしまうことについては，ユーザである原告にとって容易に受け入れ難いものであることは明らかである。その遅延については，たとえそれがＦＩＳ社からの納品が遅れることによるものであるとしても，被告の責めに帰すべきものということができる。
オ　本件最終合意書の作成以降における被告の対応
本件最終合意書が交わされた後における被告の原告に対する対応について触れておくことにする。
（ア）　まず，本件最終合意書において原告の支払金額が定められた経緯についてみると，本件最終合意書が交わされたのは本件基本合意書①が交わされてから約１年が経過した平成１７年９月３０日であり，その間に，原告と被告は，現行踏襲型アプローチの方法によるものではあるが，要件定義や現行分析の作業を積み重ねていたのであって，上記支払金額は，要件定義が終了することを予定して決められようとしていたものであり，少なくとも，計画・要件定義＃２の成果物である要件定義書が同年１２月末までには納入される予定であることを前提として決められたものということができる。しかも，被告は，原告に対し，平成１７年６月３０日付けの書面により，Ｃｏｒｅｂａｎｋによる効率的開発手法の確立及びそれを前提とした見積り方法の確立が未済であること，商品のＢＰＲによる開発対象基礎数値の確立と合意が未済であることなどの課題が残されていることを理由として最終合意の締結を同年６月末から同年９月末にすることを申し出たが，その後，システム開発コスト見積りの前提となる基礎数値（オンライン取引数，帳票数，リンクデータ数，バッチジョブ数）についてはほぼ確定に近づいたなどという経過報告をして，最終的に同年９月３０日に本件最終合意を締結したものであって，原告に対しては，それらの確定した基礎数値を前提として原告の支払金額を決定したものということができる。なお，被告は，原告との本件最終合意書を交わした時点においては，被告の都合で本件最終合意の締結が平成１７年５月から９月末日となってしまったことを除き，本件システム開発の進捗について特段の問題点を指摘していなかった（甲６の１２）。
その後，被告は，①平成１７年１０月５日に開催された第１２回ステアリング・コミッティにおいて，Ｃ専務が，期限は守られるのか，費用は予算内に収まるのか，日本の銀行の標準機能として持つべき機能は実現されるのかという３点につき，当初の計画どおり対応してほしいと述べたのに対し，異議を唱えなかった（甲６の１２），②同年１１月１１日に開催された第１３回ステアリング・コミッティにおいて，ＩＢＭアジア・パシフィック，ＦＩＳ社と開発手法の検討を開始したことを原告に報告した際には，原告から，プロジェクトを遅延させない，サービスインの期限を守る，本件最終合意書で約束したことを守る上で効率化を図るための提案であれば承認するとの申入れがあったのに対し，これを了承する旨返答した上，ＦＩＳ社との検討会によってプロジェクトの前提条件を変えることは考えていない旨述べ（甲６の１３），③同年１２月に被告から旧ＢＲＤの提案がされた後，平成１８年１月１１日に開催された第１４回ステアリング・コミッティにおいて原告から「１月以降の作業計画について」と題する書面について言及された際には，業務要件を削減することはしない，あくまで平成２０年１月本番稼働をうまくいかせるためにどうするかという観点で合理化案について検討させていただきたい旨を述べ（甲６の１４），④平成１８年４月１１日に開催されたプロジェクト進捗会議においても，原告が現在のＢＲＤの方向性はこれでよいのか，当初の目的としては工数削減があったと思うが，現時点での検討結果を見ると，より良いものを開発することで工数が増えていると思われる旨質問したのに対し，横展開の観点から，追加費用及び原告側工数増加は発生しないため問題はない旨答え（甲１３９），⑤同年４月に被告から新ＢＲＤの提案がされた後，平成１８年５月１０日に開催された第１８回ステアリング・コミッティにおいて，Ｃｏｒｅｂａｎｋを有効活用するためにパッケージ・ベース・アプローチで進めるということできたが，開発手法が定まらないまま進めてきてしまった，新ＢＲＤについては本件プロジェクトを正しい軌道に乗せるベストの方法と考えている，本件最終合意書については，費用，スケジュール，スコープを含めて原告の要件が記載され，扱いについても会社間で合意したものと認識している，新ＢＲＤの中で合意書に記載されたビジネス要件をパッケージ・ベース・アプローチでいかに実現するか検討を進めていきたい旨を述べ（甲６の１８），さらに，⑥同年８月３１日に開催されたＢＲＤ最終報告会において，被告作成の「エグゼクティブ・サマリー」と題する書面中「ＢＲＤ概要」のＢＲＤの主要目的(4)項に「当初想定投資の再見積りを行う」旨記載されていたことについて，原告が，後付けで目的を追加することは認められないので，削除されたい，追加する理由も本件最終合意を破棄するためのものなのかと指摘したのに対し，上記の項目は被告内部の事項であり当初設定した目的にはなかったことなので，削除する旨回答した（甲２６）。
上記のような被告の対応に接した原告は，開発手法の変更がありながらも，本件最終合意書で合意された内容が実現するものと考えていたのであり，その際に，原告側が負担すべき費用が本件最終合意書の金額よりも増額されることは考えてはいなかったものと認めることができる。そして，このような状況の中で，原告は，本件システム開発に関する費用として，被告に対し，平成１６年９月２９日付け現行契約に基づき，本件最終合意書が交わされた平成１７年９月３０日までに合計７億５９３５万８９５０円を支払い，平成１６年１２月２９日付け現行契約に基づき，平成１７年１０月３１日に１２億２４３０万円を，同年１１月３０日に１０億４５８０万円を，平成１８年６月３０日に６億８２５０万円を，同年９月２９日に６億８８００万円を，それぞれ支払い，そのほかにも，個別将来契約に基づく代金を支払ったものである。
（イ）　上記の各事情に鑑みれば，原告としては，本件最終合意が締結された時点において，被告が提案した開発手法に従ったシステム開発に問題があるとは認識していなかったし，本件最終合意書で定められた原告の支払金額には相応の根拠があると信頼していたものというべきである。また，本件最終合意書が交わされた後，被告の提案した開発手法に誤りがあるとしてこれを変更する提案がされ，旧ＢＲＤ及び新ＢＲＤが行われたとしても，その経緯の中で，被告は，原告に対し，本件最終合意書の内容は両者間の合意であり，これを実現する方向で開発を進めるなどと述べ，本件最終合意書の内容を尊重する姿勢を表明していたのであるから，原告は，少なくとも，平成１８年８月に被告からサービスインの時期の修正について提案がされるまで，平成２０年１月に一斉切替えによるサービスインを行うことが無理であるとは考えていなかったし，また，同月に被告から追加費用の負担についての申出がされるまで，原告において追加費用の負担を考慮する必要はないと考えていたのである。そして，そのような認識の下で，上記各現行契約及び個別将来契約に基づく代金を支払ったものである。
仮に，被告として，本件最終合意書を交わした後の段階において，新たにＢＲＤを実施してみなければ確実な見積りができないため，ＢＲＤの内容いかんにより本件最終合意書で記載された代金額の修正を原告に対して申し出るつもりであったのであれば，その時点でこれを原告に説明して，そのような前提の下で被告との本件プロジェクトを続けるのか否かを判断する機会を与えることもできたというべきである。それをすることなく，被告は，開発手法の変更があっても本件最終合意書の内容を尊重する旨を原告に告げて本件システム開発を続け，原告からはその間に代金の支払を受けた上，後になってＢＲＤの実施により事情が変わったなどとして原告に支払金額の増額を申し出たのであり，このような被告の対応は，原告に対し，信義に反するものであるとの不信感を抱かせるものというべきである。
（ウ）　これに対し，被告は，本件最終合意書が交わされた時点では，新システムの開発規模を工数の積み上げにより見積もることができる客観的状況にはなく，単に「概算見積り」が行われたにすぎず，原告もそれを理解していたのであるから，被告には，開発コストを正確に見極めなかったことについて，プロジェクト・マネジメント義務違反などあり得ない旨主張する。
しかし，本件最終合意書が交わされた時点においては，計画・要件定義＃２の成果物である要件定義書が出来上がる見通しが立ち，被告から原告に対して平成１７年１２月末までには納入されることが予定されていたのであり，また，被告は，Ｃｏｒｅｂａｎｋによる効率的な開発手法の確立，それを前提とした見積り方法の確立，ＢＰＲによる開発対象基礎数値の確立などの課題が解決されたものとの対応をしていたのであって，本件システム開発に係る原告の支払金額８９億７０８０万円は，そのような経過を前提として決められたものということができる。そうすると，上記支払金額については，これが両当事者を法的に拘束するまでの効力を有しないとしても，両当事者が目標とする重要な指針を定める趣旨であることは疑いを入れないものというべきであり，しかも，被告は，旧ＢＲＤ及び新ＢＲＤを行っていた際，原告に対して本件最終合意書の内容を尊重する旨を述べ，原告から現行契約に基づく代金を受領していたのであって，原告としては，これを信頼して本件プロジェクトを進めたものということができる。
被告の上記主張を直ちに採用することはできない。
カ　ＴＣＢの提案
被告は，原告に対し，平成１９年４月１８日，基幹系に用いられるものとされていたパッケージソフトウェアであるＣｏｒｅｂａｎｋに代えてＴｅｍｅｎｏｓ社のＴＣＢを採用することを提案したのであるが，その際，ＴＣＢを採用した場合に，いつの時点までにサービスインすることができるのか，また，いくらの費用を負担すれば本件システムが完成するのかについて，被告は確かな検証を済ませていなかった（甲９，甲３０）。
そもそも，Ｃｏｒｅｂａｎｋは，被告がこれについて日本化が順調に進んだとして原告に勧めたパッケージソフトウェアであり（前記前提事実(3)カ），本件基本合意書①にＮＥＦＳＳパッケージとして「コアバンク」と記載され（前記前提事実(4)），本件最終合意書においても採用する基幹システムのパッケージソフトウェアは「ＮＥＦＳＳ／Ｃｏｒｅｂａｎｋ」であると記載されていて（前記前提事実(8)），原告は，被告と共に，Ｃｏｒｅｂａｎｋを基幹システムに据えて本件システムを構築することを大前提として，本件基本合意書①を交わしてから２年半以上の間，多額の費用と多大な労力をかけて本件プロジェクトを進めてきたものである。特に，原告と被告は，法的拘束力を有する個別契約においても，Ｃｏｒｅｂａｎｋを利用することを明示的に合意し又はこれを前提として合意し（例えば，甲５の２，甲５の３の１，２，甲５の８の５など），原告がこれに基づいて代金を現に支払い又は支払うことが予定されていたのであって，少なくともＴＣＢの提案がされた平成１９年４月の時点においては，原告と被告との間において，本件プロジェクトを進めるに当たりＣｏｒｅｂａｎｋを基幹系のパッケージソフトウェアとして利用することが法的拘束力を有するものとして合意されていたと解することができる。
このような状況の下，被告がＣｏｒｅｂａｎｋによる基幹系のシステム開発を別のパッケージソフトウェアを利用して行うという代替案を提案する以上，その代替案は，完成時期や費用負担について十分な検証を行って成算がある，ないしは原告にとっても利益があるという確かな見通しが持てるようなものでなければ，原告にとって受け入れ難いものであることは明らかである。そうであるにもかかわらず，被告は完成時期や費用負担について十分な検証を済ませないままＴＣＢによることを原告に提案したのであり，そのこと自体，原告との信頼関係を失わせる根拠になるものということができる。
キ　以上によれば，被告には，本件システム開発のベンダとして適切にシステム開発を管理することなどを内容とするプロジェクト・マネジメント義務の違反があるものというべきである。そして，上記の各事情に照らして考えれば，原告が，被告からＴＣＢの提案を受けた段階で，被告に対して本件プロジェクトを白紙に戻したいと伝えて本件プロジェクトを中止する決断をしたことについては，何ら非難に値するものではないし，むしろ，相応の根拠があるものということができる。そうすると，被告のプロジェクト・マネジメント義務違反により本件プロジェクトが頓挫したものであり，被告はこの点について責任を負わなければならないというべきである。
(3) 　原告の協力義務違反の有無
被告は，原告が本件プロジェクトにおいて必要な協力をせず，責任を一方的に被告に押しつける態度に終始したために本件プロジェクトは頓挫したものであり，このことは原告の責めに帰すべきものであって，原告の協力義務違反の根拠となる事情が認められると主張する。以下，この点について検討する。
ア　現行の業務及びシステム分析の必要性を認めようとせず，資料すら満足に提供しなかったこと
被告は，原告が，要件定義の前提となる現行の業務及びシステム分析の必要性を認めようとせず，資料すら満足に提供しなかったなどと主張するが，上記の事実を認めるに足りる証拠はない。
また，被告が主張する上記の事実は，本件最終合意書が交わされる前の事情であり，このような事情が，本件システム開発の頓挫と関連するものということはできない。
被告の上記主張は失当である。
イ　商品数・帳票数の削減を行わなかったこと
まず，被告は，原告がＢＰＲにおいて商品数・帳票数の削減を行わなかった旨主張するので，この点について検討する。
証拠（甲６の６，甲６の１１，甲４５，甲４６，乙２８）及び弁論の全趣旨によれば，ＢＰＲにおいては，「新経営システムスタート時までに廃止しなければならない商品数は，融資８９８商品，預金１９商品とする」とされていたところ，原告は，ＢＰＲにより，上記のとおり廃止しなければならないとされた商品を実際に廃止することにしたこと（廃止対象商品については，乙２８の添付資料９及び１２を参照），平成１７年４月８日に開催されたステアリング・コミッティにおいて，被告のＭ事業部長は，「ＢＰＲについてはこれで終わりということではなく一つのチェックポイントとして考えている。検討着手した時点では見えないところもあり，どうかと思うところもあったが，こうやって具体的な数値（削減商品数やグループ数）を出すことができた。スルガの担当者の方には負担をかけ，ありがとうございました。」と述べていたこと，原告は，その後においても，商品を廃止していること等の事実が認められる。これによれば，原告がＢＰＲにおいて商品数・帳票数の削減を行わなかったなどということはできない。
次に，被告は，原告がＢＲＤの過程においても現行の業務に固執して帳票数の削減を拒んだなどと主張する。
しかし，後記ウのとおり，原告が帳票数の削減を拒んだ事実を認めることはできない。
ウ　開発スコープの削減等に応じなかったこと
被告は，本件基本合意書①によれば，当初から，要件定義後に開発の契約を締結するか否かを検討する機会を設けることが予定されていたこと，原告は，想定よりも開発工数がかかる見込みであることを理解していたからこそ，開発スコープやスケジュールが「先送り」となる本件最終合意書を交わしたこと，原告はシステム開発の専門家であり，開発スコープを調整せずに８９億７０８０万円で原告の夢が全て実現できるはずがないことを理解していたこと等の事情があったのに，原告は，開発スコープの削減，調整に応じなかったものであるなどと主張するので，この点について検討する。
確かに，本件最終合意書７条によれば，同条所定の１ないし９の項目に関しては，本件最終合意の締結に至るまでの協議に基づく案を添付し，今後更に協議をして，最終化することに合意する旨規定されており，このことからすれば，本件最終合意書が交わされた時点においては，これに添付された上記の案（原告の商品数としては，融資２１９グループ，預金８８グループの合計３０７グループ，帳票数としては，１６１８個（ただし，同一帳票は除く。））が確定的な合意の内容となっているものということはできない。しかし，原告としても，必要な内容を開発スコープに盛り込むことを主張するのは何ら非難に値するものではない。しかも，上記の案は，本件最終合意書が交わされた時点のものであることや，これを前提として開発委託費用９５億円が見積もられていたことからしても，意味を有しないものということはできないのであり，むしろ，その後に原告被告間でされる協議自体はこれを基準にして行われるべきものということができる。
また，実際にも，①本件最終合意書が交わされた時点での帳票数は４６１７個であったところ，その後の経過を見ると，原告は，平成１８年８月３１日までに帳票数の削減を行い，バッチ帳票が４１７１個（うち重複帳票２６３５個）となったこと（甲４４。なお，上記重複帳票については，その数を開発する個数から差し引くことができるものと考える。），②被告は，平成１８年８月９日に開催された第２１回ステアリング・コミッティにおいて，「パッケージに合わせることについては，スルガの協力に感謝する。無駄を省くことができた。」旨述べていること（甲６の２１）等の事情が認められるのであって，原告が帳票の削減や開発スコープの削減，調整に応じなかったなどということはできない。
なお，被告が主張する事情のうち，本件基本合意書①によれば，当初から，要件定義後に開発の契約を締結するか否かを検討する機会を設けることが予定されていたことについては，このことによって，上記認定及び判断が左右されるものではない。また，原告は，システム開発の専門家であり，開発スコープを調整せずに８９億７０８０万円で原告の夢が全て実現できるはずがないことを理解していたとの主張については，原告がシステム開発の専門家であるとの事実を認めるに足りる証拠はない。
エ　本件最終合意書の記載内容に固執して，一切の妥協をしなかったこと
被告は，原告が本件最終合意書に記載された８９億７０８０万円という負担額，開発スコープ及びサービスインの時期に固執し，強硬な態度に終始して，一切の妥協をしなかったなどと主張するので，この点について検討する。
（ア）　まず，８９億７０８０万円という上記支払金額については，前記３(2)オのとおり，これが両当事者を法的に拘束するまでの効力を有しないとしても，両当事者が目標とする重要な指針を定める趣旨であることは疑いを入れないものというべきであり，しかも，被告は，旧ＢＲＤ及び新ＢＲＤを行っていた際，原告に対して本件最終合意書の内容を尊重する旨を述べ，原告から現行契約に基づく代金を受領していたのである。そうすると，そのような状況の下で，原告が本件最終合意書で記載された原告の支払金額８９億７０８０万円を強く主張したとしても，特段非難に値するものではなく，このことが原告の協力義務違反の根拠となるものとはいい難い。
（イ）　また，サービスインの時期について，原告は，新ＢＲＤが終了した後の平成１８年１１月１３日，本件最終合意書で記載されていた平成２０年１月という時期を，平成２０年１月，同年５月，同年１０月及び同年１２月の４段階によるサービスインに変更することに合意しているのであり，原告が，サービスインの時期に固執したものということはできない。その後，原告は，被告から，平成１９年１月３１日にサービスインは平成２１年５月になるリスクが大きいと，平成１９年３月１９日に平成２０年１月から平成２２年１月までの５段階の段階的移行を内容とするサービスイン方式にしたいとそれぞれ告げられたことに対し，いずれもこれを拒否する回答をしているが，そこで提案されたサービスインの時期の遅延は相当に大幅なものであるし，このような提案を原告が受け入れなければならないような根拠も見当たらないのである。したがって，原告がサービスインの時期に係る被告の提案を受け入れなかったからといって，これが協力義務違反になるものということはできない。
オ　追加費用の負担や開発スコープに関する不合理な交渉経過
被告は，原告が，要件定義終了後に総開発費用の見積りが出された際，被告がＮＥＦＳＳに莫大な投資を行っていて後に引けないことを知悉して，スコープについても費用負担額についてもいったんは合意するそぶりを見せながら，これを覆し，不合理に強硬な交渉態度に終始し，被告が要請する平成１８年１２月あるいは平成１９年１月の契約締結を拒否した旨主張する。
しかしながら，原告が被告に対して不合理に強硬な交渉態度をとって平成１８年１２月ないし平成１９年１月に契約の締結を拒否した事実を認めるに足りる証拠はない。
確かに，原告のＥ副社長は，被告のＦ専務に対し，平成１８年１２月１３日，本件システム開発について原告が出せる追加費用は最大でも２０億円である旨を述べたことが認められるが，それ自体は，Ｅ副社長の見通しを述べたものにすぎないし，スコープなどその他の条件について具体的に述べたわけでもないのであり，これを原告からの提案とみることはできない。したがって，その後，被告から原告の追加費用を２０億円とすること等を含む内容の提案がされたのに対し，原告がこれを受け入れなかったとしても，これが不当な交渉態度であるということはできない。
そもそも，原告は，本件最終合意書で定められた原告の支払金額には相応の根拠があると信頼していたものであり，また，旧ＢＲＤ及び新ＢＲＤが行われた経緯の中で，被告は，原告に対し，本件最終合意書の内容は両者間の合意であり，これを実現する方向で開発を進めるなどと述べ，本件最終合意書の内容を尊重する姿勢を表明していたのであって，これによれば，原告が，平成１８年１２月に被告から追加費用の負担についての申出を受けた際，被告の対応に不信感を抱いたとしても不思議なことではなく，また，原告の支払金額の増額については，被告側から増額の根拠について十分な理由が提示されない限り，これに応ずる必要はないと考えることにも合理的な理由があるというべきである。
また，被告は，原告が，平成１９年１月１８日に開催された第２５回ステアリング・コミッティにおいて，開発スコープが調整済みであったことを否定し，合意を白紙に戻してしまった旨の主張についても，上記事実を認めるに足りる証拠はない。すなわち，上記ステアリング・コミッティにおいて，Ｃ専務は，開発スコープの調整について，「現場の作業を否定するものではない。本件はＩＢＭの経営としてどう責任を取るかという経営マターである。本資料については見直しの上，目的や理由，経緯等のコメントを付けるということでお願いする。」と述べており，これに対して，被告のＮは「了解した。」と回答しているのであって（甲６の２５），原告が，開発スコープが調整済みであった事実を否定し，合意を白紙に戻してしまったなどということはできない。
カ　以上によれば，本件システム開発について原告には協力義務違反があるという被告の主張は採用することができない。
(4) 　被告は，本件プロジェクトの頓挫原因について，開発フェーズのコストの見積りが１０５億円から２２６億円に増大したことの定量的分析をすると，原告側に原因（銀行によって内容が異なる要件及び原告独自の要件を開発するための費用の増加）のあるものが９１．９６億円（８２．８５％），被告側に原因（邦銀標準のパッケージを作るための費用の増加）があるものが１９．０４億円（１７．１５％）であり，圧倒的な割合で原告側の原因によって見積りが増加しているし，仮に，本件最終合意締結後に新たに判明した要件のみが原告側の原因によるものであるとしても，なお５６．３２％という割合であるから，本件プロジェクトの頓挫原因は原告にあるなどと主張する。
しかしながら，開発費用の増加原因を上記のように分類するのが相当であるのか疑問がある上，そもそも，本件プロジェクトの頓挫原因は上記(2)で述べたとおりの事情であると認められるのであるから，被告の上記主張は採用することができない。
(5) 　そうすると，本件システム開発が頓挫したことの責任はもっぱら被告にあるのであり，そのことについて，被告は原告に対してプロジェクト・マネジメント義務違反の責任を負うものというべきである。
４ 　損害賠償責任に関する契約条項
(1) 　本件最終合意書８条ただし書が免責条項であるとの主張について
被告は，「いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。」と規定する本件最終合意書８条ただし書は免責契約であり，被告に債務不履行又は不法行為があった場合でも，被告はそれが故意又は重過失に基づくものであるとき以外は責任を負うことはない旨主張する。
そこで，「いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。」との文言がいかなる意味を有するのかについて検討する。同文言が法的義務を負わないとするのは，本件最終合意書に基づく法的義務のことであり，それも，「各個別契約が締結され，各関連個別契約の中で両当事者の各局面における義務が規定されるまで」は，法的義務を負わないものとするものであって，上記の規定が，例えば不法行為に基づく責任のように，本件最終合意書に基づいて発生するものではない法的義務について，一般的に両当事者の責任を限定したり，免除したりする内容のものとみることはできない。
そうすると，被告の上記主張を採用することはできない。
(2) 　本件最終合意書４条の解釈
次に，本件最終合意書４条の規定をどのように解釈すべきであるのかについて検討する。
個別契約が既に締結されている場合，これに関する当事者間の紛争について，個別契約の契約書の条項が法的な効力を有するものというべきであるが，他方，８条ただし書が「各個別契約（第１条記載の個別将来契約を含むがこれらに限定されない。）が締結され，各関連個別契約の中で両当事者の各局面における義務が規定されるまでは，いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。」と規定していることからすれば，個別契約が既に締結されて両当事者の各局面における義務が規定された以上，個別契約に規定されていない事柄については，本件最終合意書の規定が既に締結された個別契約に関わる限度において効力を有するものと解するのが相当である。
そうすると，本件最終合意書４条の規定については，個別将来契約が締結されてこれにより各当事者の義務が規定された以上，本件最終合意書４条の規定が法的効力を有するものと解するのが相当である。
なお，原告と被告との間で平成１６年９月２９日に締結されたＩＢＭ支援サービス契約書（甲５の２）６条１項によれば，「お客様がＩＢＭの責に帰すべき事由に基づいて救済を求めるすべての場合において，ＩＢＭの損害賠償責任は，請求の原因を問わずお客様に現実に発生した通常かつ直接の損害に対する，損害発生の直接原因となった当該「サービス」の料金相当額（月額料金の場合は，１２か月分に相当する金額，年額料金の場合は１年分に相当する金額）を限度とする金銭賠償に限られます。」と規定されている。また，原告と被告との間で同日に締結されたＩＢＭシステム・インテグレーション契約書（甲５の２）１４条本文によれば，「お客様がＩＢＭの責に帰すべき事由に基づいて救済を求めるすべての場合において，ＩＢＭの損害賠償責任には請求の原因を問わず現実に発生した通常かつ直接の損害に対してのみ，損害発生の直接原因となった当該別紙所定の作業に対する受領済みの代金相当額を限度（ただし，別紙に損害賠償限度額の記載がある場合にはこれによる。）とする金銭賠償に限られます。」と規定されている。これらの現行契約にかかわる損害賠償責任については，損害賠償額の限度を定める上記の条項が適用されるものと解される（本件最終合意書４条は，個別将来契約について規定したものと考えられる。）。
５ 　原告の損害
(1) 　実損害①について
ア　証拠（甲５の２，５の３の１，５の５ないし７，５の８の１ないし５，５の９，５の１０の１，５の１０の２，５の１１，甲１０，甲１１の１ないし１４）及び弁論の全趣旨によれば，原告は，被告に対し，システム・インテグレーションに関する個別契約に基づき，合計４９億１３１０万４８３０円を支払ったことが認められる。
イ　証拠（甲５の４の１，甲１１の１５ないし１１７，甲１５６，甲１５７，甲１５８の１ないし６９）及び弁論の全趣旨によれば，原告は，被告に対し，ＯＩＯ契約に基づき，合計３７億３１６２万８４８４円（ただし，甲１１の１５ないし１１７の合計２１億８４５１万４１２０円と甲１５８の１ないし６９の合計１５億４７１１万４３６４円を合わせた金額）を支払ったこと，このうち，原告が現に使用している資産に関するリース料等の額が２０億１２６０万２６４１円であることが認められる。そして，上記３７億３１６２万８４８４円から２０億１２６０万２６４１円を控除すると１７億１９０２万５８４３円となる。
ウ　弁論の全趣旨によれば，上記ア及びイの合計６６億３２６８万５８４７円のうち，「アセットアロケーション／最適商品選定システム」及び「ライフプランニングシステム」については，原告が行っている別件プロジェクトで利用可能であり，これらの対価相当額は７９２７万５０００円であることが認められる。
そして，上記アの支払額４９億１３１０万４８３０円，上記イの支払額の一部１７億１９０２万５８４３円の合計額である６６億３２１３万０６７３円から上記ウの対価相当額７９２７万５０００円を差し引くと，６５億５２８５万５６７３円となる。そうすると，本件システムを構築するための費用として原告が被告に対して支払った金員のうち，６５億５２８５万５６７３円が原告の損害となる。
(2) 　実損害②について
証拠（甲１２，甲１３の１ないし３３，甲１６１，甲１６２の１の１ないし４３の２，甲１６３，甲１６４）及び弁論の全趣旨によれば，原告は，本件システムで使用するソフトウェアやハードウェアの調達，設備の改造等を行うに際し，被告以外の者に対して１５億９８４７万７０５５円を支払ったこと，このうち，原告が現に使用している物の金額は７億３７６６万６６００円であることが認められる。そうすると，原告が上記のとおり被告以外の者に対して支払った金員については，上記支払額１５億９８４７万７０５５円から７億３７６６万６６００円を差し引いた８億６０８１万０４５５円が原告の損害となる。
(3) 　逸失利益について
原告は，逸失利益として４１億６６００万円の損害を受けた旨主張するが，原告が本件システム開発をその主張するとおりに完成させることができたかどうか，また，これによって原告が主張するような利益を上げることができたかどうかについては，なお不確定の要素が含まれているのであり，本件システム開発により利益を上げられた事実を認めるに足りる証拠はない。
(4) 　以上によれば，上記システム・インテグレーションに関する個別契約及びＯＩＯ契約に基づく支払，本件システムで使用するソフトウェアやハードウェアの調達，設備の改造等のための支払は，いずれも本件システム開発の一環としてされたものであるから，本件システム開発が被告のプロジェクト・マネジメント義務違反により頓挫してしまい，原告による上記支払が意味のないものとなってしまった以上，原告の損害を構成するものというべきである。そうすると，原告は，被告のプロジェクト・マネジメント義務違反により，実損害として，合計７４億１３６６万６１２８円（上記(1)の６５億５２８５万５６７３円と上記(2)の８億６０８１万０４５５円との合計額）の損害を受けたものというべきである。
６ 　損益相殺
(1) 　被告は，①再利用可能な成果物の客観的価値相当分（要件定義書，システム設計書，他社製パッケージソフトウェア）４２億３９２１万６２０１円，②プロジェクト頓挫により原告が債務を免れる結果となる本件未払個別契約①及び②に基づく未払金１３億６９６０万１４９３円，③プロジェクト頓挫により原告が債務を免れる結果となる暫定的合意書（ＬＯＩ）に基づく債務２億３１００万円について，損益相殺として原告の損害から控除されるべきである旨主張するので，この点について検討する。
(2) 　再利用可能な成果物の客観的価値相当分４２億３９２１万６２０１円
被告は，被告が本件個別契約に基づき原告に納入した成果物の大部分は本件プロジェクトが頓挫したとしても，被告以外のベンダとの開発において利用が可能であり，上記成果物の客観的な価値相当分は原告の損害を構成しない旨主張する。
まず，被告が原告に納入した要件定義書についてであるが，上記成果物が客観的な価値を有することを認めるに足りる証拠はない。かえって，証拠（甲１６５，甲１７０，甲１７２，甲１７３，証人Ｏ）及び弁論の全趣旨によれば，原告が被告以外のベンダとの間で現にシステム開発を行っている別件プロジェクトではソフトウェアとしてＣｏｒｅｂａｎｋが用いられていないこと，ベンダとパッケージソフトウェアが異なれば要件定義のやり方が異なってくるし，要件定義書の内容も異なってくるのであって，被告が原告に納入した要件定義書を別件プロジェクトに利用することは困難であること，上記要件定義書は，平成１８年当時の内容しか反映していないものであり，内容的に古くなっていること，他のベンダは，上記要件定義書の内容について，被告から引き継ぎを受けることも，被告に問い合わせをすることもできないのであり，これを別件プロジェクトに転用するには多大な作業と費用を要すること等の事情が認められるのであって，これによれば，上記要件定義書は客観的な価値を有するとはいえないものというべきである。そして，上記の結論は，乙３８２号証，乙３８４号証，証人Ｐの証言等によっても左右されることはない。
次に，被告から原告に納入されたシステム設計書についてであるが，本件プロジェクトで採用の予定されていたパッケージ又は製品が，原告が行っている別件プロジェクトにおいて客観的に利用され得るものであるとの事実を認めるに足りる証拠はない。そうすると，上記システム設計書が客観的な価値を有するものということはできない。
さらに，他社製パッケージソフトウェアについてであるが，本件全証拠によっても，原告が別件プロジェクトで利用可能であると自認するアセットアロケーションシステム等を除き，ＳＡＰパッケージ及びＣＲＭパッケージを含めて原告において別件プロジェクト等で利用し得るものがあるとの事実を認めることはできない。
以上のとおり，被告が本件個別契約に基づき原告に納入した成果物の大部分には客観的利用価値があるとする被告の主張は，採用することができない。
(3) 　本件未払個別契約①及び同②に基づく未払金１３億６９６０万１４９３円
証拠（甲１５の１）及び弁論の全趣旨によれば，原告は平成１９年７月１８日に被告の債務不履行を理由として本件最終合意及び本件個別契約（本件未払個別契約①及び同②を含む。）を解除する旨の意思表示をした事実が認められるところ，本件システム開発について被告のプロジェクト・マネジメント義務違反が認められる以上，本件未払個別契約①及び同②に基づいて，原告が被告に対して契約代金を支払うべき義務はないものというべきである。そうすると，被告は，本件未払個別契約①及び同②に基づく未払金の請求権を有しないのであるから，上記未払金相当額を損益相殺として原告の損害から控除すべきであるとする被告の主張は理由がない。
(4) 　ＬＯＩに基づく債務２億３１００万
上記のとおり，原告が被告の債務不履行を理由として本件最終合意及び本件個別契約（本件未払個別契約①及び同②を含む。）を解除する旨の意思表示をした事実が認められ，また，本件システム開発について被告のプロジェクト・マネジメント義務違反が認められる以上，原告はＬＯＩに基づく債務を負わないものというべきである。そうすると，被告は，ＬＯＩに基づく代金の請求権を有しないのであるから，この代金相当額を損益相殺として原告の損害から控除すべきであるとする被告の主張は理由がない。
７ 　本訴請求に係るその余の争点について
(1) 　争点(3)（本件個別契約の債務不履行解除の成否）及び争点(4)（説明義務違反の有無）について
仮に，被告に本件個別契約の債務不履行があり，原告に債務不履行解除が認められた，又は被告に説明義務違反があったとしても，前記３で判示した被告のプロジェクト・マネジメント義務違反に基づき，前記５で算定した原告の損害額を上回るとはいえないので，争点(3)及び(4)については判断しない。
ただし，本件個別契約の債務不履行解除の成否については，後記８において，争点(7)（反訴請求の可否）の判断に必要な範囲で触れることとする。
(2) 　争点(5)（錯誤の有無）について
原告は，本件個別契約の全てはＣｏｒｅｂａｎｋを大前提にして締結されたものであるから，実際にＣｏｒｅｂａｎｋの採用が不可能であったということは契約の重要な要素について錯誤があると主張して，錯誤無効に基づく原状回復請求として，被告に対して６５億５３４１万０８４７円の支払を求めているが，この請求額が上記５で算定した原告の損害額を上回るものではないので，上記主張に係る争点(5)についても当審の判断を示すことはしない。
(3) 　被告による相殺の主張について
なお，前記のとおり，被告のプロジェクト・マネジメント義務違反に基づくものとして当裁判所が認める原告の本訴請求債権は，不法行為に基づく損害賠償請求であるので，被告が主張する相殺の受働債権には当たらない。
８ 　争点(7)（反訴請求の可否）について
(1) 　本件未払個別契約に基づく請求（反訴請求の趣旨１項に係るもの）について
ア　原告と被告が本件未払個別契約①及び同②を順次締結したこと，被告が，本件未払個別契約①所定の成果物を平成１８年３月３１日に原告に対して納品し，原告による受領，受入検査を完了したこと，被告が，本件未払個別契約②所定の成果物のうち，「設計・実装局面　作業計画」を除く「基幹系・取引機能マトリックス」等を同年１２月２６日までに原告に対して納品し，原告による受領，受入検査を完了したことは当事者間に争いがない。
イ　しかし，前記３(2)のとおり，本件システム開発について被告のプロジェクト・マネジメント義務違反が認められ，前記前提事実（第２の２(9)セ）のとおり，原告が平成１９年７月１８日に本件最終合意及び本件個別契約（本件未払個別契約①及び同②を含む。）を解除する旨の意思表示をした以上，本件未払個別契約①及び同②に基づいて，原告が被告に対して契約代金を支払うべき義務はなく，被告は，原告に対し，本件未払個別契約①及び同②に基づく未払金の請求権を有しないものというべきである。
したがって，本件未払個別契約①及び同②に基づく被告の反訴請求は理由がない。
(2) 　協力義務違反等の不法行為に基づく損害賠償請求（反訴請求の趣旨２項に係るもの）について
原告には，本件システム開発について協力義務違反があるとはいえないこと，被告との間で不誠実な交渉をしたということもできないことについては，前記３(3)のとおりである。その他，原告が被告に対して不法行為をしたことの根拠となる事実を認めるに足りる証拠はない。
したがって，被告の上記損害賠償請求も理由がない。
(3) 　ＥＳＯ契約対象ソフトウェアの使用料金に係る請求（反訴請求の趣旨３項に係るもの）について
ア　原告と被告がＯＩＯ契約及びＥＳＯ契約を締結したこと，原告のＥＳＯ契約対象ソフトウェアの使用料金実績金額は，平成２０年度において１７８３万４０００円（消費税抜き），平成２１年度において９６４９万０４００円（消費税抜き）の範囲で，いずれも使用料金上限値を超過したこと，被告は，原告に対し，平成２２年２月２６日，上記使用料金超過額に消費税を付加した次の金額（平成２０年度について１８７２万５７００円，平成２１年度について１億０１３１万４９２０円。いずれも消費税抜き）を請求したことは当事者間に争いがない。
イ　これに対し，原告は，ＥＳＯ契約対象ソフトウェアの中には実際には全く使用されていない新経営システム用のソフトウェアが含まれていて，これについての使用料金も実績金額に含まれていたのに，被告がこれをＥＳＯ契約の対象から外すことを拒否していたのであり，これがＥＳＯ契約の対象から外されていれば，平成２０年度については，使用実績値が「使用料金上限値」を超えることはなく，支払う必要のない４４３０万０８６５円を支払ってしまったし，平成２１年度については，使用実績値が「使用料金上限値」を超えた金額は３８１４万１７７５円にすぎなかったものであるとして，上記４４３０万０８６５円の不当利得返還請求権を自働債権とし上記３８１４万１７７５円を受働債権として対当額において相殺する旨主張している。
そこで，検討するに，前記のとおり，本件プロジェクトが頓挫したのは被告のプロジェクト・マネジメント義務違反によるものであるというべきところ，証拠（甲１７５，甲１７６，乙３７２，乙３７３の１，２，乙３７４）及び弁論の全趣旨によれば，ＥＳＯ契約対象ソフトウェアの中には，本件プロジェクトが頓挫したために実際には全く使用されていない新経営システム用のソフトウェアが含まれていること，平成１９年１０月以降，これについて，原告が被告に対して交渉したにもかかわらず，被告はこれをＥＳＯ契約の対象から外すことを拒否したこと，平成２０年度及び平成２１年度において，これについての使用料金を原告は被告に対して支払ったこと，これがＥＳＯ契約の対象から外されていれば，平成２０年度については，使用実績値が「使用料金上限値」を超えることはなく，かえって，原告は，支払う必要のない４４３０万０８６５円を支払ったこと，平成２１年度については，使用実績値が「使用料金上限値」を超えた金額は３８１４万１７７５円にすぎなかったこと等の事実が認められる。
そうすると，上記４４３０万０８６５円の不当利得返還請求権を自働債権とし，上記３８１４万１７７５円を受働債権として対当額において相殺する旨の原告の抗弁には理由がある。
ウ　以上によれば，ＥＳＯ契約対象ソフトウェアの使用料金に係る被告の反訴請求も理由がない。
第４ 　結論
以上によれば，原告の本訴請求は，原告が被告に対し不法行為に基づく損害賠償として７４億１３６６万６１２８円及びこれに対する不法行為の後である平成１９年７月１８日から支払済みまで民法所定の年５分の割合による遅延損害金の支払を求める限度で理由があり，その余は理由がないというべきである。また，被告の反訴請求は，その余の点を判断するまでもなく，いずれも理由がない。よって，原告の本訴請求を上記の限度で認容し，その余の本訴請求を棄却することとし，被告の反訴請求をいずれも棄却することとして，主文のとおり判決する。
（裁判長裁判官　髙橋譲　裁判官　榮岳夫　裁判官　山下浩之）

*******