第120号　電子カルテシステム開発失敗でユーザー顧客に約１４億円の支払を命じる判決　

～「お客様は神様」とは限らない（札幌高裁平成29年8月31日判決　旭川医大病院ｖｓＮＴＴ東日本事件）※1～

１　はじめに

 大学病院の電子カルテシステムをカスタマイズするシステム開発が遅れ、ユーザーである旭川医大とベンダーであるＮＴＴ東日本との間で、相互に相手を訴えあう巨額訴訟に発展した。４年前にこのコラムでスルガ銀行vs日本ＩＢＭ事件を解説したことがあった（勘定系システム開発失敗で約４２億円の支払を命じる判決～システム開発トラブルで起きる諸問題（スルガ銀行vs日本ＩＢＭ事件、https://www.westlawjapan.com/column-law/2013/131030/））。その同種事案ともいえる控訴審判決が出たので、今回はこれを取り上げる。
 一審判決※4に対して、両当事者とも控訴していたが、今回の控訴審判決は、双方に賠償を命じた一審判決を変更し、旭川医大のみに約１４億１５００万円の支払を命じた。一審判決は穏当な痛み分けの判決だったが、控訴審判決は、まるでベンダー側の準備書面を読んでいるような筆致で、厳しくユーザーを批判する内容となっている。
 今回の判決を一般的なベンダーとユーザーのトラブルとして読みやすくする便宜から、本稿での「一審原告」（旭川医大）は「ユーザー」と、「一審被告」（ＮＴＴ東日本）は「ベンダー」とそれぞれ置き換えて表現、引用するものとする。

２　システム開発をめぐる紛争事例

 もとより、システム開発をめぐる紛争事件は、どの企業においても他人事ではない。この種の訴訟に関する裁判例も多数報告されている。
 （１）このうち、スルガ銀行vs日本ＩＢＭ事件のように、双方に一定の責任を認めて解決が図られている事例がいくつかある。
例えば、
 （事例Ａ）いずれか一方の当事者のみの責めに帰すべき事由によるものというのは適切ではなく、システム開発の失敗は双方の不完全な履行、法改正その他に関する開発内容の追加、変更等が相まって生じた結果である等として、当事者双方の債務不履行責任がいずれも否定されたが、民法６４１条に基づく請負契約の解除が認められ、同条に基づく損害賠償について同法４１８条を類推適用して、６割の過失相殺をした事例（東京地判平成１６年３月１０日確定、判例タイムズ１２１１号１２９頁・Westlaw Japan文献番号2004WLJPCA03100004）、
 （事例Ｂ）次期情報システムのソフトウェア開発個別契約上に導入支援契約を解除することはできないが、上記システムに多数の不具合・障害という瑕疵を生じさせたのはベンダーであるとして、過失相殺の法理により４割の減額をした上でユーザーの損害賠償請求を一部認容した事例（東京高判平成２６年１月１５日）（なお、一審では、過失相殺の法理に基づく大幅な減額（８割）が認められていた。東京地判平成２５年５月２８日、判例タイムズ１４１６号２３４頁・Westlaw Japan文献番号2013WLJPCA05288007）、
 （事例Ｃ）統合基幹業務システム導入の失敗の原因としてユーザー企業側の義務違反を認定したが、ベンダーの付随義務違反によってプロジェクトが中止された場合において、基本的に注文者の内部要因に基づいてプロジェクトの方針転換が行われ、仮にプロジェクトを中止しなければ完成したであろう本件システム開発を注文者自らの判断で中止するに至ったといえる事情の下では、ベンダーの付随義務違反と相当因果関係のある損害は賠償額の３割相当にとどまるものとされた事例（トクヤマ・ＴＩＳ事件、東京地判平成２８年４月２８日、判例時報２３１３号２９頁・Westlaw Japan文献番号2016WLJPCA04286001）等がある。
 今回の事件の一審判決も、概ねこの部類に属するものであった。
 （２）しかし、ベンダー側の責任を重く認め、結論として、主たる責任をベンダーに負わせた事例もある。
例えば、
 （事例Ｄ）企業におけるコンピューターシステムに関するコンサルティング契約及びシステム開発契約について、ユーザーの主張する請負人の債務不履行による契約の解除を認め、ベンダーからの未払代金の請求は棄却し、ベンダーへの既払代金についての原状回復請求を認容した事例（東京地判平成２２年９月２１日、判例タイムズ１３４９号１３６頁・Westlaw Japan文献番号2010WLJPCA09218009）、
 （事例Ｅ）ベンダーは、最終合意締結時にシステムを完成させるには、開発費用、開発スコープ及び開発期間のいずれかまたはその全部を抜本的に見直す必要があり、見直しがなければ、システム開発を進められないこと、その結果、従来の投入費用、今後の費用が無駄になることがあることをユーザーに具体的に説明し、中止も含めたユーザーの適切な判断を促す義務があったにもかかわらず、締結された最終合意は、開発スコープに関する構想を抜本的に変更せず、その延長線上にとどまるものであり、ベンダーに求められる説明義務を果たしたとはいえず、プロジェクト・マネジメントに関する義務違反があったから、最終合意締結の段階以降、ユーザーがシステム開発遂行のために投じた費用につきベンダーはユーザーに対して不法行為に基づく損害賠償責任を免れないとされた事例（東京高判平成２５年９月２６日、金融・商事判例１４２８号１６頁・Westlaw Japan文献番号2013WLJPCA09266001。一審の東京地判平成２４年３月２９日、Westlaw Japan文献番号2012WLJPCA03296002でもコンピューターシステムの開発において、ベンダーのユーザーに対するプロジェクト・マネジメント義務の違反が認められていた。最二小決平成２７年７月８日、Westlaw Japan文献番号2015WLJPCA07086001・2015WLJPCA07086002で上告棄却、上告不受理）がある。
 （３）これに対して、ベンダーの責任よりもユーザーに責任があったものとして、実質的にユーザーを敗訴させている事例もある。
例えば、
 （事例Ｆ）ユーザーがベンダーとの打ち合わせのたびに新たな要求事項を追加する等してソフトウェアの要件定義を確定させなかった上、追加費用の負担の提案にも一切応じなかったことが最大の原因であり、ベンダーに債務不履行の原因があるということはできない等としてユーザーの損害賠償請求をいずれも棄却した事例（東京地判平成２２年７月２２日、判例時報２０９６号８０頁・Westlaw Japan文献番号2010WLJPCA07228008）、
 （事例Ｇ）情報システムのパッケージソフト導入請負契約において、ユーザーが請負代金を支払わなかったので、請負人が未払請負代金の支払を求めたところ、ユーザーの契約締結の意思表示には錯誤があり、その意思表示は無効であるとした一審判決を否定し、本件請負契約の成立を認めたうえ、納品物の一部に未完成のものがあるが、これはユーザーの責に帰すべき事由によるものであるとして、本件契約に基づき請負代金の全額を請求することができるとされた事例（一審の判決を取り消して逆転判決。東京高判平成２６年１１月２６日、判例時報２３１０号６７頁・Westlaw Japan文献番号2014WLJPCA11266014）。
 今回取り上げる控訴審判決も、ユーザー敗訴の判決に一事例を追加するもので、事例Ｇに続くユーザーの逆転敗訴事例といえ、ソフトウェア開発を依頼するユーザー一般に広く警鐘を鳴らすものとして受け止めるべきだろう。特に、今回の控訴審判決は、ベンダーのプロジェクト・マネジメント義務違反を否定した事例として注目されよう。
 本件は、ほとんどが事実に関する争いとその評価をめぐる問題なので、やや長くなるが、本判決で問題となったエピソードをできるだけ拾って、ソフトウェア開発訴訟について考えてみたい※5。

３　本事案の概要

 今回の事件は、病院情報管理システム（以下「本件システム」という。）を開発し、構築する一連のプロジェクト（以下「本件プロジェクト」という。）に関するものであった。すなわち、ユーザー、ベンダー及びＮＴＴファイナンスは、ベンダーがユーザーのために本件システムを構築し、ＮＴＴファイナンスを所有者としてユーザーに本件システムをリースする契約を締結した。ところが、その目的は達せられず、次のような訴訟事件となり、それらが併合審理された。
 （１）第１事件は、ベンダーが納期である平成２２年１月３日に本件システムの完成及び引渡しをしなかったのでユーザーに逸失利益等の損害が生じたと主張して、ユーザーがベンダーに対して、債務不履行に基づき合計１９億３５６７万９０６７円の損害賠償及びこれに対する遅延損害金の支払を求めた。
 （２）第２事件は、ベンダーのユーザーに対する主位的請求及び第１次予備的請求からなる。すなわち、本件システムの完成及び引渡しが遅れたことにつきベンダーに帰責性はないのに、ユーザーの協力義務違反及び不当な受領拒絶により、ベンダーは上記契約の完成義務を履行できなくなり、売買代金を得られなくなった等と主張して、主位的には債務不履行に基づく損害賠償として、予備的には不法行為に基づく損害賠償として、合計２２億７９７６万３３７３円及びこれに対する遅延損害金の支払を求めた。
 （３）なお、第２次予備的請求として、ベンダーが、本件システム開発に係る業務を、ユーザーからの要請を受け、ベンダーの営業の範囲内で行ったと主張して、ユーザーに対して商法５１２条（報酬請求権）に基づく請求もされた。
 しかし、控訴審は、本件契約が金額（リース料金）を定めて締結された契約である以上、本件契約を離れて報酬請求できるものではないとして、その予備的請求は退けている。
 （４）一審では、ベンダー側の責任を重視して、ユーザーからの追加要望に振り回され「進捗を適切に管理できなかった」として、本件プロジェクトの頓挫につき、ユーザーに２割、ベンダーに８割の責任があるとして、ユーザーの請求については約３億６５００万円（及びこれに対する遅延損害金）の支払を命じ、ベンダーの請求（主位的請求）については約３億８４００万円（及びこれに対する遅延損害金）の支払を命じ、その余の請求をいずれも棄却した。その意味では、一審判決は痛み分けのようではあるものの、実質的にはベンダーの敗訴、ユーザーの勝訴であった。
 ところが、控訴審判決はユーザー側だけに約１４億１５００万円の支払を命じ、ユーザーの請求は全部棄却するという大逆転判決となった。控訴審は、本件システムが遅くとも本件解除時（平成２２年４月２６日）までには、ユーザーの協力が得られずに保留せざるを得なかった１項目を除き、全て完成していたものと認定し、契約の目的が達せられなかった一切の責任をユーザーに負わせた。ユーザーはベンダーに対して様々な批判をしているが、これを控訴審はことごとく退けた。
 本件は、証拠に照らして事実を素直に見たら、控訴審のような評価にならざるをえなかったということなのかもしれない。そうだとするならば、事実を歪曲までして中立的な公平さを装うような判決よりも、真実に合致した適正な判決であると評価することもできよう。

４　当事者双方の権利義務を定めることの困難性

 ソフトウェア開発紛争をめぐる一連の判例に関しては様々な評釈があるが、この領域において実体的に未解決の問題が多いことが指摘されてきた（例えば、「ソフトウェア開発訴訟の手引き」判例タイムズ１３４９号４頁（２０１１年）、鼎談「情報システムの開発・運用と法務」ＮＢＬ１０５０号１５頁等参照）。
 そこでの中心的な課題は、ソフトウェア開発契約における当事者双方の権利義務がどのように整理されるのかという点である。もとより、それが当初の契約書で明記できれば苦労はない。当初の段階では、それが詳細に特定できないために、大まかな枠組みだけを定めておき、徐々に詳細を詰めていくことが必要となる。
 そのプロセスにおいて、どこまでがユーザーの責任で、どこまでがベンダーの責任であるかの線引きは困難だ。とはいえ、双方の信頼関係が維持されて、協議で解決できる間は問題が顕在化しない。ところが、いったん信頼関係が崩れて紛争となれば、深刻なトラブルとなる。それが裁判ともなれば、議事録やメールのやりとり、証言等膨大な資料等から、裁判官が何がしかの認定をすることになる。
 ただ、その判断が、取引の実態に即して、どこまで適正に行うことができるのかは、極めて難しい問題であることも、十分に覚悟しておく必要がある。特に、ソフトウェア開発訴訟は、裁判所にも専門部があるわけではない。その都度、初めてこの種の事例を取り扱うという裁判官が多いであろうから、素人の裁判官を技術的な問題を含めてきちんと理解してもらうことは多大な労力が必要となるだろう。
 どこまでがユーザーの責任で、どこまでがベンダーの責任であるかを検討するに際して、法律家のアプローチとしては、両者の具体的な合意内容がどうであったかを当該事実関係の下で認定しようと試みる。ただ、これが、相当に無理のある作業となる。
 第一に、そもそも当事者自身の要望自体が流動的で、確たる意思を有している当事者等はほとんどいないだろう。新たなシステム開発をする場合、注文者であるユーザー側の要望ないし注文内容を取りまとめるのも一筋縄ではない。ましてや病院のような大きな組織で、新たなシステムについて、いろいろな意見や希望を持っている者が多ければ多いほど、それを上手くまとめるのは至難の業だ。
 第二に、システム開発においては、そのシステム自体についても相場とか、ある決まった形や標準スタイルがあるわけではなく、その追加注文があっても、元の注文の範囲に入っているのか、入っていないかといったことを判断するのは難しく、それがシステム開発の特徴だといえるだろう。
 ただ、これに似たような話は、建築の世界にはある。どういう建物にするかは、必ずしも決まっているわけではないので、注文者の意向、代金その他の状況で決まっていく。とはいえ、建築の場合には、基本的な注文内容を写真や絵等のイメージで指し示すことができれば、それなりに契約内容に入っているか否かを決めることができよう。ところが、システムの場合、形にならないものもあって、その内容を表現することに相当の手間がかかる。
 第三に、ベンダーの契約上の義務といっても、対価をもらって生じるものであるはずだが、その対価の計算方法も客観的に決まっていない。もとより、新システムの導入は決して安価なものではなく、顧客とすれば、巨額の代金を支払う以上、それに見合うシステムができるだろうと、大きく期待を膨らませてしまうのも無理はない。ベンダー側がそうした期待を誘発していることも少なくない。そうなると、その対価から逆算してベンダーの義務がどうであるかを推論するといったことも難しくなる。
 控訴審は、ベンダーにおいて、開発したシステムの内容の確認をユーザーに求めることは当然のことであって、「だからといって、ユーザーからなされる追加開発要望を受け入れることをベンダーが許容していたということはできない」とも指摘する。ユーザーの期待がそのままベンダーの義務になるわけではないのは、当然のことである。

５　プロジェクト管理義務を「立証責任」から考えてみる

 （１）一般に、システム開発においては、ベンダー側が開発プロジェクトを適切に管理する「プロジェクト・マネジメント義務」を負い、ユーザー側は開発システムの内容を明らかにするための情報を提供し、開発に協力する義務を負うものとされる。
 その役割分担が、あらかじめ契約で明確に定められていればよいが、契約段階では詳細までを詰めることができないから、どちらの責任なのかを明確に定めていない事項があった場合、基本的にベンダー側の責任なのか、ユーザー側の責任なのか、いずれなのだろうか。
 契約の一般原則からすれば、契約の成立はその成立を主張する者が立証する必要があるわけだから、ベンダーの負う「プロジェクト・マネジメント義務」はユーザーが立証し、ユーザーの協力義務はベンダーが立証する責任を負い、それぞれ立証に失敗したら、その義務は成立しないことになる。ただ、その立証は、当該業界の慣行等をも基礎にしながら、両者の有する情報格差等も勘案するし、当該関係から一般的に認められるべき義務内容は一応、契約上の義務として認められることになろう。
 今回の控訴審判決は、ユーザーから出された１７１項目の追加要望に関して、ユーザーに協力義務違反が認められる根拠の一つとしてベンダーが主張するものであるから、「これらの開発要望が出されたこと及びそれが開発対象外の開発要望であることについてベンダーが主張立証責任を負うものというべきであり、これに反するベンダーの主張は採用できない」という。これによれば、開発対象内であるとのユーザーの立場が原則として認められても、ベンダーが立証できた部分が開発対象外となるわけで、この点ではプロジェクト・マネジメント義務に関してベンダー側が重い責任を負わされているものと理解することができる。
 しかし、今回の事件において、控訴審は、１７１項目の追加要望（実数は１６９項目）のうち、ユーザーが本件仕様凍結合意後に要望を出したのは１６２項目（実数は１６１項目）であり、このうち１２５項目（実数は１２４項目）が開発対象外の開発要望であったと認定した。ベンダーは、それなりに自己の引き受けた義務を履行したことを示すことができたのである。
 （２）一方、ユーザーは高い代金を支払っている以上、原則としてベンダー側に責任があると主張するだろう。他方、ベンダーは、代金を頂く範囲でしか注文を受けていないのであって、代金で想定していない話については、追加料金をもらわない限りは責任を負ういわれはないと主張するだろう。
 この場合、ベンダー側とユーザーの力関係によって合意が形成されることもあるので、その力関係から、どういう合意をしたかを認定することは考えられるかもしれない。
 例えば、ベンダーの属する業者間の競争が激しいマーケットであれば、ユーザーはできるだけ親切にプロジェクト管理してくれるベンダーを希望するはずだ。その場合には、ベンダーがより多くのマネジメント義務を引き受けていると認定しやすいことになるだろう。
 逆に有能なベンダーが少なく、ユーザーが譲歩しなければならないようなマーケットの状況であれば、ある程度、ユーザーが積極的に協力をしていく必要があるはずであり、ベンダーが無理をしてマネジメント義務を引き受けるということは考えにくい。そうだとしたら、当該マーケットでどのような競争があって、その中でベンダーがどこまでのサービスを提供するかをアピールしていたかは、基本的にベンダー側が開発プロジェクトを適切に管理するプロジェクト・マネジメント義務を負うつもりであったのか、そうでなかったかを分けるポイントとなるように思われる。
 ところが、そのあたりの力関係が拮抗していると、このあたりの判断は使えないことになる。さらに、いったん一つのベンダーを選定すると、ユーザーは容易にベンダーを交代させることが難しくなるので、交渉力が弱まる。ベンダーがそこにつけこんで無理難題を強いれば、ユーザーはたちまち窮することになるだろう。
 そこで次の問題として、いったん選定されたベンダーが、自己の交渉力が強くなったことをいいことに、サービスが悪くなり、ユーザーに無理難題を求めるようなリスクもあるかもしれない。いわば「釣った魚にエサはやらない」状態となるリスクである。
 しかし、基本的にベンダーは引き受けた業務を完成することを目標として動いているし、ベンダーも業者としての評判・評価を気にするだろう。取引として成立した以上は、それを成功させるインセンティブの方が強く働くはずだ。ユーザーとしても、自らベンダーを選定した以上は、選定したことに伴うリスクは引き受けたものと考えれば、ある程度、そのリスクは引き受けたものと考えるほかない。
 （３）本件において、ベンダーは、６２５項目の追加開発要望を受け入れた（本件追加開発合意）が、それ以後は、新たな機能の開発要望はもちろん、画面や帳票、操作性に関わるものも含め、一切の追加開発要望を出さないという合意（本件仕様凍結合意）を取り付けた。
 本判決は、これをもって、「プロジェクトマネジメント義務の履行として、追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で、追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をした」と認定し、「これを越えて、ベンダーには納期を守るためには更なる追加開発要望をしないようにユーザーを説得したり、ユーザーによる不当な追加開発要望を毅然と拒否したりする義務があったということはでき」ないとして、プロジェクト・マネジメント義務の違反を否定する結論を導いた。
 これはベンダーからの「これ以上の追加開発要望は受け付けることができない」という明確な意思表示であって、これによって「仕様凍結」をしたことが、ベンダーのプロジェクト管理義務を果たすことになることを明示した点に、この判決の最重要ポイントがあるといえる。
 こうした仕様凍結は、控訴審にとっては合理的な一区切りと見えたのだろう。ユーザーが「パッケージ標準機能及び他病院機能を信頼して、未確認部分についても一切の追加開発要望は出さないことを受け入れることが、あながち不合理な意思決定といえない」として、ユーザーが合理的にそのように受け入れるべきであったといわんばかりである。つまり、ベンダーとしてはギリギリまで頑張って仕事をしたのであって、それに対して、ユーザーはそれを受け入れないで一方的な主張を続けたという判断となっている。
 それ故に、控訴審は、ベンダーは「ＷＧにおいて作成すべき画面イメージや帳票サンプル等の確認及び承認を得ていた」として、一つの区切りを認定したうえで、「要件定義書等の提出がなかったからといって、要件定義工程が終了していなかったということはできず、また、追加開発要望が出せるとユーザーが期待していたとしても、その期待は合理的なものであったということはできない」としてユーザーの主張を退けた。
 （４）その後の段階においても、ユーザー側が追加注文をしたり、いろいろとクレームをつけたりして、トラブルになるリスクもある。特に、システムの納品・検収の段階で、ユーザーが「品質が劣る」「使えない」等のクレームをつけて、受け入れテスト等の協力を拒否し、検収・受領を拒絶し、プロジェクトが中止に追い込まれることがある。この場合、成果物の品質が劣悪か否かを、定量的・客観的に立証することは困難だ。
 この点については、どちらが立証責任を負うのか問題となることもある。ベンダーが一応の履行をしたことを示せば、その瑕疵についてはユーザー側に立証責任があることになる。したがって、基本的には、ユーザー側に自らの主張を裏づける根拠がなければ、ベンダーがうまく裁判所を説得できる可能性も高くなるだろう。
 本判決では、ベンダーのＳＥの資質欠如が本件システム開発遅延の一因である旨のユーザーの主張は、これを認めるに足りる的確な証拠はないという指摘がされている。この手の主張は、単なる感覚的な主張では通るものではない。

６　ベンダー側に肩入れした事実認定

 現実がどうであったのかは、部外者から知る由もない。本判決は基本的に事例判決であって、裁判所がなぜ、そのような事実認定をしたかについては、必ずしも明らかではない。ただ、本判決が、敢えて中間的な立場を取らずに、ユーザー側に重い責任を認めたのは、裁判所から見て、ユーザーの対応に合理性が認められなかったからだろう。
 確かに、病院で取り扱われる情報は、かなりセンシティブな個人情報も多く、極めて専門性が高いので、ベンダー側がコントロールするのが困難であったものと考えられる。ベンダー側には医療業務の専門的な知見や経験を備えた者がいないのであれば、それはユーザー側がかなり時間を割いて対応しなければならないはずである。
 ところが、ユーザー側にベンダーを下に見るような雰囲気があって、ベンダー側の立場が弱いとなれば、ベンダー側に無理を強いるような傾向に陥っていた可能性があり、そういう事情があれば、紛争になった場合には、そのような関係を調整する力が働く可能性がある。
 控訴審は、ベンダーのプロジェクト・マネジメント義務について、それなりに検討を加え、先の項目で検討したとおり、ベンダーはプロジェクト・マネジメント義務を尽くしたと判断した。
 さらに、控訴審は、ベンダーがユーザーに強く出られない弱い立場にあることを斟酌した事実評価をしているようだ。例えば、ユーザーはベンダーのＣＰＬらが「本件システムの不具合や開発の遅れを認め、謝罪する旨の発言」をしている点を指摘した。しかし、これに対しては、「追加開発要望がユーザーから大量に出され、その相当数について対応を余儀なくされ、本件システム開発が遅れていたベンダーによる謝罪であって、その発言が全てベンダーの真実の認識に基づくものであったと考えるのは相当ではない」と判断している。
 また、ベンダーが「継続的な設定変更・確認が必要なマスタ」の抽出作業を行っていたことを認定したが、それらはユーザーがその義務であるマスタの抽出作業を行わず、本件プロジェクトが停滞する中で、やむなくベンダーがその一部の作業を代行したものであったと認定し、それらの事実があったからといって、ベンダーが『「継続的な設定変更・確認が必要なマスタ」の抽出義務を負っていたということはできない』と判断し、こうした事情からベンダーの負担が増大したものと認めて、ユーザーを批判している。

７　仕事の完成の認定

 今回のシステム開発は、失敗したのではなく、ベンダーの仕事は完成していた。それにいろいろな文句をつけてプロジェクトを頓挫させたユーザーが、一方的に悪かったと評価できるような事件だ、というのが控訴審の見立てであった。
 まず控訴審は、「システム開発では、初期段階で軽微なバグが発生するのは技術的に不可避であり、納品後のバグ対応も織り込み済みであることに照らすと、バグが存在しても、システムを使用して業務を遂行することが可能であり、その後の対応で順次解消される類のものであれば、仕事が完成したと認定すべきである」という。
 この立場を前提に、「結局、本件仕様凍結合意時に本件システムに含めることに合意された機能６４８６項目のうち・・・、平成２２年３月１６日時点で開発未了だったのは１項目・・・に過ぎない。・・・ベンダーは、上記６４８６項目について、・・・ユーザーの協力が得られずに保留せざるを得なかった１項目を除く全てについて開発を完了させた」、「本件仕様凍結合意後にユーザーが大量の追加開発要望を出していなければ、同月３日までには本件システムを完成させ、同月４日から運用を開始することが十分に可能であった」等と認定した。
 同様に、「プロジェクト再開に向けてのご提案」では、本件システム開発の進捗状況として、「プログラムの不具合」（バグ）１１２個のうち１１０個は既に対応が完了していると認定し、ベンダーが平成２２年６月２５日までに作成した完成証明資料によれば、「同日までには、ユーザーの協力が必要であった１項目」を除き、本件システムは完成していたと認定した。
 また、「平成２１年１２月１３日に予定されていた第２回外来リハーサルが中止され、以後、リハーサル及び操作研修等が行われなかったのは、ユーザーの一部職員が、独自の見解から、リハーサルの実施に消極意見を出し・・・、また、ベンダーとの接触を一方的に拒否したためであって・・・、本件システムが未完成だったからとは認められない」とか、「ユーザーの意向を踏まえた運用確認等が必要であると考えていたのであって、即時の検収等を求めなかったからといって、本件システムが完成していなかったということはできない」等と指摘して、本件解除時までに本件システムは完成していなかった旨のユーザーの主張をことごとく退けた。
 結局、本件プロジェクトは完成していたが、ユーザーが文句をつけて受領しなかったトラブルにすぎないと控訴審は評価したようだ。

８　ユーザーの協力義務について

 一般に、注文者・ユーザーは、システムの開発過程において、資料等の提供その他システム開発のために必要な協力を開発業者から求められた場合、これに応じて必要な協力を行うべき契約上の義務（協力義務）を負っている。
 本判決は、薬品や検査項目等のように病院ごとに異なる「継続的な設定変更・確認が必要なマスタ」の作成は、医療業務に対する知識が必要であるうえ、病院ごとに医療業務の内容及びデータ処理の実情が異なることから、医療業務に従事していないベンダーが単独でこれらマスタを作成することは不可能なのであって、ユーザーの責任で作成し、その後の継続的な設定変更・確認を行うことが必要であるという。
 そして、本判決は、協力義務違反について、システム開発はベンダーの努力のみによってなし得るものではなく、ユーザーの協力が必要不可欠であって、ユーザーもベンダーによる本件システム開発に協力すべき義務を負い、この協力義務は、本件契約上ユーザーの責任とされていたもの（マスタの抽出作業等）を円滑に行うというような作為義務はもちろん、本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、ベンダーにその対応を強いることによって本件システム開発を妨害しないという不作為義務も含まれていると指摘した。それにもかかわらず、本件では、ユーザーが本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、ベンダーがこれに対応せざるを得なかったことから、本件システム開発が遅延したと認定した。
 また、ユーザーがマスタの抽出義務を負っていたにもかかわらず、これを懈怠し、ユーザーの協力が得られないままベンダーが代行せざるを得なくなったことも、本件プロジェクトが遅延した理由の一つだと指摘する。
 さらに、ユーザーは、その追加開発要望に基づいて現行システムの備える機能を最大限取り込むことを要求しながら、そのために必要な現行システムの情報（基本設計書等）を十分に提供せず、またベンダーがユーザーに代わってマスタの抽出作業を行うに際しても、ＮＥＣに必要な協力依頼を行うことを怠ったという。
 そして、本件システムは、遅くとも平成２２年４月２６日までには、ユーザーの協力が得られずに保留せざるを得なかった１項目を除き、全て完成していたにも関わらず、ユーザーは、独自の見解から本件システムの開発がベンダーの責任で遅延したとして、一方的に本件解除をしたと指摘して、ユーザーの本件契約上の協力義務違反（債務不履行）を認めた。

９　結びに代えて

 トラブルに巻き込まれた場合に、相手方と争うのは自由であるし、争う権利は誰にでもある。しかし、双方協議はあくまでもフェアでなければならない。ユーザーとしてお金を支払っているからといって、ベンダーの立場に対して配慮が乏しいユーザーは決して賢明とはいえない。今回の控訴審判決が認定している事実のとおりであるとすれば、ユーザーの対応は、利己的な印象であり、不合理の感は否めない。合理的な協力をして、プロジェクトの成功に努力すべきだったのに、そうした姿勢が足りなかったことは、ユーザーの組織のガバナンスにも問題があったことをうかがわせる。
 今回の事案は、システム開発に失敗したわけではないのに、失敗したことにさせられたもので、もう少しユーザーは柔軟に対応すべきだったということになる。この結論が最高裁でも維持されれば、ユーザーは、一連の紛争でかなり大きな損失を被ることになり、その紛争費用も含めて、その学習コストはとても高くつくことになるわけで、大きな教訓を残してくれた一つの事例として記憶されることになるだろう。

（掲載日 2017年11月13日）