ウォーターフォール・モデルにおいてはまず初めに，①「要件定義」が行われる。ここではユーザが RFP（Request for Proposal）と呼ばれる資料を 作成し，ベンダに自社の要望を伝える。ベンダはこれを基に，導入するシステムにどのような機能を持たせるのか，どのような速度でどのような使い勝手にするのか等をまとめ た「要件定義書」を作成する。以降のシステムの設計・開発はこの「要件定義書」に基づいて行われることになる。次に，②「外部設計」ないし「概要設計」において，ベンダ...
ベンダのプロジェクトマネジメント義務とユーザの協力義務
――システム開発契約に関する 3 件の高裁判決の検討を中心として――
x x x
x x x 学 x x. 富 大 経 済 論 集 第67巻第 1 号抜刷（2021年8月）
富山大学経済学部
ベンダのプロジェクトマネジメント義務とユーザの協力義務
―― システム開発契約に関する3 件の高裁判決の検討を中心として ――
x x x
キーワード：システム開発契約，プロジェクトマネジメント義務，協力義務
1 はじめに
2 システム開発契約と性質決定
3 裁判例の紹介
4 裁判例の検討
5 おわりに
1 はじめに
企業活動における業務の効率化や省力化を目的としたシステム化が進む中，システム開発をめぐる紛争が多く生じている。システム開発が途中で頓挫したり，完成したシステムがユーザの求めるものでなかった場合についてのベンダの責任が争われることが多く，裁判例はこれをベンダの「プロジェクトマネジメント義務」の違反の有無という形で扱ってきた。一方で，その義務の内容や位置づけについては学説上共通した理解が確立しているわけではなく，そもそもシステム開発契約自体をどのように性質決定するかについても議論が分かれている。
また，システム開発契約はベンダとユーザの共同作業といわれることがあり，プロジェクトマネジメント義務違反の有無が争われた裁判例の多くで，併せて
ユーザの協力義務も問題となっている。もっとも，ユーザの協力「義務」といっても，これをシステム開発契約上のユーザの義務として検討する裁判例がある一方，ベンダのプロジェクトマネジメント義務違反の有無や，それに基づく損害賠償における過失相殺の判断において，ユーザがしかるべき協力をしたか否かを評価する裁判例もある。
ベンダのプロジェクトマネジメント義務とユーザの協力義務は，その適用領域が交錯することも少なくなく，議論すべき余地が残されているように思われる。そこで本稿は，ベンダのプロジェクトマネジメント義務違反が争われた 3件の高裁判決の検討を通じ，プロジェクトマネジメント義務や協力義務の内容と根拠，さらには両義務の関係について一定の整理を試みる。
2 システム開発契約と性質決定
（1） システム開発契約の流れ
システム開発とは，業務のシステム化による効率化や省力化を目的として，企業がシステム開発業者に依頼するものである。システム開発の依頼を受けた開発業者をベンダ，システム開発の依頼者をユーザといい，両者の間でシステム開発契約が締結される。以下で述べるようにシステム開発契約の法的性質は議論のあるところであるが，請負契約であるとすればベンダが請負人，ユーザが注文者となり，準委任契約であるとすればベンダが受任者，xxxが委任者となる。
企業の基幹業務を担うシステムの開発等では，巨費を投じ長期間にわたってプロジェクトが進められることが少なくない。そのため，開発プロジェクトを時系列で作業工程ごとに分割し，これらの工程を順に遂行していく「ウォーターフォール・モデル」の開発手法に従って，契約の締結，履行が行われるのが主
流である 1。
ウォーターフォール・モデルにおいてはまず初めに，①「要件定義」が行われる。ここではユーザが RFP（Request for Proposal）と呼ばれる資料を作成し，ベンダに自社の要望を伝える。ベンダはこれを基に，導入するシステムにどのような機能を持たせるのか，どのような速度でどのような使い勝手にするのか等をまとめた「要件定義書」を作成する。以降のシステムの設計・開発はこの「要件定義書」に基づいて行われることになる。次に，②「外部設計」ないし「概要設計」において，ベンダが画面やデータベースを設計する。続く③
「内部設計」では，技術的な設計を行う。最後に，④「プログラミング」を行い，テストをして成果物が完成する 2。なお，①～③の各段階でも，システムが要求通りに動作するかの確認，バグを検出し修正するためのテストが都度行われる。
本稿で取り上げる裁判例はいずれもウォーターフォール・モデルのシステム開発契約であり，以下では同モデルを念頭に置いて議論を進めることとする 3。
（2） 建築請負契約との異同
システム開発契約の多くは上述したウォーターフォール・モデルに沿って締結・履行されることから，設計図の作成から始まり段階的に施行が完了する建
1 xxxxほか『IT ビジネスの契約実務』（商事法務，2017 年）23 頁。複数の作業工程が並行して行われることや，次の工程に進んでから前工程に戻ることは想定されておらず，滝が上から下に流れ落ちるように開発が進むことから「ウォーターフォール・モデル」と呼ばれている。
2 xxxxほか「座談会 システム開発取引はなぜ紛争が絶えないのか（1）～（2・完）」 NBL1115 号4 頁，1116 号28 頁（いずれも2018 年）。特に1115 号5 頁参照。また，以上の各用語の定義について，参照，xxxx編『法律家・法務担当者のためのIT 技術用語辞典』（商事法務，2017 年）121 ～ 122 頁。
3 この他の開発手法として，アジャイル開発やデブオプス（DevOps）が挙げられる。これらはいずれも，テスト段階になってから機能不足が明らかになり手戻りせざるを得なくなるというウォーターフォール・モデルのデメリットを克服しようとするものであり，開発と運用を密に協力して行う点に特徴がある。xx編（2017 年）・前掲注2・122 ～ 123 頁，xxxxx『AI の法律』（商事法務，2020 年）197 ～ 198 頁。
築請負契約に類似しているとされている 4。またいずれの契約においても，請負人の設計・施工の管理に関わる義務，打合せ等への注文者の協力義務が問題になる場面が想定されよう。一方で，実務上，システム開発契約においては建築請負契約とは異なるトラブルが生じることが指摘されている 5。そこで，本稿の検討対象であるシステム開発契約におけるベンダのプロジェクトマネジメント義務，ユーザの協力義務の検討の前提として，建築請負契約とシステム開発契約との異同につき以下で整理しておくこととする。
異同の一点目として，ステム開発の性質上，成果物やその過程が目に見えず，ユーザにとっては設計図からも成果物が想像しづらいことが挙げられる。建築請負契約においては，設計図から注文主も完成物の予測をある程度立てることができ，実際の建材の様子等も目視で確認することができる。一方，システム開発におけるユーザは，ベンダの SE（システムエンジニア）が作成した設計図を見ても理解できないことがほとんどである 6。結果として，成果物がユーザの想定していたものと異なることが後から判明し，トラブルが生じることがある。
二点目として，xxxとベンダの共通認識が不足しているという問題がある。建築請負契約においては，注文者と請負人との間の，建築における可能不可能についての認識の差が問題になることはさほどない。物理学上の制約や予算等との兼合いで不可能なことは注文者にもある程度認識できるためである。この
4 xxx＝xxxx編『講座 現代の契約法 各論3』（青林書院，2019 年）317 頁〔xxxx執筆部分〕。建築請負契約では成果物がどのようなものになるか，どのような手法で施工していくのかが設計図という形で示されるのに対し，システム開発契約においても「要件定義書」が作成され，これに沿ってシステムが設計されていくことになる。
5 影島ほか（2018 年（1））・前掲注2・6 ～ 8 頁。
6 この点，同じSE であっても他のSE の作った設計図を読みとくのは困難な場合があるとの指摘がある。同上6 頁。であるとすれば，「要件定義書」等からユーザが成果物や開発工程を予測しづらかったり，そもそも「要件定義書」がユーザの真の希望を反映したものになっていないといった問題は，ユーザと専門家であるベンダとの知識の差のみによるものとは単純に言い切ることができないのではないか。
点，システム開発においては，ユーザはそもそも何ができて何ができないのかが分かっていないことがある。このため，ユーザの要望が実は例外的な要求であって，そのことが後から判明してトラブルになることがある 7。
三点目として，建築における建築確認がシステム開発契約においては存在しない。建築請負契約では建築基準法，構造計算，耐震基準等があり，建築確認を経ていれば最低限人が住むことのできる建築物が完成する。一方，システム開発では現在のところ国が稼働性を確認する仕組みや最低限の基準がないため，まったく動かないシステムが完成することもあり得る。
四点目として，修正のコストが挙げられる。もっともこの点については，建築請負契約においても，すでに施工した部分に修正すべき点が見つかった場合，おおがかりな修正作業が必要になる可能性はある。システム開発契約の場合，何らかの不具合が見つかったとしても，ハード自体の不具合か，ハードに入っているソフトウェア（OS）の不具合か，その上に新しく構築しようとしているシステム（アプリケーション）の不具合かただちに特定できないため，人海戦術的に探して修正するしかなく，莫大な時間と費用がかかるとされる。特に，前述したウォーターフォール・モデルでは手戻りが想定されていないため，テストの段階になって機能不足が明らかになるケースが多発することが指摘されている 8。
以上のように，システム開発契約には建築請負契約との類似点が認められる
7 この点については，同上7 頁において以下のような例が挙げられている。「たとえば建物であれば，普通ドアはノブを引けばすぐ開くだろう。でも，システムでは，処理上，開けるのに1 分はかかるかもしれない。しかし，ユーザ側は0.1 秒で開くことを想定しているかもしれない。ここにお互いの考える常識，共通認識に差がある。」このような場合，システムの完成後にユーザが想定していたシステムになっていないことが判明する一方で，xxxにとっては例外的な要求をするのであれば契約締結時ないし「要件定義書」作成の段階で言ってもらわなければ困るということになるのであろう。両者に共通認識がないために，xxxはそれがそもそも例外的な要求であることを理解しておらず，結果として不要のシステムが完成してしまう可能性もある。
8 影島編（2017 年）・前掲注2・122 ～ 123 頁。
一方，特有のリスクが生じ得る。このうち上に挙げた異同の第一点目及び第二点目については，システム開発についてのユーザの専門知識の不足に由来するところが大きく，これに対してベンダが専門家であることから，システム開発契約は契約当事者間の知識や情報の格差を内包する契約類型であるといえる。このような場合には，建築請負契約における建築士同様，ベンダは専門家として高度な水準での注意義務を負う立場になるであろう9。とはいえ上記のリスクは知識や情報の格差に基づくものにとどまらず，また，システムがユーザの要望に合わせて開発される以上，ユーザの適切な情報提供や協力なしにはベンダはシステムを完成させることができない点にも留意する必要がある。
（3） システム開発契約の性質
システム開発契約は請負契約や準委任契約とされることが多いが，その法的性質については議論が分かれている 10。そこで以下では，主な考え方を三つに分けて紹介する。
第一は請負契約説である。xxは，ソフトウェアは完成しなければ無意味であることから，特殊な場合を除き，請負契約と解すべきとする 11。xxもまた，
9 建築請負契約においても，専門家たる建築士に要求される注意義務の水準は極めて高度なものになると考えられている。xxxx「建築士の責任」xxxx『専門家の責任』（日本評論社，1993 年）412 ～ 413 頁。もっとも，これはその専門家性に加え，建築士の仕事上のミスが注文者に与える影響が（場合によっては生活や生命身体に関わる）極めて重大なものであるためと説明される。
10 以下に掲げるものの他，システム開発契約の法的性質に関する議論状況を概観したものとして，xxxx「システム開発契約におけるプロジェクト・マネジメント義務―専門家の視点からの一考察」日本ロー 16 号（2019 年）146 頁。
11 xxxx「注文者の協力義務―コンピュータソフト開発契約をめぐる最近の判例を中心に」xx52 巻4 号（2008 年）396 頁。併せて，システム開発契約が請負契約か否かが争われた複数の判決において，請負契約であるとの判断がなされたことが指摘されている。なお
「特殊な場合」とは，必ずしも成果物がはっきりしない場合，ユーザとベンダの共同事業性が強い場合，実験的なソフトやシステムを開発するような場合であると説明されている。同
「請負人の債務―プロジェクトマネジメント義務をてがかりに（1）～（2・完）」xx58 巻 4 号923 頁，59 巻1 号113 頁（いずれも2014 年）。特に59 巻1 号143 頁参照。
xxxが仕事の完成に報酬を支払うことを理由として，請負契約の一類型とする 12。工程ごとに個別契約が締結されることからシステム開発契約は多段階契約方式であるとも考えられるものの，全体として見れば，当初提案されたようなシステムの完成を目的として合意し，基本契約を締結するため，基本契約締結段階で請負契約とすべきであるという 13。
第二は非典型契約説である。xxは，受託者が債務内容の実現に向けて努力するという点では準委任契約的な要素を有している一方，その努力は成果物の完成に向けてであり，その点では請負契約の要素を有すると評価する 14。これによれば，システム開発契約は，請負契約と準委任契約の要素を有する混合契約ということになる。また，xxは，請負や準委任等の典型契約構成を併せ持つ非典型契約であると評価する 15。目的物（ソフトウェア）の性質上，完成すべき仕事の内容についてユーザとベンダの認識にずれが生じることが多く，仕事の完成の定義が契約当事者間で必ずしも明確でないことから，完成に対して報酬を支払う民法の請負契約としては扱うことには無理があるという。その上で，システム開発の取引形態は請負型，委任型，派遣型の 3 つに分けられ，契約の目的・内容に応じてそれぞれの契約類型に当てはめられるという。
第三は，開発過程に応じて柔軟に性質決定をすべきとする考え方である。ウォーターフォール・モデルを念頭に置いた場合，基本契約の他，要件定義や外部設計といった開発段階ごとに個別契約が締結されることが多い。そこでそれぞれの契約の目的に照らし，どのような性質の業務を遂行する工程であるか，契約締結段階で完成すべき仕事や目的物が明確になっているかといった観点か
12 xxxxx「システム開発契約における開発業者のプロジェクト・マネジメント義務」青森法政論叢16 号（2015 年）4 ～ 5 頁。
13 同上。
14 xx調和「ソフトウェア開発委託契約」xxx＝xxxx『非典型契約の総合的検討』（商事法務，2013 年）171 頁。
15 xxx「ソフトウェア開発委託契約紛争事例の研究（1）～（2・完）」現代法学10 号（2005年）168 頁，11 号（2006 年）94 ～ 95 頁。
ら，契約の性質決定がなされるべきとされる 16。なお，経済産業省が公表したウォーターフォール型ソフトウェア開発のモデル契約においても，例えばユーザが主体となる要件定義には準委任契約，ベンダが主体となる内部設計以下のソフトウェア開発業務には請負契約が用いられている 17。
（4） 性質決定の意義と本稿の問題意識
私見では，ベンダはソフトウェアの完成を約束し，ユーザはこれに対して報酬を支払うのであるから，全体としてみれば請負契約と評価するのが妥当であろうと考える。
確かにシステム開発契約においては，基本契約締結時において完成すべき仕事の具体的内容が必ずしも明確でなかったり，ユーザの情報提供や協力なしには仕事を完成し得ないといったことが起こり得る。とはいえ請負契約における仕事完成義務は，「請負人が履行期までに完成することを可能にするために，適時に仕事に着手し，完成に向けて行為をする義務」18 であり，完成すべきソフトウェアの具体像を段階的に詰めながら作業を進める義務を契約の条項や解釈によって読み込むことは十分に可能であろう。また，請負契約における注文者の協力義務についてもかねてより議論の蓄積があり，注文者が協力義務に反した場合は請負人の損害賠償請求（民法 415 条）や解除（民法 541 条）が認め
16 xxほか（2017 年）・前掲注1・28 ～ 33 頁によれば，例えば，要件定義ではユーザの積極的な協力が不可欠であり，ベンダがユーザの要件を取りまとめるという事務の履行が契約の目的となることから，準委任契約として個別契約が締結される。一方，開発工程では基本的にベンダが単独で作業を行い，契約締結段階でその内容や範囲が明確になっている目的物を納入することが契約の目的であることから，請負契約として個別契約が締結されるべきことになるという。
17 経済産業省 情報システムの信頼性向上のための取引慣行・契約に関する研究会「情報システム・モデル取引・契約書〔第2 版〕」（2020 年12 月公開）55 ～ 57 頁。xxxxx://xxx.xxx. xx.xx/xxx/xxxxxxx/00000000.xxxx
18 xxxx『契約法』（有斐閣，2017 年）504 頁。なお同501 頁では，請負の一種である「物以外の仕事の成果を引き渡すべき」場面として，ソフトウェアの作成が例に挙げられている。
られる 19。そうすると，こうしたシステム開発契約の特徴はいずれも，請負契約上の義務として説明が可能である。
そもそもシステム開発契約の性質決定にまつわる議論は，請負契約とするか準委任契約とするかで契約上の義務が異なるという点に実質的意義を見出しているように思われる。例えば請負契約であればxxxは仕事完成義務を負い，xxxはその仕事の結果に対して報酬を支払うことになる（民法 632 条）。対して準委任契約では仕事完成義務を負わないため，ベンダのリスク回避の観点からは準委任契約を選択すべきとも考えられる 20。
しかし，契約当事者の義務の内容は，当該契約が請負であるか準委任であるかによって決まるのではなく，当事者による性質決定にも必ずしも影響されない 21。当事者がどのような義務を負っていたかは個々の事案における契約の条項や解釈によって定まるものであり，さらには，契約上の義務や不法行為上の義務の違反についての裁判所の判断から導くことができるはずである。
なお，システム開発が頓挫した場合等の責任分担に関しては，そのような場合について当事者間に何らかの合意があれば，第xx的にはその合意の適用・解釈によって規律される。しかし明確な合意がないことも多く，その場合は，ベンダが（契約上あるいは不法行為上の）プロジェクトマネジメント義務を尽
19 同515 ～ 516 頁。またxx（2015 年）・前掲注12・4 頁は，請負契約であったとしてもxxx上の注意義務としてユーザに情報提供等の協力義務を課すことは可能であると指摘する。
20 xx＝xx編（2019 年）・前掲注4・316 頁〔xx執筆部分〕。xx（2015 年）・前掲注12・ 4 頁は，実務において個別契約を準委任とすることで，xxxが仕事完成義務を負うことなく，個別契約ごとに定められた業務終了段階で対価請求権を生じさせるといったベンダのリスク回避が企図されていることを指摘している。xx（2005 年）・前掲注15・169 ～ 171 頁は，ソフトウェア開発を請負型で委託することは，委任型や派遣型で委託する場合に比べてユーザ・ベンダ双方にとってリスクや法的責任が大きいとした上で，それでもなお実務において請負型が主流とならざるを得ない背景を検討している。
21 例えば，東京地判平成22 年9 月21 日（判タ1349 号136 頁）は，コンピュータシステムに関するシステム開発契約について，当該契約書に準委任契約と書かれているとしてもシステム構築に係る部分は請負契約の要素を含むとした。
くしていたか，ユーザに協力義務はあったのかが評価されねばならない。
このように考えてくると，システム開発契約の性質決定に拘泥することは実益が薄いように思われる。むしろ，個々の契約をどのように性質決定するにせよ，プロジェクトマネジメント義務や協力義務の違反があったか否か，ひいては義務の内容や根拠はどのように説明されているのかを具体的に論じることが重要である。さらに，ベンダのプロジェクトマネジメント義務違反に基づく損害賠償についての過失相殺や，xxxの協力義務違反が原因でシステム開発が頓挫したとしてベンダの義務違反を否定する場合等，両義務の適用領域が交錯することも少なくない。
そこで以下では，3 件の高裁判決の検討を通じ，プロジェクトマネジメント義務や協力義務の内容と根拠，さらには両義務がどのように関係し合いながら紛争解決を導いているのか明らかにすることを試みる。
3 裁判例の紹介
（1）「プロジェクトマネジメント義務」概念の登場
システム開発契約では，期限までにシステムが完成しなかったり，完成したとしても不具合等によりユーザの求める通りに機能しないといったトラブルが生じやすい。このような場合，xxxの帰責性は，ベンダがプロジェクトマネジメント義務を果たしたか否かという形で争われ得る。さらに，システム開発はユーザとベンダの共同作業であって，双方が協力し合わなければ達成し得ないとされる。そのためベンダのプロジェクトマネジメント義務とともに，ユーザの協力義務についても争われることが多い。
システム開発契約紛争における「プロジェクトマネジメント義務」という用語は，東京地判平成 16 年 3 月 10 日（判タ 1211 号 129 頁）において初めて言
及されたものである 22。平成 16 年判決では，「ベンダは，注文者であるユーザ のシステム開発へのかかわりについても，適切に管理し，システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユーザに働きかける義務（以下，これらの義務を『プロジェクトマネジメント義務』という。）を負」うとされた（以下，下線は引用者による）23。さらにプロジェクトマネジメント義務の内容について，「ユーザにおける意思決定が必要な事項や，ユーザにおいて解決すべき必要のある懸案事項等について，具体的に課題及び期限を示し，決定等が行われない場合に生ずる支障，複数の選択肢から一つを選択すべき場合には，それらの利害得失等を示した上で，必要な時期までにユーザがこれを決定ないし解決することができるように導くべき義務を負い，また，ユーザがシステム機能の追加や変更の要求等をした場合で，当該要求が委託料や納入期限，他の機能の内容等に影響を及ぼすものであった場合等に，ユーザに対し適時その旨説明して，要求の撤回や追加の委託料の負担，納入期限の延期等を求めるなどすべき義務」であ
ると説明された。
これを機に，裁判所はシステム開発契約紛争におけるベンダの契約上あるいは不法行為上の義務としてプロジェクトマネジメント義務を論じるようになっ
22 なお，平成16 年判決以前から，「プロジェクトマネジメント義務」と明示されてはいないものの実質的にプロジェクトマネジメント義務に相当する義務が争われた事例があるとの分析がある。xx（2014 年（1））・前掲注11・928 頁。
23 この事案では，納期までにシステムが完成しなかったため，ユーザが債務不履行に基づく解除と損害賠償を請求し，ベンダは完成しなかった原因はユーザの協力義務違反にあるとして債務不履行に基づく損害賠償を反訴として求めていた。結果として，開発の遅れは一方の当事者のみの帰責事由によるものではなく，双方の不完全な履行，法改正等が相まった結果であるとして，いずれの債務不履行責任も否定された。予備的請求であったユーザの民法 641 条に基づく解除は，同条に基づく損害賠償を6 割過失相殺した上で認められた。本件の主な評釈として，xxxx「電算システム開発契約における注文者の協力義務と請負人のプロジェクトマネジメント義務」xx52 巻4 号（2008 年）471 頁。
なお，以下では当事者の役割を明快にするため，判決文中の当事者の表記を適宜「ベンダ
/ ユーザ」に置き換えている。
た。その後現在に至るまで，同判決を含めて 15 件の判決においてベンダのプロジェクトマネジメント義務違反の有無が争われている 24。経済産業省が公表したウォーターフォール型ソフトウェア開発のモデル契約においても，モデル契約条項としては規定されていないものの，複数の判決におけるプロジェクトマネジメント義務や協力義務が紹介されている 25。
そこで以下では上記の 15 件のうち，高裁レベルでの判断がなされた 3 つの判決（平成 25 年スルガ銀行対日本 IBM 判決，平成 26 年 CTC 対第一法規判決，平成 29 年旭川医大対 NTT 東日本判決）を紹介する。
24 本文中で紹介するものの他，東京地判平成25 年12 月19 日（LEX/DB 文献番号25516950），東京地判平成26年4月7日（LEX/DB 文献番号25519214）， 東京地判平成26 年6 月26 日
（LEX/DB 文献番号25520345），東京地判平成28 年6 月17 日（LEX/DB文献番号25543491），東京地判平成28年11月30日（LEX/DB 文献番号25538437）， 東京地判平成31 年3 月20 日
（LEX/DB 文献番号25563106）。
25 経済産業省（2020 年）・前掲注17・82 ～ 83 頁。経済産業省は，証券取引所における大規模なシステム障害等の事例を受けて「情報システムの信頼性向上のための取引慣行・契約に関する研究会」を立ち上げ，2007 年に「情報システム・モデル取引・契約書〔第1 版〕」を公表した（xxxxx://xxx.xxxx.xx.xx/xxxxxx/xx_xxxxxx/xxxxxxx/xxxxx_xxxxxxxxxx.xxx）。その後，ベンダのプロジェクトマネジメント義務が争われた裁判例が相次いだこと等を受け，見直しを行った上で第2 版が公表された。
この他，ソフトウェア開発のプロジェクト管理に関する国際的な知識体系ガイドとして，プロジェクトマネジメント協会が発行するPMBOK（Project Management Body of Knowledge）が存在する。ここでは，典型的なプロジェクトマネジメントは，コスト管理，スケジュール管理，スコープ管理，品質管理，組織のマネジメントを指すとされている。しかし後述する裁判例では，ユーザに開発を阻害する要因がないかどうかについての発見につとめ，それを予防するようユーザに働きかける義務や，時にはプロジェクト中止を提言する義務までもがベンダのプロジェクトマネジメント義務として認められることがある。上記ガイドが実務においてどこまで受け入れられているか明確でないが，裁判例におけるプロジェクトマネジメント義務概念とはずれがあり，特にベンダはガイドが想定する以上のリスクまで負うことになる可能性があるように思われる。
（2） 裁判例の紹介
① 東京高判平成 25 年 9 月 26 日（金判 1428 号 16 頁）―スルガ銀行対日本 IBM 判決 26
《事案の概要》
平成 12 年頃，ユーザ（スルガ銀行）は老朽化した現行基幹システムの刷新を考え，従来ユーザのシステム管理・運用を支援していたベンダ（日本 IBM）に提案を依頼した。ベンダは，日本でまだ導入されたことのない海外の基幹系パッケージソフト Corebank を用いた新システムの提案を行い，ユーザはこれを採用した。
平成 16 年 9 月，ユーザとベンダとの間で，ユーザの銀行業務全般を処理する新経営システム（以下，本件システム）の構築に関する基本合意（1）が，同年 12 月には基本合意（2）が締結された 27。平成 17 年 9 月，本件システム開
26 原審の主な評釈として，xxxx「情報システム開発契約の多段階契約に関する新しいアプローチの必要性」NBL977 号（2012 年）4 頁，xxxx「スルガ銀行・IBM 裁判が今後のシステム開発プロジェクトに及ぼす影響（上）・（下）」ビジネス法務12 巻8 号82 頁，同9 号 82 頁（いずれも2012 年），xxxx「金融システム開発契約に係る法的諸論点の帰趨」金法 1952 号（2012 年）52 頁，xxxx「判批」速判解12 号（2013 年）87 頁，xxxx「スルガ銀行vs 日本IBM 事件から導かれるモデル契約の変更点」ビジネス法務13 巻10 号（2013 年） 25 頁。
本件の主な評釈として，xxxx「システム開発に関する法的責任の新たな枠組み」 NBL1013 号（2013 年）4 頁，xxxx「『スルガ銀行vs 日本IBM 事件』東京高裁判決の意義」金財2013 年12 月16 日号30 頁，xxxx「銀行業務システム開発契約における，開発者のプロジェクト・マネジメント義務」速判解14 号（2014 年）91 頁，xxxx「判批」金法2001号（2014 年）71 頁，xxxx「システム開発の頓挫と開発業者の責任」xx59 巻3 号（2014年）527 頁，xx（2015 年）・前掲注12・1 頁，帷子（2019 年）・前掲注10・143 頁。
27 本件では開発の進捗に応じて基本契約を更新する手法が採用され，最終的には3 つの基本契約が締結されている。この点につきxx（2013 年）・前掲注26・4 ～ 5 頁は，最終的なシステムの全体像やコストが明らかでない開発の当初においてのみ基本契約を締結する場合に比べ，本件は模範的事例であると評価する。また，xx（2014 年）・前掲注26・71 頁は，システム開発契約の特徴として，契約締結前の確定的債務内容の存在を前提とした契約観ではとらえられない，いわゆる「多段階契約モデル」であることを指摘する。不確定要因が大きいため，様々な協議や個別合意を重ね，交渉を継続しながら互いにリスク分配を図ることが望ましく，「最終合意」や正式な「契約の締結」は成果物の確認と代金の確定作業に過ぎないという。
発での個々の局面の権利・義務を規定した個別契約を締結することを条件に，サービスイン時期を平成 20 年 1 月として総額約 90 億円で本件システム構築を行うことについて最終合意書 28 が交わされた。
しかし開発は当初の想定通りに進まず，平成 18 年 12 月，xxxはユーザに対し開発スコープの削減や追加費用の支払を提案したが，xxxは拒否した。平成 19 年 4 月にはベンダは Corebank の利用を断念し，別のパッケージソフトに切り替えることを提案したが，xxxはこれも拒否した。結局，追加費用や開発スケジュールについての協議が整わず，平成 19 年 7 月，ユーザはベンダに対し，開発の中止と締結されていた各個別契約の解除を通知した。
xxxはベンダに対し，①本質的義務違反，②プロジェクトマネジメント義務違反，③説明義務違反があったとして，請負契約の債務不履行又は不法行為に基づく損害賠償として計約 116 億円の支払を求めて提訴した。これに対してxxxは反訴として，個別契約に基づく未払代金計約 14 億円の支払と，ユーザの協力義務違反を理由とする不法行為に基づく損害賠償として投資費用相当額約 111 億円の支払等を求めた。
第xx東京地判平成 24 年 3 月 29 日（判タ 1405 号 254 頁）は，本件プロジェクトが平成 19 年 5 月ないし 6 月に頓挫したことを認め，これについて「どちらにどのような責任があるのかについて検討」した。ベンダについては，「〔パッケージ型システム開発における〕パッケージの選定は，開発の対象となるシステムの根幹を成すものであり，その適切な選定，開発方法の採用は極めて重要な課題である。システム開発の専門家であるxxxは，パッケージの選定に当たり，パッケージの機能・性能，……その他関連する諸事情を考慮して，ユーザが構築しようとしているシステムに最適のパッケージを選定した上，これに
28 ただし，最終合意書8 条ただし書には「各個別契約……が締結され，各関連個別契約の中で両当事者の各局面における義務が規定されるまでは，いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする」と規定されており，個別契約は締結されなかった。このため，原審，控訴審ともに最終合意書に記載された費用負担額，開発スコープ，サービスインの時期等の法的拘束力を否定している。
適した開発方法を採用しなければならず，そのために，ベンダはユーザへの提 案前に様々な観点からパッケージの機能，開発手法，リスク等について十分に検証又は検討しなければならない」とした上で，ベンダは十分な検討・検証を怠ったとした（以下，〔〕内は引用者による）。
他方でユーザについては，開発スコープの削減やサービスイン時期に係るベンダの提案に応じなかったこと等は協力義務違反とならないとし，「本件システム開発が頓挫したことの責任はもっぱらベンダにある」とした。
以上によりベンダのプロジェクトマネジメント義務違反を理由とし，実損額を約 74 億円として不法行為に基づくユーザの損害賠償請求を認めた。その余の請求はいずれも棄却され，xxxが控訴した。
なお，本件の争点は多岐にわたるため，本稿ではベンダのプロジェクトマネジメント義務とユーザの協力義務の内容を明らかにするという問題意識に関わる部分に限って取り上げることをお断りする。
《判決の要旨》
東京高裁はまず本件の判断枠組みについて以下のように述べる。「ベンダとユーザの間には，各基本合意及び各個別契約が締結されているから，損害賠償責任の成否及びその範囲を考えるに当たっては，まず契約内容を合理的に解釈することを要するというべきである。また，訴訟においては，当事者の主張の構成に沿ってその当否を判断すべきものであり，本件のユーザのように，両立し得る請求権について順序を付けている場合においては，その主張の構成に沿ってその当否を判断するのが相当である。そこで，当裁判所は，損害賠償を求めるユーザの請求原因の構成に沿って，契約締結前については，契約がないことを前提に，契約締結後については，不法行為を主張する請求は不法行為規範に照らし……，契約責任を主張する請求は当事者間で締結された契約内容及び契約法理に照らし，それらの責任の成否及び範囲について検討することとする。」
その上で，ベンダのプロジェクトマネジメント義務につき，企画・提案段階と開発段階とに分けて検討を行っている。まず前者について，「企画・提案段階においては，……プロジェクト構想と実現可能性に関わる事項の大枠が定められ，また，それに従って，プロジェクトに伴うリスクも決定づけられるから，企画・提案段階においてベンダに求められるプロジェクトの立案・リスク分析は，システム開発を遂行していくために欠かせないものである。そうすると，ベンダとしては，企画・提案段階においても，自ら提案するシステムの機能，ユー ザのニーズに対する充足度，システムの開発手法，受注後の開発体制等を検討・検証し，そこから想定されるリスクについて，ユーザに説明する義務があるというべきである。このような……義務は，契約締結に向けた交渉過程におけるxxxに基づく不法行為上の義務として位置づけられ，ベンダはかかる義務
（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる」。
一方で「システム完成に向けた開発協力体制が構築される以前の企画・提案段階においては，システム開発技術等……について，情報の非対称性，能力の非対称性が双方に存在するものといえ，ベンダにシステム開発技術等に関する説明責任が存するとともに，ユーザにも……システム開発について自らリスク 分析をすることが求められるものというべきであ」り，「企画・提案段階の計画どおりシステム開発が進行しないこと等をもって，直ちに企画・提案段階におけるベンダのプロジェクト・マネジメントに関する義務違反があったということはできない」とし，本件ではベンダに問題がなかったわけではないとしつつも企画・提案段階での義務違反を否定した。また，このことをもってxxxの説明義務違反も否定した。
続いて開発段階のプロジェクトマネジメント義務については，「前記各契約 29 に基づき，……適宜得られた情報を集約・分析して，ベンダとして通常求
29 本件ユーザとベンダとの間で交わされた3 つの基本合意と16 個の個別契約を指す。
められる専門的知見を用いてシステム構築を進め，ユーザに必要な説明を行い，その了解を得ながら，適宜必要とされる修正，調整等を行いつつ，本件システ ム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負う」とした。
また，「〔この〕義務の具体的な内容は，契約文言等からxx的に定まるものではなく，システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。すなわち，……想定していた開発費用，開発スコープ，開発期間等について相当程度の修正を要すること，更にはその修正内容がユーザの許容限度を超える事態が生じることもあるから，ベンダとしては，そのような局面 に応じて，ユーザのシステム開発に伴うメリット，リスク等を考慮し，適時適切に，開発状況の分析，開発計画の変更の要否とその内容，更には開発計画の中止の要否とその影響等についても説明することが求められ，そのような説明義務を負うものというべきである」とし，またこの段階では「開発進行上の危機を回避するための適時適切な説明と提言をし，仮に回避し得ない場合には本件システム開発の中止をも提言する義務があった」30 とした。
そして本件では中止を含めた提言をしなかったとして企画・提案段階のベンダのプロジェクトマネジメント義務違反を肯定し，本件最終合意締結後にユーザが支出した費用約 42 億円について不法行為に基づくユーザの損害賠償請求を認めた。
また，開発中止か否かの選択を要する局面においてベンダがプロジェクトマネジメント義務を果たしていない以上，「ユーザが，ベンダの提案に容易に応ぜず，……本件システム開発が中止されるに至ったことをもって，ユーザに債
30 東京高裁はこれに先立ち，当事者は「……プロジェクトの大幅な延期や中止せざるを得ない状況が発生した場合，……両者は真摯に協議の上，互いに誠意をもって損害賠償等の措置を含む適切な対応をするものとする」（本件基本合意書3 条）との合意をしていたが，本件最終合意において責任限定条項が改定され，損害賠償の限度額を拡張した故意・重過失条項が設けられた経緯から，ベンダがこの時点において本件システム開発が困難な状況に陥っていることを認識していたことは明らかであると指摘している。
務不履行ないし不法行為責任を問うことはでき」ず，従ってユーザによる損害賠償請求についての過失相殺も認められないとした。
xxxが上告したが，最二小決平成 27 年 7 月 8 日（LEX/DB 文献番号 25540949）は上告棄却，不受理となった。
② 東京高判平成 26 年 1 月 15 日（LEX/DB 文献番号 25503191）―CTC 対第一法規判決 31
《事案の概要》
平成 16 年 4 月 15 日，ユーザ（第一法規）は CRC ソリューションズとの間で，ユーザの新基幹システムの開発プロジェクトについて，ユーザを委託者， CRC ソリューションズを受託者とする業務委託基本契約を締結した。その後ベンダ（xxxxxxソリューションズ：CTC）が CRC ソリューションズを吸収合併し，ベンダが本件新基幹システムに係る要件定義，外部設計を行い代金が支払われた他，個別契約を締結しないままベンダによる開発作業，ユーザによる導入支援業務が行われていた。
平成 20 年 12 月 25 日，ユーザとベンダとの間で，上記業務委託基本契約に係る個別契約として，本件新基幹システムに係るソフトウェア開発個別契約が締結された。同契約では，業務遂行形態を請負とすること，xxxは平成 21 年 1 月 5 日までに本件新基幹システムを納品すること，ユーザによる検収は同年 4 月末までに行うことが合意された。本件ソフトウェア開発個別契約締結後，ユーザによる変更要望が多数出され，仕様変更が行われた。その後，本件新基幹システムは約定期日に納品されたが，検収において軽微とは言えない不具合が多数発見され，平成 21 年 6 月 16 日にユーザは解除の意思表示を行うに至った。
31 原審の主な評釈として，xxxx「ソフトウェア開発契約における瑕疵担保責任の有無および内容」リマークス53 号（2016 年）38 頁。本件の主な評釈として，xxxx「システム開発契約におけるプロジェクト・マネジメント義務」日本ロー 17 号（2020 年）87 頁。
そこでベンダがユーザに対し，本件ソフトウェア開発個別契約に基づく委託料及び追加開発業務に係る業務代金等として，計約 14 億円の支払を求めて提訴した。これに対しユーザは，約定期日までに仕事を完成すべき義務を怠り，またその仕事に瑕疵があるために契約の目的を達成することができないとして，解除が有効であると主張した。また反訴として，債務不履行又は瑕疵担保責任に基づく損害賠償として，支払済みの開発費用等計約 14 億円の支払を求めた 32。
第xx東京地判平成 25 年 5 月 28 日（判タ 1416 号 234 頁）は，本件新基幹システムは完成したものの瑕疵があったといわざるを得ないとし，瑕疵担保責任に基づく本件ソフトウェア開発個別契約の解除を有効とした上で，業務代金等に係るベンダの本訴請求には理由がないとして否定した。
反訴請求については，xxxの上記瑕疵担保責任を肯定し，xxxは「開発 業務の全般にわたり『プロジェクト管理』の責任があり，……プロジェクトマネジメント義務違反としての責任も免れないというべきである」とした。一方，
「瑕疵の発生についてユーザ側にも原因があるという場合には，ベンダのみにその全ての責任を負わすのは不xxであり，過失相殺の法理により，ユーザの損害賠償請求については，減額を認めるのが相当である（プロジェクトマネジメント義務違反としての責任ととらえても，過失相殺が認められる。）」とし，多くの瑕疵が発生した主たる原因はユーザの度重なる変更要望にあるとして 8割減額した。これにより，上記瑕疵担保責任に基づく損害賠償としてユーザの請求を約 2000 万円の限度で認容した。
その余の請求はいずれも棄却され，xxxが控訴，xxxが付帯控訴をした。
《判決の要旨》
東京高裁も，多数の不具合・障害や，そのために検収期間終了時において検
32 本件反訴は，本件反訴請求債権につき本件本訴において相殺の自働債権として既判力ある判断が示された場合には，その部分については反訴請求としない旨の予備的反訴である。
収が終了せず，ユーザの現行ホストコンピュータの保守期間満了後もなお長期 間を要する状態を認め，「本件ソフトウェア開発個別契約は，本件新基幹システムの瑕疵のために，社会通念上，本件ソフトウェア開発個別契約をした目的を達することができないもの」とし，改正前民法 635 条に基づく解除を認めた。その際，上記瑕疵によって契約の目的を達することができないことにつき ユーザにも原因の一部があるとしつつも，「瑕疵が，ユーザの供した材料や与えた指図によって生じたものであると認めるに足りる証拠はな」いとして改正
前民法 636 条本文の適用を否定した。
さらに，瑕疵担保責任に基づく損害賠償における過失相殺について，瑕疵の発生についてはユーザによる変更の申入れやデータ移行作業の不適切さが一因であるとしつつも，以下のように述べて原審から過失相殺の割合を減額した。本件個別契約 33 によれば「ベンダは，ユーザの変更申入れを応諾する契約上 の義務を負わず，契約上これを拒絶することができる」。そして，「ユーザがシステム開発等についての専門的知見を備えているとは認められない顧客であるのに対し，ベンダは，システム開発等の専門的知見や経験を備えた専門業者であって，ユーザからの変更の申入れに応じること〔で〕……本件ソフトウェア開発個別契約の目的を達成できなくなる場合においては，本件プロジェクトの 業務委託基本契約に基づく善管注意義務及び本件ソフトウェア開発個別契約における付随的義務として，その専門的知見，経験に照らして，これを予見した
上，ユーザに対し，これを告知して説明すべき義務を負うものであって，なお， xxxが変更を求めるときは，これを拒絶する契約上の義務がある」。
本件ではこのようなベンダの義務違反が，ユーザの過失の一因となっているとして，過失相殺による減額の割合を 4 割とし，瑕疵担保責任に基づく損害賠
33 個別契約3 条3 項は，「仕様書等の変更の申入れがあった場合，その申入れから14 日以内に，ユーザ及びベンダは変更の内容及びその可否につき協議を行い，変更の可否につき決定」し，「協議が調わない場合，ベンダは，従前の仕様書等に基づき本件業務を遂行する」としている。
償として約 2 億円の限度でユーザの請求を認めた。その余の請求はいずれも棄却された。
③ 札幌高判平成 29 年 8 月 31 日（判時 2362 号 24 頁）―旭川医大対 NTT 東日本判決 34
《事案の概要》
ユーザ（旭川医大）は平成 20 年 8 月頃に病院情報管理に係る新システムの導入を決定し，入札を実施したところ，ベンダ（NTT 東日本）と NTT ファイナンスが落札者となった。三者は，ベンダがユーザのために本件システムを開発し，NTT ファイナンスをその所有者としてユーザに本件システムをリースすることを目的とする契約を平成 20 年 10 月 31 日付で締結した。
その後，ユーザが入札時の仕様と異なるカスタマイズの追加要望を多数回行ったため，当初の予定通りに開発が進まなかった。平成 21 年 7 月 7 日，ベンダが 625 件の変更・追加要望を受け入れることで仕様凍結とする旨の仕様凍結合意が交わされた。しかしその後もユーザは 171 件の変更・追加要望を行い，xxxはこのうち 136 件を受け入れた。これらの追加作業のため，稼働予定日であった平成 22 年 1 月 4 日にシステムは稼働しなかった。そこでユーザはベ
ンダに対し本件システムに係る債務の履行を催告した上で，平成 22 年 4 月 26日に債務不履行に基づく解除の意思表示をした。
その上でユーザはベンダに対し，ベンダが納期である平成 22 年 1 月 3 日に本件システムの完成及び引渡しをしなかったためユーザに逸失利益等の損害が生じたと主張し，上記契約の債務不履行に基づく約 19 億円の損害賠償を求め
34 本件の主な評釈として，xxxx「システム開発取引においてベンダとユーザが果たすべき責任の内容」NBL1111 号（2017 年）22 頁，xxxx「NTT東日本対旭川医大事件」 BLJ2018 年1 月号54 頁，xxxx「プロジェクトマネジメントの義務」A2Z2018 年8 月号36頁，xxxx「判批」税務事例51 巻2 号（2019 年）63 頁，xxx「システム構築契約に関する契約当事者の責任配分」ジュリ1534 号（2019 年）110 頁，xxxxx「システム開発契約における注文者の協力義務違反」青森法政論叢20 号（2019 年）19 頁。
提訴した（第 1 事件）。これに対しベンダは，本件システムの完成及び引渡しが遅れたことにつきベンダに帰責性はないとした。そして反訴として，ユーザの協力義務違反及び不当な受領拒絶によりベンダは上記契約に基づく完成義務を履行し得なくなり，これにより NTT ファイナンスから本件システムの売買代金を得られなくなったと主張し，主位的には上記契約の債務不履行に基づく損害賠償，予備的には不法行為に基づく損害賠償として約 23 億円の支払を求めた（第 2 事件）35。第 1 事件及び第 2 事件は併合審理されることとなった。
第xx旭川地判平成 28 年 3 月 29 日（判時 2362 号 64 頁）は，開発頓挫に関するベンダの責任について，「ベンダとしては，ユーザからの開発要望に対しては，代替案や運用上の工夫による対処案を示すなどしてユーザの納得を得る か，それができないのであれば，追加開発はベンダの義務ではないことや，追加開発に応じていては予定どおりの稼働には間に合わないことを説明し，ユーザの要望を拒絶すべきであった」とした。その上で「ベンダが上記のような毅然とした対応をとらず，開発要望に応じた結果，完成が遅滞したとしても，そのことをもってベンダが免責されるとはいえない」とし，本件システム開発が頓挫したことについてベンダに 8 割の責任があるとして，債務不履行に基づく損害賠償として約 3.7 億円の限度でユーザの請求を認めた。
他方，本件システム開発の頓挫につきユーザにも 2 割の責任があり，ユーザに契約上の協力義務違反が認められるとして，債務不履行に基づく損害賠償として約 3.8 億円の限度でベンダの主位的請求を認めた。
その余の請求はいずれも棄却され，xxxとxxxの双方が控訴した。
《判決の要旨》
札幌高裁は，「システム開発では，初期段階で軽微なバグが発生するのは技
35 なおベンダは第2 次予備的請求として，本件システム開発に関わる業務につき，ユーザの要請を受けた商人たるベンダがその営業の範囲内で行ったと主張し，商法512 条の報酬請求権の行使として約23 億円の支払を求めていたが，請求は棄却されている。
術的に不可避であり，納品後のバグ対応も織り込み済みでることに照らすと，バグ等が存在しても，システムを使用して業務を遂行することが可能であり，その後の対応でxx解消される類のものであれば，仕事が完成したと認定すべきである」とした上で，「本件システムは，遅くとも本件解除時（平成 22 年 4
月 26 日）までには，一審原告の協力が得られずに保留せざるを得なかった 1項目を除き，全て完成していた」と認めた。
さらに，本件仕様凍結合意が「開発対象を確定し，以降，ユーザは，ベンダに対し，……一切の追加開発要望を出さないとの合意」を意味することを認め，
「プロジェクト頓挫についてのユーザとベンダの責任」について以下のように述べた。
まず，ユーザの債務不履行責任について，「システム開発はベンダの努力の みによってなし得るものではなく，ユーザの協力が必要不可欠であって，〔本件〕ユーザも，ベンダによる本件システム開発に協力すべき義務を負う（ユーザも，一般論として上記のような協力義務を有していることは認めているところである。）。そして，この協力義務は，本件契約上ユーザの責任とされていたもの……を円滑に行うというような作為義務はもちろん，本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し，ベンダにその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである」とした。
その上で，ユーザが本件仕様凍結合意に反して大量の追加開発要望を出したこと，開発に必要な現行システムの情報を十分に提供しなかったこと等をもってユーザの協力義務違反を肯定した。これにより，債務不履行に基づく損害賠償として約 14 億円の限度でベンダの主位的請求を認めた 36。
36 なお，xxxの不法行為責任については，ユーザの協力義務違反は「債務不履行を超えて不法行為を構成するほどの違法性を有するものであると認めることはできない」として否定した。またユーザの受領義務違反については，xxxが即時の検収等を求めていなかったことから否定した。
次に，ベンダの債務不履行責任について，履行遅滞の事実は認めつつも，「本件システム開発が遅延し，結局引渡しがなされないまま本件解除に至ったのは，
……xxxが協力義務に違反したためであり，xxxの責任によるものとは認められない」とした。さらに，「ベンダは，プロジェクトマネジメント義務の履行として，追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で，追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる。これを超えて，……納期を守るためには更なる 追加開発要望をしないようユーザを説得したり，xxxによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず，ベンダにプロジェクトマネジメント義務の違反があったとは認められない」とした。
以上により「ベンダには債務不履行（履行遅滞）について帰責性がなく，また，ユーザの債務不履行について過失相殺の対象となるべき過失の存在も認められない」として原審を否定した。
xxxが上告したが，最二小決平成 30 年 5 月 11 日（LEX/DB 文献番号 25560951）は不受理となった。
4 裁判例の検討
（1） 請求権の性質
ベンダのプロジェクトマネジメント義務，ユーザの協力義務の違反が争われる場合の当事者の請求は，以下の 2 つに大別される。
第一に，システム開発が途中で頓挫した場合，xxxはベンダに対して損害賠償を請求し得る。例えばスルガ銀行対日本 IBM 判決では，ベンダに本質的義務違反や説明義務違反とともにプロジェクトマネジメント義務違反があったとして，ユーザがベンダに対し債務不履行又は不法行為に基づく損害賠償を請求した。旭川医大対 NTT 東日本判決では，納期までにシステムの完成及び引渡しがなされなかったとして，ユーザは直接的にはベンダの債務不履行（履行遅滞）に基づく損害賠償請求を行っているが，判決はシステム開発頓挫に際し
てのベンダのプロジェクトマネジメント義務違反の有無に言及している。 上記のようなユーザの請求に対し，xxxは反訴として，システム開発の報
酬を請求する他，ユーザの協力義務違反を理由として債務不履行又は不法行為に基づく損害賠償を請求し得る。スルガ銀行対日本 IBM 判決では反訴として，未払代金の支払とともに，ユーザの協力義務違反を理由とする不法行為に基づく損害賠償請求が行われた。旭川医大対NTT 東日本判決では反訴として，ユーザの協力義務違反を理由として主位的には債務不履行，予備的には不法行為に基づく損害賠償が請求された。
第二に，システム開発が頓挫した場合等に，xxxがユーザに対して未払代金の支払を求めたり，頓挫の原因はユーザの協力義務違反にあるとして損害賠償を請求したりすることが考えられる。なおユーザの協力義務は，契約上の義務または不法行為上の注意義務として主張され得る。CTC 対第一法規判決では，開発が頓挫したために契約を解除したとして支払を一部拒んでいるユーザに対し，xxxが代金の支払を求めて提訴した。
これに対する反訴として，xxxはベンダのプロジェクトマネジメント義務違反を理由として，債務不履行又は不法行為に基づく損害賠償を請求し得る。 CTC 対第一法規判決では，xxxが反訴として，ベンダの債務不履行又は瑕疵担保責任 37 に基づく損害賠償請求を行っており，判決においてベンダのプロジェクトマネジメント義務違反が認められている。なお同判決はユーザの協力義務については直接触れていないものの，瑕疵の発生につきユーザの過失を認め，瑕疵担保責任に基づく損害賠償について過失相殺を行っている。
37 近時の債権法改正において，請負人の瑕疵担保責任規定は削除され，売主の契約不適合責任規定が包括準用されることとなった。なお，瑕疵の実質的意味は「契約の内容に適合しないこと」であると従前より考えられており，改正により請負人の責任の法的性質に変更が生じるものではないと説明されている。参照，xxxxほか編『改正債権法コンメンタール』
（法律文化社，2020 年）866 頁〔xxxxx部分〕。改正後民法下では，システム開発契約のユーザがベンダの債務不履行に基づく損害賠償責任を追及する場合，債務不履行一般の規定が適用されることになる（改正後民法564 条・415 条）。
以上のように，プロジェクトマネジメント義務は契約上の義務または不法行為上の注意義務として争われる。債権者の完全性利益が侵害されたとき，それが契約上の保護義務に対する違反と評価されれば債務者の債務不履行責任，「故意又は過失」による「権利又は法律上保護される利益」の侵害（民法 709 条）と評価されれば不法行為責任が肯定されることになる。請求権競合説によれば，一つの行為が契約責任と不法行為責任の両方の請求権発生根拠規範の要件を満たすのであれば，請求権者は相互に独立した請求権として任意にいずれかを選択できる 38。
この点につき，システム開発契約において，被害者（債権者）が経済的な不利益を被ったに過ぎない場合にまで不法行為法を適用することは不法行為制度の趣旨に反するとの指摘がある 39。契約上の義務が未確定である契約締結過程においては不法行為構成を取らざるを得ないとしても，その後正式に契約が成立し，契約上の義務が生じているのであれば，それ以前のプロセスにも遡って契約の効力を及ぼして良いという。
確かに，スルガ銀行対日本 IBM 判決の判決文中では，ユーザの主張に従い不法行為責任の成否を検討するとしつつ，契約上の義務の履行過程における不法行為責任が問題となっているのであって，債務不履行責任の成否についても基本的に同様の検討が当てはまる旨が述べられている 40。同判決はベンダのプロジェクトマネジメント義務を不法行為上の義務として認めているものの，債務不履行構成を否定するものではないことが窺える。ユーザの協力義務に関しては，旭川医大対 NTT 東日本判決はユーザの債務不履行責任を肯定する一方で，本件ユーザの協力義務違反は「債務不履行を超えて不法行為を構成するほ
38 xxxx『債権総論〔第5 版補訂〕』（信山社，2020 年）8 ～ 9 頁。
39 xx（2014 年）・前掲注26・25 ～ 26 頁。
40 本件原審につき，「本件当事者間の法律関係は不法行為によるのではなく，個別契約の解釈によるべき」との批判がある。原審は最終合意書の法的拘束力を否定し，ベンダの債務不履行又は不法行為は成立しないとする一方で，最終合意書を交わした経緯自体を考慮して不法行為上の義務たるプロジェクトマネジメント義務の違反があるとしており，論理構成が不透明であるという。xx（2012 年）・前掲注26・61 頁。
どの違法性を有するものであると認めることはできない」として否定している。このように，ベンダのプロジェクトマネジメント義務及びユーザの協力義務 は本質的には契約上の義務であると考えられているようである。システム開発契約においては，多段階契約方式が採用され，頓挫した時点での個別契約が締結されていないといった状況があり得る。しかしながらこのような場合でも，ベンダとxxxとが継続的に関わり合いながらプロジェクトを遂行していくのであり，契約関係を前提として互いにプロジェクトマネジメント義務ないし協力義務を負うと考えられる。被害者救済の観点から，請求権発生根拠規範の要件を満たす以上は請求権の競合が否定される理由はないものの，プロジェクトマネジメント義務違反は本来的には債務不履行として構成されるべきであろう。
（2） ベンダのプロジェクトマネジメント義務の内容
前述したように，システム開発契約では基本契約，個別契約を積み重ねながら開発が進められることが多い。そのため，ベンダのプロジェクトマネジメント義務の内容も，開発過程ごとに区別して考える必要があるように思われる。特にスルガ銀行対日本 IBM 判決においては，ウォーターフォール・モデルで長期にわたって開発が進められるシステム開発の特徴から，そこにおけるプロジェクトマネジメント義務の内容についても開発過程ごとの具体化が行われている。そこで以下では，上記 3 件の高裁判決を参照しながら，ベンダのプロジェクトマネジメント義務について 3 段階における計 4 つの義務として整理する 41。
第一は基本契約締結前の企画段階であり，ここでは①企画段階における説明義務がベンダに認められる。例えばスルガ銀行対日本 IBM 判決では，企画・提案段階のベンダの義務として「自ら提案するシステムの機能……等を検討・
41 同様にシステム開発の各段階におけるプロジェクトマネジメント義務の内容を整理したものとして，参照，帷子（2019 年）・前掲注10・149 頁。企画・提案から契約締結までは「企画・提案段階における説明義務」，プロジェクト遂行段階では「進捗状況管理」，「阻害要因排除」，
「関与促進」，「説明，指導，助言」，「中止提言」といった内容がプロジェクトマネジメント義務として認められるという。
検証し，そこから想定されるリスクについて，ユーザに説明する義務」が存在することが認められている。同判決の原審も，企画段階と開発段階とを区別してはいないものの，「ベンダはユーザへの提案前に様々な観点からパッケージの機能，開発手法，リスク等について十分に検証又は検討しなければならない」としている 42。
第二は，基本契約締結後，実際にプロジェクトを進めていく開発段階である。ここでは②完成に向けて開発作業を行う義務，③開発段階における説明義務がベンダのプロジェクトマネジメント義務として認められ得る。このうち②については，スルガ銀行対日本 IBM 判決において「本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務」がベンダに存在することが認められている。この他，CTC 対第一法規判決原審において，ベンダの瑕疵担保責任を検討する際，「開発業務の全般にわたり『プロジェクト管理』の責任があり，……プロジェクトマネジメント義務違反としての責任も免れない」と言及されている。もっとも，完成に向けて開発作業を行う義務はシステム開発契約上のベンダの給付義務そのものといえ，このような義務がベンダに存在することは否定しようがない。
③については上記 3 件の高裁判決において格別争われてはいないものの，システム開発において完成すべきソフトウェアの具体像を段階的に詰めながらプロジェクトを進めることが一般的である以上，ベンダがユーザに対し，都度開発に必要な説明を行ったり情報を提供したりすることは当然認められよう。
第三は，開発段階において特に進行が滞り，完成が危ぶまれたり，完成したとしても期日を大幅に過ぎることが確実視される等，プロジェクトが頓挫の危機に瀕している段階である。ここでは，ベンダに④中止提言義務ないし拒絶義務が認められる可能性がある。上記 3 件の高裁判決ではいずれも，開発が頓挫
42 なお，原審がシステム開発全体のベンダのプロジェクトマネジメント義務違反を肯定したのに対し，控訴審は企画段階と開発段階とを区別してそれぞれについてのプロジェクトマネジメント義務違反の有無を検討し，後者のみ違反を認めている。このため認められた損害賠償額は原審より減額されている。
する危機に瀕している場合に開発そのものを中止したり，ユーザの要望を拒否する義務があるのかが争われ，判断が分かれている。
スルガ銀行対日本 IBM 判決は「開発進行上の危機を回避するための適時適切な説明と提言をし，仮に回避し得ない場合には本件システム開発の中止をも提言する義務」をベンダに認めた。CTC 対第一法規判決は，ベンダには，システム開発契約の目的を達成できなくなる場合にはその旨をユーザに告知し説明する義務があり，「〔それでも〕なお，xxxが変更を求めるときは，これを拒絶する契約上の義務がある」とした。一方，旭川医大対 NTT 東日本判決では，原審はベンダの説得・拒絶義務違反を認めたものの，控訴審では「納期を守るためには更なる追加開発要望をしないようユーザを説得したり，xxxによる不当な追加開発要望を毅然と拒否したりする義務があったということはでき」ないとして義務の存在自体を否定している。
以上のように，ベンダのプロジェクトマネジメント義務はシステムの完成に向けて開発作業を行う義務，契約締結前後の説明義務からなり，場合によっては開発が頓挫の危機に瀕した際の中止提言義務ないし拒絶義務も認められ得る。もっとも，システム開発の内容や頓挫に至る経緯は事案によって異なることから，上述したものにとどまらない義務がベンダに認められる可能性も否定できない。システム開発契約においてベンダに認められ得る義務の内容は多岐にわたり，プロジェクトマネジメント義務は開発過程全体にわたるxxな義務を包括的に表現する用語としてとらえられる 43。
43 この点，xx（2014 年）・前掲注26・16 頁は，プロジェクトマネジメント義務は，実態としては個別具体的義務の集合体であり，そのような個別的義務の違反に基づいてベンダの責任を追及することも可能であるとする。その上で，これらの密接不可分な関係にある個別的義務の包括的概念としてプロジェクトマネジメント義務を設定し，一括して義務違反の責任を追及する方が簡明かつ有益であると主張する。
（3） ベンダのプロジェクトマネジメント義務の根拠
以下では，上述した多様な内容からなるプロジェクトマネジメント義務が，それぞれ何によって根拠付けられるのかを検討する。
まず，②完成に向けて開発作業を行う義務については，上述したように，システム開発契約上のベンダの給付義務そのものであり，プロジェクトマネジメント義務という概念を持ち出すまでもなく契約上の義務として導くことができる。
次に，①企画段階における説明義務や③開発段階における説明義務については，その根拠はベンダの専門家性に求められる。上記 3 件の高裁判決いずれもベンダの専門家性に言及しており，プロジェクトマネジメント義務の根拠付けについて，ひとまず契約当事者間の原則的非対等性と信頼関係として説明することができよう。ユーザはベンダの専門家性への信頼を基礎として契約を締結すると考えられ，このような意味でのプロジェクトマネジメント義務は自己決定基盤の整備を目的として認められてきた情報提供義務や説明義務の一類型と考えることができる 44。
契約における「専門家」の意義とは，「科学または高度の知識に裏づけられ，それ自身一定の基礎理論をもった特殊の技能を，特殊な教育または訓練によって習得し，それに基づいて不特定多数の市民の中から任意に呈示された個々のクライアントの具体的要求に応じて具体的活動を行ない，よって社会全体の利益のためにつくす職業である」とされている 45。そして，このような専門家としての責任の法的根拠は，専門家に対する「現代社会の一般的信頼性ならびに個々のクライアントの，個々のプロフェッションに対する個別・具体的信頼」
44 情報提供義務が認められる典型例は，金融取引，保険，不動産取引，フランチャイズ契約，医療等である。xxxx『新債権総論Ⅰ』（信山社，2017 年）140 頁，xxxx『債権総論〔第 4 版〕』（岩波書店，2020 年）147 ～ 148 頁。
45 xxx「日本法における『専門家の契約責任』」xxxx『専門家の責任』（日本評論社， 1993 年）16 ～ 17 頁。
にあるとされる 46。
もっとも，前述したようにシステム開発契約はベンダとユーザの共同作業という側面があり，専門家たるベンダであっても，ユーザのしかるべき要求や情報提供，協力なしには開発を進めることができない。システム開発につきベンダには専門家性が認められるものの，開発の基礎となるデータはユーザが保有している場合がほとんどであり，単純な情報の格差があるわけではないのである。このように当事者の双方がシステム開発という共通の目的に向けて協働するシステム開発契約は「共同型」とされ，開発対象となるシステムが巨大化・複雑化すればするほどこのような傾向が強まるとされる 47。
本稿で取り上げた 3 件の高裁判決はいずれも巨費を投じた大型のシステム開発契約であり，長期にわたって当事者双方が協力し合いながらプロジェクトを進める「共同型」のシステム開発契約である。そうであるとすると，ベンダがシステム開発の専門家であることに単純に言及するだけでは，プロジェクトマネジメント義務の根拠付けとしていささか不十分であるようにも思われる 48。なお，契約締結前の情報提供義務の法的性質については，判例も不法行為責
46 同上。また，そのように考えた場合，その責任の法的根拠は，当該個別具体的契約上のクライアントの信頼に対する違反として，（不法行為でなく）契約責任構成によるべきであるとされる。
47 xx（2012 年）・前掲注26・57 ～ 58 頁。「共同型」システム開発においては，ユーザもシステム開発についての専門的知見を有する人材を抱えていることが少なくなく，このような場合には，ユーザは単なる協力義務にとどまらず，「その専門的知見を活かしてシステム開発を主導するかのような役割が求められる」という。
48 この点に関連して，ベンダに専門家としての責任を追及することの正当化根拠として，開発にあたってのベンダの裁量に着目する見解がある。ユーザの求めるシステム開発をするために協力し合わねばならないとしても，具体的選択等についてはベンダに一定の裁量がある。すなわち，ベンダが支配可能な範囲で開発手法を決め，その裁量で納期を決めるのであって，結果的にそれがうまくいかず，納期に間に合わなかったり途中で計画自体が頓挫したとしても，基本的にはベンダは責任を免れないと考えられる。xxx「システム開発業者のプロジェクト・マネジメント義務」富大経済論集60 巻1 号（2014 年）41 頁。
任説をとっている 49。スルガ銀行対日本 IBM 判決においても，①企画段階における説明義務について「契約締結に向けた交渉過程におけるxxxに基づく不法行為上の義務」と説明されている 50。これに対して③開発段階における説明義務は，システム開発契約の付随義務として認められることになろう。
最後に，その根拠付けが特に問題となるのは，④中止提言義務ないし拒絶義務である。この義務をベンダのプロジェクトマネジメント義務として認めた高裁判決の文言を見ると，部分的には助言義務として説明することが可能であるように思われる。助言義務には多種多様な内容が含まれ得るが，「情報提供義務を超えて，相手方が求めている目的に照らしてその行動が有利かどうかについて，専門家としての評価をし，助言する義務」とされている 51。
例えばスルガ銀行対日本 IBM 判決は，「開発計画の中止の要否とその影響等について……〔の〕説明義務を負うものというべきである」とし，さらに開発進行上の危機を回避し得ない場合には「本件システム開発の中止をも提言する義務があった」とする。CTC 対第一法規判決は，システム開発契約の目的を達成できなくなる場合には，xxxは「ユーザに対し，これを告知して説明すべき義務を負うものであって，なお，xxxが変更を求めるときは，これを拒絶する契約上の義務がある」とする。いずれも前半部分については，開発中止の要否やそれによるユーザへの影響について説明・助言することを内容とする，契約上の付随義務と考えることができる。
49 xx（2020 年）・前掲注44・150 ～ 151 頁。xxは，義務の根拠が契約自由の実質的確保にあることからすると，債務不履行責任として構成するべきではないかと指摘する。
50 スルガ銀行対日本IBM 判決では，ベンダから，プロジェクトマネジメント義務は付随義務であり付随義務違反に基づく解除はできないとの主張がなされた。控訴審は，プロジェクトマネジメント義務はシステム開発において契約の目的達成に不可欠の義務であるとしてユーザによる解除を認めている。
51 xxxx『消費者契約の法理論』（弘文堂，2002 年，初出1990 年）96 頁。また，参照，xx（2020 年）・前掲注44・148 頁。契約締結前の指導助言義務について，参照，xx（2017 年）・前掲注44・148 ～ 150 頁。契約締結前であっても，一方当事者が専門家であり，相手方の求めている目的を知っており，相手方との間に信認関係が成立している場合には，助言義務が認められ得る。
しかしながら，このような説明・助言を受けてなおユーザが開発中止に応じずあくまでプロジェクトを進めようとする場合，これを拒絶したり開発中止を提言したりする義務を，xxx上の付随義務として構成することができるかは疑問である。
この点，プロジェクトマネジメント義務の中核は説明義務であり，それを超えて拒絶義務を課すには契約条項が必要となる可能性があるとの指摘がある 52。確かに，ベンダがプロジェクトマネジメント義務の一環として中止提言義務ないし拒絶義務を認めた上記 2 つの高裁判決では，大幅な延期や中止をせざるを得ないような状況における損害賠償等についての合意や，大幅な仕様変更があり協議が整わない場合の対応についての合意が存在した 53。ここでは，このような合意の存在から，本件プロジェクトが頓挫しかねないリスクをはらんだものであることをベンダが認識していることが認められる。そうであるとすれば，それでもなお開発を阻害するようなユーザの行動を拒絶しなかったベンダには，結果として生じたリスクを負担することが求められよう。
システム開発契約上の付随義務として中止提言義務ないし拒絶義務をベンダに課すことについては，実務上も困難があるようである。というのも，開発を中止する場合，xxxにとってはその時点までの報酬を回収することが難しい。改正後民法 634 条は仕事未完成の場合の割合的な報酬請求権を明文化したが，システム開発が中途で終了した場合，未完成のソフトウェアがユーザ側に利益があると認められる場合は考えにくい 54。また，大手ベンダ企業の契約書のひ
52 帷子（2020 年）・前掲注31・96 頁。
53 スルガ銀行対日本IBM 判決における基本合意書3 条，CTC 対第一法規判決における個別契約3条3項。
54 「情報システム・モデル取引・契約書」を公開している経済産業省のワーキンググループは，民法改正に対応した整理を行った際，この点について，システム開発契約において可分性や報酬額を決める利益の割合を金銭的に評価するのは困難ではないかと指摘している。経済産業省 モデル取引・契約書見直し検討部会「第一版及び追補版 DX 推進のための見直しにおける民法改正を踏まえた整理にあたって」（2019 年12 月公開）19 頁。xxxxx://xxx.xxx. xx.xx/xxxxx/000000000.xxx
な型は，仕様変更の合意ができなかった場合は中止し作業分の費用を支払うとされていることが多いが，実際には最初の工程は安価で，工程が進んだところで回収することが想定されているため，ベンダにとっては続行しないと採算が合わないとされる 55。システムが完成して初めてシステム構築に係る報酬を回収できる立場にあるベンダにとっては，プロジェクト中止提言の選択肢は選び難いものであるといえる 56。
以上からすれば，説明義務を超えるような中止提言義務ないし拒絶義務は，システム開発契約の付随義務としては当然には導かれないと考えるのが妥当であろう。当事者が契約書等においてこれらの内容につき合意した場合にのみ，これを根拠として，プロジェクトマネジメント義務の一環として中止提言義務ないし拒絶義務が認められるべきである 57。
55 影島ほか（2018 年(2)）・前掲注2・36 頁，xx（2019 年）・前掲注34・68 ～ 69 頁。
56 ベンダがユーザの追加要望を拒絶して従来の要望通りに開発を進めるとすれば，結果的にはユーザにとって不要のシステムが完成することになり，双方にとって望ましくない結末となる。
57 ベンダの中止提言義務ないし拒絶義務が契約上の付随義務としては認められないとしても，開発が頓挫することが確実な場合においてなおユーザがベンダとの契約関係を維持することに拘る場合には，いわゆる損害軽減の法理を適用し得るのではないだろうか。すなわち，代替取引によってユーザが自らの損害を軽減できるのであれば，ユーザは現在のシステム開発契約に拘らずに代替取引を行い，仮にそうしなかったために拡大した損害については賠償の対象としないことが考えられる。
損害軽減義務は，国際物品売買契約に関する国際連合条約（CISG）§77，ヨーロッパ契約法原則（PECL）§9-505 等において採用されている。わが国の債権法改正作業においても，民法418 条の「過失相殺」の文言を排除し，「損害軽減義務」によって損害賠償額を調整することが検討された（ただし実現せず，「過失相殺」文言が維持された）。民法418 条にまつわる改正作業の経緯について，参照，xxxx『民法（債権関係）改正法の概要』（きんざい， 2017 年）72 ～ 73 頁。また損害軽減義務に関する論稿として，xxx「契約の拘束力―強制履行と損害賠償」同『契約の時代』（岩波書店，2000 年）176 頁，xxxxx『損害賠償調整の法的構造―請求者の行為と過失相殺理論の再構成のために』（日本評論社，2011 年）97 頁，xxxx「損害拡大防止義務」xxxx編『民法学の現在とxxx』（法律文化社，2012 年） 122 頁等。
（4） ユーザの協力義務との関係
システム開発契約におけるユーザの協力義務について正面から論じたものは，上記 3 件の高裁判決のうち旭川医大対 NTT 東日本判決のみである。しかしながら，この他の 2 件の高裁判決においても，xxxの損害賠償責任やその際の過失相殺の判断において，プロジェクトに対するユーザの協力の態様が評価されている。そこで以下では，ユーザの協力義務の具体的内容や，ベンダのプロジェクトマネジメント義務との関係について検討する。
まず，ユーザの協力義務に関しては，旭川医大対 NTT 東日本判決のように，ユーザがシステム開発契約上負うべき債務の内容として正面からこれを認めることが考えられる 58。同判決は，システム開発が双方の協力なしには完成し得ないことを前提に，ユーザの協力義務として「本件契約上ユーザの責任とされていたもの……を円滑に行うというような作為義務」と「本件システム開発を妨害しないというような不作為義務」とを肯定している 59。上記作為義務としては，契約上の期日までにユーザが必要なデータ移行作業を済ませること等が考えられる。一方，仕様凍結後にユーザが大量の追加開発要望を出すといった行為は，上記不作為義務に反することになる。
また，例えば，xxxの情報提供義務として，xxxがベンダに対して要望等の情報を適宜伝える義務があるとも考えられる。近年の債権法改正作業においても，改正作業における情報サービス産業関係者の発言として，システム開発取引を念頭に，契約交渉過程だけでなく履行過程においてもユーザ（注文者）の協力義務の一環として情報提供義務を入れてはどうかと立法提案があっ
58 xx（2019 年）・前掲注34・25 頁は，ユーザがシステム開発を妨害しない義務が，契約自体あるいは契約目的そのものから導かれる能動的義務として認められたとして，本判決の判断を妥当であると評価している。
59 この事案ではxxxが協力義務を負うことにつき契約当事者間で合意があったことが強調されているようである。
た 60。この場合，ユーザの契約上の付随義務として協力義務が認められることになる。
一方，ベンダのプロジェクトマネジメント義務違反を判断するにあたっての一要素としてユーザの協力の有無を評価し，間接的にユーザの協力義務を読み込むことも考えられる。スルガ銀行対日本 IBM 判決は，企画段階のベンダのプロジェクトマネジメント義務違反について検討する中で，「ベンダに……説明責任が存するとともに，ユーザにも……システム開発について自らリスク分析をすることが求められる」としている。その上で，企画段階の計画通りに開発が進行しないことにつきベンダに問題がないわけではないとしながらも，ベンダのプロジェクトマネジメント義務違反を否定した 61。
さらに，ベンダのプロジェクトマネジメント義務違反に基づく損害賠償責任が認められた後，過失相殺による賠償額の調整の段階で，ユーザの協力の有無が考慮されることがある。CTC 対第一法規判決の原審は，「責任の所在・瑕疵の発生についてユーザ側にも原因があるという場合には，ベンダのみにその全ての責任を負わすのは不xxであり，過失相殺の法理により，ユーザの損害賠償請求については，減額を認めるのが相当である」とし，過失相殺を認めた。控訴審も，ベンダのプロジェクトマネジメント義務違反がユーザの過失の一因となっていることを理由に，減額の割合を減らした上で過失相殺を認めた。ここでは，xxxの協力義務が，過失相殺の前提となる債権者の注意義務として
60 法制審議会民法（債権関係）部会第27 回会議（2011 年6 月7 日）情報サービス産業協会・xxxx参考人発言。なお，結果としては交渉破棄や情報提供義務の明文化は見送られた。これは，その要件を過不足なく規定するのが困難であり，包括的な要件にすることで濫用が懸念され，他方で要件を絞り込むと法発展に支障をきたすおそれがあるためであると説明される。xxほか編（2020 年）・前掲注37・961 頁〔xx執筆部分〕。
61 他方で開発段階については，上述した通りベンダのプロジェクトマネジメント義務違反が認められており，xxxが同義務を果たしていない以上，xxxがベンダの提案に容易に応じなかったとしても，ユーザの債務不履行責任ないし不法行為責任を問うことはできないとされた。ここでも，ベンダのプロジェクトマネジメント義務違反の判断と密接に関連した形でユーザの協力義務が考慮されている。
読み込まれることになる。
以上から，ユーザの協力義務の内容としては，遅滞なく必要なデータ移行作業を行うことや，システム開発を妨害するような追加要望を出さないこと等，多様なものが考えられる。もっとも，協力「義務」といっても，必ずしも契約目的から，もしくは契約上の付随義務として能動的に根拠付けられるわけではない。直接には債務者（ベンダ）の損害賠償責任を判断する中で，責任決定や賠償額の調整においてユーザの態様についての価値判断がなされ，適切に協力しなければ責任追及が認められなかったり制限されるといった形で，受動的に協力義務が読み込まれることがある。
なお，請負契約における注文者の協力義務については，従来から論じられてきたところである 62。典型的には注文者の受領行為が考えられるが，それにとどまらず，判例研究から具体的な協力行為の実態が示されてきた。xxは，わが国においては注文者の協力懈怠があった場合，請負人の報酬請求権を認める形で請負人を保護してきたと指摘する 63。xxは，①債務の履行の着手の前提となる協力義務，②債務の履行継続に必要となる協力義務，③完成した仕事の引渡しに必要となる協力（受領）義務を区別した上で，①②類型に該当する裁判例においては解除や損害賠償の請求が問題となるとする 64。
本稿で取り上げたシステム開発契約に関する高裁判決において特に争われた，ユーザのシステム開発を阻害しないという意味での協力義務は，上記②類型に該当しよう。旭川医大対 NTT 東日本判決においても認められたように，
62 xxxx「債権者の協力義務―ドイツ請負契約における注文者の義務を中心に」早法44巻（1994 年）1 頁，xxx「注文者の協力義務」xxxxxx『現代契約法の展開』（経済法令研究会，2000 年）265 頁，同『建築請負契約のリスクと帰責』（日本評論社，2009 年）等。また，学説や判例の状況を概観するものとして，xxx編『新注釈民法（14）債権（7）』（有斐閣，2018 年）145 ～ 153 頁〔xxxxx部分〕。
63 xx（1994 年）・前掲注62・30 ～ 31 頁。これに対し，ドイツでは注文者の協力懈怠の効果が規定され（BGB642 条以下），判例も法的義務としての注文者の協力義務を認めてきたという。
64 xx（2000 年）・前掲注62・269 ～ 273 頁。
このような協力義務の違反は損害賠償請求権を根拠付ける他，解除や，（実質的には困難が伴うものの）報酬請求権も認める余地がある。
とはいえ上述したように，裁判例においては協力義務がユーザの契約上の義務として単体で問題となるのではなく，ベンダのプロジェクトマネジメント義務に係る判断と交錯しながら全体として紛争の解決が図られている。特にシステム開発が頓挫した場合には，プロジェクトマネジメント義務違反の決定や過失相殺といった法理を通じて，頓挫に至る両当事者の帰責性を考慮しながら，妥当なリスクの配分が企図されているように思われる。
5 おわりに
本稿は主に 3 件の高裁判決のみを取り上げたものであるが，ベンダのプロジェクトマネジメント義務と総称される義務の中身は多岐にわたることが確認された。すなわち，基本契約締結前の企画段階における説明義務，開発段階における完成に向けた開発作業を行う義務，開発段階における説明義務，そしてプロジェクトが頓挫の危機に瀕している段階における中止提言義務ないし拒絶義務が含まれる。プロジェクトマネジメント義務は，これらの多様な義務を包括する概念として観念される。
このうち完成に向けて開発作業を行う義務は，システム開発契約の目的そのものから導くことができる。企画段階ないし開発段階における説明義務については，システム開発についてのベンダの専門家性を背景に，実効的な私的自治を実現するためにxxx上認められる契約上の付随義務として基本的には説明することができる。とはいえ，「共同型」のシステム開発契約ではベンダとユーザとの間に専門的知識・情報の格差が見られない場合もあり，それでもなおベンダのみに高度な説明義務を課すためにはさらなる理由付けが求められる。また，中止提言義務ないし拒絶義務については契約上の付随義務としては当然には導かれず，裁判所は契約書等の明示の根拠を手がかりとしてこれらの義務の存在を肯定している。
一方，ユーザの協力義務についても，遅滞なく必要なデータ移行作業を行う義務や，システム開発を妨害しない義務等，多様なものが考えられる。その根拠は，ユーザの契約上の義務ないし契約上の付随義務として説明することもできるが，裁判例には，ベンダの損害賠償責任の有無や賠償額の決定に際してユーザの協力義務を考慮していると評価できるものが多い。
システム開発契約紛争の典型例である開発が頓挫した事例においては，一方当事者のみが開発の頓挫を招くというより，両当事者の帰責性が重なり合って頓挫に至ることが多い。このような場合には，将来に向けて契約を解消した上で，契約責任や額の決定に関わる多元的な法理を介して両当事者の帰責性を考慮することで，リスクのxxな分担が図られている。契約両当事者の帰責性が契約責任決定規範を構成する一場面であるといえよう 65。
最後に，本稿では子細に立ち入ることができなかったが，システム開発契約を請負として位置付ける場合，完成義務の判断にもプロジェクトマネジメント義務が関わってくる可能性がある。
システム開発契約においては，建築請負契約同様，予定された最後の工程までの一応の終了によって完成が認められるとされている 66。工程の終了は，標準的には検収の終了を指すとされているが，そもそも検収の基準となる検査仕様書が作成されていなかったり，最終的に合意したシステムの仕様に関して認識の齟齬があるためにユーザが検収を拒否する場合もある。
そこで，厳密には検収の終了を認定できない場合でも，納品したシステムを
65 そもそも，請負契約の契約不適合の評価には請負人の過失が取り込まれるとの指摘がある。仕事の作成過程における様々な要素を請負人が完全にコントロールすることは難しいため，改正前民法下では，こうした要素をどこまでコントロールすれば瑕疵がないと評価されるかが争われ，この点で請負人の過失が問われることがあった。参照，xxほか編（2020年）・前掲注37・867 頁〔xx執筆部分〕。システム開発契約におけるベンダの契約不適合に基づく損害賠償責任が争われる際，ユーザの適切な協力がなかったことをもって責任が否定されるとすれば，ここでは請負人のみならず注文者の過失（ないし帰責性）についても評価されているといえるのではないか。
66 xx＝xx編（2019 年）・前掲注4・361 ～ 362 頁〔xxx路執筆部分〕。
ユーザが運用しているか否かといった完成の徴表となる諸要素や，（ユーザが不具合を主張する場合には）不具合の種類や程度を勘案してシステムの「完成」を判断すべきであるとされる 67。また，xxxが正当な理由なく検収を拒否している場合にも完成を認める余地がある 68。
このような完成概念の判断は，例えばベンダが完成させるべきシステムの程度や，ユーザが検収に際して取るべき行動についての規範的判断に他ならない。であるとすれば，完成概念の判断にあたっても，ベンダのプロジェクトマネジメント義務ないしユーザの協力義務概念に包含される価値判断が働いていると評価できそうである 69。
今後，さらなる学説上の議論や判例の蓄積により，ベンダのプロジェクトマネジメント義務やユーザの協力義務の内容や位置付け，判断基準が整理され，ひいては適正なシステム開発契約実務につながることを期待したい。
提出年月日：2021 年 5 月 24 日
67 同362 頁。本稿で取り上げた旭川医大対NTT 東日本判決でも，システム開発契約において納品後の初期段階における軽微なバグの発生は技術的に不可避であることから，バグ等が存在しても，システムを使用して業務を遂行することが可能であれば仕事が完成したと認定すべきであるとしている。
68 同上。
69 請負契約における完成概念についても，自然科学的な概念ではなく，一定の法的かつ社会経済的評価を含んだ概念であると指摘されている。xxx『建築請負契約の法理』（成文堂， 2013 年，初出2010 年）112 ～ 113 頁。完成概念を「労務によってまとまった結果を発生させること」と定義したとしても，どの程度まとまっているかが問題となり，請負契約の内容が有形物だけでなく無形物にも及ぶ以上，統一的な完成概念を立てることは困難であるという。
なお，仕事完成義務不履行の場合，改正後民法下では，債務の本旨不履行として民法415条に基づく損害賠償責任を負う。請負契約の契約不適合責任についても，売買契約の不適合に関する規定（民法562 条以下）が包括準用され（民法559 条），注文者は請負人に対して民法415 条に基づく損害賠償請求をすることができる。いずれにせよプロジェクトマネジメント義務ないし協力義務概念に包含される契約当事者の帰責性が評価される可能性があり，両者の交錯が問題となり得る。