判例詳解シリーズ第１段のスルガ銀行vs日本IBM事件。前回に続いて第２部は「一審の判断」。
目次
第１ 事案の概要
第２ 一審の判断 （本エントリ）
第３ プロジェクトマネジメント義務総論
第４ 企画・提案段階におけるプロジェクトマネジメント義務
第５ プロジェクト推進中におけるプロジェクトマネジメント義務
第６ 基本合意書・最終合意書の意義
第７ 議事録等に基づく事実認定
第８ 損害の額と，責任限定条項の解釈
第９ 過失相殺と損益相殺
第２ 一審の判断
平成20年に提起された本件訴訟の判決日は平成24年3月29日。スルガ銀行(X)の請求は，日本IBM(Y)が，
（１） 基本合意や個別契約に基づく「本質的義務」を，本旨に従った履行をしなかった，
（２） 本件プロジェクトが中止に至ったのは，プロジェクトマネジメント義務違反があった，
ことなどを理由に，請負契約の債務不履行又は不法行為に基づく損害賠償を求めるというものであった*1。
結論は，ほぼXの主張が認められたといってもよく，請求額115億8000万円のうち，約74億円が認容された（退けられた部分は，主に逸失利益であった。）。反訴は棄却された。
よく知られているとおり，この判断は，控訴審で変更され，認容額が減額されている。しかし，その違いは，事実認定が変更されたというよりは，一定の事実に対する評価が分かれたというものである。基礎となる事実には両判決において大きな違いはない。
本質的義務
Xは，（前回の事実の概要で示したように）平成17年9月に締結した「最終合意」に基づいて，Yが，平成20年1月までに，代金89億7080万円で，システムを完成・納入し，稼働させる義務等の本質的義務を負っていたところ，Corebankの採用を断念するなどして，本旨に従った履行をしなかったと主張していた。
この点については，前回も引用したように，最終合意には「法的拘束力を負わない」という文言の解釈が争点となった。
本件最終合意書１条及び８条ただし書によれば、本件最終合意書に記載されたXの支払金額の法的拘束力については、XとYとの間で本件プロジェクトの各局面における義務を定めた個別契約が締結されることを前提条件として生ずるものとされていると解すべきである。
（略。注：開発・テスト以降の個別契約の大半が未締結であるから）上記支払総額が法的拘束力を有するに至る程度に条件が充たされているとはいえないので、Yの債務不履行又は不法行為の成立をいうXの上記主張は採用することができない。
と述べて，最終合意に基づいてXが主張するような本質的義務が生じるものではないとした。詳細は，別途「基本合意書・最終合意書」の点でも触れるが，一審では，上記の判断に続いて，最終合意について注目すべき判示がなされている。
上記支払総額の規定が設けられたのは両当事者が目標とする重要な指針を定める趣旨であることは疑いのないところであり、本件最終合意書が交わされた平成１７年９月３０日の時点において、Yは、本件システム開発のコスト見積りの前提となる基礎数値を確定させてXの支払金額を決めたものであることなどからすれば、上記支払総額の規定された本件最終合意書が交わされたとの事情が、Yの信義則上ないし不法行為上の義務違反の有無を考慮するに当たり意味を有し得るものであることを否定するものではない。
上記の太字部は，相当回りくどく，何が言いたいのか伝わりにくいが，要するに，「裁判所はちゃんと考慮しますよ」ということだろう。
なお，この主張は，控訴審では維持されていない。明示的に「法的拘束力なし」と書かれていた書面を中心に据えた主張であったわけだし，X側ももともと，「あわよくば」的な意味で主張していたのかもしれない。
プロジェクトマネジメント義務
大まかに言えば，一審では，パッケージを用いた開発を行う場合には，パッケージの機能や充足度，開発手法，カスタマイズを含めた開発体制について，Yが事前に十分な検討・検証をしていないことが，プロジェクトマネジメント義務違反にあたるとした。
ベンダの義務内容について述べた部分が下記のとおり。
本件のように、ベンダとユーザとの間でパッケージ型システム開発が行われる場合、パッケージの選定は、開発の対象となるシステムの根幹を成すものであり、その適切な選定、開発方法の採用は極めて重要な課題である。システム開発の専門家であるベンダは、パッケージの選定に当たり、パッケージの機能・性能、設定・導入の容易性、導入実績、パッケージの提供者の導入実績、経営の安定性、技術力、カスタマイズへの積極性その他関連する諸事情を考慮して、ユーザが構築しようとしているシステムに最適のパッケージを選定した上、これに適した開発方法を採用しなければならず、そのために、ベンダは、ユーザへの提案前に様々な観点からパッケージの機能、開発手法、リスク等について十分に検証又は検討しなければならないものというべきである。加えて、それまで日本の銀行の基幹系のシステム開発において海外のパッケージが用いられたことはなかったのであり、しかも、Yは、製造業や流通業でのパッケージ・ベース・アプローチの経験はあるが、銀行のシステムをこの手法で開発した経験がなかったのであるから、Yとしては、本件システム開発に当たって、より慎重に、パッケージの機能、開発手法、リスク等について検証又は検討し、適切な開発方法を採用しなければならないものというべきである。
その上で，上記の３つのポイント（パッケージの機能，開発手法，開発体制）について，いずれも十分な検討・検証を行ったものではないとした。
まず，機能については，Yの役員らの会議における発言等を根拠に，十分な検討をしていないとした。開発手法についても，当初はパッケージに合わない部分をカスタマイズして合わせようとするカスタマイズ・ベース・アプローチとしながらも，途中からパッケージにできるだけ業務を合わせようとするパッケージ・ベース・アプローチに変更したということなどを挙げて，十分な検討をしていないとした。そして，開発体制についても，パッケージベンダのFISとの調整が後になって迷走したことを挙げて，十分な検討をしていないとした。
要するに，プロジェクトの企画，提案の段階から，十分に検討をしていないシステム構成を提案したことが，プロジェクトマネジメント義務違反にあたるのだから，その提案を信じてXが支払った金銭は，基本的に全額損害に当たるとした。
控訴審の判断にも通ずるが，最終合意を締結した時点におけるYの言動についても，次のように述べている。
仮に、Yとして、本件最終合意書を交わした後の段階において、新たにＢＲＤを実施してみなければ確実な見積りができないため、ＢＲＤの内容いかんにより本件最終合意書で記載された代金額の修正をXに対して申し出るつもりであったのであれば、その時点でこれをXに説明して、そのような前提の下でYとの本件プロジェクトを続けるのか否かを判断する機会を与えることもできたというべきである。それをすることなく、Yは、開発手法の変更があっても本件最終合意書の内容を尊重する旨をXに告げて本件システム開発を続け、Xからはその間に代金の支払を受けた上、後になってＢＲＤの実施により事情が変わったなどとしてXに支払金額の増額を申し出たのであり、このようなYの対応は、Xに対し、信義に反するものであるとの不信感を抱かせるものというべきである。
最終合意を結ぶ段階で，問題があるのであれば，ベンダであるYは，その旨を言うべきであったのに，それを告げずにプロジェクトを継続させ，最終合意の締結から間もない時期に，増額を申し出たのは不信感を抱かせたとする。
損害論については，追って詳細に分析するが，Yは，途中まで作成した成果物には，客観的価値があるから，その価値相当額は損害額から減額されるべき（損益相殺）との主張をしたが，Yの主張は退けられた。
この判断を基準にすると，ベンダは，ユーザに対して，事前に製品の内容，開発手法，開発体制などをきっちり検証したうえで提案しなければならず，新しい製品，ソリューションの適用がかなり難しいという印象を抱かせるものであった。
*1:そのほかにも，「説明義務違反」や「錯誤による無効」の主張もあったが，ここでは割愛する。
