システムの本番稼働直後に復旧不能な障害が発生して頓挫した事案において、契約解除の範囲等が争われた事例。
事案の概要
Ｘ（Ｚ会）が、Ｙ（日立ソリューションズ）*1に対して基幹システム（本件システム）の開発を委託したが、頓挫したために、既払い金の返還や損害賠償等の合計約27.3億円の支払いを請求したという事案である。
本件システムの開発は、ウォーターフォール型で行うこととされ、ＸＹ間では、基本契約は締結されず、フェーズ等に合わせて38個の契約（判決文では、「本件個別契約１」などと表記される。）が締結されていた。
Ｙは順次、設計、開発、テストを進め、総合試験、受入試験、本番稼働準備まで行われた。
Ｘは、2017年1月11日から本件システムの本番稼働を開始した。同月13日に初回の夜間バッチ処理を実施したところ、夜間に終了せず、異常終了するという障害が発生した（本件障害）。その結果、Ｘは本件システムの利用を停止し、現行システムに切り戻すこととした。その後、本件システムが再稼働することはなかった。
Ｘは、Ｙに対し、不具合があるとして修補を求めたが、Ｙは、テスト工程においてＸがコストを優先させて工数を大幅に削減したり、本番データの提供がなかったうえに、Ｘが本番稼働を強行したからであって、Ｙが責を負うべき不具合はないなどと回答していた。そこでＸは、2017年12月に本件各個別契約をすべて解除し、本訴を提起した。
Ｘの請求は、Ｘの請求原因は、多岐に渡るが、
- ①開発・単体テストに係る請負契約（本件個別契約７）の債務不履行を理由とする本件個別契約７と、これに密接関連する本件各個別契約の解除、又は
- ②本件各個別契約に付随する信義則上の義務（ユーザから適切に情報を収集するなどしてシステムを構築する義務）の債務不履行を理由とする解除
に基づく原状回復請求としての既払い金の返還（約20.2億円）と、システムが使えなかったことによる社内の費用等の損害賠償金（約7.1億円）から構成される。
なお、本件各個別契約には、下記のような責任制限条項が定められていた。
Ｙの責めに帰すべき事由による債務不履行に起因してＸが損害を被った場合，Ｘは，Ｙに対し，当該損害の直接の原因となったサービス商品（Ｙが本件各個別契約に基づいて提供する各業務の総称をいう。）のサービス料金相当額を上限として，当該損害の賠償を請求することができる。
原審（東京地判令4.2.24・平29ワ39366）の結論が、控訴審でも維持されている。高裁の判決は、地裁判決の「改め方式」になっており、以下の裁判所の判断部分は、すべて地裁判決の引用部分である。
控訴審では、Ｘは予備的主張として瑕疵担保責任に関する主張を追加し、改正前民法635条に基づいて契約が解除できるとも主張していたが、
ここで取り上げる争点
（１）本件個別契約７におけるＹの債務の内容及びその違反
Ｘは、夜間バッチ処理は９時間以内に完了するという性能要件について合意していたところ、これを満たさなかったことが債務不履行にあたると主張していたのに対し、Ｙは性能要件について合意はないと主張していた。
（２）Ｘの協力義務違反
Ｙは、Ｙが必要な試験を適切に実施するためのスケジュールや予算を確保すべきであったのに、Ｙの提案した試験に必要な工数を削減したなどと主張していた。
（３）解除できる契約の範囲
Ｘは、最判平8.11.12を挙げて、目的が相互に密接に関連付けられた2個以上の契約について、いずれかが履行されるだけでは契約の目的が全体として達成できない場合には、1つの契約上の債務不履行を理由に、他の契約を解除できると主張し、本件個別契約７の不履行を以って、全体を解除できると主張していた。
（４）責任制限条項の適用の有無
Ｙは、本件個別契約７に債務不履行があるとしても、責任制限条項により、サービス料金相当額である約6.2億円が賠償の上限になると主張していたが、Ｘは、原状回復請求権には適用されないことや、著しい悪質性が認められるから適用されない等と主張していた。
裁判所の判断
争点（１）夜間バッチのパフォーマンスの合意とその違反
裁判所は、契約の目的や、設計書、さらにはバッチジョブ運用スケジュール表などの文書から、夜間9時間以内に正常終了するという合意内容が含まれるとした。
本件個別契約７は，詳細設計，プログラミング，単体試験及び結合試験を行い，本件システム（Ｖ１．２）の開発作業を実施する旨の個別契約であるところ，一般にシステムにおいて定期実行されるバッチ処理が，想定されるデータ処理量の処理を所定時間内に完了する性能を有していなければシステム全体が機能しなくなる可能性がある（略）ため，データ処理量及びその処理が完了するまでの時間というバッチ処理の性能要件に関する定義はシステムが正常に稼働するかどうかに関わる重要な問題であり，システムの開発作業前にそのような性能要件を定義しないことは通常考えにくく（略）
本件個別契約７（略）を締結するに至るまでの間，新業務フローによるＸの業務を実現する本件システムの開発に向けて，バッチ処理の機能及び性能に関する検討を含めた準備が実際に進められていたものであり，当事者間では，教材発送に係るバッチ処理を含め，Ｘの業務を実現するのに必要な機能及び性能を有するシステムを開発することが当然の前提となっていたものと考えられる。（略）
本件システム方式設計書には，個々のバッチの処理時間，要求性能等に関する具体的な記載はないものの，本件システム方式設計書の目的として，「以降の工程で詳細化する上でのインプットとする」旨記載されており（略）そして，本件システムの機能設計の段階から平成２８年１１月２４日頃までの間，ジョブ名及びジョブＩＤなどで特定される個々のバッチの周期（日次，週次等），実行開始時間，実行時間帯の区分，目標処理時間，終了時間，処理内容などが記載されたバッチジョブ運用スケジュール表が作成及び改訂されており（略），同日に交付されたバッチジョブ運用スケジュール表の最終版（甲１９）においては，夜間に定期実行される教材発送に係るバッチ処理を含むバッチの実行開始時間及び終了時間が，いずれも午前０時３０分から午前９時３０分までの９時間の間に割り当てられていたことからすると，夜間バッチ処理において，Ｘの業務で通常想定される教材発送に係るデータ処理量の処理を夜間９時間以内に正常に完了するシステムを完成させることが，本件個別契約７における合意内容になっていたというべきである。
そして、バッチジョブ運用スケジュール表に記載された目標処理時間が45分-60分のジョブが15-20時間かかったり、異常終了したりするなど、夜間バッチ全体で9時間以内に正常に終了する性能を有しておらず、本件個別契約７について債務不履行があったことを認めた。
争点（２）Ｘの協力義務違反
Ｙが主張していた「協力義務違反」の内容としては、①十分な工数を確保した試験ができるような契約を締結しなかったこと、②本番相当データを用意しなかったこと、③Ｘが主体として行う受入試験・運用試験を先送りし、本番稼働を強行したことなどを挙げた。裁判所は次のように述べ、①について否定した。
Ｘは，システム開発について専門的な知見を有していなかったために，上記プロジェクトの実現を当初から専門業者に委ねていたものであり，本件システムの開発作業等にもほとんど関与していなかったのであるから，本件システムの開発作業等の内容を詳細に把握することはできなかったと考えられる。そうすると，Ｙが，Ｘに対し，提案する試験工数を削減した場合のリスクについて具体的な説明をしなければ，ＸにおいてＹが提案する試験内容で契約を締結すべきかどうかを適切に判断することが困難であるから，上記説明がされなかったのであれば，Ｙが当初提案した試験工数を削減した内容で契約を締結したことをもって，Ｘに協力義務違反があったということはできない。
また、本番データを用いてバッチ処理の性能検証を先送りにしたことについて、Ｙからの十分な説明があったとは認められないなどという補足もしている。
その他に、②と③の義務違反についても退けた。
争点（３）解除できる契約の範囲
この点は、法的にも実務的にも関心があるため、少々長いが関係する箇所を引用する。
確かに，ＸとＹとの間で締結された本件各個別契約は，いずれもＸの新たな基幹システム（本件システム）を構築して稼働させることに向けられた１つのプロジェクトのうちの一過程であるという側面を有しており，本件個別契約７の債務不履行があったことによって，Ｘが本件システムを稼働して業務を行うことが困難な状況になっているという意味では（略），上記プロジェクトが全体としてはその目的を達成するに至らなかったということができる。しかし，他方において，Ｘ及びＹは，本件システムを構築して稼働させるまでに必要となる作業を各工程に分けて，一工程を終えると次の工程に進むといった具合に段階的に本件システムの構築に向けた作業を進めるウォーターフォール型と呼ばれる手法を採用し，工程ごとに細分化した形式で本件各個別契約を締結したものである。このような契約形態がとられるのは，一般にコンピュータシステムの構築に向けた作業が進められる過程で当初予定されていなかった種々の問題が一定程度不可避的に発生し得ることなどを見据えて，必要に応じて次の工程の作業内容の見直しや変更も検討しながら作業を進めることを可能にするという当事者双方にとってのリスクマネジメントの機会を確保するという意味合いがあり，本件システムの構築についても，当事者双方が，各工程で行うべき作業の範囲をその都度検討した上で，それぞれ独自の債務の目的・内容を設定して本件各個別契約を締結したものと解される。そして，本件では，本件各個別契約に共通して適用されるような基本契約が締結され，本件システムを構築して稼働させるに至らなかった場合には直接の債務不履行となった個別契約のみならず他の個別契約をも解除することを可能にするような条項が設けられているといった事情もない。
以上の点を踏まえると，本件各個別契約のうち本件個別契約７についてＹに債務不履行があったことを理由に，Ｘがその他の本件各個別契約の全体を解除し，全ての契約の拘束力から解放される結果を認めるのは，本件各個別契約を締結した契約当事者の意識に適合した解釈とはいい難く，それぞれの契約に設定された独自の給付ないし債務の目的に照らし，本件個別契約７のそれと密接関連性が認められ，当該他の個別契約のみの実現を強制することが相当でないといえる場合に限って解除が認められるというべきである。平成８年判決は，一方の契約のみの実現を強制することが契約当事者の意識に適合せず，相当でないと認められる場合に，一方の契約の債務不履行を理由に他方の契約の解除を認めたものと解されることから，上記のような考え方が平成８年判決の趣旨に反するものではない。
ウォーターフォール型で工程ごとに分けて契約しているので、1つの契約を解除したら残り全て解除することは当事者の意識に適合しないとしつつも、一定の条件を満たす他の個別契約については解除ができると述べた（私が知る限り、このような中庸的な平成8年判決の射程を定めた事例は知らない。）。
そのうえで、本件個別契約７以外の37個の個別契約のうち、上流工程の契約や、仕様変更関連、受入試験の支援、データ移行などの契約については、「それぞれの契約において独自に設定された債務の履行が，必ずしも本件システムの開発作業が完成しなくとも完了し，それによって債務の目的は達成されるものであることからすると，本件個別契約７の債務不履行を理由に解除を認めることが相当であるとはいえない」としつつ、以下の個別契約については、「本件システムの開発作業等を目的とした本件個別契約７のそれと密接に重なり合い，本件システムの開発作業の完成に向けて，いわば一体的に進められるべきであった作業に係る契約である」として、解除を認めた。
- 本件個別契約７で開発したシステムの総合試験に関する本件個別契約２２
- 個客支援サブシステムの機能設計，詳細設計，プログラミング，単体試験及び結合試験（本件個別契約１１）
- 個客支援サブシステムの結合試験（本件個別契約１２）
- 本件個別契約７において開発したシステムの改修作業を含んだ本件個別契約１３及び１４
- 現行システムや、フロント系システムと本件システムの連携プログラムの設計・開発に関する本件個別契約２１、２９、３０及び３１
- 一部の仕様変更を含む本件個別契約３２
これにより、これらの契約の解除と既払い金合計約11.1億円の支払義務を認めた。
争点（４）責任制限条項の適否
裁判所は、次のように述べ、責任制限条項は適用されるとしつつ、本件個別契約７以外の解除に伴う原状回復請求には及ばないとした。
かかる責任制限条項を設けた当事者の合理的な意思は，本件個別契約７の債務不履行があった場合，請求の根拠が本件個別契約７の解除に基づく原状回復請求であるか本件個別契約７の債務不履行であるかを問わず，Ｙが負担する債務を本件個別契約７のサービス料金相当額である６億１８５０万円に制限するというものであったと解される。
したがって，本件個別契約７の解除に基づく原状回復請求ないし本件個別契約７の債務不履行に基づく損害賠償請求が認められるとしても，Ｙが負担する債務の上限は，６億１８５０万円に制限されるというべきである。なお，このように解したとしても，本件個別契約１１ないし１４，２１，２２及び２９ないし３２については，本件個別契約７とは別個の契約であるから，本件個別契約７の責任制限条項の効力は，本件個別契約７と併せて解除される本件個別契約１１ないし１４，２１，２２及び２９ないし３２の解除に基づく原状回復請求に及ぶものではない。
若干のコメント
個人的な体験でいえば、バッチウィンドウ*2に収まるようにジョブネットを組んで、思ったよりパフォーマンスが上がらず朝5時くらいにひやひやしたという昔の体験を思い出させる事件です。
バッチ処理時間について、性能要件を合意していないということは考えにくく、そしてまたテストの工数を削って本番相当データでのテストをしないまま本番稼働を迎えたというのもなかなか考えられないことです。
本文中では触れませんでしたが、Ｘは、本番稼働以降の保守をＹではなく、別のベンダに委託するという話をしており、その影響で、本番稼働直後の障害についてＹが最後まで対応せず、紛争に至ったのではないかと思われます。
その点はさておき、本件は、38個という多数の個別契約が独立して存在していたという点に特徴があり、処理がバッチウィンドウに収まらなかったという不具合があったとしても、すべての個別契約に債務不履行があったとは言い難いので、Ｘとしては、他の個別契約の支払済み報酬をいかにして取り戻すかということに頭を悩ませたのではないかと思われます。もちろん、他の契約に基づいて支払った報酬は、問題があった契約（本件個別契約７）の債務不履行によって生じた損害だという主張は可能ですが、明示的な責任制限条項があるため、ここを乗り越える必要があります。
そこで、平成8年最判を持ち出して複数の契約を芋づる式に解除しようと思われますが、裁判所は、一連の契約に関連性があると認めつつも、平成8年最判との事案の違いなども考慮し、「その中の一部について解除を認める」という技巧的な判断をして、中間的な結論を導きました。判決文からだけでは、どこまで解除できるとすべきかはなかなか判断が難しいのですが、少なくとも要件定義や基本設計などの上流工程やデータ移行、運用試験支援などは解除を認めていないものの、一部の試験やインターフェースの部分については解除を認めています。
平成8年最判の事例は同時並行で進む契約であり、意図的に契約を分割したシステム開発の多段階契約においてまで射程を及ぼすことは否定的で、現に東京地判平31.3.20（野村vs日本IBM）でも事案が異なるとのべています。システム開発の事例で、平成8年最判を援用して契約の解除を認めた事例としては、東京地判平28.11.30がありますが、ソフトウェアの開発とハードウェアの購入というもので、比較的平成8年最判と近いといえます。
そういう意味で、過去の事例からすると、本件で平成8年最判を根拠に複数の契約を解除するという結論には疑問があります。しかし、ウォーターフォール型開発では、契約を細かく分ける実務があるものの、さすがにここまで細かく分けて、責任制限条項の壁を設けると、ベンダを過度に保護することになるのではないか、実質的に１つの契約でよいものを細かく分け過ぎではないか、という価値判断があったのかもしれません。
