IT・システム判例メモ

弁護士 伊藤雅浩が,システム開発,ソフトウェア,ネットなどのIT紛争に関する裁判例を紹介します。

システム開発頓挫の責任 旭川地判平28.3.29(平23ワ99号ほか)

大規模医療システムの導入プロジェクトが頓挫した場合におけるベンダ・ユーザの責任の所在・割合と損害の額等が問題となった事例。

事案の概要

医療法人Xは,電子カルテシステムを中核とする病院情報管理システム(本件システム)を導入することを企図し,入札を実施した。これに対し,ベンダのYは,平成20年10月1日付けで,パッケージをカスタマイズしてシステムを完成させるという提案をした。Xは,同月31日にYを落札者と決定し,平成21年9月24日までに検査を完了させることが合意された。


しかし,仕様の確定や,その後の追加要望について紛糾し,平成22年1月を過ぎてもYは,本件システムを引き渡すことができなかったため,Xは同月4月26日になって,債務不履行に基づく解除の意思表示をした。


そこで,Xは,Yに対し,債務不履行に基づく損害賠償として約19億円を請求したのに対し(第1事件),Yは,Xに対し,無効な解除の意思表示を前提とする不当に受領拒絶によって履行し得なくなったとして,主位的には債務不履行,予備的には不法行為に基づく損害賠償として,合計約23億円を請求した(第2事件)。

ここで取り上げる争点

争点が多数あるが,印象に残ったものをいくつか取り上げる。

(1)本件システムの稼働を延期するとの合意があったか
(2)本件システムは完成したのか
(3)本件システムのカスタマイズ範囲
(4)要件定義書及び外部設計書の提出義務はあるか
(5)本件仕様凍結合意の意味
(6)本件プロジェクト頓挫についてのX,Yの責任
(7)Xの損害額
(8)Yの損害額

裁判所の判断

争点(1)稼働時期延期の合意

裁判所は,少なくともXの権限のある者によってリース開始日(事実上の稼働日)を延期するとの決定はなされていないとし,Yの主張を退けた。なお,稼働予定日の約1か月前に会議においてシステム稼働を延期することの決定がなされていることについては次のように述べている。

平成21年12月9日の第14回専門部会においては、平成22年1月1日からの本件システム稼働を延期することが決定されているが、これは、Yが納期どおりに本件システムを納品することができないという現状を踏まえ、予定どおりのシステム稼働が不可能となったことが上記専門部会で確認されたことを意味するにすぎず、これをもって引渡日を延期することがXY間で合意されたということはできない。

争点(2)システムの完成

引渡予定日におけるシステムの完成が主要な争点となった。この点については,次のように述べて平成22年1月3日時点では完成していないとされた。

本件システムは、本件要求仕様書等においてXが要求し、Yが本件技術仕様書等において提供することを約束した機能等が実現され、稼働する状態が達成されて初めて完成とみなされる。

ところが、前記1(8)キによれば、本件システムについては、平成21年11月には総合試験を開始していたと認められるところ、前記1(7)サ、スのとおり、同月14日に実施されたプレリハーサルにおいては複数の不具合が発生し、同月28日の第1回外来リハーサルにおいても、やはり複数の不具合が発生していた(略)。また、前記1(8)ウ、エ(イ)のとおり、Yは、同年12月9日、不具合の存在等を理由に平成22年1月の稼働開始を延期したい旨申し入れ、その結果、平成21年12月13日に予定されていた第2回外来リハーサルも中止される事態となっている。(略)

加えて、前記1(9)エのとおり、平成22年1月18日の第16回専門部会では、Xから、Yの作成した資料に記載されていない不具合があることが指摘され、Yが試験項目数やマスタ設定数の設定に不備があったこと、開発が完了したとの判定に不適切なものがあったこと、試験の実施方法に問題があったことを認め、謝罪し、今後は修正や変更後のテストを徹底すると述べるに至っている。

そして、前記1(9)オのとおり、Xが平成22年1月から同年2月にかけて本件プロジェクトを継続するか否かを判定するため本件システムの完成度を評価したところ、その結果は、最終的には6WGにおいて「否」とされ、総合評価も「否」とされている

加えて、前記1(9)クのとおり、平成22年3月16日にYがXに提出した「プロジェクト再開に向けてのご提案」と題する書面(甲15)においては、平成22年3月に不具合改修・開発を行うこと、同年5月上旬までに自主的品質点検を行うこと、その上で納期を平成23年1月又は平成22年9月下旬とすることが提案されている。

ウ こうした経緯を踏まえると、前記1(8)キのとおり、Yは、総合試験を終了したとして、平成21年12月28日、Xに総合試験成績書を提出しているものの、その内容をたやすく信用することはできないというべきであって、平成22年1月3日までに本件システムが完成、すなわち稼働する状態を実現していたと認めるに足りる証拠はないというべきである。

裁判所は,多くの裁判例で用いられた「予定されていた最後の工程を終えているか」という基準ではなく,各種事象の総合判断によって完成を判断した。Yは,総合試験成績書を提出していたものの,各種不具合が発生していたこと,ユーザによる完成度評価が「否」とされていたことや,納期を大幅に遅らせる旨の提案をしていたことなどから完成を否定した。

争点(3)本件システムのカスタマイズ範囲

個別具体的な事情となるため詳細は割愛するが,Xが求めていた仕様が,XY間で合意されていたか(開発対象となっていたか)が問題となった。これにあたって,Yが作成する書面(本件技術仕様書等)においては対象外とされていたと認定する一方で,Yの担当者も現行機能は守ると発言していたなど,Xの主張に沿う事実もあったと認定されていた。この点について,裁判所は次のように述べて,合意はされていなかったとした。

本件システム開発がパッケージをベースとしたものであることについてはX及びYの共通認識であったと認められるところ、カスタマイズのために無制限にシステム開発作業を実施すれば、作業量が増大し、開発費用が大きく増加することは明らかである。そうすると、ベンダであるYにとって、カスタマイズの範囲は、開発費用の見込みに大きく影響を与える重要な要素であって、それゆえに本件技術仕様書等においてこれが表示されていると考えられるのであるから、分類1、2についてカスタマイズを行わないとYの担当者が十分に説明していなかったとか、本件技術仕様書の文言に必ずしも明確でない部分があったとしても、そのことから直ちに分類1、2についてもカスタマイズが予定されていたということは困難である。

争点(4)要件定義書・外部設計書の提出義務

Xは,「一般的な意味における要件定義書や外部設計書」を作成する義務があったと主張し,Yはこれを否定していた。しかし,裁判所は,

  • Xが提示した要求仕様書(RFPのようなもの)には,基本設計資料等の提出を求めることが記載されていたこと
  • Yが入札時に提示した資料には要件定義書・外部設計書を提出することが記載されていたこと
  • Yが作成した要件定義工程作業実施要領において成果物として要件定義書等が定められていたこと

などから,Yが基本設計資料,実装設計資料,要件定義書を作成してXの承認を得ることが予定されていたとした。

争点(5)「仕様凍結合意」の意味

本件において,平成21年7月7日に仕様凍結するという合意があったことを前提に,その解釈に争いがあった。Yは,それ以降Xは追加要望ができないという意味であったとするのに対し,Xは,新規機能の開発要求はしないことに限られ,画面周りの要望は当然に許されると主張していた。この点については,次のように述べてYの解釈を採用した。

そもそも「仕様凍結」という用語自体、仕様を凍結する、すなわち、開発すべき仕様を確定し、以後これを変更しないことを意味するものと解するのが、その文言からして自然である。そして、システム開発が、画面や帳票等に関する軽微な変更であっても、他の部分に影響し、結果として開発の工数や費用が増大する可能性があるのであるから、「仕様凍結」後には、新たな機能の開発要求はもちろん、画面や帳票、更には操作性に関わる開発要求をすることは、基本的には許されないものと解するのが合理的である。

(略)

以上の事情を総合すると、本件仕様凍結合意とは、開発範囲を確定し、以後、Xは、Yに対し、新たな機能の開発要求はもちろん、画面や帳票、更には操作性に関わる開発要求も含め、一切の追加開発要望を出さないとの合意であったとみるのが相当である。

争点(6)本件プロジェクト頓挫についてのXとYの責任

システムの運用開始時期に間に合わなかったことはすでに認定されたとおりであるが,その原因は,要件定義,外部設計工程を予定どおりに終えられず,いったんは仕様凍結の合意がなされたものの,その後も171項目に及ぶカスタマイズ要望が出され(追加と認定されたのは92項目),リハーサルでは不具合が生じるなどの経緯が認定された。


責任の所在については,本判決の主要部分に当たるので少々長く引用する。

以上の経緯に鑑みると、本件プロジェクトが頓挫するに至った大きな要因は、開発工数がYの処理能力を超えていたという点にあるといえる。そして、その原因を本件仕様凍結合意後の事情に照らし考察すると、Xが同合意後も様々な開発要望を出したことがYの重い負担になっていたことが容易に推認される。(略)Xが本件仕様凍結合意の後に開発要望を出したことは、同合意に反するものといわざるを得ない。

しかしながら、そもそもシステムの開発過程においては、ユーザ側から、本来ベンダが開発義務を負うものではない項目について開発(カスタマイズ)が要望されることはしばしばみられる事態である。そうすると、システム開発の専門業者であるYとしては、納期までに本件システムが完成するよう、Xからの開発要望に対しても、自らの処理能力や予定された開発期間を勘案して、これを受け入れて開発するのか、代替案を示したり運用の変更を提案するなどしてXに開発要望を取り下げさせるなどの適切な対応を採って、開発の遅滞を招かないようにすべきであったというべきである。

このような観点からYの対応をみると、そもそも平成21年2月第4週までには要件定義書及び外部設計書を完成させることが予定されていたにもかかわらず、その完成は大幅に遅滞し、Yは同年7月7日の本件仕様凍結合意の時点でもこれらを完成させることができなかったものである。この原因についても、Xから種々の開発要望が出されたことが大きな要因になっているものと推認することができるものの、Yが本件プロジェクトの進捗を適切に管理すべき専門業者であることも踏まえると、要件定義書及び外部設計書の完成が遅滞したことについては、Yがその責任の大半を負うべきものである。

(略)

Yとしては、本来、本件仕様凍結合意後のXからの開発要望に対しては、同合意を理由に追加開発を拒絶するか、代替案を示したり運用の変更を提案するなどしてXに開発要望を取り下げさせる、あるいは専門部会にこの問題を上程して開発方針について協議するなどの適切な対応を採るべきであったのに、本件仕様凍結合意後の専門部会の議事録(乙2の9ないし14)に照らしても、Yがこのような対応を採ったことは何らうかがわれない。そうすると、Yは、納期までに本件システムを完成させることに十分な意識を向けないまま、Xの要望するままに追加開発を行い、その結果本件プロジェクトの遅滞を招いたものといわざるを得ない。

以上によれば、本件プロジェクトが頓挫した最大の原因は、システム開発の専門業者であるYが、Xの追加開発要望に翻弄され、本件プロジェクトの進捗を適切に管理することができなかったことにあるとみるのが相当である。
したがって、Yは、本件システムが完成しなかったことについて、債務不履行に基づく損害賠償責任を負う。

こうして,Y(ベンダ)の債務不履行責任を認めた。


続いて,Yのみが責任を負うわけではないとして,Xの責任について次のように述べた。

他方で、本件プロジェクトの遅滞については、Xにも責めに帰すべき事由があることは否定し難い。

(略。注:カスタマイズは最小限とすることが想定されていたが)Xが、本件プロジェクトの開始直後から、本来Yが開発義務を負わない分類1、2の項目についても多数の追加開発を要望したため、本件プロジェクトの遅滞を招いた面があることは否定できない。
加えて、前記5のとおり、平成21年7月7日の本件仕様凍結合意後においては、一切の開発要望を出すことができないにもかかわらず、Xからは、92項目にも及ぶ開発対象外の要望が出されたのであって、上記(2)のとおり、これが開発の遅延をもたらした一因であることは否定し難い。
また、前記7のとおり、Xは、マスタの移行に関して、既存マスタからデータを抽出した上で、これをマスタ登録シートに入力するなどの協力義務を負っていたにもかかわらず、多くのマスタについては、Xが作成しなかったため、Yが作成せざるを得なくなったことが認められる。(略)この点も本件プロジェクトの遅滞をもたらした一因であると認めるのが相当である。

そして、Xは、自らの開発要望等が本件プロジェクトの遅滞をもたらした一因であるにもかかわらず、Yが本件システムの完成に向けてなお尽力したいとの姿勢を見せていた平成22年4月、以後の一切の協力を拒絶して、本件解除を行い、その完成の可能性を閉ざしたのである。

こうした一連の経緯に鑑みると、本件プロジェクトが頓挫したことについては、Xの協力が不十分であったこともその一因となっていることは否定できない。本件プロジェクトは、医療に関する大規模システム開発を目的とするものであって、その遂行に当たっては、情報システムの専門家であるYが中心的役割を果たすべきことはもちろんであるが、Xも医療の専門家としてこれに協力すべき義務があるというべきである。そして、一たび本件プロジェクトが頓挫してしまえば、Yとしては、その時点での成果物を他のプロジェクトに流用することも困難であると考えられるのであって、Xが十分な協力を行わず本件プロジェクトの遅滞を招いた上、本件解除によって本件プロジェクトを頓挫させたことについては、Xにも協力義務違反があったものとして、相応の責任があるというべきである(略)。

したがって、Xは、本件システムが完成しなかったことについて、債務不履行に基づく損害賠償責任を負う(略)。

このように,裁判所は,本件プロジェクトの頓挫については,XY双方に帰責事由があるとした。そのうえで,両社の責任割合について次のように述べた。

Yはシステム開発の専門業者であり、Xの要望に対しても適切に管理して本件プロジェクトを進めていくべき責任があったことからすると、Yが自らの処理能力を正確に見極めることのないまま、Xからの追加開発要望に応じたことについては、重い責任があるといわざるを得ない。

一方、Xは、本件プロジェクトが開始された直後から、本来Yが開発義務を負わない多数の項目について開発を要望し、前記6のとおり、本件仕様凍結合意後も開発対象外の92項目について追加開発を要望したものではあるが、その要望は、あくまでWG等の場においてX病院の医師や職員から出されたものにすぎず、少なくともYが平成21年12月に再度の納期延長を求めるまでは、Xが組織として、開発要望に応じてもらえなければ本件プロジェクトを進めることは認めないなどという強硬姿勢をとったり、Yの開発作業を妨害するなどして本件プロジェクトの進捗を妨げたりしたとは認められない。そうすると、Yとしては、Xからの開発要望に対しては、代替案や運用上の工夫による対処案を示すなどしてXの納得を得るか、それができないのであれば、追加開発はYの義務ではないことや、追加開発に応じていては予定どおりの稼働には間に合わないことを説明し、Xの要望を拒絶すべきであったのである。Yが平成22年1月4日の稼働開始に間に合わせるべく、Xとの関係悪化を回避するためXの追加開発要望に応じざるを得なかったという実情は理解できる面はあるものの、Yが上記のような毅然とした対応を採らず、開発要望に応じた結果、完成が遅滞したとしても、そのことをもってYが免責されるとはいえない。

以上の事情を総合考慮すると、本件プロジェクトが頓挫したことについては、Xに2割、Yに8割の責任があると認めるのが相当である。

争点(7)Xの損害額

XY間の契約では,違約金が徴収できる旨の規定があり,違約金の額は,「リース料金の総額から履行完了部分に相応する金額を控除した額の10分の1」と定められていた。そこで,「履行完了部分」の割合については,正確に認めるに足りる証拠はないとしつつ「民事訴訟法248条の趣旨に照らし」8割だとされた。


したがって,リース料金総額約24億円の8割相当については履行が完了している都市,その残額の10分の1,約4900万円が違約金だとされた。


そのほかに,Xが第三者との間で,本件システムの導入に合わせて調達したシステムの利用料相当額や,本件システムとのインタフェースのための改修費用に加え,逸失利益(フィルムレス化が遅れたことによるコスト削減機会の損失,電子カルテ導入遅れによるコスト削減機会の損失について約2.2億円を認めたことが興味深い。さらには,債務不履行による損害賠償請求であったものの「極めて専門性の高い紛争」であることを理由に,損害額の5%(約2200万円)の弁護士費用の賠償を認めた。


以上,全体でXの損害額は,約4.6億円(請求額は約19億円)とされ,その8割の約3.7億円がYの賠償すべき損害金だとされた。

争点(8)Yの損害額

Yには,本件システムが完成したとすればリース会社から得られたであろう代金等約23.7億円の損害を認め,そのうちYの過失割合8割を控除し,さらに損益相殺として約9000万円を控除し,結果として約3.8億円をXが賠償すべき損害額だと認定された。

若干のコメント

システム開発に関する紛争の裁判例の大部分が東京地裁で出されていますが,本件は,旭川地裁で出されたもので珍しい事例です。日経コンピュータ誌2016年10月13日号で取り上げられていました。


争点は多岐にわたるため,本文中では割愛しましたが,驚いたのは,171項目の追加要望が,開発対象内か外かという点について,ひとつひとつ裁判所が判断したことです。その判断部分だけで,判決文総文字数約15万字中,5万字を費やしており,両当事者も,裁判所も相当大変だったと思われます。そのほかにも,マスタの移行作業の役割分担についても丁寧な事実認定が行われているなど,訴訟提起から判決まで5年ほどの期間を要したのも頷けるところです。


本件では,近時注目されている「プロジェクトマネジメント義務」「協力義務」といった用語は用いられていないものの,それと同等の義務違反を認めたことと,それぞれに義務違反があったとして損害賠償責任を負わせたという点が注目されます。