判例評釈速報：ＩＢＭ／スルガ銀行システム開発事件〜東京地判平成２４年３月２９日判例集未登載（控訴）

作者: 電子情報技術産業協会ソリューションサービス事業委員会
出版社/メーカー: 商事法務
発売日: 2008/10
メディア: 単行本
購入: 4人クリック: 57回
この商品を含むブログ (1件) を見る

１　事案の概要及び主な争点
　本件は、地方銀行であるＸが、システムベンダであるＹとの間で新経営システムと呼ばれる勘定系システム再構築プロジェクト（以下、「本件プロジェクト」という。）に関する契約を締結し、再構築を委託したところ、本件プロジェクトが頓挫したことから、ＸがＹに対し損害賠償を請求する訴訟を提起し、ＹがＸに対して反訴を行ったというものである（以下、「本件訴訟」という。）。

　主な時系列は以下の通りである。
・２００４年９月　　　　プロジェクト開始（２００８年１月稼働予定）
・２００５年９月　　　「最終合意書」作成（以下、「本件合意書」という。）
・２００６年１２月頃　両当事者間でスケジュール及び追加費用について交渉
・２００７年４月　　　ＹがＸに対し他のパッケージソフト採用の検討を勧誘*1
・２００７年５月　　　ＸはＹに対しプロジェクトを白紙に戻すことを通知
・２００８年３月　　　Ｘが提訴（１１１億７００万円請求*2）
・２００８年４月　　　第１回口頭弁論
・その後　　　　　　　弁論準備による非公開の手続が２０１０年まで継続
・２００８年８月　　　Ｙが反訴（１３億７４００万円請求）
・２０１０年前半　　　証人尋問
・その後　　　　　　　再度弁論準備による非公開の手続
・２０１１年７月　　　証人尋問
・２０１１年１０月　　結審
・２０１２年３月　　　判決（以下、「本件判決」という。）

　本件訴訟では、以下の３点が主な争点となった。
（１）本件合意書がシステム完成に至るまでの一括請負契約を意味するか
　プロジェクト開始段階では、新システムを９５億円で開発するという基本合意書が交わされ、また、要件定義工程の個別契約が締結されて要件定義が開始された。そして、要件定義継続中の２００５年９月に締結された本件合意書においては、「新システムを８９億７０８０万円で開発し、２００８年１月に稼働させる」と記載されていた*3。
　Ｘは、本件合意書により、システム完成に至るまでの一括請負契約が成立しているところ、Ｙは結局システムを完成することができなかったのだから、Ｘとして報酬を支払う理由はないので、既に支払った報酬である約６０億円*4は返還されるべきであると主張した。
　これに対し、Ｙは、あくまでも今後次フェーズ以降の個別契約を結ぶことが前提となっており、両者は、そのような費用と納期となるような形で個別契約を今後結ぶことを想定していることを確認したのが本件合意書に過ぎず、本件合意書により最終納期や報酬額が確定したものではなく、また、Ｙは要件定義工程における個別契約を履行したのだから既払い報酬は返還する必要はなく、むしろ、個別契約の範囲外の追加作業を大量に行っており、Ｘとして追加報酬金を支払うべきであると主張した*5。

（２）要件定義失敗の責任はユーザ側にあるかベンダ側にあるか
　Ｘは、要件定義を３回繰り返してスケジュールを遅延させた後、２００６年１１月頃からＹ側が大幅な機能削減と稼働延期を要求しており、Ｙ側のプロジェクトマネジメント失敗が要件定義失敗の原因であると主張し、このようなＹ側の責任による本件プロジェクト失敗により、Ｙは債務不履行責任を負うから、上記の既払い報酬に加え、本件プロジェクトが成功した場合に得られたはずの逸失利益を含む計１１５億８０００万円が支払われるべきであると主張した。
　Ｙは、要件定義が終わらなかった理由はＸの責任だと主張する。Ｘの現行業務が、内容の微妙に異なる類似商品を多数販売するといった非効率的なものであったところ、Ｘの責任でＢＰＲ（Business Process Reengineering）を実施して業務をスリム化し、これを前提とした新システムを構築することが合意されていたところ、Ｘが業務のスリム化をすることができず、新システムの要件を予定通りに提示しない等、要件定義に非協力的であった。その結果３回の要件定義が必要になった他、開発範囲が当初の予定よりもはるかに多くなり、スケジュール遅延及び開発費用の増大が発生した。この点は、２００５年１１月頃から、Ｘに対して業務改革に主体的に取り組むことを強く要望していたが、それが実現せず、２００６年１１月頃からＹ側として、スケジュールを延期すると共に、開発範囲増大に伴う開発費用の増加を説明し、次期工程の個別契約を、開発範囲増大に応じた適正価格で行うよう依頼したものの、Ｘがそれを不合理に拒み、本件プロジェクトが頓挫したと主張した。
　Ｘは、これに対し、Ｘとしては、後述のとおり、本件プロジェクトがCorebankと呼ばれるパッケージを前提としたものであるところ、Ｘとしてはパッケージのアドオン（追加開発）をできるだけ避けるため、業務のスリム化を最大限図り、残高のない商品の終了、残高のある商品の販売停止及び別商品との切り替え依頼等、要件定義に最大限協力したのであって、Ｘには何ら要件定義失敗の責任はないと主張した*6。

（３）ＹによるCorebank採用断念によりシステム構築が不可能になったのか
　Ｘは、本件プロジェクトが、Corebankと呼ばれる米フィデリティ・インフォメーション・サービス（以下「ＦＩＳ」という。）の勘定系パッケージソフトを元にした開発を行うことが合意されていたところ、ＹにはCorebankの知識が不十分であったために、Ｙが納期及び費用について過少見積りをし、更にＹによる要件定義の内容がCorebankと整合しないことや、ＹとＦＩＳとの役割分担・権利関係の調整に失敗した結果、ＹとしてCorebankに基づくシステム開発ができないことが判明し、２００７年４月頃、Corebankから採用するパッケージソフトを変更したいと懇願した。しかし、これは本件プロジェクトの前提を破壊するものであり、まさにＹの責任によるCorebank採用断念によりシステム構築が不可能になったものであると主張した。
　これに対し、Ｙは、Corebankの採用は断念しておらず、Corebankを前提とした開発は十分可能であったところ、ＸによるＢＰＲ失敗のため、要件が膨れ上がったことから、２００６年１２月からの交渉を行い、その中で、Corebankを前提に納期と費用を大幅にオーバーしたシステムを構築するか、Corebankを前提に要件を削減したシステムを構築するか、それとも、他のパッケージを前提としたシステムを構築するかといった様々なオプションを提示し、Ｘと折り合いのつくビジネス的解決を模索したものであり、２００７年４月頃のレターも、そのような趣旨として理解されるべきであるところ、結局２００７年５月にＸはシステム開発中止の通知を行い、Ｘが一方的にプロジェクトを中止したと主張した*7。

２　判旨*8
　本件判決は、上記各争点について以下のように判示し、Ｘの請求額につき７４億１３６６万６１２８円分を認容*9してそれ以外を棄却し、更にＹの請求全額を棄却した。訴訟費用はＸが１、Ｙが５の割合で負担することとした*10。

（１）本件合意書がシステム完成に至るまでの一括請負契約を意味するか
　本件合意書の内容及び本件合意書が、既に２００４年９月の要件定義開始後１年を経た２００５年９月に締結されたといた経緯から、本件合意書はシステム完成に至るまでの一括請負契約を意味するものであり、ＹはＸに対し、（Ｘの適切な協力を前提に）新システムを８９億７０８０万円で開発し、２００８年１月に稼働させる義務を負う。

（２）要件定義失敗の責任はユーザ側にあるかベンダ側にあるか
Ｘ側に落ち度がない訳ではないが、要件定義の失敗の責任は主としてＹ側のCorebankパッケージについての理解の不足や、プロジェクト管理義務の懈怠によるものである。

（３）ＹによるCorebank採用断念によりシステム構築が不可能になったのか
　ＹがCorebankの採用を完全に断念したのかは兎も角、上記のように要件定義失敗の責任はＹ側にあり、その結果、納期と予算の大幅な超過が発生しており、いずれにせよシステム構築は、Ｙの責任で不可能になったものと言わざるを得ない。

３　コメント
（１）一括請負契約の合意について
　本件訴訟開始段階から、本件合意書が一括請負と解釈される可能性は低いと思われていた。

　例えば、松島淳也弁護士は「開発対象」が明確にならないと、何が請負人において完成すべき仕事なのかが不明確なのだから、本件合意書が一括請負と解釈されるためには、開発対象の明確性が必要であるとした上で、通常は、画面や帳票などの設計が終わり、システム全体の構成が決まる「基本設計」の終了段階ではじめて開発対象が明確になると解すべきであり、もちろん、本件合意書により「どの程度開発対象が明確になっていたか」によるが、一般論としては「今回のケースで裁判所は、日本ＩＢＭ側の主張を受け入れる可能性が高い」としていた*11。

　システム開発において、ユーザとしては、経営戦略と整合するシステム開発という観点及び予算管理という目的から、稼働時期と予算を早期に確定することを強く求める傾向にある*12。その意味で、ユーザは本件合意書のような納期と費用の合意を結ぶことを強く求める。しかし、システム開発には、システム開発過程において完成すべきシステムの内容が徐々に形成されていくという特徴がある*13。システム開発当初において開発すべき具体的な画面・帳票が明確ではなく、正確な見積もりが極めて困難という特性がある。ベンダとしては、特に当初契約時では、その後の工程の作業が想定通りに収まる前提で大雑把な見積もりを行うことはできても、詳細かつ信頼性のある見積もりを行うことは非常に困難である*14。そこで、ベンダは、各フェーズ毎に締結する個別契約が、法的な意味で納期／報酬額を決定するのであって、本件合意書のような合意をユーザの要望に応じて締結するとしても、それはあくまでも、今後そのような個別契約を締結する意図を両者がその段階で持っていることを確認するという内容であり、その後のシステム開発の進展によって当然に納期も金額も変わってくる可能性があるものであって、法的な義務、特に当該納期までに当該報酬以上の報酬を受け取ることなく請負人として仕事を完成させる義務までは負わないと考えるのが通常である。

　これまでの裁判所も、個別契約を重視する判断をする傾向がみられる。例えば、最終的には和解で終わったものの、ＪＴＢ情報システムのシステム開発頓挫訴訟において、ユーザ側が納期と費用総額が記載された「基本合意書」を根拠に、基本合意書で定めた総額を超える支払い義務はないと主張したものの、裁判所は、「システム開発受託個別契約書」の存在を理由に、個別契約が優先するとした*15。また、ある地方公共団体が行政事務に関する様々なシステム開発を委託したところ、結局税関連システムについて導入が断念されたという事案*16において、ベンダからカスタマイズを最小限に抑えて税関連システムを含む各システムを構築するとの提案書が出され、これに対しユーザが採用通知を出したことは認定されたが、税関連システムの個別契約が存在しないのであって、ベンダは税関連システムを構築する義務を負わないと判断されている。

　その意味で、本件判決は、事例判断ではあるものの、基本合意締結段階においてどの程度開発対象が明確であれば、納期と報酬が固定された一括請負と判断されるかについて判断したものとして、今後の裁判実務へ一定の影響があるものと言えるだろう。

（２）要件定義失敗の責任及びパッケージ選定について
　要件定義工程においては、ユーザ及びベンダそれぞれがシステム開発に協力する義務を負うと解されている。

　東京地方裁判所プラクティス委員会第二小委員会前掲論文２１頁でも「ベンダーは、ＩＴ専門家としてユーザーの要求を正確に聴取分析し、それにふさわしいシステムを構築する責任があるが、他方でソフトウェアの仕様確定にはユーザーの協力が不可欠であり、いわば両者の共同作業であるという性質がある。特にユーザーが金融業、医療機関である等、システム開発の対象業務が専門的分野である場合は、ユーザー側で積極的に情報提供しない限り、適切なシステムの完成は期待できない」と解されている。本件のＸの業務は金融機関であり、特にユーザー側の協力が必要とされる業種と言える。

　また、パッケージソフトの場合には、既製品であることから、その中核的機能を変更することは物理的にはできるのかもしれないが、多数のアドオン開発（追加開発）を必要とすることになり、パッケージを利用することで短納期・低コストで開発するという目的が達成できなくなる。そこで、ユーザの方で自らの業務内容をパッケージソフトの仕様に合わせなければならない場合もある*17。このようなユーザ側の業務変革（ＢＰＲ）は通常ユーザ内部の抵抗が多く、また、商品数削減であれば顧客との交渉も存在するために、顧客側の協力、特に、経営陣がリーダーシップをもってＢＰＲを推進し組織的協力を行うことが必要である。

　反面、適切なパッケージを選定しなければ、結局システム開発失敗のリスクが高まることから、ベンダとしては、フィットアンドギャップ分析を適切に行い、システム開発の目的達成の上で有益なパッケージを提案すべきであって、中核的機能を変更しなければユーザの経営戦略と適合するシステムにならないパッケージ等、不適切なパッケージを提案すべきではない*18。

　本件判決においては、結論としてベンダに対してかなり厳しい判断がされているが、パッケージ選定の問題、パッケージを前提としたシステム開発におけるベンダのパッケージに関する理解の問題、要件定義工程においてベンダが要求を聴取して要件としてまとめる上での責任等、様々な要素を総合して判断されたものと解される。

（３）「謝罪」の問題
　ここで、本件判決が上記のようなベンダに厳しい判断をした１つの理由として、ベンダ側が謝罪をしたこと等が、書面に残っていることが挙げられる。

　「『改変を強要された』、スルガ銀―ＩＢＭ裁判で日本ＩＢＭ副会長」*19に詳細に論じられているが、日本IBMの金田治副会長は、２０１０年３月４日の証人尋問において書面でＹの責任を認めて謝罪をしたり、議事録においてＹが要件定義におけるユーザの義務を果たしているというような、Ｙにとって有利な記載がなされている趣旨は、ＹのメンバがＸから軟禁され、終電時間を過ぎてもプロジェクト拠点の静岡県三島から返してもらえず、厳しい叱責を受けたことから、「我々が頭を下げることでプロジェクトが前進するならいくらでも謝ろう、プロジェクトの成功のために我慢しよう」という考えで、事実と異なる謝罪文を作成し、また、会議議事録を事後的に改変したと証言した。

　大企業であるＹが、このような主張をすることは一見奇異にも見られるが、実は、裁判例でこのような謝罪が問題となり、それが真意に反するとされた事案は結構ある。例えば、東京地判平成８年７月１１日判例時報１５９９号９９頁では、納品したシステムのハードウェアについて不良があり、これをベンダがユーザの要望に応じて交換したものの、ユーザが債務不履行を主張して提訴したという事案において、ベンダが謝罪文を書いたものの、故障がある旨の通知を受けたときは調査をして無償交換等の適切な措置を取っており、ベンダに債務不履行はないと判示されている。また、システム開発の途中で、ベンダはコピーが保存されているという理解の下で、元データを削除したところ、ユーザが削除について抗議をしたためベンダ従業員が謝罪文を作成し、その後ユーザがベンダを訴えたという事案において、ベンダ従業員が徹夜作業の後に、ユーザ役員から一方的に厳しく非難され、土下座させられたことから、いったんユーザ役員らの怒りを沈静化するため、その言い分に従って事実と異なる謝罪文を作成したものであって、真意ではないとされた事案もある*20。その他、東京地判平成１７年１月２１日判例秘書等、ベンダが謝罪文を書いたものの、それがユーザの強要や、信頼関係醸成のためのもので、ベンダに責任がある訳ではないとされた事案は意外と多い。

　なぜこのようなベンダによる謝罪が行われるかといえば、ベンダとしては、システム開発プロジェクトを前に進めたいという気持ちが強いところ、ユーザとの関係が険悪化した場合に、「謝っておく」ことでユーザのキーマン（プロジェクトオーナー、担当役員等）の気持ちを和らげ、ユーザの協力を引き出して、なんとか稼働までこぎつけたいというインセンティブがある。特に請負契約においては、力の弱いベンダはユーザの検収を得るまでは、報酬が得られないという後払い契約を結ばざるを得ないこともあり、そうすると、法的に未完成であっても、出来高請求等をすることは可能な余地があるとしても、ビジネス上は、稼働させなければ、今までの苦労が全く報われないという状況があり、その中で真意に反する謝罪をするということがあり得るだろう。また、稼働すれば、ユーザとして「確かにベンダが予定より大幅な工数を掛けたのは事実であり、それによっていいシステムが稼働している」として、ベンダに対して同情的になり、追加報酬等の交渉も進むという「読み」もある。

　だからこそ、前記の裁判例のように裁判所が、謝罪に引きずられずに真相を解明すれば、謝罪は真意に反するという判がなされることは相当多いといえる。ところが、システム開発紛争についてあまり知識のない裁判官は、要件定義段階の各当事者の責任分担といったかなり専門的かつ複雑な問題について、判断に困ってしまうことが少なくない。その場合、*21専門知識を背景に、両当事者の主張を整理し、実務慣行に照らして両当事者の責任割合がどうかを的確に判断できればよいが、それでも現実には難しい場合も多く、そうすると、ベンダが謝罪しているという点に引きずられる裁判官も少なくない。まるで刑事裁判における「自白調書の信用性」の判断過程において「重大犯罪について自白をすれば極刑の可能性もあるのだから、虚偽自白をするはずがない」という判断がされることがあるのと同様、「システム開発が頓挫し、訴訟になれば、謝罪文を理由に巨額の賠償義務を負う可能性があるのだから、ベンダが簡単に事実と異なる謝罪文を作成するはずがない」等として謝罪を根拠にベンダに対してかなり厳しい和解を迫るという事例もまま見られる。

　本件判決も、どちらかといえば後者に近い事例と言えよう。ビジネスサイドが勝手に謝罪文を出して、後でトラブルになった場合に交渉力が大きく落ちるというのは、法務サイドとしては極めて困ってしまう話である。もちろん、本当にベンダに責任がある場合に、謝って人員を投入して完成にこぎつける等、謝罪をするべき場合もあるが、明らかにユーザとの対立が激しく、謝罪をしてもあくまでも一時的なものに過ぎず、その後プロジェクトが頓挫する可能性が高い場合に、ビジネスサイド限りの判断で謝罪することは、会社に大きな損害を与えることにもなりかねない。ビジネスサイドとしては、「恥ずかしい」と思わずに、法務と早め早めに相談をすることで、このようなリスクを回避することが強く求められるだろう。

４　終わりに
　２００４年に開始したプロジェクトについて、２００８年に訴訟が起こり、約４年後の２０１２年になって第一審の本件判決が下された。今後高裁・最高裁で争い続けた場合、最終的な紛争解決が、プロジェクト開始１０年後ということも現実にあり得る。

　あるＩＴ系裁判を経験せざるを得なくなったビジネスサイドのリーダーの言葉を又聞きした。

　裁判をやる前は、裁判所には勝者と敗者がいる。こう思っていました。でも、訴訟を経験して分かりました。裁判所には『敗者』しかいない。裁判になった時点で両者とも負けなのです。

　Ｘは、本件判決においては、約７４億円の賠償を受けることができるという意味で、「勝者」なのかもしれない。しかし、上訴された後も同様の判断が維持されるかは不明である。
また、本件プロジェクトが成功すれば、２００８年１月には新勘定系システムを利用できていたのに、実際には、訴訟の影響もあってかＸは、別のベンダとの間の新勘定系システムの刷新プロジェクトを２０１０年６月頃に開始しており*22、まさに、次期システム開発に遅れをとったと言わざるを得ないだろう。この間の５年以上は、情報システム部及び法務部の相当多数の人員が裁判のために時間と労力を割かれていたことは間違いない。この時間と労力を次期システム稼働に向けた場合、どうなったのだろうか。２００６年末からの交渉の中で妥結点を見つけ、例えば一次開発は要件を大幅に削減して稼働を開始し、その後二次・三次開発を行うとか*23、２００７年頃に見切りをつけて新システム導入プロジェクトを開始する方が、もしかすると、裁判で勝訴するよりもビジネス的にはベターだったのかもしれない。
本件判決は、個別の争点に関する判断はもちろんであるが、裁判によるシステム開発紛争の解決の限界を鋭くえぐり出すという意味もある重要判決と言えるのではないか。

まとめ
　今日は２０１２年４月１日です。本件判決の本当の「判決理由」はＹが閲覧制限を申し立てているため、本日現在明らかにはなっていないことは、周知のとおりです*24。そこで、判旨は１００％想像で作成したものであり、実際の判決理由とは異なりますので、誤解なきようお願いします。

４／２７追記：日経の「ＩＢＭに74億円の賠償命令、スルガ銀裁判の深層」テクノロジー : 日経電子版によれば、判決では日本IBMのプロジェクトマネジメントに不備があったと認定されたとされ、東京地裁は日本IBMがシステム開発の「契約上の付随義務」に違反したとみなし、民法第709条の「不法行為」に当たると認定したとのことである。判決全文の早期公開が期待される。

５／１８追記：判決文を読み、大幅に評釈を書き直しました。
ＩＢＭ対スルガ銀行事件判決評釈（東京地判平成２４年３月２９日第一法規判例体系） - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常

*1:Ｘに言わせれば、ＹがCorebankによる本件プロジェクトを断念し、他のパッケージに基づく開発を懇願。

*2:後に115億8000万円へと請求を増額

*3:http://itpro.nikkeibp.co.jp/article/COLUMN/20100615/349225/?ST=ittrend

*4:http://itpro.nikkeibp.co.jp/article/NEWS/20120329/388253/

*5:日経コンピュータ２００８年１２月１５日号１８頁

*6:日経コンピュータ２００８年８月１日号１８〜１９頁参照

*7:日経コンピュータ２００８年７月１日号１１８頁、日経コンピュータ２００８年８月１日号１８〜１９頁、http://togetter.com/li/280424参照

*8:最後の「まとめ」をご覧ください。

*9:仮執行宣言月付

*10:http://itpro.nikkeibp.co.jp/article/NEWS/20120329/388253/。なお、訴訟費用の負担割合により、おおむね本件訴訟において両当事者の責任がＸが２０％弱、Ｙが８０％強という裁判所の判断を推測することができる。

*11:日経コンピュータ２００８年７月１日号１１９頁