アホヲタ元法学部生の日常

アニメを見て法律を思い、法律を見てアニメを思う法アニクラスタ、ronnorのブログ。頻繁にツイッター(@ahowota)に出没しております。メールはronnor1あっとgmail.comへ。BLJにて「企業法務系ブロガー」として書評連載中。 #新人法務パーソンへ #オタク流勉強法 #明認方法 「アホヲタ元法学部生の日常」(ブログ)、「これからの契約の話をしよう」(同人誌)、『アニメキャラが行列を作る法律相談所』(総合科学出版)等。

判例評釈速報:IBM/スルガ銀行システム開発事件〜東京地判平成24年3月29日判例集未登載(控訴)

ソフトウェア開発モデル契約の解説

ソフトウェア開発モデル契約の解説

 
1 事案の概要及び主な争点
 本件は、地方銀行であるXが、システムベンダであるYとの間で新経営システムと呼ばれる勘定系システム再構築プロジェクト(以下、「本件プロジェクト」という。)に関する契約を締結し、再構築を委託したところ、本件プロジェクトが頓挫したことから、XがYに対し損害賠償を請求する訴訟を提起し、YがXに対して反訴を行ったというものである(以下、「本件訴訟」という。)。
 
 
 主な時系列は以下の通りである。
・2004年9月    プロジェクト開始(2008年1月稼働予定)
・2005年9月   「最終合意書」作成(以下、「本件合意書」という。)
・2006年12月頃 両当事者間でスケジュール及び追加費用について交渉
・2007年4月   YがXに対し他のパッケージソフト採用の検討を勧誘*1
・2007年5月   XはYに対しプロジェクトを白紙に戻すことを通知
・2008年3月   Xが提訴(111億700万円請求*2
・2008年4月   第1回口頭弁論
・その後       弁論準備による非公開の手続が2010年まで継続
・2008年8月   Yが反訴(13億7400万円請求)
・2010年前半   証人尋問
・その後       再度弁論準備による非公開の手続
・2011年7月   証人尋問
・2011年10月  結審
・2012年3月   判決(以下、「本件判決」という。)

 
 本件訴訟では、以下の3点が主な争点となった。
(1)本件合意書がシステム完成に至るまでの一括請負契約を意味するか
 プロジェクト開始段階では、新システムを95億円で開発するという基本合意書が交わされ、また、要件定義工程の個別契約が締結されて要件定義が開始された。そして、要件定義継続中の2005年9月に締結された本件合意書においては、「新システムを89億7080万円で開発し、 2008年1月に稼働させる」と記載されていた*3
 Xは、本件合意書により、システム完成に至るまでの一括請負契約が成立しているところ、Yは結局システムを完成することができなかったのだから、Xとして報酬を支払う理由はないので、既に支払った報酬である約60億円*4は返還されるべきであると主張した。
 これに対し、Yは、あくまでも今後次フェーズ以降の個別契約を結ぶことが前提となっており、両者は、そのような費用と納期となるような形で個別契約を今後結ぶことを想定していることを確認したのが本件合意書に過ぎず、本件合意書により最終納期や報酬額が確定したものではなく、また、Yは要件定義工程における個別契約を履行したのだから既払い報酬は返還する必要はなく、むしろ、個別契約の範囲外の追加作業を大量に行っており、Xとして追加報酬金を支払うべきであると主張した*5
 
 
(2)要件定義失敗の責任はユーザ側にあるかベンダ側にあるか
 Xは、要件定義を3回繰り返してスケジュールを遅延させた後、2006年11月頃からY側が大幅な機能削減と稼働延期を要求しており、Y側のプロジェクトマネジメント失敗が要件定義失敗の原因であると主張し、このようなY側の責任による本件プロジェクト失敗により、Yは債務不履行責任を負うから、上記の既払い報酬に加え、本件プロジェクトが成功した場合に得られたはずの逸失利益を含む計115億8000万円が支払われるべきであると主張した。
 Yは、要件定義が終わらなかった理由はXの責任だと主張する。Xの現行業務が、内容の微妙に異なる類似商品を多数販売するといった非効率的なものであったところ、Xの責任でBPR(Business Process Reengineering)を実施して業務をスリム化し、これを前提とした新システムを構築することが合意されていたところ、Xが業務のスリム化をすることができず、新システムの要件を予定通りに提示しない等、要件定義に非協力的であった。その結果3回の要件定義が必要になった他、開発範囲が当初の予定よりもはるかに多くなり、スケジュール遅延及び開発費用の増大が発生した。この点は、2005年11月頃から、Xに対して業務改革に主体的に取り組むことを強く要望していたが、それが実現せず、2006年11月頃からY側として、スケジュールを延期すると共に、開発範囲増大に伴う開発費用の増加を説明し、次期工程の個別契約を、開発範囲増大に応じた適正価格で行うよう依頼したものの、Xがそれを不合理に拒み、本件プロジェクトが頓挫したと主張した。
 Xは、これに対し、Xとしては、後述のとおり、本件プロジェクトがCorebankと呼ばれるパッケージを前提としたものであるところ、Xとしてはパッケージのアドオン(追加開発)をできるだけ避けるため、業務のスリム化を最大限図り、残高のない商品の終了、残高のある商品の販売停止及び別商品との切り替え依頼等、要件定義に最大限協力したのであって、Xには何ら要件定義失敗の責任はないと主張した*6
 
 
(3)YによるCorebank採用断念によりシステム構築が不可能になったのか
 Xは、本件プロジェクトが、Corebankと呼ばれる米フィデリティ・インフォメーション・サービス(以下「FIS」という。)の勘定系パッケージソフトを元にした開発を行うことが合意されていたところ、YにはCorebankの知識が不十分であったために、Yが納期及び費用について過少見積りをし、更にYによる要件定義の内容がCorebankと整合しないことや、YとFISとの役割分担・権利関係の調整に失敗した結果、YとしてCorebankに基づくシステム開発ができないことが判明し、2007年4月頃、Corebankから採用するパッケージソフトを変更したいと懇願した。しかし、これは本件プロジェクトの前提を破壊するものであり、まさにYの責任によるCorebank採用断念によりシステム構築が不可能になったものであると主張した。
 これに対し、Yは、Corebankの採用は断念しておらず、Corebankを前提とした開発は十分可能であったところ、XによるBPR失敗のため、要件が膨れ上がったことから、2006年12月からの交渉を行い、その中で、Corebankを前提に納期と費用を大幅にオーバーしたシステムを構築するか、Corebankを前提に要件を削減したシステムを構築するか、それとも、他のパッケージを前提としたシステムを構築するかといった様々なオプションを提示し、Xと折り合いのつくビジネス的解決を模索したものであり、2007年4月頃のレターも、そのような趣旨として理解されるべきであるところ、結局2007年5月にXはシステム開発中止の通知を行い、Xが一方的にプロジェクトを中止したと主張した*7
 
2 判旨*8
 本件判決は、上記各争点について以下のように判示し、Xの請求額につき74億1366万6128円分を認容*9してそれ以外を棄却し、更にYの請求全額を棄却した。訴訟費用はXが1、Yが5の割合で負担することとした*10
 
 
(1)本件合意書がシステム完成に至るまでの一括請負契約を意味するか
 本件合意書の内容及び本件合意書が、既に2004年9月の要件定義開始後1年を経た2005年9月に締結されたといた経緯から、本件合意書はシステム完成に至るまでの一括請負契約を意味するものであり、YはXに対し、(Xの適切な協力を前提に)新システムを89億7080万円で開発し、 2008年1月に稼働させる義務を負う。

 
(2)要件定義失敗の責任はユーザ側にあるかベンダ側にあるか
X側に落ち度がない訳ではないが、要件定義の失敗の責任は主としてY側のCorebankパッケージについての理解の不足や、プロジェクト管理義務の懈怠によるものである。
 
 
(3)YによるCorebank採用断念によりシステム構築が不可能になったのか
 YがCorebankの採用を完全に断念したのかは兎も角、上記のように要件定義失敗の責任はY側にあり、その結果、納期と予算の大幅な超過が発生しており、いずれにせよシステム構築は、Yの責任で不可能になったものと言わざるを得ない。
 
 
3 コメント
(1)一括請負契約の合意について

 本件訴訟開始段階から、本件合意書が一括請負と解釈される可能性は低いと思われていた。
 
 
 例えば、松島淳也弁護士は「開発対象」が明確にならないと、何が請負人において完成すべき仕事なのかが不明確なのだから、本件合意書が一括請負と解釈されるためには、開発対象の明確性が必要であるとした上で、通常は、画面や帳票などの設計が終わり、システム全体の構成が決まる「基本設計」の終了段階ではじめて開発対象が明確になると解すべきであり、もちろん、本件合意書により「どの程度開発対象が明確になっていたか」によるが、一般論としては「今回のケースで裁判所は、日本IBM側の主張を受け入れる可能性が高い」としていた*11
 
 
 システム開発において、ユーザとしては、経営戦略と整合するシステム開発という観点及び予算管理という目的から、稼働時期と予算を早期に確定することを強く求める傾向にある*12。その意味で、ユーザは本件合意書のような納期と費用の合意を結ぶことを強く求める。しかし、システム開発には、システム開発過程において完成すべきシステムの内容が徐々に形成されていくという特徴がある*13システム開発当初において開発すべき具体的な画面・帳票が明確ではなく、正確な見積もりが極めて困難という特性がある。ベンダとしては、特に当初契約時では、その後の工程の作業が想定通りに収まる前提で大雑把な見積もりを行うことはできても、詳細かつ信頼性のある見積もりを行うことは非常に困難である*14。そこで、ベンダは、各フェーズ毎に締結する個別契約が、法的な意味で納期/報酬額を決定するのであって、本件合意書のような合意をユーザの要望に応じて締結するとしても、それはあくまでも、今後そのような個別契約を締結する意図を両者がその段階で持っていることを確認するという内容であり、その後のシステム開発の進展によって当然に納期も金額も変わってくる可能性があるものであって、法的な義務、特に当該納期までに当該報酬以上の報酬を受け取ることなく請負人として仕事を完成させる義務までは負わないと考えるのが通常である。
 
 
 これまでの裁判所も、個別契約を重視する判断をする傾向がみられる。例えば、最終的には和解で終わったものの、JTB情報システムのシステム開発頓挫訴訟において、ユーザ側が納期と費用総額が記載された「基本合意書」を根拠に、基本合意書で定めた総額を超える支払い義務はないと主張したものの、裁判所は、「システム開発受託個別契約書」の存在を理由に、個別契約が優先するとした*15。また、ある地方公共団体が行政事務に関する様々なシステム開発を委託したところ、結局税関連システムについて導入が断念されたという事案*16において、ベンダからカスタマイズを最小限に抑えて税関連システムを含む各システムを構築するとの提案書が出され、これに対しユーザが採用通知を出したことは認定されたが、税関連システムの個別契約が存在しないのであって、ベンダは税関連システムを構築する義務を負わないと判断されている。
 
 
 その意味で、本件判決は、事例判断ではあるものの、基本合意締結段階においてどの程度開発対象が明確であれば、納期と報酬が固定された一括請負と判断されるかについて判断したものとして、今後の裁判実務へ一定の影響があるものと言えるだろう。
 
 
 
(2)要件定義失敗の責任及びパッケージ選定について
 要件定義工程においては、ユーザ及びベンダそれぞれがシステム開発に協力する義務を負うと解されている。
 
 
 東京地方裁判所ラクティス委員会第二小委員会前掲論文21頁でも「ベンダーは、IT専門家としてユーザーの要求を正確に聴取分析し、それにふさわしいシステムを構築する責任があるが、他方でソフトウェアの仕様確定にはユーザーの協力が不可欠であり、いわば両者の共同作業であるという性質がある。特にユーザーが金融業、医療機関である等、システム開発の対象業務が専門的分野である場合は、ユーザー側で積極的に情報提供しない限り、適切なシステムの完成は期待できない」と解されている。本件のXの業務は金融機関であり、特にユーザー側の協力が必要とされる業種と言える。
 
 
 また、パッケージソフトの場合には、既製品であることから、その中核的機能を変更することは物理的にはできるのかもしれないが、多数のアドオン開発(追加開発)を必要とすることになり、パッケージを利用することで短納期・低コストで開発するという目的が達成できなくなる。そこで、ユーザの方で自らの業務内容をパッケージソフトの仕様に合わせなければならない場合もある*17。このようなユーザ側の業務変革(BPR)は通常ユーザ内部の抵抗が多く、また、商品数削減であれば顧客との交渉も存在するために、顧客側の協力、特に、経営陣がリーダーシップをもってBPRを推進し組織的協力を行うことが必要である。
 
 
 反面、適切なパッケージを選定しなければ、結局システム開発失敗のリスクが高まることから、ベンダとしては、フィットアンドギャップ分析を適切に行い、システム開発の目的達成の上で有益なパッケージを提案すべきであって、中核的機能を変更しなければユーザの経営戦略と適合するシステムにならないパッケージ等、不適切なパッケージを提案すべきではない*18
 
 
 本件判決においては、結論としてベンダに対してかなり厳しい判断がされているが、パッケージ選定の問題、パッケージを前提としたシステム開発におけるベンダのパッケージに関する理解の問題、要件定義工程においてベンダが要求を聴取して要件としてまとめる上での責任等、様々な要素を総合して判断されたものと解される。
 
 
(3)「謝罪」の問題
 ここで、本件判決が上記のようなベンダに厳しい判断をした1つの理由として、ベンダ側が謝罪をしたこと等が、書面に残っていることが挙げられる。
 
 
 「『改変を強要された』、スルガ銀―IBM裁判で日本IBM副会長」*19に詳細に論じられているが、日本IBMの金田治副会長は、2010年3月4日の証人尋問において書面でYの責任を認めて謝罪をしたり、議事録においてYが要件定義におけるユーザの義務を果たしているというような、Yにとって有利な記載がなされている趣旨は、YのメンバがXから軟禁され、終電時間を過ぎてもプロジェクト拠点の静岡県三島から返してもらえず、厳しい叱責を受けたことから、「我々が頭を下げることでプロジェクトが前進するならいくらでも謝ろう、プロジェクトの成功のために我慢しよう」という考えで、事実と異なる謝罪文を作成し、また、会議議事録を事後的に改変したと証言した。
 
 
 大企業であるYが、このような主張をすることは一見奇異にも見られるが、実は、裁判例でこのような謝罪が問題となり、それが真意に反するとされた事案は結構ある。例えば、東京地判平成8年7月11日判例時報1599号99頁では、納品したシステムのハードウェアについて不良があり、これをベンダがユーザの要望に応じて交換したものの、ユーザが債務不履行を主張して提訴したという事案において、ベンダが謝罪文を書いたものの、故障がある旨の通知を受けたときは調査をして無償交換等の適切な措置を取っており、ベンダに債務不履行はないと判示されている。また、システム開発の途中で、ベンダはコピーが保存されているという理解の下で、元データを削除したところ、ユーザが削除について抗議をしたためベンダ従業員が謝罪文を作成し、その後ユーザがベンダを訴えたという事案において、ベンダ従業員が徹夜作業の後に、ユーザ役員から一方的に厳しく非難され、土下座させられたことから、いったんユーザ役員らの怒りを沈静化するため、その言い分に従って事実と異なる謝罪文を作成したものであって、真意ではないとされた事案もある*20。その他、東京地判平成17年1月21日判例秘書等、ベンダが謝罪文を書いたものの、それがユーザの強要や、信頼関係醸成のためのもので、ベンダに責任がある訳ではないとされた事案は意外と多い。
 

 なぜこのようなベンダによる謝罪が行われるかといえば、ベンダとしては、システム開発プロジェクトを前に進めたいという気持ちが強いところ、ユーザとの関係が険悪化した場合に、「謝っておく」ことでユーザのキーマン(プロジェクトオーナー、担当役員等)の気持ちを和らげ、ユーザの協力を引き出して、なんとか稼働までこぎつけたいというインセンティブがある。特に請負契約においては、力の弱いベンダはユーザの検収を得るまでは、報酬が得られないという後払い契約を結ばざるを得ないこともあり、そうすると、法的に未完成であっても、出来高請求等をすることは可能な余地があるとしても、ビジネス上は、稼働させなければ、今までの苦労が全く報われないという状況があり、その中で真意に反する謝罪をするということがあり得るだろう。また、稼働すれば、ユーザとして「確かにベンダが予定より大幅な工数を掛けたのは事実であり、それによっていいシステムが稼働している」として、ベンダに対して同情的になり、追加報酬等の交渉も進むという「読み」もある。
 
 
 だからこそ、前記の裁判例のように裁判所が、謝罪に引きずられずに真相を解明すれば、謝罪は真意に反するという判がなされることは相当多いといえる。ところが、システム開発紛争についてあまり知識のない裁判官は、要件定義段階の各当事者の責任分担といったかなり専門的かつ複雑な問題について、判断に困ってしまうことが少なくない。その場合、*21専門知識を背景に、両当事者の主張を整理し、実務慣行に照らして両当事者の責任割合がどうかを的確に判断できればよいが、それでも現実には難しい場合も多く、そうすると、ベンダが謝罪しているという点に引きずられる裁判官も少なくない。まるで刑事裁判における「自白調書の信用性」の判断過程において「重大犯罪について自白をすれば極刑の可能性もあるのだから、虚偽自白をするはずがない」という判断がされることがあるのと同様、システム開発が頓挫し、訴訟になれば、謝罪文を理由に巨額の賠償義務を負う可能性があるのだから、ベンダが簡単に事実と異なる謝罪文を作成するはずがない」等として謝罪を根拠にベンダに対してかなり厳しい和解を迫るという事例もまま見られる。
 
 
 本件判決も、どちらかといえば後者に近い事例と言えよう。ビジネスサイドが勝手に謝罪文を出して、後でトラブルになった場合に交渉力が大きく落ちるというのは、法務サイドとしては極めて困ってしまう話である。もちろん、本当にベンダに責任がある場合に、謝って人員を投入して完成にこぎつける等、謝罪をするべき場合もあるが、明らかにユーザとの対立が激しく、謝罪をしてもあくまでも一時的なものに過ぎず、その後プロジェクトが頓挫する可能性が高い場合に、ビジネスサイド限りの判断で謝罪することは、会社に大きな損害を与えることにもなりかねない。ビジネスサイドとしては、「恥ずかしい」と思わずに、法務と早め早めに相談をすることで、このようなリスクを回避することが強く求められるだろう。
 
 
4 終わりに
 2004年に開始したプロジェクトについて、2008年に訴訟が起こり、約4年後の2012年になって第一審の本件判決が下された。今後高裁・最高裁で争い続けた場合、最終的な紛争解決が、プロジェクト開始10年後ということも現実にあり得る。



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

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


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

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


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


5/18追記:判決文を読み、大幅に評釈を書き直しました。
IBM対スルガ銀行事件判決評釈(東京地判平成24年3月29日第一法規判例体系) - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常

*1:Xに言わせれば、Yが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:日経コンピュータ2008年12月15日号18頁

*6:日経コンピュータ2008年8月1日号18〜19頁参照

*7:日経コンピュータ2008年7月1日号118頁、日経コンピュータ2008年8月1日号18〜19頁、http://togetter.com/li/280424参照

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

*9:仮執行宣言月付

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

*11:日経コンピュータ2008年7月1日号119頁

*12:西本強「ユーザを成功に導くシステム開発契約」参照

*13:東京地方裁判所ラクティス委員会第二小委員会「ソフトウェア開発関係訴訟の手引」判例タイムズ1349号14頁

*14:独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター編「経営者が参画する要求品質の確保」2版38頁参照

*15:株式会社JTB情報システム野々垣典男「裁判を経験したから分かるシステム開発契約の『やってはいけない』」Business Law Journal45号50頁

*16:名古屋地判平成16年1月28日判例タイムズ1194号198頁

*17:東京地方裁判所ラクティス委員会第二小委員会前掲論文23頁

*18:東京地方裁判所ラクティス委員会第二小委員会前掲論文23頁でも「ベンダーがユーザー業務とパッケージソフトの適合性について十分に調査せず、部分的な仕様変更で足りると安易な見込みを立て」ることがベンダ側の責任によるパッケージソフト開発の失敗の原因の1つとして例示されている。

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

*20:東京地判平成16年4月26日判例秘書

*21:専門委員の助力を得たり鑑定をする等

*22:http://bizboard.nikkeibp.co.jp/kijiken/summary/20100630/NC0759H_1785225a.html

*23:住信SBIネット銀行のように、「スモールスタート」であれば、同一基盤の上でシステムを稼働することは可能であったようだhttp://itpro.nikkeibp.co.jp/article/COLUMN/20080919/315126/

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