PaaSを用いた大型のシステム開発紛争において、ベンダの開発手法・方法論の選定や、プロジェクトマネジメント違反等による損害賠償責任が認められた事例。
事案の概要
ユーザ（X＝原告）*1は、販売管理システム（本件システム）の刷新をベンダ（Y＝被告）に委託し、各種の個別契約（本件個別契約）が締結された。本件システムの開発は、いわゆるERPパッケージを使用したものではなく、セールスフォースのプラットフォーム（SF。よく知られているSaaSではなくPaaSの部分）を利用し、標準部品を利用しながら必要な機能をカスタムで開発するという手法が採用された。
XY間で締結されていた本件各個別契約には共通約款があり、次のような内容が含まれていた。
- Yは、情報システムの開発・運用等に関する支援サービスを提供するが、その対象業務は顧客の管理・監督の下にXの責任において完成されるものであり、かつ、契約の性質は仕事の完成を目的とした請負契約ではなく準委任契約であること
- Yの損害賠償責任は、請求の原因を問わずXに現実に発生した通常かつ直接の損害に対する、損害発生の直接原因となった当該サービスの料金相当額を限度とする金銭賠償に限られる
- 法律上の瑕疵担保責任を含めいかなる明示又は黙示の保証もない
一次要件定義フェーズ、二次要件定義フェーズが行われたが、仕様が未決定のものが残ったまま設計・開発フェーズへ持ち込まれた。設計・開発フェーズに入っても、仕様に関する意思決定の遅れや仕様の追加変更はしばしば起きていた。そういった事情もあって、設計・開発フェーズは、いくつかのスプリントに分けて実際に動作する画面を確認しながら仕様を確定させるというアジャイル開発を予定していたが、実際にはウォーターフォール型開発方式で行われていた。
2016年3月に予定どおりSIT（システム結合テスト）が開始されたものの、中断するなどして難航し、最終的には終了しなかった。UAT（ユーザ受入テスト）は、SITと並行する形で同年8月ころから開始されたが、エラーが発生するなどしてこちらも難航した。
本件システムの開発は2017年1月中旬に中断し、Yの要員が撤収した。その後もYは、ニューヨークに渡ってYの米国本社の専門家チームと協議するなどして対策を検討し、Xに対して大幅な方針転換をして改めてSFの標準部品を最大限活用するなどしてスコープも大きく縮小する再提案を行ったが、再開には至らず、2018年7月には個別契約が解除された。
Xは、Yに対し、本件個別契約が、Yの責に帰すべき事由により履行されなかったとして、既払い金や第三者に支払った金銭相当額など、約27.8億円の損害賠償を求めた（本訴）。これに対し、Yは、Xに対し、Xが行うべきユーザ側のプロジェクト・マネジメント義務に違反して、Yの業務（本件業務）を難航させたことは不法行為に当たるとして、約12億円の損害賠償を求めた（反訴）。
ここで取り上げる争点
（１）本件の責任原因
Xは、主に次の点を以て、Yによる業務はYの責に帰すべき事由によって履行不能あるいは不完全履行であると主張していた。
- SFには、Apex制限*2やデータストレージの制限がある上に、多くのカスタマイズによってSFのバージョンアップに多大な制約が生じる*3にもかかわらず、YはUATに至るまでその制約に抵触することの検証を怠ったり、Xへの説明を怠った。
- 現行踏襲とToBeとを兼ね備えたシステムとすべきところ、現行踏襲が至らず、UATにおいて多数の不具合が生じたりするなど、品質面に問題があった。
- 本件各個別契約において、システム開発過程において、適宜得られた情報を集約・分析して、ベンダとして通常求められる専門的知見を用いてシステム構築を進め、ユーザに必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整等を行いつつ、システム完成に向けた作業（プロジェクト・マネジメント）を適切に行うべき義務の履行を怠った。
もちろん、これらのXの主張に対して、Yはいずれも争うとともに、システム開発がとん挫したのは、仕様凍結合意の締結後に追加変更要求を出してシステム開発を妨害したりしないこと等を内容とするユーザ側のプロジェクト・マネジメント義務を怠ったためであったと主張していた。
（２）Xの損害の額
Xは、以下の損害を含む合計約27.8億円を請求した。
- 本件システムの開発に関してYに対して支払った約22億円
- 本件システムの開発に関して第三者に支払った約2.7億円
裁判所の判断
争点（１）責任原因について
裁判所は大要、下記６つの事実を認定したうえで、次のように述べてYの不完全履行を認めた。
- Yは本件各個別契約の締結に先立って、システムの確実な実現と導入時期の達成や業務革新ポイントの実現をうたい、SFの標準部品を活用しつつ、カスタム開発を併用する自由度の高さ等をアピールした。
- カスタム開発の割合が95%に達した結果、4度にわたってApex制限の拡張申請し、SITは進捗率50%の段階で770の欠陥が発見するなど難航し、結果的に完了しなかった。
- SITと並行してUATを実施したものの、少なくとも欠陥であることが争いのないものについて182件あり、Xから対応を優先するよう求めたものの、結局UATも未了のままとなった。
- Yが米国本社らと行った協議では、専門家チームからYの貧弱なプロジェクト・マネジメント、開発リソースのスキルセットがSF開発業界の標準より低いことなどが指摘されていた。
- 2017年に開発が中断したのち、Yはカスタム開発を20%以内に抑え、Xの業務を簡素化してもらうことが可能か打診し、XもYに一定程度協力する姿勢を示していた。
- ところが、2017年5月のYの提案は、カスタム開発をほぼ全廃し、当初のサービスイン予定からは約3年延期と21億円の追加費用を要求するもので、業務革新ポイント18項目のうち15項目は実施できないという内容で、XはYに対する信頼感を喪失した。
このような経緯に照らすと、仮に５・２９提案（やそれに続く８．１０提案）それ自体に技術的な実現可能性が高かったとしても、その費用や期間、開発スコープが被告の当初提案とは余りにかけ離れていることからみて、原告がこの期に及んでこれを受け入れなければならないと解すべき理由はなく、また、被告が開発していた本件システムは、これがＵＡＴに供された平成２８年８月末頃の時点では、仮に欠陥であることの明らかな１８２件全てに対応したとしても稼働する見込みがなかったか、少なくとも年３回予定されているＳＦのバージョンアップの都度看過し得ない障害が生ずるなどして早晩機能を停止することが容易に推認することのできる状態にあったものといわざるを得ないから、本件システムの構築は、遅くとも平成２９年１２月の本件解除の時点において、その完成が見込まれないものになっていたものというべきである。そして、その主たる原因は、ＳＦの標準部品を積極的に活用し、現行業務との差異は運用や、場合によってはその簡素化に踏み込むなどしない限り、本件システムをＳＦ上で合理的な期間及び費用により開発することができる可能性は事実上なかったにもかかわらず、被告がＳＩＴやＵＡＴで障害が多発するまでそのような危険性があることに気付かず、又はその危険性を軽視し、むしろ原告の要求に応ずるままにカスタム開発の比率を高めていったことにより、いたずらに本件システムを肥大化させ、ひいては本件制約等を顕在化させたことにあるものと解される。
したがって、被告は、その開発手法を誤り、かつ、適時適切な修正、調整を通じてシステム完成に向けたプロジェクト・マネジメントを適切に行うべき義務に違反するという本件業務の不完全履行によって上記のような状態を招来したものといわざるを得ず、そうである以上、本件解除までに原告に生じさせた損害を賠償すべき義務があることは明らかである。
これに対し、Xのプロジェクト・マネジメント義務違反については次のように述べた。
原告の側にも、仕様の確定が遅れた（認定事実(1)オ）とか、仕様変更要求を適時に被告に伝えなかった（同(7)ア）等の問題があったことは事実である。しかしながら、ＵＡＴの時点以降に原告が要望した仕様変更を考慮しないとしても本件システムは稼働する合理的な見込みがなかったものと解される上、上記(1)のような本件の経緯からみて、原告による仕様の確定が適時適切に行われていたからといって、それだけで本件システムの肥大化による本件制約等の顕在化を防ぐことができたとは考え難いことなどからすれば、原告側の上記問題を過失相殺の局面で考慮することがあり得るのは格別、原告にプロジェクト・マネジメント義務違反があったとまでいうことはできないものというべきである。
詳細は割愛するが、Yは下記のように様々な反論をしているものの、裁判所はすべて退けている。
- UATの段階ですでに完成していた
- RFPを実現することは可能であったが、Xが本件システムに求めたものはRFPからかけ離れたもので、それを実現するにはカスタム開発を行うことは当然であった
- Xの内部において、RFPで想定されていた機能ではなく、現行踏襲に固執するメンバーいるなどした結果、大量の仕様変更要求がなされた
- 中断後に行われたYによる提案により、二次要件定義フェーズ完了時点での要件で完成させる見込みだった
- Apex制限はあるが、SFに依頼すれば追加の費用なく拡張することができるのだから、物理的な制限は存在しない
- 途中でオラクルのストレージを採用したことで工数が増大したという事実はない
- SFのバージョンアップに伴うリグレッションテスト*4によって稼働ができなくなるといった事態は生じていない
- SITは完了していた
争点（２）Xの損害の額
裁判所はXがYに対して支払った約22億円のうち、次のように述べて約20億円がYによるプロジェクト・マネジメント義務の不完全履行によって被った損害だとした。
- 二次要件定義フェーズの成果物として、非機能要件定義書、システム全体図、インフラ検討書等を作成し、Xと共有しており、これらの成果物が本件個別契約１に基づくYの準委任事務の履行の結果としてそれ自体不完全なものとまではいえない
- しかし、二次要件定義フェーズ終了時点では、手組み（スクラッチ開発）による開発範囲が当初の見込みから相当程度拡張されることが明らかになったなどの事情からすると、設計・開発フェーズ以降にXがYに支払った約20億円（本件個別契約２ないし２６に係る部分の合計）は、その全てがYによるプロジェクト・マネジメント義務の不履行により被ったXの損害というべきである
他方で、第三者ベンダ等に支払った金銭については、サービス料金相当額が責任の限度であるとする条項との関係で、先に過失相殺の範囲を検討することとなった（これらをすべて認めると、契約で定めるサービス料金相当額を超過するためであると考えられる。）。
過失相殺の割合は、以下のような事情を述べたうえで、Yが負うべき割合は85%だとした。
- いったん確定した仕様の変更を求める事態がしばしば生じており、プロジェクト・マネジメントを困難にした
- Yは仕様凍結合意をした後も、しばしば仕様の追加・変更を行ったと主張するが、そのような書面の合意はなく、議事録の記載も「今後は開発範囲の変更が発生しないようにしたい」と述べてXがうなずいたという程度に過ぎない
- Yが仕様変更だと主張しているもののうち、いくつかは欠陥であると認められ、Xが行ったとされる仕様変更要求は、それほど広範なものであったとまでは認められない
- 仕様変更要求が増えた一因は、設計・開発フェーズで「動く画面」を示して仕様を確定することが少なく、コアメンバーにおいて仕様の詳細がイメージしづらかったこともある
これらの事情を考慮すれば、原告の損害賠償請求にはなお一定の過失相殺を認めるべきであるものの、その程度はそう大きいとはいえないというべきであり、上記のような諸点を勘案すると、公平の見地から、原告の被った損害のうち、被告に帰責すべき部分は、その８５％の範囲にとどまるものと解するのが相当である。
そこで、第三者ベンダに支払った金銭等も含めた約23.3億円に85%を乗じた約19.8億円を損害賠償請求として請求しうるとし、これは個別契約の金額の総額を下回るから責任限定規定を適用する必要がないとした。
なお、Yからの反訴請求のうち、Xに責任があることを前提とする不法行為請求が認められなかったことはもちろんのこと、追加報酬支払の合意や商法512条に基づく請求についても、いずれも退けられ、反訴請求はすべて棄却された。
若干のコメント
本件は、スルガ銀行vs日本IBM（東京高判平25.9.26）、トクヤマvsTIS（東京地判平28.4.28）、旭川医大vsNTT東日本（札幌高判平29.8.31）、日東電工vsフューチャー（東京高判平30.3.28）、野村HDvs日本IBM（東京高判令3.4.21）らと並ぶ大型のシステム開発訴訟事件です。
最近の大型の基幹系業務システムの場合、ERPパッケージを用いることが多いのですが、本件では、セールスフォースのPaaSを使って、事実上、スクラッチ開発に近い形態で進められたと思われますが、PaaSならではの制約（コード量の制限や、強制的なバージョンアップへの対応*5等）が顕在化した事案であるともいえるでしょう。
もっとも、法的には、多段階契約のもとで進められた開発が頓挫した場合におけるプロジェクト・マネジメント責任の所在が問題となったという意味では、上記で挙げたような大型事案と争点としては類似します。
現行踏襲＋ToBeの実現という、いかにも難しそうな開発案件を、PaaSのプラットフォームにて実現しようとしたところ、さまざまな制約が足枷となって遅延が生じ、UATの段階で品質も十分でなく、開発の進め方を抜本的に変更せざるを得なかったという事実認定を見る限り、ベンダの責任割合が大きくなってしまうのもやむを得ない事案であったと思われます。
しかし、この種の事案は前述の旭川医大事件や野村HD事件のように、ちょっとした事実認定の差で結果が大きく変わってしまうことがありますので、控訴審でもこの結果が維持されるかどうかはわかりません*6。
ここで改めて強調しておきたいのは、XY間の契約はすべて準委任契約で、個別契約も判決文からわかる範囲では少なくとも26個に分けて締結され、順次報酬が支払われていたにもかかわらず、ほとんどすべての支払済報酬相当額が損害であると認定された事実です。「準委任であれば履行が終われば（期間が過ぎれば）安心」というベンダ側の論理は裁判所では通用しないという事例がここでもう一つ積み重ねられたといえるでしょう。
判断枠組みとしては、前述のスルガ銀行vs日本IBM事件に近く、頓挫の原因となったポイントを認定し（本件では二次要件定義フェーズ終了時）、それ以降に支払われたものは契約の種類（準委任契約、請負）を問わず、すべて損害だとしています。
蛇足ですが、過失割合を８５：１５にしたというのが特徴的でした。経験上、８：２、７：３など、母数が10以外のケースはあまり見たことがなく、ここも額が大きいだけに、９：１や８：２ではしっくりこないという裁判所の微妙な匙加減が感じられます。
なお、蛇足その２ですが、本件では、事実認定に際して、Yが米国本社とともに対策を協議した際の内部資料が証拠として用いられていました。こうした証拠について、裁判所は、
なお、上記各乙（内）号証は、乙（内）２９－０３－１０の２を除き、全て被告に対する文書提出命令（略）が抗告審で確定したことに基づいて初めて被告から提出されたものであり、かつ、被告が当裁判所による民訴法２２３条６項に基づく提示命令に応じなかったことは、いずれも当裁判所に顕著な事実である。
と判示しています。内部資料の提出について、Yがかなり強く抵抗したことが窺えます。このことがどこまで心証に影響したのかはわかりませんが、一般にはこの種のことが判決文で言及されることは多くありません。また、大規模な事案であるため、証拠番号を単純に乙第〇号証といったナンバリングをするのではなく、種類別（基、内、共など）をつけて、連番ではなく日付を付けていることなど、審理に工夫がなされているという印象を受けます。
本件は、日経BPでも提訴時、判決時など、何度か取り上げています。
*1:原告は、「文化シヤッター株式会社」ですが、私はこのブログを書くまで「シヤッター」だとは知りませんでした。キヤノンらと同じですね。
*2:SF上で開発する言語（Apex）のコードの文字数には制限があり、この制限のことをApex制限と呼んでいた。
*3:SFは年3回程度のバージョンアップを行っている。基本的にはユーザが開発したApexコードは動作するとされているものの、多数のカスタマイズを行う際には動作しないこともあり、その検証が必要となっていた。
*4:以前は動作していたソフトウェアを、環境の変化等が生じた後も同様に動作するかどうかを確認するテスト。
*5:オンプレミス型のERPパッケージの場合もバージョンアップ問題は発生しますが、ユーザがバージョンアップする／しないの判断ができるので、PaaSほど深刻な問題は発生しにくいと考えられます。
