【営業代行から学ぶ判例】crps 裁判例 lgbt 裁判例 nda 裁判例 nhk 裁判例 nhk 受信料 裁判例 pl法 裁判例 pta 裁判例 ptsd 裁判例 アメリカ 裁判例 検索 オーバーローン 財産分与 裁判例 クレーマー 裁判例 クレプトマニア 裁判例 サブリース 裁判例 ストーカー 裁判例 セクシャルハラスメント 裁判例 せクハラ 裁判例 タイムカード 裁判例 タイムスタンプ 裁判例 ドライブレコーダー 裁判例 ノンオペレーションチャージ 裁判例 ハーグ条約 裁判例 バイトテロ 裁判例 パタハラ 裁判例 パブリシティ権 裁判例 ハラスメント 裁判例 パワーハラスメント 裁判例 パワハラ 裁判例 ファクタリング 裁判例 プライバシー 裁判例 プライバシーの侵害 裁判例 プライバシー権 裁判例 ブラックバイト 裁判例 ベネッセ 裁判例 ベルシステム24 裁判例 マタニティハラスメント 裁判例 マタハラ 裁判例 マンション 騒音 裁判例 メンタルヘルス 裁判例 モラハラ 裁判例 モラルハラスメント 裁判例 リストラ 裁判例 リツイート 名誉毀損 裁判例 リフォーム 裁判例 遺言 解釈 裁判例 遺言 裁判例 遺言書 裁判例 遺言能力 裁判例 引き抜き 裁判例 営業秘密 裁判例 応召義務 裁判例 応用美術 裁判例 横浜地裁 裁判例 過失割合 裁判例 過労死 裁判例 介護事故 裁判例 会社法 裁判例 解雇 裁判例 外国人労働者 裁判例 学校 裁判例 学校教育法施行規則第48条 裁判例 学校事故 裁判例 環境権 裁判例 管理監督者 裁判例 器物損壊 裁判例 基本的人権 裁判例 寄与分 裁判例 偽装請負 裁判例 逆パワハラ 裁判例 休業損害 裁判例 休憩時間 裁判例 競業避止義務 裁判例 教育を受ける権利 裁判例 脅迫 裁判例 業務上横領 裁判例 近隣トラブル 裁判例 契約締結上の過失 裁判例 原状回復 裁判例 固定残業代 裁判例 雇い止め 裁判例 雇止め 裁判例 交通事故 過失割合 裁判例 交通事故 裁判例 交通事故 裁判例 検索 公共の福祉 裁判例 公序良俗違反 裁判例 公図 裁判例 厚生労働省 パワハラ 裁判例 行政訴訟 裁判例 行政法 裁判例 降格 裁判例 合併 裁判例 婚約破棄 裁判例 裁判員制度 裁判例 裁判所 知的財産 裁判例 裁判例 データ 裁判例 データベース 裁判例 データベース 無料 裁判例 とは 裁判例 とは 判例 裁判例 ニュース 裁判例 レポート 裁判例 安全配慮義務 裁判例 意味 裁判例 引用 裁判例 引用の仕方 裁判例 引用方法 裁判例 英語 裁判例 英語で 裁判例 英訳 裁判例 閲覧 裁判例 学説にみる交通事故物的損害 2-1 全損編 裁判例 共有物分割 裁判例 刑事事件 裁判例 刑法 裁判例 憲法 裁判例 検査 裁判例 検索 裁判例 検索方法 裁判例 公開 裁判例 公知の事実 裁判例 広島 裁判例 国際私法 裁判例 最高裁 裁判例 最高裁判所 裁判例 最新 裁判例 裁判所 裁判例 雑誌 裁判例 事件番号 裁判例 射程 裁判例 書き方 裁判例 書籍 裁判例 商標 裁判例 消費税 裁判例 証拠説明書 裁判例 証拠提出 裁判例 情報 裁判例 全文 裁判例 速報 裁判例 探し方 裁判例 知財 裁判例 調べ方 裁判例 調査 裁判例 定義 裁判例 東京地裁 裁判例 同一労働同一賃金 裁判例 特許 裁判例 読み方 裁判例 入手方法 裁判例 判決 違い 裁判例 判決文 裁判例 判例 裁判例 判例 違い 裁判例 百選 裁判例 表記 裁判例 別紙 裁判例 本 裁判例 面白い 裁判例 労働 裁判例・学説にみる交通事故物的損害 2-1 全損編 裁判例・審判例からみた 特別受益・寄与分 裁判例からみる消費税法 裁判例とは 裁量労働制 裁判例 財産分与 裁判例 産業医 裁判例 残業代未払い 裁判例 試用期間 解雇 裁判例 持ち帰り残業 裁判例 自己決定権 裁判例 自転車事故 裁判例 自由権 裁判例 手待ち時間 裁判例 受動喫煙 裁判例 重過失 裁判例 商法512条 裁判例 証拠説明書 記載例 裁判例 証拠説明書 裁判例 引用 情報公開 裁判例 職員会議 裁判例 振り込め詐欺 裁判例 身元保証 裁判例 人権侵害 裁判例 人種差別撤廃条約 裁判例 整理解雇 裁判例 生活保護 裁判例 生存権 裁判例 生命保険 裁判例 盛岡地裁 裁判例 製造物責任 裁判例 製造物責任法 裁判例 請負 裁判例 税務大学校 裁判例 接見交通権 裁判例 先使用権 裁判例 租税 裁判例 租税法 裁判例 相続 裁判例 相続税 裁判例 相続放棄 裁判例 騒音 裁判例 尊厳死 裁判例 損害賠償請求 裁判例 体罰 裁判例 退職勧奨 違法 裁判例 退職勧奨 裁判例 退職強要 裁判例 退職金 裁判例 大阪高裁 裁判例 大阪地裁 裁判例 大阪地方裁判所 裁判例 大麻 裁判例 第一法規 裁判例 男女差別 裁判例 男女差别 裁判例 知財高裁 裁判例 知的財産 裁判例 知的財産権 裁判例 中絶 慰謝料 裁判例 著作権 裁判例 長時間労働 裁判例 追突 裁判例 通勤災害 裁判例 通信の秘密 裁判例 貞操権 慰謝料 裁判例 転勤 裁判例 転籍 裁判例 電子契約 裁判例 電子署名 裁判例 同性婚 裁判例 独占禁止法 裁判例 内縁 裁判例 内定取り消し 裁判例 内定取消 裁判例 内部統制システム 裁判例 二次創作 裁判例 日本郵便 裁判例 熱中症 裁判例 能力不足 解雇 裁判例 脳死 裁判例 脳脊髄液減少症 裁判例 派遣 裁判例 判決 裁判例 違い 判決 判例 裁判例 判例 と 裁判例 判例 裁判例 とは 判例 裁判例 違い 秘密保持契約 裁判例 秘密録音 裁判例 非接触事故 裁判例 美容整形 裁判例 表現の自由 裁判例 表明保証 裁判例 評価損 裁判例 不正競争防止法 営業秘密 裁判例 不正競争防止法 裁判例 不貞 慰謝料 裁判例 不貞行為 慰謝料 裁判例 不貞行為 裁判例 不当解雇 裁判例 不動産 裁判例 浮気 慰謝料 裁判例 副業 裁判例 副業禁止 裁判例 分掌変更 裁判例 文書提出命令 裁判例 平和的生存権 裁判例 別居期間 裁判例 変形労働時間制 裁判例 弁護士会照会 裁判例 法の下の平等 裁判例 法人格否認の法理 裁判例 法務省 裁判例 忘れられる権利 裁判例 枕営業 裁判例 未払い残業代 裁判例 民事事件 裁判例 民事信託 裁判例 民事訴訟 裁判例 民泊 裁判例 民法 裁判例 無期転換 裁判例 無断欠勤 解雇 裁判例 名ばかり管理職 裁判例 名義株 裁判例 名古屋高裁 裁判例 名誉棄損 裁判例 名誉毀損 裁判例 免責不許可 裁判例 面会交流 裁判例 約款 裁判例 有給休暇 裁判例 有責配偶者 裁判例 予防接種 裁判例 離婚 裁判例 立ち退き料 裁判例 立退料 裁判例 類推解釈 裁判例 類推解釈の禁止 裁判例 礼金 裁判例 労災 裁判例 労災事故 裁判例 労働基準法 裁判例 労働基準法違反 裁判例 労働契約法20条 裁判例 労働裁判 裁判例 労働時間 裁判例 労働者性 裁判例 労働法 裁判例 和解 裁判例

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

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

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

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

裁判経過
上告審 平成27年 7月 8日 最高裁第二小法廷 決定 平26(オ)200号・平26(受)260号 損害賠償・請負代金等反訴請求事件 〔IBM 対 スルガ銀行事件・上告審〕
上告審 平成27年 7月 8日 最高裁第二小法廷 決定 平26(オ)201号・平26(受)261号 損害賠償・請負代金等反訴請求事件 〔IBM 対 スルガ銀行事件・上告審〕
控訴審 平成25年 9月26日 東京高裁 判決 平24(ネ)3612号 損害賠償・請負代金等反訴請求控訴事件 〔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頁

参照条文
民法415条
民法505条1項
民法632条
民法703条
民法709条

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

平成20年(ワ)第5320号損害賠償請求本訴事件
平成20年(ワ)第24303号請負代金等請求反訴事件

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

 

 

主文

1  本訴被告(反訴原告)は,本訴原告(反訴被告)に対し,74億1366万6128円及びこれに対する平成19年7月18日から支払済みまで年5分の割合による金員を支払え。
2  本訴原告(反訴被告)のその余の本訴請求を棄却する。
3  本訴被告(反訴原告)の反訴請求をいずれも棄却する。
4  訴訟費用は,本訴反訴を通じ,これを6分し,その1を本訴原告(反訴被告)の負担とし,その余は本訴被告(反訴原告)の負担とする。
5  この判決は,第1項に限り,仮に執行することができる。

 

事実及び理由

第1  請求
1  本訴
本訴被告(反訴原告)は,本訴原告(反訴被告)に対し,115億8000万円及びこれに対する平成19年7月18日から支払済みまで年6分の割合による金員を支払え。
2  反訴
(1)  反訴被告(本訴原告)は,反訴原告(本訴被告)に対し,13億7484万1650円及びうち2億5515万円に対する平成18年8月31日から,うち11億1969万1650円に対する平成19年4月7日から各支払済みまで年6分の割合による金員を支払え。
(2)  反訴被告(本訴原告)は,反訴原告(本訴被告)に対し,110億5710万2553円及びこれに対する平成19年11月30日から支払済みまで年5分の割合による金員を支払え。
(3)  反訴被告(本訴原告)は,反訴原告(本訴被告)に対し,1億2004万0620円及びこれに対する平成22年2月26日から支払済みまで年6分の割合による金員を支払え。
第2  事案の概要
1(1)  本訴は,本訴原告(反訴被告。以下「原告」という。)と本訴被告(反訴原告。以下「被告」という。)との間で,原告の銀行業務全般をつかさどる次期情報システムである「新経営システム」の構築に関する基本合意(以下,上記システムの開発を「本件システム開発」といい,これに係る原告被告間のプロジェクトを「本件プロジェクト」という。)を締結するとともに,本件システム開発での個々の局面の権利,義務を規定した個別の契約(以下「本件個別契約」という。)を締結したが,結果として本件プロジェクトが中止するに至ったことにつき,原告が,①被告は,上記基本合意や本件個別契約に基づく本質的義務に従って履行すべき義務があったにもかかわらず,債務の本旨に従った履行をしなかった,②本件プロジェクトが中止するに至ったのは,被告にプロジェクト・マネジメント義務違反があったことによるものである,③被告には本件プロジェクトに関して説明義務違反があったなどと主張し,被告に対し,請負契約の債務不履行又は不法行為に基づく損害賠償を求め,あるいは,④本件プロジェクトに関して原告には要素の錯誤があったので,本件個別契約はいずれも錯誤により無効であると主張し,不当利得に基づく原状回復を求める事案である。
(2)  反訴は,被告が,原告に対し,①本件システム開発の過程において被告と原告との間で締結された本件個別契約に定められた代金の一部が未払となっていると主張して,同契約に基づく残代金の支払を,②本件プロジェクトが中止するに至ったのは原告の協力義務違反が原因であると主張して,不法行為に基づく損害賠償をそれぞれ求めるとともに,③本件プロジェクトにおいて導入されたソフトウェアのうち被告と原告との間で締結されたエンタープライズ・スペシャル・オファリング契約が適用されるものの使用について,同契約に基づき,使用料金の支払を求める事案である。
2  前提事実(証拠を掲記しない事実は,当事者間に争いがなく,その他の事実は,各項に掲記した証拠及び弁論の全趣旨により認められる。)
(1)  当事者
ア 原告は,預金又は定期積金の受入れ,資金の貸付け又は手形割引及び為替取引その他銀行法,担保付社債信託法,社債等登録法その他の法律により銀行が営むことができる業務を目的とする株式会社である。
イ 被告は,コンピュータ・システムの開発,運用,管理,搬入及び保守サービスを業とする株式会社であり,汎用コンピュータ・システム,サーバー等のハードウェア及びこれに付随するシステム・ソフトウェア等の販売等も行っている。
(2)  本件プロジェクトに関する前提知識
ア NEFSS/Corebank
本件プロジェクトは,「次世代金融サービス・システム(Next Evolution in Financial Services Systems。以下,単に「NEFSS」ということもある。)」を利用して,原告の銀行業務全般をつかさどる次期情報システムたる「新経営システム」(本件システム)を構築するものである。
Corebankは,本件システムのうち基幹系システムにおいて用いられたFidelity Information Services社(米国)(以下「FIS社」という。)のアプリケーション・パッケージである。
イ システム開発の一般的作業工程
(ア) 事業・業務要件定義
事業・業務要件定義では,経営の方針や事業部門からの業務上のニーズあるいはシステムの課題など事業及び業務上の要求(課題)を分析し,実現すべきビジネスモデルを検討・決定し,それに合わせてシステム化の方向性を決定する。
(イ) 要件定義
要件定義とは,システムの設計・開発行為に入る前にシステム化のための要件を全て洗い出し,確定する工程である。具体的には,開発するシステムの満たすべき要件を決定し,システムの目的,機能(業務内容),費用対効果,開発スケジュールなどをまとめる。
(ウ) 外部設計工程
外部設計では,システムのユーザや周辺システムから見える部分の設計を行う。具体的には,画面設計,帳票設計,周辺システムとのインターフェース,論理的なデータベースなどをまとめる。
(エ) 内部設計工程
内部設計では,システムの内部構造や仕組を設計する。具体的には,プログラムの詳細な機能や物理的なデータベースの仕様の詳細などをまとめる。
(オ) プログラミング工程(実装工程)
プログラミング工程では,内部設計工程で機能が確定されたプログラムの設計を行い,実際にコード化し,プログラムを作成する。完成したプログラムの単体テストも行う。
(カ) 結合テスト
結合テスト工程では,サブシステムのプログラムを結合してテストを行う。
(キ) システムテスト
システムテストでは,主にサブシステム間のインターフェースをテストする。
(ク) 運用テスト
運用テスト工程では,ほぼ実際の運用に近い形でテストを行う。開発工程はこの工程で終了である。
ウ 本件プロジェクトにおける作業工程
本件システム開発に際しても,事業・業務要件定義→計画・要件定義→設計→実装(プログラミング)→結合テスト→システムテスト→システム切替え→システム稼動という上記とほぼ同様の開発過程を経る予定とされていた。また,本件システム開発は,原告の業務全般のシステムに関するもので,非常に広範囲かつ膨大な作業が必要となることから,実際の開発作業は,①預金や融資などの基幹業務及び口座振替等の周辺業務といった銀行業務に関するシステム開発を担当する「業務グループ」(Corebank関連は本グループの担当であった),②外部との通信システム及びアクセスハブ等の制御システムの開発を担当する「制御グループ」,③システムの運用・管理,セキュリティ,災害対策等に関する基盤システムの開発を担当する「基盤グループ」の三つのグループに分けて進められた。
しかし,本件プロジェクト開始から約2年6か月以上かけて実際に行われたのは,本件システムで最も重要な部分である基幹系システム(上記業務グループ担当部分)については,実質的には,計画・要件定義の工程及び外部設計の途中までであり,制御及び基盤システムについては,設計作業が終了し,一部,プログラミング作業に入ったところまでであった。本件システム開発の作業は,本件プロジェクトの頓挫により中断した。
(3)  本件プロジェクト開始に至る経緯
ア 原告は,昭和46年10月に導入した基幹システムの老朽化が進んできたこと等の理由から,その刷新を図るため,平成12年ころ,当時既に30有余年にわたり原告のシステムの管理,運用の支援,OSの保守等を行ってきた被告に対し,オープンプラットフォームによる基幹系システム構築の提案及び同システムの運用,開発に係るトータルコストの削減に関する検討を依頼した(甲125,証人C)。
イ 原告は,同年9月,被告と共に,原告の事業戦略上実現すべき業務内容,次期システムの在るべき姿及びその要件等の洗い出し作業を開始した。
ウ 被告は,平成14年1月,次世代の勘定系ソリューションの一つとして,「NeFIS」(Next Generation Financial Services System(次世代金融サービス・システム)の略。NEFSSと改称される前の名称。以下,改称の前後にかかわらず,「NEFSS」という。)を企画,開発するためのチームを立ち上げた。
被告は,NEFSSの内部で銀行の勘定系システムをどう組み込むかを検討したところ,開発コストや開発に要する期間,さらにはIBMグループとしての戦略の観点から,米国Alltel Corebanking Solutions,LLC.(FIS社の前身。以下,まとめて「FIS社」という。)が権利を保有していたCorebankをNEFSSの部品として採用する方向で検討を開始した。
被告は,Corebankを用いて邦銀の勘定系システムを構築する場合に大きなギャップとなりそうなところが解決できるか,また,次世代の金融システムとしてアドバンテージとなるべき機能が実装できるのかを検討するとともに,COBOLを使用していたCorebankを,NEFSSの開発言語として使用する予定のJava(J2EE)にコンバート(Java化)する必要があると考えた。そして,平成15年3月には,NEFSSプロジェクトはいよいよ開発を始める段階に至った(乙177,証人D)。
エ 平成12年9月から実施された原告,被告による洗い出し作業(上記イ)の結果,平成15年7月,原告が導入する次期システムによって実現すべき事業要件が「変革のテーマ」と題する文書としてまとめられた。
オ 原告は,平成14年9月から平成15年12月ころにかけて「eプロジェクト」を実施し,被告はそれに協力した。被告は,この中で,原告が次世代の勘定系システムの在るべき姿を見定めることの手伝いをするとともに,そのような勘定系システムの開発に要する費用や期間等についての大まかなイメージを示した(乙176,177,証人D)。
カ 被告は,Corebankの日本化(Japanization)の作業が順調に進んだと考えたことから,平成16年3月12日,原告に対し,同日付け「「顧客中心」・「迅速・柔軟な商品・サービス提供」・「オンデマンド」を可能とする次世代金融サービスシステムのご紹介」と題する書面を交付した。
その中の「「次世代金融サービスシステム」業務機能の実装」と題する頁には,「以下の観点よりUSの先進パッケージ(Fidelity Information Servicesの‘Corebank’)を有効活用します。」,「「次世代金融サービスシステム」の目標である「顧客中心」の商品・サービスを「プロダクトビルド」(自由設計)できる機能を実現するためには,先行している欧米のパッケージの有効活用が優位である。」,「短期間でパッケージを構築するには,ゼロからの開発ではなく実績のあるパッケージを有効活用して開発する方が優位である。」と記載されている。また,「基本方針」として,「先進パッケージ機能と,2002年初めより実施してきた日本の銀行商品・サービスのモデル化とを融合させます。」,「パッケージのコンポーネント(部品)を「Web Sphere」上の「Java」にコンバージョン」,「日本の銀行の商品・サービスを追加」と記載されている(甲16,乙177)。
キ 原告は,被告のほか,複数のシステム開発業者から提案されたシステムを比較検討した結果,被告による提案の内容が最も好ましいものと考え,平成16年9月21日,①原告の基幹系オンラインシステムを被告が提供するNEFSSバンキングシステムを基に全面的に改良し,新経営システムを構築すること,②上記費用として,初期費用約95億円,保守費用として約6億2000万円(年額)を支出することを決めた。
なお,同日の原告取締役会に提出された議題に添付された原告作成の資料には,「プロジェクトのスケジュール」として「合意書/支援サービスの締結によって計画・要件定義#1を開始,計画・要件定義#2終了までに要件をまとめ,その内容に基づいた最終合意書(請負)を締結する。」,「総費用の概算内訳」として「ステップ1では上限を設定」とした上で計95億円と記載されている(甲20,21)。
(4)  「新経営システム」構築に関する基本合意(以下「本件基本合意①」といい,その合意書を「本件基本合意書①」という。)の締結(甲3)
同月29日,原告と被告との間で本件基本合意書①が交わされ,本件プロジェクトは開始された。本件基本合意書①には,概要下記アないしエのとおり記載されている。なお,この時点においては,原告と被告との間で,平成17年5月末に本件プロジェクトに関する最終合意が締結される予定であった。
ア 原告と被告は,被告提供のNEFSSを利用した原告の「新経営システム」構築に当たり,以下のとおり合意した。
イ 原告の目標である「開発スコープ」(平成16年9月21日付け資料:「新経営システムご提案概要」)の実現を前提とした「新経営システム」構築に当たり,以下①②③の全てが実行されることを条件として,被告は95億円(原告側要員費用含む)にて稼働を実現するよう確約する。
役割分担合意に伴う被告の管理下での原告側要員費用については,両者協議の上,工数及びスケジュール等の観点で管理を実施するものとする。
① 原告と被告の役割分担の両者による合意及び原告管理下のワークロード・費用の確定がされること
② 原告の商品・取引・帳票等に対する「BPR・標準化」による合理化・効率化の合意が両者によりされること
③ 上記①の役割分担合意に伴う,当該プロジェクトを遂行する上で必要な原告の協力がされること
ウ 「新経営システム」構築プロジェクトの計画・要件定義局面終了までに,以下の項目を含む外部設計局面以降に関して合意することを目標に両者は作業を進めるものとする。
(ア) 開発機能・スコープの詳細
(イ) 稼働までの初期費用総額の詳細及び支払計画
(ウ) プロジェクト期間中及び稼働後のランニング費用
(エ) ハードウェア構成・ソフトウェア構成と前提キャパシティ
(オ) プロジェクト遅延及び不履行時の取り決め
本条に定める合意までの間に,プロジェクトの大幅な延期や中止せざるを得ない状況が発生した場合,あるいは,本条に定める合意に至らなかった場合には,両者は真摯に協議の上,互いに誠意を持って損害賠償等の措置を含む適切な対応をするものとする。
エ 計画・要件定義局面の契約として,以下の内容を含む「IBM支援サービス契約書」(金額:7億2319万9000円)につき平成16年9月29日を目標に締結すべく,両者協議の上,進めるものとする。
(ア) 「新経営システム」構築の計画・要件定義フェーズ#1 ご支援作業
(イ) 「NEFSSパッケージ」(「コアバンク」及び「次世代金融サービス・システムライブラリー」)
(5)  本件プロジェクトの開始~計画・要件定義#1の経過
ア 原告は,同月29日,被告との間で,次の内容のIBM支援サービス契約を締結した(甲5の2)。
(ア) サービス名
「新経営システム」構築(計画・要件定義#1)
(イ) サービス内容
a 「新経営システム」構築の計画・要件定義#1支援作業
(a) プロジェクトスコープの確認
(b) プロジェクト計画の立案
(c) 「NEFSS」,「Corebank」の要件定義作業の方針検討・策定
(d) 現行システム分析
b 以下のプログラム(既存資料)の提供
(a) 「コアバンク(Version4.2)」
(b) 「次世代金融サービス・システム ライブラリー(現行版)」
(ウ) サービス料金
確定料金合計7億2319万9000円(消費税別)
(エ) サービス期間
平成16年9月30日より同年12月28日まで
イ(ア) 同年9月30日から本件プロジェクトが正式に開始された。
(イ) 本件プロジェクトにおいては,原則として毎月1回,原告及び被告の現場の開発担当者から役員までを出席者として会議(以下「ステアリング・コミッティ」という。)を行うこととされ,このステアリング・コミッティは,同年11月5日に第1回目が開催されて以来,平成19年3月まで合計27回開催された。
ステアリング・コミッティの目的は,「スルガ銀行及びIBM間の上級マネジメントレベルでの意思決定を行う」ことであるとされ,その主な内容として「プロジェクトの総合評価」,「スケジュール,作業進捗の実績,課題の共有」,「重要課題の意思決定,重要事項の報告」(なお,「重要事項の報告」のみ改訂版で追加された。)が規定されていた(甲49の1及び2)。
ウ 計画・要件定義#1(同年9月30日~同年12月28日)においては,本件プロジェクトの目標,開発対象となるシステム及び開発スケジュールの明確化,開発方法の検討などが行われ,被告は,原告に対し,計画・要件定義#1の成果物として,同月21日付けプロジェクト管理計画書(以下「PMP」という。)を作成した(甲5の3の2,乙261)。
(6)  「新経営システム」構築に関する基本合意書#2(以下「本件基本合意②」といい,その合意書を「本件基本合意書②」という。)の締結
原告は,同月29日,被告との間で,本件基本合意書①のコスト(本件システムの稼動後におけるランニング費用)に関する条項等を変更し,同日以降の作業を行うための個別契約を締結すべく協議すること等を定めた本件基本合意②を締結した(甲4)。
(7)  計画・要件定義#2の開始
ア 原告は,平成16年12月29日,被告との間で,計画・要件定義#2(計画・要件定義#1で作成されたPMPを踏まえた要件定義等の作業)を対象とした次の内容のIBMシステム・インテグレーション契約を締結した。計画・要件定義#2は,平成17年9月末までの予定とされていた(甲4・添付-3,甲5の3の1)。
(ア) 作業範囲
被告は,本件プロジェクトの要件定義(計画・要件定義#2)を請け負う。
(イ) 成果物
a 要件定義書
b PMP(更新版)
(ウ) 契約金額
確定金額35億円(消費税別)
イ 原告と被告は,平成16年12月29日,計画・要件定義#2を開始した。この計画・要件定義#2においては,本件システムにおいて実現すべき「変革のテーマ」等をどのように実際に具現化していくかについての方法の検討,本件システムに継承すべき現行システムが有する機能の分析,原告の現行システムとNEFSS/Corebankを用いたシステム上の処理との差異の分析(FIT/GAP分析)などが行われた。
なお,原告の現行システムが有する機能を分析し,それをベースとして,Corebankが有する機能を利用できればそれをそのまま利用するが,Corebankが有しない機能(ギャップ)については個別(カスタム)のプログラムを作成することでシステムの開発を進めるという手法(以下「カスタマイズ・ベース・アプローチ」又は「現行踏襲型アプローチ」という。)が採用されていた。
ウ 平成17年5月末に締結予定であった最終合意について,開発範囲・機能の合意に時間を要することなどを理由に,締結が同年6月末に延期されたが,更に同年9月末に再度延期された(甲47の1及び2)。
(8)  「新経営システム」合意(以下「本件最終合意」といい,その合意書を「本件最終合意書」という。)の締結
ア 原告は,同年9月30日,被告との間で本件最終合意書を交わした。本件最終合意書には概要次のとおり定められている(甲5の1)。
(ア) 第1条(新経営システム)
両当事者(原告及び被告を指す。以下同じ。)は,両当事者が合意する作業範囲,価格,支払条件及びその他の契約条件を規定する次の個別将来契約が両当事者により締結されることを条件として,本件システムの構築を被告への支払総額89億7080万円(消費税別。現在締結されている次の現行契約に基づく代金(消費税別)を含む。)で被告が行うことに同意する。
a 個別将来契約
(a) IBMシステム・インテグレーション契約書(基盤,制御,業務に関する外部設計局面~統合テストa局面のサービス契約)
(b) IBMシステム・インテグレーション契約書(NEFSS周辺システムのパッケージ・ソフトウェアのライセンス契約)
(c) IBMシステム・インテグレーション契約書(eMuSCに関する外部設計局面~統合テストa局面のサービス契約)
(d) IBMシステム・インテグレーション契約書(統合テストb局面~システムテスト局面のサービス契約)
(e) IBM支援サービス契約書(現行システムに対するTivoliを用いたホストシステム運用改善のためのサービス契約)
(f) IBMオープン・インフラストラクチャー・オファリング契約書(平成16年12月29日締結済)に対する将来の通知書11億6314万7000円分(ただし,現在見積金額)
b 現行契約(原告と被告との間で,本件プロジェクトの初期段階に関して,合意された次の契約をいう。)
(a) IBM支援サービス契約書(平成16年9月29日締結。計画・要件定義局面#1)
(b) IBMシステム・インテグレーション契約書(同年12月29日締結。計画・要件定義局面#2)
(c) IBMオープン・インフラストラクチャー・オファリング契約書(同日締結)及び同日付けの通知書(5億2050万4000円分)
(d) IBM支援サービス契約書(平成17年2月14日締結。z/OS総合移行サービス)
(e) IBM支援サービス契約書(同日締結。災害対策(BRS)システム構築支援サービス)
(f) IBMシステム・インテグレーション契約書(同年7月26日締結。eMuSC移行)
(イ) 第4条(損害賠償責任)
1.両当事者が第1条記載の各個別将来契約を締結した場合で,各個別将来契約において,原告が被告の責に帰すべき事由に基づいて救済を求める全ての場合において,被告の損害賠償責任には契約責任,不法行為等の請求原因を問わず,(a)被告は,現実に発生した通常かつ直接の損害に対してのみ,損害発生の直接原因となった各関速する個別将来契約の代金相当額を限度額とし,かつ(b)被告は,いかなる場合にも,被告の責めに帰すことのできない事由から生じた損害,被告の予見の有無を問わず特別の事情から生じた損害,逸失利益,データ・プログラムなど無体物の損害,及び,第三者からの損害賠償請求に基づく原告の損害については,責任を負わない。
2.本第4条第1項(a)記載の金銭賠償の限度額にかかわらず,第1条記載の各個別将来契約の下で被告に故意又は重過失が認められる場合,第1条記載の各個別将来契約の下でのあらゆる請求ないし請求原因に係る被告による損害賠償総額は,損害発生時点において締結済みの現行契約及び個別将来契約における原告の支払済みの累計料金相当額とする。ある時点での賠償総額は,その時点までの各個別契約の下での支払総額に限定され,また,被告が既に賠償をしていた場合には,損害賠償総額からその支払額を差し引くものとする。
3.本条第2項で,故意とは,原告に損害が生ずることを認識して被告が意図的に各個別将来契約に反する行為を行った場合を意味する(ただし,被告が原告の損害が拡大することを防止するために意図的に行った場合を除く。)。また,重過失とは,原告に損害が生ずることを認識しつつも注意義務の著しい懈怠による各個別将来契約の義務違反があった場合を意味する。
(ウ) 第7条(添付案)
原告と被告は,以下の項目に関して本日に至るまでの協議に基づく案を添付し,今後さらに協議をして,最終化することに合意する。
a 構築要件
b 新システム基盤
c 切り替え方針
d プロジェクト計画
e 前提条件
f 商品統廃合検討結果報告
g 権利関係
h 今後締結予定の契約内容
i サービスイン後の保守体制
(エ) 第8条(本合意書の性質)
原告の新経営システム構築プロジェクトとNEFSSは両当事者にとって戦力的に重要であることをここに再度確認する。また,両当事者は,新経営システム及びNEFSSの横展開可能成果物の開発を共同で行うこととする。両当事者は,各関連個別契約の締結により,本契約及び既に締結した「新経営システム」構築に関する基本合意書2通(本件基本合意書①及び同②)は,各関連個別契約に順次置き換えられることを認識し,全ての個別契約の合意に達するべく速やかに協議を行い,かつ,この協議を当事者の合意に基づき成功裡に完了することとする。
ただし,各個別契約(第1条記載の個別将来契約を含むがこれらに限定されない。)が締結され,各関連個別契約の中で両当事者の各局面における義務が規定されるまでは,いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。両当事者の書面による合意がある場合を除いては,本第8条は有効とする。
イ 本件最終合意書には,「「新経営システム」構築に関する基本合意書(添付)」と題する本件最終合意書7条に規定された案が添付されている。同案には次の記載がある。
(ア) 構築要件
「eプロジェクトパイロット3」(平成14年10月~平成15年6月)にて検討した変革テーマを元に44のグループにグルーピングを実施した。更に,平成17年1月から3月にかけて営業店等でのヒヤリングを実施し,結果を44のグループに分類した。44グループに属さない案件を変革テーマグループNo.45として定義した。「新経営システム」においては,45グループを実現すべき変革テーマとして位置付ける。
(イ) 採用パッケージソフトウェア一覧
基幹システム・NEFSS/Corebank
(ウ) サービスイン予定日
平成20年1月4日
(エ) 前提条件
a 基礎数値
以下の数値は,原告と被告との間の協議に基づいた初期的段階の見積りであって,両当事者の今後の協議及び同意に基づいて確定されるものとする。
b 商品グループ数
現行商品のシステムビューの商品グループ数:融資219グループ,預金88グループの計307グループ
c 印刷帳票数
4617帳票(平成17年4月15日報告)。今後の作業の中で帳票数を削減する。平成17年7月時点での見込み数は1618帳票(プログラムベース)(原告提示の削減見込み数(2526)から被告にて同一帳票などを削減試算した結果)。
d トランザクション数
現処理フロー数1407本(平成17年8月31日)。今後の作業の中で,上記フローを標準化し削減することを検討する。平成17年7月時点での見込み数は,813取引数(被告にてNEFSS API群をベースに試算した結果)。
ウ 原告と被告は,同日,プロジェクトの基本的な運営に関する覚書を締結した。そこには次のとおり定められている(乙1)。
(ア) 両者は共同開発パートナーとしての精神に基づき,プロジェクトの管理運営に一致協力していく。
(イ) 両者は従来型の発想にとらわれることなく,革新的なアプローチを柔軟に取り入れるよう対応する。
(ウ) プロジェクト推進に当たっては,両者はプロジェクトの中心となるビジネス目標達成を核とするという共通認識に立ち,ビジネス変革の効果を訴求する。
(エ) 実装手段の詳細については両者は互いを信頼し,現行システム及びその手順との親和性要件に伴う制約(例えば端末の画面・インターフェースなど)を可能な限り取り除いて,ソリューションの最大限の効果を引き出すような柔軟な対応を進める。
(オ) システムの実現方式として,パッケージ・ソリューション適用の基本を共通に認識し,カスタマイゼーションを最小限にとどめるよう対応する。
(カ) 原告の現行のプロセスの改善に努め,かつそれに伴うプロセスの変更にも柔軟に対応する。システムの効果を最大化するために,事務取扱手順の変更等を含めた案を両者で検討する。
(キ) プロジェクト推進に当たっては,進捗管理の指標として業務要件の実現適否を中心にし,プロジェクトの進捗に影響を与えるような文書化などの作業を低減,ないし最適化する。
(9)  本件最終合意締結後の経過
ア 平成17年10月5日に開催された第12回ステアリング・コミッティにおいて,制御グループ及び基盤グループによる計画・要件定義#2の完了評価が行われ,両グループの担当部分については,同月よりシステムの設計工程に入ることとされた。この制御グループ及び基盤グループの計画・要件定義#2は,ほぼ当初のスケジュールどおり進行した。
しかし,業務グループ担当部分の計画・要件定義#2は,平成17年12月末が終了予定時期とされた。
イ 被告は,同年12月12日,原告に対し,平成20年1月の安定的・成功裡のサービスインのためには,開発手法及びスコープの見直しが必要であるなどとして,開発方法及び開発内容の変更を提案した(乙5)。
その後,平成18年3月からBRD(Business Requirement Definition。以下,同月から同年5月まで行われたBRDを「旧BRD」という。)が開始された。旧BRDでは,パッケージソフトであるCorebankが有する機能をベースとして,原告の業務プロセスを可能な限りCorebankに合わせて変革し,カスタマイズは必要最小限に抑える手法(以下「パッケージ・ベース・アプローチ」という。)が採られた。
ウ 業務グループの計画・要件定義#2は,いったん延期された平成17年12月末という期限を超え,結局,平成18年3月8日に開催された第16回ステアリング・コミッティにおいて終了したことが確認された。
エ 同年4月5日に開催された第17回ステアリング・コミッティにおいて,制御グループ及び基盤グループの担当につき,設計工程が一応完了し,これらのグループ担当の部分については,実装工程(プログラミング工程)を開始することが承認された。
オ 同年3月から旧BRDが行われていたが(上記イ),同年6月から,FIS社の担当者がより深く関与する形に体制が改善された形でBRD(以下「新BRD」という。)が実施され,同年8月31日まで行われた。
なお,同年4月に開始された制御グループ及び基盤グループの実装工程作業(上記エ)は,新BRDでは,システムの根幹部分にメスを入れるため,いろいろなところに影響があるとして作業は中断されることになった。
カ 被告は,新BRDが同年8月31日に終了したことを踏まえ,同年9月前半から中旬ころ,業務グループ担当の基幹系システム部分につき,本件システムの基本設計工程作業を開始した。新BRD開始に伴い中断されていた制御グループ及び基盤グループの実装工程作業は,業務グループの基本設計工程の開始に伴い再開された。
キ 原告と被告は,同年11月13日に開催された第23回ステアリング・コミッティにおいて,次のスケジュールで本件システムを稼動させるという基本的な方向性について合意した(甲6の23)。
(ア) 平成20年1月:外為関連の新商品の提供に関するシステム稼動
(イ) 同年5月:本件システムによる一部サービスの開始
(ウ) 同年10月:全営業店における基幹系システム稼動
(エ) 同年12月末:本件システムの全面稼動
ク 被告は,平成18年11月以降,原告に対し,開発スコープの削減と開発費用の追加負担に関する提案を行っていたところ,同年12月11日,当初の計画どおりの開発スコープを実現するためには,追加費用として127億円を要すことを示した上,開発スコープの削減及びそのスコープを前提とした追加費用34億円の支払を提案した(甲7,乙83,310,312)。
ケ 同月13日,原告のE代表取締役副社長(以下「E副社長」という。)と被告のF取締役・専務執行役員(肩書は当時。以下「F専務」という。)との間で,開発スコープ及び開発費用についての打合せが行われた(乙112)。
コ 被告は,同月22日,原告に対し,原告の追加負担費用額を20億円に減少させた案を提案した。
サ その後,原告と被告の間で,開発スコープや追加の開発費用について合意ができない状態が続いたが,被告は,平成19年3月19日,原告に対し,平成22年1月までに5段階に分けて全面稼動させるスケジュールを提案した(甲80,乙8)。
シ 被告は,平成19年4月18日,原告に対し,Corebankに代えて,Temenos社の基幹系パッケージソフトであるTCBを採用する代替案を提案した。なお,TCBは,韓国の銀行において,韓国のIBMがベンダとなって開発したシステム上で稼動しているパッケージソフトであるが,勘定系にメインフレームと呼ばれるシステムを使用し,プログラム言語は4GL(4th Generation Language)及びCOBOLであった(甲9,弁論の全趣旨)。
ス 原告は,同年5月9日,被告に対し,本件プロジェクトをいったん白紙に戻す旨を記載した書面を交付した(甲31)。
セ 原告と被告は,本件プロジェクトに関する話合いを継続したが,合意に達せず,原告は,同年7月18日,同月17日付け内容証明郵便により,被告に対し,本件最終合意及び本件個別契約を債務不履行(履行不能)により解除する旨の意思表示を行った(甲15の1)。
(10)  反訴請求(ただし,不法行為に基づく損害賠償請求(請求の趣旨2項に係るもの)を除く。)に係る事実関係
ア 被告と原告は,本件プロジェクトに関し,次の契約を締結した。
(ア) 被告と原告は,平成18年3月31日,本件プロジェクトに関する「制御」及び「基盤」の設計局面#2(アクセスハブ設計作業,新対外システム設計作業,「新経営システム」システム基盤設計作業,「新経営システム」運用システム設計作業)に関する請負契約であるIBMシステム・インテグレーション契約(以下「本件未払個別契約①」という。)を締結した。成果物は,システム設計書(CD-ROM)一式であり,納入期限は同年3月31日,代金額は2億5725万円(消費税込み)で,支払期日が同年8月30日とされた(甲5の8の2)。
(イ) 被告と原告は,同年9月29日,基幹系基本設計の実施,周辺システム基本設計の実施,基盤環境構築作業,制御実装作業,移行基本設計の実施に関する請負契約であるIBMシステム・インテグレーション契約(以下「本件未払個別契約②」という。)を締結した。成果物は,基幹系・取引機能マトリックス(CD-R)一式等であり,納入期限は同年12月1日,代金額は11億1969万1650円(消費税込み)で,支払期日が平成19年4月6日とされた(甲5の8の5)。
イ 被告は,本件未払個別契約①所定の成果物である「システム設計書(制御編・基盤編)」を納入予定日である平成18年3月31日付けで原告に対して納品し,同日,原告による受領,受入検査を完了した。
原告は,本件未払個別契約①所定の代金額支払期日である同年8月30日を経過した現在においても,その代金の一部である2億5515万円(消費税込み)を支払っていない。
ウ(ア) 被告は,原告に対し,本件未払個別契約②所定の成果物である「基幹系・取引機能マトリックス」等(ただし,後記(イ)記載の一部を除く。)を納入予定日である平成18年12月1日に原告に対して納品し,原告の受入検査を経て,同月26日に上記の更新版を納品して,原告による受領,受入検査を完了した。
(イ) ただし,本件未払個別契約②所定の成果物である「設計・実装局面作業計画」については,いまだ原告による受領,受入検査がされていない。
(ウ) 原告は,本件未払個別契約②所定の代金額支払期日である平成19年4月6日を経過した現在においても,その代金額11億1969万1650円(消費税込み)を支払っていない。
エ(ア) 被告と原告は,平成16年12月29日,本件プロジェクトにおけるハードウェア,ソフトウェア等の導入,リース及び保守等に関し,オープン・インフラストラクチャー・オファリング契約(以下「OIO契約」という。)を締結した(甲5の4の1)。
OIO契約は,ハードウェア及びソフトウェアを広く対象とするものであるが,そのうち,乙372・14ないし17頁の「製品名称」欄記載のソフトウェアについては,OIO契約と一括して締結されたエンタープライズ・スペシャル・オファリング契約が適用される(以下,この契約を「ESO契約」といい,これが適用されるソフトウェアを「ESO契約対象ソフトウェア」という。)。
(イ) ESO契約対象ソフトウェアの使用料金の合計に関しては,一定の上限値が定められ,当該使用料金の上限値を超えた場合には,原告は,被告に対し,上限値の超過金額を支払う義務を負う。そして,平成20年度及び平成21年度における使用金額の上限値は次のとおりである。
平成20年度 2億3019万7600円(消費税抜き)
平成21年度 1億5776万0400円(消費税抜き)
(ウ) 平成20年度及び平成21年度における原告のESO契約対象ソフトウェアの使用料金実績金額は,次のとおり使用料金上限値を超過した。
平成20年度 1783万4000円(消費税抜き)
平成21年度 9649万0400円(消費税抜き)
(エ) 被告は,原告に対し,平成22年2月26日,上記使用料金超過額に消費税を付加した次の金額を請求した。
平成20年度 1872万5700円(消費税込み)
平成21年度 1億0131万4920円(消費税込み)
(オ) 原告は,被告の上記請求に対し,いまだに支払をしていない。
3  主たる争点
(1)  本件本質的義務の法的拘束力及びその不履行の有無(本訴,反訴)
(2)  本件プロジェクト中止の原因及びその責任の所在(本訴,反訴)
(3)  本件個別契約の債務不履行解除の成否(本訴,反訴)
(4)  説明義務違反の有無(本訴)
(5)  錯誤の有無(本訴,反訴)
(6)  原告の損害(本訴)
(7)  反訴請求の可否(反訴)
4  主たる争点に対する当事者の主張
(1)  争点(1)(本件本質的義務の法的拘束力及びその不履行の有無)について
(原告の主張)
ア 請負契約の締結
(ア) 原告及び被告は,本件基本合意書①及び同②により,被告がNEFSSを利用して,原告の銀行業務全般をつかさどる次期情報システムたる本件システムを報酬額95億円にて構築を請け負うことに関し,基本的事項の合意を行った。
(イ) 原告と被告は,平成17年9月30日,本件基本合意書①及び同②を受けて,本件最終合意を締結し,作業範囲,価格,支払条件及びその他の契約条件を規定する将来の個別契約(以下「本件将来個別契約」という。)の締結を前提として,被告が本件システムを開発,構築し,その結果(完成物)に対し,原告が89億7080万円を支払う旨の請負契約を締結した(本件最終合意書1条)。
イ 本件最終合意書の法的拘束力
(ア) 本件最終合意書8条ただし書及び同1条は,関連する個別契約の締結を前提として本件最終合意書が法的拘束力を有することを定めたものである。そして,個別将来契約(本件最終合意書1条)は,個別将来契約(4)「IBMシステム・インテグレーション契約書」を除き,全て締結済みである。
また,本件最終合意書8条ただし書記載の「各個別契約」は,本件最終合意書1条の「個別将来契約」の記載から明らかなように,本件最終合意の締結以降に実施すべき各工程に関するものである。本件システムを完成させるためには当然これらの工程の実施が不可欠であり,それに関する個別契約の締結も必要になる。しかしながら,仮に原告が,個別契約の締結を合理的理由がなく拒んだ場合にも,被告が本件システムを完成させる請負契約上の義務を免れないとすることは不合理である。本件最終合意書8条ただし書及び同1条は,このような不都合を避けることを趣旨として規定されたものである。そして,未締結の個別将来契約(4)「IBMシステム・インテグレーション契約書」が締結されなかったのは,当事者が不合理に締結を拒絶したことによるものではなく,この契約が対象とする「システムテスト」工程に入る前の段階で被告の故意又は重過失により本件プロジェクトが頓挫したためである。この個別契約は,仮に本件プロジェクトが順調に進行していれば,当然締結されていたはずのものであり,締結されなかったのは被告の故意又は重過失によるものであって,この契約が締結されなかったことに原告の帰責性は一切ない。
したがって,本件最終合意書が法的拘束力を持つと解釈しても,本件最終合意書8条ただし書及び同1条が懸念したような上記不都合は生じない。以上からすれば,本件最終合意書は,その文理及び趣旨に照らして,法的拘束力を有することが明らかである。
(イ) 被告は,本件最終合意書8条第3文をも本件最終合意書の法的拘束力を否定する根拠としている。本件最終合意書8条第3文には,「両当事者は,各関連個別契約の締結により,本契約および既に締結した『新経営システム』構築に関する基本合意書2通は,各関連個別契約に順次置き換えられることを認識し・・・」と記載されている。この本件最終合意書8条第3文と同条ただし書を併せ読むと,本件基本合意書①,同②及び本件最終合意書は,各関連個別契約の締結を前提として法的拘束力を有するが,各関連個別契約に個別に規定された部分については,個別契約が優先するということになる。すなわち,本件最終合意書8条第3文は,本件最終合意書の法的拘束力を否定するものではなく,むしろ本件最終合意書の該当部分が,各関連個別契約に「置き換えられる」としていることからすると,本件最終合意書の法的拘束力を大前提としている規定と解するのが自然である(本件基本合意書①及び同②にも法的拘束力があることが前提とされている。)。したがって,本件最終合意書8条第3文を根拠として本件最終合意書の法的拘束力を否定しようとする被告の主張は失当である。
(ウ) さらに,契約書に規定された内容を合理的に意思解釈する場合,その文言自体もさることながら,契約に至る経緯や契約締結後の当事者の履行状況その他関連する事実を総合的に考慮して当事者の合理的意思の内容は決定されるべきである。
本件最終合意が締結されたのは,平成16年9月に本件プロジェクトが開始してから1年後のことである。この間に開催された11回のステアリング・コミッティの議事録を見れば,かなり詳細な検討がされた上で,本件最終合意書において請負の報酬額を89億7080万円という確定金額として定め,本件システムのサービスイン時期を平成20年1月と定めたことが明確に理解できる。
また,本件最終合意の締結は,被告側の理由により,当初の締結予定時期(平成17年5月)から大幅に遅れて締結された。これは,本件基本合意書①においては「概算見積り」を合意し,本件最終合意書においては「確定金額」を合意するという「2段階の合意」が当初からの予定であり,これが原告及び被告双方が認識していた本件基本合意書①及び本件最終合意書の位置付けであり,それゆえ,計画・要件定義作業の実施により最終合意書に規定する内容(特に本件本質的義務の内容や別添資料に盛り込むべき業務要件定義の内容)を具体的に確定するのに時間を要した。
加えて,被告は,本件最終合意書の履行の過程においても,終始一貫して本件最終合意書に法的拘束力があることを前提とする言動を行っており,本件最終合意書に法的拘束力が認められないという趣旨の言動をしたことは一度たりともない。被告も,本件最終合意書の効力に関して自らがいかなる言動をとってきたかを冷静に振り返れば,この点は否定しようがないはずである。本件最終合意書の履行の過程からしても,原告のみならず被告も本件最終合意書が法的拘束力を有するとの認識があったことが分かる。
以上からすれば,当事者の率直な意思からしても,本件最終合意書に法的拘束力が認められることは明白である。
(エ) 仮に,本件最終合意書の法的拘束力が全ての個別契約の締結という停止条件に服していると解釈されても,被告は,故意又はこれと同視すべき重過失によりこの停止条件の成就を妨害したのであるから,民法130条により,この停止条件は成就したものとみなされる。
また,被告は,個別将来契約(4)「IBMシステムインテグレーション契約書」以外にも個別契約が締結される予定であり,かかる個別契約も締結していないのであるから,本件最終合意書は法的拘束力を有していない旨主張する。しかし,本件最終合意書1条において締結することが「条件」とされた「個別将来契約」のうち,未締結のものは個別将来契約(4)「IBMシステム・インテグレーション契約書」のみである。加えて,仮に被告がいうとおり,個別将来契約(4)「IBMシステム・インテグレーション契約書」以外にも個別契約が締結される予定であったとしても,かかる個別契約は,全てCorebankを採用したのでは本件システムを完成できないことが明らかとなって,本件プロジェクトが頓挫した以降の工程に関するものであり,被告の故意又は重過失により締結されなかったものである。
その他,被告の主張は,本件プロジェクトにおける自らの言動を翻し,過度に一般論にのみ依拠した「後付けの論理」に終始しているばかりか,本件における事実関係及び客観的証拠に一切基づかないものであり,極めて失当である。
ウ 本件本質的義務の法的拘束力
(ア) 被告は,上記ア,イのとおり,「次世代金融サービス・システム(NEFSS)」を利用した本件システムを完成させるべき請負契約上の義務を負っているが,その具体的義務として少なくとも次の義務(以下,総称して「本件本質的義務」という。)を負っている。
a FIS社のアプリケーション・パッケージ(基幹システム)であるCorebankを採用し,Corebankに,日本の銀行特有の基幹業務の機能を追加して,本件システムを構築する義務
b 銀行業務全般をカバーし,「変革のテーマ」(本件基本合意書①(甲3)の添付資料「『新経営システム』プロジェクト新業務・機能要件に対する開発方針」と題する文書)に記載の業務を実現するシステム(基幹系,周辺系,基盤系,制御系システムの全てを含む。)を開発対象の範囲(以下「開発スコープ」という。)とし,本件システムを構築する義務
c 平成20年1月までに,請負代金を89億7080万円として,本件システムを完成・納入し,稼動させる義務
(イ) 被告が本件本質的義務を法的拘束力があるものとして負っていることは,本件本質的義務の内容が,本件最終合意書と一体のものとしてこの一部を構成する添付資料「『新経営システム』構築に関する基本合意書(添付)」に明示的に記載されている(同資料9頁以下)ことから明らかである。
なお,本件最終合意書によると,上記添付資料は,「本日に至るまでの協議に基づく案」であり,「今後さらに協議をして,最終化することに合意する」とされている(本件最終合意書7条)。しかし,少なくとも,上記(ア)aないしcの事項については,本件最終合意の締結時点においては確定的な合意事項として最終化されていた。これは,本件最終合意の締結に至る経緯のみならず,次の事情から明らかである。
すなわち,上記(ア)aないしcの事項(基幹システムに関する事項(いかなるアプリケーション・パッケージを採用するか),開発スコープに関する事項並びに構築したシステムのサービスイン時期及び費用に関する事項)が合意されなければ,システム開発に関する契約はその成立要件を満たさない,つまりいかなるシステムをいつまでにいくらの費用で構築するのかが決まらなければ,システム開発の委託につき合意されたとはいえない。また,上記(ア)aないしcの事項は,請負の報酬金額を見積もる上で必要不可欠な事項であるところ,本件最終合意書では請負の報酬額が確定金額として定められている。さらに,被告は,その作成に係る平成18年12月11日付け「『新経営システム』構築プロジェクトの今後の進め方に関するご相談」と題する文書において,「合意書時点の計画」として,原告及び被告が,上記(ア)a及びc(サービスイン時期)の事項を本件最終合意の締結時点で合意した事項として明示的に確認している。
加えて,被告は,本件基本合意①締結直後の平成16年10月20日に行ったプレスリリースにおいても,上記(ア)a及びc(サービスイン時期)の事項は被告が行う事項として明記している。
以上からすれば,本件最終合意書添付資料が案であるとしても,少なくとも上記(ア)aないしcの事項については本件最終合意の締結時点において「最終化」されており,本件本質的義務は,法的拘束力のある義務として原告及び被告により合意されたことが分かる。
(ウ) Corebankを基幹に据えて本件システムを構築する義務
a 被告は,法的拘束力のある本件基本合意書①及び本件最終合意書において,Corebankを基幹に据えて本件システムを構築する義務を負っている。
そもそも,パッケージ型システム開発においては,基盤となるパッケージソフトが開発費用,開発スケジュール,稼動時期(サービスイン時期),開発手法,開発体制などの「プロジェクト全体計画」策定の基礎となるものであり,同時にハードウェア構成,ソフトウェア構成といった構築システムの根幹を決定するものでもある。すなわち,パッケージ型システム開発においては,パッケージが決定されないことには,開発も開始することができない。この意味で,パッケージ型システム開発において,パッケージの選定は,最終的に開発する対象となるシステムの根幹を決定するものであり,プロジェクトの大前提であって,かつ,その適切な選定は最重要課題の一つというべきものである。
したがって,システムに用いるパッケージは,システム開発の開始以前の段階において確定されなければならない。本件システムにおいては,Corebankが採用されることが前提とされていたが,パッケージ型システム開発においては,システムに用いるパッケージが決まらないことにはシステムの開発作業が開始できないのであるから,本件プロジェクトが開始された段階,すなわち本件基本合意①が締結された平成16年9月29日には,当然,原告及び被告において確定的に合意されていた。
b また被告は,本件基本合意書①及び本件最終合意書に加え,法的拘束力を有することに全く争いのない本件個別契約においても,Corebankを採用して本件システムを構築することを合意している。
したがって,万が一,本件基本合意①を締結した時点ではCorebankを採用して本件システムを構築する義務が最終化していなかったとしても,法的拘束力のある本件個別契約を締結した時点では,かかる義務は最終化し,本件個別契約上の法的義務となったといわざるを得ない。
c また,本件プロジェクト開始以降,約2年もの期間を費やして実施された計画・要件定義#1,計画・要件定義#2,旧BRD,新BRDにおける検討作業の大半がCorebankと本件システムのFIT/GAP分析作業であった。
d さらに本件プロジェクトの遂行過程においても,被告は,Corebankは,本件システムの根幹である旨を終始一貫,繰り返し強調し,原告もその被告の説明を信頼していた。それのみならず,被告は,当初から終始一貫してCorebankの採用を大前提とした書面での報告を繰り返し行っている。
e また,被告は,Corebankが本件システムの基幹部分を構成する最重要部分であったことから,わざわざ原告を北欧にまで連れて行き,Corebankを実際に採用したシステムの稼動状況を視察させている(平成17年10月31日~同年11月4日)。
f 上記のような揺るぎない証拠の存在にもかかわらず,被告は,訴訟になって,「実はCorebankの採用も『最終化』されていなかった」などと主張している。つまり,被告は,パッケージ型システム開発を行うとしながら,その基幹となるパッケージも当事者間で最終的には合意していなかったと主張しているのであるが,このような主張は,単に失当であるのみならず,システム開発業者としては非常識かつ無責任極まりない。それとも被告は,本件システム開発において,約79億円もの大金を受け取っておきながら,プロジェクトの最重要事項の一つであるパッケージの種類についても,法的義務を終始一貫負っていなかったとでもいうのであろうか。このような極めて不合理な主張が失当であることは明白である。また,被告は,業務要件を充たしさえすれば,パッケージはCorebankでもTCBでも何でもよかったのであるという旨主張しているが,これは暴論以外の何ものでもない。さらに,被告は,「Corebankの採用が本件プロジェクトにおいて原告,被告間で前提とされていたこと」については訴訟においても明示的に認めておきながら,「Corebankの採用が本件プロジェクトにおける前提となっていたことと,Corebankの採用が当事者間において法的拘束力を有する合意であるかどうかは別論である」などと主張している。被告は,原告から客観的証拠に基づき,被告がCorebankを採用して本件システムを構築する義務を負っていたことを主張され,かつ,この原告の主張に反論できないことから,この主張に対して正面から反論せずに上記のような苦し紛れの主張をしているのであろうが,このような論理はせいぜい「言葉遊び」にすぎず,到底採用できるものではない。加えて,被告は,Corebankの採用の「提案」を行ったのではなく「紹介」を行っただけであると主張するが,かかる主張は極めて不当な詭弁である。
被告がこのように不合理で,到底本気で行っているとは思えない主張を行わざるを得ないことからすれば,被告も,自らがCorebankを採用して本件システムを構築する法的義務を負っていたことを実質的には認めているというべきである。
g 以上からすれば,被告がCorebankを採用して本件システムを構築する法的義務を負っていた事実は揺るがない。
(エ) 開発費用,開発スケジュール及び開発スコープ
被告は,本件本質的義務のうち,89億7080万円という開発費用,平成20年1月のサービスイン時期及び開発スコープに関しても法的義務を負っていた。
a そもそも,大規模なシステム開発をベンダに委託する際に,システム開発全体に要する開発費用を何ら合意することなく,全て各フェーズの個別契約に委ねるということは非現実的であり,通常,契約当事者の合理的意思とはいい難い。
もとより企業が大規模な投資を行う場合,その対象がシステム開発であろうと他の案件であろうと必ず投資効果分析を行い,投資を上回る効果が得られると判断できて初めて投資の意思決定が可能となる。投資効果の評価を行うことなく投資を意思決定するなどということは,経営の常識に照らしてあり得ない。仮にそのような経営判断をしたとすれば,経営者は重大な経営判断の誤りを犯したと評価されることになることに議論の余地はなかろう。そして,投資効果分析を行うためには,総投資額(あるいは上限)が明確になっていることが必須である。しかし,開発費用について上限を定めず,プロジェクトの進行に伴って随時,個別契約により業務委託費用を決めていくこととすれば,開発費用は,歯止めがなくなり,際限なく増大してしまうおそれが高く,青天井となってしまう。そして,開発費用がユーザの当初想定を大きく上回る事態になれば,プロジェクトは頓挫することになる。このような結果は,ユーザだけでなく,ベンダにとっても大きなデメリットである。プロジェクトが失敗に終われば,ユーザとの信頼関係は崩れ,ベンダはユーザから委託費用を円滑に回収することも困難になりかねないし,プロジェクトを失敗させたというレピュテーションリスクも背負うことになるからである。開発費用にあらかじめ上限を設けないことは,一見するとベンダにとっては赤字に陥るリスクを回避できる点でメリットのみがあるように思えるかもしれないが,開発費用の上限を定めない場合,予算の抑制が効かず業務委託費用が際限なく増える確率も高まり,結果としてプロジェクトが失敗する確率が高まることから,ベンダにとっても望ましくないのである。
したがって,システム開発全体に要する開発費用を何ら合意することなく,全て各フェーズの個別契約に委ねるということは,ユーザはもちろんベンダにとっても合理的意思とはいえない。
そこで,原告は,開発費用が「青天井」になることを避けるために,平成12年9月から,被告と共に約4年の年月をかけて,原告の事業戦略上,実現すべき業務内容,次期システムの在るべき姿及びその要件等の洗い出し作業を実施して,本件基本合意書①においては「概算見積り」を合意し,本件最終合意書においては「確定金額」を合意したのである。より具体的にいえば,平成12年9月から,原告は,被告と共同で,「E-Project パイロット3 新システム予備検討」と題して原告の次世代システムの検討を行い,平成15年7月からは「NEXT 予備検討」と題して更に検討を進めた。
また,被告は,これらの検討結果を受け,平成16年4~6月,原告と共同で,次世代システムの機能要件(「変革のテーマ」。これは本件基本合意書①に添付され,同合意書の内容にもなっている。),投資費用,運用費用及びシステムデザイン等を作成した。こうした詳細な検討を経て本件基本合意①が平成16年9月29日に締結され,本件プロジェクトが開始された。さらに,本件最終合意は,プロジェクトが開始されてから約1年間かけて業務要件定義工程を実施した後に締結されたのである。
このように,被告は,平成12年9月からの上記の諸検討によって,開発費用の見積りに必要な基礎データを十分に把握した上で,本件最終合意書において89億7080万円という開発費用を合意したのである。本件プロジェクトのように,約5年もの時間をかけた極めて入念な事前検討を経て,開発費用や開発スケジュールが具体的に合意されることは,システム開発においても非常にまれである。被告は,これだけの事前検討を入念に行っていたのであるから,極めて精緻な見積りと開発スケジュールの策定を行うことが可能であったはずである。
このようにして最終的に合意された89億7080万円という開発費用が法的拘束力のある確定金額であることに疑念の余地はない。
b また,被告自身も,この89億7080万円という開発費用は,本件システムを構築するための開発費用の確定的な総額であるとの理解に立っていた。
被告は,本件訴訟において,本件プロジェクトの遂行過程における自らの言動とことごとく矛盾する主張を行っているが,かかる主張に説得力がなく,無意味なものであるのは明白である。
c なお,確かに,システム開発の案件によっては,被告が主張するとおり,開発費用の総額を確定的に合意することなく,個別契約において各フェーズの業務委託費用を合意していくケースもある。
実際に,被告も,他のシステム開発案件においては,通常,プロジェクト開始時点の「基本契約」で具体的なシステム開発費用について合意しない。
しかし,本件プロジェクトにおいて,原告と被告は,このような被告の通常のプラクティスとも全く異なり,本件基本合意①を締結するまでに4年,本件最終合意を締結するまでに5年もの歳月をかけて業務要件等を共に検討した上で,89億7080万円という開発費用を明確に合意している。しかも,その金額は1000万円単位のようなおおざっぱな定め方ではなく,10万円単位の詳細な額で定められている。この精度は実に0.001%(10万円÷89億7080万円)という極めて高い精度であり,この事実も,89億7080万円という金額が上述の詳細な分析・検討の結果提示されたものであって,単なる「目安」のような抽象的な金額でないことを示している。
d 上記の開発費用に関する議論は,開発スコープに関する事項及びシステムのサービスイン時期についても同様に当てはまる。すなわち,これらに関する事項が合意されなければ,そもそもシステム開発に関する契約はその成立要件を満たさない。
e また,被告は,法的拘束力を有することに全く争いのない本件個別契約においても,本件最終合意書における開発スコープに関する事項及び構築したシステムのサービスイン時期を大前提として合意している。
したがって,万が一,本件基本合意書①では開発スコープに関する事項及び構築したシステムのサービスイン時期が「最終化」していなかったとしても,法的拘束力のある本件個別契約を締結した時点では,かかる義務は「最終化」し,本件個別契約上,被告の法的義務となったといわざるを得ない。
エ 本件本質的義務の債務不履行
(ア) 履行不能(Corebankを基幹に据えた本件システムの開発が不可能になったこと)
被告は,①GAP開発の役割分担,開発スケジュール,更には開発費用等についてFIS社との間で合意することができず,結果,Corebankのカスタマイズが行えない状況となったこと,②本件システムの開発費用が現実的な水準を越え,かつ,開発スケジュールにおいても本件システムがいつ完成するか分からない状態になったこと,③「Corebankの技術的な問題」(Java変換後のパフォーマンスの悪さ)が存在し,本件システムへの採用に耐え得る状態ではなかったこと,更には,④本件プロジェクトが正式に開始され,約2年7か月もの間,Corebankの採用を大前提として膨大な費用と労力をかけて開発が進められてきた中で,被告がTCBの採用という「代替案」を提案せざるを得なくなったこと,及び⑤その「代替案」の提案自体の内容も極めて杜撰(検証不十分)で提案と呼べるものではなかったにもかかわらず,被告がこの段階で,極めて不合理な提案を行わざるを得なかったことなどからすれば,Corebankを基盤に据えて本件システムを構築することが不可能であったことは極めて明白である。したがって,本件本質的義務(Corebankを採用して本件システムを構築する義務)が履行不能となったことに疑念の余地はない。
(イ) 債務の本旨不履行(被告がCorebankの採用を断念したこと)
また,被告は,Corebankの採用が不可能となったことから,これを断念し,平成19年4月18日にCorebankの代替案としてTCBの採用を提案するに至ったことは明白であり,したがって,被告は,本件本質的義務の本旨に従った債務の履行をしなかったことも明白である。
(ウ) さらに,Corebankを基盤に据えて本件システムを構築することが不可能となり,被告が本件プロジェクトを頓挫させたことからすれば,本件本質的義務のうち,サービスイン時期に関する義務(原被告の合意により変更された平成20年12月に全面稼動させる義務)及び合意された開発スコープを実現した本件システムを構築する義務も本旨不履行及び履行不能となったことは明白である。
(被告の主張)
ア 本件最終合意書の法的拘束力
(ア) 本件基本合意書第8条ただし書には,本件最終合意書が法的拘束力を有しないと明記されている。原告の主張は,本件最終合意書の規定に明確に反する解釈論であって,全く容れるところがない。
本件最終合意書第8条は,本件最終合意書が,その締結時点及び個別契約が全て締結された時点のいずれにおいても法的拘束力を有しないことを極めて明確に規定している。「各関連個別契約の中で両当事者の各局面における義務が規定されるまでは,いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする」と明確に規定され,「本第8条は有効とする」とされているにもかかわらず,なぜ第1条に記載された89億7080万円でシステムを完成させる「法的な義務」を負うと考えるのか,理解に苦しむ。
(イ) 原告は,本件最終合意書で締結が予定されている各個別契約は個別将来契約(4)を除き全て締結済みであるとする。しかし,原告が唯一未締結であると主張する個別将来契約(4)「IBMシステムインテグレーション契約書」は,「統合テストb局面~システムテスト局面」を対象とするものであるところ,本件では,これ以外にも,本件最終合意書第1条に規定する個別将来契約(1)「IBMシステムインテグレーション契約書」のうち,「業務」に関する外部設計・内部設計・開発・テスト局面,並びに「制御」及び「基盤」に関する開発・テスト以降の局面に関する個別契約のほとんど,すなわち,個別将来契約(1)の大半が未締結である。
(ウ) また,原告は,締結していない個別将来契約は被告の故意又は重過失により締結できなかったものであるため,本件最終合意書の趣旨に照らし,本件最終合意書が法的拘束力を有するなどと主張する。しかし,これらの個別契約が締結されなかったのは,被告が,要件定義・BRD終了後に行った見積りを基に,平成18年9月から12月ころにかけて現実的な開発スコープ及び開発費用の負担額等に関して積極的な提案を行ったにもかかわらず,原告被告間に契約がなくなった同年12月18日以降も原告がこれに応じず,被告が契約を締結するよう強く要請した平成19年1月に至っても原告がこれを締結しなかったからである。したがって,これらの個別契約が被告の故意又は重過失により締結されなかったなどという事実はなく,むしろ,原告が,交渉において,法的拘束力のないことが明らかな開発スコープや89.7億円等に固執するなど不合理に強硬な姿勢を貫き,結局これらを締結しなかったというのが真実である。
(エ) さらに,原告は,本件最終合意書8条本文第3文の解釈につき,「本件基本合意書①,同②及び本件最終合意書は,各関連個別契約の締結を前提として法的拘束力を有するが,各関連個別契約に個別に規定された部分については,個別契約が優先する」と主張する。したがって,原告の上記解釈によっても,「関連する個別契約の締結を前提として本件最終合意書が法的拘束力を有する」以上,本件最終合意書が締結されたときから個別契約が締結されるまでの間は,本件最終合意書に法的拘束力がないことには争いがない。
そして,原告は,「各関連個別契約に個別に規定された部分については,個別契約が優先する」とするところ,個別契約のうち請負契約に該当する「IBMシステム・インテグレーション契約」には,(ⅰ)契約金額,(ⅱ)作業予定及び成果物の納入予定日,並びに(ⅲ)作業範囲及び作業項目が,また,個別契約のうち準委任契約に該当する「IBM支援サービス契約」には,(ⅰ)サービス料金,(ⅱ)サービス期間,及び(ⅲ)サービス対象範囲が,いずれも例外なく記載される。したがって,原告の解釈を前提としても,少なくとも,本件最終合意書記載の(ⅰ)開発費用のうち原告の負担分,(ⅱ)開発スケジュール,及び(ⅲ)開発スコープについては,本件最終合意書の規定内容は,同一の項目を規定する法的拘束力を有する個別契約が「優先する」ことになる。
よって,個別契約締結後も,上記(ⅰ)~(ⅲ)の点について,本件最終合意書が法的効力を有することはない。
(オ) 原告は,本件最終合意書8条第3文につき,「本件最終合意書の法的拘束力を否定するものではなく,むしろ本件最終合意書の当該部分が,各関連個別契約に「置き換えられる」としていることからすると,本件最終合意書の法的拘束力を大前提としている規定と解するのが自然である」などと根拠のない解釈論を展開するが,法的拘束力がない合意書が法的拘束力のある個別契約に「置き換えられる」ことに何ら不自然な点もないし,そもそも,原告の上記主張は,あたかも個別契約により置き換えられる本件最終合意書が,「置き換えられる」より前の時点,すなわち個別契約締結以前の時点で法的拘束力を有していることを前提とするかのようであって,個別契約締結までは本件最終合意書に法的拘束力がないことを認める自らの主張と完全に矛盾している。
(カ) 履行を強制し,あるいはその不履行について損害賠償請求をすることのできる法的拘束力を持った契約であるためには,合意の内容が特定されていなければならないことはいうまでもない。
本件最終合意書においては,原告の費用負担額については第1条及び第8条により確定していないことは明らかであるし,開発スコープ及びサービスインの時期についても第7条において「今後さらに協議をして,最終化する」としており,その時点では「最終化」していないことが明らかである。つまり,費用負担額,開発スコープ及びサービスインの時期について,今後要件定義等を通じて「何を作るのか」が決まる過程で,交渉等を経て決定されることが予定されていた。
したがって,本件最終合意書は,履行を強制し,あるいはその不履行についての損害賠償を請求することができるものではない,すなわち請負契約としての成立要件を満たさない。
(キ) 原告は,本件最終合意書に至る経緯や契約締結後の当事者の履行状況その他の事情を「当事者の合理的意思」などとして本件最終合意書の解釈に影響を与えるかのように主張する。しかし,当事者の意思解釈とは,条文の趣旨が不明確なときにその解釈について補充的に行われるべきものであって,本件最終合意書第8条ただし書のように,法的拘束力を有しないことが一義的に明確な場合に当事者の意思解釈を持ち込む余地はない。しかも,本件最終合意書は,東証一部に上場する銀行である原告と世界的なIT企業である被告という大企業同士がその文言について十分検討を行なって締結したものであるから,「当事者の合理的意思」の解釈という名の下に,文言に反する効果を発生させるべき事案ではない。仮に,原告の主張するように,企業間の取引において,協議の上で一義的に明確な文言を定めたにもかかわらず,それに一見して反する解釈を「当事者の合理的意思」などと称して公然と行うことになれば,契約書や合意書の文言を信頼して日常的かつ大規模に行なわれる企業間の取引が,その信頼の基盤を失い,大きな支障を来すことは必定であり,経済社会に与える影響は図りしれない。本件においては,原告の主張するように文言を逸脱した解釈を行うことは断じて認められるべきではないのである。
(ク) 加えて,原告が「当事者の合理的意思」の基礎として主張する各事実は,いずれも失当である。
a まず,本件最終合意書が平成17年9月に締結された経緯は,原告の主張するようなものではなかった。当時,要件定義における現行の業務・システムの分析が遅滞していたこと,BPRにおける商品,取引,帳票等の削減等に対する非協力的態度に象徴されるように,原告が自分たちは95億円以上支払うことはないから「あとは何から何まで全部被告にやらせてしまえばよい。ベンダである被告が何とかすべきだ」という非協力的な態度に終始していたこと等から,コストが増加することが明らかとなっていた。そのため,本件プロジェクトにおける開発費用等がいずれも未確定であって法的拘束力を持ったものではないことを改めて明確にする趣旨で,本件最終合意書を締結した。
b 次に,原告は,甲47の1の記載から,本件基本合意書①においては「概算見積り」を合意し,最終合意書においては「確定金額」を合意するという「2段階の合意」が原告及び被告双方が認識していた本件基本合意書①及び本件最終合意書の位置付けであったなどと主張する。しかし,被告もプロジェクト開始前に合意した本件基本合意書①の時点においては,「最終合意書」と称する本件最終合意書と性質の異なる合意書を交わすことができると考えられていたことについて争っているわけではない。被告は,そのような当初の見通しとは異なり,計画・要件定義#1において「現行分析」ではなく「現行分析の準備」を行うことになってしまったこと,計画・要件定義#2においてヒアリングをベースとして現行分析を行ったが現行の業務及びシステムを書面化するに十分な知識を持った者が原告にいなかったことから平成17年5月からリバース・エンジニアリング等により現行を分析することとなったこと,BPRにおいて開発対象を絞り込むことができていなかったことなどから,当初「最終合意書」の締結を予定していた平成17年5月ころには,いまだ,開発スコープ,開発費用及び開発期間を確度の高い形で見積もり,合意に至ることが不可能な客観的状況にあったことを指摘しているのである。そして,このような状況にあったことは,甲47の1に,「業務要件の開発範囲・機能が5月末には概要レベルで合意でき,昨年9月時点の見積りコスト内に納められると予測しておりました」,「「BPR」による開発対象基礎数値(目標値)の確定と合意が未済」などと記載されていることからも証拠上明らかである。
原告は,このような被告の客観的な状況に関する証拠に基づいた主張に何ら反論できていない。
この点につき,原告は,被告は契約締結のための膨大な時間と費用を掛けて「概算見積り」を2回もしようとしていたというのであろうかなどとも主張する。しかしながら,そもそも,本件最終合意書における89億7080万円という金額は,本件基本合意書①における95億円という金額から原告側において直接支出すべき費用(原告管理下での原告側要員費用,原告が富士通から購入するSMILE端末費用及び同じく三菱東京UFJ銀行から購入するMBA費用)を差し引いたものにすぎない。すなわち,実質的には本件基本合意書①における95億円をそのまま記載したにすぎないのであって,「見積り」を行ったものではないから,原告の主張はその前提を欠いている。
(ケ) 以上のとおり,本件最終合意書の法的拘束力に関する原告の主張はいずれも失当であり,本件最終合意書はその第8条に明記されているとおり,法的拘束力を有しないものであることは明らかである。
イ 本件本質的義務の法的拘束力
(ア) 本件最終合意書が法的拘束力を有しないものである以上,原告が主張する本件最終合意書に基づく本件本質的義務も法的拘束力を有しないものであることは明らかである。これは,これらの事項が「最終化」(本件最終合意書7条)しているか否かに関わらない。
すなわち,第1条における89億7080万円という金額やその添付における「構築要件」(開発スコープ)及び「プロジェクト計画」(開発スケジュール)その他の記載を含む本件最終合意書全体につき,本件最終合意書8条において,原告と被告は明示的に「いずれの当事者も本合意書に基づき何らの法的義務を負わない」と合意した事実は動かないのであって,これにもかかわらず,原告の主張する本件本質的義務なるもののみが本件最終合意書に基づいて法的拘束力を有することなどあり得ない。
(イ) 原告は,パッケージ型システム開発においては,パッケージが決定されないことには,開発も開始することができないなどとし,システムに用いるパッケージは,システム開発の開始以前の段階において確定されなければならないことを,専門家の意見書を引用して主張し,Corebankの採用は変更し難い「不可侵」の部分であったとしている。このような原告の主張及び原告側の専門家の意見書は,いずれも,「パッケージ」には様々な種類のものが存在することを一切捨象し,完成した既存のパッケージを適用するシステム開発を行うことを前提としたものとなっている。しかしながら,そもそもCorebank自体が完成したパッケージであるという前提自体が誤っている。Corebankは,銀行の勘定系システムのプログラムを開発するための「部品」であるAPI及びデータベースの集合体にすぎない。
そして,NEFSSとCorebankの関係を整理すれば,NEFSSというパッケージの中でCorebankという部品が呼び出される関係にある。その結果,NEFSSというパッケージからみると,部品を他パッケージへ変更したり,User Exitと呼ばれる金融機関独自のプログラムを外付けで作成したりすることが可能である。
このように,ユーザからみれば,原告が主張するパッケージに該当するのはNEFSSなのであり,CorebankはNEFSS内部で呼び出されている単なる部品にすぎない。
被告は,被告が販売するパッケージ(ソリューション)としての「NEFSS(NeFIS)」を,本件プロジェクトが開始された平成16年9月よりも2年以上前である平成14年6月ころから開発してきていた。そして,本件プロジェクトは,NEFSSの第1号案件であり,本件プロジェクトを通じてNEFSS/Corebankという横展開可能なパッケージを完成させることが企図されていた。だからこそ,本件プロジェクトは,被告の投資案件として,被告からも多額の投資を行うものとされていたのである。
したがって,「Corebank」という完成されたパッケージを導入するプロジェクトであるという前提の上に立った原告の主張及び意見書は,①本件プロジェクトを通じてNEFSS/Corebankを完成させるという前提,及び②CorebankはNEFSSの内部で呼び出されるAPI(部品)にすぎず,原告のいう「パッケージ」「ひな型」に該当するのはCorebankではなくNEFSSであるという前提をいずれも欠いているために,あるいは少なくともこれらの前提についての検討がなされていないために,無意味なものとなってしまっているのである。
以上のとおり,CorebankはNEFSSの内部で呼び出される部品(API)にすぎないことから,ERPパッケージ等の完成度の高いパッケージとは異なり,同様の機能を有する「部品」,例えばTemenos社のTCBであっても,ユーザからみたパッケージである「NEFSS」において同等の機能を提供されていれば,目的を達成することができるものなのである。
したがって,本件プロジェクトにおいて,仮にCorebankが使用されなかったとしても,原告の業務要件が実現される限り,どのAPIを使用するかについて被告が法的な責任を負うものではない。被告が「Corebank」の採用が本件の非本質的部分であり,被告の法的義務を構成するものではないと主張するのはかかる意味においてであり,原告の上記主張は,この点に対する有効な反論となっていない。
(ウ) 原告は,本件プロジェクトにおいてCorebankの採用が当事者間において前提とされていたことをるる主張する。しかし,被告においてもNEFSSにおける勘定系構築の部品としてCorebankを採用することを前提として莫大な投資を行ってきたのであり,争いがあるのは,Corebankの採用が被告にとって法的拘束力のある義務であり,Corebankの採用を義務の履行として強制することができるか否かという点である。
この点,そもそも,原告がCorebankの採用を法的義務をもって定めたと主張する本件最終合意書自体に法的拘束力がない以上,原告の主張が失当であることはいうまでもない。
また,仮にこの点を措くとしても,前述のとおり,CorebankはNEFSS内部で呼び出されるAPIの集合体であって,ユーザの業務要件を実現することができれば,プロジェクトの状況に応じて,より適切なパッケージの採用の検討を提案することができるものである。
(エ) さらに,原告は,被告の主張について,「パッケージも当事者間で最終的には合意していなかったと主張しているのであるが,このような主張は単に失当であるのみならず,システム開発業者としては「非常識」かつ「無責任」極まりない」などと非難した上で,「システムに用いるパッケージは,システム開発の開始以前の段階において確定されなければならない」と断言する。しかしながら,本件システムの周辺サブシステムについても多数のパッケージが使用されているが,プロジェクトの開始時点では採用するパッケージが未確定のものがほとんどであり,要件定義の過程において使用するパッケージを確定していったのである。この客観的に明確な事実一つをもってしても,原告の「システムに用いるパッケージは,システム開発の開始以前の段階において確定されなければならない」という主張がITシステム開発における常識とかけ離れたものであることは明白である。このように,要件を定める過程でパッケージを定めることはあり得ることであり,要件に合わなければパッケージを変更することもしばしば見られることなのである。
(オ) 仮に,原告が主張するように本件最終合意書に法的拘束力が認められるという前提をおいたとしても,本件最終合意書の第7条には,スコープ等は本件最終合意書時点では定まっておらず,後に「最終化」することが明記されている。すなわち,本件最終合意を締結した時点では,本件最終合意書に添付された「『新経営システム』構築に関する基本合意書(添付)」(以下「本件最終合意書添付資料」という。)に記載された事項は,全ていまだ確定したものではなく,これから「最終化」するものであったことは疑う余地がない。そして,本件最終合意書添付資料には,開発スコープ及びサービスインの時期についてそれぞれ記載されている。
したがって,開発スコープ及びサービスインの時期が,本件最終合意の時点において確定しておらず,「今後さらに協議をして,最終化」するものであったことは一見して明白である。原告が,本件最終合意書締結時点において,開発スコープ及びサービスイン時期について確定的なものとして請負契約上の義務であったと主張することは,「今後さらに協議をして,最終化する」ものがその時点で既に「最終化」していたと主張していることになるであって,被告にはその不整合を合理的に理解することができない。
この点,原告は,被告の主張について,「システムが完成するまでは,開発スコープに関する合意は「最終化」しないとでもいうのであろうか。システム開発の専門業者たる被告が,システム開発を行うスコープに関して,システムが完成するまで一切法的義務を負わないなどという極めて無責任な主張が認められてはならない」などと論難する。
しかし,本件プロジェクトは,超上流工程である要件定義が終わった後,設計・開発に入る前に,費用負担,開発スコープ及びサービスインの時期について協議している途中で頓挫したものである。原告の主張は,本件プロジェクトが「システム開発に被告が失敗した案件」であるかのごとき印象を与える言い回しをしているが,実際には「どのようなシステムを作るのかといういわば『入り口』のところで原告被告間の協議が決裂し,システム開発に着手できなかった案件」であるという客観的事実に反している。また,被告は,要件定義と外部設計が終わらなければ費用もスコープも期間も確定できないという一般論を前提に,本件最終合意が締結された時期は要件定義が始まったばかりの時期であった以上,費用,スコープ及び期間が確定できる客観的状況にはなかったこと,及び要件定義が終わった後である平成18年9月以降,費用,スコープ及びサービスイン時期について協議が続けられていたことから,それらが確定した事項ではなかった,という当たり前の主張をしているのである。
したがって,原告が,被告が「システムが完成するまでは,開発スコープに関する合意は『最終化』しない」などと一見して不合理な主張をしているかのごとき印象を与えた上で,被告の主張が不合理であると非難してみても,全く無意味である。
(カ) 次のaないしdのとおり,本件最終合意書に記載された開発費用は,いかなる意味でも原告の主張するような法的拘束力を有するものではない。
a 原告は,システム全体の開発費用を何ら合意することなく,全て各フェーズの個別契約に委ねるということは,ユーザはもちろんベンダにとっても,合理的意思とはいえないなどと主張する。しかし,かかる主張は,本件最終合意書の記載はおろかシステム開発の実務を無視するもので,完全に失当である。
そもそも,上述のとおり,本件最終合意書8条は,「いずれの当事者も本合意書に基づき何らの法的義務を負わない」と規定して,明確に法的拘束力がない旨を定めており,一流の大企業同士である原告及び被告が明示的にこのような合意をした以上,当事者の合理的意思の解釈と称して文言に反する解釈をすることは許されない。
仮にこの点を措くとしても,システム開発の局面ごとに個別契約を締結して契約関係を積み重ねていくという多段階契約の形式は,システム開発において一般的な実務となっている。特にある程度以上の規模のシステム開発においては,委託料,作業期間及び納期,成果物等を個別契約において定めるのが一般的であり,かかる実務は経産省モデル契約においても採用されている。
システム全体の開発費用を基本合意書等で合意することなく,各開発工程の個別契約においてそれぞれ委託料を定めるという多段階契約の方式は,ベンダのみならずユーザにとっても大きなメリットが存する。原告は,開発費用の上限を定めない場合は,予算の抑制が効かず業務委託費用が際限なく増える確率も高まり,結果としてプロジェクトが失敗する確率が高まることから,ベンダにとっても望ましくないなどと主張するが,これは,言い換えれば,プロジェクトの初期に不確定な見積りに基づき開発費用を確定額として合意した場合,プロジェクトの進展に伴って不可避的に生ずる開発費用の増額を全てベンダに負担させればいいというユーザ本意の一方的な契約解釈であり,このような解釈をされることこそがベンダにとって望ましくないから,特に大規模なシステム開発において多段階契約の方式が採用されるのであり,本件でも本件最終合意書が法的拘束力を有しないことを改めて確認するものとして締結されたのである。
b 一般に「一括契約」といっても,それはあくまでも要件定義後の開発についての一括契約であるという点に留意する必要がある。原告も,プロジェクト開始前に締結された本件基本合意書①又は同②によって一括契約が成立したと主張しているのではなく,要件定義が9か月行われた後に締結された本件最終合意において,以後の開発作業について一括契約が成立したと主張している。
要件定義が終了(原告の主張では完全に終わらないまでも実質的に終わった段階であれば足りるとするようである。)する前に一括請負契約が締結されることは全く想定されていないのである。つまり,原告も,要件定義前の「見積り」が確定見積りでないことは争っておらず,本件では,本件最終合意書の段階で行われた見積りは「確定見積り」であって,拘束力があるものであると主張しているにすぎない。そうすると,この点に関する争点は,結局,①客観的状況において要件定義が実質的に終わっており「確定見積り」といえる状況であったかどうか,②仮に要件定義が実質的に終わっている客観的状況にあったと仮定して,それが法的な拘束力を持つ「確定見積り」として合意されたかの2点である。
c 本件最終合意書が締結された平成17年9月末の時点では,現行分析の作業の最中であり,要件定義の作業は同年9月初めから開始されたばかりであったことは一目瞭然である。この点に関し,原告は,「2段階の合意を行う予定であった」とするばかりであり,当初の予定と異なり要件定義の作業が遅れ,見積りを行う客観的状況になかったことについて,有効な反論をなし得ていない。
また,原告は,平成12年から行われた原告の予備的検討から本件基本合意①及び本件最終合意の締結に至るまでの経緯から,被告が「開発費用の見積りに必要な基礎データを十分に把握した上で,本件最終合意書において89億7080万円という開発費用に合意した」旨主張する。しかし,原告が行った本件プロジェクトに至る予備的検討の中で,被告が原告の作業に関与していたのは,原告が導入する次期システムにおいて新たに実現すべき項目(「変革のテーマ」)の洗い出しの検討に当たっての戦略的コンサルティング作業が中心であった。そして,その検討については,被告は原告から対価を一切受領していないのであって,被告としては,原告の次期勘定系システムの構築においてベンダとなれるよう営業活動の一環として関与していたにすぎない。また,かかる「変革のテーマ」において現行のビジネス及びシステム上の業務・機能の要件についてはほとんど検討の対象とされなかったのが現実である。そして,このような原告の現行のビジネス及びシステム上の業務・機能要件の調査に莫大な時間と労力を要し,また,原告が現行のビジネスの変革に消極的態度を示し,また現行システムの機能に固執した結果,本件システムの開発規模,開発費用等も大幅に増加することとなった。
このような経緯にかんがみれば,本件プロジェクト開始時において締結された本件基本合意①はもちろん,いまだ現行システムの分析の最中であった本件最終合意の締結段階においても,被告において開発費用の見積りに必要な基礎データを十分に把握していたといえる状況にないことは明白であり,原告の主張は前提を欠くのである。
d 前記ア(ク)に記載のとおり,本件最終合意書における開発費用の額が法的な拘束力を持つ「確定見積り」として合意された事実はない。
(キ) 原告は,本件最終合意書において,あるいはプロジェクト開始当初から,被告が本件本質的義務として本件システムの開発スコープ及びサービスイン時期についても法的義務を負っていたと主張するが,この点についても,上記の開発費用と同様の議論が妥当し,原告の主張が失当であることは明らかである。すなわち,原告の主張は,①本件最終合意書において開発スコープ及びサービスインの時期が「今後さらに協議をして,最終化する」と合意されていること,②乙31において,平成18年12月に,原告と被告の担当者がスコープの調整について協議を重ねていたという事実が存在すること等を無視したものであり,それこそ「後付け」の議論にすぎない。
また,甲7号証には,①「合意書時点の計画」「合意書時点での対象業務」として本件最終合意書添付資料に記載されたサービスイン時期及び開発スコープが記載され,②そして,それについてBRDを経た後に行った費用の見積りが記載され,③当該見積りを踏まえての現実的な開発スコープ及び費用負担額が記載されている。かかる記載から,甲7号証は,本件最終合意書7条で「今後さらに協議をして,最終化する」と合意されたサービスイン時期及び開発スコープを記載した上で,その「協議」の一環としての「最終化」案を提案したものであることは一見して明らかである。
ところが,原告は,②をもって「本件プロジェクトが開始されて約2年が経過した時点でもなお,開発スコープは,本件最終合意書において合意した開発スコープと『変わらず』としている」から,BRD終了後においても被告が開発スコープを本件最終合意書締結時点と「変わらず」と認識していたなどと主張するのであって,証拠の評価を誤っていることは明白である。むしろ,甲7号証によれば,費用負担額,開発スコープ及びサービスインの時期について「協議」が行われていたことが明らかなのであって,開発スコープ及びサービスイン時期が本件最終合意書締結時点で「最終化」した確定的な合意ではなかったことを雄弁に物語っている。
(ク) 原告は,被告が本件最終合意書のみならず,本件個別契約に基づき本件本質的義務を負う旨主張する。しかし,本件個別契約それぞれにおける被告の債務の内容は,本件システムを完成させるべき請負契約上の義務とは全く異なるものであり,失当である。
ウ 本件本質的義務の債務不履行
Corebankの採用が不可能になったこと,及び被告がCorebankの採用を断念したことに関する原告の主張はいずれも全く理由がない。
プロジェクト開始当初に予定されていたとおり,要件定義により何を作るのかが決まったところで見積りを行い,それに従って両者が協議し,費用の一部負担(95億円+20億円),周辺系に関するスコープ調整及びサービスイン時期について原告の協力が得られていれば,あと1年から1年半でCorebankを採用し本件システムを構築することは十分可能であった。そうでなければ,被告が,平成19年1月に,20億円の負担をすれば開発ができるから契約を締結するように要求したはずがないし,その時点で契約が締結されていれば,システムは完成していた。
TCBの提案は,原告が,被告によるこれらの提案に対し誠実に交渉に当たらず,不合理に強硬な姿勢で「交渉」を行い全く協力する姿勢を見せなかったことから,何とか本件システムを完成させるための別のソリューションとして,Corebankとの選択的な追加提案として行われたものである。
原告は,TCBの提案をもって被告がCorebankの採用を断念したという仮定の上に立ち,プロジェクトが開始され約2年7か月が経過した後に,突然,Corebankを採用することはできないと言われ,被告に対する信頼を完全に失ったとか,システム開発において最も重要なベンダたる被告とユーザたる原告との間の『信頼関係』が完全に崩壊したなどとする。
しかし,「信頼関係」が崩壊したというのであれば,原告は,被告が本件プロジェクトによりNEFSSを完成させられることを前提に100億円を超える巨額の投資を行っていることを知って,「何らの法的義務を負わない」と明記され,「今後さらに協議して,最終化する」と明記された費用負担額,開発スコープ及びサービスイン時期に拘泥し,既に契約がなくなっていて被告としては開発体制を維持することができなくなっているにもかかわらず,不合理に強硬な態度をとり続けて被告に全てを押しつけようとしたものであって,平成19年1月に被告が強く要請した契約の締結ができなかった時点で,「信頼関係」が崩壊し,実質的に本件プロジェクトは頓挫していた。
(2)  争点(2)(本件プロジェクト中止の原因及びその責任の所在)について
(原告の主張)
ア Corebankの無謀な選択
システム開発委託契約を締結する際,システム開発の専門業者(ベンダ)は,発注者(ユーザ)の要望にかない,かつ,実際にシステムの実装段階で採用することが可能なアプリケーション・パッケージを選択し,それをユーザに提案しなければならない。システム開発の専門業者たるベンダが,実際にシステムに採用することが不可能なアプリケーション・パッケージを選択し,それをユーザに提案して,開発委託契約を獲得することが許されないのは至極当然のことである。
被告は,システム開発専門業者である以上,欧米で利用されているCorebankの機能がどのようなものであり,Corebankは,特有の業務が多々ある日本の銀行業務を支えるシステムのパッケージ足り得るのかなどを十分に吟味,検討し,Corebankの著作権を保有するFIS社との権利関係を適切に処理し,結果,Corebankを採用することが確実に可能であることが確認できた段階で初めて,Corebankを選択し,ユーザである原告に提案しなければならなかった。
それにもかかわらず,被告は,この吟味,検討を十分に行わず,かつ,FIS社との権利関係の処理も行うことなく,「見切り発車」的にCorebankを選択し,原告に対しては採用することが可能なものとして積極的に提案した。
そして結局,本件プロジェクトが開始されて約2年半が経過した後に,Corebankの採用が事実上不可能であることが明らかとなり,本件プロジェクトは頓挫した。
以上からすれば,被告は,Corebankを採用することができない可能性があることを認識しながら,それを原告に提案したのであり,かかる提案は「杜撰かつ無謀」なものといわざるを得ず,被告は,結果(損害)の発生を少なくとも未必的に容認していたといわざるを得ない。この意味で,被告には(未必の)故意が認められる。また,被告は,情報システム開発の専門業者であるにもかかわらず,システムに採用できないかもしれないという事情を認識しながらあえてCorebankを選択し,提案して,結局,Corebankの採用ができなかったのであるから,少なくとも重過失が認められる。
イ プロジェクト・マネジメント義務違反
(ア) システム開発業者は,専門業者として,自らが有する高度の専門的知識と経験に基づき,ユーザとの合意に従って,システムを構築し,完成させる義務を負う。
したがって,システム開発業者は,納入期限までにシステムを完成させるように,ユーザに提示し,ユーザとの間で合意された開発手順や開発手法,作業工程等に従って開発作業を進めるとともに,常に進捗状況を管理し,開発作業を阻害する要因の発見に努め,これに適切に対処すべき義務を負う。そして,システム開発は,ユーザと打合せを重ねて,その意向を踏まえながら行うものであるから,開発業者は,ユーザのシステム開発への関わりについても,適切に管理し,システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユーザに働きかける義務(以下,これらの義務を総称して「プロジェクト・マネジメント義務」という。)を負っている。
(イ) 次の事実によれば,本件において被告にプロジェクト・マネジメント義務違反が認められるのは明白である。
a 本来,計画・要件定義#2においてパッケージ・ベース・アプローチを採用し,Corebankを有効活用するとともに,邦銀標準となり得るシステムの要件定義を完成させることが被告の義務であったにもかかわらず,被告はこれに失敗した。被告は,計画・要件定義#2では誤った開発手法である現行踏襲型アプローチ(カスタマイズ・ベース・アプローチ)を採用してしまい,グローバルIBMの指摘によりパッケージ・ベース・アプローチで旧BRDを実施するよう命ぜられた。
それにもかかわらず,被告は,旧BRDも現行踏襲型アプローチになっているとの指摘を再度グローバルIBMから受けてしまい,再度BRDのやり直しが必要になって新BRDの実施を余儀なくされた。被告は,上記のような開発手法の誤りにより,要件定義作業のやり直しを都合3回にわたって行うことを余儀なくされ,本件プロジェクトを迷走状態に陥れたのであるから,被告がプロジェクト・マネジメント義務に違反したことに疑念を容れる余地はない。
b 被告は,①被告とFIS社との契約交渉が難航しているのであれば,可及的早期に合意が形成できるよう対処し,②それに関してユーザである原告が決定すべき事項があれば具体的に課題と期限を示し,③複数の選択肢がある場合は利点と課題を示し,原告が必要な時期までに決定できるように導く義務を負っていた。
しかしながら,被告は,旧BRDの開始時も,また4段階サービスインを申し入れてきた平成18年8月以降も,原告に対してFIS社との関係については一切具体的な説明をせず,事後的に謝罪をして新BRDを実施せざるを得ないことを承諾させたり,サービスイン時期や開発スコープの見直しについて度重なる申出を繰り返したにすぎない。
これでは,原告としては,本件プロジェクトが混迷している真の原因を知らされていないのであるから,挽回策の検討も協力もしようがない。その結果,本件プロジェクトは頓挫することを余儀なくされたのである。
したがって,被告は,少なくとも平成18年2月以降,FIS社との役割分担及び開発スケジュール等に関する交渉が難航していたにもかかわらず,この事実を原告に対して適時に開示して,当該リスク情報を共有し,原告と共同して当該リスクに対処しなかったことは明らかである。被告の当該行為は,プロジェクト・マネジメント義務の懈怠に当たる。
c プロジェクトマネージャーは,一般に組織の資源をプロジェクト活動に使用する権限を与えられ,プロジェクト達成の責任を持つ,プロジェクトの要となる要員である。プロジェクトマネージャーはプロジェクトの初期に任命され,プロジェクトが終結(完了)するまでその任に当たる。プロジェクトの遂行には困難が伴い,開発期間全体で首尾一貫してマネジメントしてゆく必要がある。
しかし,本件プロジェクトにおいては,プロジェクトマネージャーが度々交代し,特に新BRD以降は頻繁に交代した。特に,被告の開発手法の誤り(本件プロジェクトはパッケージ型システム開発であるにもかかわらず「カスタマイズ・ベース・アプローチ」の開発手法を適用してしまったこと)が失敗であるとグローバルIBMにより指摘されてから以降は,グローバルIBMが突如として開発に参画してくるようになり,被告とグローバルIBM間での責任分担が不明確になって,適切なプロジェクト・マネジメントが実施できない状況に陥ったと考えられる。
また,システム開発は,ユーザがシステムで実現したいことやユーザの業務内容をベンダの開発担当者に対して説明し,「知識の移転」を行う作業である。そのため,開発要員に交代があると,再び最初から説明を実施する必要があり,開発上非効率である。特に,開発開始から時間がたてばたつほど,多くの知識を再度短時間で移転させることが必要になるため,要員の交代は作業効率を著しく損なうことになる。要員調達は,必要な要員が必要な時期に投入され,作業が終了したら離任するというのが基本である。上記のようなシステム開発の特性から,要員の交代は開発の遅れや費用の増加を招く。
被告は,この点でもそのプロジェクト・マネジメント義務に違反した。
d 本件プロジェクトのように大規模なパッケージを用いた基幹システムの開発プロジェクトにおいては,パッケージのカスタマイズに関する作業量,作業期間,費用が大きなものとなるため,カスタマイズ作業を適切に実施できる体制が整えられているか否かがプロジェクトの成否に直結する重要なポイントである。開発プロジェクトの中心的な,かつ最も難易度が高い作業は,パッケージのカスタマイズ作業だからである。
汎用的に作られているパッケージを特定の企業向けに適合させるには,対象となるパッケージについての相当なノウハウの蓄積が必要となる。パッケージ全体について,企業に適合するように機能の組合せを決めるときには,パッケージを熟知している優秀なSEでも矛盾を避けられないことが多い。このため,パッケージを活用してシステム構築を行う場合には,対象となる業務及びパッケージを熟知しているパッケージ業者がプロジェクトに参加することが絶対条件となる。
したがって,本件プロジェクトにおいても,平成16年9月のプロジェクト開始当初から,本件プロジェクトの主要メンバーとしてFISの要員を本格的に参画させておくべきであった。このような適切な体制を組むことも,システム開発のプロであるベンダがプロジェクト・マネジメント義務の一つとして負う義務である。
Corebankを最もよく知るFIS社の要員がプロジェクトの当初から本格的に参画する体制が組まれていれば,Corebankの機能を考慮することなく,原告の現行システムのリバースエンジニアリングを実施し,著しく詳細な現行システム調査を行ってまでカスタマイズ・ベース・アプローチを採用するという基本的かつ致命的な過ちを犯すことは避けられた。
Corebankに真に精通した者が参画していれば,被告が採用した開発手法で作成される要件定義書の内容がCorebankと著しく乖離したものになることは容易に予想できることであり,それよりもCorebankのカスタマイズ量を極力削減することが可能なパッケージ・ベース・アプローチを採用したであろうことが蓋然的だからである。
以上からすれば,被告がカスタマイズ・ベース・アプローチという誤った開発手法を採用してしまったのは,被告の本件プロジェクトに参画したメンバーにCorebankに精通した者がほぼ皆無だったことによると考えられる。Corebankの機能を熟知していなければ,Corebankの機能を前提として,それとユーザの要望とに係るFIT/GAPを分析する作業などできようはずがないからである。
よって,この点でも,被告にはプロジェクト・マネジメント義務違反が認められる。
なお,被告は,FIS社の要員がプロジェクト開始当初から参画しなかった問題について,本件プロジェクトはNEFSSプロジェクトの一部の個別プロジェクトにすぎず,そのためFIS社の要員を参加させないのは当然のことであったと主張している。
この主張が本件訴訟のための後付けのものでなく,本件プロジェクトの当時からこのように考えていたとすれば,それこそが本件プロジェクトを頓挫に導いた最も重要な原因というべきである。被告は,本件プロジェクトとは別個独立のプロジェクトとしてNEFSSプロジェクトなるものが存在し,本件プロジェクト以外にもNEFSS/Corebankを用いるプロジェクトが存在していたかのごとく主張しているが,事実に反している。本件プロジェクトこそが邦銀標準の勘定系パッケージとしてNEFSS/Corebankを完成させるための唯一のプロジェクトであった。したがって,本件プロジェクトにFIS社の要員を参画させなければ,他に参画させる場などなかったのである。そして,被告が現行踏襲型アプローチという誤った開発手法を採らざるを得なかった原因は,Corebankに精通した者が本件プロジェクトに参画していなかったという点にある。FIS社の要員が参画せずに行われた旧BRDがグローバルIBMの指摘により中止を命ぜられ,FIS社の要員を参画させて新BRDをやり直さざるを得なかったことから明らかなように,パッケージ・ベース・アプローチで行うためには,本件プロジェクトの開始当初からFIS社の要員を参画させておくことが必要不可欠だったのである。
e 本件プロジェクトにおいては,米国製のCorebankという海外パッケージを邦銀初の試みとして採用することとされた。そのため,Corebankと邦銀の業務との間にはビジネス(業務プロセス)の考え方にかなり相違があること,邦銀の業務に対するCorebankの乖離(GAP)がかなり大きいことは必然であり,大規模なカスタマイズが必要となることは事前に分かり切ったことであった。
このような状況にあっては,ベンダである被告には,コーザである原告及びFIS社などの利害関係者との利害関係を調整し,かつ協力して本件プロジェクトを推進させるという高いマネジメント力及び折衝力が求められる。しかも,本件プロジェクトにおいては,被告には改変権がなく,FIS社のみがこれを有していたのであるから,FIS社との利害調整をうまくマネジメントすることは必須の条件であった。FIS社との役割分担等の調整がうまくいかず,FIS社がカスタマイズを行わないという状態に至れば,Corebankを採用することができず,本件プロジェクト自体が頓挫するという事態に至るからである。
しかるに,被告は,開発手法の誤りによる度重なる迷走などによって原告との間の「信頼関係」を崩壊させ,FIS社との間の役割分担等の協議も失敗し,その結果,本件プロジェクトを頓挫させた。被告は,原告及びFIS社との役割分担等の協議,調整に失敗し,本件プロジェクトを頓挫させたのであるから,被告にプロジェクト・マネジメント義務違反が認められ,その責任を負わなければならないのは当然の帰結である。
f 被告がCorebankの改変権を有していないこと及びCorebankがFIS社という海外ベンダの提供によることに起因して生じるリスク(FIS社との協議が失敗すればプロジェクト自体が頓挫してしまうリスク等)を原告に対して一切説明しなかったことも,重大なプロジェクト・マネジメント義務違反を構成する。すなわち,システム開発プロジェクトにおいては,リスクマネジメントもプロジェクト・マネジメントに含まれるところ,被告は,上記のリスクを原告に開示し,これに対する適切な対応策を講じること(リスクマネジメント)を一切しなかった。そして,結局,このリスクが顕在化して本件プロジェクトは頓挫したのである。この点が被告の説明義務違反を構成するのと同時に,重大なプロジェクト・マネジメント義務違反をも構成するのである。
また,被告は,本件プロジェクトが頓挫する直前になってFIS社等の「外部依存関係の評価」を行い,FIS社の開発能力に疑問を呈している。これは,本件プロジェクトが開始される前にCorebankの提供者であるFIS社に関するリスクを検討していなかったことを明確に示しており,リスクの高い海外パッケージの採用を予定していた本件プロジェクトにおいては,致命的な過ちである。
g 以上のとおり,被告には重大なプロジェクト・マネジメント義務違反が認められ,その結果,本件プロジェクトが頓挫に至り,原告に多大な損害が生じたのは明らかである。
ウ 協力義務違反の不存在
原告には本件プロジェクトについての協力義務違反があるという被告の主張については争う。この点に係る被告の主張,反論は,断片的な証拠を誇張ないし誤用して作り上げたフィクションにすぎない。
(ア) 20億円の追加負担の交渉に関する協力義務違反
本件最終合意書の変更契約をめぐる交渉の経緯からすれば,原告は,被告のいうように「強硬な姿勢で交渉を続ければ被告は必ず折れる」などと考えて交渉していたわけでもなければ,C代表取締役専務(肩書は当時。以下「C専務」という。)らの「責任回避」のために交渉を行っていたわけでもない。原告は,ときにはハードに交渉しながらも,本件プロジェクトを何とか軌道に乗せようとする一念で誠実に交渉を行っていた。
仮に,被告が,「原告が追加して20億円を支払えば,本件システムが完成する(20億円以上追加負担が発生しない)」ということを合理的な根拠をもって説明していれば,原告は喜んで支払うと言ったはずである。しかしながら,被告が開発手法を誤り,かつ,自らの約束を簡単に反故にするなどして本件プロジェクトが混迷を極めていた当時の状況にあっては,原告からすれば,「もはやIBMの言うことは容易には信じられない」「IBMの提案を鵜呑みにすれば,再び失敗を繰り返すことになるのではないか」と考えざるを得ない状況にあった。
これは,それまでの被告の態度に照らせばやむを得ないことであり,原告がこのように考え,慎重に20億円の追加負担についての根拠を検討する姿勢をとったことをもって原告に協力義務違反という法的責任を負わせるのは,明らかに公正を欠くものである。
(イ) 商品数,帳票数の削減に関する協力義務違反
原告は,本件最終合意を締結する際に95億円という金額の前提とされた商品数(融資は898商品,預金は19商品)まで,BPRにおいて削減を行ったし,新BRDの結果,新たにCorebankには機能がないと判明した商品やサービスについて,廃止したり,Corebankの機能に沿うように変更したりした。
また,原告は,帳票数についても,95億円という見積りの前提とされた数(1618個)まで,これを削減した。
(被告の主張)
ア Corebankの無謀な選択について
Corebankの選択に関する原告の議論は,NEFSSとCorebankを混同したものであり無意味であるし,被告には,Corebankの選択に関する義務に違反した事実がないことは,前記(1)(被告の主張)欄ウ記載のとおりである。
イ プロジェクト・マネジメント義務違反について
(ア) 計画・要件定義#1・2の後,旧BRD及び新BRDを実施したが,それは要件定義をやり直したものではない。すなわち,それぞれの作業を極めて簡略化していうと,要件定義は,現行の業務及びシステムをベースに,どのようなシステムを作るのかを定義したものであり,BRDは,まず邦銀標準の業務フローが何かを確定し(旧BRD),その業務フロー及び要件定義書とCorebankとのFIT&GAPの作業を行ったもの(新BRD)であって,繰り返しが行われていないことは客観的に明らかなのである。
当初平成17年9月あるいは12月までに終了する予定であった要件定義の作業が,平成18年3月末まで,BRDまで含めれば同年8月末までかかったことは事実であるが,やり直しをした事実はないのであって,原告の認識はこの点において根本的に誤っている。
(イ) 本件プロジェクトの開始当初は,原告の現行の業務及びシステムを前提に本件システムを開発し,その中から邦銀標準を抽出する形で横展開することを想定していた。ところが,商品数や帳票数が当初の予定より大幅に増加するなど原告がプロジェクト推進に非協力的な態度を見せたことや,リバース・エンジニアリングを行ったりしたこと等が原因で見込まれるコストが大きく増加したことから,先に「邦銀標準」を確定し,それになるべく合わせる形で本件システムを開発することで,被告として投資できる額を大きくし,原告の費用負担額を抑えようとした。これを被告のプロジェクト・マネジメント義務違反と称することなどできないことは明らかである。
そもそも,要件定義を行う前に,現行分析を時間と費用をかけて行う必要が生じたのは,原告に現行の業務及びシステムについての資料も知識もなかったからであって,現行分析を行わざるを得なくなったことについて,原告が被告を非難するのは全くの筋違いである。
(ウ) そもそも,本件プロジェクトにおいては,平成18年3月末までに要件定義の作業が終了し,同年8月末にはBRDが終了している。そして,原告は,プロジェクトが頓挫した原因は,被告がFIS社との権利関係の調整ができなかったこと,あるいはCorebankが使い物にならないものであったためにCorebankを使用したシステム構築が不可能になったことにあると主張している。そうであるとすれば,BRD終了までに要件定義を3回繰り返したという原告の主張は,それを前提としてもプロジェクトを頓挫させた原因ではないことになるのであって,仮に,要件定義及びBRDが完了するまでの過程で,被告のプロジェクト・マネジメントには全く一貫性がなかったという前提の上に立ったとしても,要件定義及びBRDの作業の過程自体から生じた独自の損害があれば別論,そうでない以上,これを不法行為であるとして損害賠償請求することはできないのであって,原告の主張はそもそも失当である。
(エ) 原告は,FIS社との交渉が難航していた事実を適時に開示し,原告と共同してリスクに対処しなかったとか,FIS社との役割分担等の協議に失敗したことがプロジェクト・マネジメント義務違反を構成するなどと主張する。
しかし,後記ウ(イ)記載のとおり,原告は,NEFSSに莫大な投資を行っている被告が後に引けないことを知悉して,スコープについても費用負担額についてもいったんは合意するそぶりを見せながら,これを覆し,不合理に強硬な交渉態度に終始し,被告が要請する平成18年12月あるいは平成19年1月の契約締結を拒否して本件プロジェクトを頓挫させたのであり,上記主張は無意味である。
(オ) 被告側の体制に,様々な人材が投入されているのは,何とかプロジェクトを成功させようとする被告の努力の表れであり,キーとなる人材のほとんどが留任しつつ追加の人材が投入されていることからもそれは明らかである。
本件プロジェクトは,要件定義が進むにつれ,当初の想定よりも主としてコストの点に大きな問題を抱えていることが分かった。そこで,IBM AP(アジア・パシフィック)及び米国IBMの専門家がレビューを行い,被告と解決策を検討し,必要な人材を次々投入して成功させようとしていたのである。トラブル・リスクの予兆があれば,社内あるいはその上位組織のレビューが入ることはあらゆるベンダにおいて行われていることであり,そこでプロジェクトを停止したりせず,世界中から人材を投入したことをもって,プロジェクト・マネジメント義務を果たしていると評価されることはあっても,かかる義務の違反を指摘される道理はない。
(カ) 被告においては,本件プロジェクト開始よりも2年以上前からNEFSSプロジェクトが進行しており,原告の本件プロジェクトは,NEFSS/Corebankを使用した第1号案件であった。被告としては,銀行業を生業とする原告の勘定系システムの構築プロジェクトを通じて具体的な要件をNEFSS/Corebankに取り込み,NEFSS/Corebankを「横展開」可能なパッケージ・ソリューションとすることが企図されていた。そして,それにより,原告は,開発費用の一部のみを負担することでシステム構築が可能になるという利益を享受していたのである。
したがって,NEFSS内部で呼び出すCorebankについては,NEFSSプロジェクトにおいて,FIS社担当者と極めて密接に連絡を取り合ってJapanization等を行っていたのであって,個別プロジェクトである本件プロジェクトに,FIS社の担当者を参加させないことは当然のことであった。しかし,要件定義を行う過程で,想定よりもコストがかかることが見込まれたため,まずNEFSS/Corebankで実現する「横展開」可能な「邦銀標準」を確定し,それとCorebankの機能とのギャップを開発の中心とすることとしたため,その段階から,個別プロジェクトである本件プロジェクトにも,FIS社の担当者を直接関与させた方がよいと判断した。
したがって,当初からFIS社担当者が本件プロジェクトに直接関与していないことがプロジェクト・マネジメント義務違反を構成することはない。
(キ) Corebankの改変権については,改変権がないとしても改変を行うに適切な体制が組まれていたし,そもそもCorebankの改変権がないことがプロジェクト頓挫の要因ではないから,原告の主張はその前提を欠く。
ウ 原告には重大な協力義務違反がある
(ア) システム開発の作業は,ユーザとベンダの共同作業なのであって,ベンダがプロジェクト・マネジメント義務を負うことに対応して,ユーザにおいても,システム開発のために必要な協力を行うべき協力義務がある。
まして,本件プロジェクトは,被告が平成14年から100億円以上の投資を行いNEFSSの開発を進めていたところに,そのNEFSSの第1号案件として始まったものであり,本件プロジェクトを通じてNEFSSを「横展開」可能なレベルの商品とすることにより,原告は本件プロジェクトにおける開発費用の一部のみを負担することで足りるという利益を享受していた。そうでなければ,平成18年12月に費用負担の提案をした際に,20億円を原告の負担とし,100億円を被告の負担とすることなどあり得ない。このような性質を有する本件プロジェクトは,原告と被告の共同作業としての色彩は極めて強いのであって,原告の協力義務も,一般的な「システム発注者としてのユーザ」と「システム開発受託者としてのベンダ」という関係におけるユーザの協力義務より,高度なものが課せられていた。そして,このことを原告もよく承知していた。
(イ) それにもかかわらず,原告は,単なる「お客様」としての原告と「出入り業者」としての被告という程度を越え,本件プロジェクトが成功裡に終わらなければ110億円ものNEFSSへの莫大な投資が全て無駄になってしまうという弱みにつけ込んで,何でも被告に押し込むことで,何かを勝ち取ったかのような勘違いを続けていた。
具体的には,①要件定義の前提として必要な現行の業務及びシステムの分析の必要性を認めようとせず,資料すら満足に提供せず,②BPRにおいて商品数・帳票数の削減を行わず,③BRDの過程においても現行の業務に固執して帳票数の削減すら拒み,④現行の業務・機能に固執して開発スコープの調整等に応じなかった挙げ句,⑤「何らの法的義務を負わない」(第8条)ことが明記されており「今後更に協議」(第7条)をするとされている本件最終合意書の89.7億円という負担額,開発スコープ及びサービスイン時期に固執し,「自分たちはそれ以上払う事はないから何から何まで被告の作業に押し込んでしまえばよい。あとはベンダである被告が何とかすべきだ」などという不合理に強硬な態度に終始して,一切の妥協をしなかった。
そして,⑥要件定義終了後の見積りにより総開発費用が算出された際に,被告は,107億円分をスコープ調整等やスケジュールの変更等によりコスト削減した上で,被告が100億円を,原告が20億円をそれぞれ負担する案を提案した。当時,平成18年12月18日以降は原告被告間に契約が存在しなくなり,プロジェクトの開発体制を維持するためには,被告は回収できるのかの見通しもない中で下請会社の要員の費用の支払等毎月数億円の負担をしなければならない状況にあったのであり,原告もそのことは承知していた。それにもかかわらず,原告は,NEFSSに莫大な投資を行っている被告が後に引けないことを知悉して,スコープについても費用負担額についてもいったんは合意するそぶりを見せながら,これを覆し,不合理に強硬な交渉態度に終始し,被告が要請する平成18年12月あるいは平成19年1月の契約締結を拒否した。この点について,被告より提案された20億円の追加負担について拒絶したことなど一度もないとする原告の主張は明確に事実に反している。
原告は,常に被告と対峙する姿勢を見せ,例えば,被告が資料を要求すればそれが必要ではない旨を延々と論じて提供を拒否したり,現場で事実上合意ができたことをステコミに上程すると不合理にも拒否したり,ステアリング・コミッティに被告が提案をしただけでなぜそのようなものを突然持ち出すのかなどと被告を非難するなど,常に「どちらが悪いのか」という発想で物事を捉え,必ず責任が被告にあることを認めさせようとしていたのである。このような姿勢では,ユーザとベンダの共同作業であるシステム開発がうまくいくはずがない。
被告が主張するユーザの協力とは,このような原告の姿勢をいっているのであって,「顧客」である自分が強硬なポジションで交渉をすれば,「業者」でありNEFSSに莫大な投資をしており原告が本件プロジェクトから降りればその投資が水泡に帰すことになる被告は必ず折れると原告が信じていたのだとすれば,それ自体が違法行為であったと評価されるべきものである。
(ウ) 以上のとおり,原告には,協力義務違反が認められるから,プロジェクト頓挫についての帰責性を論ずるとすれば,それは原告の責めに帰すべき事由による。
本件プロジェクトは,要件定義及びBRDの作業により何を作るのかが定まった後で,当初から予定されていたとおり見積りを行い,スコープ,費用及びサービスインの時期について協議をしたが,原告がこれを頑として受け入れず,設計・開発作業を被告に発注しなかったために頓挫したのである。
なお,原告は平成19年4月18日に被告がCorebankの代替案としてTCBの採用を提案し,Corebankを採用して本件システムを完成することができなくなったことをもって本件プロジェクトが頓挫したと捉えているが,本件において,同日当時Corebankの採用は可能であり,現在においても可能であって,原告の主張には理由がない。
エ 定量的分析による本件プロジェクトの頓挫原因
(ア) NEFSS/Corebankの機能の充足度
NEFSS/Corebankを被告が提案した際に,原告のいう邦銀の勘定系システムにとって必要な機能を充足しない「使い物にならない」パッケージであり,被告がNEFSS/Corebankの機能充足度を見誤っていた旨の主張は,仮に妥当するとしても,わずか15.4%についてのものにすぎないのであり,したがって,使い物にならないパッケージであり,被告がNEFSS/Corebankの機能充足度を見誤っていたという結論を導くような割合ではないのであるから,これがプロジェクトの頓挫原因であるとするのは,全くの誤りである。
(イ) 開発フェーズのコストの見積りが増大した原因
本件プロジェクトは,開発フェーズに係るコストの見積りが105億円から226億円に増加した原因について,定量的分析をすると,邦銀標準のパッケージを作るための費用の増加が被告側,銀行によって内容が異なる要件及び原告独自の要件を開発するための費用の増加が原告側という,本来在るべき分類によれば,原告側に原因があるものが91.96億円(82.85%),被告側に原因があるものが19.04億円(17.15%)となる。そうすると,82.85%という圧倒的な割合で,原告側の原因によって見積りが増加しているし,仮に,本件最終合意書締結後に新たに判明した要件のみが原告側の原因によるものだという前提に立ったとしても,なおも56.32%という過半の割合が,原告側の原因によって開発フェーズのコストの見積りが増加したためである以上,本件プロジェクトが頓挫した責任がもっぱら原告にあることは明らかである。開発フェーズのコストの見積りが増大した原因の責任の一部が仮に被告側にあったとしても,原告に責任があるか,被告に責任があるかという意味では,本件プロジェクト頓挫の責任は被告にはなく,原告にある。
しかも,極めて重要なことに,Corebankの機能の充足度の不足なるものは,19.04億円のことをいっているにすぎない。原告は,見積り全体のわずか8.81%,見積りの増加額でいっても17.15%にすぎない要因を指して,これがコスト増加の最大の要因でありプロジェクトが頓挫した本質的原因であるなどと主張し,客観的な事実に反する事実認定を求めていることになる。
(3)  争点(3)(本件個別契約の債務不履行解除の成否)について
(原告の主張)
前記前提事実(9)セ記載のとおり,原告は,平成19年7月18日,被告に対し,被告の債務不履行を理由として,本件最終合意書及びこれに関連する全ての本件個別契約を解除する旨の意思表示をした。
(被告の主張)
原告は,Corebankの採用に関する善管注意義務違反,説明義務違反及びプロジェクト・マネジメント義務違反に基づき,本件個別契約全部の解除を主張している。
しかしながら,契約の目的を達成するのに必須とはいえない付随的義務の違反が契約の解除原因とはなり得ない。すなわち,かかる付随義務の不履行があったとしても,本来的かつ主要な債務の履行が完了していれば,本旨履行が行われている以上,契約を解除することはできない。
これを本件についてみるに,各本件個別契約は,それぞれ,本来的かつ主要な債務として独自の成果物の納入義務やサービスの提供義務を定めており,これらの債務こそが各本件個別契約の契約金額と対価性を有するものであり,これらの義務が被告により履行され,原告が検収を終えていることは争いがない。
したがって,本件各個別契約の解除は認められない。
(4)  争点(4)(説明義務違反の有無)について
(原告の主張)
ア 専門業者とそうでない者が契約を締結する際,専門業者は,相手方当事者の知識,経験,能力等に応じて,当該取引により生じ得る利害得失を判断するのに必要かつ適切な情報(リスク情報も当然含む)について説明する信義則上の義務を負う。これは,高度かつ複雑な専門知識及び技術が必要となるシステム開発についても等しく当てはまることであり,システム開発業者は,専門家として,システム開発において生じ得る利害得失を判断するのに必要かつ適切な情報(リスク情報も当然含む)を,ユーザに対して説明する信義則上の義務を負う。
そして,システム開発の専門業者たるベンダは,パッケージを用いたシステム開発に際しては,パッケージの選定に当たって,パッケージの機能,性能,設定・導入の容易性,導入実績,パッケージの提供者(パッケージベンダ。本件でいえばFIS社。)の導入実績,経営の安定度,技術力,カスタマイズへの積極性その他関連する諸事情を総合的に考慮して,ユーザが構築しようとしているシステムに最適なパッケージを選定し,提案しなければならない。仮に選定したパッケージが,ユーザの構築しようとしているシステムに適合しなければ,それを前提とした費用,スケジュール,開発体制その他一切の開発計画が無意味なものとなる。したがって,ベンダは,ユーザに対する提案前に様々な観点から十分なリスク分析を含めた検討を行う必要がある。
ベンダは,このような検討を行った上で,リスクについて十分にユーザに説明し,リスクの存在及び内容を理解させた上で,ユーザに最終的に当該パッケージを採用するかを判断させなければならない。ベンダはシステム開発のプロであり高度の専門的知見を有するのに対し,ユーザはこの点では素人であり,特にパッケージの機能等に関する予備知識がほとんどないことが通常だからである。
すなわち,ベンダは,ユーザに対して,導入の可否に関する判断の機会を与えるために,専門家として,当該パッケージの選定のリスクに関する説明義務を契約上の責任として負うのである。
イ 大規模なパッケージを用いた基幹システムの開発プロジェクトを行う場合で,かつ,日本において導入実績がない海外のパッケージを初めて日本において導入するような場合,ベンダは,改変権の有無,(改変権がない場合には)パッケージベンダが自ら行うカスタマイズに協力的か否か,パッケージベンダの能力,評判,開発拠点の分散の有無その他パッケージに関する諸事情を総合的に検討して,慎重にリスク分析を行い,リスクに対する対応策を検討しなければならない。
そして,これらの検討を経た上で,ベンダは,当該海外パッケージに関連するリスクをユーザに対して十分に説明して対応策を協議し,当該リスクを十分に理解させた上で,ユーザに当該パッケージを採用するかどうかの意思決定をさせなければならない。仮に,ベンダが,改変権を有しておらず,パッケージの改変はパッケージベンダに依存せざるを得ない状況であるにもかかわらず,ベンダが,ユーザに対して,当該リスクを説明し,十分理解させ,かつ,リスクへの対応策を協議した上で,ユーザに当該パッケージの採用を意思決定させてプロジェクトを開始しなかった場合,当該ベンダは,当然,説明義務違反の責任を負わなければならない。
ウ 以上を本件についてみるに,Corebankは,これまで日本において導入実績がなく,かつ,海外のパッケージベンダであるFIS社から提供を受ける予定であった。また,開発の対象となるシステムが邦銀の基幹システムという極めて大規模なものであったことから,Corebankに加えるカスタマイズの規模は大規模なものが予定されていた。
それにもかかわらず,Corebankについて改変権を有するのはFIS社のみであって,被告はFIS社にCorebankの改変を「要求」することができるのみであった。かかる状況にあっては,Corebankのカスタマイズは,FIS社に対して全面的に依存せざるを得ないのであり,FIS社が承諾しなければCorebankの改変を一切実行することができない。
したがって,被告とFIS社との間で役割分担や開発スケジュール等についての交渉や調整が不調となった場合,Corebankのカスタマイズができないということになり,これを基盤に据えて本件システムを構築することが不可能となって本件プロジェクト自体が頓挫するという重大なリスクが存在した。加えて,FIS社が海外のベンダであることに伴うリスク及びその開発拠点もコペンハーゲンその他2か所に分散していたことに伴う開発の困難性,非効率性,不確実性といったリスクも存在していた。
Corebankの採用には,このような幾つもの重大なリスクが存在していたのであるから,被告は,ユーザである原告に対して,当該リスクを少なくとも本件プロジェクトが開始された本件基本合意①の締結前に十分に説明し,これを理解させ,万全な対応策を立てた上で,Corebankの採用を意思決定させなければならなかった。
仮に,被告がこのような説明をしていれば,原告としては,FIS社も契約当事者として三社契約を締結して,原告に対する法的義務をFIS社に直接負わせたり,本件プロジェクトの当初からFIS社が主体的に参画する体制の整備を被告との間の契約条件としたり,原告もFIS社との間で交渉したりするなど,リスクを低減する方策はいくらでもあったのである。
それにもかかわらず,被告は,原告に対して本件基本合意①を締結する前に一切の説明もせずに,原告をしてCorebankの採用につき意思決定をさせたのであるから,被告が説明義務違反の責めを負わなければならないのは当然である。
そして,結局,上記リスクが現実化して本件プロジェクトが頓挫したことからすれば,被告の説明義務違反は極めて重大であり,その責任は重いといわざるを得ない。
(被告の主張)
ア Corebankのようなパッケージ・ソフトにおいては,ソース・コードを改変する権利がパッケージベンダから第三者に付与されることは一般的ではなく,原告も,(「NEFSS」ではなくNEFSSを構成する「部品」の一つである)CorebankはFIS社が改変していることは認識しており,それが両当事者の当然の前提となっていた。被告に改変権がないことを知らなかった,ひいてはそれについての説明義務違反があるなどという主張は,それこそ後付けの主張である。
イ 一般論として,「大規模なパッケージを用いた基幹システムの開発プロジェクトを行う場合,プロジェクトにおいて中心的でかつ最も難易度が高い作業は,パッケージのカスタマイズ作業である」とする原告の主張は誤りである。
もっとも,NEFSS/Corebankは,本件プロジェクトを含む平成14年からの一連のNEFSSプロジェクトを通じて「パッケージ」として横展開可能なものを作ろうとしていたものであって,実際,被告とFIS社が協力してCorebankの「Japanization」(日本化),すなわちカスタマイズを進めていた。しかし,ユーザである原告から見えるのは,NEFSSというパッケージなのであって,CorebankはNEFSSの内部で呼び出される部品の一つにすぎない。
したがって,Corebankで実装できなければ,被告が,NEFSSライブラリとしてあるいは原告オリジナルのプログラムとして開発すればよい。単に,Corebankの機能を追加・修正して実装することと,被告が実装することのどちらが技術的・経済的に優れているかに基づいて,振り分けが行われるだけの問題である。
よって,そもそも,FIS社との関係が上手く調整できてCorebankが改変できるかどうかは,NEFSSを使用した本件システムの構築を不可能にならしめるようなリスクではない。
ウ CorebankではなくNEFSSで考える必要があるという点をひとまず措き,原告が主張するFIS社との関係について考えたとしても,次のとおり,原告が主張するような「リスク」が存在しなかった。
すなわち,①Corebankは元々IBMが開発を開始したソフトであり,かつ,被告は,原告にCorebankを紹介する約2年前からAlltel CS社(FIS社)と共同でCorebankのJapanizationの作業を順調に行うなど,被告は,Corebankについて十分な検討を行い,Corebankについて十分理解した上で原告にCorebankを紹介した,②NEFSS内部においてCorebankの機能の追加・修正を行うか,NEFSS側の開発を行うかは自由に決定できる事柄であること,③住信SBIネット銀行において,NEFSS/Corebankの勘定系システムが稼動していること,④被告とFIS社の間の権利関係や役割分担は適切に調整されていたこと,⑤NEFSS/Corebankの開発体制は最良のものであったこと,⑥FIS社が新BRDから前面に出るようになった開発体制は極めて妥当な体制であったのであり,リスクは存在しなかった。
エ 以上のとおり,本件プロジェクトにおいては,Corebankの採用に関するリスクなど存在しなかったが,仮にこの点を措くとしても,本件プロジェクトは,原告がスコープの調整や追加の開発費用の一部負担を不合理に強硬な交渉態度に終始して拒絶し続けた結果頓挫したのであって,原告が主張するように,FIS社との権利関係等の調整ができないというリスクが現実化したために頓挫したものではない。
(5)  争点(5)(錯誤の有無)について
(原告の主張)
ア 本件個別契約の全ては,Corebankの採用を大前提として締結されたものである。したがって,実際にはCorebankの採用が不可能であったということは,契約の重要な要素について錯誤があったことを意味する。
仮に,本件個別契約の締結に先だってCorebankの採用が不可能であることを原告が認識していたならば,Corebankの採用を大前提とする本件個別契約を締結することなどあり得なかったのは,議論の余地なく明白である。
イ 被告がCorebankをカスタマイズする権利を有していないということは,原告からすれば,約90億円もの巨額の委託料を支払って開発を委託する相手方が,自らはそのプロジェクトの核となるパッケージのカスタマイズを行う権限を有しておらず,契約外の第三者たるFIS社にこれを全面的に依存せざるを得ないということにほかならない。そして被告とFIS社が役割分担やスケジュール等につき合意できなければ,Corebankを本件システムに採用することができなくなり,本件プロジェクトは頓挫するという帰結が待っている。この状況は,原告にとっては,本件プロジェクトの成否が被告とFIS社の協議の成否という原告自身では全くコントロールできない事情によって左右されることを意味するのであって,何らの契約上の手当てなしには到底取ることができないリスクである。このような極めて重要なリスクがある中で,90億円前後にも上る巨額のシステム投資の意思決定をすることなどできようはずはないのである。
このように,被告がCorebankをカスタマイズする権利を有しているかという事情は,本件プロジェクトの成否と直結する極めて重大な事実であり,本件基本合意①,同②,本件最終合意及び本件個別契約の「要素」に当たる。
仮に,本件基本合意①の締結時点又は遅くとも本件最終合意の締結時点において,原告が上記のような重要な事実,すなわち被告自身はCorebankの修正作業を行う権限を有しておらず,FIS社のみがこれを行うことができるという事情を知っていれば,本件基本合意①,同②,本件最終合意及び本件個別契約を(少なくとも締結した内容で)締結していなかったことは明らかである。
ウ したがって,本件個別契約の全ては,要素に錯誤があったものであり,民法95条により無効である。
エ よって,原告は,錯誤無効に基づく原状回復請求権として,後記(6)(原告の主張)欄ア記載の65億5341万0847円の返還を求める。
(被告の主張)
ア Corebankを採用して本件システムを構築することは可能であり,また,Corebankの採用は本件個別契約の要素ではないこと等から,本件個別契約について,Corebankの採用の可否に関する錯誤など存在せず,この点にかかる原告の主張は失当である。
イ FIS社が改変権を有することは,原告被告間で当然の前提とされていたのであって,改変権がないことを知らなかったという原告の主張は「後付け」の主張であって,原告には錯誤などというものは存在しなかった。
また,仮にこの点を措くとしても,原告の主張は,Corebankの改変権を被告が有しないことがリスクであるとするものであるが,そもそも,パッケージを用いたシステム開発において,システムベンダがパッケージの部分を改変するということは,一般的ではないのであって,原告の主張はその前提が誤っている。むしろ,被告が,Corebankのアーキテクチャに最も通じたFIS社に対し,日本における銀行業務・商品に必要な要件を伝えて,FIS社がこれを実装するという開発形態が最も優れた体制であった。実際,NEFSSプロジェクトにおいて,被告は,FIS社と協力してCorebankのJapanization等を進めていた事実が存在するのであり,原告のいうリスクは存在しなかった。
(6)  争点(6)(原告の損害)について
(原告の主張)
原告の損害は,次のアないしウを合計した115億8022万1302円であり,本訴においては,このうち115億8000万円の損害賠償を求める。
ア 実損害① 65億5341万0847円
本件システムを構築するための費用として被告に対して支払った金額のうち,原告が現に使用している製品等の対価を控除した金額であり,詳細は次のとおりである。
(ア) システム・インテグレーションに関する個別契約に基づく支払相当額49億1310万4830円
原告が本件プロジェクトの要件定義や基本設計その他のシステム・インテグレーションに関する各個別契約に基づき被告に対して49億1310万4830円を支払った。
(イ) オープン・インフラストラクチャー・オファリング契約(以下「OIO契約」という。)に基づき支払った金額のうち,未使用資産に係る金額 17億1958万1017円
原告は,OIO契約締結以後,平成22年3月末日の間,被告に対し,同契約に基づき37億3218万3658円を支払った。そのうち,原告が現に使用している資産に関するリース料等の金額である20億1260万2641円を控除した17億1958万1017円が損害額となる。
(ウ) 上記(ア)及び(イ)の損害のうち,「アセットアロケーション/最適商品選定システム」及び「ライフプランニングシステム」については,別件プロジェクトで利用可能であり,その対価相当額である7927万5000円は実損害を構成しないので,(ア)及び(イ)の合計額66億3268万5847円から上記7927万5000円を控除した65億5341万0847円が損害額となる。
イ 実損害② 8億6081万0455円
本件システムを大前提として,本件システムで使用するソフトウェアやハードウェアの調達,設備の改造等を行うに際し,被告以外の者に対して15億9847万7055円を支払った。そのうち,原告が現に使用している物の金額を控除した8億6081万0455円が損害額となる。
ウ 逸失利益 41億6600万円
原告は,本件システムの平成20年1月の稼動開始が不可能となったことにより,本件システムが予定どおり稼動開始していたならば,その新機能の活用により得られたはずの利益を得ることが不可能となった。この逸失利益は,被告の債務不履行により生じた損害であり,その額は,少なく見積もって2年分の逸失利益だけでも41億6600万円を下らない。この逸失利益の金額は,原告が本件システム導入を検討していた平成15年3月に,被告が「本件システムを導入すればこれだけの利益が得られる」として原告に対して提示した金額である。
(被告の主張)
ア 損害に関する原告の主張については争う。
イ 原告が主張する実損害①及び同②は,本件個別契約に基づき支払われた代金であり,各本件個別契約が定める成果物や対象サービスについては,被告がサービス又は成果物を納入し,原告は適切に検収や受領を完了しているのであるから,これらが損害を構成するものでないことは明らかである。
ウ 本件最終合意書8条ただし書による法的義務の排除
本件最終合意書8条ただし書は,「ただし,個別契約(中略)が締結され,各関連個別契約の中で両当事者の各局面における義務が規定されるまでは,いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。両当事者の書面による合意がある場合を除いては,本8条は有効とする。」と規定する。ここで,本合意書に基づく法的義務とは,本件最終合意書1条の89.7億という金額や,7条にいう「本日に至るまでの協議に基づく案」である「添付」(甲5の1)を含んでいる。「添付」には,本件プロジェクトの構想全体が記載されているのであるから,上記8条ただし書によって,原告と被告は,本件プロジェクトの開発スコープ,金額,スケジュール等について,8条の予定する個別契約に基づく責任のほか,何らの責任を負わないことを合意しているのである。
よって,本件最終合意書を交わした後に,要件定義作業が終了し,そこで定義された要件を積み重ねて「確定見積り」(乙2・9頁)を行った際に,開発スコープ,金額,スケジュール等が想定から外れていることが判明した場合であっても,被告は,本件最終合意書に基づく開発スコープ,金額,スケジュール等について,契約上の義務はもちろんのこと,信義則上の義務も負うことはない。
なお,8条ただし書の規定について,被告が不当に責任を免れる意図を有するものでないことは明らかであるから,上記の規定は,被告に故意が認められる場合でない限り有効に適用されることになる。
エ 個別契約の責任制限条項
本件最終合意書の交渉経過からも明らかなとおり,本件における法的義務の発生根拠となり得るのは本件個別契約のみであるところ,本件個別契約には,それぞれ責任制限条項が存在するため,原告が個別契約に基づいて支払った代金を被告に対して返還請求することができるのは,次の場合に限られる。これらの点について,原告の主張及び立証はされていない。
(ア) 個別契約のうち,原告が各個別契約に基づいて支払った額を累積した額の損害賠償を否定する旨の責任制限条項が規定されているものにおいては,原告が被告に対して損害賠償請求できるのは,それぞれの個別契約に基づく被告の作業が,それぞれ,損害発生の「直接の原因」となったこと,及びそれぞれの個別契約における代金の支払が,原告の主張する被告の契約違反又は不法行為による「通常かつ直接の損害」であることを主張,立証した場合に限られる。
(イ) 個別契約のうち,故意・重過失ある場合に累積的な損害賠償を認める旨の責任制限条項が規定されているものにおいては,それぞれの個別契約における代金の支払が,原告の主張する被告の契約違反又は不法行為による「通常かつ直接の損害」であることを主張,立証した場合に限られる。
オ 本件最終合意書4条による原告の逸失利益の損害賠償請求の排除
本件最終合意書4条によれば,各個別将来契約について,原告が被告に逸失利益の賠償を求めることはできないとされている。
カ 損益相殺
次の(ア)ないし(ウ)については,損益相殺により,原告の損害から控除されるべきである。
(ア) 再利用可能な成果物の客観的価値相当分 42億3921万6201円
被告が本件個別契約に基づき原告に納入した成果物の大部分は,本件プロジェクトが開発フェーズに入らずに頓挫したとしても,すなわち,NEFSS/Corebankを使用せずに被告以外のベンダと開発を行ったとしても利用可能であり,成果物の客観的な価値相当分は,原告における損害を構成しないというべきである。なぜなら,仮に,プロジェクトが頓挫して原告の支払が損害となったとの原告の主張を前提としたとしても,それにより,原告は,当該客観的価値に相当する利益を得ているからである。すなわち,原告の本件個別契約に基づく支払は,被告との間の本件プロジェクトが頓挫した時点において,全く無意味な支出となったとはいえず,①要件定義書(インターネットバンキングの要件定義も含む。),②システム設計書,③他社製パッケージソフトウェア(SAP社パッケージソフトウェア関連も含む。)の客観的価値相当分として,原告が支払った金額のうち,少なくとも42億3921万6201円は,原告における損害を構成しない。
(イ) 原告の本件未払個別契約①及び同②に基づく未払金(反訴請求の趣旨1項に係る請求分と同じ) 少なくとも13億6960万1493円
a 本件未払個別契約①及び同②の反訴請求は,その全額(13億7484万1650円)が認められるべきであるが,仮にこれが認められない場合には,プロジェクト頓挫により原告は同額の債務を免れる結果となるから,原告の損害から13億7484万1650円を控除するべきである。
b 仮に,本件未払個別契約②所定の成果物のうち,原告による受領,受入検査がされていない「設計・実装局面作業計画」に該当する部分の対価が請求できないとしても,本件未払個別契約①及び同②の対価の合計13億7484万1650円から,本件未払個別契約②の対価の0.468%(「設計・実装局面作業計画」の作成に係るワークロード(人月)が本件未払個別契約②所定の15の成果物に占める割合)に当たる524万0157円(消費税込み)を控除した13億6960万1493円は,仮に本件未払金反訴が認められないとすれば,原告がプロジェクトの頓挫によって同債務を免れる結果となるから,そのような不当な結果を導かないために,原告の損害から控除するべきである。
(ウ) 暫定的合意書(以下「LOI」という。)に基づく債務 2億3100万円
原告は,本件未払個別契約②の期間が終了した後,平成18年12月18日から平成19年1月15日の期間の作業の対価2億2000万円(消費税別)について,被告に対して支払う旨を書面で合意した。この2億2000万円(2億3100万円(消費税込み))は,本件不法行為反訴請求(反訴請求の趣旨2項に係る請求)に含まれるべきものであるが,仮に同請求が認容されないとすれば,原告はプロジェクトの頓挫により同額の債務を免れる結果となっているから,原告の損害から控除するべきである。
キ 相殺
仮に,本訴請求のうち,①請負契約の債務不履行に基づく損害賠償請求,②個別契約の債務不履行解除による損害賠償請求又は③個別契約の錯誤無効による不当利得返還請求のいずれかが認容される場合には,被告は,次の債権をもって,次の(ア)から(ウ)の順に従って,原告の上記本訴請求債権とその対当額で相殺する。
(ア) 本件未払個別契約①及び同②に基づく未払金請求権13億7484万1650円及びうち2億5515万円に対する平成18年8月31日から,うち11億1969万1650円に対する平成19年4月7日から各支払済みまで年6分の割合による金員(反訴請求の趣旨1項に係る請求分と同じ)。
(イ) ESO契約に基づく未払金1億2004万0620円及びこれに対する平成22年2月26日から支払済みまで年6分の割合による金員(反訴請求の趣旨3項に係る請求分と同じ)。
(ウ) 不法行為に基づく損害賠償請求権110億5710万2553円及びこれに対する平成19年11月30日から支払済みまで年5分の割合による金員(反訴請求の趣旨2項に係る請求分と同じ)。
(原告の反論)
ア 責任限定条項について
債務者に故意又は重過失がある場合,責任限定条項は無効であるから,故意又は重過失により本件プロジェクトを頓挫させた被告に,本件最終合意書4条の責任限定条項は適用されない。
イ 損益相殺の主張に対する反論
(ア) 再利用可能な成果物の客観的価値相当分について
被告は,原告は本件成果物の客観的価値に相当する利益を得ているから,本件成果物の客観的な価値相当分が損害を構成しないとして,損益相殺に基づく主張をする。しかしながら,次のとおり,被告の上記主張はその前提を欠いている。
a 被告は,本件成果物のうち,本件プロジェクトが頓挫したとしても依然として利用可能な部分として,①要件定義書(インターネットバンキングの要件定義も含む。),②システム設計書,③他社製パッケージソフトウェア(SAP社パッケージソフトウェア関連も含む。)の客観的価値相当分が損害を構成しないと主張する。
しかしながら,これらの成果物のうち,③他社製パッケージソフトウェアの一部である株式会社キャピタル・アセット・プランニング製の「アセットアロケーション/最適商品選定システム」及び「ライフプランニングシステム」(以下「アセットアロケーションシステム等」と総称する。)を除き,別件プロジェクトで利用可能な部分は存在しない。
(a) 要件定義書について
①被告が原告に納入した要件定義書は失敗作であって,Corebankを前提とした場合でさえグローバルIBMが指摘した問題(パッケージの特性を生かせないなどの問題)があるのに,他ベンダのパッケージを用いるプロジェクトにそのような要件定義書を用いることなど到底できないこと,②要件定義書のレベル5(「現新論理モデル対比表」及び「新処理機能記述」の2つの文書から構成される。)及びその添付資料である「現行処理記述」は,平成16年当時の現行システムの約4分の1についてしか作成されていない未完成なものであり,かつ,レベル5に至ってはレベル4との整合性も確認できない代物にすぎないし,「現行処理記述」はとても利用に耐えない品質であること,③平成18年1月から3月にかけて被告から納入された要件定義書は,新規開発又は改訂の内容を一切反映していないのであって,その内容が完全に陳腐化しており,不完全な内容となっていること,④別件プロジェクトでは,当然のことながらベンダは被告ではなく,パッケージもCorebankではないところ,要件定義は,ベンダごとにそのやり方が全く異なるし,要件定義書の内容,形式も全く異なるのであるから,被告が作成した要件定義書を別件プロジェクトにおいて利用することは不可能であること,⑤要件定義書を転用する場合,他のベンダは,膨大な要件定義書を完全に理解,検証し,不備などを是正しなければならないところ,本件成果物の要件定義書は前述のとおり陳腐化してしまっているため,これらの作業はより大変な作業となるし,原告が被告と裁判で争っている以上,他のベンダは,被告から必要な引継ぎを受けることもできないし,要件定義書に関して不明な事項があったとしても,被告に問い合わせることすらできないのであるから,転用のための上記作業を行うには莫大な時間とコストが必要となるのであり,このような作業を行うのであれば,他のベンダが最初から要件定義を行う方が早いしコストも低く抑えられることからすると,要件定義書は別件プロジェクトで利用できない。
また,本件要件定義書につき損益相殺を認めることは,被告を不当に利し,原告に不当に犠牲を強いるものであって,公平性を著しく欠く。すなわち,本件要件定義書のうち,Corebankに依存する部分が別件プロジェクトで利用できないのはもちろんのこと,そうでない部分,つまり平成16年10月当時の本件処理フローを整理した部分も,これを利用することは著しく非効率であり,これをあえて別件プロジェクトで利用することは,開発費用の面でも,納期(開発期間)の面でも,品質の面でも,原告にとって莫大な負担を強いられることになるほか,上記のような状況下にある以上,本件要件定義書を別件プロジェクトで利用しなければならないとする被告の主張は,どう考えても不合理であり,公平性を欠く。
また,原告は,本件プロジェクトが頓挫したことによって,別件プロジェクトを実施せざるを得なくなり,原告に支払った開発費用に加え,別件プロジェクトにおいても莫大な費用負担を強いられている。仮に,本件要件定義書が利用可能であるとして損害額が差し引かれるような事態となれば,原告は,莫大な開発費用の二重の負担を強いられることになるのであり,著しく公平性を欠くことは明白である。
(b) 計画・要件定義#1の作業について
計画・要件定義#1は成果物がなく,計画・要件定義#1の作業で再利用可能なものなど物理的に存在しない。
また,仮に計画・要件定義#1の成果が計画・要件定義#2の成果物たる要件定義書に反映されているとしても,この要件定義書を別件プロジェクトで利用することはできない。したがって,原告が計画・要件定義#1の支援作業に対する対価として支払った7億5935万8950円(消費税込み)のうち,83.09%は再利用可能とする被告の主張は失当である。
(c) システム設計書について
被告から納入されたシステム設計書は,当然のことながら,本件プロジェクトで採用することが予定されていたパッケージ又は製品を用いることが前提とされている。しかしながら,別件プロジェクトでは,本件プロジェクトで採用することが予定されていたパッケージ又は製品は利用されない。
(d) SAP社パッケージソフトウェア関連
SAP社パッケージソフトウェア関連(以下「SAPパッケージ」という。)は,本件プロジェクトにおいて,本件システムの一部を構成するものとして採用が決定されたものである。SAPパッケージは,多数のユーザに使用許諾されている製品ではあるものの,大規模な業務パッケージであることから,本件プロジェクトが頓挫した場合に他に容易に流用が可能なものではない。また,使用許諾契約上,原告が第三者に使用権を譲渡することもできない。
それゆえ,当該SAPパッケージは,本件プロジェクトが頓挫したことにより,その時点で利用価値を失い,その対価が原告の損害となった。しかしながら,原告においては,別件決算処理システムプロジェクトで同一のパッケージを使用することになったので,損害を減少させるため,当該SAPパッケージの使用権を流用しようと考え,SAP社及び被告と交渉を行った。それにもかかわらず,被告がこの交渉を不合理に拒絶したことから,原告は購入済みのSAPソフトの流用を諦め,SAPソフトを新規に購入せざるを得なくなった。これにより,当該SAPパッケージの対価は,原告の被った損害を構成することとなった。
(e) イーディーエス・ジャパン・エルエルシー社製のCRMパッケージ(以下「CRMパッケージ」という。)について
CRMパッケージも本件システムの一部を構成する目的で採用されたものである以上,本件プロジェクトが頓挫した時点でその対価が損害を構成することとなった。
b 原告は,既に複数の他のベンダに委託をして,新経営システムの構築に着手している(別件プロジェクト)。しかしながら,原告は,別件プロジェクトにおいて,本件成果物を一切使用することなく要件定義工程から全てやり直し,再度,要件定義についての費用も全て負担している。つまり,原告は,本件成果物を一切利用しておらず,本件成果物による利益など全く享受していない。このように,客観的事実として,原告が本件成果物による利益を受けていない状況にあって,損益相殺的な考え方により,損害の額が減縮されるようなことになれば,原告は,莫大な開発費用の負担を二重に強いられることになり,極めて不合理である。この意味でも,被告の損益相殺に基づく上記主張は失当である。
(イ) 原告の本件未払個別契約①及び同②に基づく未払金について
本件未払個別契約①及び同②に基づく未払金請求権が存在しないことは,後記(7)(原告の主張)欄に記載のとおりである。そうすると,被告の主張は,存在しない未払金請求権相当額を損害から控除すべきと主張しているに等しく,失当である。
また,被告は,本件未払個別契約②の納入物のうち,「設計・実装局面作業計画」の作成に必要な作業量(人月)の割合は「0.468%」にすぎないなどとして,本件未払個別契約①及び②の対価のうち,総額13億6960万1493円は原告の損害から控除しなければならないとも主張する。しかし,「設計・実装局面作業計画」とは,「本件システムの設計及び実装にいかなる作業が必要となるか」「誰が」「いつまでに」「いかなる作業を」「いかなる方法で」行っていくかといった事項が「作業計画」として詳細にまとめられるものである。「設計・実装局面作業計画」がなければ次フェーズ以降の作業を実施することができない。
このように,「設計・実装局面作業計画」は極めて重要な納品物なのであって,これが納品されなければ,本件未払個別契約②の目的は達成されない。
以上からすれば,「設計・実装局面作業計画」の作成に必要な作業量(人月)の割合によって契約金額の大部分の控除を求める被告の上記主張が無意味で,かつ失当であることは明らかである。
(ウ) LOIに基づく債務
被告は,原告と被告との間のLOIに記載された2億3100万円(消費税込)は,原告における損害から控除されるべきものであると主張する。しかし,原告は,そもそもLOIに記載された金額については,本訴請求において損害として被告に対して請求していない。仮に,原告が,LOIに記載された金額を被告に対して支払っていれば,それも実損害①を構成するものとして本訴請求の請求金額に含めていたところである。
また,LOIは,Corebankを基幹に据えて本件システムを構築することを目的とする本件最終合意書に関連する個別契約と位置付けられるところ,原告は,被告の債務不履行及び不法行為を理由として平成19年7月17日付けでこれを解除しており,LOIに基づく債務を負っていない。
(7)  争点(7)(反訴請求の可否)について
(被告の主張)
ア 本件未払個別契約に基づく請求(反訴請求の趣旨1項に係るもの)
(ア) 原告と被告は,本件プロジェクトに関し,本件未払個別契約①及び②を順次締結した。
(イ) 被告は,本件未払個別契約①所定の成果物である「システム設計書(制御編・基盤編)」を納入予定日である平成18年3月31日付けで原告に対して納品し,原告による受領・受入検査も同日完了した。しかるに,原告は,本件未払個別契約①所定の代金額の支払期日である同年8月30日を経過した平成20年8月29日現在においても,被告に対し,本件未払個別契約①の代金の一部である2億5515万円(消費税込み)を支払っていない。
(ウ)a 被告は,原告に対し,本件未払個別契約②所定の成果物である「基幹系・取引機能マトリックス」等(ただし,後記b記載の一部を除く。)を納入予定日である平成18年12月1日に納品し,原告による受入検査を経て,同月26日に上記成果物の更新版を納品し,原告の受領,受入検査を完了している。
b なお,本件未払個別契約②所定の成果物である「設計・実装局面作業計画」については,いまだ原告による受領・受入検査がされていない。
「設計・実装局面 作業計画」は,基本設計フェーズ後の本件プロジェクトの作業計画であるから,本件プロジェクトのスケジュールや開発スコープ等について,原告と被告との合意の下,方針がまとまることを前提とするものである。そして,被告は,要件定義・BRDを踏まえた現実的なスケジュール等について原告と協議を行い,共通理解を醸成し,これに基づく提案を行うなど,原告との間で上記方針がまとまるよう努力すると同時に,平成18年12月末には,当該方針がまとまりさえすれば納入可能なWBS(Work Breakdown Sheet。作業の詳細を記載したもの)等の「設計・実装局面 作業計画」の作成を完了していた。
それにもかかわらず,原告が,本件プロジェクトの基本設計フェーズ後の現実的な作業計画について,被告との間で方針をまとめ,上記「設計・実装局面 作業計画」を受領することを拒絶したまま,本件プロジェクトを一方的に中断したため,上記の成果物は,原告による受領及び受入検査が未了となっている。
すなわち,原告は,原告の現行システムの機能や本件プロジェクト初期の概略的見通しに基づくスコープ,代金額等に固執するなどして,本件プロジェクトの進行に対し非協力的な態度をとり,本プロジェクトの基本設計フェーズ後の現実的な作業計画(具体的には,サービスインのスケジュールの点や開発スコープの調整に基づく作業内容及びこれらに伴う開発費用負担等)についての方針をまとめるための協力を行ってこなかった。それにもかかわらず,原告は,平成19年4月19日に被告がプロジェクトを進行するために行ってきた原告との協議やこれに基づく共通理解や提案を覆す態度をとり,また,被告がCorebankの代替案として行ったTCBに関する提案を何ら検討することなく即刻拒否し,本件プロジェクトをいったん白紙に戻すと宣言し,さらには,平成19年7月17日付けの原告代理人による被告宛通知書(甲15の1)において,本件未払個別契約を含む本件個別契約全部の債務不履行に基づく解除又は錯誤無効を主張するに至った。
このような原告の態度は,本件未払個別契約②所定の成果物の一つである「設計・実装局面 作業計画」の作成に不可欠である本プロジェクトの現実的なスケジュールや開発スコープ等に関する方針をまとめるために必要不可欠な協力を拒否し,被告からの成果物の受領を拒絶する意思を明確にするものである。このように,被告の「設計・実装局面 作業計画」の納入義務は,専ら原告の責めに帰すべき事由により履行ができない状態となった。
したがって,本件未払個別契約②所定の成果物のうち,被告が納入済みの成果物について原告が代金額の支払義務を負うのはいうまでもなく,上記原告が未受領の成果物についても,原告は被告に対して本件未払個別契約②に基づき代金額の支払義務を負う。
(エ) 原告は,本件未払個別契約②所定の代金額の支払期日である平成19年4月6日を経過した平成20年8月29日現在においても,被告に対し,本件未払個別契約②の代金額である11億1969万1650円円(消費税込み)を支払っていない。
(オ) よって,被告は,原告に対し,本件未払個別契約①(平成18年3月31日付け「IBMシステム・インテグレーション契約書」)に基づき請負代金の一部である2億5515万円及びこれに対する平成18年8月31日から支払済みまで年6分の割合による遅延損害金の支払を,本件未払個別契約②(平成18年9月29日付け「IBMシステム・インテグレーション契約書」)に基づき,請負代金11億1969万1650円及びこれに対する平成19年4月7日から支払済みまで年6分の割合による遅延損害金の支払をそれぞれ請求する。
イ 不法行為に基づく請求(反訴請求の趣旨2項に係るもの)
(ア) 原告は,前記(2)(被告の主張)欄記載のとおり,プロジェクト開始当初から,①BPRを行わず,②報告や議論についてそれが存在しなかったかのごとき虚偽の資料をあえて作成させ,③ことあるごとに責任論を持ち出してプロジェクトを遅延させた上,④原告の副社長自身が提示した現実的な条件を反故にして,実現不可能な要求を突きつけて,交渉とも呼べない交渉を行うなどして,プロジェクトを頓挫させた。
原告は,これにより,被告が少なくとも110億5710万2553円にのぼる莫大な投資をして開発してきたNEFSS/Corebankの横展開を不可能にし,被告の投資を水泡に帰せしめた。原告のこのような行為が不法行為に当たることは明らかである。
(イ) したがって,被告は,原告に対し,不法行為に基づき,NEFSS構築のために費やしてきた投資相当額の損害金110億5710万2553円及びこれに対する不法行為の後である平成19年11月30日から支払済みまで年5分の割合による遅延損害金の支払を請求する。
ウ ESO契約に基づく請求(反訴請求3項に係るもの)
(ア) 原告と被告は,平成16年12月29日,本件プロジェクトに関するハードウェア,ソフトウェア等の導入,リース及び保守等に関し,OIO契約を締結した。
(イ) ESO契約対象ソフトウェアには,次の4つの課金方式のいずれかが適用される。
a 変動式ワークロード使用料金(VWLC。使用したプロッセッサ能力(MSU)で決まる変動月額料金)
b 定額式ワークロード使用料金(FWLC。固定月額料金)
c ティア料金(Tier Pricing,LVTR。プリンタ等を制御するソフトに適用されるもので,プリンタ等の周辺機器の構成で決まる固定月額料金)
d 固定料金(Flat Pricing,FLAT。古くからある固定月額料金。)
ESO契約対象ソフトウェアは,いずれも,メインフレームと呼ばれる大型コンピュータで動作するソフトウェアである。メインフレームは,同時並行的に多数のソフトウェアを動作させることができる高性能なコンピュータである。原告は,このメインフレームを使用して,本件プロジェクトの当時から現在に至るまで,継続して,現行システムを稼動させて業務を行っている。なお,メインフレームは,内部のプロセッサの使用量を記録する機能を有している。上記aの料金は,この使用量を元にした,いわば「使った分だけ支払う」という従量制の料金である。メインフレームで使用するソフトウェアは,ESO契約により,この従量制の料金と上記b,cの固定制の料金を組み合わせる方式で,代金を支払うことになっている。
これらのESO契約対象ソフトウェアの使用料金の合計に対しては,一定の上限値が定められ,当該使用料金の上限値を超えた場合には,原告は被告に対し,上限値の超過金額を支払う義務を負う(ESO契約5条2項)。
かかるESO契約上のソフトウェア使用料金の上限値は,ESO契約5条2項に定められているが,これは平成17年12月30日付け通知書において変更されており,平成20年度(第4年度。平成20年1月1日~同年12月31日)における使用料金の上限値は2億3019万7600円(消費税抜き),平成21年度(第5年度。平成21年1月1日~同年12月31日)における使用料金の上限値は1億5776万0400円(消費税抜き)である。
(ウ) 平成20年度(第4年度)における原告のESO契約対象ソフトウェアの使用料金実績金額は2億4803万1600円(消費税抜き),平成21年度(第5年度)における同金額は,2億5425万0800円(消費税抜き)であった。
したがって,原告のESO契約対象ソフトウェアの使用料金実績金額は,平成20年度(第4年度)においては1783万4000円(消費税抜き),平成21年度(第5年度)においては9649万0400円,ESO契約(平成17年12月30日付け通知書による変更を含む。)に定める使用料金上限値を超過した。
(エ) 被告は,平成22年2月26日,原告に対し,上記使用料金上限値超過金額に消費税を付加した金額(平成20年度分については1872万5700円,平成21年度分については1億0131万4920円)を請求した。
(オ) それにもかかわらず,原告は,上記の被告の請求に対し,協議を申し入れ,いまだに支払を行っていない。
したがって,被告は,原告に対し,ESO契約に基づき,ESO対象ソフトウェアの使用料金上限値超過金額として,金1億2004万0620円及びこれに対する平成22年2月26日から支払済みまでの年6分の割合による遅延損害金の支払を求める。
(原告の主張)
ア 被告の上記アの主張について
(ア) 原告と被告が本件未払個別契約①及び②を順次締結したこと,被告が,本件未払個別契約①所定の成果物を平成18年3月31日に原告に対して納品し,原告による受領,受入検査を完了したこと,被告が,本件未払個別契約②所定の成果物のうち,「設計・実装局面 作業計画」を除く「基幹系・取引機能マトリックス」等を同年12月26日まで原告に対して納品して,原告による受領,受入検査を完了したことについては,いずれも認める。
(イ) 債務不履行解除
本件未払個別契約①及び同②は,いずれも被告の債務不履行を理由に解除したことは,上記(2)及び(3)の原告の主張欄に記載のとおりである。
(ウ) 錯誤無効
本件未払個別契約①及び同②は,いずれも錯誤無効であることは,上記(5)の原告の主張欄に記載のとおりである。
(エ) 変更の合意に基づく弁済
被告は,被告が平成18年9月26日付けで作成した「SCS殿要員の発注に関して」(以下「本件支払変更依頼書」という。)において,新BRDに関して被告が負担すべきであったSCS社の人件費の一部の支払方法を被告から(A&I社という第三者を通じて)SCS社に対して支払うのではなく,原告から直接SCS社に対して支払ってほしいとの依頼をした。そして,原告がこれを承諾したことから,被告は,原告に対し,本件個別契約①の契約金額である2億4500万円(消費税別)から2億4300万円(消費税別)を差し引いた残額200万円に消費税10万円を加えた金額210万円を「最終お支払い」として請求書を発行し,原告はこれに応じて支払った。
さらに,原告は,上記合意に基づき,新BRDに関するSCS社の人件費をSCS社に対して支払った。
以上からすれば,原告及び被告との間で,本件未払個別契約①の支払方法等に関し変更する合意がされ,原告は,当該合意に基づき,本件未払個別契約①の弁済を行ったことは明らかである。
(オ) 同時履行
被告は,本件未払個別契約②に基づく成果物の一部を納品していないのであるから,原告が,本件未払個別契約②に基づく支払を行う必要がないのは当然である(同時履行の抗弁)。
イ 被告の上記イの主張について
否認ないし争う。
本件プロジェクトが頓挫したのは,被告の責めに帰すべき事由によるものであり,それについての原告の主張は,上記(2)の(原告の主張)欄記載のとおりである。
ウ 被告の上記ウの主張について
(ア) 不当利得に基づく返還請求権による相殺
a 原告は,本件プロジェクトが頓挫したことを受け,平成19年10月以降,本件システム用のソフトウェアについては,ESO契約の対象から外し,被告に対してソフトウェアを返却するべく交渉を重ねてきたが,被告は,平成22年3月に至るまでこれを拒否し続けた。
仮に,本件システム用のソフトウェアについては,ESO契約の対象から外し,被告がソフトウェアの返却に応じていれば,平成20年については,「対象プログラム使用実績値」が「使用料金上限値」を超えることはなかったし,平成21年については,「対象プログラム使用実績値」は「使用料金上限値」を超えていたが,その金額は3814万1775円にすぎなかった。
したがって,被告の原告に対するESO契約に基づく金銭支払請求権は,3814万1775円である。
b 他方,原告は,平成20年分に関して4430万0865円を支払ったが,これは,将来的にも使用しないことが確定していたソフトウェアの返却に被告が応じていれば支払う必要のなかった無意味な金額であり,当該金額は,被告の不当利得に該当するから,原告は,被告に対し,4430万0865円の不当利得返還請求権を有している。
c 原告は,上記不当利得返還請求権とESO契約に基づく金銭支払債務を対当額にて相殺する。
(イ) 債務不履行に基づく損害賠償請求権による相殺
a 使用料金の算定の基礎となる「対象プログラム使用実績値」の算出方法の詳細は原告に開示されておらず,被告が「対象プログラム実績値」を算出して原告に報告しない限り,原告には「対象プログラム使用実績値」が「使用料金上限値」を上回る状況にあるか否かを知る術がない。そこで,ESO契約では,被告が四半期ごとに原告の「対象プログラム使用実績値」を原告に対して報告するものとし(ESO契約5条2項),被告は,原告の使用状況に応じて料金を変更するものとされている(ESO契約と一体のものとして適用されるIBMプログラムのご提供条件6条1項)。
しかしながら,被告は,この四半期ごとの「対象プログラム使用実績値」の報告を平成22年3月に至るまで一度も実施していないし,原告の使用状況に応じて料金を変更することもしていない。
b 後に原告からの要求に応じて被告からされた報告によれば,平成17年度から平成20年度における原告の「対象プログラム使用実績値」は,「使用料金上限値」を大幅に下回っており,この4年間で3億0394万6125円もの金額について,対象プログラムを全く使用していないにもかかわらず,無意味に支払を強制された。
仮に,被告が原告に対して「対象プログラム使用実績値」の報告を行い,原告が対象プログラムの使用状況を見直す機会を付与されていれば,原告は使用状況に応じて料金を変更したのであるから,これにより3億0394万6125円の支払を免れることができた。
c したがって,原告は,被告に対し,ESO契約5条2項及びIBMプログラムのご提供条件6条1項違反という債務不履行に基づき,3億0394万6125円の損害賠償請求を有している。
仮に,上記(ア)の抗弁が認められず,被告が原告に対するESO契約に基づく1億2004万0620円の金銭支払請求権を有していたとしても,原告は,上記損害賠償請求権と同金銭支払請求権を対当額で相殺する。
(ウ) 信義則違反,権利濫用
ESO契約に基づく被告の請求は,上記(ア),(イ)の事情にかんがみると,信義則違反,権利濫用にも当たるものであるから,被告の同請求は,この意味でも認められる余地はない。
第3  当裁判所の判断
1  認定事実
前記前提事実に加え,証拠(甲119,甲120,甲123,甲125及び甲151並びに証人G,同H及び同Cのほか,後掲の証拠)及び弁論の全趣旨を総合すれば,次の事実が認められる。
(1)  本件最終合意の締結に至るまでの経緯等
ア 本件プロジェクト開始に至る経緯
(ア) 原告は,平成12年9月,被告と共に,原告の事業戦略上実現すべき業務内容,次期システムの在るべき姿及びその要件等の洗い出し作業を行い,その結果,平成15年7月,原告が導入する時期システムによって実現すべき事業要件が「変革のテーマ」と題する文書にまとめられた(前記前提事実(3)イ,エ)。
(イ) また,原告は,平成14年9月から平成15年12月ころにかけて「eプロジェクト」を実施し,被告はこれに協力した。被告は,この中で,原告が次世代の勘定系システムの在るべき姿を見定めることの手伝いをするとともに,そのような勘定系システムの開発に要する費用や期間等についての大まかなイメージを示した(前記前提事実(3)オ)。
(ウ) 被告は,平成16年3月12日,原告に対し,同日付け「「顧客中心」・「迅速・柔軟な商品・サービス提供」・「オンデマンド」を可能とする次世代金融サービスシステムのご紹介」と題する書面を交付した。
その中の「「次世代金融サービスシステム」業務機能の実装」と題する頁には,「以下の観点よりUSの先進パッケージ(Fidelity Information Servicesの‘Corebank’)を有効活用します。」,「「次世代金融サービスシステム」の目標である「顧客中心」の商品・サービスを「プロダクトビルド」(自由設計)できる機能を実現するためには,先行している欧米のパッケージの有効活用が優位である。」,「短期間でパッケージを構築するには,ゼロからの開発ではなく実績のあるパッケージを有効活用して開発する方が優位である。」と記載されている。また,「基本方針」として,「先進パッケージ機能と,2002年初めより実施してきた日本の銀行商品・サービスのモデル化とを融合させます。」,「パッケージのコンポーネント(部品)を「WebSphere」上の「Java」にコンバージョン」,「日本の銀行の商品・サービスを追加」と記載されている(前記前提事実(3)カ)。
(エ) 平成16年4月12日に行われた原告と被告との間の打合せにおいて,原告のC専務は,「スルガ個社の事を考えずに,(NefisのSelling Talk通り)次世代のシステムのあるべき論からスタートし,現実解を求めたい。このことはスルガとしてかなり思いきったことを言っている。過去のスルガの文化とかプライドとかを全て捨てても良いと思っている。必要であれば事務フロー/プロセスも変更する。社内の軋轢にもTOP自ら号令をかけて実行したい。(IBMも腹をくくって対応して欲しい。)スルガTOP(社長/副社長/専務)の意向である。」,「システム化するにあたり,捨てるものを決める必要がある。全く別のものになった場合移行コストが膨大であることは理解している。選別し捨てる覚悟はある。」などと述べた(乙21)。
(オ) 原告は,被告のほか,複数のシステム開発業者から提案されたシステムを比較検討した結果,被告による提案の内容が最も好ましいものと考え,同年9月21日,①原告の基幹系オンラインシステムを被告が提供するNEFSSバンキングシステムを基に全面改良を行い,新経営システムを構築すること,②上記費用として,初期費用約95億円,保守費用として約6億2000万円(年額)を支出することを決めた。
なお,同日の原告取締役会に提出された議題に添付された原告作成の資料には,「プロジェクトのスケジュール」として「合意書/支援サービスの締結によって計画・要件定義#1を開始,計画・要件定義#2終了までに要件をまとめ,その内容に基づいた最終合意書(請負)を締結する。」,「総費用の概算内訳」として「ステップ1では上限を設定」とした上で計95億円と記載されている(前記前提事実(3)キ)。
イ 本件基本合意①の締結
(ア) 原告は,同月29日,被告との間で,本件基本合意①を締結し,本件プロジェクトは開始された。本件基本合意書①には概要次のとおり記載されている。なお,この時点においては,原告と被告との間で,平成17年5月末に本件プロジェクトに関する最終合意がされる予定であった(前記前提事実(4))。
a 原告と被告は,被告提供のNEFSSを利用した原告の「新経営システム」構築に当たり,以下のとおり合意した。
b 原告の目標である「開発スコープ」(平成16年9月21日付け資料:「新経営システムご提案概要」)の実現を前提とした「新経営システム」構築に当たり,以下①②③の全てが実行されることを条件として,被告は95億円(原告側要員費用含む)にて稼働を実現するよう確約する。
役割分担合意に伴う被告の管理下での原告側要員費用については,両者協議の上,工数及びスケジュール等の観点で管理を実施するものとする。
① 原告と被告の役割分担の両者による合意及び原告管理下のワークロード・費用の確定がされること
② 原告の商品・取引・帳票等に対する「BPR・標準化」による合理化・効率化の合意が両者によりされること
③ 上記①の役割分担合意に伴う,当該プロジェクトを遂行する上で必要な原告の協力がされること
c 「新経営システム」構築プロジェクトの計画・要件定義局面終了までに,以下の項目を含む外部設計局面以降に関して合意することを目標に両者は作業を進めるものとする。
(a) 開発機能・スコープの詳細
(b) 稼働までの初期費用総額の詳細及び支払計画
(c) プロジェクト期間中及び稼働後のランニング費用
(d) ハードウェア構成・ソフトウェア構成と前提キャパシティ
(e) プロジェクト遅延及び不履行時の取り決め
本条に定める合意までの間に,プロジェクトの大幅な延期や中止せざるを得ない状況が発生した場合,あるいは,本条に定める合意に至らなかった場合には,両者は真摯に協議の上,互いに誠意を持って損害賠償等の措置を含む適切な対応をするものとする。
d 計画・要件定義局面の契約として,以下の内容を含む「IBM支援サービス契約書」(金額:7億2319万9000円)につき平成16年9月29日を目標に締結すべく,両者協議の上,進めるものとする。
(a) 「新経営システム」構築の計画・要件定義フェーズ#1 ご支援作業
(b) 「NEFSSパッケージ」(「Corebank」及び「次世代金融サービス・システムライブラリー」)
(イ) また,本件基本合意書①に添付された被告作成の平成16年9月21日付け「新経営システムご提案概要」には「計画・要件定義局面#1の進め方」として,次のとおり記載されている(甲3)。
a 計画・要件定義#1での作業工程
(a) 「プロジェクトスコープ」の確認
(b) プロジェクト計画の立案
(c) NEFSS/Corebank要件定義作業の方針検討と策定
(d) 現行システム調査(情報の整理・ドキュメント整備)
b 計画・要件定義#1の作業主体
現行システム調査(情報の整理・ドキュメント整備),具体的には,現行システム取扱い商品性の調査,現行システム取引フローの調査,現行システム処理フローの調査,現行システム事務フロー,業務フローの調査等は,原告が責任作業を実施し,被告が責任作業への支援をする。
ウ 計画・要件定義#1
(ア) 原告は,同月29日,被告との間で,計画・要件定義#1に係るIBM支援サービス契約を締結した(前記前提事実(5)ア)。
(イ) 上記(ア)のIBM支援サービス契約に基づき,同年9月30日から本件プロジェクトが正式に開始された。同日,キックオフ・ミーティングと称する打合せが開催され,その際の被告作成資料には,次の記載がある(前記前提事実(5)イ(ア),乙22)。
a 計画・要件定義#1の作業項目のうち,現行システム分析準備は,原告が主体となり作業を実施する(乙22・24頁)。
b 現行システム分析準備として,①既存資料の収集ポイント整理(ただし,この作業は被告が主担当),②既存資料の収集,③既存資料の充足度合い確認,④不足情報の対応策検討を行う(乙22・39,43頁)。
(ウ) 原告と被告は,同年10月5日,週次進捗会議を開催した。被告は,本件基本合意書①で実施することが合意されたBPRについての説明を行った。BPRのアプローチとして,①フェーズ1として,原告経営戦略・商品の収益性,他行事例等から,廃止又は現行商品に統合する商品を決定し,現行商品群から廃止又は統合される部分を差し引いた部分がNEFSS移行対象商品とする,②フェーズ2として,各商品の取引フローを標準化することにより,フロー数を集約,統合し,NEFSS移行対象商品から,フロー数を集約,統合されたものを差し引いた部分が,NEFSSに実装される取引フロー(概要レベル)となると説明した(乙23)。
(エ) 同年11月5日に開催された第1回ステアリング・コミッティにおいて,原告が12月末までに計画・要件定義#2の契約,来年5月に本契約を目指すという認識でよいかと質問したのに対し,被告は,12月末までの計画・要件定義#2の契約について早急に対応するとともに,来年5月の最終合意に向けてスケジュールを調整すると答えた(甲6の1)。
エ 計画・要件定義#2の開始
平成16年12月29日から,計画・要件定義#2が開始された。その目的は,「新経営システム」構築に対する「要求」を調査,分析し,システム化の対象を絞り込み,最終的な「システム化要件」を定義することであるとされていた。計画・要件定義#2を実施する過程で,平成17年4月8日開催の第6回ステアリング・コミッティにおいて,現処理フローの作成の必要性が確認されたが,現処理フローを記した原告側の資料がない部分については,いわゆるリバースエンジニアリングの方法により現処理フローが作成されることとなった。その結果,同年5月11日開催の第7回ステアリング・コミッティにおいて,計画・要件定義#2の完了を同年12月末まで延期することとされた(甲6の2,甲6の6,甲6の7)。
オ 本件最終合意の締結の延期
被告は,「Corebank等のパッケージを最大限に活用した効率的開発手法」の確立及びそれを前提とした見積り方法の確立が未済であること,商品のBPR(統廃合とグルーピング)による開発対象基礎数値(目標値)の確立と合意が未済であることを理由として,原告に対し,平成17年6月30日付けの「「新経営システム」構築プロジェクトにおける「最終合意」締結延期に関するご報告と今後の対応」と題する書面を交付して,同年5月末から同年6月末に締結が延期されていた最終合意を同年9月末に締結することを目標とすることを申し出た(甲47の1)。
原告のI常務は,同年7月6日に開催された第9回ステアリング・コミッティにおいて,いろいろな事情があったかとは思うが,合意書締結が遅れたことは遺憾である,経営者間での取り決めについては必ず守るということを強くお願いすると述べた(甲6の9)。
カ 本件最終合意の締結まで
(ア) 被告は,同年8月3日に開催された第10回ステアリング・コミッティにおいて,最終合意の最終版作成に当たり,基礎数値の見直しについては原告の協力をいただき収束の状況にある,ほぼ固まった状況で被告社内において確認を行っているところである旨を報告した。この報告で用いられた被告作成の資料には,「システム開発コスト見積もりの前提となる基礎数値(オンライン取引数,帳票数,リンクデータ数,バッチジョブ数)については,スルガ様ご協力のもとほぼ確定に近づいた 現在は生産性の検証と見直しおよび見積もり開発工数の再確認を行った上でのコスト確定とプロジェクト開発計画の承認を受けるための準備処理を実施中」(資料の3-1頁)との記載がされていた(甲6の10)。
(イ) また,同年9月7日に開催された第11回ステアリング・コミッティにおいて,被告は,最終合意書について一つだけ大きな課題が残されていて,鋭意対応中であるので,今しばらく時間をいただきたいと述べた。これに対し,原告は,同月中に締結できるようにお願いしたい旨述べた。そして,計画・要件定義#2の成果物である要件定義書については,被告から原告に対して同年12月末までに納入される予定であることが報告された(甲6の11)。
原告と被告は,その後である同年9月30日,本件最終合意書を交わした(前記前提事実(8))。
(2)  本件最終合意の締結後から平成18年12月末までの経緯等
ア 旧BRD実施までの経緯等
(ア) 平成17年10月5日に開催された第12回ステアリング・コミッティにおいて,被告は,計画・要件定義#2の全体作業状況として,現モデルの作成,変革テーマの取り込み,システム全体概要の検討,NEFSS差異分析及びシステムの定義を継続実施中であること,システム全体概要の検討では,同年9月からLevel5(サブシステム(新システムにおける取引レベル)の検討及び文書化(Level4の新処理フローを骨格として,取引フローの集約,統合及び変革テーマの取り込みを実施し,新システムでの取引仕様を検討,文書化したもの)の作業を開始したことを報告した。
被告の担当者は,課題及び依頼事項として,①IBMアジア・パシフィック,FIS社を含めたチームにより,今後の進め方についてレビューと最適な(実情にあった)開発手法の検討を実施中であり,NEFSS/Corebank関連部分の開発手法の再確認とそれによる開発生産性の向上,作業範囲の確認,周辺システム(パッケージ主体部分)の開発手法に沿った最適な開発スケジュールの確認等,業務中心に全体の見直しも視野に入れた検討タスクの組成を予定していること,②その中で横展開の資産としてのコア部分と原告固有部分の分離を検討する予定であること,③マネジメント体制の見直しも含め,継続的な対応と管理を実施する予定であること,④業務の要件定義については同年12月末で完了予定であるが,融資稟議と外為については一部未済項目が残ることが見込まれることなどを報告した。
また,被告は,原告に対し,①被告の都合で,合意書の提示時期が同年5月予定が9月末まで延びて御迷惑をお掛けした,②原告に無理を申し上げた,③基本は信用を裏切らないようにすることと認識しているなどと話した。
一方,原告のC専務は,被告に対し,当初お約束いただいた①期限は守られるのか,②費用は予算内に収まるのか,③日本の銀行の標準機能として持つべき機能は実現されるのか,この3点につき,当初の計画どおり対応してほしいと話した(甲6の12)。
(イ) 同年11月11日に開催された第13回ステアリング・コミッティにおいて,被告が,前回のステアリング・コミッティで報告したとおり,被告,IBMアジア・パシフィック,FIS社を含めたチームにより最適な開発手法の検討を開始したと報告したのに対し,原告は,プロジェクトを遅延させない,サービスインの期限を守る,本件最終合意書で約束したことを守っていただく上で効率化を図るための提案であれば承認すると述べ,被告はこれを了解した。
また,被告は,①FIS社との検討会は,被告内でもこのままこのプロジェクトを進めてよいかという意見もあり,FIS社のアドバイスをきちんと受けて,これから先を確実に進めていくために実施したものである,②プロジェクトにある前提条件を変えることは考えていないと述べた(甲6の13)。
(ウ) 被告は,同年12月12日,原告に対し,開発方法及び開発内容の変更を提案した。その提案書である同日付け「貴社「新経営システム」構築プロジェクト プロジェクト見直しのご提案」と題する書面には,次のような記載がある(前記前提事実(9)イ,乙5)。
a ご提案の背景
(a) これまでの本件プロジェクトの進め方は,Corebank機能の理解及びCorebank機能を最大限活用する開発手法の確立が不十分であったため,現行機能をベースとした機能要件をCorebankを使って開発するという「現行踏襲型アプローチ」となっていた。
(b) Corebank開発元であるFIS社及びIBMアジア・パシフィックのパッケージ・ベース・アプローチ有識者によるプロジェクト・レビューの結果,現在の進め方では,①Corebankパッケージ機能を最大限活用できなかったことにより,柔軟性,拡張性及び品質の確保ができない,②平成20年1月の安全的・成功裡なサービスインに対して,開発ボリュームが適正値を超えている,③原告,被告両者の投資金額の上限を超える可能性があるという三つのリスクが内在することが判明した。
b ご提案の骨子
(a) Corebank機能の最大限の活用
① FIS社の実績ある開発手法(パッケージ・ベース・アプローチ)の採用により開発リスクの最小化を図るとともに,Corebank機能及びFIS社の実績,経験を最大限に活用することによりパッケージ機能を最大限に享受する(FIS社メンバーを直接プロジェクトに参画させる。)。
② 要件をパッケージ機能と追加開発で実現するのではなく,パッケージ機能が存在するエリアの中に要件を収束させることにより拡張性,柔軟性を確保すると同時に横展開可能なシステムとする。
(b) 開発ボリュームの適正化
「開発ボリューム=スコープ×品質」の考え方において,「品質」を維持しつつ平成20年1月の安定的,成功裡なサービスイン(=「開発ボリュームの適正化」)を実施するためには,次のとおり開発スコープの見直しを実施する。
① ビジネス目標達成のための業務要件の実現にフォーカスし,開発スコープを縮小する。
② 既存システム対応も含めた原告,被告双方合わせた全体最適の観点及び個別業務要件ではなく最終的なビジネス目標達成の観点から,安定したサービスインを迎えるための最適ソリューションを検討する。
(c) サービスイン後の保守容易性の確保とスキル移管の促進
① サービスイン後のメンテナンスを効率化するために,カスタマイズ,作り込みを極小化する。
② SCSメンバーの再配置による原告体制下での開発実施により,サービスイン後の保守容易性を確保する。
(エ)a 平成18年1月11日に開催された第14回ステアリング・コミッティにおいて,被告のF専務は,「1月以降の作業計画について」と題する資料により原告に対する提案をした。F専務は,基本的な作り方についてのコンセプトとして,できるだけ手作りをやめてパッケージの機能を利用することで,変革のテーマを始めとする新要件・機能を実現しつつ,開発スピードを上げる,保守性を高める,NEFSSユーザ拡大時の自由度を高めることがねらいであること,平成20年1月に本番稼動を迎えるために,NEFSS/Corebankのソリューション機能をどのように活用すればいいのか,開発内容全てをテーブルに上げて整理させていただきたいということがこの提案の主旨であると説明した。
これに対し,原告は,被告作成の上記「1月以降の作業計画について」と題する書面の中で「③2008年1月の確実なサービスインへ向けた開発量の適正化」と記載されている点について,①これが要件の削減を意味しているのであればこの提案を受けることはできない,②本件プロジェクトの目的は,変革のテーマを実現することにあり,変革のテーマを削減して単なるオープン系システムに作り替えるということではプロジェクトを行う意味がない,③開発量の最適化については,あくまでも合理的な提案であれば受け入れる余地はあるが,単なる削減では受け入れることはできないなどと述べた。また,原告は,以前約束していただいたとおり変革のテーマについては,全て実現すると言っていただきたいと伝えたところ,被告は,業務要件を削減することはしない,深さについては相談させていただきたい,あくまでも平成20年1月本番稼動をうまくいかせるためにどうするかという観点で合理化案について検討させていただきたいと答えた。さらに,原告は,BRDを実施することのメリット,リスク,BRDを実施しないことのリスクなどを明確にしていただき,原告として判断できる提案書を提示いただきたいと述べた(甲6の14)。
b 被告は,上記ステアリング・コミッティにおける原告側からの意見を踏まえ,平成18年1月26日,原告に対し,「貴社「新経営システム」構築プロジェクトにおける1月作業のご報告とご提案」と題する書面を交付し,平成20年1月のサービスイン,「プロジェクト憲章」の「プロジェクトの目的」を達成するシステムの構築を目的として,開発計画の見直しの提案をした。この提案では,14週間のスケジュールを予定するBRDの進め方の方針として,IBM傘下にFIS社を入れ,FIS社のスキルを有効に活用するためFIS社の方針で進めていくこと,BRDは現在の要件定義書をベースに合理的なソリューションの検討を行うことが挙げられていた(乙198)。
また,現状の開発手法における問題点として,次のような指摘がされていた。
(a) Corebankの優位性が十分活かされないシステム
現状の開発手法は,現行のシステム機能の分析結果をベースに変革のテーマ等の新規要件を組み込む形態をとっており,Corebankの最も顕著な優位性である柔軟な商品開発や新商品の迅速な展開という側面において,Corebankのメリットを十分発揮でき得るシステム形態とならない懸念がある。
現行の原告の事務・システム機能をベースとしてCorebankの機能の適合性を検証するというアプローチを採用し要件定義を実施したため,Corebankの持つポジティブ・ギャップ(現行システムには存在しないが,Corebankが製品として保有する機能)を有効に活用する検討が十分されていない懸念がある。
(b) Corebankスキルの欠如
Corebankのパッケージ仕様に精通した要員がプロジェクトに参画していないことから,Corebankの適合性判断における品質について懸念がある(製品知識が十分でない部分があるため,特に明確なFit,明確なGap以外のグレー部分における判断においてCorebankを利用した代替策等の検討が不十分な箇所があると認識)。
Gapの実現方式がCorebankのコンセプトやアーキテクチャーと整合性がとられた方式であるということの技術的な検証が不十分であり,後続局面(開発やテスト)で問題として発覚する懸念がある。
(c) システム複雑度合いの増大
Corebankを有効に利用できずGapの作りこみが大きくなることが結果としてCorebankの外側に作りこむプログラムの増大につながり,システム全体の複雑度合いが増大する結果となる懸念がある。
開発するシステムが複雑になるほど,開発要員のコントロール,テストケースの複雑さの増大等につながり,プロジェクトの品質と成功裡なサービスインに影響を与え得る懸念がある。
(d) サービスイン後の保守
Corebank機能の利用を前提とせず,大きな作りこみを多数することにより,将来的にパッケージの機能拡張の際にスムーズに製品のバーション・アップ等が図れなくなる懸念がある。
(オ) 平成18年2月9日に開催された第15回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の15)。
a 被告は,グローバルIBMのSI部門のレビューメンバーが来日して,本件プロジェクト全体のレビューを実施したことを報告した。被告は,上記レビューにおいて,①計画・要件定義#2で基幹系について現在作成されている要件定義書を基にそのまま設計・実装を進めた場合,ⅰ)新処理フローの記述において,Corebankに整合しないフローとなっている可能性があり,実装段階でその不整合が顕在化するリスクがある,ⅱ)Corebank機能及びメリットを十分に享受できないシステムとなる可能性がある,ⅲ)横展開可能な「邦銀標準」としてのシステムとならない可能性がある,②システム化対象範囲が基幹系だけでなく,CRM,DWH,投信ほか極めて多数のコンポーネントの一斉サービスインとなっているが,安全かつ確実なサービスインに向けての検討が不十分であると指摘を受けた。
b 被告は,上記指摘を受けて,従前提案していた全面的なFIS社(IBM傘下)方式による14週間のBRDではなく,被告主導によりFIS社のCorebankスキルを十分に活用した上で,邦銀標準を確立すべくBRD作業を実施し,併せて,安全かつ確実なサービスインへ向けての切替の検討作業を優先的に実施したいと考えていることを原告に伝えた。
c そして,被告は,上記①のリスクを回避する目的で旧BRD作業を,上記②のリスクを回避する目的でシステム切替検討作業をそれぞれ実施したいと提案した。旧BRD作業の実施内容の概要として挙げられたものは次の(a)~(e)であり,システム切替検討作業の実施内容概要として挙げられたものは次の(f)~(h)である。
(a) 原告の新業務フローの作成(被告及び原告)
原告の要件定義書及び事務取扱要領を基に新業務フロー(代表的な業務及び変革テーマにより変更される業務を中心)を作成。
(b) 邦銀標準の抽出(固有部分の特定)(被告及び原告)
他行事務との比較をし,邦銀標準プロセスを抽出,原告固有部分を特定。
(c) Corebankとの整合性確認(被告及びFIS社)
FIS社と協業して,業務フローを基にCorebankとの整合性の確認及びポジティブ・ギャップの抽出を実施。
(d) 原告要件と邦銀標準との差異(被告及び原告)
邦銀標準と異なると判断される部分については,邦銀標準に極力合わせるよう原告で検討をお願いしたい。その際,ユーザインターフェースの変更や業務プロセスの変更を伴う場合がありますが,検討,協力をお願いしたい。検討の結果,原告にて合理的と判断された場合には,邦銀標準への適合をお願いしたい。変革のテーマなど原告固有の要件については個別に設計,実装する。
(e) BRD結果を基にCorebankの特性を反映した設計工程の作成(被告,FIS社)
FIS社と協業して後続工程(設計作業)を作成。
(f) サブシステム間の相互依存関係の分析(被告)
要件定義書を基にサブシステム間の相互依存関係を分析し,サブシステム間の関連を明確にする。
(g) テスト計画の作成(被告及び原告)
サブシステム間依存度を考慮したサービスインまでのテスト計画を作成する。
(h) 段階切替の検討(被告及び原告)
サブシステム間の依存関係を基に段階切替(先行リリース,後続リリース)の案を提示し,安全かつ確実なサービスインの実施を検討する。
d 被告は,原告に対し,①カスタマイズをどれだけ抑え,その上で原告の要件をいかに満たすかが大きな課題と認識している,②他行の事例でも過去に大量の工数をかけカスタマイズを行ってきたシステムを,カスタマイズしたがゆえに複雑になりすぎて保守できない,保守要員を確保できないといった理由から,現在は本来のパッケージの姿に戻そうという動きになっている,③被告としては,全力を挙げて取り組み,何が何でも乗り越えるつもりであるなどと伝えた。
e 原告は,被告に対し,事務の標準化について,原告は独自性を大事にしている会社であり,現状からダウンすること,あるいはお客様に影響を与えることは許されないこと,この点については譲れないと考えていることを伝えた。
これに対し,被告は,現実には変えていかないといけない事項も出てくると考えていること,そのときに短期間で決めていくためのルール作りも必要と考えていることを伝えた。
f 被告は,原告に対し,旧BRDはこれをやっていくしかない本流の作業として考えていると伝えた。
g 原告と被告は,被告から提案があった旧BRD作業とシステム切替検討作業を実施することを決定した。
イ 旧BRDから新BRDまでの経緯等
(ア) 同年3月8日に開催された第16回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の16)。
a 被告のF専務は,①これまで手作り開発になれてきたこともあり,パッケージをベースとした開発をうまく推進できず,業界標準からずれた形の成果物となり,プロジェクトの進捗にも影響を与えたことに関してはお詫び申し上げる,②しかし,良いシステムを早く作る,そのためには品質を確保する必要があり,BRDとシステム間相互連携を意識した検討は必須と考えており,この作業を通して全体のデザインを見直し,日本の銀行の標準システムをCorebankを活用して構築したいと考えている,③現在,被告だけでなく,グローバルの力を結集して進めており,不安を感じている方もおられるかしれないが,平成20年1月にCorebankで動かすということで進めているのでよろしくお願いしますなどと挨拶した。
b 被告は,原告に対し,旧BRDとシステム切替検討実施に至った背景として,①平成16年10月の本件プロジェクト開始以降,被告においてパッケージベースの開発方法論を確立できず,計画・要件定義局面において現行機能ベースの開発を前提とした作業となってしまったため,Corebank機能の最適活用と横展開可能な標準化が推進できていなかったこと,②被告において一斉サービスイン(全店全業務一斉移行)のリスク評価を要件定義期間中に実施できなかったことがあったと報告した。
c 被告は,旧BRDの作業計画について,平成18年2月16日以来打合せを実施した結果,同年3月3日までに,次のとおり予定していた作業及び合意事項が達成したことを報告した。
(a) BRD作業計画(BRD実施の目的,BRD作業を進めるに当たっての方策,BRD作業内容,スケジュール)を確認,合意
(b) 対象業務フロー選定について検討,協議合意
(c) 新業務フローの策定上の指針
d 旧BRDの作業概要は,次のとおりとされた。
(a) 方針策定
新業務フロー策定上の指針案,対象業務案についてのたたき台は被告が作成し,原告と協議・検討の上,確定させる。
(b) 業務フローの検討
①現行要件定義書,業務手続(Palette)をベースに新業務フローを作成する,②新業務フローの見直し案については,FIS社要員,邦銀業務精通者を交え,被告にて作成する,③新業務フローの見直し案の提示に当たっては,メリット,デメリットを合わせて提示し,原告と協議,検討の上,決定する。
(c) 商品定義の検証
①10~20程度の商品選定のたたき台は被告が作成し,原告と協議,検討の上,確定させる,②FIS社にて要件定義書を基に商品定義を実施し検証する,③直しが必要な場合,原告と協議,検討の上,決定する。
(d) アクティビティー図の修正
見直しとなった業務フローを基に修正が必要なアクティビティー図(Lv5)を特定し,修正する。
(イ) 平成18年3月8日,第16回ステアリング・コミッティで旧BRD作業計画が承認されたことを受け,旧BRD作業が開始された(前記前提事実(9)イ,甲6の16)。
(ウ) 同年4月5日に開催された第17回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の17)。
a 被告のF専務は,旧BRD,切替・移行計画検討もおおむねスケジュールどおり進んでいる,一部FIS社との作業分担を詰める事項が残っており,遅れているものがあるが,キャッチアップ可能と考えていると話した。
b 被告は,原告に対し,旧BRDの作業について,商品定義検証作業にてFIS社との作業調整がつかず遅延が発生していること,当初3月21日の週から21商品に関して実際にCorebank上に商品定義作業を実施予定であったが,個別に商品定義作業を実施する以前に,全商品定義に関し,商品定義の粒度及び要件定義局面で識別されているGAPについて影響度(制度対応,顧客影響,事務影響)及び独自性(邦銀標準,原告固有)の観点から分類作業が必要と判断し,同作業をFIS社と共同で実施中であること,個別の商品定義の作業については4月から順次着手予定であることを報告した。
c 原告は,被告に対し,制御グループ,基盤グループの作業に関して,BRD実施後にマスタースケジュール見直しとあるが,旧BRDによりスケジュールが遅延するとは認識していないし,BRD実施を原告が了解した条件は,スケジュールが遅延しないことであった,BRDを実施してもスケジュールは遅延しないという認識でよいかと質問した。これに対して,被告は,原告に対し,ここでのスケジュール見直しは,旧BRDの結果により作るものや作り方が変わった場合,その変更内容を反映するというものであるとか,平成20年1月の一括サービスインに変更はなく,切替・移行計画検討はあくまでコンティンジェンシープラン策定タスクとして検討をしていると答えた。
原告は,被告に対し,平成20年1月に一斉切替を行うことは契約済みの事項であることは再認識していただきたいと述べたところ,被告は,了解していると答えた。
d 原告は,切替・移行計画の検討について,コンティンジェンシープランというのは,あくまでも平成20年1月に本番稼動することを前提としてのコンティンジェンシーという認識でよいかと質問したところ,被告は,結構であると回答した。
(エ) 平成18年4月11日に開催されたプロジェクト進捗会議において,次のようなやりとりがされた(甲139)。
a 被告は,BRD作業におけるFIS社の参画スケジュールについて遅延が生じており,商品定義検証作業とCorebankの観点からの業務フローの見直し案作成について未着手となり,5月末のBRD作業完了に懸念が生じていると報告した。
b 原告は,被告に対し,FIS社との契約は何について合意できない状態なのかと質問したところ,被告は,作業内容や費用面の条件で折り合いがつかなかったと答えた。
c 原告は,FIS社の参画なしでBRDは進められるのかを質問したところ,被告は,FIS社の参画は必須であり,BRDも進める,FIS社に参加してもらうことで社内で動いていると答えた。
d 原告は,現在のBRDの方向性はこれでよいのか,当初の目的として工数削減があったと思うが,現時点での検討結果を見ると,工数面ではむしろより良いものを開発することで工数が増えていると思われると質問したところ,被告は,横展開の観点から,追加費用及び原告側工数増加は発生しないため問題はないと答えた。また,原告は,邦銀標準の観点からも,もっと大幅な見直し提案があってもよいのではないかと考えていると提案した。
(オ) 被告は,第16回ステアリング・コミッティにおける旧BRD作業計画承認に基づき,①Corebank機能を最適活用する(業務フローのCorebankの観点からの見直し及び商品定義の検証),②マーケット価値を訴求できる(他行に横展開可能な)日本標準の業務を標榜し,要件定義書を洗練するという二つを目的に旧BRD作業を実施してきたが,IBMスペシャリストの検証により,旧BRDのアプローチでは十分にパッケージ・ベース・アプローチに沿っていないため,作業の変更が必要と判断するに至った。
そこで,被告は,平成18年4月14日,原告に対し,上記スペシャリスト検証を踏まえ,①本件プロジェクトは原告のみならず被告にとっても最重要であること,②当初の計画に基づいて本件プロジェクトを継続することでは成功裡にサービスインを遵守することは難しいこと,③本件プロジェクトの複雑さを考慮し,成功裡なプロジェクト完遂のために新しいアプローチが必要であること,④新しいアプローチの最初のステップが新BRDとなり,これはパッケージ・アプローチに準拠することを報告した上,新しいアプローチの新BRDに移行したい旨を説明した(甲6の18)。
(カ) 被告は,同月28日,ソリューション設計の簡素化及びCorebankの最大活用を目的として,被告の実績あるパッケージ導入アプローチを適用し,原告,被告及びFIS社の3社の参画によりプロジェクト体制を再編成した上,「要件定義の再利用評価」,「棚卸し及びCorebankとの対比」,「Corebank適合化」並びに「計画とスコープ」から成る新しいBRDの実施を原告に対して提案した(甲6の18,乙230)。
(キ) 同年5月10日に開催された第18回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の18)。
a 被告のF専務は,①これまで古い方式で作成した要件定義書を基に作業を進めてきたが,日本の銀行システムの標準を作るという点から新たなやり方を模索してきた結果,ビジネス要件を満たすためには新BRDが最適であるとの結論に至った,②新BRDでは,グローバルIBMからパッケージ・ベース・アプローチや銀行業務に精通した要員が参加するなどと述べた。
また,被告のJ常務は,①昨年9月よりCorebankを有効活用するためにパッケージ・ベース・アプローチで進めるということできたが,開発手法が固まらないまま進めてきてしまった,②Corebankの位置付けも定まらないまま,2回ほど進め方も変更し,また,今回新BRDとして仕切り直しをお願いすることについて大変申し訳ない,③新BRDについては本件プロジェクトを正しい軌道に乗せるベストの方法と考えている,④本件プロジェクトではこれまでパッケージベースと言ってきたが,やり方を間違えていた,⑤被告においては,製造業や流通業でのパッケージ・ベース・アプローチの経験はあるが,銀行システムをパッケージベースで開発するという経験がないため,グローバルIBMからCorebankを熟知している者,パッケージ・ベース・アプローチの専門家を集めている,⑥昨年9月の合意書については,費用,スケジュール,スコープを含めて原告の要件が記載され,扱いについても会社間で合意したものと認識している。新BRDの中で合意書に記載されたビジネス要件をパッケージ・ベース・アプローチでいかに実現するか検討を進めていきたい,平成20年1月にどういう形で実現できるか,原告のリクエストを聞きながら進めたいなどと述べた。
b 被告は,原告に対し,旧BRDの状況として,①商品定義検証作業,Corebankの観点からの見直しについては,FIS社との契約の関係上実施できなかったこと,②この点については当初計画していた実施方法ではなく,新BRDの中で実施予定であること,③当初予定した3タスク(業務フローの見直し,商品定義検証,アクティビティー図修正)のうち,現時点では業務フローの見直しのうち現行要件定義をベースとした業務フロー作成及び邦銀標準の観点による見直し案作成については完了したが,Corebankの観点による業務フローの見直しについては実施できなかったこと,④邦銀標準の観点からの見直し案については,原告側で検討を実施していることを資料に基づいて報告した。
これに対して,原告は,①なぜCorebankの観点からの見直しが実施できなかったのか,なぜ新BRDではできるのか説明されたい,②契約上の関係とはどういうことか,③旧BRDでは後半の契約ができなかったということは,最終的な契約ができないのに旧BRDの実施を提案したのか,④新BRDでも6月になって契約ができずにやめたということはないのか,⑤新BRDでは大丈夫だということをどう信じればいいのかなどと述べた。
被告は,①契約ができなかったことは,旧BRDのやり方が間違っており,社内の承認が下りなかったためである,②旧BRDは,要件が決まったものを主としてパッケージに合わせるという考え方であったが,新BRDは,パッケージを主として合わせるものと,独自のものを切り分けるという考え方である,③旧BRDのままでは,どれくらいの開発ボリュームになるか分からない状況であったなどと答えた。
c さらに,被告は,原告に対し,新BRDの概要として次のとおり報告した。
(a) 新BRDの目的は,①Corebankを最大活用し,ビジネス要件をCorebank機能に極力合わせる,②邦銀標準の銀行基幹系システムを確立する,③安全な切替・移行計画を策定するという3点である。
(b) 上記目的を達成するための方策として,①BRDフェーズではIBMの実績あるパッケージ導入アプローチを適用する(ビジネス要件を理解する,ビジネス要件の優先順位付けを実施する,戦略要件の実現のためのギャップ(差異)を特定する,戦略要件以外のエリアは業務プロセスをCorebankに合わせる,原告業務担当者とFIS社との参画により実施する),②旧BRDの業務フローをインプットとし,検討未済分については,邦銀標準精通者の参画により補う,③旧切替・移行検討タスクでのアウトプットをインプットとし,IBMスペシャリストを交えてソリューション設計の簡素化を含めて検討するという点が挙げられる。
d 原告は,被告に対し,新BRDの目的について,ビジネス要件をCorebank機能に極力合わせるとあるが,これはビジネス要件をCorebank機能に極力合わせて実現するということでよいか,と質問したところ,被告は,御指摘のとおりであると回答した。
また,原告は,新BRDの目的は本件最終合意書の実現であり,そのために旧BRDと同様にCorebank機能の活用や邦銀標準の確立を目指し,新BRDはあくまでもその手段であるが,具体的な作業方法を提示されていないため,今後作業内容を協議,合意した上で実施するということでよいかと質問した。これに対し,被告は,①そのとおりであり,考え方,基本方針は変わらない,ビジネスニーズも変わらない,プロセスや作りが変わるものである,②パッケージの機能に合わせるものについては細かなレベルでは変わる可能性はあるが,ニーズそのものが変わることはない,③今までの現行機能をベースとしたものではなく,パッケージベースとなるので,要件定義書のLv.5のような実現方式については変更となる,また,合意書についても,ビジネス要件だけではなく,実現方式について記載されている部分もあり,その部分は変更となるなどと答えた。
さらに,被告は,パッケージに合わせることを検討する際には,①銀行システムの基本となるもの,②邦銀標準となるもの,③原告が他行との差別化のために独自に有するものの三つに分けて進めるものであるところ,戦略的なものについては作るが,極力パッケージに合わせて使ってもらえないかと考えている,海外のパッケージが扱っていない商品,サービス,機能だからといって,それらを削ることはないなどと話した。また,被告は,要件定義書については,実装するときのValidation用資料となること,そこで記載された要件は,場合によっては手作業になったり,機能レベルで実装されないものが出てくる可能性があるが,銀行との合意なしに勝手に削ったりはしないなどと話した。
e 原告と被告は,新BRDを実施することについて合意した。
(ク) 平成18年6月2日に開催された新BRDキックオフ・ミーティング(第19回ステアリング・コミッティの代替)において,被告のJ常務は,①新BRDの検討では,1年半掛けて分析,設計を行ってきたこれまでの成果を踏まえ,原告のこれからの20年,30年の経営を支えるシステムを作っていく,②実装の仕方は変わるかもしれないが,何をやるか,実現すべき要件は,新BRDになっても変わらない,③NEFSS/Corebankを最大限活用するために開発のやり方を変更するものであり,本日のキックオフ・ミーティングはその方針確認に対する参加者の意識を揃えることが目的である,④BRDにより,ⅰ)いかにパッケージに合わせて要件を実現するか,ⅱ)サービスインについてどういう形でやるのが確実か,この2点を明らかにするなどと挨拶した。
また,同会議において,新BRDプロジェクトの目的,プロジェクト体制,検討範囲及び会議体が決定された(甲6の19)。
(ケ) 被告のF専務は,同月29日,E副社長及びC専務と打合せを行った。E副社長は,最初からパッケージベース開発ができると思ってIBMにお願いしていたにもかかわらず残念であると述べた上で,平成20年1月にサービスインができるのかを尋ねたところ,F専務は,現時点では分からない,いかにパッケージ/邦銀標準に合わせられるかが鍵であると答えた。また,E副社長は,初期費用に関して追加費用を要求するのかを尋ねたところ,F専務は,「現時点では分からない。ビジネス要件は基本的に実装するが。IBMも70億近い投資を予定しており,BRDでこの投資内に収めるようにしたい。」と答えた(乙285)。
(コ) 平成18年7月5日に開催された第20回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の20)。
a 被告は,原告に対し,Corebank業務チーム・ディスカバリーステージの結果について,資料に基づき次のとおり報告した。
(a) ディスカバリーステージの期間中,業務チームは現在の原告の商品,業務プロセス及び変革のテーマについての検討を行った。業務チームは,現在の原告の機能,業務プロセスがCorebankが提供する機能やプロセスと異なる部分についての特定を実施した。これら特定された項目は,Gapとして個々のチーム(預金,融資,顧客)のセッションの中でリスト化され管理されている。
(b) FIS社及び被告の業務チームは,現在これらのGapを調査し,Gapの妥当性の確認及びどのような変更がGapを解決するために必要とされるかという点についての分析を行っている。この分析の一環として,FIS社及び被告から,原告に対し,銀行の業務プロセスや業務手順の変更を行うことが可能と思われるもののリストを提示する予定である。この作業を支援する位置付けとして,現在原告の業務チームメンバーがGap内容を分析し,Gapのカテゴリー分けと優先順位付けを実施している。カテゴリー分けによる分類は,①法定に起因するもの,②既存のお客様に影響のあるもの,③現行の業務プロセスに影響のあるものに分類する予定である。
b 原告は,被告に対し,①マル優など以前から分かっているGapではないか,これではゼロからギャップ分析を行っているようなもので,新BRDは手戻りであり時間の無駄ではないのか,②新BRD以前に担当されていたメンバーを戻してやった方が効率的ではないのか,Compilationステージは,過去担当していたメンバーや投入することも含めてもっとやり方を考えるべきである,③以前のFit&Gap結果の資料や人材の有効活用についてはこれまでもお願いしてきた事項であるなどと意見を述べた。
これに対し,被告は,①ギャップについて,その理由や必要性をFIS社が認識できたことは,今後FIS社がギャップの解消方法を検討していく上で有意義であったと考える,②過去担当してきた者ということでは,全員ではないがキーマンを残している,③以前のFit&Gap時の成果物は英訳し,活用していくなどと回答した。
c また,原告は,被告に対し,話を聞いているとCorebankに合わせろと言っているように聞こえるが,原告は,他の銀行よりも柔軟に対応することで生き残っている銀行であり,原告独自の機能の実現は必須であるし,同時に日本の銀行として当然備えるべき機能も実現する必要があるから,Gapのカテゴライズにある①法定に起因するものについては「ねばならないMUSTの機能」であり,②既存のお客様に影響のあるものについても同様に「MUST」である,③業務プロセスに影響のあるものについては,もっとディスカッションを行う必要があるなどと述べた。
これに対し,被告は,Corebankは,①顧客志向のシステムであること,②商品定義を柔軟に行えること,③商品のパッケージ化が容易であること,④経営の意思決定判断のために必要な情報を提供していることといった特徴を持っており,原告の要望におこたえできるパッケージソフトであることをお伝えしたいと述べた。加えて,被告は,①カテゴライズのうち法定に起因するものについてはFIS社と被告で対応する,②業務のプロセスについては,きちんとした分析をすべきであり,その上で原告への影響が小さいことが分かればCorebankの仕様に合わせてもらうことを推薦することもある,③独自性を保持するために必要なものは当然変える余地はないなどと答えた。
原告は,業務プロセスについては具体的なものが出てきていないので判断できないが,合理的な提案であれば変えることも考える,日本の銀行で標準的にやっているものについては実現していただくということでよいかと尋ね,被告は,結構であると答えた。
d 新BRD局面において発見されたCorebankグループのギャップの解決策やnon-Corebank/Technicalグループの合理化案について,被告とFIS社において作成し,それを原告に提案するということとなった。
(サ) 同年8月9日に開催された第21回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の21)。
a 被告のF専務は,①パッケージに合わせることについては,原告の協力に感謝する,②無駄を多く省くことができたと認識している,③BRDを実施して良かったことは,開発スケジュールがどのようになるか具体的に見えてきたことである,④平成20年1月の一斉切替については,全面切替は厳しいが,どういった形でできるのか,現実解としてもどこにも迷惑をかけない健全な方式を決めるために議論を進めていきたいなどと挨拶した。
また,被告のJ常務は,①174件のギャップが洗い出され,うち46件については,いかにCorebankに適用させるか検討させていただいた,うち20件について代替策を導き出した,②non-Corebank,テクニカルについては,提案内容の6割から7割程度を採用いただき,前向きな協力に感謝する,③切替・移行計画におけるスケジュールの短縮については特別な効果を導き出せておらず,現在,技術的に詰めた二つの案を担当者間で議論させてもらっているが,原告の平成20年1月からのビジネスニーズと突き合わせしながら,開発のフィージビリティも考慮し,現実的な案をまとめていきたいなどと挨拶した。
b 被告は,原告に対し,切替・移行計画について,当初の一括切替案について,FIS社と被告の技術者が細かな検討を行ってきたが,全員一致で,全てのことを一度に行うことは正当化できないリスクがあることが分かった,一括切替を平成20年1月に行うことは無理で,本日提示する二つのオプションこそ,リスク面,機能面等を考えた中で最もバランスの取れた案と考えると述べた。
原告は,BRD開始時に平成20年1月のサービスインに間に合わせるための唯一の道だと説明を受けたが,結果としてそうならなかった理由を明確にしていただきたいなどと述べた。これに対し,被告は,①Corebankがどこまでできるのか,これまで被告は分かっていなかったが,BRDにより肌で感じることができた,②これから立案するスケジュールは実現性が高いものと考える,③BRD実施前後を比較すると,当時思っていた以上にリスクがあることが分かった,④スケジュール短縮の期待はあったが,Corebankだけでなく,周辺も含めて考えると,2案以外にないのではないか,⑤BRDを実施する前に比べて見積り精度が上がっており,これならできるという担当者の納得も,Corebankの活用の確信度合いも違うなどと述べた。
C専務は,メンバーが不安に感じている,被告は最初からなぜBRDをやらなかったのか,遅れることによる出費,要員確保などをどうするのか,そもそもこれまで原告は被告に従ってプロジェクトを進めてきた,遅れたことの原因と責任が被告にあることについて,原告として譲る気はない,したがって,追加費用が発生しても原告は一切負担しない,被告のプロジェクトの進め方に問題があったのではないか,Corebankについて被告は十分理解していなかったのではないか,だからFIS社を入れてBRDを実施したのではないかなどと発言した。
被告のブロッシュは,責任の所在については被告の責任もある,どの部分が被告の責任か,また今後どう対応していくのかについて,別途打合せの機会を設けてほしいと述べた。
c 被告は,原告に対し,切替・移行計画として,リスク,投資,機能充足度等について検討した結果,二つの代替案を提示した。一つは,FIS社が提供するオンラインシステムと主要な周辺を先行してリリースし,後続においてバッチ及び残りの周辺を移行するという基幹系先行案であり,平成21年1月に先行部分リリース予定とされた。もう一つは,FIS社のパッケージの基本的な機能を使って戦略的な新商品を提供するもので,ビジネスの成長が期待できるとされた新商品先行案であり,機能,範囲が少なく時間短縮が可能なため,平成20年1月に先行部分リリースが可能とされた。
原告のC専務は,経営サイドとしては本日の案は受け入れ難いが,週末に新たな案を被告から出してもらえるということなので,それを拝見した上で議論させていただきたいと述べた。
d 原告と被告は,平成18年7月25日に打合せがされた次の3点の合意事項について承認した。
(a) 現行要件定義書をベースとしてBRD成果物を追加する。
(b) BRD成果物は現行要件定義書を代替するものではない。
(c) 新BRDでは現行要件定義書を修正しない。
(シ) 被告は,新BRDでCorebankとのギャップとして識別された174件のうち,現在実施している方式を継続するために必然的に発生してしまうギャップ若しくはCorebankのシステム機能根幹に関わるギャップとして識別された46件について,被告及びFIS社がCorebankに合わせた業務的な代替回避策を検討した上で原告に提示した。原告は,検討した結果,平成18年8月17日,そのうち20件について業務的代替回避策を採用することを決めたが,24件については業務的代替回避策の採用を不可と判断したので,Corebankを中心としたテクニカル・ソリューション(システム対応)によって対応することが決定した(甲44,69)。
(ス) 被告のK代表取締役社長(肩書は当時。以下「K社長」という。)は,同月31日,原告のA代表取締役社長(以下「A社長」という。)に対し,新BRDの終了を報告した上で,BRDの結果,平成20年1月のサービスインが難しい状況と判断していること,サービスインの時期が平成20年10月になる可能性が高いことを伝えた。これに対し,A社長は,K社長に対し,平成20年5月にはサービスインを実現してもらいたい旨伝えた。また,K社長は,A社長に対し,BRDの結果,コストも大幅に増えており,被告も先行投資をしていくが,原告にも費用面での今後御協力をお願いしたいと伝えた(乙155)。
(セ) 平成18年8月31日に開催されたBRD最終報告会において,次のようなやりとりがされた(甲26)。
a 同会議で配付された被告作成の「「新経営システム」構築プロジェクトBRD局面最終報告エグゼクティブ・サマリー」と題する書面中「BRDの概要」のBRDの主要目的の一つとして,(4)項に「当初想定投資の再見積りを行う」旨の記載がされていた点について,原告は,①後付けで目的を追加することは認められないので削除されたい,②追加した理由も最終合意を破棄するためであるのかなどと指摘した。これに対して,被告は,①プロジェクト推進にとって重要な事項であり,健全なプロジェクト運営とするために必要な事項ということで追記した,②本件はあくまで被告内部において再見積もりしたもので,BRD実施により,明確になったということを報告したかった,③BRD開始時点で目的として原告には提示していなかったが,BRDを通して作業工数を正確に理解することは被告としてBRD実施目的であった,④BRDを実施したからこそ,より正確に理解することができるようになり,これからどうプロジェクトを進めていったらよいか理解が深まったなどと述べた上で,上記の項目は,被告内部の事項であり,当初設定した目的にはなかったことなので,削除することとされた。
b 被告のJ常務は,当初のBRDの目的,期待値に対してできていないこともあることは認識しているが,基盤としては詳細なものができたと考えているし,本件プロジェクトが当初想定よりも複雑だということも認識できたなどと述べた。
c 原告と被告との間において,BRDはこの最終報告会をもって完了し,9月から設計フェーズに入ることが決定された。
ウ 新BRD終了後から平成18年12月末までの経緯等
(ア) 被告のF専務は,平成18年9月7日,原告のE副社長と打合せを行った。E副社長は,サービスインについて,平成20年5月に全てやってくれとは言わないが,なんとしても平成20年5月のサービスインを実現してほしいと伝え,F専務は,どうすれば可能になるのか最大限の努力をして検討していると答えた。また,F専務は,E副社長に対し,期間が延びることによる追加コストについては相談したいと伝えた(乙156)。
(イ) 原告と被告は,平成18年9月1日以降,切替・移行計画の案について集中検討を行っていたところ,同月12日に開催されたプロジェクト進捗会議においては,原告と被告のプロジェクトレベルで同月15日までに切替・移行案について合意形成できる見通しであったが,原告の経営陣に承認されるかは原告プロジェクトメンバーにも不明であった。その後,被告は,同月19日,原告に対し,4段階リリース案(平成20年1月から4段階に分けてサービスインをし,平成21年5月に全面稼動)を提案した。しかし,同案については,移行の最終段階(Step4)として計画していた口振,法定帳票,DWH,バッチ帳票のサービスイン時期(平成21年5月)について,原告の経営陣は了承しなかった(甲6の22,乙105)。
(ウ) 平成18年9月25日に開催された第22回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の22)。
a 原告は,同月19日に提案された切替・移行計画案について,平成20年10月,遅くとも同年12月までにフルスコープを実現していただきたい,現時点では平成21年5月については合意していないことをお伝えするなどと述べた。
b 被告は,平成18年9月19日に提案した切替・移行計画案から最終段階(Step4)として計画していた口振,法定帳票,DWH,バッチ帳票のサービスイン時期について,前倒しの可能性を探ってきた結果として,口振と法定帳票についてはStep3に前倒しすることを前提に今後の作業を進める予定であるが,DWH,バッチ帳票については現時点では前倒しができるとは申し上げられず,基本設計作業の中で見極めていきたいなどと述べた。
これに対し,原告は,前倒しについて言及できないのはおかしい,検討漏れがあったのかなどと質問したところ,被告は,BRDで注力したのは業務要件の確認であり,中心はCorebankとのギャップを明らかにすることであった,帳票,DWHについてはもう少しDB構造や各データソースを調べてから見極めたい,極力前倒しができないかということを検討したが,現時点ではそれに至っていないなどと答えた。
原告は,今まで十分な要員を投入せず十分な検討もされていない状況で,平成21年5月まで本番稼動が延びることは納得できないなどと述べたところ,被告は,原告,被告双方のメンバーでバッチ帳票のスペック,構築のスケジュールを2,3日で集中検討することを提案したいがいかがかと話した。これに対して,原告は,これまで被告の要望に沿って5000の帳票を大幅に減らしてきた,そのために小会議を繰り返してきたが,過去の経緯を軽視しすぎていないのか,新BRDの3か月間で帳票について具体的な検討がされてこなかったのが不満であるなどと述べた。
c また,原告は,サービスインの時期については,平成20年12月でなければ到底受け入れられない,どのように説明を受けようと平成21年5月リリースであるというのであれば原告としては協力できない,原告としては全体の完了が平成20年12月であり,段階的に進めていって全体の完了が平成21年以降になることは認められないなどと述べた。被告は,平成20年12月までにどこまでやるのかを今後検討させていただきたいと返答した。
d Step4のDWHと還元帳票については,平成20年12月本番稼動を目指して,どのようにすれば実現できるのか,1か月間の期間で検討を継続することとされた。
(エ) 被告のプロジェクトレベルのメンバーは,平成18年10月24日,原告のプロジェクトレベルのメンバーに対し,総額で1億1000万ドルの追加費用が必要で,そのうちの3000万ドルを原告で負担してほしい旨を申し入れた。原告のプロジェクトレベルのメンバーは,追加費用について,プロジェクトレベルで受け入れる余地はないと拒否した上で,C専務に上記申入れがあったことを報告した(甲146,乙103の1,307)。
(オ) 原告と被告は,同年11月9日に打合せを行い,そこで開発スコープの削減や追加費用負担についての話合いがされた(甲153,乙83)。
(カ) 原告と被告は,同月13日に開催された第23回ステアリング・コミッティにおいて,次のスケジュールで本件システムを稼動させるという基本的な方向性について合意した(前記前提事実(9)キ)。
a 平成20年1月:外為関連の新商品の提供に関するシステム稼動
b 同年5月:本件システムによる一部サービスの開始
c 同年10月:全営業店における基幹系システム稼動
d 同年12月末:本件システムの全面稼動
(キ) 被告のF専務,J常務らは,平成18年11月21日,原告のE副社長及びC専務に対し,本件プロジェクトのコストが大幅に増加していることを説明した上,スコープの削減と共に追加費用の負担についての提案を行った。具体的には,平成17年9月時点の見積もりが147億円(原告68億円,被告79億円)であったのが,現在316億円となっていること,見積増加分の169億円の内訳として,①有効活用が困難と思われる部分が54億円,②原告の現行システムへの対応で予想していなかったものが45億円,③コスト削減を予定していたが実現できなかった部分が10億円,④サービスイン時期延長によるものとして15億円,⑤想定以上に詳細設計以降のワークロードがふくらんだ部分として45億円であることを示した上で,二つのスコープ削減案とそれぞれの追加費用についての案を示した。しかし,原告が,上記提案内容は全く納得できないとの考えを明らかにしたため,提案内容についてのお互いの理解のすりあわせ,原告のコスト増加を含めたトータルコストの検討を原告と被告で至急実施することで合意した(乙310,311)。
(ク) 被告のF専務らは,平成18年11月30日,原告のC専務らと打合せを行った。その中で,F専務は,被告に対する支払以外に原告で必要となるコストについても検討したとして,被告に対する支払以外に非常に大きなコストがかかる状況であることを説明した。また,F専務は,開発スコープを勘定系に絞ったケースを想定すると,被告に対する追加費用約44億円のうち,10億円は被告が追加投資するので,34億円は契約してもらいたいこと,34億円に対しては,コミッション方式(ペイバック方式)を検討することを提案した。
原告と被告は,同年12月末までに現実的なスコープとコストを決めていくこと,方向性について社長同士のミーティングを持つことで同意した(乙294,312,313)。
(ケ) 同月1日,更新版要件定義書1式を含む基本設計に係る品物が,被告から原告に対して納品された(甲6の24)。
同月6日に開催された第24回ステアリング・コミッティにおいて,被告のJ常務は,基幹系詳細スケジュールについては同月15日に原告に納得していただける内容のものを提示したいと述べた。これに対し,C専務は,このプロジェクトは次世代のバンキングシステムを作るということで,大いに期待している,次世代にふさわしい良いシステムを作っていただきたいと述べた(甲6の24)。
上記ステアリング・コミッティと同じ日に,C専務とF専務は面談する機会を持った。C専務は,F専務に対し,被告側から出されている追加費用の負担の申出について,本件最終合意書の金額は被告から持ち出されて決めたものであり,被告が間違えたとか,Corebankを知らなかったからといって,費用をユーザの負担とするのは納得できないと告げた。これに対し,被告のF専務は,原告のC専務に対し,「普通の地方銀行が10年でやることを短期間で,しかもあの金額でやれるのか,無謀な計画で突っ走って来てしまった。」などと述べた。また,F専務は,最善の方法は,やめるわけにはいかないので,負担部分を一時原告に負担してもらい他の顧客がついたら被告から原告に返すというようなペイバック方式を確固たるものにすることであるなどと述べた(甲128)。
(コ) 被告のF専務は,同月11日,原告のC専務に対し,スコープ削減,追加コストのお願い等の提案をした。被告作成に係る同日付け「「新経営システム」構築プロジェクトの今後の進め方に関するご相談」と題する書面には次のとおり記載されている(甲7,乙295)。
a 本件最終合意書での計画が継続できなくなり,BRDを実施しなくてはならなくなった理由について,①パッケージ・ベース・アプローチが徹底されておらず,現行機能からの積み上げで要件定義を行ったため,パッケージ機能に整合しない仕様になっている可能性があり実装段階でその不整合が顕在化するリスクが認識されたこと,また,パッケージ機能及びメリットを十分に享受できないシステムとなる可能性が生じたこと,②システム化対象範囲が基幹系だけでなく極めて多くのコンポーネントに及び,かつ一括リリースとなっていたため,安全かつ確実なサービスインへ向けて多大なリスクが認識されたことが挙げられた。
b BRD実施後,再度プロジェクトの経過を見直す必要が出てきた理由として,BRDの成果自体は,期間短縮,工数削減に寄与したが,BRDの検討結果を踏まえて改めて計画策定,コスト見積もりを実施した結果,本件最終合意書時点での想定は,スケジュール,コストともに大幅に過少に見ていたことが判明したとされ,①スケジュールに関しては,残念ながら当初目標であった平成20年1月の一括サービスインが実現不可能であることが明らかになり,4段階リリース案を提案した,②BRDの検討結果を受けてコスト見積りの精緻化を行った結果,本件最終合意書締結時点の想定を大幅に超過することが判明し,開発規模(ピーク時の要員数等),両社の投資余力の観点から,フォーカススコープでの提案をせざるを得ない状況となった。
c 今後原告に追加で発生する総費用は,全スコープを実現する場合には,被告に対する支払費用127億円,それ以外に掛かる費用(サービスイン延期に伴う費用)約38億円を合計した約165億円である。また,今回提案しているスコープ(①金・公共債,端末管理,口振は原告が開発,②CRM,バッチ(帳票,法定帳票,リンクデータ)は現行システムを活用,③投信,DWH,外為,顧客営業支援は開発範囲見直し)の場合,被告に対する支払費用44億円,それ以外に掛かる費用(サービスイン延期に伴う費用,現行システムとのブリッジ開発にかかる費用,現行システムを残存させることに伴うIBMハード・ソフト費用,現行システムを残存させることに伴う他社ソフト費用)約66億円を合計した約110億円である。
d 今回提案したスコープで本件プロジェクトを実施することを承認していただきたい。
e 被告に対する追加費用として約34億円,残存及び追加ハードウェア,ソフトウェア費用(約19億円。サービスイン後5年間と想定したもの。)を平成19年1月中旬をメドに契約していただきたい。
(サ) 原告のE副社長と被告のF専務との間で,平成18年12月13日,開発スコープ及び開発費用について打合せが行われた。
F専務は,これまでの経緯を説明した上で,開発スコープは勘定系以外のスコープは全て削減し,その上で追加費用34億円の支払をしてもらいたいこと,この場合,被告以外への費用を含んだ原告の追加費用総額は約110億円以上となることなどを伝えた。これに対し,E副社長は,①当初の約束が全て反故にされたこと,②現行システムを残した二重オペレーションは費用,効率,サービス品質の観点から受け入れられないこと,③提案が受けられないならプロジェクトをストップするとの被告の発言によって被告への信頼が壊れたことを挙げて,このようなひどい提案は受けることができないので,これならもう本件プロジェクトをやめようなどと述べた。
F専務は,E副社長の説得を行い,原告から見た本件プロジェクトを続けるための条件を質問したところ,E副社長は,①二重オペレーションは受け入れられない,②周辺システムを実現すること,③追加費用は最大でも20億円であること,④平成20年10月又は周辺システムができたときに支払を行うなどと話した(前記前提事実(9)ケ,乙112)。
(シ) 被告は,平成18年12月22日,原告に対し,同月13日にE副社長と話し合ったことを踏まえて,開発スコープを同月11日の提案より拡大し,原告の追加負担費用額を20億円に減少させた案を提案した(前記前提事実(9)コ,甲28)。
(ス) 原告のC専務は,同日,被告のF専務に対し,電話を掛けた。その中で,C専務は,E副社長に同日の被告からの提案(上記(シ))を伝えたところ,E副社長からの課題として,フルスコープのソリューションを開発するケースでは,被告は,前回127億円を提案していたが,本日の提案では20億円の追加となったのであり,そのようになった合理的な説明とギャップを詳しく知りたいなどと申し入れた(乙320)。
(セ) 原告のHは,同日,被告に対し,本件プロジェクトの費用負担に関してメールを送ったところ,被告は,原告の追加費用が大きいこと,トータル費用が被告の投資よりも大きくなることも認識していると回答した(甲144)。
また,Hは,同月23日,被告に対し,「結果として当社の投資が御社より多いことに納得性が保つことが理解できない」,「あまりにも当社の負担が増大しリスクテイクしている現状であります」などと記載したメールを送った(乙210)。
(ソ) 原告のHは,同月26日,被告に対し,C専務からの伝言として,「費用について」「①当社の交渉が甘すぎた 20億の追加はしない」「②たかだが10日足らずの検討でここまで削減できるのならなぜBRD中に人員カットして検討しなかったのか」「③そもそも提示された金額がでたらめなものでありでたらめなまま当社経営にまで提示した責任はないのか」と記載したメールを送った。また,同メール内で,Hは,「資料見ましたが あれだけの指摘にも関わらず 意図的な虚偽の資料を作成しているのはIBMの投資の少なさを隠している悪質的な所作の結果と考えますので ここに通知します。具体的には 再三無視しているので記入しますが ハードウェアや追加投資他のNEFSS関連投資をグラフ上に記入せず 誤った判断をクライアントにさせようとしているということです」とも記載した(乙103の2)。
(タ) 原告のHは,C専務からの伝言として,「①たかだか数週間の検討の前と後の比較説明資料を提出してください」,「②20億は無しで進めてください。2億の話ですべて当社の中ではリセットされています。逆説的ですが120が20に簡単になったのですから検討すべきことはしましたので 残りは御社の負担でどうぞお願いします」と記載したメールを送った(甲92)。
(3)  平成19年1月以降の経緯等
ア TCBの提案まで
(ア) 原告は,被告からの20億円の追加負担の提案について検討した結果,当初の提案から107億円も削減できた正確な理由は被告に確認しないと分からないものの,①原告への作業移転,②被告作業自体の効率化であると思われ,被告が提案のあった20億円を負担としたとしても,原告の方が負担が大きいのではないかと考えていた(甲143)。
(イ) 原告は,平成19年1月5日,被告に対し,合意書案を来週月曜までに提示するように求めるとともに,これについて,①原告が追加費用として20億円を目処にするということはなく,この点をC専務と交渉しても無駄だと思うこと,②46億円の内訳の詳細を表示することが前提となることを伝えた(甲94,95)。
(ウ) 被告は,同月12日,原告に対し,支払総額を109億7080万円(本件最終合意書の金額に追加費用額20億円を加算した額)とする合意書のドラフトを提示した(甲96)。
原告が,被告に対し,20億円の内訳,根拠を提示することなどの要望を伝えたところ,被告において,検討して修正案を提示することとなった。
同日,被告は,原告に対し,上記20億円の追加費用のほか,SCSへの委託料10億円及び追いつき案件の対応に要する費用10億円の合計20億円を負担するように求めた(乙238)。
(エ) 同月18日に開催された第25回ステアリング・コミッティにおいて,次のようなやりとりがされた(甲6の25,甲50)。
a Hは,被告から提案されたスコープについて,これまでのステアリング・コミッティで説明も受けていない,また承認も得ていないようなものがなぜ突然出てくるのか,内容も結論のみ記載されており,なぜスコープ削減を行わなければいけないのか,その理由,目的,検討の経緯といった内容がない,きちっとした説明が必要であるとなどと述べた。また,C専務も,本件は契約に関わる根幹的な事項である,内容を見ると当初の合意内容を大きく覆すもので,この場で決定できるようなものではない,スルガは,これまで業務の見直しや帳票の削減等,コスト削減を図ってきた,BRD,新BRDについても同様であり,すべてIBMの要望に応えてきた,その上で現在の状況にあるのは進め方が悪かったのではないかなどと発言した。
b これに対し,ランドルトは,指摘のあった資料は,決定したものではなく現在の状況を説明するものであるとした上,実現可能なプロジェクトにするには作業の見直しが必要である,BRDを実施したが,時間,スコープの観点からみてデリバリ可能な状況ではなかった,契約と著しく異なっていることは認識しているが,本プロジェクトを実現可能なものにするには,真のインフラを築く必要がある,今回作業レベルでは,ソリューションについてスルガと前向きな検討ができたことを感謝すると述べた。また,Nは,当該資料は現場レベルでの技術的な検討結果をまとめたものであると指摘した。
c これまでの発言を受けて,C専務は,現場の作業を否定するものではない,本件はIBMの経営としてどう責任を取るかという経営マターである,本資料については,見直しの上,目的,理由,経緯等のコメントを付することをお願いすると発言し,これに対し,Nは,了解したと返答した。
(オ) 被告は,平成19年1月24日,支払総額を109億7980万円とするなど本件最終合意書の内容を変更する「新経営システム」合意書の案(甲97の1,2)を,改めて原告に提示した。なお,被告は,原告に対し,同日,CRMに関する追加費用(額は未定)及びeMuSC(インターネットバンキング)のパッケージライセンス料7億円などを追加負担することを求めた(甲98)。
これに対して,原告は,支払総額を従前のとおり89億7980万円とする合意書の案(甲99の1,2)を原告に提示した。
その後も,原告は,被告に対し,引き続き,20億円の根拠を示してほしいとの申入れをした(甲100,甲122の1)。
(カ) F専務は,C専務に対し,同年1月31日,CorebankについてFIS社のデリバリーが遅れる可能性が大きく,サービスインのスケジュールが現に合意している平成20年1月から平成21年5月になるリスクが大きいことから,「今月末までにスルガ様に結論を出すことをお願いしていた新MOU締結につき,その結論の期日を2月半ばまで延期させていただきたい」と申し入れた。これに対し,C専務は,IBMの責任でプロジェクトが迷走したにもかかわらず,なぜ原告に全ての責任を押しつけるのか,なぜもっとFIS社を早期からプロジェクトに入れなかったのか,平成20年10月のサービスインは平成18年10月に合意したことであり,これが平成21年5月になることは受け入れられないので,なんとしても平成20年10月にできるように検討,推進してほしい,FIS社は被告の管理下という位置付けであり,被告はFIS社を管理しているはずである,追加費用の支払について原告内部で承認を得るためには,当初プランよりも良いことが原告にあるという前向きのロジックが必要であるなどと話した。F専務は,C専務に対し,資料を準備の上,説明することを約するとともに,過去の約束を離れて被告の新しい提案を聞いてほしい旨依頼した(乙246)。
(キ) 平成19年2月17日,C専務は,F専務と面談し,被告から提案のあった追加費用20億円の負担について,①NEFSS-Corebankのシステムが他行に売れる度に,IBMとの共同開発の版権料として20億円に達するまでは1行当たり5%,それ以降は2.5%を支払う,②20億円の支払はシステム納入後の一括払とするとの条件を提示した(甲126,甲127の1,2)。
(ク) 同月19日に開催された第26回ステアリング・コミッティにおいては,遅延タスクについて,プロジェクトの週次進捗会議で進捗状況を管理し,早期解決を図ることとされた。なお,ステアリング・コミッティの席上,被告のLから,GAP開発についてFIS社と検討してきたが,まだ継続検討中である,GAPによる追加機能について,Corebankに何を作り,外に何を作ればよいのか,詳細を検討する必要があったため時間がかかっている,これが確定した時点でスケジュールも確固たるものとなると発言した(甲6の26)。
(ケ) 同年3月8日に開催された第27回ステアリング・コミッティにおいては,被告側から,詳細設計の開始に向けた準備状況,先行開発に向けた作業内容等の説明がされた。その中で,Lは,FIS社との役割分担について,最終的な決着がついていないと発言した(甲6の27)。
(コ) 同月19日,被告は,原告に対し,「「新経営システム」構築プロジェクトに関して」と題する書面を交付した。同書面には,要件定義及び現時点までの設計を進める過程でCorebankパッケージとの間で多くのギャップの存在が顕在化し,その200を超えるギャップが原告にとって不可欠のものであること,パッケージ開発元のFIS社と被告で開発の最適化を行った場合でも2年以上の開発期間を要することが判明したこと,特に融資系のギャップ解決に大きな時間と工数を要することなどの理由から,平成20年1月から平成22年1月までの5段階の段階的移行を内容とするサービスイン方式を提案する旨が記されていた(甲80,甲122の2)。
原告は,受け入れられる内容ではないとして,この提案を拒否した(甲125)。
(サ) 被告が平成19年3月27日に作成した週次進捗報告書(甲129の1ないし4)には,FIS社と被告との間でギャップ作業分担スコープ調整を行っており,ギャップスケジュールを作成中であると記載され,同じく同年4月3日作成の週次進捗報告書(甲130の1ないし4)には,FISチームがギャップ開発スケジュールを見直し中であり,取引実装チームにおいては,ギャップ作業スコープは確定したが,スケジュール調整は継続中であると記載され,同じく同月17日作成の週次進捗報告書(甲133の1ないし4)には,FISチームがギャップ開発スケジュール見直し中(22件分のみスケジュール確定)であるとの記載がされている。また,上記の各週次進捗報告書を含めて,その頃に作成された週次進捗報告書(甲129,130,132ないし134の各1ないし4)の遅延タスク一覧の遅延状況の欄には,取引実装のギャップ対応チームについて,「昨年10月よりWBS確定を依頼してきたが,IBM-FIS間の調整が完了せず,現時点でも確定していない状況」と記載されている。
(シ)a 被告は,平成19年4月18日,原告に対し,検討は初期段階であり更なる精査が必要になることに留意されたいとした上で,本件プロジェクトの代替案として,Corebankに代えて,Temenos社の基幹系パッケージソフトであるTCBを採用する案を提案した。その際に原告に示された被告作成に係る同日付け「「新経営システム」構築プロジェクトに関するご相談」と題する文書には,新ソリューションの採用により原告がメリットを享受し得る可能性について検討した項目中に次の記載がある(前記前提事実(9)シ,甲9)。
(a) 開発規模及びスケジュールの観点からリスクとなっている「融資のGap開発」において,ベンダへの依存度が低減するため,開発スケジュールの前倒しの可能性がある。
(b) 簡易言語(4GL)による開発のため,スキルの習得が容易であり,開発,保守の生産性に寄与できる可能性がある。
(c) 生成されたCOBOLコードにより,品質の向上,生産性の向上に寄与できる可能性がある(FIS社のCorebankの場合はAPI(部品)のみ提供されるため,APIの受け入れテスト及び取引としての実装,テストが必要)。
(d) コストについては,現在見積もりを実施しており,追加の負担に関しては別途説明予定。
(e) 新ソリューションを採用することにより,潜在的なリスクの発生を抑制できる可能性がある。
b この時点において,F専務は,FIS社と共にCorebankを使って本件システム開発をすることは候補から落ちたものと考えていた(証人F)。
(ス) 被告のF専務は,同日,全体の会議でTCBの採用に係る上記提案を行う前に,原告のC専務と打合せを行った。その際,C専務は,F専務に対し,①同日の被告の提案は,原告として従来の提案内容から大幅な変更であるとの認識であり,プロジェクトチーム内で方針決定する範囲を超えた提案と判断する,過去に被告からの提案どおり(NEFSS/Corebank採用,BRDの適用,スケジュール変更等)実施してきた経緯を考えても,今回は継続プロジェクトの位置付けとは考えにくい,②正式に企業と企業とで検討する内容であると判断するので,K社長名でA社長宛に,一週間以内に,ⅰ)現状の認識,ⅱ)現状の課題,ⅲ)今後の進め方を文章で提出されたい(若しくは提案内容を具体的に。),③NEFSS/Corebankパッケージで3年以上進めてきたプロジェクトについて,銀行業務の基幹となる勘定系の部分を新たなパッケージで即刻進めることを何ら技術的,業務的な事前検証作業なしで進めることはできない,同じパッケージ方式での開発の誤りを銀行として二度と繰り返すことはできない,④原告として,正式な機関決定は必要であるが,本件プロジェクトをいったん白紙に戻したい,先回までの検討課題であった追加資金20億円の話も白紙に戻してくださいなどと述べた(乙333)。
(セ) 同日に開催された会議において,被告作成の同日付け「「新経営システム」構築プロジェクトに関するご相談」と題する書面が提出され,原告と被告間で次のようなやりとりがされた(甲30,122の3)。
a 被告の提案について,原告から次の意見が出された。
(a) 本日の提案は,NEFSS/Corebankで新バンキングシステムを構築するという前提を覆す新たな提案と認識する,これまでのプロジェクトを一度ゼロにするものである。
(b) 海外のパッケージは日本のバンキングには適さず日本化することが大変という理由であるにもかかわらず,なぜ今回も海外のパッケージを提案するのか疑問である。
(c) 今回の案が適しているのならば,なぜ当初からこの案を選択しなかったのか,被告はCorebankを選択したのではないのか。
b これに対し,被告は,次のとおり回答した。
(a) 新バンキングシステムとしてNEFSSを構築するというコンセプトに変わりはない,その中心となるシステムが変更になるだけである。
(b) FISの解決策が見つかればこのような提案にはならない。
(c) Corebankと違うのは,ソースコードが公開されている点である,Corebankはブラックボックスだったが,今回は被告がコントロールできるため,スケジュールの主導権をとれることが大きく相違している。
(d) 業務要件を実現することを考えると,Corebankより今回のほうが優れていると考える。
c そして,被告としては,原告の意向が把握できたため,被告から再度提案を行うこととした。
イ TCB提案後の経緯等
(ア) 被告は,平成19年4月26日,原告に対し,次の内容の同日付け「貴社「新経営システム」構築プロジェクトについて」と題する書面を交付した(乙33)。
a ここ数か月間においては,プロジェクトの進展が芳しくなく,多くの未解決の重要事項(SCSへの過去作業分の支払とSCSの今後の取扱い,貴社から弊社への未払金,周辺システムに関するスケジュール,提供機能及び費用等の問題)が存在している。
b 被告としては,FIS社製ソリューションは依然として有効なソリューションであると考えている。
c 未解決の問題の重大性に鑑みると,Temenos社製のコアバンキング・パッケージを含めた代替ソリューションを検討の対象として,可能性のあるオプションを両社で協議し,適切なソリューション,作業範囲,価格及び条件について,両社で検討,合意することを提案する。
d 代替手段を検討するとともに,現在の本件プロジェクトにおける被告の作業を一時中断することを提案する。作業中断により,コストを削減することが可能となり,また,代替手段の検討に一層注力することが可能と考えている。
(イ) 原告は,同年5月9日,被告に対し,①原告の判断としては,同年4月18日の被告の提案は,本件最終合意書による本件システムを現在の被告の技術力では実現できないことの意思表明と認識している,②原告は,現況が本件最終合意書による本件システムの完成の見込みはないとの理解で,本件プロジェクトをいったん白紙に戻すこととし,原告が支払済みの開発費及び原告側の要員費用など原告が負担した費用全額について速やかに返還していただきたい旨を通知した。また,本件プロジェクトについて被告がどう対処するのかを,同年5月31日までに書面で回答するよう求めた(甲31)。
(ウ) 被告のF専務は,同月16日,原告のC専務に対し,現行システムの抱える課題を整理し,現勘定系システムを拡張しながら原告の経営課題の解決と市場の要求に迅速に対応するためのソリューションの検討及び本件プロジェクトに関する契約関連の課題解決の検討を90日間で実施することを提案した。しかし,C専務は,①本件プロジェクトの契約の整理を終えて,現行システムの延命の議論に入るべきで,同時提案は受け入れ難い,②今は巻き返しを急ぐ時期と考えている,③新経営システムの構築を諦めたわけではないなどと述べて,同提案資料をF専務に返却した(甲32,乙260)。
(エ) 被告は,同月31日,原告に対し,上記(イ)の回答として,同日付け「貴社「新経営システム」構築プロジェクトについて」と題する文書(K社長からA社長に宛てた書簡)で,上記(ウ)の案を正式に提案した(甲33)。
(オ) 原告のC専務と被告のF専務は,同年6月1日,打合せを行った。そこでは,次のようなやりとりがされた(甲29)。
a F専務が,今の原告の要望に合わせると,サービスインが平成22年になってしまう,コストを低減するためにも代替案を検討するに至ったと述べたところ,C専務は,原告独自のものでなくて良いと何度も言ったはずである,他行に売れる邦銀の標準的なものを構築したいと言ったはずであるなどと述べた。
b C専務が,「Corebankのことを分からず進めてきたことが誤りですよね」と質問したところ,F専務は,「全部理解はしていました。ただ,日本の銀行の諸制度に合致させることが難しかったのは事実です。現実解としてパフォーマンスの問題が出ることが分かりました。もちろん最初からは分かっていませんでした。世の中が変わったため,難しくなってしまったのです。」と答えた。
また,F専務は,「機能の中身を,貴社が求めている機能と合わせてみると,パフォーマンス上の問題が露呈したのは事実です。」と述べた。
c C専務が,開発費用とスケジュールが何とかなれば,本件システムはデリバリーできるのかと質問したところ,F専務は,「はるかに大きくなると予想されますが。」と答えた。これに対し,C専務が,それはFIS社がCorebankの内容を開示しないからであるのか問うたところ,F専務は,CorebankはFIS社のプロパティであり,被告はどうこう言える立場にないと答えた。さらに,C専務が,「何でそんなパッケージを勧めたのですか。それを知らなかったのですか。」と質問したところ,F専務は,「提案した当初は銀行の業務には一番合っていると思いました。最良の検証も実施しました。結果として検証が足りなかったということです。」と答えた。
d C専務が「どちらに責任があったのでしょうか。当社が悪かったのでしょうか。」と尋ねたところ,F専務は,「このような状況に陥った責任は感じています。」と返答した。また,F専務は,勘定系はCorebankでは難しいのは事実ですと述べた。
e C専務が,「コアバンクは選択ミスだったのですか。」と質問したところ,F専務は,「結果としてそうなってしまいました。システムの真ん中はそうなってしまいましたが,周辺は生かしたいと思います。」と返答した。これに対し,C専務が「それでは,途中でなぜ分からなかったのですか。BRDのとき,何で提案してくださらなかったのですか。Corebankに問題があると言ったのはFさんですよ。」と質したところ,F専務は,「そのとおりです。自分でチェックはできませんでした。技術側から何とかなるだろうと言われ,BRDを進めました。真実は話したとおりです。勘定系はだめでした。」と述べた。
(カ) 原告は,同月8日,被告に対し,原告と被告との間で事実関係について認識の相違があることから,被告の同年5月31日付け文書(上記(エ))を返却し,再度本件プロジェクトにおける事実関係についての被告の見解を明記の上回答するよう求めた(甲34)。
(キ) 被告は,同年6月25日,原告に対し,同日付け「貴社「新経営システム」構築プロジェクトについて」と題する文書を交付した。同文書には,被告が認識する本件プロジェクトが一時中断に至った原因について,次のとおり記載されている(甲35)。
a Corebankを有効に活用するための準備が不十分であったこと
本件プロジェクト開始時において,Corebankの機能の充足度や開発手法の検証が不十分であった。
b プロジェクトの初期の段階で開発手法の選択を誤ったこと
パッケージをベースとする方法でなく,Corebank部品をベースとしたカスタム開発手法を採った。
c 原告の要件に対する認識不足,また,ともに投資をし,リスクを共有するパートナーとしての意識が不足していたこと
新業務要件を明確にし,パッケージに合わせるために要件を絞ることが必要であったが,要件定義局面では現行機能のドキュメントがなく,その作成に多大なワークロードを要すとともに,当初の想定以上に現行機能が複雑であることが判明した。また,要件決定に当たっては,現行機能の踏襲に固守した部分が多く,結果,要件の絞り込みが不十分なものとなった。
d SCSを本件プロジェクトにおける被告のビジネスパートナーとして活用することができなかったこと
SCSが他のビジネスパートナーと同様にプロジェクトに参画すると想定していたが,実際には銀行としての立場で参画することが多く,十分に活用できなかった。
e 開発手法についてはプロジェクト期間中に軌道修正したが,見直し後のスケジュール,費用の観点で合意に至ることができず,プロジェクトは一時中断せざるを得ない状況となった。
(ク) 原告のC専務と被告のF専務は,同日,打合せを行った。そこでは,次のようなやりとりがされた(甲36の1)。
a C専務は,同日付け書面(上記(キ))について,被告に責任があったと認識していると理解してよいのか質問したところ,F専務は,パッケージの選択の誤りといった一つの原因だけではないが,準備が不十分だったことは認識している,また本件プロジェクト当初に開発手法の選択を誤ったのは事実であると答えた。C専務が,被告に責任があると認識されているのですねと質問したところ,F専務は,上記(キ)aないしeの複合原因で今の状況に陥ったと認識していると答えた。
b F専務は,Corebankの中身を邦銀標準に合わせる共同作業をFIS社に申し入れたが,FIS社サイドから自分たちが開発するとのレスポンスがあったので,それをブラックボックスと表現したと述べた。
c F専務は,BRDを開催した理由について,原告の業務が分からない,どうやって対応するのか分からない,FIS社が持っているCorebankの機能にどうやって銀行業務を合わすのか,又はパッケージをどのように合わせていくのかを機能的に精査していかなければならないといった問題を解決するために実施したと答えた。また,BRDの中で100を超える機能のうち,いくつかが駄目で,いくつかが大丈夫かを報告会で報告させてもらったが,その中の対応ができない事項をどうやって開発するかの交渉の中で難易度が分かってきたと述べた。
これに対し,C専務は,「そこが「貴社がCorebankを分かっていない」と指摘している点なのです。今さらですが,新BRDはその程度の目的で実施されたんですか。改めて4月の段階でカスタマイズの難しさの説明をされましたが,プロジェクト開始当初から分かっていたのではないのですか。銀行業務が分からないと言っても,少なくとも日本の銀行のシステムをずっと手掛けてきている御社スタッフがBRDに参加していたわけですから,新BRDで業務を理解する段階ではないのではないですか。」と返答した。
d C専務は,追加費用について,当初の作業量の見積りが間違っていたのかと質問したところ,F専務は,パッケージをベースにしなかったことに問題があった,現行機能の踏襲が必要であり,パッケージだとその機能が落ちてしまうとまずいとの議論の中から,提示の金額に行き着いてしまったと述べた。また,「見積り相違であり,運営の仕方の相違であり,また我々自身の努力不足でした。いろいろな要因があります。両社が要件がこんなに大きくなるとは予想しなかったのも一つの原因です。」とも述べた。
(ケ) 原告は,同年7月18日,同月17日付け内容証明郵便により,被告に対し,本件最終合意及び本件個別契約を債務不履行(履行不能)により解除する旨の意思表示を行った(前記前提事実(9)セ,甲15の1)。
2  本件最終合意書に記載された原告の支払金額等の拘束力
(1)ア  原告は,被告は,本件最終合意書において本件システム開発を89億7080万円で構築する旨約したにもかかわらず,その義務を尽くさなかったので被告には債務不履行又は不法行為が成立する旨主張する。そこで,本件最終合意書1条に規定されている原告から被告に対する支払総額89億7080万円の金額が,両当事者に対して法的拘束力を有しているのかどうかについて検討する。
イ  本件最終合意書の内容は,前記前提事実(8)ア記載のとおりであるが,その中で,①本件最終合意書1条では,原告及び被告は,原告及び被告が合意する作業範囲,価格,支払条件及びその他の契約条件を規定する同条記載の個別将来契約が両当事者により締結されることを条件として,本件システムの構築を被告が89億7080万円で行うことに同意した旨規定し,②同7条は,原告と被告は,構築要件,新システム基盤,プロジェクト計画などを記載した本日(本件最終合意の締結日)に至るまでの協議に基づく案を添付し,今後さらに協議をして,最終化することに合意する旨規定し,③同8条ただし書は,「ただし,各個別契約(第1条記載の個別将来契約を含むがこれらに限定されない。)が締結され,各関連個別契約の中で両当事者の各局面における義務が規定されるまでは,いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。両当事者の書面による合意がある場合を除いては,本第8条は有効とする。」と規定している。
上記のとおり,本件最終合意書1条及び8条ただし書によれば,本件最終合意書に記載された原告の支払金額の法的拘束力については,原告と被告との間で本件プロジェクトの各局面における義務を定めた個別契約が締結されることを前提条件として生ずるものとされていると解すべきである。
そして,本件最終合意書1条記載の個別将来契約のうち,IBMシステム・インテグレーション契約書(統合テストb局面~システムテスト局面のサービス契約)が締結されていないことは当事者間に争いがない上,証拠(甲5の8の1ないし5)及び弁論の全趣旨によれば,IBMシステム・インテグレーション契約書(基盤,制御,業務に関する外部設計局面~統合テストa局面のサービス契約)について,業務に関する外部設計・内部設計・開発・テスト局面,並びに制御及び基盤に関する開発・テスト以降の局面に関する個別契約の大半が未締結であることが認められる。
そうすると,上記支払総額が法的拘束力を有するに至る程度に条件が充たされているとはいえないので,被告の債務不履行又は不法行為の成立をいう原告の上記主張は採用することができない。
ウ  なお,上記8条ただし書の規定は,各個別契約の中で両当事者の義務が規定されるまでは,いずれの当事者も本件最終合意書に基づく法的義務を負わないものとしたにすぎない。後記3(2)オのとおり,上記支払総額の規定が設けられたのは両当事者が目標とする重要な指針を定める趣旨であることは疑いのないところであり,本件最終合意書が交わされた平成17年9月30日の時点において,被告は,本件システム開発のコスト見積りの前提となる基礎数値を確定させて原告の支払金額を決めたものであることなどからすれば,上記支払総額の規定された本件最終合意書が交わされたとの事情が,被告の信義則上ないし不法行為上の義務違反の有無を考慮するに当たり意味を有し得るものであることを否定するものではない。
(2)  また,本件最終合意書7条によれば,開発スコープ及びサービスインの時期についても,「今後さらに協議をして,最終化する」ことが予定されていたものと解されるから,これらが本件最終合意書によって直ちに法的拘束力を生ずるに至るものであるということはできない。
(3)  上記の点について,原告は,仮に,本件最終合意書の法的拘束力が全ての個別契約の締結という停止条件に服していると解釈されても,被告は,故意又はこれと同視すべき重過失によりこの停止条件の成就を妨害したのであるから,民法130条により,この停止条件は成就したものとみなされるなどと主張する。しかし,後記3で判示する本件プロジェクトが頓挫した原因について,被告の故意又はこれと同視すべき重過失があったとまではいえないから,原告の上記主張も採用できない。
3  本件プロジェクトが頓挫したことについての帰責事由(争点(2))
本件プロジェクトが中止するに至ったことについて,原告は,被告はCorebankに関する知識に乏しく,開発工程が混迷を極め,結局,Corebankによる開発を断念せざるを得なくなったために,本件プロジェクトが頓挫したなどと主張するのに対し,被告は,原告が主張する本件プロジェクトの中止に至る事実経過はいずれも客観的事実に反するものであり,むしろ,被告が本件プロジェクトを成功に導くためあらゆる手を尽くしたにもかかわらず,原告が必要な協力をせず,責任を一方的に被告に押しつける態度に終始したために,本件プロジェクトは頓挫したものであるなどと主張する。
そこで,本件プロジェクトが中止するに至ったことについて,どちらにどのような責任があるのかについて検討することとする。
(1)  まず,前記1の認定事実によれば,本件プロジェクトが頓挫するに至ったのは,平成19年5月ないし6月であるということができる。すなわち,被告が原告に対して同年4月18日にTCBの提案をしたが,原告がこれを受け入れず,同年5月9日に本件プロジェクトをいったん白紙に戻したいと被告に通知した上,さらに,被告が原告に対して同年5月31日付けの書簡により現状の課題の整理とその解決の検討を提案したのに対し,原告は,同年6月8日,これをも返却して,その提案を受け入れなかったのであり(前記1(3)ア(シ)ないし(セ),イ(ア)ないし(カ)),この時点においては,本件プロジェクトは頓挫したものということができる。
この点について,被告は,本件プロジェクトが頓挫したのは平成19年1月であると主張する。しかし,前記1の認定事実によれば,この時点においては,原告及び被告共に,本件システム開発をいつまでに,どのような範囲で,また,いくらの費用で行うかについての交渉を続けていたのであり,本件プロジェクトが上記時点で頓挫したなどということはできない。
なお,被告が,本件訴訟の当初,本件プロジェクトは原告がTCBによる代替案を拒絶して本件プロジェクトを白紙に戻すこととする旨を一方的に宣言したことで頓挫したと主張していたことは当裁判所に顕著である(答弁書19頁,42頁)。
(2)  原告が主張する被告の責任原因の有無
原告は,被告は,システム開発業者として,自らが有する高度の専門的知識と経験に基づき,納入期限までにシステムを完成させるようにユーザに提示し,ユーザとの間で合意された開発手順や開発手法,作業工程等に従って開発作業を進めるとともに,常に進捗状況を管理し,開発作業を阻害する要因の発見に努め,これに適切に対処すべき義務や,ユーザのシステム開発への関わりについても適切に管理するなどの行為をすべき義務(これらの義務を総称したものとしてのプロジェクト・マネジメント義務)を負っていたにもかかわらず,この義務を尽くさなかったのであり,本件プロジェクトは,被告がCorebankに関する知識に乏しく,開発工程が混迷を極め,結局,Corebankによる開発を断念せざるを得なくなったために頓挫したものであるなどと主張するので,この点について検討する。
ア Corebankの機能や開発手法についての検証,検討等
(ア) 本件のように,ベンダとユーザとの間でパッケージ型システム開発が行われる場合,パッケージの選定は,開発の対象となるシステムの根幹を成すものであり,その適切な選定,開発方法の採用は極めて重要な課題である。システム開発の専門家であるベンダは,パッケージの選定に当たり,パッケージの機能・性能,設定・導入の容易性,導入実績,パッケージの提供者の導入実績,経営の安定性,技術力,カスタマイズへの積極性その他関連する諸事情を考慮して,ユーザが構築しようとしているシステムに最適のパッケージを選定した上,これに適した開発方法を採用しなければならず,そのために,ベンダは,ユーザへの提案前に様々な観点からパッケージの機能,開発手法,リスク等について十分に検証又は検討しなければならないものというべきである(甲76ないし78,甲88ないし90)。加えて,それまで日本の銀行の基幹系のシステム開発において海外のパッケージが用いられたことはなかったのであり(甲76,78),しかも,被告は,製造業や流通業でのパッケージ・ベース・アプローチの経験はあるが,銀行のシステムをこの手法で開発した経験がなかったのであるから(甲6の18),被告としては,本件システム開発に当たって,より慎重に,パッケージの機能,開発手法,リスク等について検証又は検討し,適切な開発方法を採用しなければならないものというべきである。
(イ) ところで,パッケージ型システム開発は,既製のプログラムを最大限そのまま利用することで新規開発量を削減し,それにより開発コストの削減と開発スケジュールの短縮を実現することを重要な目的としているから,システムベンダは,業務要件定義の段階からパッケージの機能をベースとして,ユーザが実現を望んでいる機能をパッケージの既存機能で実現する方法を検討し,既存機能では実現不可能な部分をギャップとして新規開発(カスタマイズ,アドオン)する方法を採るのが合理的である。しかし,被告が計画・要件定義#1及び2で採用した現行踏襲型アプローチは,ユーザの現行システムの機能を基礎にしてそれに新システムで必要な機能を積み上げるという手法であり,これでは,パッケージソフトウェアであるCorebankの利点を十分に享受することができず,ギャップ開発の量が不必要に増大してしまうことが避けられないというべきである(この点について,甲77を参照)。現に,被告は,上記のとおり,Corebankについて当初は現行踏襲型アプローチの開発手法を採用して要件定義書を作成するまでに至ったが,その開発手法に誤りがあるとして旧BRDを行ったのであり,さらに,旧BRDは十分にパッケージ・ベース・アプローチの手法に沿っていないので変更が必要であるとして,新BRDを実施するに至ったものである。上記のように開発方法について基本的なやり直しをしなければならなかったのであるから,被告は,Corebankを利用した場合の適切な開発方法についてあらかじめ十分な検証又は検討をしていたものということはできない。
(ウ) また,上記のとおり,被告はCorebankの開発方法の点において基本的なやり直しをしなければならなかったという事情のほか,①F専務は,平成18年8月9日開催の第21回ステアリング・コミッティにおいて,「Corebankがどこまでできるのか,これまでIBMは分かっていなかった。BRDにより肌で感じることができた。」と述べていたこと(甲6の21),②被告作成に係る平成18年12月11日付け書面に,本件プロジェクトのコストが増大した理由の一つとして,被告による「Corebankの成熟度の見誤り」との記載がされていること(甲7・4頁),③平成18年になってから,CorebankをJava化したもののパフォーマンスが悪いことが判明したこと(証人L),④被告が平成22年1月の全面稼働というスケジュールを示した際に原告に提示した平成19年3月19日付け書面には,外部依存関係の評価として,「FIS社等ベンダーの開発能力および,リスクの評価を実施したところ想定以上に課題が確認された」と記載されていること(甲80・3頁),⑤被告は,原告に対し,平成19年4月18日,Corebankによる基幹系のシステム開発に代えてTemenos社のTCBによる開発という代替案を提案したが,その際に,「FISでは妥当な結果が出ない」,「FISがブラックボックス」,「Javaのパフォーマンスが悪い」などと説明したこと(甲9,甲30,甲122の3),⑥F専務は,平成19年6月1日に行われたC専務との面談において,Corebankについて,「日本の銀行の諸制度に合致させることが難しかったのは事実です。現実解としてパフォーマンスの問題が出ることが分かりました。もちろん最初からは分かっていませんでした。」,「勘定系はCorebankでは難しいのは事実です。」などと述べたこと(甲29),⑦K社長作成の平成19年6月25日付け書簡には,本件プロジェクト中断の原因として,「プロジェクト開始時において,Corebankの機能の充足度や開発手法の検証が不十分であった」,「プロジェクトの初期の段階で開発手法の選択を誤った」などと記載されており,F専務は,同日に行われたC専務との面談において,本件プロジェクトが中断した原因について,「パッケージの選択といった一つの原因だけではありません。ただ,準備が不十分だったことは認識しています。またプロジェクト当初に開発手法の選択を誤ったのは事実です。」と述べたこと(甲35,甲36の1)等の事情が認められる。
これらの事情によれば,被告が,原告との間で本件プロジェクトを開始するに当たり,基幹系のパッケージソフトウェアとしてCorebankを採用する上で,その機能や充足度についてあらかじめ十分な検証又は検討をしたものということはできない。
(エ) さらに,パッケージ型システム開発においては,パッケージにはパッケージベンダしか分からない部分があるので,システムベンダは,パッケージベンダからの支援を受けることが必要であるが(甲77),被告は,新BRDの段階に至るまで本件プロジェクトにFIS社の社員を関与させてはいなかった。しかも,本件プロジェクトのような場合,システムベンダ自身において,ユーザの要求を理解できる業務知識と利用するパッケージの構造を熟知している者をプロジェクトに参加させることが必要であるが,被告がCorebankによるシステム開発について知識や経験のある技術者等の要員を本件プロジェクトのメンバーとして配置していたことを認めるに足りる証拠はなく,かえって,これを配置していなかったとの事実が認められる(甲6の16)。
そうすると,被告としては,本件システム開発を遂行するに当たり,Corebankを利用した適切な開発方法を採用したということはできない。
(オ) 以上のとおり,被告は,本件システム開発を開始するに当たり,Corebankの機能や充足度,その適切な開発方法等についてあらかじめ十分に検証又は検討したものとはいえないし,また,本件システム開発を遂行するに際し,適切な開発方法を採用したものということもできない。
イ FIS社の関与による開発体制の整備等
本件のように,大規模なパッケージを用いた基幹開発のプロジェクトにおいては,パッケージのカスタマイズがその中核となり,かつ,難易度の高い作業であって,カスタマイズに関する作業量,作業時間,費用が一般的にかなり大きなものとなるため,カスタマイズ作業を適切に実施できる体制が整えられているか否かがプロジェクトの成否に直結する重要なポイントであるというべきである(甲76ないし78,甲88ないし90)。したがって,上記プロジェクトを行うシステムベンダとしては,上記の体制を整えておくことが不可欠である。
前記のとおり,被告は,Corebankの改変権を有しておらず,その改変はFIS社によって又はFIS社の承諾に基づいて行わなければならなかったのであり,また,被告は,本件システム開発において,新BRDの段階になる前はパッケージベンダであるFIS社を参画させることがなかったのである。それ以前に,被告が本件システム開発においてCorebankをカスタマイズするために要する役割分担(例えば,被告がCorebankを利用せずに外付けで開発するのか,又はFIS社がCorebankを改変して開発するのかなど),作業量・作業時間,費用等について十分に検討したことや,FIS社との間でこの点を協議するなどして,カスタマイズ作業を適切に実施できる体制を整えていたことを認めるに足りる証拠はない。特に,被告がCorebankの改変についてFIS社の承諾が得られなかったり,同社との交渉が難航したりするような場合には,パッケージのカスタマイズが行えないことによって開発の遅延や中止を迫られることになるのであるから,被告としては,このような開発の阻害要因に対処するため,あらかじめ,FIS社との間でカスタマイズ作業の作業分担や費用負担について合意が得られるようにするか,あるいは,合意が得られないような事態に対処する方法を準備するなどしておく必要があったものというべきである。
現に,新BRDが終了した段階において,原告と被告との間で平成18年9月29日にIBMシステム・インテグレーション契約(甲5の8の5)が締結されたことにより,被告は,FIS社との間でGAP開発の役割分担やスケジュールなどを協議し,その結果に基づいて設計・実装局面の作業計画を作成して,これを平成18年12月1日までに原告に納品することとされていたが,その期限になっても,被告とFIS社との協議は整わず,上記作業計画が原告に対して提示されることはなかった。その後,ようやく平成19年3月27日ころまでに,被告とFIS社との間で融資のギャップについての振り分けが完了したにすぎない。この時点に至っても,上記作業計画が原告に提示されることはなかったのである(なお,この点について,被告は,「設計・実装局面 作業計画」は,基本設計フェーズ後の本件プロジェクトの作業計画であるから,本件プロジェクトのスケジュールや開発スコープ等について,原告と被告との合意の下,方針がまとまることを前提とするものであるが,原告が被告との間で上記の方針をまとめることを拒絶したなどと主張するが,その主張に係る事実を認めるに足りる証拠はない。)。
このように,被告は,本件システム開発において,Corebankの改変権を有しているFIS社との間で協議をするなどしてCorebankのカスタマイズ作業を適切に実施できる体制を整えていたとはいえないのであり,このことが本件プロジェクトにおいて作業の遅延や費用の増大を招いたものであるということができる。そして,このことにより,被告がCorebankを利用して本件システム開発を完成できるのかについて,原告が強い疑念を抱いても不自然ではない状況が作り出されたものというべきである。
ウ 被告の原告に対する説明
本件のように,パッケージの改変権を有していないシステムベンダがそのパッケージを用いて大規模なシステム開発を行う場合,パッケージベンダの対応いかんが開発上の重大な阻害要因になり得るのであるから,この点に関する事情は,システム開発を行う上での重要なリスクに関連するものとして,ユーザが契約関係に入るかどうかを決定する上で重要なものというべきである。なお,本件システム開発が,海外のパッケージソフトウェアであるCorebankを利用して邦銀の基幹システムを開発する大規模なものであることからすれば,被告においては,相当に大規模なカスタマイズをする必要があるということはあらかじめ知り得るところであったものということができる。
ところが,被告は,原告に対し,本件基本合意書①を交わした平成16年9月29日の時点においても,また,本件最終合意書を交わした平成17年9月30日の時点においても,被告がCorebankの改変権を有していないことが本件システム開発において作業の阻害要因になり得ること,Corebankを改変するために必要とする役割分担,作業量・作業時間,費用等に関して被告とFIS社との間で十分な協議が整っていないことなどの事情について,これを説明してはいなかった。
上記のとおり,被告が上記の事情をあらかじめ原告に伝えていなかったことは,原告の信頼を損なうものということができる。
エ サービスインの時期の延期
前記認定のとおり,本件システムのサービスインの時期について,本件最終合意書では平成20年1月とすることとされていたが,原告と被告は,平成18年11月13日,新BRDの結果をも踏まえて,平成20年1月,同年5月,同年10月及び同年12月の4段階によるサービスインを行うことに合意した。しかし,被告は,原告に対し,平成18年12月6日に開催された第24回ステアリング・コミッティにおいて同月15日までに提示することを約していた基幹系詳細スケジュール(甲5の8の5の個別契約により原告に納品すべきもの)をその後においても提示しなかった上(甲6の24,甲71の1ないし18),上記の合意から3か月も経過しない平成19年1月31日,CorebankについてFIS社のデリバリーが遅れる可能性が大きく,サービスインのスケジュールが現に合意している平成20年1月から平成21年5月になるリスクが大きいと告げた。さらに,被告は,平成19年3月19日,原告に対して新たな提案をし,Corebankパッケージとの間で多くのギャップの存在が顕在化したため,FIS社と被告で開発の最適化を行った場合でも2年以上の開発期間を要することが判明したことから,平成20年1月から平成22年1月までの5段階の段階的移行を内容とするサービスイン方式を提案したものである。
本件最終合意書によりされたサービスインの時期の定めが法的に確定したものではないと解されるとしても,平成18年11月13日にされたサービスインの時期に関する合意は,既に要件定義もBRDの作業も終了した時点でのものであり,その合意に至る経緯からしても,原告と被告との間で確定的な合意をしたものと解さざるを得ない。それにもかかわらず,被告がこのように合意したサービスインの時期すらも遵守することができず,サービスインがそこから大幅に遅れる見通し(本件最終合意書で記載されていたサービスインの時期からは2年,平成18年11月13日の合意の時期からも1年以上の遅れ)となってしまうことについては,ユーザである原告にとって容易に受け入れ難いものであることは明らかである。その遅延については,たとえそれがFIS社からの納品が遅れることによるものであるとしても,被告の責めに帰すべきものということができる。
オ 本件最終合意書の作成以降における被告の対応
本件最終合意書が交わされた後における被告の原告に対する対応について触れておくことにする。
(ア) まず,本件最終合意書において原告の支払金額が定められた経緯についてみると,本件最終合意書が交わされたのは本件基本合意書①が交わされてから約1年が経過した平成17年9月30日であり,その間に,原告と被告は,現行踏襲型アプローチの方法によるものではあるが,要件定義や現行分析の作業を積み重ねていたのであって,上記支払金額は,要件定義が終了することを予定して決められようとしていたものであり,少なくとも,計画・要件定義#2の成果物である要件定義書が同年12月末までには納入される予定であることを前提として決められたものということができる。しかも,被告は,原告に対し,平成17年6月30日付けの書面により,Corebankによる効率的開発手法の確立及びそれを前提とした見積り方法の確立が未済であること,商品のBPRによる開発対象基礎数値の確立と合意が未済であることなどの課題が残されていることを理由として最終合意の締結を同年6月末から同年9月末にすることを申し出たが,その後,システム開発コスト見積りの前提となる基礎数値(オンライン取引数,帳票数,リンクデータ数,バッチジョブ数)についてはほぼ確定に近づいたなどという経過報告をして,最終的に同年9月30日に本件最終合意を締結したものであって,原告に対しては,それらの確定した基礎数値を前提として原告の支払金額を決定したものということができる。なお,被告は,原告との本件最終合意書を交わした時点においては,被告の都合で本件最終合意の締結が平成17年5月から9月末日となってしまったことを除き,本件システム開発の進捗について特段の問題点を指摘していなかった(甲6の12)。
その後,被告は,①平成17年10月5日に開催された第12回ステアリング・コミッティにおいて,C専務が,期限は守られるのか,費用は予算内に収まるのか,日本の銀行の標準機能として持つべき機能は実現されるのかという3点につき,当初の計画どおり対応してほしいと述べたのに対し,異議を唱えなかった(甲6の12),②同年11月11日に開催された第13回ステアリング・コミッティにおいて,IBMアジア・パシフィック,FIS社と開発手法の検討を開始したことを原告に報告した際には,原告から,プロジェクトを遅延させない,サービスインの期限を守る,本件最終合意書で約束したことを守る上で効率化を図るための提案であれば承認するとの申入れがあったのに対し,これを了承する旨返答した上,FIS社との検討会によってプロジェクトの前提条件を変えることは考えていない旨述べ(甲6の13),③同年12月に被告から旧BRDの提案がされた後,平成18年1月11日に開催された第14回ステアリング・コミッティにおいて原告から「1月以降の作業計画について」と題する書面について言及された際には,業務要件を削減することはしない,あくまで平成20年1月本番稼働をうまくいかせるためにどうするかという観点で合理化案について検討させていただきたい旨を述べ(甲6の14),④平成18年4月11日に開催されたプロジェクト進捗会議においても,原告が現在のBRDの方向性はこれでよいのか,当初の目的としては工数削減があったと思うが,現時点での検討結果を見ると,より良いものを開発することで工数が増えていると思われる旨質問したのに対し,横展開の観点から,追加費用及び原告側工数増加は発生しないため問題はない旨答え(甲139),⑤同年4月に被告から新BRDの提案がされた後,平成18年5月10日に開催された第18回ステアリング・コミッティにおいて,Corebankを有効活用するためにパッケージ・ベース・アプローチで進めるということできたが,開発手法が定まらないまま進めてきてしまった,新BRDについては本件プロジェクトを正しい軌道に乗せるベストの方法と考えている,本件最終合意書については,費用,スケジュール,スコープを含めて原告の要件が記載され,扱いについても会社間で合意したものと認識している,新BRDの中で合意書に記載されたビジネス要件をパッケージ・ベース・アプローチでいかに実現するか検討を進めていきたい旨を述べ(甲6の18),さらに,⑥同年8月31日に開催されたBRD最終報告会において,被告作成の「エグゼクティブ・サマリー」と題する書面中「BRD概要」のBRDの主要目的(4)項に「当初想定投資の再見積りを行う」旨記載されていたことについて,原告が,後付けで目的を追加することは認められないので,削除されたい,追加する理由も本件最終合意を破棄するためのものなのかと指摘したのに対し,上記の項目は被告内部の事項であり当初設定した目的にはなかったことなので,削除する旨回答した(甲26)。
上記のような被告の対応に接した原告は,開発手法の変更がありながらも,本件最終合意書で合意された内容が実現するものと考えていたのであり,その際に,原告側が負担すべき費用が本件最終合意書の金額よりも増額されることは考えてはいなかったものと認めることができる。そして,このような状況の中で,原告は,本件システム開発に関する費用として,被告に対し,平成16年9月29日付け現行契約に基づき,本件最終合意書が交わされた平成17年9月30日までに合計7億5935万8950円を支払い,平成16年12月29日付け現行契約に基づき,平成17年10月31日に12億2430万円を,同年11月30日に10億4580万円を,平成18年6月30日に6億8250万円を,同年9月29日に6億8800万円を,それぞれ支払い,そのほかにも,個別将来契約に基づく代金を支払ったものである。
(イ) 上記の各事情に鑑みれば,原告としては,本件最終合意が締結された時点において,被告が提案した開発手法に従ったシステム開発に問題があるとは認識していなかったし,本件最終合意書で定められた原告の支払金額には相応の根拠があると信頼していたものというべきである。また,本件最終合意書が交わされた後,被告の提案した開発手法に誤りがあるとしてこれを変更する提案がされ,旧BRD及び新BRDが行われたとしても,その経緯の中で,被告は,原告に対し,本件最終合意書の内容は両者間の合意であり,これを実現する方向で開発を進めるなどと述べ,本件最終合意書の内容を尊重する姿勢を表明していたのであるから,原告は,少なくとも,平成18年8月に被告からサービスインの時期の修正について提案がされるまで,平成20年1月に一斉切替えによるサービスインを行うことが無理であるとは考えていなかったし,また,同月に被告から追加費用の負担についての申出がされるまで,原告において追加費用の負担を考慮する必要はないと考えていたのである。そして,そのような認識の下で,上記各現行契約及び個別将来契約に基づく代金を支払ったものである。
仮に,被告として,本件最終合意書を交わした後の段階において,新たにBRDを実施してみなければ確実な見積りができないため,BRDの内容いかんにより本件最終合意書で記載された代金額の修正を原告に対して申し出るつもりであったのであれば,その時点でこれを原告に説明して,そのような前提の下で被告との本件プロジェクトを続けるのか否かを判断する機会を与えることもできたというべきである。それをすることなく,被告は,開発手法の変更があっても本件最終合意書の内容を尊重する旨を原告に告げて本件システム開発を続け,原告からはその間に代金の支払を受けた上,後になってBRDの実施により事情が変わったなどとして原告に支払金額の増額を申し出たのであり,このような被告の対応は,原告に対し,信義に反するものであるとの不信感を抱かせるものというべきである。
(ウ) これに対し,被告は,本件最終合意書が交わされた時点では,新システムの開発規模を工数の積み上げにより見積もることができる客観的状況にはなく,単に「概算見積り」が行われたにすぎず,原告もそれを理解していたのであるから,被告には,開発コストを正確に見極めなかったことについて,プロジェクト・マネジメント義務違反などあり得ない旨主張する。
しかし,本件最終合意書が交わされた時点においては,計画・要件定義#2の成果物である要件定義書が出来上がる見通しが立ち,被告から原告に対して平成17年12月末までには納入されることが予定されていたのであり,また,被告は,Corebankによる効率的な開発手法の確立,それを前提とした見積り方法の確立,BPRによる開発対象基礎数値の確立などの課題が解決されたものとの対応をしていたのであって,本件システム開発に係る原告の支払金額89億7080万円は,そのような経過を前提として決められたものということができる。そうすると,上記支払金額については,これが両当事者を法的に拘束するまでの効力を有しないとしても,両当事者が目標とする重要な指針を定める趣旨であることは疑いを入れないものというべきであり,しかも,被告は,旧BRD及び新BRDを行っていた際,原告に対して本件最終合意書の内容を尊重する旨を述べ,原告から現行契約に基づく代金を受領していたのであって,原告としては,これを信頼して本件プロジェクトを進めたものということができる。
被告の上記主張を直ちに採用することはできない。
カ TCBの提案
被告は,原告に対し,平成19年4月18日,基幹系に用いられるものとされていたパッケージソフトウェアであるCorebankに代えてTemenos社のTCBを採用することを提案したのであるが,その際,TCBを採用した場合に,いつの時点までにサービスインすることができるのか,また,いくらの費用を負担すれば本件システムが完成するのかについて,被告は確かな検証を済ませていなかった(甲9,甲30)。
そもそも,Corebankは,被告がこれについて日本化が順調に進んだとして原告に勧めたパッケージソフトウェアであり(前記前提事実(3)カ),本件基本合意書①にNEFSSパッケージとして「コアバンク」と記載され(前記前提事実(4)),本件最終合意書においても採用する基幹システムのパッケージソフトウェアは「NEFSS/Corebank」であると記載されていて(前記前提事実(8)),原告は,被告と共に,Corebankを基幹システムに据えて本件システムを構築することを大前提として,本件基本合意書①を交わしてから2年半以上の間,多額の費用と多大な労力をかけて本件プロジェクトを進めてきたものである。特に,原告と被告は,法的拘束力を有する個別契約においても,Corebankを利用することを明示的に合意し又はこれを前提として合意し(例えば,甲5の2,甲5の3の1,2,甲5の8の5など),原告がこれに基づいて代金を現に支払い又は支払うことが予定されていたのであって,少なくともTCBの提案がされた平成19年4月の時点においては,原告と被告との間において,本件プロジェクトを進めるに当たりCorebankを基幹系のパッケージソフトウェアとして利用することが法的拘束力を有するものとして合意されていたと解することができる。
このような状況の下,被告がCorebankによる基幹系のシステム開発を別のパッケージソフトウェアを利用して行うという代替案を提案する以上,その代替案は,完成時期や費用負担について十分な検証を行って成算がある,ないしは原告にとっても利益があるという確かな見通しが持てるようなものでなければ,原告にとって受け入れ難いものであることは明らかである。そうであるにもかかわらず,被告は完成時期や費用負担について十分な検証を済ませないままTCBによることを原告に提案したのであり,そのこと自体,原告との信頼関係を失わせる根拠になるものということができる。
キ 以上によれば,被告には,本件システム開発のベンダとして適切にシステム開発を管理することなどを内容とするプロジェクト・マネジメント義務の違反があるものというべきである。そして,上記の各事情に照らして考えれば,原告が,被告からTCBの提案を受けた段階で,被告に対して本件プロジェクトを白紙に戻したいと伝えて本件プロジェクトを中止する決断をしたことについては,何ら非難に値するものではないし,むしろ,相応の根拠があるものということができる。そうすると,被告のプロジェクト・マネジメント義務違反により本件プロジェクトが頓挫したものであり,被告はこの点について責任を負わなければならないというべきである。
(3)  原告の協力義務違反の有無
被告は,原告が本件プロジェクトにおいて必要な協力をせず,責任を一方的に被告に押しつける態度に終始したために本件プロジェクトは頓挫したものであり,このことは原告の責めに帰すべきものであって,原告の協力義務違反の根拠となる事情が認められると主張する。以下,この点について検討する。
ア 現行の業務及びシステム分析の必要性を認めようとせず,資料すら満足に提供しなかったこと
被告は,原告が,要件定義の前提となる現行の業務及びシステム分析の必要性を認めようとせず,資料すら満足に提供しなかったなどと主張するが,上記の事実を認めるに足りる証拠はない。
また,被告が主張する上記の事実は,本件最終合意書が交わされる前の事情であり,このような事情が,本件システム開発の頓挫と関連するものということはできない。
被告の上記主張は失当である。
イ 商品数・帳票数の削減を行わなかったこと
まず,被告は,原告がBPRにおいて商品数・帳票数の削減を行わなかった旨主張するので,この点について検討する。
証拠(甲6の6,甲6の11,甲45,甲46,乙28)及び弁論の全趣旨によれば,BPRにおいては,「新経営システムスタート時までに廃止しなければならない商品数は,融資898商品,預金19商品とする」とされていたところ,原告は,BPRにより,上記のとおり廃止しなければならないとされた商品を実際に廃止することにしたこと(廃止対象商品については,乙28の添付資料9及び12を参照),平成17年4月8日に開催されたステアリング・コミッティにおいて,被告のM事業部長は,「BPRについてはこれで終わりということではなく一つのチェックポイントとして考えている。検討着手した時点では見えないところもあり,どうかと思うところもあったが,こうやって具体的な数値(削減商品数やグループ数)を出すことができた。スルガの担当者の方には負担をかけ,ありがとうございました。」と述べていたこと,原告は,その後においても,商品を廃止していること等の事実が認められる。これによれば,原告がBPRにおいて商品数・帳票数の削減を行わなかったなどということはできない。
次に,被告は,原告がBRDの過程においても現行の業務に固執して帳票数の削減を拒んだなどと主張する。
しかし,後記ウのとおり,原告が帳票数の削減を拒んだ事実を認めることはできない。
ウ 開発スコープの削減等に応じなかったこと
被告は,本件基本合意書①によれば,当初から,要件定義後に開発の契約を締結するか否かを検討する機会を設けることが予定されていたこと,原告は,想定よりも開発工数がかかる見込みであることを理解していたからこそ,開発スコープやスケジュールが「先送り」となる本件最終合意書を交わしたこと,原告はシステム開発の専門家であり,開発スコープを調整せずに89億7080万円で原告の夢が全て実現できるはずがないことを理解していたこと等の事情があったのに,原告は,開発スコープの削減,調整に応じなかったものであるなどと主張するので,この点について検討する。
確かに,本件最終合意書7条によれば,同条所定の1ないし9の項目に関しては,本件最終合意の締結に至るまでの協議に基づく案を添付し,今後更に協議をして,最終化することに合意する旨規定されており,このことからすれば,本件最終合意書が交わされた時点においては,これに添付された上記の案(原告の商品数としては,融資219グループ,預金88グループの合計307グループ,帳票数としては,1618個(ただし,同一帳票は除く。))が確定的な合意の内容となっているものということはできない。しかし,原告としても,必要な内容を開発スコープに盛り込むことを主張するのは何ら非難に値するものではない。しかも,上記の案は,本件最終合意書が交わされた時点のものであることや,これを前提として開発委託費用95億円が見積もられていたことからしても,意味を有しないものということはできないのであり,むしろ,その後に原告被告間でされる協議自体はこれを基準にして行われるべきものということができる。
また,実際にも,①本件最終合意書が交わされた時点での帳票数は4617個であったところ,その後の経過を見ると,原告は,平成18年8月31日までに帳票数の削減を行い,バッチ帳票が4171個(うち重複帳票2635個)となったこと(甲44。なお,上記重複帳票については,その数を開発する個数から差し引くことができるものと考える。),②被告は,平成18年8月9日に開催された第21回ステアリング・コミッティにおいて,「パッケージに合わせることについては,スルガの協力に感謝する。無駄を省くことができた。」旨述べていること(甲6の21)等の事情が認められるのであって,原告が帳票の削減や開発スコープの削減,調整に応じなかったなどということはできない。
なお,被告が主張する事情のうち,本件基本合意書①によれば,当初から,要件定義後に開発の契約を締結するか否かを検討する機会を設けることが予定されていたことについては,このことによって,上記認定及び判断が左右されるものではない。また,原告は,システム開発の専門家であり,開発スコープを調整せずに89億7080万円で原告の夢が全て実現できるはずがないことを理解していたとの主張については,原告がシステム開発の専門家であるとの事実を認めるに足りる証拠はない。
エ 本件最終合意書の記載内容に固執して,一切の妥協をしなかったこと
被告は,原告が本件最終合意書に記載された89億7080万円という負担額,開発スコープ及びサービスインの時期に固執し,強硬な態度に終始して,一切の妥協をしなかったなどと主張するので,この点について検討する。
(ア) まず,89億7080万円という上記支払金額については,前記3(2)オのとおり,これが両当事者を法的に拘束するまでの効力を有しないとしても,両当事者が目標とする重要な指針を定める趣旨であることは疑いを入れないものというべきであり,しかも,被告は,旧BRD及び新BRDを行っていた際,原告に対して本件最終合意書の内容を尊重する旨を述べ,原告から現行契約に基づく代金を受領していたのである。そうすると,そのような状況の下で,原告が本件最終合意書で記載された原告の支払金額89億7080万円を強く主張したとしても,特段非難に値するものではなく,このことが原告の協力義務違反の根拠となるものとはいい難い。
(イ) また,サービスインの時期について,原告は,新BRDが終了した後の平成18年11月13日,本件最終合意書で記載されていた平成20年1月という時期を,平成20年1月,同年5月,同年10月及び同年12月の4段階によるサービスインに変更することに合意しているのであり,原告が,サービスインの時期に固執したものということはできない。その後,原告は,被告から,平成19年1月31日にサービスインは平成21年5月になるリスクが大きいと,平成19年3月19日に平成20年1月から平成22年1月までの5段階の段階的移行を内容とするサービスイン方式にしたいとそれぞれ告げられたことに対し,いずれもこれを拒否する回答をしているが,そこで提案されたサービスインの時期の遅延は相当に大幅なものであるし,このような提案を原告が受け入れなければならないような根拠も見当たらないのである。したがって,原告がサービスインの時期に係る被告の提案を受け入れなかったからといって,これが協力義務違反になるものということはできない。
オ 追加費用の負担や開発スコープに関する不合理な交渉経過
被告は,原告が,要件定義終了後に総開発費用の見積りが出された際,被告がNEFSSに莫大な投資を行っていて後に引けないことを知悉して,スコープについても費用負担額についてもいったんは合意するそぶりを見せながら,これを覆し,不合理に強硬な交渉態度に終始し,被告が要請する平成18年12月あるいは平成19年1月の契約締結を拒否した旨主張する。
しかしながら,原告が被告に対して不合理に強硬な交渉態度をとって平成18年12月ないし平成19年1月に契約の締結を拒否した事実を認めるに足りる証拠はない。
確かに,原告のE副社長は,被告のF専務に対し,平成18年12月13日,本件システム開発について原告が出せる追加費用は最大でも20億円である旨を述べたことが認められるが,それ自体は,E副社長の見通しを述べたものにすぎないし,スコープなどその他の条件について具体的に述べたわけでもないのであり,これを原告からの提案とみることはできない。したがって,その後,被告から原告の追加費用を20億円とすること等を含む内容の提案がされたのに対し,原告がこれを受け入れなかったとしても,これが不当な交渉態度であるということはできない。
そもそも,原告は,本件最終合意書で定められた原告の支払金額には相応の根拠があると信頼していたものであり,また,旧BRD及び新BRDが行われた経緯の中で,被告は,原告に対し,本件最終合意書の内容は両者間の合意であり,これを実現する方向で開発を進めるなどと述べ,本件最終合意書の内容を尊重する姿勢を表明していたのであって,これによれば,原告が,平成18年12月に被告から追加費用の負担についての申出を受けた際,被告の対応に不信感を抱いたとしても不思議なことではなく,また,原告の支払金額の増額については,被告側から増額の根拠について十分な理由が提示されない限り,これに応ずる必要はないと考えることにも合理的な理由があるというべきである。
また,被告は,原告が,平成19年1月18日に開催された第25回ステアリング・コミッティにおいて,開発スコープが調整済みであったことを否定し,合意を白紙に戻してしまった旨の主張についても,上記事実を認めるに足りる証拠はない。すなわち,上記ステアリング・コミッティにおいて,C専務は,開発スコープの調整について,「現場の作業を否定するものではない。本件はIBMの経営としてどう責任を取るかという経営マターである。本資料については見直しの上,目的や理由,経緯等のコメントを付けるということでお願いする。」と述べており,これに対して,被告のNは「了解した。」と回答しているのであって(甲6の25),原告が,開発スコープが調整済みであった事実を否定し,合意を白紙に戻してしまったなどということはできない。
カ 以上によれば,本件システム開発について原告には協力義務違反があるという被告の主張は採用することができない。
(4)  被告は,本件プロジェクトの頓挫原因について,開発フェーズのコストの見積りが105億円から226億円に増大したことの定量的分析をすると,原告側に原因(銀行によって内容が異なる要件及び原告独自の要件を開発するための費用の増加)のあるものが91.96億円(82.85%),被告側に原因(邦銀標準のパッケージを作るための費用の増加)があるものが19.04億円(17.15%)であり,圧倒的な割合で原告側の原因によって見積りが増加しているし,仮に,本件最終合意締結後に新たに判明した要件のみが原告側の原因によるものであるとしても,なお56.32%という割合であるから,本件プロジェクトの頓挫原因は原告にあるなどと主張する。
しかしながら,開発費用の増加原因を上記のように分類するのが相当であるのか疑問がある上,そもそも,本件プロジェクトの頓挫原因は上記(2)で述べたとおりの事情であると認められるのであるから,被告の上記主張は採用することができない。
(5)  そうすると,本件システム開発が頓挫したことの責任はもっぱら被告にあるのであり,そのことについて,被告は原告に対してプロジェクト・マネジメント義務違反の責任を負うものというべきである。
4  損害賠償責任に関する契約条項
(1)  本件最終合意書8条ただし書が免責条項であるとの主張について
被告は,「いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。」と規定する本件最終合意書8条ただし書は免責契約であり,被告に債務不履行又は不法行為があった場合でも,被告はそれが故意又は重過失に基づくものであるとき以外は責任を負うことはない旨主張する。
そこで,「いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。」との文言がいかなる意味を有するのかについて検討する。同文言が法的義務を負わないとするのは,本件最終合意書に基づく法的義務のことであり,それも,「各個別契約が締結され,各関連個別契約の中で両当事者の各局面における義務が規定されるまで」は,法的義務を負わないものとするものであって,上記の規定が,例えば不法行為に基づく責任のように,本件最終合意書に基づいて発生するものではない法的義務について,一般的に両当事者の責任を限定したり,免除したりする内容のものとみることはできない。
そうすると,被告の上記主張を採用することはできない。
(2)  本件最終合意書4条の解釈
次に,本件最終合意書4条の規定をどのように解釈すべきであるのかについて検討する。
個別契約が既に締結されている場合,これに関する当事者間の紛争について,個別契約の契約書の条項が法的な効力を有するものというべきであるが,他方,8条ただし書が「各個別契約(第1条記載の個別将来契約を含むがこれらに限定されない。)が締結され,各関連個別契約の中で両当事者の各局面における義務が規定されるまでは,いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。」と規定していることからすれば,個別契約が既に締結されて両当事者の各局面における義務が規定された以上,個別契約に規定されていない事柄については,本件最終合意書の規定が既に締結された個別契約に関わる限度において効力を有するものと解するのが相当である。
そうすると,本件最終合意書4条の規定については,個別将来契約が締結されてこれにより各当事者の義務が規定された以上,本件最終合意書4条の規定が法的効力を有するものと解するのが相当である。
なお,原告と被告との間で平成16年9月29日に締結されたIBM支援サービス契約書(甲5の2)6条1項によれば,「お客様がIBMの責に帰すべき事由に基づいて救済を求めるすべての場合において,IBMの損害賠償責任は,請求の原因を問わずお客様に現実に発生した通常かつ直接の損害に対する,損害発生の直接原因となった当該「サービス」の料金相当額(月額料金の場合は,12か月分に相当する金額,年額料金の場合は1年分に相当する金額)を限度とする金銭賠償に限られます。」と規定されている。また,原告と被告との間で同日に締結されたIBMシステム・インテグレーション契約書(甲5の2)14条本文によれば,「お客様がIBMの責に帰すべき事由に基づいて救済を求めるすべての場合において,IBMの損害賠償責任には請求の原因を問わず現実に発生した通常かつ直接の損害に対してのみ,損害発生の直接原因となった当該別紙所定の作業に対する受領済みの代金相当額を限度(ただし,別紙に損害賠償限度額の記載がある場合にはこれによる。)とする金銭賠償に限られます。」と規定されている。これらの現行契約にかかわる損害賠償責任については,損害賠償額の限度を定める上記の条項が適用されるものと解される(本件最終合意書4条は,個別将来契約について規定したものと考えられる。)。
5  原告の損害
(1)  実損害①について
ア 証拠(甲5の2,5の3の1,5の5ないし7,5の8の1ないし5,5の9,5の10の1,5の10の2,5の11,甲10,甲11の1ないし14)及び弁論の全趣旨によれば,原告は,被告に対し,システム・インテグレーションに関する個別契約に基づき,合計49億1310万4830円を支払ったことが認められる。
イ 証拠(甲5の4の1,甲11の15ないし117,甲156,甲157,甲158の1ないし69)及び弁論の全趣旨によれば,原告は,被告に対し,OIO契約に基づき,合計37億3162万8484円(ただし,甲11の15ないし117の合計21億8451万4120円と甲158の1ないし69の合計15億4711万4364円を合わせた金額)を支払ったこと,このうち,原告が現に使用している資産に関するリース料等の額が20億1260万2641円であることが認められる。そして,上記37億3162万8484円から20億1260万2641円を控除すると17億1902万5843円となる。
ウ 弁論の全趣旨によれば,上記ア及びイの合計66億3268万5847円のうち,「アセットアロケーション/最適商品選定システム」及び「ライフプランニングシステム」については,原告が行っている別件プロジェクトで利用可能であり,これらの対価相当額は7927万5000円であることが認められる。
そして,上記アの支払額49億1310万4830円,上記イの支払額の一部17億1902万5843円の合計額である66億3213万0673円から上記ウの対価相当額7927万5000円を差し引くと,65億5285万5673円となる。そうすると,本件システムを構築するための費用として原告が被告に対して支払った金員のうち,65億5285万5673円が原告の損害となる。
(2)  実損害②について
証拠(甲12,甲13の1ないし33,甲161,甲162の1の1ないし43の2,甲163,甲164)及び弁論の全趣旨によれば,原告は,本件システムで使用するソフトウェアやハードウェアの調達,設備の改造等を行うに際し,被告以外の者に対して15億9847万7055円を支払ったこと,このうち,原告が現に使用している物の金額は7億3766万6600円であることが認められる。そうすると,原告が上記のとおり被告以外の者に対して支払った金員については,上記支払額15億9847万7055円から7億3766万6600円を差し引いた8億6081万0455円が原告の損害となる。
(3)  逸失利益について
原告は,逸失利益として41億6600万円の損害を受けた旨主張するが,原告が本件システム開発をその主張するとおりに完成させることができたかどうか,また,これによって原告が主張するような利益を上げることができたかどうかについては,なお不確定の要素が含まれているのであり,本件システム開発により利益を上げられた事実を認めるに足りる証拠はない。
(4)  以上によれば,上記システム・インテグレーションに関する個別契約及びOIO契約に基づく支払,本件システムで使用するソフトウェアやハードウェアの調達,設備の改造等のための支払は,いずれも本件システム開発の一環としてされたものであるから,本件システム開発が被告のプロジェクト・マネジメント義務違反により頓挫してしまい,原告による上記支払が意味のないものとなってしまった以上,原告の損害を構成するものというべきである。そうすると,原告は,被告のプロジェクト・マネジメント義務違反により,実損害として,合計74億1366万6128円(上記(1)の65億5285万5673円と上記(2)の8億6081万0455円との合計額)の損害を受けたものというべきである。
6  損益相殺
(1)  被告は,①再利用可能な成果物の客観的価値相当分(要件定義書,システム設計書,他社製パッケージソフトウェア)42億3921万6201円,②プロジェクト頓挫により原告が債務を免れる結果となる本件未払個別契約①及び②に基づく未払金13億6960万1493円,③プロジェクト頓挫により原告が債務を免れる結果となる暫定的合意書(LOI)に基づく債務2億3100万円について,損益相殺として原告の損害から控除されるべきである旨主張するので,この点について検討する。
(2)  再利用可能な成果物の客観的価値相当分42億3921万6201円
被告は,被告が本件個別契約に基づき原告に納入した成果物の大部分は本件プロジェクトが頓挫したとしても,被告以外のベンダとの開発において利用が可能であり,上記成果物の客観的な価値相当分は原告の損害を構成しない旨主張する。
まず,被告が原告に納入した要件定義書についてであるが,上記成果物が客観的な価値を有することを認めるに足りる証拠はない。かえって,証拠(甲165,甲170,甲172,甲173,証人O)及び弁論の全趣旨によれば,原告が被告以外のベンダとの間で現にシステム開発を行っている別件プロジェクトではソフトウェアとしてCorebankが用いられていないこと,ベンダとパッケージソフトウェアが異なれば要件定義のやり方が異なってくるし,要件定義書の内容も異なってくるのであって,被告が原告に納入した要件定義書を別件プロジェクトに利用することは困難であること,上記要件定義書は,平成18年当時の内容しか反映していないものであり,内容的に古くなっていること,他のベンダは,上記要件定義書の内容について,被告から引き継ぎを受けることも,被告に問い合わせをすることもできないのであり,これを別件プロジェクトに転用するには多大な作業と費用を要すること等の事情が認められるのであって,これによれば,上記要件定義書は客観的な価値を有するとはいえないものというべきである。そして,上記の結論は,乙382号証,乙384号証,証人Pの証言等によっても左右されることはない。
次に,被告から原告に納入されたシステム設計書についてであるが,本件プロジェクトで採用の予定されていたパッケージ又は製品が,原告が行っている別件プロジェクトにおいて客観的に利用され得るものであるとの事実を認めるに足りる証拠はない。そうすると,上記システム設計書が客観的な価値を有するものということはできない。
さらに,他社製パッケージソフトウェアについてであるが,本件全証拠によっても,原告が別件プロジェクトで利用可能であると自認するアセットアロケーションシステム等を除き,SAPパッケージ及びCRMパッケージを含めて原告において別件プロジェクト等で利用し得るものがあるとの事実を認めることはできない。
以上のとおり,被告が本件個別契約に基づき原告に納入した成果物の大部分には客観的利用価値があるとする被告の主張は,採用することができない。
(3)  本件未払個別契約①及び同②に基づく未払金13億6960万1493円
証拠(甲15の1)及び弁論の全趣旨によれば,原告は平成19年7月18日に被告の債務不履行を理由として本件最終合意及び本件個別契約(本件未払個別契約①及び同②を含む。)を解除する旨の意思表示をした事実が認められるところ,本件システム開発について被告のプロジェクト・マネジメント義務違反が認められる以上,本件未払個別契約①及び同②に基づいて,原告が被告に対して契約代金を支払うべき義務はないものというべきである。そうすると,被告は,本件未払個別契約①及び同②に基づく未払金の請求権を有しないのであるから,上記未払金相当額を損益相殺として原告の損害から控除すべきであるとする被告の主張は理由がない。
(4)  LOIに基づく債務2億3100万
上記のとおり,原告が被告の債務不履行を理由として本件最終合意及び本件個別契約(本件未払個別契約①及び同②を含む。)を解除する旨の意思表示をした事実が認められ,また,本件システム開発について被告のプロジェクト・マネジメント義務違反が認められる以上,原告はLOIに基づく債務を負わないものというべきである。そうすると,被告は,LOIに基づく代金の請求権を有しないのであるから,この代金相当額を損益相殺として原告の損害から控除すべきであるとする被告の主張は理由がない。
7  本訴請求に係るその余の争点について
(1)  争点(3)(本件個別契約の債務不履行解除の成否)及び争点(4)(説明義務違反の有無)について
仮に,被告に本件個別契約の債務不履行があり,原告に債務不履行解除が認められた,又は被告に説明義務違反があったとしても,前記3で判示した被告のプロジェクト・マネジメント義務違反に基づき,前記5で算定した原告の損害額を上回るとはいえないので,争点(3)及び(4)については判断しない。
ただし,本件個別契約の債務不履行解除の成否については,後記8において,争点(7)(反訴請求の可否)の判断に必要な範囲で触れることとする。
(2)  争点(5)(錯誤の有無)について
原告は,本件個別契約の全てはCorebankを大前提にして締結されたものであるから,実際にCorebankの採用が不可能であったということは契約の重要な要素について錯誤があると主張して,錯誤無効に基づく原状回復請求として,被告に対して65億5341万0847円の支払を求めているが,この請求額が上記5で算定した原告の損害額を上回るものではないので,上記主張に係る争点(5)についても当審の判断を示すことはしない。
(3)  被告による相殺の主張について
なお,前記のとおり,被告のプロジェクト・マネジメント義務違反に基づくものとして当裁判所が認める原告の本訴請求債権は,不法行為に基づく損害賠償請求であるので,被告が主張する相殺の受働債権には当たらない。
8  争点(7)(反訴請求の可否)について
(1)  本件未払個別契約に基づく請求(反訴請求の趣旨1項に係るもの)について
ア 原告と被告が本件未払個別契約①及び同②を順次締結したこと,被告が,本件未払個別契約①所定の成果物を平成18年3月31日に原告に対して納品し,原告による受領,受入検査を完了したこと,被告が,本件未払個別契約②所定の成果物のうち,「設計・実装局面 作業計画」を除く「基幹系・取引機能マトリックス」等を同年12月26日までに原告に対して納品し,原告による受領,受入検査を完了したことは当事者間に争いがない。
イ しかし,前記3(2)のとおり,本件システム開発について被告のプロジェクト・マネジメント義務違反が認められ,前記前提事実(第2の2(9)セ)のとおり,原告が平成19年7月18日に本件最終合意及び本件個別契約(本件未払個別契約①及び同②を含む。)を解除する旨の意思表示をした以上,本件未払個別契約①及び同②に基づいて,原告が被告に対して契約代金を支払うべき義務はなく,被告は,原告に対し,本件未払個別契約①及び同②に基づく未払金の請求権を有しないものというべきである。
したがって,本件未払個別契約①及び同②に基づく被告の反訴請求は理由がない。
(2)  協力義務違反等の不法行為に基づく損害賠償請求(反訴請求の趣旨2項に係るもの)について
原告には,本件システム開発について協力義務違反があるとはいえないこと,被告との間で不誠実な交渉をしたということもできないことについては,前記3(3)のとおりである。その他,原告が被告に対して不法行為をしたことの根拠となる事実を認めるに足りる証拠はない。
したがって,被告の上記損害賠償請求も理由がない。
(3)  ESO契約対象ソフトウェアの使用料金に係る請求(反訴請求の趣旨3項に係るもの)について
ア 原告と被告がOIO契約及びESO契約を締結したこと,原告のESO契約対象ソフトウェアの使用料金実績金額は,平成20年度において1783万4000円(消費税抜き),平成21年度において9649万0400円(消費税抜き)の範囲で,いずれも使用料金上限値を超過したこと,被告は,原告に対し,平成22年2月26日,上記使用料金超過額に消費税を付加した次の金額(平成20年度について1872万5700円,平成21年度について1億0131万4920円。いずれも消費税抜き)を請求したことは当事者間に争いがない。
イ これに対し,原告は,ESO契約対象ソフトウェアの中には実際には全く使用されていない新経営システム用のソフトウェアが含まれていて,これについての使用料金も実績金額に含まれていたのに,被告がこれをESO契約の対象から外すことを拒否していたのであり,これがESO契約の対象から外されていれば,平成20年度については,使用実績値が「使用料金上限値」を超えることはなく,支払う必要のない4430万0865円を支払ってしまったし,平成21年度については,使用実績値が「使用料金上限値」を超えた金額は3814万1775円にすぎなかったものであるとして,上記4430万0865円の不当利得返還請求権を自働債権とし上記3814万1775円を受働債権として対当額において相殺する旨主張している。
そこで,検討するに,前記のとおり,本件プロジェクトが頓挫したのは被告のプロジェクト・マネジメント義務違反によるものであるというべきところ,証拠(甲175,甲176,乙372,乙373の1,2,乙374)及び弁論の全趣旨によれば,ESO契約対象ソフトウェアの中には,本件プロジェクトが頓挫したために実際には全く使用されていない新経営システム用のソフトウェアが含まれていること,平成19年10月以降,これについて,原告が被告に対して交渉したにもかかわらず,被告はこれをESO契約の対象から外すことを拒否したこと,平成20年度及び平成21年度において,これについての使用料金を原告は被告に対して支払ったこと,これがESO契約の対象から外されていれば,平成20年度については,使用実績値が「使用料金上限値」を超えることはなく,かえって,原告は,支払う必要のない4430万0865円を支払ったこと,平成21年度については,使用実績値が「使用料金上限値」を超えた金額は3814万1775円にすぎなかったこと等の事実が認められる。
そうすると,上記4430万0865円の不当利得返還請求権を自働債権とし,上記3814万1775円を受働債権として対当額において相殺する旨の原告の抗弁には理由がある。
ウ 以上によれば,ESO契約対象ソフトウェアの使用料金に係る被告の反訴請求も理由がない。
第4  結論
以上によれば,原告の本訴請求は,原告が被告に対し不法行為に基づく損害賠償として74億1366万6128円及びこれに対する不法行為の後である平成19年7月18日から支払済みまで民法所定の年5分の割合による遅延損害金の支払を求める限度で理由があり,その余は理由がないというべきである。また,被告の反訴請求は,その余の点を判断するまでもなく,いずれも理由がない。よって,原告の本訴請求を上記の限度で認容し,その余の本訴請求を棄却することとし,被告の反訴請求をいずれも棄却することとして,主文のとおり判決する。
(裁判長裁判官 髙橋譲 裁判官 榮岳夫 裁判官 山下浩之)

 

*******

関連記事一覧

  • コメント ( 0 )

  • トラックバックは利用できません。

  1. この記事へのコメントはありません。