システム開発頓挫の責任が，仕様凍結の合意後も大量の追加仕様を要求し続けたなど，ユーザにある一方で，ベンダは，リスクの説明をするなど，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は上告したようですが，この種の事案が上告審で覆ることは容易ではないでしょう。
以下では，控訴審判決を少し詳しめに紹介します。
ここで取り上げる争点
原審の争点とほぼ同様であるが，控訴審の構成に沿って以下の順に取り上げる。
（１）本件システムの稼働を延期するとの合意があったか
（２）本件システムは完成したのか
（３）本件契約上のYの義務の範囲
（３−１）システムのカスタマイズ範囲
（３−２）要件定義書及び外部設計書の提出義務はあるか
（４）本件仕様凍結合意の意味
（５）171項目の追加要望の開発対象該当性
（６）マスタ抽出義務の所在及び違反
（７）本件プロジェクト頓挫についてのX，Yの責任
裁判所の判断
争点（１）稼働時期延期の合意
この点は，特に詳細な判断が示されることはなく，原審判断が維持されて，延期するという明示または黙示の合意はないとされた。
争点（２）本件システムは完成したのか
原審では，完成を否定している。当審では，完成判断基準として，次のように述べた。
システム開発では，初期段階で軽微なバグが発生するのは技術的に不可避であり，納品後のバグ対応も織り込み済みであることに照らすと，バグ等が存在しても，システムを使用して業務を遂行することが可能であり，その後の対応で順次解消される類のものであれば，仕事が完成したと認定すべきである。
そして，裁判所は当初の納期ではなく，遅くとも契約解除時（平成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の反論も退けて，システムの完成を認めた（原審判決からの変更点）。
争点（３）Yの契約上の義務の範囲
【本件システムのカスタマイズ範囲に関する義務の範囲】
この点は原審判決の結論が維持されている。その過程の判示部分に以下のような記載がある。
現行の運用の維持を最優先して，一から新たに開発するオーダーメイド型の開発を発注するのか，運用の見直しを前提として，パッケージをベースにした開発を発注することにより経費の削減を図るのかは，まさに発注者であるXの判断事項であり，Xにおいて後者を選択した以上は，カスタマイズの要望ができる範囲が限定されたとしても，やむを得ないことというべきである。この点，本件の紛争の根本的な原因は，Xが，現行の運用の維持に固執する現場の医師らの要望を十分に反映させないまま本件要求仕様書等を取りまとめて本件契約を締結したこと，にもかかわらず，その後，本件要求仕様書等並びにこれを踏まえて作成された本件技術仕様書の記載を無視して出される現場の医師らの追加開発要望を抑えるための努力を放棄し，Yがその対応に当たらざるを得なかったことにあったと考えられる。
また，Xが主張する開発項目について，運用確認，仕様検討していたという事実が，開発対象にすることを意味するものではないとした。
【要件定義書及び外部設計書の提出義務】
この点は原審では，基本設計資料，要件定義書を作成してXの承認を得る義務があるとされていた。当審では，その一部についてのみYにその義務があり，それを怠ったというように変更されている（個別の事情に依るところが大きいため，ここでは割愛する。）。
争点（４）「仕様凍結合意」の意味
平成21年7月7日にXY間で，仕様を凍結するという合意があったが，この解釈が争われていた。原審では，Yの解釈，すなわち，新たな機能の開発要求はもちろん，画面や帳票，操作性も含めて一切の追加開発要望を出さないという合意であるとした。この点も原審判決が維持された。
当審で，Xは，本件仕様凍結合意後も，Yから仕様の確認を求めていたという事実は，変更の余地があることを前提とするものであったと主張していたが，この点について裁判所は次のように述べた。
ベンダにおいて，開発したシステムの内容の確認をユーザに求めることは当然のことであって，だからといって，ユーザからなされる追加開発要望を受け入れることをベンダが許容していたということはできない。
さらに，Xは，一切の追加開発要望が出せないということをXは認識しておらず，そうなのであれば，Yが適切に説明しなかったのはYの責任だと主張した。
X自身，本件仕様凍結合意が今後一切の追加開発要望を出さないという合意であると認識していたことは，上記ウや，Xによる追加開発要望のために本件システム開発が遅れており，開発対象に取り込むべき開発要望の精査を行ってきた結果本件仕様凍結合意に至った経緯などに照らして明らかである。もっとも，現場の医師らには，そのような認識が必ずしも浸透していたとはいえず，これが本件の紛争の根本的な原因の一つとなっていたことは，前記４(1)イ(ｱ)のとおりであるが，これは，Yではなく，Xの責任というべきである。
争点（５）171項目の追加開発該当性
原審では171項目すべてについてつぶさに開発対象内であったかどうかが判示された。そもそも，これらの項目が開発対象内であることについてXが立証責任を負うのか，開発対象外であることについてYが立証責任を負うのかということから問題となった。
１７１項目の追加要望は，本件システムの引渡しが履行期になされなかったこと（債務不履行）についての帰責性がなく，また，Xに協力義務違反が認められる根拠の一つとしてYが主張するものであるから，これらの開発要望が出されたこと及びそれが開発対象外の開発要望であることについてYが主張立証責任を負うものというべきであり，これに反するYの主張は採用できない。
なお，判決文では１７１項目それぞれについて，開発対象外であるかどうか，再度認定がなされているが，ここでは割愛する。
争点（６）Xのマスタ抽出義務の有無
Xが，薬品や検査項目などのマスタデータを作成（あるいは現行システムからの抽出）義務があったかどうかが争われていた。
データ移行はシステム開発におけるトラブルで頻出する。システムの稼働に不可欠でありながらも，目立たない作業であるため，作業分担やスケジュールが曖昧になりがちなタスクだからだ。
控訴審でも，Xがマスタ抽出義務を怠ったと認定されている。判決文では，要求仕様書，技術仕様書，プロジェクト計画書などの資料から丁寧に事実認定し，Yが一部マスタの抽出業務を行ったとしつつも，
しかしながら，これらは，Xがその義務であるマスタの抽出作業を行わず，本件プロジェクトが停滞する中で，やむなくYがその一部の作業を代行したものであったと認められ，これらの事実があったからといって，Yが「継続的な設定変更・確認が必要なマスタ」の抽出義務を負っていたということはできない。
そして，このようにYがXに代わってマスタの抽出作業を行うに当たっても，Xは，既存システムのマスタの調査及び分析に必要な協力（ＮＥＣへの協力依頼等）を行わず，このため，Yの負担が増大したものと認められる。
と，Xに厳しい認定をした。このマスタ抽出義務に関しては，Yにおいてもその支援をする義務があるとされていたが，「Yは，繰り返し，Xによるマスタの抽出作業が遅れている旨を指摘して，早期の対応を求めていたのに，Xが抽出作業を怠っていたものである」として，Y自身の支援義務には不履行がなかったとされている。
争点（７）本件プロジェクト頓挫についてのXとYの責任
この争点が本件のハイライトとなる。Xの債務不履行（協力義務）が認定される箇所を少々長いが引用する。
システム開発はベンダであるYの努力のみによってなし得るものではなく，ユーザであるXの協力が必要不可欠であって，Xも，Yによる本件システム開発に協力すべき義務を負う（Xも，一般論として上記のような協力義務を有していることは認めているところである。）。そして，この協力義務は，本件契約上Xの責任とされていたもの（マスタの抽出作業など）を円滑に行うというような作為義務はもちろん，本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し，Yにその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。
しかるに，前記６などのとおり，Xが本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し，Yがこれに対応せざるを得なかったことから，本件システム開発が遅延した。また，前記７のとおり，Xがマスタの抽出義務を負っていたにもかかわらず，これを懈怠し，Xの協力が得られないままYが代行せざるを得なくなったことも，本件プロジェクトが遅延した理由の一つになっている。
さらに，Xは，Xの追加開発要望に基づいて現行システムの備える機能を最大限取り込むことを要求しながら，そのために必要な現行システムの情報（基本設計書等）を十分に提供せず，また，YがXに代わってマスタの抽出作業を行うに際しても，ＮＥＣに必要な協力依頼を行うことを怠った。
そして，前記３のとおり，本件システムは，遅くとも平成２２年４月２６日までには，Xの協力が得られずに保留せざるを得なかった１項目を除き，全て完成していたにも関わらず，Xは，独自の見解から本件システムの開発がYの責任で遅延したとして，一方的に本件解除をした。
上記のとおり，Xには，本件契約上の協力義務違反（債務不履行）が認められる。
続いて，YにPM義務違反があったというXの主張について検討された。
Yは，平成２１年３月４日以降，専門部会等において，繰り返し，Xによる追加開発要望の多くは仕様外のものであること，Yとしては，これらの追加開発要望に対応するのは難しく，同年９月２４日（本件原契約におけるリース開始日）に間に合わなくなることを説明した。
そして，Yは，同年７月７日，Xによる６２５項目の追加開発要望を受け入れる（本件追加開発合意）一方で，以後は，新たな機能の開発要望はもちろん，画面や帳票，操作性に関わるものも含め，一切の追加開発要望を出さないという合意（本件仕様凍結合意）を取り付けたものである。このように，Yは，プロジェクトマネジメント義務の履行として，追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で，追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる。
これを越えて，Yにおいて，納期を守るためには更なる追加開発要望をしないよう注文者（X）を説得したり，Xによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず，Yにプロジェクトマネジメント義務の違反があったとは認められない。したがって，Yには債務不履行（履行遅滞）について帰責性がなく，また，Xの債務不履行について過失相殺の対象となるべき過失の存在も認められない
以上のとおり，X（ユーザ）の債務不履行を認める一方で，Y（ベンダ）の債務不履行を認めなかった。さらには，Y側の過失相殺も認めなかった。
そして，本件システムが完成し，リースが開始されれば得られたであろう金額（約１５億円）から，一部の損益相殺（物品の転用）をして，約１４億円の損害賠償を認めた。
*1:ITpro「失敗の全責任はユーザー側に，旭川医大とNTT東の裁判で逆転判決」http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/
