第15号　勘定系システム開発失敗で約４２億円の支払を命じる判決　

～システム開発トラブルで起きる諸問題（スルガ銀行vs日本ＩＢＭ事件 ）※1～

１　はじめに

海外製の勘定系パッケージソフトをカスタマイズするシステム開発が失敗に終わり、ユーザーである銀行とベンダーとの間で相互に相手を訴えあう泥沼の巨額訴訟に発展した。今回は、その控訴審判決を取り上げる。
控訴人（被告）はベンダーである日本ＩＢＭ、その相手方の被控訴人（原告）はユーザーであるスルガ銀行である。各当事者についた訴訟代理人も著名弁護士であり、裁判所が巨額の支払を命じたこともあって注目されている。
筆者もこの種の訴訟を取り扱ったことがあり、事実上の争いにおいては技術的な問題を明確にする必要があり、法律的にも微妙な評価が分かれる問題が多く、難しい訴訟となりやすい。その開発費用が大きいプロジェクトであればあるほど、その争いも深刻となる。
本件は、一般的なベンダーとユーザーのトラブルとしても検討する意義があるので、判決書の「原告」「被控訴人」を「ユーザー」と、「被告」「控訴人」を「ベンダー」とそれぞれ読み替えて解説していくことにする。

２　本事案の概要

元来、このベンダーは、ユーザーのシステムの管理・運用支援等を行っていたところ、平成１２年頃、ユーザーから基幹系システム構築の提案等の依頼を受け、同年９月からその提案等の検討を進め、平成１５年７月に提案書を提出した。ユーザーは、複数の他の業者からのパッケージソフトの提案とも比較検討した結果、海外で実績のあったベンダーの金融機関向けの汎用パッケージである「ＮＥＦＳＳ」の選定を決定した。この決定を受け、両社は、次のように、いくつもの契約を締結しながら、銀行業務全般を処理する「新経営システム」（本件システム）の開発を目指した。
（１）両社は、平成１６年９月２９日、本件基本合意①を締結した。これにより、ベンダーが開発を進めていたＮＥＦＳＳの第１号案件として、本件システム開発が開始された。
（２）両社は、その作業結果を踏まえ、平成１６年１２月２９日、本件基本合意①を修正した本件基本合意②を締結した。
（３）しかし、計画・要件定義作業により明らかとなる開発スコープ等を踏まえて締結する予定だった最終合意の内容をなかなか固めることができず、その合意の時期がどんどん延期され、両社は、計画・要件定義による成果を待つことなく、平成１７年９月３０日、本件最終合意を締結し、プロジェクトの基本的な運営に関する覚書を締結した。
（４）その後も進捗は難航し、合意した開発日程どおりにシステム稼働させることができない状況で、ベンダーがユーザーの予期しない提案を行ってユーザーの責任者等を激怒させ、ベンダーへの信頼関係を失わせる等した。結局、ユーザーは、平成１９年７月１８日、同月１７日付け内容証明郵便により、ベンダーに対し、本件最終合意及び本件最終合意に関連する全ての個別契約をベンダーの債務不履行（履行不能）を理由に解除するに至り、本件システム開発は中止された。
この開発中止によって大損害を被ったユーザーは本訴を提起し、本件システム開発の中止につき、ベンダーの①本質的義務（平成２０年１月までに、総額８９億７０８０万円で本件システムを開発させる義務）違反、②プロジェクト・マネジメント義務違反、③説明義務違反を主張し、併せて、本件個別契約はいずれもユーザーの錯誤により無効である等と主張した。請求原因は、請負契約の債務不履行又は不法行為に基づく損害賠償請求権（前記①ないし③）、又は不当利得に基づく原状回復請求権からなり、ユーザーがベンダーに対して総額１１５億８０００万円とその遅延損害金の支払を求めた。
これに対して、ベンダーも反訴を提起し、ユーザーに対して、（ア）本件未払個別契約①及び②に基づく代金とその遅延損害金の支払、（イ）ユーザーの協力義務違反の不法行為に基づき、ＮＥＦＳＳ構築のための投資費用相当額とその遅延損害金の支払等を求めた。

３　判決の意義

第一審判決は、ベンダーに不法行為に基づく損害賠償責任を認めて約７４億円の支払を命じ、ベンダーの反訴請求を全部棄却した　（東京地裁判決2012年3月29日※4）が、控訴審判決（東京高裁判決2013年9月26日）はベンダーの賠償責任を認めたものの、その損害額を大幅に減額し、第一審判決と比べると６割未満の賠償金額になった。
第一審判決では、システムの企画設計から要件定義、開発中止に至るまでの全体にわたって、ユーザーがベンダーに支払った費用について損害として認めていた。これは実質的にユーザー側が主張する実損害分をほぼ満額認めたに等しかったようだ※5。
しかし、控訴審判決は、損害額の範囲を見直し、ユーザーにも一定のリスク負担を認めて、最終合意書を交わした平成１７年９月末日以降の費用に限定した。その結論に至るまでの判決理由は、極めて数多くの教訓を含んでいる。細かい論点に対する裁判所の判断はオーソドックスなものも含んでいるが、微妙な問題も多く、システム開発契約をめぐる法律上の諸問題を検討するには格好の素材といえよう。
システム開発会社はもちろん、大きなプロジェクトを発注する事業者、相互に協力しなければならないプロジェクトの業務委託又は請負契約を締結するビジネスに関与する事業者等の法務担当者にとっても、大いに参考になる事例であろう。

４　多岐にわたる論点

注目すべきポイントは多岐にわたり、興味深い素材が数多く含まれている。そのうち、ごく一部を取り上げて紹介してみたい。
（１）ステアリング・コミッティの議事録の証拠価値
まず、この種のトラブルで用いられる証拠に関して、ステアリング・コミッティの議事録に基づく事実認定が争われた。ベンダーは、その議事録に基づいて本件システム開発の経過を認定することについて、議事録の記載内容はユーザーから修正を加えられたものであり、作業等の実態を必ずしも反映していないと主張した。
しかし、控訴審判決は、その会議の性質や議事録データベースの記録化の状況を踏まえて、その内容と表現は会議の実態を反映したものであるとして、事実認定の大きな拠り所としている。この点は、トラブル防止の観点から重要であるだけでなく、議事録が将来起きるかもしれない紛争の帰趨を左右するものだと知っておく必要がある※6。
（２）ベンダーの義務
控訴審判決は、この種の契約におけるベンダーの義務を明らかにしている。
第一に、企画・提案段階において、ベンダーは、「自ら提案するシステムの機能、ユーザーのニーズに対する充足度、システムの開発手法、受注後の開発体制等を検討・検証し、そこから想定されるリスクについて、ユーザーに説明する義務がある」と指摘する。かかるベンダーの検証、説明等に関する義務は、契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務としても位置づけられるものであることを判示しており、ベンダーは、この段階でもプロジェクト管理に関する義務を負うことを明らかにしている。
第二に、ベンダーは、ユーザーに対し、システム開発過程において、適宜得られた情報を集約・分析して、ベンダーとして通常求められる専門的知見を用いてシステム構築を進め、ユーザーに必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整等を行いつつ、本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負う。
第三に、システム開発は必ずしも当初の想定どおり進むとは限らず、当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり、想定していた開発費用、開発スコープ、開発期間等について相当程度の修正を要すること、更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから、ベンダーは、「そのような局面に応じて、ユーザーのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説明義務」を負う。
（３）ユーザーにもリスク分析が求められる
だからといって、ベンダーにすべてお任せできるとは限らない。本件基本合意書①には、一定の条件付ながら、「ユーザー側要員費用を含めて９５億円内で本件システムの稼働を実現することを確約する」との規定が設けられ、本件システム開発に投じるユーザーの負担額に一定の想定枠が設定された。こうした定めからすると、最終的にシステムが稼働しなかった以上、ベンダーの責任は免れないかのように思われるかもしれない。
しかし、本件基本合意書①には同時に、計画・要件定義の結果次第によって開発の遂行が困難となる事態も想定して「本条に定める合意（本件最終合意）までの間に、プロジェクトの大幅な延期や中止せざるを得ない状況が発生した場合、あるいは、本条に定める合意に至らなかった場合には、両者は真摯に協議の上、互いに誠意をもって損害賠償等の措置を含む適切な対応をするものとする。」との定めが設けられた。
これを踏まえて、控訴審は、「ユーザーにもシステム開発の対象とされる業務の分析とベンダーの説明を踏まえ、システム開発について自らリスク分析をすることが求められる」と指摘し、「企画・提案段階における検討・検証等において、その後の遂行過程で生じた事情、要因等を漏れなく予測することは困難であったといえ、本件システム開発の過程において一定の修正等があり得ることも当然想定されていたものというべきである」として、最終合意をする前の段階においては、ベンダーにプロジェクト・マネジメントに関する義務違反を認めることはできないと判断した。この点が、控訴審判決で賠償額が大幅減額されるに至った大きなポイントにもなっている。
本件において、そのシステム開発が中止されるに至った原因は、その開発過程で、ベンダーの提供できる機能とユーザーが求める機能との間のギャップが大きいことが次第に明らかになり、開発スコープの調整に失敗し、開発計画の大幅な遅延、開発費用の増大を招き、ついには開発進行自体についての調整が困難となったことによる。その意味では、当初からベンダーの企画提案が邦銀の勘定系システムに導入するソフトとしての性能をおよそ備えていなかったとまではいえないものだった。
しかし、もしも当初からその性能を備えていないのであれば、ベンダーには全面的な責任が生じうることもありえよう。それに対して、それなりの性能を備えたものであれば、ユーザーの側もその進行を上手にクリアしなければ、システムが稼働しなかった場合の責任を負うことになろう。
（４）　責任限定条項の有効性と適用
本件基本合意①及び同②には、責任限定条項はなかったが、本件最終合意締結前の個別契約や本件最終合意書には、いくつかの責任限定条項があった。これらの有効性や適用についても争われたが、控訴審判決は、「契約当事者間において、当該契約に起因して発生する損害賠償の成立要件、範囲につき、特別の定めをすることは、その内容が公序良俗に反しない限り有効なものである」と判示した。
また、「故意又は重過失がない場合における損害賠償の責任限定条項は、公序良俗に反するものとはいえないし、ベンダーとユーザーとの間では、大手企業間における重要取引として、当時の状況を踏まえて交渉を重ね、弁護士等の助言を受けながら検討をして合意に至ったものと認められるから、その合意は有効であるというべきであり、ベンダーの契約違反及び不法行為については、その約定に定める点にはそれが適用され、約定に定めるところに従って判断されるべきものである」としている。
これらはオーソドックスな判断であるが、ユーザーは、「プロジェクト・マネジメント義務がシステム開発契約の本質的義務であり、本件最終合意や個別契約から導き出されるものではないとして、本件最終合意の責任限定条項が及ばない」とも主張した。しかし、控訴審判決は、「責任限定条項は、本件システム開発において、ベンダーがベンダーとして当然に果たすべき義務を想定し、その義務違反があったときの損害賠償額の予定について合意したことは明らか」だとして、ユーザーの主張を排斥している。

５　結びに代えて

今回のシステム開発の失敗は、ベンダー、ユーザーのいずれかが一方的に悪かったとはいえない事案であった。双方に生じた損害は、決して回復することのできない巨額なものであり、その後の紛争費用も含めて、その学習コストは余りにも高いものであった。
システム開発の失敗には、必ず原因がある。その双方協議における記録の取り方、双方の義務の履行段階における内容に至るまで、適切な法的助言を受けていれば、その状況はまた変わっていたかもしれない。
こうしたシステム開発に取り組む場合には、その選定段階から、開発に伴うリスクを十分に踏まえたシステム開発契約の締結が求められる。また、プロジェクト・マネジメントは、法的観点からもチェックをすることが有用であろう。多くの営業・技術担当者に加えて、将来の紛争予防の観点からも、こうしたプロジェクトにおける法務の役割を考えていくことが望まれる。