PaaSを用いた開発が頓挫した事例において、ユーザにも仕様検討の遅れなどの落ち度はありつつも、過失の程度はそれほど大きくないとして、ベンダとの過失割合を９：１とした事例。
事案の概要
詳細は一審判決に関する下記リンク記事のとおりで、日本IBM（ベンダ）が、セールスフォース（SF）のプラットフォームを用いたシステムの開発を受託していたが、UATまで進んだものの、中止に至った。
文化シヤッター（ユーザ）は、ベンダに対し、約27.8億円の損害賠償を求め（本訴）、ベンダはユーザに対し、ユーザにプロジェクトマネジメント義務違反があった等として約12億円の損害賠償を求めた（反訴）。
一審では、ベンダの責任を認め、ユーザの請求の大半を損害として認めつつ、ユーザ側の過失が15%あるとして、85%にあたる約19.8億円を損害として認定した。
ここで取り上げる争点
基本的に原審における認定が維持されているが、控訴審における補足的主張に対する判断部分を取り上げる。
裁判所の判断
判決文の引用部分は、ベンダ（日本IBM）＝一審本訴被告、ユーザ（文化シヤッター）＝一審本訴原告と表記されている。
①本件システムが稼働できなかったのは技術的な問題によるものではないとのベンダの主張に対して
裁判所は、ベンダ内部での調査資料を引用しつつ、
構築中の本件システムは「極めてカスタマイズされており、複雑なインテグレーション、ガバナ制限への抵触、データの問題及びデータ・モデルの安定性の低いデザインに照らして多くのチャレンジが存在する。」との認識の下、本件システム構築継続の断念、本件旧システムとの併用、ビジネス・プロセス・リエンジニアリングから始めてＳＦの標準部品を活用したシステムを完全に再構築すること等が推奨され、本件システムの開発態勢について、貧弱なプロジェクト・マネジメントがスコープ・クリープにつながっていること、経験のあるＳＦのリソースが主要なポジションに欠けていたことがベスト・プラクティスの欠如につながったこと、開発リソースのスキルセットがＳＦの開発業界のスタンダードより低いこと等の問題点が端的に指摘されている
とした上で、
このことに、一審本訴被告が、ＵＡＴフェーズが半ば終了した時点（平成２８年１０月末頃）になって、プロジェクト管理者（略）等を変更した上、プロジェクトの技術的課題解決の促進のためＳＦ社の技術担当者を新たに配置する等、体制を抜本的に見直す方策を採っていること（略）を併せ考えれば、ＵＡＴ時点の本件システムに存在した性能上の課題（技術的な問題）が、多くのプロジェクトで発生している一般的なものであるとか、ＳＦの技術面での課題がシステムの本番稼働を妨げる問題ではなかったなどとは認められない。本件システムは、遅くとも平成２９年１１月２４日に本件個別契約を解除した時点においては、その完成が見込まれないものとなっていたものというべきである
と、ベンダの主張を退けた。
②本件システムが本番稼働できなかったのは、上流工程で求められた仕様を適時適切に確認できなかったユーザにあるとのベンダの主張について
この点は、下記のように述べて、ベンダの主張を一定程度認め、過失相殺としては考慮し得るものの、ベンダの責任を否定できるものではないとした。
もとより、システムの要求仕様を決定できるのは、業務内容を知り、これを決定し得るユーザであるから、システム開発プロジェクトにおいて、仕様書を確認して仕様を判断・決定する役割と責任は基本的にユーザが負っているというべきところ、本件においては、一審本訴原告の側にも、仕様の確定が度々遅れたとか、仕様変更要求を適時適切に一審本訴被告に伝えなかった等の問題があったことが認められ（略）、このことが、一審本訴被告のプロジェクト・マネジメントを一層困難なものにした側面があることは否定できない。しかし、他方において、システム開発、とりわけＳＦに関する専門的知見を有するのは一審本訴被告をおいて他にないのであるから、一審本訴被告は、一審本訴原告の要求する機能をＳＦ上で実現するために必要な条件を技術的観点を踏まえて検討・整理するとともに、当該機能を取り入れることの相当性について助言すべき立場にあったといわなければならない（略）。
しかるに、一審本訴被告は、各フェーズにおいて、本件制約等を踏まえた検討・整理を適時適切に行うことなく、一審本訴原告の要求に応ずるままにカスタム開発の比率を高めていった結果、本件制約等を顕在化させるに至ったのであるから（深刻な事態に至っていることに気づいて抜本的な見直しを図ったのは、ＵＡＴが半ば終了した平成２８年１０月頃になってからであった。）、上記事態に至った主因は、（略）一審本訴被告の不十分なプロジェクト・マネジメント（略）や、ＳＦの経験・スキルの不足（平成２８年１０月頃になってＳＦ社の技術担当者を配置する等しているが、遅きに失したというべきである。）にあったといわざるを得ない（ＳＦには、標準機能の活用により開発費用や開発時間を圧縮するというメリットもあるものの、本件制約等のデメリットもあるのであって、ＳＦの採用を提案して選定されたベンダとしては、デメリットが顕在化しないよう、適切なマネジメントを行う義務があり、一方、ＳＦを選択したユーザとしてもそれに合わせた業務プロセスのリエンジニアリングを行うという覚悟が求められるというべきである。）。
その他のベンダの補足的主張はすべて裁判所に退けられた。
③ユーザの過失を認めて過失相殺を行ったことが不当だとの主張について
裁判所は、②でも触れていたように、ユーザにも一定の非があるから、過失相殺をするのが妥当だとしつつ、下記のように過失の程度はさほど大きくないとして、ベンダの責任割合を原審の85%から90%へと引き上げた。
しかし、一審本訴原告による仕様確定の遅れは二次要件定義フェーズから度々生じており、それによって設計・開発の遅れが発生していたこと、要件定義フェーズ等における画面や帳票等のレイアウト等にこだわりが強い一審本訴原告が、仕様がいったん確定した後もその変更を求める事態がしばしば生じていたこと、かかる度重なる仕様変更要求の結果、スケジュールの縛り（略）もあって一審本訴被告の開発時間が圧縮され、そのプロジェクト・マネジメントを困難にした側面があることは否定できない（略）。そして、こうした背景から数多くの不備が生じることとなり、その対応もあってますます開発時間が不足するといった悪循環（略）に陥っていったと認められるから、（略）本件においては、公平の見地から、一審本訴原告の損害賠償請求につき一定の過失相殺を認めるべきである。他方、一審本訴原告の仕様検討の遅れの原因の一端が、一審本訴被告の不十分なプロジェクト・マネジメントや（略）、一審本訴被告が設計・開発フェーズの過程で「動く画面」によって画面遷移等をコアメンバーらに具体的に示して仕様を確定することが当初の想定よりかなり少なく、仕様の詳細がイメージしづらかったことにあったことは否定できない。このことに、一審本訴被告がシステム開発に関する豊富な知識・経験（一審本訴原告との間には格段の差異があったことが明らかである。）を有するベンダであり、本件で使用するＳＦの特徴や制限等についてもユーザに対し十分な説明をすべき立場にあったこと等の事情にも照らせば、一審本訴原告の過失の程度はさほど大きいものとみることはできない。
これらの事情その他本件に表れた一切の事情を併せ考慮すれば、一審本訴原告の被った損害のうち、一審本訴被告に帰責すべき部分は９０％をもって相当と認める（略）。
ほかに、ベンダに故意・重過失があったとの主張も退けられている。
なお、認定した損害額は、原審と同じ23億3331万2961円で、その90%は20億9998万1664円となるが、設計開発フェーズ以降に支払われた20億0564万9461円を上回るということで、責任限定条項を適用して20億0564万9461円とし、認容額はわずかだけ削られた。
若干のコメント
パッケージソフト等の大型システムの導入が失敗する場合、原因は一律にベンダにあるとは限らず、ユーザの調整不足、仕様決定不足などが原因であることも少なくなく、現にそのような判断をしてユーザの請求を退けた事例は少なくありません（東京高判令3.4.21（野村HDvs日本IBM）、札幌高判平29.8.31（旭川医大vsNTT東）等）。本件では、SFの制約に関する経験・技術力不足、PMの力不足というベンダの問題と、仕様決定の遅れというユーザの問題がどちらもあるとしつつも、その割合は９：１（ベンダの責任が9割）とされました。
カスタマイズが多く、SFの性能が低下したということも、元をたどれば、ユーザの要件が膨らんだからだともいえるので、ベンダの責任を重く見過ぎであるようにも思えます。控訴審判決では、この点について、ベンダが「動く画面」を具体的に示して仕様を確定することが少なく、仕様の詳細がイメージしにくかったことや、「一審本訴被告がシステム開発に関する豊富な知識・経験（一審本訴原告との間には格段の差異があったことが明らかである。）を有するベンダ」であるとの情報の非対称性を根拠に、「一審本訴原告の過失の程度はさほど大きいものとみることはできない」としたことについては、業界への影響は小さくないと思われます。
「ベンダ＝プロ」「ユーザ＝素人」という格差を強調するフレーズは、この種の判決文で頻出しますが、個人的にはそういった判断が続くことによってユーザが力の格差を埋めることへのインセンティブを削ぐのではないかということを危惧しています。つい最近でも、セキュリティインシデントに関する前橋地判令5.2.17では、ベンダが提出した仕様書について、ユーザ（自治体）が要求を満たすものかどうかを判断することは困難だとして、ベンダの責任を認めており、（敢えて言葉を選ばずにいうと）ユーザを甘やかしすぎているのではないかと思える事例もあります。
20世紀末になって、SAPをはじめとするERPが大企業中心に広がって、ベストプラクティスの導入がすすめばプロジェクトは短期・低予算化して、システム開発紛争がなくなるかという説もありましたが、全然そんなことはありませんでした。本件のようにクラウドになっても、大規模紛争に至ります。今後、生成AIを活用して基幹システムの導入を、といった話が必ず出てくると思われますが、果たしてそれで紛争は減るのかどうか、注目していきたいと思います。
なお、本件では、訴訟係属中に、ユーザが文書提出命令の申立てを行うなど、証拠開示についても争われています（東京高決令3.12.14）。
