ブログトップ 記事一覧 ログイン 無料ブログ開設

IT・システム判例メモ

2018-02-09

マイグレーションの失敗 東京地判平28.10.31(平23ワ10498)

複数の個別契約を順次締結しながら進められたAS/400からのマイグレーションプロジェクトが頓挫した場合におけるベンダの責任の範囲が争われた事例。
※なお,本件は控訴審判決(東京高判平29.12.13)も出ている*1。なお,原判決には更正決定も出ており,主文が変更されていると思われるが,その具体的内容は不明。


事案の概要


Y(ユーザ)は,いわゆるレガシーシステムである本件旧システムを利用していたが,これをJavaベースのオープン系システム(本件新システム)に刷新するため,X(ベンダ)に開発を委託した。予算は,物流・販売業務システムを含めた全体で25億円,最大でも30億円で,平成21年9月が稼働開始予定とされた。


平成19年9月3日にXY間で基本契約を締結し,同日,物流システムの開発を委託する旨の個別契約を締結した(代金7億7000万円)。Xは,当該個別契約に基づいて,物流システムを開発し,平成20年8月には,物流システムの運用が順次開始され,Yは,物流システムを利用して業務を行っている。YはXに対し,物流システム開発の代金のほか,本件新システムの開発にかかる費用として,平成20年3月までに,合計で約16億円支払った。


他方で,販売システムは,物流システムより遅れて協議を開始した。準備作業としての分析作業を実施したところ,Xは,Yに対し,平成20年5月に,販売システムの開発見積もりとして,約25億円を提示した。この見積はスクラッチ開発をベースとしたものであったが,当初予算を大幅に超過するとして協議したところ,Xは,マイグレーション及びリファクタリングによって販売システムを開発することを提案した。


この手法は,RPGで書かれた本件旧システムのコードを,コンバータを用いて機械的にJavaに変換し(マイグレーション),その見直しを行う(リファクタリング)という方法である。


販売システムの開発は,フェーズごとに個別契約を締結する方法で行われた。平成20年9月29日,販売システムの要件定義作業を行う個別契約(約2億6000万円)が締結された。Xは,平成21年3月31日までに要件定義作業の成果物を納入し,Yは,全額代金を支払った。


また,販売システムの開発を目的として「第1契約」(平成20年9月26日締結。代金合計約4億8000万円)が締結され,平成21年7月31日までに合計約4億1000万円が支払われた。


同じく,販売システムの開発を目的として「第2契約」(平成21年7月6日締結。代金合計約4億1000万円)が締結されたが,本契約に基づく代金は支払われていない。


さらに,会計パッケージソフト「SuperStream」のカスタマイズを目的とした「第3契約」(平成21年7月8日締結。代金合計約3000万円)が締結されたが,本契約に基づく代金は支払われていない。


さらに,販売システムの開発を目的とした「第4契約」(平成21年11月10日締結。代金合計約2000万円)が締結されたが,本契約に基づく代金は約600万円のみが支払われた。


平成21年7月には,XからYに対し,マイグレーションが計画どおりに進捗していないことが報告された。「第1契約」の納期である同年8月28日を過ぎても第1契約の成果物を完成させることができなかった。


同年9月以降も障害が発生している状況が続き,Xは,販売システムのサービスインを平成22年10月とする案を提示したが,Yはこれに同意しなかった。


Yは,外部機関を使用した調査の結果を踏まえて,平成21年12月に,Xに対して,物流システムは不合格であること,販売システムは「通常のJavaプログラミングでは考えられない」という評価が出たとして,作業の停止を求めた。


その後,Yは,日本IBM日本ユニシスに,販売システムの品質について診断を委託するなどしたが,マイグレーション作業の再開には至らなかった。


Xは,平成23年2月,第2契約から第4契約に基づく代金の支払いがなされていないとして,残代金合計約6000万円の支払いを求めるよう催告したが,Yは支払わなかったために,解除の意思表示をした。


他方で,Yも,平成23年4月,契約解除と原状回復請求と,債務不履行に基づく損害賠償請求をした。


XとYがそれぞれ相手方に対して以下の金額を請求した。

f:id:redips:20180209010406p:image

ここで取り上げる争点


1 XのYに対する契約解除に伴う損害賠償請求の可否
2 YのXに対する第1契約の解除に基づく原状回復請求等の可否
3 YのXに対する第8契約の解除に基づく原状回復請求の可否

裁判所の判断


まず,前提として,裁判所は,納期が延長する旨の合意は認められないこと,そして,平成21年11月末日の時点において,すでに平成22年3月末日までにマイグレーション作業を完成させることができない状態にあったと認めた(いずれもXの主張が退けられている。)。


これを踏まえて各争点の判断がなされることになった。

争点(1)XのYに対する契約解除に伴う損害賠償請求の可否

Yは,第2契約等に基づくXから請求されたハードウェア代金,SuperStreamのインストール代金などを支払っていなかった。Xは,第2契約から第4契約の代金不払を理由に,第1契約から第3契約を解除したが,このような解除が可能かどうかが論点となった。


裁判所は,一連の契約が密接な関係を有していることを考慮して次のように述べた。

XとYは,本件新システムの開発業務に関し,個別業務ごとに個別契約を締結することを前提に,その基本的取引条件を定めた本件基本契約を締結した上で,その個別契約として第1〜第4契約を締結したものであるところ,本件基本契約においては,本件解除条項2号により,正当な理由なく,期限内にその義務を履行する見込みがなくなったときには,本件基本契約若しくは個別契約の全部又は一部を解除することができるものとされている。本件解除条項は,その規定上,解除の対象とされる個別契約について特段の制約を設けているものではなく,少なくとも当該個別契約と密接な関連性を有する他の契約について上記の解除事由が発生し,当該個別契約についてもその本旨を実現することができないという関係にあると認められるときは,既に当該個別契約に基づく債務が履行済みであったとしても,当該個別契約を解除することができるものと解すべきである。そして,当事者の一方が本件解除条項により本件基本契約若しくは個別契約の全部又は一部を解除し得るという場合には,当該当事者は,いきなり契約の全部又は一部について解除権を行使することのほか,信義則上,解除権を行使することなく,解除事由が消失するまで当該契約に基づく自らの相手方当事者に対する債務の履行を拒むこともできるものと解するのが相当である



以上を踏まえ,第2契約から第4契約は,いずれも第1契約と密接な関連性を有し,第1契約の成果物が存在しなければ,その本旨を実現できない関係にあるとした。その結果,Yが,第1契約に基づくXの債務が社会通念上履行不能になっていたから,Yが信義則上,このことを理由としてXからの第2契約から第4契約に係る代金の請求を拒絶し得るとした(第4契約が準委任契約であり,一定期間の作業を履行していたとしても支払いを求めることはできないとしている。)。


よって,Yが,支払いを拒絶したことは違法ではないから,Xは第1契約から第3契約を解除することはできないとされた。したがって,Xの解除による損害賠償請求は理由がないとされた。


なお,問題となった販売システムに関するXの請求は退けられているが,物流システムに関する追加作業の請求(返品に関するシステムの変更作業等)は,別個の2つの契約が成立していたとして,約2200万円の限度で請求を認めた。


そのほかにも,商法512条に基づく請求の内容である物流システムのバーコード対応については,瑕疵修補であり,実証実験作業は,Xの履行不能の責を免れるための作業であるとして退けた。

争点(2)YのXに対する第1契約解除に関する請求

すでに述べたとおり平成21年11月30日時点において,Xが平成22年3月末日までにマイグレーション作業を完成させることができない状態にあったことから,Yによる第1契約の解除は有効であるとした。よって,支払済みの代金合計約4億1000万円の返還義務があるとした。


さらに加えて,解除に伴う損害賠償請求の範囲が問題となった。


まず,販売システム業務分析作業として支払われた630万円については,「上記業務分析作業が行われたからといって,Yにおいて,必ずXとの間で第1契約を始めとする販売システムの開発に係る個別契約を締結しなければならないという関係にあるものではない」として,上流工程である業務分析作業の委託料は,第1契約の成否や履行と関わりなく支出されたものであるから,第1契約の債務不履行と因果関係のある損害ではないとした。


続いて,本件旧システムの延命に係る費用が問題となった。裁判所は,遅くとも平成22年2月には,第1契約を解除して新しいベンダに販売システムの開発を委託できる状態にあったのだから,平成23年4月まで第1契約を解除しなかったのは,Yの判断によるものであって,解除をし得る状態にあったときから開発に要する期間である25か月分を超えるものについては相当因果関係のある損害ではないとした。Yの請求額約1億0700万円のうち,約3200万円についてのみ相当因果関係があるとした。


同様に,本件旧システムの保守費用相当額についても,解除しうる時期から25か月分について,少なくとも50%程度は免れたと考えられるとし,約1億1500万円について相当因果関係がある損害だとした。

争点(3)第8契約の解除に関する請求

第8契約はすでに完了した契約であったため,これが第1契約の履行不能によって解除が可能であるかどうかが争点となった。


しかし,すでに述べたとおり,「少なくとも当該個別契約と密接な関連性を有する他の契約について上記の解除事由が発生し,当該個別契約についてもその本旨を実現することができないという関係にあると認められるときは,既に当該個別契約に基づく債務が履行済みであったとしても,当該個別契約を解除することができる」と述べて,第8契約は,マイグレーション手法による販売システムの開発のための要件定義作業であるから,密接関連性があるとして,解除ができるとした(既払い金全額の約2億6300万円)。

結語

以上より,XのYに対する請求は,物流システムの仕様追加に関する請求として,約2200万円の限度で認め,YのXに対する請求は,第1契約,第8契約の既払い金の返還,本件旧システムの延命と保守費用として,合計で約7億9000万円の請求を認めた。

若干のコメント


最近,大規模なシステム開発訴訟の判決がちらほらとみられるようになりましたが,レガシーのリホスト,マイグレーションと呼ばれるタイプの大型訴訟の判決は初めて見たような気がします。マイグレーションとは,広義では基幹システムの移行を指すと思われますが,よく使われるのは,レガシー(ホスト,オフコン)からオープンシステム系への移行を意味します。


かつてダウンサイジングなどと呼ばれたときは,業務改革・改善を伴って,一からオープン系のシステムを企画,設計するという方法が採られていたと思われますが,期間・費用の問題から,ホストのプログラムを機械的にオープン系に変換するというツールを用いて,要するに「そのまま」移行するという方法を用いるときに「マイグレーション」と呼んでいるように思います。


Aという旧式の言語から,機械的にBという新しい言語に変換するだけなので,簡単なように思われますが,変換ツールは万能ではなく,また,そこを手直しするにも古いシステムのロジックを誰も理解していない状態なので,「現状維持」は想像以上に難度が高く,各所でトラブルになっているということを耳にします(実際にマイグレーショントラブルの相談は少なくありません。)。


本件でも,予算を縮減するためにマイグレーションを選択したが,想像以上に難航し,スクラッチで開発する以上の費用がかかる見込みになり,前に進めなくなったという事案でした。マイグレーションの場合,「現状維持」がベースなので,通常のシステム開発と違ってユーザの協力,主体的関与の割合が相対的に低く,失敗した場合にはベンダに帰責性があるというケースが多いのではないかと思われます*2


こういう事例を見ていると,何十年も使用してきたシステムを置き換えるというのは,ユーザにとって大変リスクのあることであり,それを引き受けるベンダのリスクも相当なものだといえます。


本件における判断で注目に値するところは,(1)多段階契約における契約解除の範囲,(2)旧システムの延命・保守延長費用が損害になるか否か,といったところでしょう。(1)に関しては,一定以上の規模のシステム開発では,複数の個別契約で構成されることが通常ですが,本件では,メインとなった個別契約の債務不履行により,履行済みである上流工程の契約解除も認めました。(2)に関しては,ホストを延命しなければならなくなったため,その合理的期間分の費用を損害として認めました。この点は,類似の事案に影響を与えるかもしれません。


なお,本文中で割愛した認定部分(平成21年11月30日時点での進捗状況)に関して,Xが,SOFTICの紛争解決センターによる単独判定手続を申し立てたことが記載されています。この手続は,

単独の申立人が申し立てた申立事項に関し中立の第三者(単独判定人)が、判定を行う手続です。判定結果に拘束力はありませんが、ソフトウェア分野について単独判定人がもつ経験や知見の専門性に基づく判断を得て、内部的な検討の資料としたり、その判断を訴訟において援用するといったことも考えられます。


というものです*3。この結果が,一定の限度でXの主張に沿うものではあったのですが,

これは,Xのみが参加し,Xから提出された申立書,主張書面,証拠書類,期日における口頭での主張に基づいて審理された手続によるものであり,当裁判所の上記認定判断とは,その主張,証拠,手続のほか,前提とする事実関係をも異にするものであるから,その単独判定合議体が中立性,専門性を備えているとしても,当裁判所の上記認定判断を覆し得るものではない。


とされたことが注目されます。当該手続は,一定の主張・証拠の限度で判断するもので,一種の私鑑定にとどまりますから,裁判所の判断を(法的にはもちろん,事実上も)拘束するものではないということに留意しなければなりません。

*1http://www.happinet.co.jp/ir/news/pdf/2018_3/20171213sosyo.pdf

*2:よく知られているように,新システムを開発するケースでは,ベンダ,ユーザの双方の協力関係が必要であり,失敗した場合に直ちにベンダの責任だといえないケースが相当割合であります。

*3http://www.softic.or.jp/adr/index.htm#2

2018-01-08

データ移行に関するベンダの責任 東京地判平28.11.30(平25ワ9026)

データ移行の不整合の責任の所在等が争われた事例(そのほかにも多数の争点あり)。


事案の概要


ユーザX(建築現場の足場等の資材リース業)は,現行システム(本件旧システム)を運用していたが,リース物件が滅失した場合等においてデータの管理が適切に処理できず,データ不整合が生じていた。Xは,これを解消するためのシステムの開発を希望していた。


平成23年6月23日に,XY間で,本件新システムの開発業務,本件新システムへのデータ移行業務棟を対象とする本件請負契約(報酬額2310万円)が締結された。請負報酬は,714万円の残額を除いて支払われた。また,XY間では,ソフトウェア,ハードウェアの本件売買契約を締結し,物件の引き渡しとともに,代金全額(367万5000円)が支払われた。


当初予定されいてた本番稼働時期の平成24年4月を過ぎても,前記のデータ不整合が多数存在したため,本件新システムは正常に稼働しなかった。


Xは,本件請負契約におけるYの債務に履行遅滞があり,それを理由に請負契約と関連する売買契約を解除した等として,原状回復請求権,履行遅滞による損害賠償請求権または不法行為による損害賠償請求権に基づいて,支払済みの請負報酬及び売買代金相当の合計約2000万円の支払い等を求めた事案。

ここで取り上げる争点


  • 争点(1)本件請負契約に基づく債務のうち,データ移行債務の履行遅滞の有無
  • 争点(2)履行遅滞についてのYの帰責性

※Yは,データ移行に関するXの情報提供と,テスト工程における追加開発要望によって,遅滞を招いたとして,帰責性を否定していた。

  • 争点(3)売買契約の解除の可否
  • 争点(4)弁護士費用相当額の請求の可否


裁判所の判断


争点(1)データ移行の履行遅滞

データ移行について,両当事者がどこまで義務を負っているのかが争われていたため,少々長いが,Yの義務について認定した個所を引用する。

まず,本件請負契約に基づくデータの移行業務としてYが負担する債務の内容について検討するに,(略)Yは,Xから,本件請負契約を締結した平成23年6月23日までの打合せにおいて,本件旧システムの機能や現在の運用状況等について説明を受け,本件旧システム上,データ不整合があることを認識し,それを前提に,Xとの間で,中間ファイルを設けることなく,請求書等の各帳票の訂正,削除等を容易に行い得る新システムを構築するとともに,Xの保有するデータを新システムへ移行し,新システムで使用することができる状態とする業務を請け負う旨の本件請負契約を締結したものであり,データの移行方式及びツールの検討,移行方式設計書の作成,移行ツールの製造(移行に必要なプログラム開発),本件旧システム上のデータを抽出し,本件新システムへデータを投入する作業については,Yの担当又はYが主体となって進めることが合意されたものであることが認められる。また,Yは,本件請負契約の締結後も,(略)Xの保有するデータを新システムへ移行し,新システムで使用することができる状態にするためには,これらのデータ不整合を解消する必要があると考えていたことが認められる。

これらの事情に照らせば,Yは,本件請負契約に基づくデータの移行業務として,本件旧システム上のデータを本件新システムに単に移行させることにとどまらず,移行したデータにより本件新システムを稼働させる債務,具体的には,データの移行業務を開始する前に,本件旧システム上の移行の対象となるデータを調査・分析して,データの性質や状態を把握し,そのデータが本件新システムに移行された後,その稼働の障害となるかを検討し,障害となる場合には,いつ,いかなる方法で当該データを修正するかなどについて決定した上で,データの移行業務(移行設計,移行ツールの開発,データの移行)に臨み,最終的には,本件旧システムから移行したデータにより本件新システムを稼働させる債務を負担していたものと認めるのが相当であり,本件においては,データ移行に当たり,データ不整合を是正・解消すべき義務を負うものというべきである。



しかし,本件請負契約に基づく債務の履行期である平成24年4月23日が経過した後の同年9月6日に,Yは,データ移行作業の工程を完了させたものの,データ不整合が障害となって本件新システムが稼働しなかったことが認定され,この点について履行遅滞があると認められた。

争点(2)Yの帰責性

データ移行には,ユーザの協力が不可欠であることを前提に,Yは,Xにおいて協力義務違反があったため,履行遅滞について帰責性がないと主張していた。この点についても,少々長めに引用する。

一般に,ユーザーが業務上使用するコンピューター・ソフトウェアのシステムの開発をベンダーに発注・委託する場合において,ベンダーがコンピューターシステムの専門家としてユーザーの要求に応えるシステムを構築する責任を負うことは当然であるが,ユーザーが業務等に関する情報提供を適切に行わなければ,そのようなシステムの構築を望めないことから,ユーザーは,ベンダーによるシステム開発について,ベンダーからの問合せに対し正確に情報を提供するなどの協力をすべき義務を負うものと解するのが相当である。本件においても,Xがそのような協力義務を負うことについては,否定されるものではない。

しかしながら,前記認定事実によれば,Xには,コンピューターシステムについて十分な専門的知見を有する者が在籍しておらず,他方,Yは,その専門的知見に基づきコンピューターシステムの開発業務を行う者であり,Xに対してヒアリングを実施するなどの過程において,Xがコンピューターシステムについて専門的知見を十分有していないことを認識していたものと認められるのであり,このような事実関係の下では,Xは,Yから求められる態様で協力をするということを超えて,自ら積極的にYが必要とする情報をあらかじめ網羅的に提供するという態様で協力をすべき義務まで負うものではないというべきである。

本件においては,前記認定事実によれば,Xは,本件請負契約の締結の前後を通じ,Yに対して,業務上使用していた本件旧システムの機能や運用について説明し,本件旧システム上,データ不整合が存在することを告げていたものであり,Yも,Xの説明により,本件旧システム上,データ不整合が存在すること自体を認識していたものである。そして,Xは,本件旧システムにおけるデータ不整合の件数やその理由について,これをYに伝えたものではないが,上記のデータ不整合が日常的な業務の中で必然的に発生し,あるいは,発生し得るものであることについては,本件請負契約の締結までの間における本件システムの運用に関する説明の中でYに伝えられていたものと認められる。また,Xは,平成23年6月の本件請負契約が締結された前後には,本件旧システムのサーバ内のデータのバックアップデータをYに提供しているのであり,Yとしては,この提供されたデータを調査・分析することにより,本件旧システムにおけるデータ不整合の件数やその理由について把握し得ることがうかがわれるところである。そして,仮に,データの提供だけではデータ不整合の件数や理由が十分に明らかにならないというのであれば,コンピューターシステム開発について専門的な知見を有するYにおいて,更にXに問合せをするなどして,技術的に必要な情報を得るようにすることが考えられてしかるべきであるところ,Yが本件請負契約の締結時及びその後の本件新システムのテストの段階において,Xに対し,本件旧システムのバックアップデータ以外に,更に技術的な情報の提供を求めたことをうかがわせる証拠はない。さらに,具体的にどのような情報が提供されればデータ不整合の件数やその理由について把握し得るものであったのかについては,Y自らこれを特定して主張し得るに至っていない。

これらの事情によれば,Xが本件旧システムにおけるデータの状態を告知することについて,不十分なところがあったとは認められないというべきである。



よって,Xの協力について不十分なところがあったとは認められず,Yに帰責事由がなかったとはいえないとされた。


さらに,Yは,Xがテスト工程の段階でも追加の要望を出し,すべてに応じないと検収しないとの態度を示したため,開発業務が遅滞したと主張していた。この点についても裁判所は,「すべての要望に応じなければ検収をしない」とXが伝えたことを認めつつもXの帰責性を否定した。

Yは,コンピューターシステムの開発について専門的な知見を有する者として,本件新システムの開発業務を請け負ったのであり,本件請負契約上,本件新システムを開発することと併せて,その開発工程全体の進捗状況を管理し,その工程に沿った開発作業を進めるとともに,システムについて専門的知識を有しないユーザーの作業や関与の在り方についても適切に管理する義務を負っていたものというべきである。

そして,Yが主張するように,本件新システムのテスト工程の段階において出されたXの要望に係る作業量がかなり多いものであったというのであれば,Yとしては,上記の義務に基づき,本件請負契約に定める本件新システムの開発工程を予定どおり進めるべく,Xに対して,要望に対応した場合には予定された開発工程に遅滞が生じるおそれがあることを伝え,あるいは,要望に対応することを前提に開発工程の見直しを図るなど,開発工程及びXの関与の在り方を適切に管理すべきであったものというべきである。この点は,XがYに対して強い態度で要望に応じるよう迫ったものであったとしても,異なるものではなく,Yとしては,少なくとも,要望に対応した場合の開発業務の完成遅延に係る具体的見通しをXに説明するなどの対応を執るべきであったと解するのが相当である。

しかるに,YがXに対し,そのような対応を執ったことを認めるに足りる的確な証拠はなく,Yは,Xの要望に対し,漫然とこれに応じ,開発作業を遅滞させたものであるといわざるを得ない。


以上より,裁判所は,Yには履行遅滞に基づく解除に伴う原状回復請求として,支払済みの請負代金の返還を認めた。

争点(3)売買契約の解除

契約としては開発業務を対象とする請負契約と,ハードウェア等を対象とする売買契約は,別のものであり,売買契約自体には債務不履行はない。しかし,最判平8.11.12民集50巻10号2673号を「参照」し,裁判所は,売買契約の解除をも認め,支払済の代金の返還を認めた。

Xは,本件各売買契約を締結して,本件新システムを動作させるためのソフトウェア及びハードウェアを購入したものであるところ,本件各売買契約の目的とするところは,本件新システムを開発して稼働させることを目的とする本件請負契約と密接に関連し,社会通念上,本件請負契約と本件各売買契約のいずれかが履行されるだけでは,本件新システムの稼働という目的が全体として達成されないと認められる。したがって,Xは,本件請負契約の履行遅滞を理由に,本件請負契約と併せて本件各売買契約をも解除することができるものというべきである。



争点(4)弁護士費用

一般に,不法行為に基づく損害賠償請求の場合は,認容額の10%程度の弁護士費用は,不法行為と相当因果関係に立つ損害であるとされることが多い。他方で,債務不履行責任の場合には,なかなか弁護士費用についての損害賠償は認められていない。


しかし,本件では,最判平44.2.27民集23巻2号441頁を参照し,「本件訴訟の追行には,こにゅーたーシステムの開発に係る専門的な知見を要するものであり,その事案の難易,請求額,その他諸般の事情を考慮すれば,弁護士費用190万円について,Yの債務不履行と相当因果関係に立つ」として認めた。


結果的にXの金銭請求についてはすべて認容された。


なお,Yは,反訴として,請負契約に基づく報酬残額を請求していたが棄却された。

若干のコメント


データ移行は,システム開発紛争の争点になりやすいところですが,本件では,もともと旧システムにおいてデータ不整合が問題になっていたこと,これを解消するためのシステム開発であることが事前に明らかになっていて,かつ,データ移行の役割分担について,ベンダが多くを担っていたことから,ベンダの債務不履行責任が認められました。


本件は,ベンダ,ユーザともに中小規模の企業で,特にユーザは,内部にシステムの専門家がいないという,よくありがちな状況だったのですが,裁判所が繰り返し「ユーザは素人」「ベンダは専門家」であるような表現を用いていたことが気になります。仮に,ユーザが素人であるからなお一層,ベンダの注意義務の程度が高くなるのだとすれば,中小規模のベンダのほうが,素人であるユーザと取引する場面が多いため,大手ベンダ以上に,高度な注意義務を負わされる(責任範囲が広くなる)ことになってしまいそうです。さらには,ユーザは自衛策として,知識,スキルを身につけたとしたら,逆にベンダの注意義務の程度が下がり,保護に欠けることになってしまわないでしょうか。


本件では,「プロジェクト・マネジメント義務」という用語は当事者の主張にしか登場せず,裁判所の判断の箇所には見られませんでしたが,役割分担や,追加仕様に関する争点があり,プロジェクト・マネジメントが争点になった事例の一つに挙げられるでしょう。


なお,その他の本件の特徴として,請負契約の債務不履行を理由として,売買契約の解除をも認めたことや,債務不履行責任において弁護士費用の賠償をも認めたことも注目されます。

2017-09-29

ユーザの協力義務違反 札幌高判平29.8.31(平28ネ189)

システム開発頓挫の責任が,仕様凍結の合意後も大量の追加仕様を要求し続けたなど,ユーザにある一方で,ベンダは,リスクの説明をするなど,PM義務の履行をしていたとされた事例。旭川地判平28.3.29(http://d.hatena.ne.jp/redips+law/20161103/1478099168)の控訴審判決。


事案の概要


ユーザ(医療法人)Xは,ベンダYに対し,病院情報管理システム(本件システム)の導入を依頼したが,納期までに本件システムの完成及び引渡しが得られなかったために,債務不履行に基づく損害賠償請求をした。


他方,Yは,Yには帰責性がなく,Xに協力義務違反,受領拒絶があったとして,債務不履行に基づく損害賠償を請求した。


原審(旭川地判平成28年3月29日)では,Xの追加開発要望に翻弄されたとはいえ,Yがプロジェクトを適切に管理することができなかったことによって頓挫したとし,Yの債務不履行を認めた。そして,その損害が約4.6億円であり,その8割(約3.7億円)がYの賠償すべき損害だとした。


一方で,プロジェクトの頓挫の責任はYのみによるものではなく,Xの協力が不十分であったことも一因となっていると述べて,Xの協力義務違反を認めた。そして,Yの損害が約23.7億円あり,そのうちYの過失割合8割を相殺するなどして,約3.8億円の賠償を認めた。



双方控訴。

若干のコメント


通常,当ブログでは,裁判所の判断を示したのちにコメントを書いていますが,判決の紹介がかなり長くなったため,ここで簡単にコメントを記しておきます。


一審判決を読んだとき,仕様凍結合意後も要求を出し続けたのはユーザなのに,それを取り下げさせたりしなかったなど,ベンダがユーザの要望に翻弄されて適切に管理しなかったことが頓挫の原因であるとされていて,ずいぶんとベンダに厳しい判決だなと思いました。


ところが,控訴審判決では,同じプロジェクトの話なのか疑いたくなるほど正反対の結論となっています。


重視されたのは,ベンダは,繰り返し,追加開発要望の多くは仕様外であること,これらの要望に対応すると納期に間に合わなくなることを説明し,さらに仕様凍結の合意にまで取り付けたという点です。


本件では,ユーザの現場と,システム担当との間における意思疎通が十分ではなかったと思われます。もちろん,一般にそういうことは起こりがちなので,ベンダも意思決定支援をする必要があるでしょうが,第一次的にはユーザ内部の問題であり,それが理由でプロジェクトが頓挫した場合には,ユーザに責任が生じるということを示した例として実務への影響は大きいでしょう。


なお,報道*1によれば,Xは上告したようですが,この種の事案が上告審で覆ることは容易ではないでしょう。


以下では,控訴審判決を少し詳しめに紹介します。

ここで取り上げる争点


原審の争点とほぼ同様であるが,控訴審の構成に沿って以下の順に取り上げる。

(1)本件システムの稼働を延期するとの合意があったか
(2)本件システムは完成したのか
(3)本件契約上のYの義務の範囲
(3−1)システムのカスタマイズ範囲
(3−2)要件定義書及び外部設計書の提出義務はあるか
(4)本件仕様凍結合意の意味
(5)171項目の追加要望の開発対象該当性
(6)マスタ抽出義務の所在及び違反
(7)本件プロジェクト頓挫についてのX,Yの責任

裁判所の判断


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

この点は,特に詳細な判断が示されることはなく,原審判断が維持されて,延期するという明示または黙示の合意はないとされた。

争点(2)本件システムは完成したのか

原審では,完成を否定している。当審では,完成判断基準として,次のように述べた。

システム開発では,初期段階で軽微なバグが発生するのは技術的に不可避であり,納品後のバグ対応も織り込み済みであることに照らすと,バグ等が存在しても,システムを使用して業務を遂行することが可能であり,その後の対応で順次解消される類のものであれば,仕事が完成したと認定すべきである。


そして,裁判所は当初の納期ではなく,遅くとも契約解除時(平成22年4月26日)にはすべて完成していると述べた。その根拠として挙げられていた事情は以下のとおりである。

  • プレリハーサルでは不具合が指摘されたが,すべて修復,対応が完了するなどして,外来リハーサルが実施できる程度に至っていたこと
  • 総合試験が実施され,47個の問題が発生したが,Yは平成22年1月8日までに対応を完了し,総合試験を実施したすべての項目について合格と判定されるに至っていたこと
  • 平成22年1月5日に配布された「技術仕様書未実施リスト」には本件仕様凍結合意の時点で6486項目の機能のうち,57項目が開発未了とされていたが,同年3月16日までには,Xの事情で保留した1項目を除いて開発が完了させたこと
  • 同年3月16日にYが提示した「プロジェクト再開に向けてのご提案」では,プログラムの不具合112項目のうち,110項目の対応が完了しており,残りの件も完了見込みであることあるいは開発対象外の要望であったこと
  • 同年6月25日までに作成された「完成証明資料」によれば,Xの協力が必要な1項目を除いて本件システムが完成していたことが認められること


なお,同種の事件でもよくある話だが,ベンダのプロジェクトリーダが「本件システムの不具合や開発の遅れを認め,謝罪する旨の発言」をしたことが認定されているが,この点については,

これらは,追加開発要望が一審原告から大量に出され,その相当数について対応を余儀なくされ,本件システム開発が遅れていたYによる謝罪であって,その発言が全てYの真実の認識に基づくものであったと考えるのは相当ではない。


と庇っている。その他のXの反論も退けて,システムの完成を認めた(原審判決からの変更点)。

争点(3)Yの契約上の義務の範囲

【本件システムのカスタマイズ範囲に関する義務の範囲】


この点は原審判決の結論が維持されている。その過程の判示部分に以下のような記載がある。

現行の運用の維持を最優先して,一から新たに開発するオーダーメイド型の開発を発注するのか,運用の見直しを前提として,パッケージをベースにした開発を発注することにより経費の削減を図るのかは,まさに発注者であるXの判断事項であり,Xにおいて後者を選択した以上は,カスタマイズの要望ができる範囲が限定されたとしても,やむを得ないことというべきである。この点,本件の紛争の根本的な原因は,Xが,現行の運用の維持に固執する現場の医師らの要望を十分に反映させないまま本件要求仕様書等を取りまとめて本件契約を締結したこと,にもかかわらず,その後,本件要求仕様書等並びにこれを踏まえて作成された本件技術仕様書の記載を無視して出される現場の医師らの追加開発要望を抑えるための努力を放棄し,Yがその対応に当たらざるを得なかったことにあったと考えられる。


また,Xが主張する開発項目について,運用確認,仕様検討していたという事実が,開発対象にすることを意味するものではないとした。


【要件定義書及び外部設計書の提出義務】

この点は原審では,基本設計資料,要件定義書を作成してXの承認を得る義務があるとされていた。当審では,その一部についてのみYにその義務があり,それを怠ったというように変更されている(個別の事情に依るところが大きいため,ここでは割愛する。)。

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

平成21年7月7日にXY間で,仕様を凍結するという合意があったが,この解釈が争われていた。原審では,Yの解釈,すなわち,新たな機能の開発要求はもちろん,画面や帳票,操作性も含めて一切の追加開発要望を出さないという合意であるとした。この点も原審判決が維持された。


当審で,Xは,本件仕様凍結合意後も,Yから仕様の確認を求めていたという事実は,変更の余地があることを前提とするものであったと主張していたが,この点について裁判所は次のように述べた。

ベンダにおいて,開発したシステムの内容の確認をユーザに求めることは当然のことであって,だからといって,ユーザからなされる追加開発要望を受け入れることをベンダが許容していたということはできない。


さらに,Xは,一切の追加開発要望が出せないということをXは認識しておらず,そうなのであれば,Yが適切に説明しなかったのはYの責任だと主張した。

X自身,本件仕様凍結合意が今後一切の追加開発要望を出さないという合意であると認識していたことは,上記ウや,Xによる追加開発要望のために本件システム開発が遅れており,開発対象に取り込むべき開発要望の精査を行ってきた結果本件仕様凍結合意に至った経緯などに照らして明らかである。もっとも,現場の医師らには,そのような認識が必ずしも浸透していたとはいえず,これが本件の紛争の根本的な原因の一つとなっていたことは,前記4(1)イ(ア)のとおりであるが,これは,Yではなく,Xの責任というべきである。



争点(5)171項目の追加開発該当性

原審では171項目すべてについてつぶさに開発対象内であったかどうかが判示された。そもそも,これらの項目が開発対象内であることについてXが立証責任を負うのか,開発対象外であることについてYが立証責任を負うのかということから問題となった。

171項目の追加要望は,本件システムの引渡しが履行期になされなかったこと(債務不履行)についての帰責性がなく,また,Xに協力義務違反が認められる根拠の一つとしてYが主張するものであるから,これらの開発要望が出されたこと及びそれが開発対象外の開発要望であることについてYが主張立証責任を負うものというべきであり,これに反するYの主張は採用できない。



なお,判決文では171項目それぞれについて,開発対象外であるかどうか,再度認定がなされているが,ここでは割愛する。

争点(6)Xのマスタ抽出義務の有無


Xが,薬品や検査項目などのマスタデータを作成(あるいは現行システムからの抽出)義務があったかどうかが争われていた。


データ移行はシステム開発におけるトラブルで頻出する。システムの稼働に不可欠でありながらも,目立たない作業であるため,作業分担やスケジュールが曖昧になりがちなタスクだからだ。


控訴審でも,Xがマスタ抽出義務を怠ったと認定されている。判決文では,要求仕様書,技術仕様書,プロジェクト計画書などの資料から丁寧に事実認定し,Yが一部マスタの抽出業務を行ったとしつつも,

しかしながら,これらは,Xがその義務であるマスタの抽出作業を行わず,本件プロジェクトが停滞する中で,やむなくYがその一部の作業を代行したものであったと認められ,これらの事実があったからといって,Yが「継続的な設定変更・確認が必要なマスタ」の抽出義務を負っていたということはできない。

そして,このようにYがXに代わってマスタの抽出作業を行うに当たっても,Xは,既存システムのマスタの調査及び分析に必要な協力(NECへの協力依頼等)を行わず,このため,Yの負担が増大したものと認められる。


と,Xに厳しい認定をした。このマスタ抽出義務に関しては,Yにおいてもその支援をする義務があるとされていたが,「Yは,繰り返し,Xによるマスタの抽出作業が遅れている旨を指摘して,早期の対応を求めていたのに,Xが抽出作業を怠っていたものである」として,Y自身の支援義務には不履行がなかったとされている。

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

この争点が本件のハイライトとなる。Xの債務不履行(協力義務)が認定される箇所を少々長いが引用する。

システム開発はベンダであるYの努力のみによってなし得るものではなく,ユーザであるXの協力が必要不可欠であって,Xも,Yによる本件システム開発に協力すべき義務を負う(Xも,一般論として上記のような協力義務を有していることは認めているところである。)。そして,この協力義務は,本件契約上Xの責任とされていたもの(マスタの抽出作業など)を円滑に行うというような作為義務はもちろん,本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し,Yにその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。

しかるに,前記6などのとおり,Xが本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し,Yがこれに対応せざるを得なかったことから,本件システム開発が遅延した。また,前記7のとおり,Xがマスタの抽出義務を負っていたにもかかわらず,これを懈怠し,Xの協力が得られないままYが代行せざるを得なくなったことも,本件プロジェクトが遅延した理由の一つになっている。

さらに,Xは,Xの追加開発要望に基づいて現行システムの備える機能を最大限取り込むことを要求しながら,そのために必要な現行システムの情報(基本設計書等)を十分に提供せず,また,YがXに代わってマスタの抽出作業を行うに際しても,NECに必要な協力依頼を行うことを怠った。

そして,前記3のとおり,本件システムは,遅くとも平成22年4月26日までには,Xの協力が得られずに保留せざるを得なかった1項目を除き,全て完成していたにも関わらず,Xは,独自の見解から本件システムの開発がYの責任で遅延したとして,一方的に本件解除をした。

上記のとおり,Xには,本件契約上の協力義務違反(債務不履行)が認められる。



続いて,YにPM義務違反があったというXの主張について検討された。

Yは,平成21年3月4日以降,専門部会等において,繰り返し,Xによる追加開発要望の多くは仕様外のものであること,Yとしては,これらの追加開発要望に対応するのは難しく,同年9月24日(本件原契約におけるリース開始日)に間に合わなくなることを説明した。
そして,Yは,同年7月7日,Xによる625項目の追加開発要望を受け入れる(本件追加開発合意)一方で,以後は,新たな機能の開発要望はもちろん,画面や帳票,操作性に関わるものも含め,一切の追加開発要望を出さないという合意(本件仕様凍結合意)を取り付けたものである。

このように,Yは,プロジェクトマネジメント義務の履行として,追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で,追加開発要望の拒否(本件仕様凍結合意)を含めた然るべき対応をしたものと認められる。
 これを越えて,Yにおいて,納期を守るためには更なる追加開発要望をしないよう注文者(X)を説得したり,Xによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず,Yにプロジェクトマネジメント義務の違反があったとは認められない。

したがって,Yには債務不履行(履行遅滞)について帰責性がなく,また,Xの債務不履行について過失相殺の対象となるべき過失の存在も認められない



以上のとおり,X(ユーザ)の債務不履行を認める一方で,Y(ベンダ)の債務不履行を認めなかった。さらには,Y側の過失相殺も認めなかった。


そして,本件システムが完成し,リースが開始されれば得られたであろう金額(約15億円)から,一部の損益相殺(物品の転用)をして,約14億円の損害賠償を認めた。

*1:ITpro「失敗の全責任はユーザー側に,旭川医大とNTT東の裁判で逆転判決」http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/

2017-09-10

カスタマイズ範囲の画定と検収協力義務 東京高判平27.6.11(平26ネ6015)

パッケージベースの開発において,カスタマイズの範囲が争われるとともに,検収手続が完了していないながらもシステムの完成が認められた事例。


事案の概要


ベンダXは,ユーザYとの間で,販売管理システム(本件システム)の開発を目的として,平成15年3月25日にシステム開発基本契約(本件基本契約)を締結した。そのサービス内容には,要件定義,設計,構築,運用準備・移行サービスが含まれていた。


XY間では,要件定義(279万3500円),設計(301万0200円),構築(1512万8400円),運用準備(306万7900円)の個別契約が締結された(その他の契約も締結されているが説明を割愛する。)。


Xは,本件システムを構築し,平成16年2月頃に本件システムの説明会を行ったが,Yから不具合が指摘された。XY間ではYの指摘に対応するための追加カスタマイズ契約(500万円)が締結された。しかし,その後,Xが作業を進め,Yに対して検収を求めたものの,本件システムの検収には至らなかった。


そこで,Xは,Yに対し,契約締結分の2526万0410円に加え,追加要望対応の費用,6663万3000円等を加えた9232万0300円の支払いを求めたのに対し,Yは,反訴請求として,Xの債務不履行があったとして,約4000万円の損害賠償を請求した。


原審(東京地判平26.10.30・平23ワ31512*1)は,ユーザの検収協力は不可欠であって,ユーザが検収を協力しない場合には,ベンダ側で必要な作業を終えていれば完成を認めてよいなどと述べて,本件システムの仕様を完成させていたものと推認できるとし,既契約締結分の2526万0410円について請求を認容し,Yからの反訴請求を棄却した。

ここで取り上げる争点


(1)カスタマイズ範囲
(2)本件システムの完成の有無及びYの債務不履行の有無

裁判所の判断


カスタマイズ範囲について

「完成」の判断の前提には,対象システムの「仕様」が問題となる。Yは,提案書において「現状の機能を網羅すること」などの記載があることを根拠に「要件定義が確定しなかった以上は,現行システムと同等の機能を備えたシステム」が仕様であるなどと主張していた。


パッケージベースでの導入では,どこまでカスタマイズするのかということが問題となる。ベンダは,当然,カスタマイズ機能一覧といった書面で書かれたものに限られると主張するであろうが,ユーザとしては,当該パッケージにはどのような機能が備わっているのかわからないため,そこに「カスタマイズ機能一覧」と合わせ見ても,それが必要十分なものかどうかわからないため,「現行維持」といった抽象的な要件を頼りにせざるを得ないところである。


この点について,裁判所は次のように述べた。少々長いが引用する。

本件においては、Xが、既存のパッケージソフトをカスタマイズして、システムの開発を行うこととされていたものである。既存のパッケージソフトを利用する方法は、フルスクラッチと比べて開発費用と工期を抑制するメリットがあるが、このような開発手法の下では、一般に、パッケージソフトには業務遂行に必要な基本的な機能が装備されているから、これを基本にしてシステムを構築するのが原則であり、それでも賄えないユーザーに特有な仕様についてはカスタマイズにより対応するものである。パッケージソフトにカスタマイズを加えることは、その分工数が増えることになるから、費用、開発期間等のメリットを生かすために、できるだけこれを少なくするほうが望ましい。仮に、ユーザーにおいて既に採用されているシステムと全く合致するような機能及び業務処理手続を、新たにシステムに導入しようとすれば、必要なカスタマイズ工数が膨大になるとともに、仮にこれを実現した場合であっても、将来的な環境や条件の変化に対応したメンテナンスが困難になるという問題が生じる。そのため、開発にあたっての一般的な考え方としては、基本的には、カスタマイズを最小限にし、むしろ業務をパッケージに合わせるようにすることが重要であるとされている。
(略)
以上のような、パッケージソフトを利用してカスタマイズを行う方法によりシステム開発をする際の問題状況からすれば、当事者の合意は、要件定義書等の成果物に記載のあるものについてはこれによって認めることとし、こうした成果物に記載のないものについては、特段の事情のない限り、パッケージソフトの仕様によっているものと考えるのが合理的であるといえる。


すなわち,「成果物に記載のないものについては,特段の事情のない限り」パッケージソフトの仕様どおりでよい,としている。さらに,裁判所は,次のように述べてYの主張を退けた。

Yは、本件システム開発を行うこととなった動機となる事情や、本件システム確認書や本件提案書に「現システムの業務内容を継承」、「現状の機能を網羅する」という記載があることを指摘して、現行システムと同等の機能を具備するものを開発する合意をしたとも主張するが、まず「現行システムと同等」とは、具体的にどのような水準・内容のものをいうのかが、そもそも明らかとならないし、上記指摘に係る事情についても、パッケージソフトの仕様によりながら、これに運用や業務方法の見直しも併用して、新しいシステムを活用して今後の業務を行っていくことも考えられるから、これらから、現行システムと同等の機能を具備するものを開発する合意が認められることにはならないというべきである。


本件システムの完成の有無及びYの債務不履行の有無

この点については,原審の判断が維持されているため,以下の点は原判決からの引用とする。

請負型のソフトウェア開発契約においては、原則として、構築したソフトウェアについてユーザーによる検収作業が行われ、検収が完了することにより、仕事が完成したというべきであるが、検収のためにはユーザーの協力が不可欠であり、ユーザーが検収に協力をしないために、検収を完了できない場合には、ベンダー側で検収前の作業を全て完了し、構築したソフトウェアが仕様確定作業により確定された仕様を満たす状態で、ユーザーにおいて検収できる状態にしていれば、請負の仕事の完成を認めるのが相当である。

また、ソフトウェア開発においては、初期段階で軽微なバグが発生するのは技術的に不可避であり、実務的にも納品後のバグ対応も織り込み済みであることに照らせば、バグが存在したとしても順次解消できる類のものであれば、瑕疵担保責任の問題として考えるべきであり、当該ソフトウェアの完成の認定を妨げるものではない。


そして,遅くとも平成19年2月のテスト稼働時点*2では,本件システムは完成させていたことが推認できるとされた。


これに対し,Yは,多数の不具合があると主張していたことから,これらが完成を妨げる特段の事情に該当するかどうかが検討された。Yが主張する不具合には,(a)本件システムに生じているバグと,(b)本件システムが備えているべき現行システムの機能の欠如があった。


これらの詳細については判例DBでは省略されているが,(a)については,平成19年2月のテスト稼働時点以前に生じていたバグであるかどうか,(b)については,現行システムが備えている機能かどうかではなく,確定仕様を具備しているかどうかという観点で判断し,いずれもYの主張は退けられた。


以上を踏まえて,

以上によれば、遅くとも、平成一九年二月のテスト稼働終了時には、本件システムは完成していたものということができる。そうとすると、前記のとおり、ソフトウェア開発においては、構築したソフトウェアの検収作業は、ユーザーとベンダーの協力作業となり、ユーザーにも検収に協力する義務があるというべきであるのに、Yは、平成一九年二月のテスト稼働時には本件システムが完成していたにもかかわらず、それまでの合意に反し、ロール発注残のデータ移行ができないことにクレームを述べて本稼働を行わず、その後も合理的な理由なく検収を拒み続けたものであるから、この点について、Yに債務不履行があったといえる。


と述べて,Yの債務不履行を認定した。


本件の請求根拠としては,システムの完成を理由とする報酬支払請求ではない。XY間の契約が合意解約されたことを前提に,それはYの債務不履行によるものだとして,履行利益(契約代金分)の請求を認めた。なお,控訴審では,一審認容額に若干の誤りがあったため,修正されている。

若干のコメント


パッケージソフトウェアの導入プロジェクトにおいて,ユーザがテストを行う段階になって「あれがない,これがない」と言われて揉めることは少なくありません。もちろん,ベンダとしては,事前にFit&Gap分析を行い,カスタマイズ対象を確定させたつもりであっても,こうした問題は起きています。ただし,本件では,一般論としてカスタマイズを最小限にするという考え方があることから,成果物に記載のないものが仕様に含まれるわけではないという結論を導いています。


また,本件で大きな争点となったのは,「検収協力義務」です。Yは,それまでの合意に反して「ロール発注残のデータ移行ができないことにクレームを述べ」るなどして,合理的な理由なく検収を拒絶したことが債務不履行にあたるとされました。


こうした事例から言えることは,ベンダとしては,カスタマイズ対象範囲を書面に落とし込んで承認を得ておくのは最低限のことであって,ユーザの見落としによるリスク,その場合の追加機能開発によるスケジュール・費用への影響までも説明しておくべきだといえます。ユーザとしても,カスタマイズ範囲を安易に承認するのではなく,現行業務あるいは現行システムとの網羅性を確認しながら承認プロセスを実施し,万が一漏れていた場合の取扱いや考え方についてもベンダに説明を求めることが必要でしょう。


本件は,結果的に契約締結済の報酬額が認容されたとはいえ,平成16年2月に最初のテスト稼働が行われ,その後も何度も修正とテスト稼働が行われ,平成22年になってようやく開発の中止に至っています。そして,平成23年には調停が申し立てられたものの不調に終わり,同年訴訟が提起され,平成27年6月に控訴審判決が出るまでは3年半程度を要しています。そう考えると,Xは,訴訟には勝ったものの,得られた金銭によって機会損失・費用が十分に補填されたとはいえず,双方にとってもう少し早い段階で何とかできなかっただろうかと思わされます。


なお,Xは,追加報酬についての請求もしていますが,

原判決も説示するとおり、Xは、新たに追加費用の見積を行っていないし、また、単にサービスであることを超えた有償の業務であり、追加費用が発生することを告知するなどした事情も認められない。Xが追加開発作業を行った当時は、Yとは本件システム開発に関する契約当事者であったのであり、追加要望分について行った実作業費用相当額について、真実Xに負担を求めないつもりであったか否かはともかくとしても、後に費用請求をするのなら、少なくとも何らかの事前告知が必要であったと解される。こうした事情が認められない以上、信義則に照らしても、Xの主張にかかる実作業費用相当額が損害であると認めることはできない


として否定されました。よって,相当長期に渡る本稼働に向けた折衝期間は無償の作業だったことになります。

*1:本ブログ未紹介

*2:最初のテスト稼働を行ったのは平成16年2月であり,本件は合計で5回の本稼働をトライしては延期することを繰り返していた。

2017-04-02

システムの開発対象と完成 東京地判平26.9.10(平22ワ46537他)

開発が完了したというためにはシステムが支障なく動作し,十分な性能を有するものである必要があるとしつつ,ドキュメント等が不十分でそれが認定できないとした事例。


事案の概要


Xは,Yから商品先物取引受託業務に使用するシステムの開発を請け負って,開発したにもかかわらず,代金を払わないとして,未払請負代金(約1090万円)と,データセンタ利用料(約530万円)の支払いを求めたのに対し(本訴),
Yは,Xが期限までにシステムを完成させなかったとして,既払代金相当額を含む損害の賠償として約9400万円の支払いを求めた(反訴)。


XY間では複数の契約(覚書含む)が取り交わされたが,これらをまとめて本件システム開発契約とする。

ここで取り上げる争点


(1)Xが請け負った業務の内容と納期
(2)Yは仕事を完成させたか

裁判所の判断


争点(1)業務の内容

システム開発紛争では,システムが完成したか否かが争われることが多いところ,その前提論点として,そもそも「何を作るのか」というところの画定から争われる。本件でも,その点が争点となっていた。ベンダXは,当初の提案書等から,ASPパッケージ部分の開発に限られると主張していたが,ユーザYは,ミドルオフィスを含む新基幹システム全体が対象であると主張していた。


細かいやり取りが認定されているが,注目すべきは,契約書面には,開発対象としてはASPパッケージシステム等としか記載されていなかったが,「本件契約書等の契約書面の記載が,本件システム開発契約において新基幹システムを構築することが合意されていたとの判断を覆すものと解することはできない。」と述べた。要は,契約書の記載よりも,実務上のやり取りを優先して開発対象を認定したことになる。


結局,次のように述べて,開発対象は,既存のシステムの機能をベースに仕様を確定していくというプロセスを経ていると認定した。

X及びYは,平成21年12月の時点で,Yが利用している既存の基幹システム(Xの主張するミドルオフィスの内容を含む。)を,並行稼動の期間を経て,Xが提供する新しい基幹システムに切り替えるための検討を始め,Xは,平成22年1月以降,その開発範囲や仕様を確定する作業を進めていたことが認められる。



そして,本件システム開発契約の対象は,「厳密にASPパッケージシステムの開発に限られるものではなく,本件ミドルシステム等システムを含む新基幹システムの構築を内容とするものであったと認めるのが相当である。」とした。


また,納期は,事実経緯から平成22年6月30日であったと認定した。

争点(2)仕事の完成

裁判所は,システムの完成について次のように述べた。

上記システムの開発が完了したといえるためには,これがY又はYの顧客が使用する端末機器等において支障なく動作し,Yが商品先物取引受託業務を行うに当たり十分な性能を有するものである必要があると解されるところ,Xは,画面のイメージ(甲18から25まで)を提出するにとどまり,プログラム本体はもとより,要件定義書,基本設計書,テスト結果報告書などを提出しておらず,Xが開発したというシステムがどのような性能を有しているものか判然としない。

要件定義書や基本設計書が作成されていない理由について,Aは,ウォーターフォール方式ではなくアジャイルという開発手法をとったためである旨供述するが(X代表者),仮にそうだとしても,システムが完成したのであれば,少なくともそのテスト結果を記録した書面やY側の確認をとった旨記載された書面等は作成されるはずであり,E及びAは,そのような書面が作成されていない合理的な理由について説明していない。

実際,Xが平成22年5月末から同年6月頃提供したテスト品は,テスト発注や顧客情報の登録などを行うことができないものであり,Xは,同月25日,Yから,動作テストの内容及び結果を明らかにするよう求めるメールの送付を受け,その後も再三にわたって要請をされたものの,テスト結果を書面で明らかにすることはしておらず,それどころか,前記1(3)コのとおり,同月29日にはシステム開発の遅れを認めて謝罪する文書を送付している。

(略)

以上からすれば,Xが,本件システム開発契約において合意した期限までにASPパッケージシステムを含む新基幹システムを完成させ,又はXが主張する出来高に至るまで開発を完了したものと認めることはできない。


最終工程を終えているかという基準ではなく,「支障なく動作」「十分な性能」という抽象的な基準を挙げる一方で,具体的にその基準に当てはめたというわけではなく,それを立証するに足りる文書(仕様書やテスト結果報告書等)が作成されておらず,X代表者が謝罪しているといった間接事実から完成を否定した。


よって,システムの完成を前提とするXの本訴請求は棄却され,逆に,Yによるシステム開発地帯による債務不履行に基づく損害賠償請求は全額認められた(Xの過失相殺の主張も退けられた。)。

若干のコメント


本件は,ベンダから完成を理由に代金支払請求したところ,ユーザから損害賠償請求の反訴が提起され,しかもユーザの主張がすべて認められるという典型的な返り討ちパターンとなっています。


本文中にも記載しましたが,システム完成の判断基準として,多くの裁判例で用いられている「最終工程基準」ではなく,より漠然とした基準を用いているところが特徴的です。ただし,本件で認定された事実によれば,仮に,最終工程基準で判断しても完成が否定された可能性は相当程度あると思われます。いずれにせよ,本件の認定方法は,規範と当てはめの対応関係がわかりにくく,予測可能性を欠くということで,疑問がないわけではありません。


また,ウォーターフォールではないから文書を作成していないというベンダXの主張は,結果論としては,完成立証に不利だったといわざるを得ないところで,たとえアジャイル型の開発だったとしても,仕様に関する合意やテスト実施のエビデンスを残しておくということは重要だと思われます。


なお,本文中には記載しませんでしたが,納期を経過しても完成していなかったということについて,Xは,納期延長の合意があったと争っていました。この点については,XからYに同月29日に送付した文書(いわゆる謝罪文書)において,

「システムの開発に遅延が起こっていることを,まずお詫びいたします。」,
「弊社として,開発への負荷の見込みが甘すぎました。重ねてお詫びします。実際に開発する上で,予定以上に時間を要してしまったところがあります。弊社が御社に必要な仕様・データの請求が遅くなってしまった箇所があります。」


という書面が送られおり,X自身は,Yからとりあえず頭を下げてくれと言われたから書いたと述べていましたが,裁判所は次のように認定し,むしろXの責任を裏付けるものであるとしました。

確かに,開発の遅れを踏まえ,内部でもシステム切替え時期を延期する手続が必要だったと考えられることから,上記のようなやり取りがあった可能性はある。しかし,開発の遅れの主たる原因がYの追加発注にあったのであれば,請負代金の支払を受ける必要があったXとしては,少なくとも,一方的に自社に非があることを認めるような文書を作成することは考え難い。(略)上記謝罪文書は,開発の遅れについてXに責任があったことを裏付けるものといえる。


本件では,一見するとベンダから謝罪文書を出したことが重く見られたというように読み取れます。しかし,実際には,謝罪文書というのは決定的なものではなく,裁判所が総合的に見てユーザ有利の心証を抱いた場合には,それを裏付けるものとして援用しているため,重要視されるようにみえるに過ぎないと感じます。逆に,ベンダ有利の心証を抱いた場合は,「プロジェクトを進めるために立場の弱いベンダとしては便宜的に謝罪しただけであって」などといった言辞でもってユーザの主張を退けているケースも少なくありません。もっとも,これが単なる謝罪にとどまらず,詳細な客観的分析とともに不備の内容をまとめたものであるときは異なる判断になることもあるでしょう。この点については,拙コラム*1のほか,桃尾・松尾・難波法律事務所コラム*2に詳しい。

*1:BUSINESS LAWYERS「その顛末書、裁判で不利になるかも?」 https://business.bengo4.com/category3/article101

*2:「システム開発における「謝罪」の法的意義と実務対応」https://www.mmn-law.gr.jp/topics/2017/images/System%20development%20column%20No%201.pdf