一審原告である札幌医大(X)、一審被告NTT東日本(Y)とファイナンス会社A社との間で、YがXのために病院情報管理システムを構築し、Aをその所有者としてXに対する当該システムのリースすることを目的とする契約を締結したところ、Xは、Yに対し、納期までに当該システムの完成及び引渡しがなかったために損害を被ったとして、Yは、Xに対し、当該遅滞につき、Yに帰責性はなく、Xの協力義務違反及び不当な受領拒絶によりYが売買代金を受け取れなかったとして、それぞれ債務不履行に基づく損害賠償請求等をした事案です。
一審はXとYのいずれの債務不履行責任も認めた上で、その責任割合をX:Y=2:8とし、いずれの請求についても一部を認容する判決を下したところ、XとYのいずれもがこれを不服として控訴したものです。
ベンダーとユーザーがそれぞれ負う、プロジェクトマネジメント義務と協力義務については、下記エントリにて解説しています。
H20.12.9 X･Y･A、YがXのために病院情報管理システムを開発し、これを所有者AがXにリースすることを目的とするリース契約(原契約)を締結
H21.7.7 X･Y、625項目の仕様項目についても開発対象に含めることで「仕様凍結」することを決定、前記システム運用開始日を平成22年1月4日に変更
H21.9.3 X･Y･A、原契約のリース期間を変更する旨の契約締結(以下、原契約と併せて「本件契約」という。)
H22.1.3 Y=>X、前記システムを引き渡さず
H22.3.10 X=>Y、前記システムに係る債務の履行の催促
H22.4.26 X=>Y、債務不履行に基づく解除の意思表示
裁判所は、 システム開発において、初期段階で軽微なバグが発生するのは技術的に不可避であり、納品後のバグ対応も織り込み済みであることに照らすと、バグ等があっても、システムを使用した業務遂行が可能であり、その後の対応でバグが解消される類のものであれば、仕事は完成 したとの一般論を示した上で、本件においては、仕事はすべて完成していたとしました。
「システム開発では、初期段階で軽微なバグが発生するのは技術的に不可避であり、納品後のバグ対応も織り込み済みであることに照らすと、バグ等が存在しても、システムを使用して業務を遂行することが可能であり、その後の対応で順次解消される類のものであれば、仕事が完成したと認定すべきである。」
「上記の見地から検討するに、以下のような事実に照らすと、本件システムは、遅くとも本件解除時(平成22年4月26日)までには、Xの協力が得られずに保留せざるを得なかった一項目を除き、全て完成していたものと認められる。」・リハーサルについて
「遅くとも平成21年12月13日までには、本件システムは外来リハーサルを実施できる程度にまでは完成していた。」
・総合テストについて
「Yは、本件システムへの切替時又は切替後に実施すべき6項目を除く項目について総合試験を実施し、総合試験を実施した全ての項目について合格と判定されるに至っている。」
・「技術仕様書未実施リスト」
「……(註：仕様凍結合意時に前記システムに含めることに合意された6486項目の機能のうち、平成22年1月5日当時に開発未了とされた)57項目のうち25項目は、DWH……の提供であり、既に完了していたし……、18項目は、システム移行･切替の最終工程で作業が必要な項目であり、同日時点で完成させる必要がない項目であった。
……結局、同日時点で未完成だったのは、……4項目に過ぎず、これら4項目を欠いた状態でも本件システムを運用することは十分に可能であった。」
「同年2月1日の……『技術仕様書未実施リスト』では、上記……の未完成の4項目のうち、……同日時点で開発未了だったのは三項目のみになっていた。」
「結局、本件仕様凍結合意時に本件システムに含めることに合意された機能6486項目……のうち、平成22年3月16日時点で開発未了だったのは一項目……に過ぎない。
これは、『Y社仕様作成中(病院様へ確認が必要なため、作業を保留)』とされており、Yは、上記6486項目について、平成22年3月16日までに、Xの協力が得られずに保留せざるを得なかった一項目を除く全てについて開発を完了させたものと認められる。」
・「プロジェクト再開に向けてのご提案」
「(註：同年3月16日にYが提出した)『プロジェクト再開に向けてのご提案』は、同日時点における本件システム開発の進捗状況として、『プログラムの不具合』(バグ)112個のうち110個は既に対応が完了しているとしていた……。
未完了の2項目のうち、『F社への帳票送信データ項目』は、Xが確定すべき帳票フォーマットの仕様に関するものであり、平成22年1月14日……、5日以内に完成可能である旨が伝えられていた。他の1項目……は、本件技術仕様書上、……バグではなく、開発対象外の開発要望であった。」
・完成証明資料
「Yが平成22年6月25日までに作成した完成証明資料によれば、同日までには、Xの協力が必要であった1項目……を除き、本件システムが完成していた事実が認められる。」
なお、裁判所は、 Yのプロジェクトリーダーらが前記システムの不具合や開発の遅れを認めて謝罪をする旨の発言をしたことにつき、そのすべてがYの真実の認識に基づくものであったと考えるのは相当でない 旨を述べています。
「専門部会の席等において、N3PLらが、本件システムの不具合や開発の遅れを認め、謝罪する旨の発言をしている……。
しかしながら、これらは、追加開発要望がXから大量に出され、その相当数について対応を余儀なくされ、本件システム開発が遅れていたYによる謝罪であって、その発言が全てYの真実の認識に基づくものであったと考えるのは相当ではない。」
本件におけるシステム開発は、Yと第三者とが共同で開発したパッケージソフトウェアを、必要に応じてカスタマイズして行う、というものでした。
裁判所は、 パッケージを必要に応じてカスタマイズするか、フルスクラッチとするかは、ユーザーであるXの判断事項であり、ユーザーがカスタマイズ開発を選択した以上は、パッケージによる制限によってカスタマイズ要望の範囲が限定されたとしてもやむを得ない というべきである旨を述べました。
また、本件の紛争の根本的原因は、Xが従来の運用の維持に固執する現場の要望を反映させないまま要求仕様書等をとりまとめて本件契約を締結し、にもかかわらず、その後に当該要求仕様書等やこれを踏まえて作成された技術仕様書等の記載を無視して出された現場の追加開発要望を抑える努力を放棄し、Yにその対応を強いたことにある旨を述べました。
「現行の運用の維持を最優先して、一から新たに開発するオーダーメイド型の開発を発注するのか、運用の見直しを前提として、パッケージをベースにした開発を発注することにより経費の削減を図るのかは、まさに発注者であるXの判断事項であり、Xにおいて後者を選択した以上は、カスタマイズの要望ができる範囲が限定されたとしても、やむを得ないことというべきである。この点、本件の紛争の根本的な原因は、Xが、現行の運用の維持に固執する現場の医師らの要望を十分に反映させないまま本件要求仕様書等を取りまとめて本件契約を締結したこと、にもかかわらず、その後、本件要求仕様書等並びにこれを踏まえて作成された本件技術仕様書の記載を無視して出される現場の医師らの追加開発要望を抑えるための努力を放棄し、Yがその対応に当たらざるを得なかったことにあったと考えられる。」
そして、裁判所は、Xの主張をすべて退け、パッケージソフトウェアの標準機能部分とX以外の他病院機能の移植部分につき、Yがこれらを無償でカスタマイズする義務を負わないとしました。
「以上のとおり、分類一(註：パッケージソフトウェアの標準機能部分)及び二(註：X以外の他病院機能の移植部分)についてのカスタマイズ義務が一審被告にあった旨のXの当審における主張は、いずれも採用できない。」
次に、YがXに対してパッケージの標準機能部分とX以外の他病院機能の移植部分に関する要件定義書等の提出を行っていなかったことにつき、作成の必要性がない項目まで網羅した要件定義書や外部設計書の作成が約束されていたわけではなく、また、カスタマイズを予定していない項目まで網羅した外部設計書の作成が必要不可欠であるとは認められないとしています。
「確かに、本件システムについて要件定義書等を作成することは、要件定義工程作業実施要領、プロジェクト計画書及び品質保証計画書に明記されており、Yは、これら『基本設計資料』をXに提出し、Xによる承認を受けることとされていた。
しかしながら、上記も、およそ作成の必要性が認められない部分についてまで網羅した『要件定義書』又は『外部設計書』というタイトルの書面の作成を約束していたものとは認められない。
この点について、Xは、……教授の意見書をもとに、全体の要件定義書等が必要である旨を主張する。しかしながら、同意見書中には、『他大学病院における開発において、ベンダがパッケージ説明書を提出した上で、これをカスタマイズした箇所および関連する画面･帳票等の変更箇所についてのみ外部設計書を提出することがみられる。』旨の記載があり、パッケージソフトをカスタマイズしたシステムを導入する場合には、大学病院においても、網羅的な外部設計書が作成されないことがある事実を認めているところである。同教授は、上記は『変更箇所のみの提出でユーザが十分に業務イメージを構築できる場合に限られる。』と記載しているが……、同記載は、『システムは全体として統合されて機能を発揮するものですから、随時確認できる全ての書類が必要である』との記載と整合せず、これら意見書によっても、カスタマイズを予定していない項目まで網羅した外部設計書の作成が必要不可欠であると認めることはできない。」
「以上のとおり、Yは、分類一及び二については、要件定義書等の作成義務を負っていなかったものと認められる。」
なお、Yは、カスタマイズが予定されていた部分についても要件定義書等を作成していませんでしたが、これについては、要件定義書等を作成してXにこれを交付する義務を怠っていた旨が述べられています。
「以上のとおり、Yは、分類三に限っては、要件定義書等を作成し、これをXに提出して、専門部会において審議及び承認を得る義務があったが、これを怠っていたものと認められる。」
裁判所は、原審と同様、本件事案における仕様凍結合意は、開発対象を特定し、 新たな機能の開発要望はもちろんのこと、画面や帳票、操作性に関わるものも含め、一切の追加開発要望を出さない との合意であるとしました。
原審の挙げた理由は、概ね次のとおりです。
「本件仕様凍結合意が、開発対象を確定し、以後、Xは、Yに対し、新たな機能の開発要望はもちろん、画面や帳票、操作性に関わるものも含め、一切の追加開発要望を出さないとの合意(一般的な意味での『仕様凍結』の合意)を意味すると見るのが相当であることは、原判決『事実及び理由』欄の『第三 当裁判所の判断』の五項のとおりであるから、これを引用する。」
原判決(旭川地裁平成28･3･29判時2362-64)
「そこで検討すると、そもそも『仕様凍結』という用語自体、仕様を凍結する、すなわち、開発すべき仕様を確定し、以後これを変更しないことを意味するものと解するのが、その文言からして自然である。そして、システム開発が、画面や帳票等に関する軽微な変更であっても、他の部分に影響し、結果として開発の工数や費用が増大する可能性があるのであるから、『仕様凍結』後には、新たな機能の開発要求はもちろん、画面や帳票、更には操作性に関わる開発要求をすることは、基本的には許されないものと解するのが合理的である。」
「そして、前記……のとおり、本件システム開発については、いわゆるウォーターフォールモデルが採用されているのであるから、仕様凍結後に新たな開発要求が出され、そのために要件定義工程や外部設計工程をやり直すことは、基本的には想定されていないというべきである。前記……のとおり、Yが平成20年11月14日のキックオフ以来複数回にわたって原告に交付したマスタスケジュール等においても、要件定義及び外部設計が終了した段階で『仕様凍結』とされ、その後は開発工程に進むものとされているが、これも仕様凍結後に要件定義工程や外部設計工程をやり直さないことを前提としたものと解される。」
「このように、本件仕様凍結合意は、Yが仕様外カスタマイズの要望に応えて追加開発を行う代わりに、本件システムの運用開始日を平成22年1月4日と変更することが前提となっていたものである。そうだとすると、本件仕様凍結合意後に、YがXの更なる要望に応えて追加開発を行うこととなれば、変更後の運用開始日までに本件システムを完成させることが困難となる可能性があるのであるから、そのような追加開発は予定されていなかったというべきである。」
「以上の事情を総合すると、本件仕様凍結合意とは、開発範囲を確定し、以後、Xは、Yに対し、新たな機能の開発要求はもちろん、画面や帳票、更には操作性に関わる開発要求も含め、一切の追加開発要望を出さないとの合意であったとみるのが相当である。」
なお、仕様凍結合意後に、Yが仕様書等やシステムの確認を求めたり、Xの指摘を受けて修正を行ったことについて、裁判所は、本件事情の下では、これらの事実をもってしても、ベンダーがユーザーからなされる追加開発要望を受け入れることをベンダーが許容するものではなく、又は追加開発要望に応じる義務を生じさせるものではないとしました。
「ベンダにおいて、開発したシステムの内容の確認をユーザに求めることは当然のことであって、だからといって、ユーザからなされる追加開発要望を受け入れることをベンダが許容していたということはできない。」
「Xは、本件仕様凍結合意後も、YがXの指摘を受けて修正を行うなどした事実があった旨を指摘するが、これは、Xによる追加開発要望をYが拒否し切れなかったというにとどまり……、Yが本件仕様凍結合意後に出される追加開発要望に応じる義務を有していたことを裏付ける事実ということはできない。」
裁判所は、原審と同様、継続的な設定変更･確認が必要なマスタについて、Xにマスタ抽出義務があったとしました。
「本件契約上マスタの抽出義務を負っていたのは、Xであり、しかるに、Xは、マスタの抽出義務を怠り、Yがマスタの作成を代行するに際しても協力を怠ったものと認められる。」
原判決(旭川地裁平成28･3･29判時2362-64)
「以上のとおり、Yが提出した本件技術仕様書の添付資料においては、各種マスタの情報の入力作業はXが行うものとされていたこと、プロジェクト概要においても、運用開始後もメンテナンスが必要な設定についてはXが行うものとされていたことが認められるのであって、Yが、本件原契約を締結するに当たって、上記……記載の一般的な手順を想定していたことは明らかである。そして、キックオフにおいても、上記の一般的な手順を前提として、YからXにマスタ作成への協力要請がされたのに対し、Xからは、マスタの作成は全てYが行うべきであるなどといった発言は出されなかったことが認められる。このような経緯を経て、XとYは本件原契約を締結し、その後、Yが作成したマスタスケジュールにおいても、マスタ作成の主担当はXであるとされていたにもかかわらず、これにXが異議を述べた形跡はうかがわれず、平成21年3月31日……においても、Yからマスタ移行について説明がされたのに対し、Xからは特段の異議が述べられていないのである。さらに、同年4月27日……において、……医師から、マスタ作成をX病院の職員が行うことへの懸念が示され、Yに作成をしてほしいとの要望が出されるに至っているものの、この発言もマスタの作成義務は本来Xにあることを前提としたものであるし、……教授も、X職員がマスタ作成作業を行うことを前提とした発言をしているのである。
そうすると、本件契約においては、継続的な設定変更･確認が必要なマスタについては、Xが既存マスタのデータを抽出し、必要な入力作業を行う義務を負っていたというべきである。」
なお、控訴審は、「継続的な設定変更･確認が必要なマスタ」につき、次の事実認定を加えています。
ユーザーにとって専門的な部分については、ベンダーのみでは対処できず、ユーザーの協力が必要ですから、そのような部分をベンダーのみが単独で行うということは、実際問題不可能であると考えられます。
「また、薬品や検査項目などのように病院ごとに異なる『継続的な設定変更･確認が必要なマスタ』の作成は、医療業務に対する知識が必要であるうえ、病院ごとに医療業務の内容及びデータ処理の実情が異なることから、医療業務に従事していないYが単独でこれらマスタを作成することは不可能なのであって、ユーザであるXの責任で作成し、その後の継続的な設定変更･確認を行うことが必要なものである。」
まず、裁判所は、次のように述べ、Xの協力義務違反を肯定しました。
すなわち、ユーザーがベンダーに対して、 本来ユーザーの責任とされていたものを円滑に行うといった作為義務 はもちろんのこと、 本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、ベンダーにその対応を強いることによって本件システム開発を妨害しないといった不作為義務 も協力義務には含まれているとした上で、Xのマスタ抽出に係る義務違反や、本件契約や凍結合意に反する大量の追加開発要望を出す等により、前記システム開発の遅延を生じさせたとしています。
「システム開発はベンダであるYの努力のみによってなし得るものではなく、ユーザであるXの協力が必要不可欠であって、Xも、Yによる本件システム開発に協力すべき義務を負う……。そして、この協力義務は、本件契約上Xの責任とされていたもの(マスタの抽出作業など)を円滑に行うというような作為義務はもちろん、本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、Yにその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。
しかるに、前記……のとおり、Xが本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、Yがこれに対応せざるを得なかったことから、本件システム開発が遅延した。
また、前記……のとおり、Xがマスタの抽出義務を負っていたにもかかわらず、これを懈怠し、Xの協力が得られないままYが代行せざるを得なくなったことも、本件プロジェクトが遅延した理由の一つになっている。
さらに、Xは、Xの追加開発要望に基づいて現行システムの備える機能を最大限取り込むことを要求しながら、そのために必要な現行システムの情報(基本設計書等)を十分に提供せず、また、YがXに代わってマスタの抽出作業を行うに際しても、C社に必要な協力依頼を行うことを怠った……。
そして、前記……のとおり、本件システムは、遅くとも平成22年4月26日までには、Xの協力が得られずに保留せざるを得なかった一項目を除き、全て完成していたにも関わらず、Xは、独自の見解から本件システムの開発がYの責任で遅延したとして、一方的に本件解除をした。
上記のとおり、Xには、本件契約上の協力義務違反(債務不履行)が認められる。」
次に、裁判所は、次のように述べ、履行遅滞について、Yに債務不履行はないとました。
「前記……のとおり、本件システムの引渡日を平成22年1月4日以降へ延期するとの合意があったとは認められず、約定の期日に本件システムの引渡しがなかった(履行遅滞)との事実は認められる。
しかしながら、本件システム開発が遅延し、結局引渡しがなされないまま本件解除に至ったのは、前記……のとおり、Xが協力義務に違反したためであり、Yの責任によるものとは認められない。」
「Yによる要件定義書等の提出義務違反は、本件仕様凍結合意後における本件システム開発の進行に影響を与えるものとはいえず、Yの責任によって本件プロジェクトが頓挫したということはできない。」
とりわけ、裁判所は、Yのプロジェクトマネジメント義務違反に有無について、次のように判断しています。
「Yは、平成21年3月4日以降、専門部会等において、繰り返し、Xによる追加開発要望の多くは仕様外のものであること、Yとしては、これらの追加開発要望に対応するのは難しく、同年9月24日(本件原契約におけるリース開始日)に間に合わなくなることを説明した……。そして、Yは、同年7月7日、Xによる625項目の追加開発要望を受け入れる(本件追加開発合意)一方で、以後は、新たな機能の開発要望はもちろん、画面や帳票、操作性に関わるものも含め、一切の追加開発要望を出さないという合意(本件仕様凍結合意)を取り付けたものである。このように、Yは、プロジェクトマネジメント義務の履行として、追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で、追加開発要望の拒否(本件仕様凍結合意)を含めた然るべき対応をしたものと認められる。
これを越えて、Yにおいて、納期を守るためには更なる追加開発要望をしないよう注文者(X)を説得したり、Xによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず、Yにプロジェクトマネジメント義務の違反があったとは認められない。
以上から、裁判所は、Yには債務不履行について帰責性がなく、Xの債務不履行について過失相殺も認められないとしています。
「したがって、Yには債務不履行(履行遅滞)について帰責性がなく、また、Xの債務不履行について過失相殺の対象となるべき過失の存在も認められない。」
結論としては、Xの請求はすべて棄却され、Yの請求が一部認容されることとなりました。
14億1501万9523円及びこれに対する平成22年9月3日から支払済みまで年6％の割合による遅延損害金の支払が認められたわけですが、遅延損害金だけでも相当の額ということになります。
なお、Xによって上告受理申立てもされましたが、最高裁判所はこれを不受理としています。
一般論として、システム開発訴訟においては、システム開発がベンダーとユーザーが共同して行っていくという性質等に照らして、過失相殺等により、いずれか一方の当事者の請求が全面的に認められるということは少ないとされています。
本件では、ベンダーであるYには債務不履行もなければ過失もなかったとされており、その意味では、比較的貴重な事案であるということもできるかと思われます。
控訴審の判決全体を見るに、控訴審は、その事実関係から、ベンダーに対するユーザーからの不合理かつ過度な要求があったという印象をまずもって抱いていたように感じられます。
このことは、例えば、上述したYのプロジェクトリーダーらによる謝罪について述べた部分や、Xの追加開発要望に関して述べた部分などの言い回し等からもそれとなく感じ取れるところです。
ユーザーの期待や要望がそのままベンダーの義務になるわけではありません。
もちろんそれぞれの力関係もあり、ユーザーからの要望に応えてしまうこともやむを得ないとして多々見られるところですが、ベンダーとしては、仕様凍結合意等を行って追加開発要望を拒絶するなど、要所要所では自らの利益を守るための行動を起こす必要があること等を示唆させる、重要な判決であると言い得るでしょう。
受付: 10:00~18:00 / 土日祝を除く