87〔判例研究〕

システム開発契約におけるプロジェクトマネジメント義務（東京高判平成26年 １ 月15日 LEX ／ DB 文献番号25503191）

帷

第１事案の概要等子

翔

太

併した（以下，株式会社ａとＸを区別せず「Ｘ」と
いう。）。

１

はじめに

⑴

本判決は，出版会社の情報システムを開発してＹは，平成17年 ７ 月15日，Ｘに対し，「新基幹シ提供すること等を目的とする契約に関し，ソフト

ステム開発提案依頼書」を提出し，Ｘが同月25日付

ウェアの受託開発等を業とするベンダであるＸ（原けで「『新基幹システム開発』のご提案」を提出し，告，反訴被告，被控訴人及び附帯控訴人。
）と，書これが採用された。そして，Ｘは，上記業務委託基

籍の出版及び販売等を業とするユーザであるＹ（被本契約に係る個別契約に基づいて，要件定義を行告，反訴原告，控訴人及び附帯被控訴人。）との間い，本件新基幹システムの具体的な機能（要件）がで，同システム開発を巡って，委託料及び損害賠償確定した後，同要件定義に基づいて外部設計を開始

等を相互に請求し合うこととなった事案である。

し，外部設計書の納入，検収を経てその代金が支払

⑵

われた。

本訴事件は，Ｘが，Ｙに対し，委託料及び追加業務に要した費用並びに導入支援費用等として約14

⑵

⑶

要件定義等

開発契約の締結等億円と遅延損害金の支払いを請求した事件である。

外部設計後の開発工程では，個別契約が締結され反訴事件は，Ｙが，Ｘに対し，債務不履行又は瑕ないまま，作業が行われていたことに加えて，平成

疵担保責任に基づく損害賠償として，支払済の費用

20年 ４ 月から，本件新基幹システム導入のためにＹ

及びその他費用など約14億円と遅延損害金の支払いの作業に対する導入支援業務がＸによって行われてを請求した事件である。

いたが，Ｙは，平成20年12月25日，Ｘとの間で，代２

事実関係の概要

金額 ８ 億9825万5749円として，上記業務委託基本契⑴

基本契約の締結

約に係る個別契約として，本件新基幹システムに係

株式会社ａは，Ｙとの間で，平成16年 ４ 月15日，

るソフトウェア開発個別契約（以下「本件ソフト

Ｙの次期情報システム（以下「本件新基幹システ

ウェア開発個別契約」という。
）を締結した。なお，ム」という。）の開発プロジェクト（以下「本件プ同契約では，請負契約とすること，本件新基幹シス

ロジェクト」という。）について，Ｙを委託者，株

テムを平成21年 １ 月 ５ 日までに納品し，同年 ４ 月末

式会社ａを受託者とする業務委託基本契約を締結しまでにＹが検収を行うことが合意された。

た。Ｘは，平成18年10月 １ 日，株式会社ａを吸収合88⑷

日本大学法科大学院「法務研究」 第17号

仕様変更等2020. 2は，プログラムの不具合・障害が多数発生し，収束

本件ソフトウェア開発個別契約締結前後，ＹがＸの見通しもたたない事案であり，…民法635条に基に対して，本件新基幹システムについて多数の変更

づいて，本書面をもって，本契約を解除します。」

要望を出したため，上記要件定義及び外部設計終了と通知し，本件ソフトウェア開発個別契約を解除す

後の段階になって，仕様変更が行われた。すなわる旨の意思表示をした。その後もさらに多くの不具ち，本件新基幹システムに係るソフトウェア開発

合・障害が発現しており，同日の時点では，本件新は，いわゆるスクラッチ型の開発（パッケージ製品

基幹システムに今後どの程度の障害・不具合が生のカスタマイズや機能追加，現在使用中のシステム

じ，その補修にどの程度掛かるのかについて，そのの改修などによらず，全体を新たに開発するか若し

目途が立たない状態にあった。

くは開発し直すこと）を内容とし，いわゆる「To-なお，第 １ 審の進行協議期日において，不具合・Be モデル」（あるべき業務プロセスモデルのこと）

障害か否かについて争いのあった事象のうち，X 及による新たなシステムを開発することが計画され，び Y が典型的なものとして挙げた ７ 件に関し，専上記要件定義及び外部設計が行われたものの，本件門委員が立ち会い，実機を用いた確認作業を行われソフトウェア開発個別契約締結前後になって，Y かているところ，本件新基幹システムについて，請求ら X に対し，旧システムからの移行を重視したい

書情報管理画面に関する事象（請求先のコード番号

わゆる「As-Is モデル」による仕様変更希望が多数を基に検索された件数は ９ 件と表示されるが，検索出されたものである。

条件に適合した明細は ４ 件しか表示されない。
），各⑸

顧客の請求金額，請求残金額などの詳細を把握する

解除通知等
Ｙは，Ｘに対し，平成21年 ４ 月30日，納品されたためのお客様情報照会画面に関する事象（契約先の個々のプログラムにおいて多数の不具合・障害が発変更に伴い請求残移管を行った場合件数が正しく表生したことを理由に「検収の完了に至ることが出来示されない。
）等の事象が確認されている。

ません。」と通知し，同年 ６ 月16日，前回の不合格通知の後に新たに127件の不具合・障害が発生した

第２

争点並びに第一審及び控訴審の判断ことを理由に「改めて，本契約書（注：本件ソフト

第 １ 審（ 東 京 地 判 平 成25年 ５ 月28日 判 タ1416号

ウェア開発個別契約書）に基づく貴社の納品成果物

234頁）は，本訴請求を棄却し，反訴請求のうち，が，検収不合格であることを通知させていただきま瑕疵担保に基づく損害賠償請求を一部認容した（約す」との通知をした。なお，Ｘの認識でも，同日の2300万円）。また，控訴審は，反訴請求のうち，瑕

時点で，本件新基幹システムの不具合，障害は31件

疵担保に基づく損害賠償請求の認容金額を約 ２ 億円あり，その他にも補修未了の不具合，障害が29件に変更し，附帯控訴を棄却した。
争点が多岐にわたるため，以下では，プロジェク（うち程度が高いものが １ 件，中程度が ６ 件，低いものが22件）あった。

トマネジメント義務に関連する部分に限って整理す

その上で，Ｙは，同日，Ｘに対し，以上のようなる。

経緯からすると，「貴社による納品成果物の完成は，

１

本件に現れたプロジェクトマネジメント義務に

社会通念上，履行不能となっていること，又，貴社ついてと弊社の信頼関係は完全に破壊されていることを理

本件は，ベンダのプロジェクトマネジメント義務

由に，本書面をもって，本契約を解除します。」，

を，下記のとおり，債務不履行に基づく損害賠償請「仮に，納品成果物が完成しているとしても，本件求の請求原因としてではなく，瑕疵担保責任に基づ

システム開発契約におけるプロジェクトマネジメント義務（帷子）89

く解除，損害賠償請求における瑕疵の生じた原因及が生じた原因について，「…原告において，上記のび過失相殺において考慮している。

とおり費用負担についての明確な合意がないまま被２

告により多くの変更を余儀なくされて混乱が生じ，

第 １ 審について
本件のうち反訴事件は，ＹがＸに対し，本件ソフ

納期の遵守も困難となったことにあることは容易にトウェア開発個別契約（請負契約）における仕事の推認することができる。…瑕疵の発生による責任は完成がなされていないという債務不履行に基づき，原告が負わなければならないとしても，その原因のまたは納品されたソフトウェアに不具合・障害が生

大部分は被告側から生じているというほかな」いとじているとして瑕疵担保責任に基づき，損害賠償請判示し， ８ 割の過失相殺を認めた。

求を求めるものである。

３

プロジェクトマネジメント義務は，ベンダ側の債務の内容として主張され，同義務違反を債務不履行

控訴審について控訴審は，上記第 １ 審の各判断に対し，以下のよ

うな変更をしている。

とすることが多いが，本件では，債務の内容として

第１審

控訴審

ではなく，瑕疵の生じた原因として主張されてい特 に， 原 告 は， 前 記 先「 前 記 １ ⑴ イ の とる。Ｙは，瑕疵の生じた原因としてＸのプロジェク

１ ⑴ イ の と お り， 開 おり」を，「システムトマネジメント管理能力の欠如（控訴審では，プロ発業務の全般にわた 開発等の専門的知見り「 プ ロ ジ ェ ク ト 管 や経験を有する専門

ジェクトマネジメント義務違反と追加主張してい理 」 の 責 任 が あ り， 業 者 で あ り， 本 件 プる。
）を主張し，また，Ｘの導入支援業務費用の請求に対し，同導入支援業務の債務不履行解除においてプロジェクトマネジメント義務違反を主張しているのである。

⑴

上記のとおりの事態 ロジェクトの業務委が生じたことについ 託基本契約に係る善て は， プ ロ ジ ェ ク ト 管注意義務に基づき」
マネジメント義務違 と改める。

そのような中で，第 １ 審は，瑕疵担保責任を肯定

反としての責任も免した判示（「本件新基幹システムには瑕疵があるとれないというべきでいうべきで，そのために仕事の目的は達成できない。
」）に続けて，「特に，原告は，…開発業務の全般にわたり『プロジェクト管理』の責任があり，上ある。
し か し， 上 記 瑕 疵 の 「 し か し，」の次に
発 生について 被 告 側 「控訴人が顧客であっにも原因があるという て， シ ス テ ム 開 発 等記のとおりの事態が生じたことについては，プロ

場 合 に は， 原 告 の み についての専門的知

ジェクトマネジメント義務違反としての責任も免れにその 全 ての 責 任を 見を備えているとはないというべきである。」と判示している。
また，第 １ 審は，上記判示に続けて，過失相殺による減額を肯定する。すなわち，「上記瑕疵の発生について被告側にも原因があるという場合には，原告のみにその全ての責任を負わすのは不公平であ負わすのは 不 公 平 で 認められないといっあ り， 過 失 相 殺 の 法 ても，」を加える。
⑵ 理 に より， 被 告 の 損
害 賠 償 請 求について
は， 減 額 を 認 め る のが 相 当 で あ る（ プ ロり，過失相殺の法理により，被告の損害賠償請求にジェクトマネジメント

ついては，減額を認めるのが相当である（プロジェ

義 務 違 反としての 責

クトマネジメント義務違反としての責任ととらえて任ととらえても，過失も，過失相殺が認められる。）。」と判示し，Ｙ側の過失について検討をしている。そして，多くの瑕疵

相殺が認められる。
）。

日本大学法科大学院「法務研究」 第17号

902020. 2

… 原 告 に お い て， 上 ※ 長 文 の た め， 以 下

能性を増加させ，その検収完了が遅延するおそれが記のとおり費用負担 で別途本文に記載し生じ得ることに照らせば，控訴人が被控訴人に対しについての明確な合 ている。

本件新基幹システムについて多数の変更を申し入れ

意がないまま被告

たことは，本件ソフトウェア開発個別契約の目的を（により多くの変更を余儀なくされて混乱が 生 じ， 納 期 の 遵 守も困難となったこと達成できなくなった原因の一つであると認められ，その点において控訴人に過失のあることを否定できないのである。
」⑶ にあることは容易に④「しかし，本件ソフトウェア開発個別契約におい推認することができては，控訴人から被控訴人に対して仕様書等の変更

る。 … 瑕 疵 の 発 生 にの申入れがあった場合，その申入れから14日以内

よる責任は原告が負わなければならないと し て も， そ の 原 因の大部分は被告側かに，控訴人及び被控訴人は変更の内容及びその可否につき協議を行い，変更の可否につき決定するものと約定されており，その期間に協議が調わない場

ら生じているという合，被控訴人は，従前の仕様書等に基づき本件業務ほかな」いを遂行するものし，控訴人はこれを了承する旨が約定されている（ ３ 条 ３ 項）ことからすれば，被控訴（上記表⑶控訴審部分）

人は，控訴人の変更申入れを応諾する契約上の義務①「控訴人は，顧客であって，システム開発等につを負わず，契約上これを拒絶することができるのでいての専門的知見を備えているとは認められないのある。そして，控訴人がシステム開発等についてのに対し，被控訴人は，システム開発等の専門的知見

専門的知見を備えているとは認められない顧客であや経験を備えた専門業者であって，本件新基幹シス

るのに対し，被控訴人は，システム開発等の専門的テムに多数の不具合・障害という瑕疵を発生させた知見や経験を備えた専門業者であって，控訴人からのは被控訴人であることが認められる。」の変更の申入れに応じることが，本件新基幹システ②「そして，その原因の一つとして，控訴人と被控ムにおける不具合・障害の発生の可能性を増加さ

訴人との間で費用負担についての明確な合意がない

せ，そのために検収終了時期を大幅に遅延させ，本まま，被控訴人が控訴人の変更要求に応じて多くの件ソフトウェア開発個別契約の目的を達成できなく変更をして混乱が生じ，約定された検収完了時期のなる場合においては，本件プロジェクトの業務委託

遵守も困難になったことがあると認められる。ま基本契約に基づく善管注意義務及び本件ソフトウェ

た，上記瑕疵のために上記検収期間終了時においてア開発個別契約における付随的義務として，その専検収が終了せず，その時期が上記予定よりも大幅に門的知見，経験に照らして，これを予見した上，控遅れ，控訴人の現行システムのホストコンピュータ

訴人に対し，これを告知して説明すべき義務を負うの保守期間である平成21年 ９ 月30日の満了後もなおものであって，なお，控訴人が変更を求めるとき

長期間を要する状態になれば，社会通念上，本件ソは，これを拒絶する契約上の義務があると認められフトウェア開発個別契約の目的を達成できなくなるるのである。そして，被控訴人において，これを予のであって，このことを控訴人が認識していた。
」

見することが困難であったとは認められないので③「そして，外部設計後に多数の変更を行えば，本あって，被控訴人のこのような義務違反が控訴人の件新基幹システムにおける不具合・障害の発生の可

上記過失の一因となっていることが否定できないの

システム開発契約におけるプロジェクトマネジメント義務（帷子）である。」⑤「また，控訴人において担当していたデータの移行作業に不適切さのあったことも，本件新基幹シス

第３91

検討（控訴審の判断に賛成）（1）

１

本判決の意義テムにおける不具合・障害という瑕疵発生の原因の本件は，第 １ 審，控訴審ともに，ベンダであるＸ

一つであると認められ，この点において，控訴人にからの委託料等の請求を棄却し，ユーザであるＹか

過失のあることを認めることができる。」

らの瑕疵担保に基づく解除及び損害賠償請求を肯定⑥「しかし，控訴人がシステム開発等についての専しつつも，過失相殺によって，同損害賠償について門的知見を備えているとは認められない顧客である

一定の減額を行い，また，過失相殺の割合を判断すのに対し，被控訴人は，システム開発等の専門的知るにあたって，ベンダ側のプロジェクトマネジメン

見や経験を備えた専門業者であって，控訴人の上記ト義務違反を考慮している。ベンダ側のプロジェク

データ移行作業の不適切さが，本件新基幹システム

トマネジメント義務を踏まえつつ，瑕疵のリスクをにおける不具合・障害の発生の可能性を増加させ，ベンダとユーザとの間で分担するよう解決を示した

そのためにその検収終了時期を大幅に遅延させ，本ように見受けられ，その点について意義があるもの

件ソフトウェア開発個別契約の目的を達成できなくと思われる。

なる場合においては，本件プロジェクトの業務委託

ただし，第 １ 審ではユーザ ８ 割，ベンダ ２ 割の責

基本契約に基づく善管注意義務及び本件ソフトウェ

任だったものが，控訴審では，ユーザ ４ 割，ベンダ

ア開発個別契約における付随的義務として，その専６ 割となっており，控訴審において，ベンダの責任

門的知見，経験に照らし，これを予見した上，このが重くなっている。

ような事態を回避するために，控訴人に告知し，控２システム開発に関する一般論

訴人のデータ移行作業に特段の対応が必要であると⑴

一般的な流れいうのであれば，その旨の指摘・指導をすべき義務システム開発の開発手法は様々であり，その生産を負うと認められる。そして，被控訴人において，過程も一つには決まらない。システム開発の手法はこれを予見することが困難であったとは認められな様々であり，一概にはいえないが，基本系 を示す

いのであって，被控訴人のこのような義務違反が控と以下のような形となる。

訴人の上記過失の一因となっていることが否定でき

①

（2）

（3）

ユーザによる業務のシステム化計画又は既存システムの再構築計画

ないのである。」「…その減額の割合は ４ 割と認めるのが相当であ②

ベンダへの開発依頼

る」③

ベンダによるユーザからの要求聴取，システム化に必要な要件の分析④

システムの仕様の確定（要件定義を含む）＊ 要件定義：システム化計画を受けて，業務上（1）

第 １ 審の評釈として，武川幸嗣「ソフトウェア開発契約における瑕疵担保責任の有無及び内容」リマーク
ス53号38頁（2） 司法研修所編『民事訴訟における事実認定─契約分野別研究（製作及び開発に関する研究）─』（法曹会，2014）92頁，東京地方裁判所プラクティス委員会第二小委員会「ソフトウェア開発関係訴訟の手引」判タ1349号 ４ 頁（2011）参照（3） ㈳情報サービス産業協会法的問題委員会契約部会『新しいソフトウェア開発委託取引の契約と実務』（商事
法務，2002）32頁以下参照

日本大学法科大学院「法務研究」 第17号

92の要求を業務要件に，システムに実装すべきシ⑶

2020. 2

上流工程について前記工程において特に重要なものが，上流工程とステムの機能要件・非機能要件を定義する段階⑤

基本設計を行い，開発の製造工程に入るいわれる「要件定義」「基本設計（外部設計）」と言⑥

テスト工程とはわれる部分である。システムの仕様確定作業を中心

⑵

開発方式

的に行う工程である。

システム開発の方式として古くからウォーターこれらの工程ではユーザのイメージするシステム

フォール型の手法が用いられることが多く，今なお像とベンダの構築しようとするシステム像のすり合主流である。

わせを行う工程で，互いに情報提供が求められる共（4）ウォーターフォール型は，システム開発の過程

同作業の工程である。ここでシステム全体の仕様がを，「企画」「要件定義」「基本設計（外部設計）」決定され，順を追って仕様に関する合意が形成され「詳細設計（内部設計）」「開発」「テスト」「運用」

る。システムによって実現したい内容，そのため求といった工程に分割し，全行程の成果物の内容によめる機能，性能，予算・運用開始期限・使用するり後工程の作業内容を画し，原則として後工程からサーバーやパソコンの機種，数量，設置場所などの前工程への後戻りを認めないとする方式である。比制約を整理・分析の上，徐々に決定される。このよ較的規模の大きいシステムの開発に用いられるとさうに，ユーザとベンダとの相互のコミュニケーショ

れ，本事案でも用いられた方法である。

ンが極めて重要といえるのであり，両者の認識に齟

（システム開発における代表例：ウォーターフォー

齬があれば，その後の開発に決定的な影響を与えてル型）

しまうものになる。

（5）⑷

システム開発契約の特色
システム開発契約の特色として，以下のような ３点を挙げることができる。

（6）①

専門的知見の必要性

システムは無形の存在であり製作や内部の仕組みに関する専門的知見を要する。
②

仕様の不確実性，システムの不可視性完成すべきシステムの仕様が当初から定まっておらず，抽象度が高く，概括的であって，可視性も低
い。
③

（4）

ユーザとベンダの協力関係の必要性

ウォーターフォール型のほか，プロトタイプ型（工程を区分せずにユーザの要望から試作品を作成・提示・計画する開発方式），スパイラル方式（比較的密接に関連した機能ごとに開発を区分し，区分ごとに設計，プログラミング，テストを短い周期で繰り返し，ユーザからのフィードバックを得ながら全体を完成させる開発手法），アジャイル型（開発対象を多数の小さな機能に分類し，1つずつ機能を開発していくもの。）などがある。なお，スパイラル方式とアジャイル方式との違いは，前者が全体を想定しながら徐々に品質を高めていくものに対し，後者は部分，部分を徐々に作る発想である点にある（難波修一ほか『裁判例から考えるシステム開発紛争の法律実務』（商事法務，2017年）20〜22頁）。
（5） 経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む），保守運用）〈第一版〉」31頁（2006）（http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05）（6） 田中俊次ほか「ソフトウェア開発関連訴訟の審理」判タ1340号5頁（2011）

システム開発契約におけるプロジェクトマネジメント義務（帷子）

ユーザの業務内容ニーズとベンダの専門知識や技能とを照らし合わせる等の協力関係が必要で（シス93（8）

法行為を構成するという見解などが見受けられる。
⑵

東京土建国民健康保険組合事件（東京地判平成テムの内容は千差万別でありオーダーメイド的性格

16年 ３ 月10日判タ1211号129頁）

を有するものであるから，ユーザからデータその他

当該判決は，裁判例で初めてプロジェクトマネジの提供，ユーザとベンダの間の円滑な意思疎通なメント義務に言及した判決である。健康保険組合でど， 緊 密 な 協 力 関 係 が な け れ ば 構 築 は 困 難 に なあるユーザが，ベンダとの間で電算システム開発業

る。），両者の協力関係を前提に，変更及び調整を重務委託契約を締結し，第 ２ 次電算システム及び共済

ねながら，システムの仕様を具体化していくことがシステムの構築を委託したが，納入期限までにシス要求される。

テムを完成させなかったなどとして，同契約の債務

このように，システム開発契約においては，専門的知見を要し，システムの仕様がもともと抽象的・不履行解除を原因として原状回復請求権に基づき，既払委託料の返還等を請求したものである。

概括的であり，ユーザとベンダが協力して内容を段

同判決は，プロジェクトマネジメント義務につい階的に定めていくという点に特色がある。また，て①合意した開発手順，開発手法，作業工程等にユーザとベンダとの間で形成されたシステムに関す従って開発作業を進めるとともに，常に進捗状況をる合意は，個々の項目ごとではなくシステム全体と管理し，開発作業を阻害する要因の発見に努め，この関係で有機的一体としての合意が形成されているれに適切に対処すべき義務，②ユーザの開発へのかと評されている。

かわりについても，適切に管理し，システム開発に

２

裁判例等

ついて専門的知識を有しないユーザによって開発作⑴

背景業を阻害する行為がされることのないようユーザに（7）

上記のとおり，システム開発契約においてはユー
ザとベンダの相互の信頼関係が不可欠であり，相互の協力なしにはシステム開発は成功しない。

働きかける義務とした。
⑶

スルガ銀行・日本ＩＢＭ事件（東京高判平成26
年 １ 月15日金判1428号16頁）

このような状況の中，相互の協力に関する義務にＩＢＭをベンダ（控訴人）スルガ銀行をユーザ関して登場した概念が，ベンダのプロジェクトマネ

（被控訴人）とするシステム開発において，複数のジメント義務とユーザの協力義務である。後述のよ基本合意と個別契約を締結したが，プロジェクトがうな裁判例にも登場しているが，その根拠は必ずし途中で頓挫した事案で，次のとおり判示されていも明らかにされていない状況である。なお，根拠にる。

ついて，プロジェクトマネジメント義務に関して「控訴人は，前記各契約に基づき，本件システム

は，①ベンダの仕事を完成させる義務の「要素たる開発を担うベンダとして，被控訴人に対し，本件シ義務」と見る見解，②仕事の完成という主たる義務

ステム開発過程において，適宜得られた情報を集に付随的な義務，③仕事が完成せずに頓挫した場

約・分析して，ベンダとして通常求められる専門的合，その頓挫の原因が当該義務違反であれば債務不知見を用いてシステム構築を進め，ユーザーである

履行責任を構成するとする見解，④③とは異なり不被控訴人に必要な説明を行い，その了解を得なが（7）

司法研修所編『民事訴訟における事実認定─契約分野別研究（製作及び開発に関する研究）─』（法曹会，2014）108頁（8） 藤谷護人「『プロジェクトマネジメント義務』判決と法的諸問題」Information Network Law Review
Vol.12（2013年）144頁。

94

日本大学法科大学院「法務研究」 第17号

2020. 2

ら，適宜必要とされる修正，調整等を行いつつ，本というべきである。
」

件システム完成に向けた作業を行うこと（プロジェ⑷

クト・マネジメント）を適切に行うべき義務を負う

札幌高判平成29年 ８ 月31日判時2362号24頁
病院情報管理システムを構築して提供することをものというべきである。」

目的とするシステム開発契約に関し，当該システム「また，前記義務の具体的な内容は，契約文言等の構築が頓挫したことにつき，ユーザ（原告）とベから一義的に定まるものではなく，システム開発のンダ（被告）との間で，相互に損害賠償等を請求し遂行過程における状況に応じて変化しつつ定まるも合うことになった事案である。ユーザは，債務不履のといえる。すなわち，システム開発は必ずしも当行に基づく損害賠償として，約19億円の支払いを請初の想定どおり進むとは限らず，当初の想定とは異求し，ベンダは，システムの完成及び引渡しが遅れなる要因が生じる等の状況の変化が明らかとなり，たことにつきユーザの協力義務違反等により，完成想定していた開発費用，開発スコープ，開発期間等義務を履行し得なくなったことにつき，主位的にはについて相当程度の修正を要すること，更にはその債務不履行に基づく損害賠償として約23億円の支払

修正内容がユーザーの開発目的等に照らして許容限いを請求している。

度を超える事態が生じることもあるから，ベンダと札幌高裁は「システム開発はベンダである被告のしては，そのような局面に応じて，ユーザーのシス

努力のみによってなし得るものではなく，ユーザでテム開発に伴うメリット，リスク等を考慮し，適時ある原告の協力が必要不可欠であって，原告も，被適切に，開発状況の分析，開発計画の変更の要否と告による本件システム開発に協力すべき義務を負その内容，更には開発計画の中止の要否とその影響う。
」「そして，この協力義務は，本件契約上原告の等についても説明することが求められ，そのような責任とされていたもの（マスタの抽出作業など）を説明義務を負うものというべきである。

円滑に行うというような作為義務はもちろん，本件「控訴人は，被控訴人と本件最終合意を締結し，契約及び本件仕様凍結合意に反して大量の追加開発

本件システム開発を推進する方針を選択する以上，要望を出し，被告にその対応を強いることによって被控訴人に対し，ベンダとしての知識・経験，本件

本件システム開発を妨害しないというような不作為システムに関する状況の分析等に基づき，開発費義務も含まれているものというべきである。
」「原告

用，開発スコープ及び開発期間のいずれか，あるいが本件契約及び本件仕様凍結合意に反して大量の追はその全部を抜本的に見直す必要があることについ加開発要望を出し，被告がこれに対応せざるを得なて説明し，適切な見直しを行わなければ，本件シスかったことから，本件システム開発が遅延した。ま

テム開発を進めることができないこと，その結果，た，（略），原告がマスタの抽出義務を負っていたに

従来の投入費用，更には今後の費用が無駄になるこもかかわらず，これを懈怠し，原告の協力が得られとがあることを具体的に説明し，ユーザーである被

ないまま被告が代行せざるを得なくなったことも，

控訴人の適切な判断を促す義務があったというべき

本件プロジェクトが遅延した理由の一つになっていである。また，本件最終合意は，前記のような局面る。
」と判断し，原告の「本件契約上の協力義務違において締結されたものであるから，控訴人は，ベ反（債務不履行）が認められる」とした。

ンダとして，この段階以降の本件システム開発の推

また，「被告は，平成21年 ３ 月 ４ 日以降，専門部進を図り，開発進行上の危機を回避するための適時会等において，繰り返し，原告による追加開発要望

適切な説明と提言をし，仮に回避し得ない場合にはの多くは仕様外のものであること，被告としては，

本件システム開発の中止をも提言する義務があった

これらの追加開発要望に対応するのは難しく，同年

システム開発契約におけるプロジェクトマネジメント義務（帷子）95（9）９ 月24日に間に合わなくなることを説明した」こしているか否かにあると考えられる。すなわち，と，「被告が625項目の追加開発要望を受け入れる一

控訴審は，「外部設計後に多数の変更を行えば，本方，以後は，新たな機能の開発要望はもちろん，画件新基幹システムにおける不具合・障害の発生の可面や帳票，操作性に関わるものも含め，一切の追加

能性を増加させ，その検収完了が遅延するおそれが開発要望を出さないという合意（本件仕様凍結合生じ得ることに照らせば，控訴人が被控訴人に対し意）を取り付けた」ことを指摘し，「被告は，プロ

本件新基幹システムについて多数の変更を申し入れ

ジェクトマネジメント義務の履行として，追加開発たことは，本件ソフトウェア開発個別契約の目的を要望に応じた場合は納期を守ることができないこと達成できなくなった原因の一つであると認められ，を明らかにした上で，追加開発要望の拒否（本件仕その点において控訴人に過失のあることを否定でき

様凍結合意）を含めた然るべき対応をしたものと認ないのである。
」と判示しながらも，「しかし，本件められる」とした。その上で，「これを越えて，被ソフトウェア開発個別契約においては，控訴人から告において，納期を守るためには更なる追加開発要被控訴人に対して仕様書等の変更の申入れがあった

望をしないよう注文者を説得したり，原告による不場合，その申入れから14日以内に，控訴人及び被控

当な追加開発要望を毅然と拒否したりする義務が訴人は変更の内容及びその可否につき協議を行い，あったということはできず，被告にプロジェクトマ

変更の可否につき決定するものと約定されており，

ネジメント義務の違反があったとは認められない」

その期間に協議が調わない場合，被控訴人は，従前として，履行遅滞に関する帰責性，過失相殺の対象の仕様書等に基づき本件業務を遂行するものし，控となるべき過失を否定した。

訴人はこれを了承する旨が約定されている（ ３ 条 ３⑸項）ことからすれば，被控訴人は，控訴人の変更申本判決におけるプロジェクトマネジメント義務の位置づけ等入れを応諾する契約上の義務を負わず，契約上これ

第 １ 審及び控訴審は，いずれも，瑕疵担保責任がを拒絶することができるのである。そして，控訴人問題となった事案において，瑕疵が生じているこがシステム開発等についての専門的知見を備えていと，そのために契約目的を達成できないこと及びそるとは認められない顧客であるのに対し，被控訴人の責任がベンダであるＸにあることを前提に，過失は，システム開発等の専門的知見や経験を備えた専相殺をし，その際，ベンダであるＸのプロジェクト

門業者であって，控訴人からの変更の申入れに応じマネジメント義務を考慮している点は共通していることが，本件新基幹システムにおける不具合・障る。

害の発生の可能性を増加させ，そのために検収終了

もっとも，第 １ 審は，ユーザであるＹの仕様変更

時期を大幅に遅延させ，本件ソフトウェア開発個別等の要求が瑕疵の生じた主たる原因であるとして ８契約の目的を達成できなくなる場合においては，本割の過失相殺を認めている一方で，控訴審は，ユー

件プロジェクトの業務委託基本契約に基づく善管注

ザであるＹの要求が瑕疵の原因であることを認めつ

意義務及び本件ソフトウェア開発個別契約における

つも， ４ 割の過失相殺としている。

付随的義務として，その専門的知見，経験に照らし判断が異なった背景には，ベンダの専門性を重視て，これを予見した上，控訴人に対し，これを告知（9） 松尾剛行「近似のシステム開発紛争事例に見る紛争解決の判断ポイント」Business Law Journal141号35頁（2019）は，「第 １ 審においてはユーザ側の落ち度が独立に問題とされたのに対し，控訴審においては，プロジェクトマネジメント義務の判断において，ユーザの非専門性が考慮されたと思われる。」とし，ユーザ側に落ち度があっても「ベンダ側はそれを漫然と見過ごすのではなく，システム開発の専門家として適切に助言をすべき義務が含まれると認められたことが大きかったのではないかと理解される。」とする。

96

日本大学法科大学院「法務研究」 第17号

2020. 2

して説明すべき義務を負うものであって，なお，控る。また，ユーザであるＸのデータ移行作業に不適訴人が変更を求めるときは，これを拒絶する契約上切さがあっても，これを予見し，指導助言する義務の義務があると認められるのである。そして，被控があるとする。

訴人において，これを予見することが困難であった

注文者であるユーザ側から，様々要望がなされるとは認められないのであって，被控訴人のこのようことはシステム開発においてはみられるところであな義務違反が控訴人の上記過失の一因となっている

るが，同要求を拒絶する義務や，ユーザの不適切なことが否定できないのである。」と判示している。

行動について指導助言まですべき義務というのは，また，「控訴人において担当していたデータの移

本来対等が原則であるはずの契約当事者において，行作業に不適切さのあったことも，本件新基幹シス

ベンダ側に高度の義務を課すものであると考えられテムにおける不具合・障害という瑕疵発生の原因のるところ，この判断には，ベンダが「本件プロジェ一つであると認められ，この点において，控訴人にクトの業務委託基本契約に基づく善管注意義務及び過失のあることを認めることができる。」と判示し本件ソフトウェア開発個別契約における付随的義ているが，「しかし，控訴人がシステム開発等につ務」を負っているだけでなく，システム開発の専門

いての専門的知見を備えているとは認められない顧家であるのに対し，ユーザが素人であるという考え客であるのに対し，被控訴人は，システム開発等の方が根底にあると思われ，したがって，ベンダの負

専門的知見や経験を備えた専門業者であって，控訴うプロジェクトマネジメント義務を，専門家として人の上記データ移行作業の不適切さが，本件新基幹の責任に位置付けているものと考えられる。

システムにおける不具合・障害の発生の可能性を増

ただし，控訴審は，ユーザの要求を拒絶すべき義加させ，そのためにその検収終了時期を大幅に遅延務があることの根拠として，「本件プロジェクトのさせ，本件ソフトウェア開発個別契約の目的を達成

業務委託基本契約に基づく善管注意義務及び本件ソできなくなる場合においては，本件プロジェクトのフトウェア開発個別契約における付随的義務」だけ

業務委託基本契約に基づく善管注意義務及び本件ソでなく，「本件ソフトウェア開発個別契約において

フトウェア開発個別契約における付随的義務としは，控訴人から被控訴人に対して仕様書等の変更のて，その専門的知見，経験に照らし，これを予見し申入れがあった場合，その申入れから14日以内に，た上，このような事態を回避するために，控訴人に控訴人及び被控訴人は変更の内容及びその可否につ告知し，控訴人のデータ移行作業に特段の対応が必き協議を行い，変更の可否につき決定するものと約要であるというのであれば，その旨の指摘・指導を定されており，その期間に協議が調わない場合，被すべき義務を負うと認められる。そして，被控訴人

控訴人は，従前の仕様書等に基づき本件業務を遂行において，これを予見することが困難であったとはするものし，控訴人はこれを了承する旨が約定され認められないのであって，被控訴人のこのような義ている（ ３ 条 ３ 項）ことからすれば」と契約条項を務違反が控訴人の上記過失の一因となっていること挙げていることから，一般的に専門家の責任としてが否定できないのである。」と判示している。

挙げられるいわゆる説明義務を超えて，要求の拒絶

このように，控訴審は，ユーザであるＹの要求が義務まで課すためには，ベンダが専門家であること

瑕疵の原因であることを認めつつも，Ｘがシステムに加えて，契約条項が必要になると考えられる可能開発等の専門的知見や経験を備えた専門業者である性がある一方で，ユーザの行動に対して指導助言す

ことを踏まえ，Ｙから仕様変更等多数の申し入れがべき義務を導くにあたっては，契約条項を根拠としあったとしても，これを拒絶する義務があるとすていないため，善管注意義務等とベンダの専門性かシステム開発契約におけるプロジェクトマネジメント義務（帷子）97

ら上記のような各義務を導くことができる可能性も者間の原則的非対等性，専門家の裁量及び信頼関係ある。

を基盤とする契約という点が挙げられている。そ⑹

して，これらは，以下の表のとおり，システム開発（10）

前掲札幌高判平成29年 ８ 月31日との比較（13）

前掲札幌高判平成29年 ８ 月31日は，ユーザ側から契約についても当てはまるものと考えられる。もっ

多数の要望や仕様変更要求が多数寄せられた結果，とも，その具体的な内容や程度等については，シス

引き渡し予定日にシステムが完成せず，紛争に至っ

テム開発契約の特殊性等を踏まえた検討が必要であており，ユーザ側から仕様変更の要望があった点でると考えられ，今後の検討課題としたい。

は本判決と共通している。しかし，前掲札幌高判平

専門家との契約の特色

システム開発契約

成29年 ８ 月31日は，ベンダ側の帰責性を否定し，反ベンダはシステム開発

対にユーザ側の協力義務違反という債務不履行を否① 契 約 当 事 者 間 の 原 の 専 門 家 で あ る 一 方，則的非対等性定して，本判決とは異なる結論を出している。

契約について素人

このような結論の相違には，開発のとん挫に至る

ユーザの求めるシステム

経緯（ベンダ側がユーザ側の仕様変更の要望等に対開発をするため，どのよ

し，十分な説明を尽くしたかどうか等）が影響していると考えられ，ベンダ側が十分な説明を尽くして（11）

いれば，それ以上に義務を負わず，したがって，うな手法を用いるか等に②

専門家の裁量（14）られる。

できるのではないだろうか。
専門家との契約形態については，典型契約として委任契約や請負契約あるいはこれに類似する無名契

ユ ー ザ は， ベ ン ダ の 専③（15）

信頼関係を基盤と

する契約

（12）

門的知見や経験等を信頼 し て 契 約 を 締 結 し，システム開発を依頼するといえる。

約といった類型が利用される ところ，システム開発契約についても，法的性質が明らかにされていな

進めるとはいえ，その選一定の裁量があると考えの進捗等に応じた各種の説明義務ととらえることがいわゆる専門家との契約との共通性等

つき，ユーザと協力して択等についてはベンダにプロジェクトマネジメントの中核は，プロジェクト⑺

ユーザはシステム開発以上いものの，基本的には当てはまると考えられる。また，専門家契約の特色として，一般的に，契約当事（10） 影島広泰ほか「座談会システム開発取引はなぜ紛争が絶えないのか【Ⅱ】分析編─プロジェクトマネジメ
ント義務の契約条項化」NBL1116号31頁〔影島広泰発言〕（2018）は，「『中止提言義務，あるいは拒絶義務』
は，実は契約上の合意に根拠があるように読めるのです。」とする。
（11） 前掲注（9）36頁は同様の指摘をする。
（12） 山川一陽「専門家責任─総論的記述にかえて─」山川一陽・根田正樹編『専門家責任の理論と実際』（新日
本法規出版，1994） ８ 頁（13） 下森定「専門家の契約責任」川井健・塩崎勤編『新・裁判実務体系 専門家責任訴訟法』（青林書院，
2004）18頁（なお同文献19頁は，第 ４ の特色として利他性・公共性を挙げるが，医師，弁護士，建築家といった職務の特色として挙げているものと考えられる。）（14） 高田寛「システム開発業者のプロジェクトマネジメント義務」富山大学紀要60巻 １ 号57頁（2014）は，ベンダがどのようなプロジェクト・マネジメントをとるかどうかにおける裁量に言及する。
（15） 前掲注（12）18頁は「専門家集団への信用を背景として契約関係に入っていく」点を指摘し，また，依頼者と専門家との契約関係について，「第一次的には，免許資格制に裏打ちされた当該専門家集団に対する客観的信頼関係，そして，第二次的には当該受任者に対する具体的信頼関係という二重の信頼関係に基づく高度の信頼関係を基盤として成立する契約だという特色を指摘できよう。」とする。