（東京高判平成26年１ 月１5日LEX ／ DB文献番号25503１9１）
〔判例研究〕
システム開発契約における プロジェクトマネジメント義務
（東京高判平成26年１ 月１5日LEX ／ DB文献番号25503１9１）
x x x x
第 １ 事案の概要等
１ はじめに
⑴ 本判決は，出版会社の情報システムを開発して提供すること等を目的とする契約に関し，ソフトウェアの受託開発等を業とするベンダであるＸ（原告，反訴被告，被控訴人及び附帯控訴人。）と，書籍の出版及び販売等を業とするユーザであるＹ（被告，反訴原告，控訴人及び附帯被控訴人。）との間で，同システム開発を巡って，委託料及び損害賠償等を相互に請求し合うこととなった事案である。
⑵ 本訴事件は，Ｘが，Ｙに対し，委託料及び追加業務に要した費用並びに導入支援費用等として約14億円と遅延損害金の支払いを請求した事件である。反訴事件は，Ｙが，Ｘに対し，債務不履行又は瑕 疵担保責任に基づく損害賠償として，支払済の費用及びその他費用など約14億円と遅延損害金の支払い
を請求した事件である。
2 事実関係の概要
⑴ 基本契約の締結
株式会社ａは，Ｙとの間で，平成16年 4 月15日， Ｙの次期情報システム（以下「本件新基幹システム」という。）の開発プロジェクト（以下「本件プロジェクト」という。）について，Ｙを委託者，株式会社ａを受託者とする業務委託基本契約を締結した。Ｘは，平成18年10月 1 日，株式会社ａを吸収合
併した（以下，株式会社ａとＸを区別せず「Ｘ」という。）。
⑵ 要件定義等
Ｙは，平成17年 7 月15日，Ｘに対し，「新基幹システム開発提案依頼書」を提出し，Xが同月25日付けで「『新基幹システム開発』のご提案」を提出し，これが採用された。そして，Ｘは，上記業務委託基本契約に係る個別契約に基づいて，要件定義を行い，本件新基幹システムの具体的な機能（要件）が確定した後，同要件定義に基づいて外部設計を開始し，外部設計書の納入，検収を経てその代金が支払われた。
⑶ 開発契約の締結等
外部設計後の開発工程では，個別契約が締結されないまま，作業が行われていたことに加えて，平成 20年 4 月から，本件新基幹システム導入のためにＹの作業に対する導入支援業務がＸによって行われていたが，Ｙは，平成20年12月25日，Ｘとの間で，代金額 8 億9825万5749円として，上記業務委託基本契約に係る個別契約として，本件新基幹システムに係るソフトウェア開発個別契約（以下「本件ソフトウェア開発個別契約」という。）を締結した。なお，同契約では，請負契約とすること，本件新基幹システムを平成21年 1 月 5 日までに納品し，同年 4 月末までにＹが検収を行うことが合意された。
⑷ 仕様変更等
本件ソフトウェア開発個別契約締結前後，ＹがＸに対して，本件新基幹システムについて多数の変更要望を出したため，上記要件定義及び外部設計終了後の段階になって，仕様変更が行われた。すなわち，本件新基幹システムに係るソフトウェア開発は，いわゆるスクラッチ型の開発（パッケージ製品のカスタマイズや機能追加，現在使用中のシステムの改修などによらず，全体を新たに開発するか若しくは開発し直すこと）を内容とし，いわゆる「To- Beモデル」（あるべき業務プロセスモデルのこと）による新たなシステムを開発することが計画され，上記要件定義及び外部設計が行われたものの，本件ソフトウェア開発個別契約締結前後になって，YからXに対し，旧システムからの移行を重視したいわゆる「As-Isモデル」による仕様変更希望が多数出されたものである。
⑸ 解除通知等
Ｙは，Ｘに対し，平成21年 4 月30日，納品された個々のプログラムにおいて多数の不具合・障害が発生したことを理由に「検収の完了に至ることが出来ません。」と通知し，同年 6 月16日，前回の不合格通知の後に新たに127件の不具合・障害が発生したことを理由に「改めて，本契約書（注：本件ソフトウェア開発個別契約書）に基づく貴社の納品成果物が，検収不合格であることを通知させていただきます」との通知をした。なお，Ｘの認識でも，同日の時点で，本件新基幹システムの不具合，障害は31件あり，その他にも補修未了の不具合，障害が29件
（うち程度が高いものが 1 件，中程度が 6 件，低いものが22件）あった。
その上で，Ｙは，同日，Ｘに対し，以上のような経緯からすると，「貴社による納品成果物の完成は，社会通念上，履行不能となっていること，又，貴社と弊社の信頼関係は完全に破壊されていることを理由に，本書面をもって，本契約を解除します。」，
「仮に，納品成果物が完成しているとしても，本件
は，プログラムの不具合・障害が多数発生し，収束の見通しもたたない事案であり，…民法635条に基づいて，本書面をもって，本契約を解除します。」と通知し，本件ソフトウェア開発個別契約を解除する旨の意思表示をした。その後もさらに多くの不具合・障害が発現しており，同日の時点では，本件新基幹システムに今後どの程度の障害・不具合が生じ，その補修にどの程度掛かるのかについて，その目途が立たない状態にあった。
なお，第 1 審の進行協議期日において，不具合・障害か否かについて争いのあった事象のうち，X及びYが典型的なものとして挙げた 7 件に関し，専門委員が立ち会い，実機を用いた確認作業を行われているところ，本件新基幹システムについて，請求書情報管理画面に関する事象（請求先のコード番号を基に検索された件数は 9 件と表示されるが，検索
条件に適合した明細は 4 件しか表示されない。），各顧客の請求金額，請求残金額などの詳細を把握するためのお客様情報照会画面に関する事象（契約先の変更に伴い請求残移管を行った場合件数が正しく表示されない。）等の事象が確認されている。
第 2 争点並びに第xx及び控訴審の判断
第 1 審（ 東京地判平成25年 5 月28日判タ1416号 234頁）は，本訴請求を棄却し，反訴請求のうち，瑕疵担保に基づく損害賠償請求を一部認容した（約 2300万円）。また，控訴審は，反訴請求のうち，瑕疵担保に基づく損害賠償請求の認容金額を約 2 億円に変更し，附帯控訴を棄却した。
争点が多岐にわたるため，以下では，プロジェクトマネジメント義務に関連する部分に限って整理する。
１ 本件に現れたプロジェクトマネジメント義務について
本件は，ベンダのプロジェクトマネジメント義務を，下記のとおり，債務不履行に基づく損害賠償請求の請求原因としてではなく，瑕疵担保責任に基づ
く解除，損害賠償請求における瑕疵の生じた原因及び過失相殺において考慮している。
2 第 １ 審について
本件のうち反訴事件は，ＹがＸに対し，本件ソフトウェア開発個別契約（請負契約）における仕事の完成がなされていないという債務不履行に基づき，または納品されたソフトウェアに不具合・障害が生じているとして瑕疵担保責任に基づき，損害賠償請求を求めるものである。
プロジェクトマネジメント義務は，ベンダ側の債務の内容として主張され，同義務違反を債務不履行とすることが多いが，本件では，債務の内容としてではなく，瑕疵の生じた原因として主張されている。Ｙは，瑕疵の生じた原因としてＸのプロジェクトマネジメント管理能力の欠如（控訴審では，プロジェクトマネジメント義務違反と追加主張している。）を主張し，また，Ｘの導入支援業務費用の請求に対し，同導入支援業務の債務不履行解除においてプロジェクトマネジメント義務違反を主張しているのである。
そのような中で，第 1 審は，瑕疵担保責任を肯定した判示（「本件新基幹システムには瑕疵があるというべきで，そのために仕事の目的は達成できない。」）に続けて，「特に，原告は，…開発業務の全般にわたり『プロジェクト管理』の責任があり，上記のとおりの事態が生じたことについては，プロジェクトマネジメント義務違反としての責任も免れないというべきである。」と判示している。
また，第 1 審は，上記判示に続けて，過失相殺による減額を肯定する。すなわち，「上記瑕疵の発生 について被告側にも原因があるという場合には，原告のみにその全ての責任を負わすのは不xxであり，過失相殺の法理により，被告の損害賠償請求については，減額を認めるのが相当である（プロジェクトマネジメント義務違反としての責任ととらえても，過失相殺が認められる。）。」と判示し，Ｙ側の過失について検討をしている。そして，多くの瑕疵
が生じた原因について，「…原告において，上記のとおり費用負担についての明確な合意がないまま被告により多くの変更を余儀なくされて混乱が生じ，納期の遵守も困難となったことにあることは容易に推認することができる。…瑕疵の発生による責任は原告が負わなければならないとしても，その原因の大部分は被告側から生じているというほかな」いと判示し， 8 割の過失相殺を認めた。
3 控訴審について
控訴審は，上記第 1 審の各判断に対し，以下のような変更をしている。
第 1 審 | 控訴審 | |
⑴ | 特に，原告は，前記 1 ⑴イのとおり，開発業務の全般にわたり「プロジェクト管理」の責任があり，上記のとおりの事態が生じたことについては，プロジェクトマネジメント義務違反としての責任も免れないというべきで ある。 | 先「前記 1 ⑴イのとおり」を，「システム開発等の専門的知見や経験を有する専門業者であり，本件プロジェクトの業務委託基本契約に係る善管注意義務に基づき」と改める。 |
⑵ | しかし， 上記瑕疵の発生について被告側にも原因があるという場合には， 原告のみにその全ての責任を負わすのは不xxであり， 過失相殺の法理により， 被告の損害賠償請求については， 減額を認めるのが相当である（ プロジェクトマネジメント義務違反としての責任ととらえても，過失 相殺が認められる。）。 | 「 し か し，」 の 次 に 「控訴人が顧客であって，システム開発等についての専門的知見を備えているとは認められないといっても，」を加える。 |
⑶ | …原告において，上記のとおり費用負担についての明確な合意 が な い ま ま 被 告 （により多くの変更を余儀なくされて混乱が生じ，納期の遵守も困難となったことにあることは容易に推認することができる。…瑕疵の発生による責任は原告が負わなければならないとしても，その原因の大部分は被告側から生じているという ほかな」い | ※長文のため，以下で別途本文に記載している。 |
（上記表⑶控訴審部分）
①「控訴人は，顧客であって，システム開発等についての専門的知見を備えているとは認められないのに対し，被控訴人は，システム開発等の専門的知見や経験を備えた専門業者であって，本件新基幹システムに多数の不具合・障害という瑕疵を発生させたのは被控訴人であることが認められる。」
②「そして，その原因の一つとして，控訴人と被控訴人との間で費用負担についての明確な合意がないまま，被控訴人が控訴人の変更要求に応じて多くの変更をして混乱が生じ，約定された検収完了時期の遵守も困難になったことがあると認められる。また，上記瑕疵のために上記検収期間終了時において検収が終了せず，その時期が上記予定よりも大幅に遅れ，控訴人の現行システムのホストコンピュータの保守期間である平成21年 9 月30日の満了後もなお長期間を要する状態になれば，社会通念上，本件ソフトウェア開発個別契約の目的を達成できなくなるのであって，このことを控訴人が認識していた。」
③「そして，外部設計後に多数の変更を行えば，本件新基幹システムにおける不具合・障害の発生の可
能性を増加させ，その検収完了が遅延するおそれが生じ得ることに照らせば，控訴人が被控訴人に対し本件新基幹システムについて多数の変更を申し入れたことは，本件ソフトウェア開発個別契約の目的を達成できなくなった原因の一つであると認められ，その点において控訴人に過失のあることを否定できないのである。」
④「しかし，本件ソフトウェア開発個別契約においては，控訴人から被控訴人に対して仕様書等の変更の申入れがあった場合，その申入れから14日以内に，控訴人及び被控訴人は変更の内容及びその可否につき協議を行い，変更の可否につき決定するものと約定されており，その期間に協議が調わない場合，被控訴人は，従前の仕様書等に基づき本件業務を遂行するものし，控訴人はこれを了承する旨が約定されている（ 3 条 3 項）ことからすれば，被控訴人は，控訴人の変更申入れを応諾する契約上の義務を負わず，契約上これを拒絶することができるのである。そして，控訴人がシステム開発等についての専門的知見を備えているとは認められない顧客であるのに対し，被控訴人は，システム開発等の専門的知見や経験を備えた専門業者であって，控訴人からの変更の申入れに応じることが，本件新基幹システムにおける不具合・障害の発生の可能性を増加させ，そのために検収終了時期を大幅に遅延させ，本件ソフトウェア開発個別契約の目的を達成できなくなる場合においては，本件プロジェクトの業務委託基本契約に基づく善管注意義務及び本件ソフトウェア開発個別契約における付随的義務として，その専門的知見，経験に照らして，これを予見した上，控訴人に対し，これを告知して説明すべき義務を負うものであって，なお，控訴人が変更を求めるときは，これを拒絶する契約上の義務があると認められるのである。そして，被控訴人において，これを予見することが困難であったとは認められないのであって，被控訴人のこのような義務違反が控訴人の上記過失の一因となっていることが否定できないの
である。」
⑤「また，控訴人において担当していたデータの移行作業に不適切さのあったことも，本件新基幹システムにおける不具合・障害という瑕疵発生の原因の一つであると認められ，この点において，控訴人に過失のあることを認めることができる。」
⑥「しかし，控訴人がシステム開発等についての専門的知見を備えているとは認められない顧客であるのに対し，被控訴人は，システム開発等の専門的知見や経験を備えた専門業者であって，控訴人の上記データ移行作業の不適切さが，本件新基幹システムにおける不具合・障害の発生の可能性を増加させ，そのためにその検収終了時期を大幅に遅延させ，本件ソフトウェア開発個別契約の目的を達成できなくなる場合においては，本件プロジェクトの業務委託基本契約に基づく善管注意義務及び本件ソフトウェア開発個別契約における付随的義務として，その専門的知見，経験に照らし，これを予見した上，このような事態を回避するために，控訴人に告知し，控訴人のデータ移行作業に特段の対応が必要であるというのであれば，その旨の指摘・指導をすべき義務を負うと認められる。そして，被控訴人において，これを予見することが困難であったとは認められないのであって，被控訴人のこのような義務違反が控訴人の上記過失の一因となっていることが否定できないのである。」
「…その減額の割合は 4 割と認めるのが相当である」
第 3 検討（控訴審の判断に賛成）
（1）
１ 本判決の意義
本件は，第 1 審，控訴審ともに，ベンダであるＸからの委託料等の請求を棄却し，ユーザであるＹからの瑕疵担保に基づく解除及び損害賠償請求を肯定しつつも，過失相殺によって，同損害賠償について一定の減額を行い，また，過失相殺の割合を判断するにあたって，ベンダ側のプロジェクトマネジメント義務違反を考慮している。ベンダ側のプロジェクトマネジメント義務を踏まえつつ，瑕疵のリスクをベンダとユーザとの間で分担するよう解決を示したように見受けられ，その点について意義があるものと思われる。
ただし，第 1 審ではユーザ 8 割，ベンダ 2 割の責
任だったものが，控訴審では，ユーザ 4 割，ベンダ
6 割となっており，控訴審において，xxxの責任が重くなっている。
2 システム開発に関する一般論
⑴ 一般的な流れ
システム開発の開発手法は様々であり，その生産過程も一つには決まらない。システム開発の手法は
（2）
様々であり，一概にはいえないが，基本系を示す
（3）
と以下のような形となる。
① ユーザによる業務のシステム化計画又は既存システムの再構築計画
② ベンダへの開発依頼
③ ベンダによるユーザからの要求聴取，システム化に必要な要件の分析
④ システムの仕様の確定（要件定義を含む）
＊ 要件定義：システム化計画を受けて，業務上
（1） 第 1 審の評釈として，xxxx「ソフトウェア開発契約における瑕疵担保責任の有無及び内容」リマークス53号38頁
（2） 司法研修所編『民事訴訟における事実認定─契約分野別研究（製作及び開発に関する研究）─』（法曹会， 2014）92頁，東京地方裁判所プラクティス委員会第二小委員会「ソフトウェア開発関係訴訟の手引」判タ
1349号 4 頁（2011）参照
（3） ㈳情報サービス産業協会法的問題委員会契約部会『新しいソフトウェア開発委託取引の契約と実務』（商事法務，2002）32頁以下参照
の要求を業務要件に，システムに実装すべきシステムの機能要件・非機能要件を定義する段階
⑤ 基本設計を行い，開発の製造工程に入る
⑥ テスト工程とは
⑵ 開発方式
システム開発の方式として古くからウォーターフォール型の手法が用いられることが多く，xxx
（4）
主流である。
ウォーターフォール型は，システム開発の過程を，「企画」「要件定義」「基本設計（外部設計）」
「詳細設計（内部設計）」「開発」「テスト」「運用」といった工程に分割し，全行程の成果物の内容により後工程の作業内容を画し，原則として後工程から前工程への後戻りを認めないとする方式である。比較的規模の大きいシステムの開発に用いられるとされ，本事案でも用いられた方法である。
（システム開発における代表例：ウォーターフォー
（5）
ル型）
⑶ 上流工程について
前記工程において特に重要なものが，上流工程といわれる「要件定義」「基本設計（外部設計）」と言われる部分である。システムの仕様確定作業を中心的に行う工程である。
これらの工程ではユーザのイメージするシステム像とベンダの構築しようとするシステム像のすり合わせを行う工程で，互いに情報提供が求められる共同作業の工程である。ここでシステム全体の仕様が決定され，順を追って仕様に関する合意が形成される。システムによって実現したい内容，そのため求める機能，性能，予算・運用開始期限・使用するサーバーやパソコンの機種，数量，設置場所などの制約を整理・分析の上，徐々に決定される。このように，xxxとベンダとの相互のコミュニケーションが極めて重要といえるのであり，両者の認識に齟齬があれば，その後の開発に決定的な影響を与えてしまうものになる。
⑷ システム開発契約の特色
システム開発契約の特色として，以下のような 3点を挙げることができる。
（6）
① 専門的知見の必要性
システムは無形の存在であり製作や内部の仕組みに関する専門的知見を要する。
② 仕様の不確実性，システムの不可視性
完成すべきシステムの仕様が当初から定まっておらず，抽象度が高く，概括的であって，可視性も低い。
③ ユーザとベンダの協力関係の必要性
（4） ウォーターフォール型のほか，プロトタイプ型（工程を区分せずにユーザの要望から試作品を作成・提示・計画する開発方式），スパイラル方式（比較的密接に関連した機能ごとに開発を区分し，区分ごとに設計，プログラミング，テストを短い周期で繰り返し，ユーザからのフィードバックを得ながら全体を完成させる開発手法），アジャイル型（開発対象を多数の小さな機能に分類し，1つずつ機能を開発していくもの。）などがある。なお，スパイラル方式とアジャイル方式との違いは，前者が全体を想定しながら徐々に品質を高めていくものに対し，後者は部分，部分を徐々に作る発想である点にある（xxxxほか『裁判例から考えるシステム開発紛争の法律実務』（商事法務，2017年）20〜22頁）。
（5） 経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む），保守運用）〈第一版〉」31頁（2006）（xxxx://xxx.xxxx.xx.xx/xxxxxx/xx_xxxxxx/xxxxxxxxx/xxxxx.xxxx#00）
（6） xxxxほか「ソフトウェア開発関連訴訟の審理」判タ1340号5頁（2011）
ユーザの業務内容ニーズとベンダの専門知識や技能とを照らし合わせる等の協力関係が必要で（システムの内容は千差万別でありオーダーメイド的性格を有するものであるから，ユーザからデータその他の提供，ユーザとベンダの間の円滑な意思疎通など，緊密な協力関係がなければ構築は困難になる。），両者の協力関係を前提に，変更及び調整を重ねながら，システムの仕様を具体化していくことが要求される。
このように，システム開発契約においては，専門的知見を要し，システムの仕様がもともと抽象的・概括的であり，ユーザとベンダが協力して内容を段階的に定めていくという点に特色がある。また，ユーザとベンダとの間で形成されたシステムに関する合意は，個々の項目ごとではなくシステム全体と
の関係で有機的一体としての合意が形成されている
（7）
と評されている。
2 裁判例等
⑴ 背景
上記のとおり，システム開発契約においてはユーザとベンダの相互の信頼関係が不可欠であり，相互の協力なしにはシステム開発は成功しない。
このような状況の中，相互の協力に関する義務に関して登場した概念が，ベンダのプロジェクトマネジメント義務とユーザの協力義務である。後述のような裁判例にも登場しているが，その根拠は必ずしも明らかにされていない状況である。なお，根拠について，プロジェクトマネジメント義務に関しては，①ベンダの仕事を完成させる義務の「要素たる義務」と見る見解，②仕事の完成という主たる義務に付随的な義務，③仕事が完成せずに頓挫した場合，その頓挫の原因が当該義務違反であれば債務不履行責任を構成するとする見解，④③とは異なり不
（8）
法行為を構成するという見解などが見受けられる。
⑵ 東京土建国民健康保険組合事件（東京地判平成 16年 3 月10日判タ1211号129頁）
当該判決は，裁判例で初めてプロジェクトマネジメント義務に言及した判決である。健康保険組合であるユーザが，ベンダとの間で電算システム開発業務委託契約を締結し，第 2 次電算システム及び共済システムの構築を委託したが，納入期限までにシステムを完成させなかったなどとして，同契約の債務不履行解除を原因として原状回復請求権に基づき，既払委託料の返還等を請求したものである。
同判決は，プロジェクトマネジメント義務について①合意した開発手順，開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務，②ユーザの開発へのかかわりについても，適切に管理し，システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユーザに働きかける義務とした。
⑶ スルガ銀行・日本ＩＢＭ事件（東京高判平成26年 1 月15日金判1428号16頁） ＩＢＭをベンダ（控訴人）スルガ銀行をユーザ
（被控訴人）とするシステム開発において，複数の基本合意と個別契約を締結したが，プロジェクトが途中で頓挫した事案で，次のとおり判示されている。
「控訴人は，前記各契約に基づき，本件システム開発を担うベンダとして，被控訴人に対し，本件システム開発過程において，適宜得られた情報を集約・分析して，ベンダとして通常求められる専門的知見を用いてシステム構築を進め，ユーザーである被控訴人に必要な説明を行い，その了解を得なが
（7） 司法研修所編『民事訴訟における事実認定─契約分野別研究（製作及び開発に関する研究）─』（法曹会， 2014）108頁
（8） xxxx「『プロジェクトマネジメント義務』判決と法的諸問題」Information Network Law Review Vol.12（2013年）144頁。
ら，適宜必要とされる修正，調整等を行いつつ，本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである。」
「また，前記義務の具体的な内容は，契約文言等からxx的に定まるものではなく，システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。すなわち，システム開発は必ずしも当初の想定どおり進むとは限らず，当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり，想定していた開発費用，開発スコープ，開発期間等について相当程度の修正を要すること，更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから，ベンダとしては，そのような局面に応じて，ユーザーのシステム開発に伴うメリット，リスク等を考慮し，適時適切に，開発状況の分析，開発計画の変更の要否とその内容，更には開発計画の中止の要否とその影響等についても説明することが求められ，そのような説明義務を負うものというべきである。
「控訴人は，被控訴人と本件最終合意を締結し，本件システム開発を推進する方針を選択する以上，被控訴人に対し，ベンダとしての知識・経験，本件システムに関する状況の分析等に基づき，開発費用，開発スコープ及び開発期間のいずれか，あるいはその全部を抜本的に見直す必要があることについて説明し，適切な見直しを行わなければ，本件システム開発を進めることができないこと，その結果，従来の投入費用，更には今後の費用が無駄になることがあることを具体的に説明し，ユーザーである被控訴人の適切な判断を促す義務があったというべきである。また，本件最終合意は，前記のような局面において締結されたものであるから，控訴人は，ベンダとして，この段階以降の本件システム開発の推進を図り，開発進行上の危機を回避するための適時適切な説明と提言をし，仮に回避し得ない場合には本件システム開発の中止をも提言する義務があった
というべきである。」
⑷ 札幌高判平成29年 8 月31日判時2362号24頁
病院情報管理システムを構築して提供することを目的とするシステム開発契約に関し，当該システムの構築が頓挫したことにつき，ユーザ（原告）とベンダ（被告）との間で，相互に損害賠償等を請求し合うことになった事案である。ユーザは，債務不履行に基づく損害賠償として，約19億円の支払いを請求し，ベンダは，システムの完成及び引渡しが遅れたことにつきユーザの協力義務違反等により，完成義務を履行し得なくなったことにつき，主位的には債務不履行に基づく損害賠償として約23億円の支払いを請求している。
札幌高裁は「システム開発はベンダである被告の努力のみによってなし得るものではなく，ユーザである原告の協力が必要不可欠であって，原告も，被告による本件システム開発に協力すべき義務を負う。」「そして，この協力義務は，本件契約上原告の責任とされていたもの（マスタの抽出作業など）を円滑に行うというような作為義務はもちろん，本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し，被告にその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。」「原告が本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し，被告がこれに対応せざるを得なかったことから，本件システム開発が遅延した。また，（略），原告がマスタの抽出義務を負っていたにもかかわらず，これを懈怠し，原告の協力が得られないまま被告が代行せざるを得なくなったことも，本件プロジェクトが遅延した理由の一つになっている。」と判断し，原告の「本件契約上の協力義務違反（債務不履行）が認められる」とした。
また，「被告は，平成21年 3 月 4 日以降，専門部会等において，繰り返し，原告による追加開発要望の多くは仕様外のものであること，被告としては，これらの追加開発要望に対応するのは難しく，同年
9 月24日に間に合わなくなることを説明した」こと，「被告が625項目の追加開発要望を受け入れる一方，以後は，新たな機能の開発要望はもちろん，画面や帳票，操作性に関わるものも含め，一切の追加開発要望を出さないという合意（本件仕様凍結合意）を取り付けた」ことを指摘し，「被告は，プロジェクトマネジメント義務の履行として，追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で，追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる」とした。その上で，「これを越えて，被告において，納期を守るためには更なる追加開発要望をしないよう注文者を説得したり，原告による不当な追加開発要望を毅然と拒否したりする義務があったということはできず，被告にプロジェクトマネジメント義務の違反があったとは認められない」として，履行遅滞に関する帰責性，過失相殺の対象となるべき過失を否定した。
⑸ 本判決におけるプロジェクトマネジメント義務の位置づけ等
第 1 審及び控訴審は，いずれも，瑕疵担保責任が問題となった事案において，瑕疵が生じていること，そのために契約目的を達成できないこと及びその責任がベンダであるＸにあることを前提に，過失相殺をし，その際，ベンダであるＸのプロジェクトマネジメント義務を考慮している点は共通している。
もっとも，第 1 審は，ユーザであるＹの仕様変更
等の要求が瑕疵の生じた主たる原因であるとして 8割の過失相殺を認めている一方で，控訴審は，ユーザであるＹの要求が瑕疵の原因であることを認めつつも， 4 割の過失相殺としている。
判断が異なった背景には，ベンダの専門性を重視
（9）
しているか否かにあると考えられる。すなわち，
控訴審は，「外部設計後に多数の変更を行えば，本件新基幹システムにおける不具合・障害の発生の可能性を増加させ，その検収完了が遅延するおそれが生じ得ることに照らせば，控訴人が被控訴人に対し 本件新基幹システムについて多数の変更を申し入れたことは，本件ソフトウェア開発個別契約の目的を達成できなくなった原因の一つであると認められ，その点において控訴人に過失のあることを否定できないのである。」と判示しながらも，「しかし，本件ソフトウェア開発個別契約においては，控訴人から被控訴人に対して仕様書等の変更の申入れがあった場合，その申入れから14日以内に，控訴人及び被控訴人は変更の内容及びその可否につき協議を行い，変更の可否につき決定するものと約定されており，その期間に協議が調わない場合，被控訴人は，従前の仕様書等に基づき本件業務を遂行するものし，控訴人はこれを了承する旨が約定されている（ 3 条 3項）ことからすれば，被控訴人は，控訴人の変更申入れを応諾する契約上の義務を負わず，契約上これを拒絶することができるのである。そして，控訴人がシステム開発等についての専門的知見を備えているとは認められない顧客であるのに対し，被控訴人は，システム開発等の専門的知見や経験を備えた専門業者であって，控訴人からの変更の申入れに応じることが，本件新基幹システムにおける不具合・障害の発生の可能性を増加させ，そのために検収終了時期を大幅に遅延させ，本件ソフトウェア開発個別契約の目的を達成できなくなる場合においては，本件プロジェクトの業務委託基本契約に基づく善管注意義務及び本件ソフトウェア開発個別契約における付随的義務として，その専門的知見，経験に照らして，これを予見した上，控訴人に対し，これを告知
（9） xxxx「近似のシステム開発紛争事例に見る紛争解決の判断ポイント」Business Law Journal141号35頁
（2019）は，「第 1 審においてはユーザ側の落ち度が独立に問題とされたのに対し，控訴審においては，プロジェクトマネジメント義務の判断において，ユーザの非専門性が考慮されたと思われる。」とし，ユーザ側に落ち度があっても「ベンダ側はそれを漫然と見過ごすのではなく，システム開発の専門家として適切に助言をすべき義務が含まれると認められたことが大きかったのではないかと理解される。」とする。
して説明すべき義務を負うものであって，なお，控 訴人が変更を求めるときは，これを拒絶する契約上の義務があると認められるのである。そして，被控訴人において，これを予見することが困難であったとは認められないのであって，被控訴人のこのような義務違反が控訴人の上記過失の一因となっていることが否定できないのである。」と判示している。
また，「控訴人において担当していたデータの移 行作業に不適切さのあったことも，本件新基幹システムにおける不具合・障害という瑕疵発生の原因の一つであると認められ，この点において，控訴人に過失のあることを認めることができる。」と判示しているが，「しかし，控訴人がシステム開発等についての専門的知見を備えているとは認められない顧客であるのに対し，被控訴人は，システム開発等の専門的知見や経験を備えた専門業者であって，控訴人の上記データ移行作業の不適切さが，本件新基幹システムにおける不具合・障害の発生の可能性を増加させ，そのためにその検収終了時期を大幅に遅延させ，本件ソフトウェア開発個別契約の目的を達成できなくなる場合においては，本件プロジェクトの業務委託基本契約に基づく善管注意義務及び本件ソフトウェア開発個別契約における付随的義務として，その専門的知見，経験に照らし，これを予見した上，このような事態を回避するために，控訴人に告知し，控訴人のデータ移行作業に特段の対応が必要であるというのであれば，その旨の指摘・指導をすべき義務を負うと認められる。そして，被控訴人において，これを予見することが困難であったとは認められないのであって，被控訴人のこのような義務違反が控訴人の上記過失の一因となっていることが否定できないのである。」と判示している。
このように，控訴審は，ユーザであるＹの要求が瑕疵の原因であることを認めつつも，Ｘがシステム開発等の専門的知見や経験を備えた専門業者であることを踏まえ，Ｙから仕様変更等多数の申し入れがあったとしても，これを拒絶する義務があるとす
る。また，ユーザであるＸのデータ移行作業に不適切さがあっても，これを予見し，指導助言する義務があるとする。
注文者であるユーザ側から，様々要望がなされることはシステム開発においてはみられるところであるが，同要求を拒絶する義務や，ユーザの不適切な行動について指導助言まですべき義務というのは，本来対等が原則であるはずの契約当事者において，ベンダ側に高度の義務を課すものであると考えられるところ，この判断には，ベンダが「本件プロジェクトの業務委託基本契約に基づく善管注意義務及び本件ソフトウェア開発個別契約における付随的義務」を負っているだけでなく，システム開発の専門家であるのに対し，ユーザが素人であるという考え方が根底にあると思われ，したがって，ベンダの負うプロジェクトマネジメント義務を，専門家としての責任に位置付けているものと考えられる。
ただし，控訴審は，xxxの要求を拒絶すべき義務があることの根拠として，「本件プロジェクトの 業務委託基本契約に基づく善管注意義務及び本件ソフトウェア開発個別契約における付随的義務」だけでなく，「本件ソフトウェア開発個別契約においては，控訴人から被控訴人に対して仕様書等の変更の申入れがあった場合，その申入れから14日以内に，控訴人及び被控訴人は変更の内容及びその可否につき協議を行い，変更の可否につき決定するものと約定されており，その期間に協議が調わない場合，被控訴人は，従前の仕様書等に基づき本件業務を遂行するものし，控訴人はこれを了承する旨が約定されている（ 3 条 3 項）ことからすれば」と契約条項を挙げていることから，一般的に専門家の責任として挙げられるいわゆる説明義務を超えて，要求の拒絶義務まで課すためには，ベンダが専門家であることに加えて，契約条項が必要になると考えられる可能性がある一方で，ユーザの行動に対して指導助言すべき義務を導くにあたっては，契約条項を根拠としていないため，善管注意義務等とベンダの専門性か
ら上記のような各義務を導くことができる可能性も
（10）
ある。
⑹ 前掲札幌高判平成29年 8 月31日との比較
前掲札幌高判平成29年 8 月31日は，ユーザ側から多数の要望や仕様変更要求が多数寄せられた結果，引き渡し予定日にシステムが完成せず，紛争に至っており，ユーザ側から仕様変更の要望があった点では本判決と共通している。しかし，前掲札幌高判平成29年 8 月31日は，xxx側の帰責性を否定し，反対にユーザ側の協力義務違反という債務不履行を否定して，本判決とは異なる結論を出している。
このような結論の相違には，開発のとん挫に至る経緯（ベンダ側がユーザ側の仕様変更の要望等に対し，十分な説明を尽くしたかどうか等）が影響して
いると考えられ，ベンダ側が十分な説明を尽くして
（11）
いれば，それ以上に義務を負わず，したがって，
プロジェクトマネジメントの中核は，プロジェクトの進捗等に応じた各種の説明義務ととらえることができるのではないだろうか。
⑺ いわゆる専門家との契約との共通性等
専門家との契約形態については，典型契約として委任契約や請負契約あるいはこれに類似する無名契
（12）
約といった類型が利用されるところ，システム開
発契約についても，法的性質が明らかにされていないものの，基本的には当てはまると考えられる。また，専門家契約の特色として，一般的に，契約当事
者間の原則的非対等性，専門家の裁量及び信頼関係
（13）
を基盤とする契約という点が挙げられている。そ
して，これらは，以下の表のとおり，システム開発契約についても当てはまるものと考えられる。もっとも，その具体的な内容や程度等については，システム開発契約の特殊性等を踏まえた検討が必要であると考えられ，今後の検討課題としたい。
専門家との契約の特色 | |
① 契約当事者間の原則的非対等性 | ベンダはシステム開発の専門家である一方，ユーザはシステム開発 契約について素人 |
② 専門家の裁量 | ユーザの求めるシステム開発をするため，どのような手法を用いるか等につき，ユーザと協力して進めるとはいえ，その選択等についてはベンダに 一定の裁量があると考え （14） られる。 |
（15） ③ 信頼関係を基盤と する契約 | ユーザは，ベンダの専門的知見や経験等を信頼して契約を締結し，システム開発を依頼す るといえる。 |
以上
（10） xxxxほか「座談会システム開発取引はなぜ紛争が絶えないのか【Ⅱ】分析編─プロジェクトマネジメント義務の契約条項化」NBL1116号31頁〔xxxx発言〕（2018）は，「『中止提言義務，あるいは拒絶義務』は，実は契約上の合意に根拠があるように読めるのです。」とする。
（11） 前掲注（9）36頁は同様の指摘をする。
（12） xxxx「専門家責任─総論的記述にかえて─」xxxx・xxxx編『専門家責任の理論と実際』（新日本法規出版，1994） 8 頁
（13） xxx「専門家の契約責任」xxx・xxx編『新・裁判実務体系 専門家責任訴訟法』（青林書院， 2004）18頁（なお同文献19頁は，第 4 の特色として利他性・公共性を挙げるが，医師，弁護士，建築家といった職務の特色として挙げているものと考えられる。）
（14） xxx「システム開発業者のプロジェクトマネジメント義務」富山大学紀要60巻 1 号57頁（2014）は，ベンダがどのようなプロジェクト・マネジメントをとるかどうかにおける裁量に言及する。
（15） 前掲注（12）18頁は「専門家集団への信用を背景として契約関係に入っていく」点を指摘し，また，依頼者と専門家との契約関係について，「第一次的には，免許資格制に裏打ちされた当該専門家集団に対する客観的信頼関係，そして，第二次的には当該受任者に対する具体的信頼関係という二重の信頼関係に基づく高度の信頼関係を基盤として成立する契約だという特色を指摘できよう。」とする。