Ⅲ スルガ銀行・日本 IBM 訴訟
青森法政論叢16号（2015年）
システム開発契約における開発業者のプロジェクト・マネジメント義務
xxxxx
目次
Ⅰ はじめに
Ⅱ システム開発契約の概観
Ⅲ スルガ銀行・日本 IBM 訴訟
Ⅳ プロジェクト・マネジメント義務
Ⅴ おわりに
Ⅰ はじめに
近時、コンピュータ・ソフトウェアや情報処理系システムの開発（以下、システム開発）委託取引を巡って、システム開発業者（以下、ベンダ）と発注者（以下、ユーザ）との間の紛争が増加している。こうしたシステム開発においてベンダとユーザとの間で紛争が生じる原因には、以下のものが考えられる。第一に、契約交渉過程において、開発すべきシステムの仕様が確定していないことがある。つまり、当該システム開発に関する要件定義等が具体的に定まらぬまま、包括的な契約締結や受発注となることが多く（1）、契約締結段階に至っても、当事者間に完成させるべきシステムの内容が「見えていない」ことが多い。結局、完成させるべきシステムの仕様内容等は、契約締結後、ベンダとユーザとの協議を経ながら、開発工程の進捗状況に応じて、徐々に確定していくことになる。これが、「システム開発においては契約締結後の作業において変更が必ず発生する。変更がおこることがあるというのではなく、変更は必ず起こる」といわれる所以である（2）。
第二に、ユーザが技術やシステム開発の進
め方に関する情報に乏しい一方、ベンダもユーザの業務が属する業界の情報に乏しいという「情報の非対称性」、つまり、二重の意味での情報格差の存在が挙げられる（3）。した
がって、システム開発では、ベンダとユーザ両当事者の共同作業的側面が、そのほかの請負契約や委託取引よりも強い。つまり、システム開発に際しては、ベンダは専門家としての高度な技術と知識を最大限駆使してシステム完成に向けて開発業務に従事する一方で、ユーザは、積極的にシステムを導入する業務内容、期待する効果、業界慣習をベンダに伝えるなど、ベンダの開発作業等に協力する義務がある。このような協力体制および密接な連携が適切にとられなければ、当該システムを完成させることは実質的に不可能なのである。
それゆえ、ベンダにはシステム開発に向けての技術的作業だけではなく、当該システム開発プロジェクトの適切な管理が求められる。つまり、開発作業に伴って生じる課題や問題点を調整して開発工程を運営し、場合によっては、当該システム開発に必要な情報を提供するようユーザに指導・助言・提言しなければならない。こうしたベンダによるシステム開発プロジェクトの管理業務は、近時の裁判例によりシステム開発契約におけるベンダの業務のひとつとして認められた。このような義務を、「プロジェクト・マネジメント義務」という。そして、システム開発プロジェクトが途中で頓挫しシステムが完成しなかったような事例では、ベンダのプロジェクト・マネジメントが適切におこなわれていた
か、すなわち、ベンダの「プロジェクト・マネジメント義務」違反の有無が問われた。例えば、その巨額な損害賠償請求が認められたことで世間の耳目を集めたスルガ銀行・日本 IBM 訴訟は、海外製勘定系パッケージソフトをカスタマイズした上で導入するはずだったシステム開発の失敗により、ユーザである銀行とシステム開発業者であるベンダが、当該システム開発プロジェクトの頓挫した責任の所在を争った事件であるが、原審および控訴審は、ベンダのプロジェクト・マネジメント義務違反の有無について詳細に検討を行った事案であった。
そこで本稿は、このスガル銀行・日本 IBM 訴訟をてがかりに、システム開発契約における開発業者（ベンダ）のプロジェクト・マネジメント義務について検討し、最近とりわけ注目されるシステム開発頓挫事例における問題解決の一助としたい。
Ⅱ システム開発契約の概観
1 ．多段階契約方式と一括契約方式
システム開発の手法はいくつかあるが（4）、我が国では大規模システム開発においてはウォーターフォール型という開発手法が一般的に採用される。これは、要件定義から始まって外部設計、内部設計、プログラミング工程、テストを経て運用という開発工程を、あたかも「waterfall（滝）」のように、上流から下流へと流れて各工程をxx進めて開発する開発手法である。この一連の工程を管理することが、ベンダのプロジェクト・マネジメントであり、ベンダは、成果をあげるために、最適な知識、技術、道具、技法を用いる必要がある。他方、ユーザは、最上流において、いわゆる RFP（提案要求書）を作成し、何のために、何の業務を、どんな形でシステム化したいのか明確にするためにベンダと打ち合わせ、プロジェクトを立ち上げる。
従来、システム開発契約はこの開発プロジェクトにかかわる業務を一括して一つの契約書で結ぶ一括契約方式が一般的であった。しかし、最近は、プロジェクトを複数のフェーズにわけ、そのフェーズごとの業務を対象とした個別契約と、全体を対象とした基本契約を締結するケースが主流になっている（5）。このような契約方式を「多段階契約」という（6）。経済産業省は、2007年 4 月に対等な交渉力を有するベンダとユーザを対象とした「情報システム・モデル取引・契約書〈第一版〉」を、2008年 4 月には、中小企業の取引の多数を占めるパッケージ等の取引について「重要事項説明書」を活用した簡易・透明な取引モデルを前提条件とする「情報システム・モデル取引・契約書〈追補版〉」を策定・公表したが、これらも多段階契約方式が採用されている（7）。
さて、一括契約方式では、システム開発の全プロセスを一括で契約する。したがって、契約締結事務は一度で済み、簡便である。また、途中で開発プロジェクトが頓挫した場合には成果物を受け取らないので、ユーザは報酬支払いを拒否することも出来るし、既払金についても、ベンダに返還請求をして原状回復が可能である。しかし、開発対象が定まっていない段階での契約締結となるので、見積もりが比較的高額となりやすい欠点があった。
これに対して、多段階契約方式は、基本契約の締結とともに、工程ごと、業務ごとにそれぞれ分割して個別契約を締結する。そして、各工程では主体的に関与する当事者がユーザかベンダか変わってくるので、工程ごとに、請負契約か準委任契約かを使い分ける。つまり、ユーザが主体的に取り組むべき工程である要件定義工程や外部設計工程は準委任契約を、内部設計工程やシステムテスト工程などのベンダだけで作業が完結する工程は請負契約を選択するということになる（8）。
この方式は、システム開発契約の不確定要因リスクを低減し、開発プロジェクトの進捗状況を把握しやすいという利点がある。また、xxxにとっては、プロジェクト途中の開発費等の増大リスクをユーザへと転嫁できる点や、成果物の完成義務を負う請負の業務をできる限り減らして、完成義務を負わない準委任の作業を多くできるなどのメリットがある。一方で、こうしたベンダの回避したリスクは、xxxが負うことになり、ユーザは増加した費用、工期の延長を受け入れざるを得ない（9）。とはいえ、開発プロジェクトの適切な運営管理が実現される点に鑑みればユーザにとっても多段階契約方式が望ましいという見解もある（10）。
多段階契約方式は、元来、一括契約方式におけるユーザの「丸投げ」意識の防止と、プロジェクト開始当初に確度の高い見積もりを行うことがきわめて困難である契約目的物の性質に対処するために、提唱されたものであった。大規模取引や債務内容が抽象的で不確定なものについての合意形成としては、それほどめずらしいものではないともいわれているが（11）、ベンダは、この多段階契約方式を損害賠償額制限条項と組み合わせてリスク回避を図ろうとすることも多いことから、ユーザの反発を招きやすい（12）。
2 ．法的性質
システム開発契約の法的性質については、これを請負契約とするか準委任契約とするか争われることがある（13）。請負契約であれば、xxxは仕事完成義務を負うので、当該システムが完成しなければユーザから報酬を支払われない（民法632条）。一方、準委任契約であれば、ベンダは成果物につき完成責任を負わないので、当該システムが未完成あるいはシステム開発が頓挫したとしても、開発業務に従事した分の報酬支払いを割合的に請求出来る（民法648条 3 項）。
学説上は、システム開発契約を非典型契約と理解する見解が有力に主張される。ソフトウェア開発委託契約についての考察ではあるが、かような委託契約を請負や準委任などの典型契約構成を併せ持つ新種の非典型契約とする見解によれば、その取引形態は「請負型」
「委任型」「派遣型」の三つに分けられるが、その取引契約の目的・内容に応じて契約類型が当てはめられるという（14）。実際の取引では、請負型で取引されることが多いが、仕事の目的物である「ソフトウェア」の性質上、ユーザとベンダの間で「完成すべき仕事の内容」に認識のずれが生じやすい等の問題があり、民法の請負契約と同様に取り扱うことには無理があるという（15）。
システム開発契約を、準委任契約から請負契約へと法的性質が流動していく契約と捉える見解もある。この見解は、システム開発契約の段階的・発展的にその内容が確定して、積み重ねられていくという特徴に着目して、契約当初は委任契約としてスタートし、その内容が確定して、積み重ねられていくのに応じて、委任契約の要素が減少し、最終的には請負契約としてゴールするという理解が説得的であるとする（16）。
また、これもソフトウェア開発委託契約に関する論稿であるが、かような契約が基本契約と複数の個別契約とが一体になった契約である点、契約の目的となるのは開発されるべき「知的給付」であり「物（有体物）」ではないという点、注文者が通常の請負契約以上に仕事の完成に向けて協力義務を負うことになる契約である点、及び、どの段階をもって仕事の「完成」したと考えるべきか不明であることから、典型的な請負契約ではなく非典型契約であると主張する見解もある（17）。この見解によれば、「ソフトウェア開発委託契約は、受託者が債務内容の実現に努力するという点では（準）委任契約的な要素を有しているといえるが、その努力は成果（物）の完
成に向けてであり、その点では請負契約の要素を有している」ことから、請負契約の要素と準委任契約の要素を有する混合契約ということになろう。
さらに、「ソフトウェア開発業界の慣行やその導入コスト等に鑑みて、…現在の民法の典型契約である請負契約や準委任契約において解釈するのは無理がある」と述べて、我が国にも、かような契約の特殊性を考慮した、法整備・法政策の導入を提案する見解もある（18）。
このように、システム開発契約を非典型契約と解する諸見解は、システム開発契約における多段階契約方式の採用やシステム開発におけるユーザとベンダの共同作業の側面といったシステム開発契約の有する独自性を理由に、典型契約として構成するのは困難であると主張している（19）。
これに対して、「ソフトウェアは完成しなければ無意味」であるとして、特殊な場合（20）を除き、システム開発契約は請負契約とする見解が主張されている（21）。この見解によれば、合意された品質・機能を有するシステムを完成させることが契約の目的であるのはいうまでもなく、ベンダの有するシステム開発能力をもってビジネス展開する以上、結果を実現する義務があり、ユーザもそれを信頼して代金を支払うということをもって、請負契約構成が妥当であるという（22）。
請負契約とは、請負人がある仕事を完成することを約し、注文者がその仕事の結果に対して報酬を支払うことを約することにより成立する契約類型である。「仕事の完成」とは、労務の提供により一定の結果を実現することであるが、これは有形的な結果の実現に限らず、無体的な仕事を中心としたものも考えられる（23）。システム開発契約もまた、ベンダの約した「仕事の完成（システム完成）」に対してユーザがその報酬を支払うことから、私見もこれを請負契約の一類型と理解する。
確かに、システム開発契約では、ユーザがシステム開発工程にある程度関与することもあり、ベンダとユーザの間には共同作業的側面が存在することから、システム開発契約を請負契約と構成することに異論もある（24）。しかし、かような共同作業的側面は、いかなる請負契約にも、ある程度は存在するであろうし、注文者に情報提供等の協力義務を課すことは、xxx上の注意義務として請負契約上も認める余地はある（25）。このことが、システム開発契約の請負契約構成を阻害する要因にはならないだろう（26）。
また、最近のシステム開発契約の多くは工程ごとに個別契約を締結する多段階契約方式がとられており、このような契約方式を採用する当事者（とりわけベンダ）の意図は、ベンダのリスク回避にある。つまり、個別契約の出来るだけ多くを準委任とすることで、xxxが仕事完成義務を負うことなく、個別契約ごとに定められた業務終了段階で対価請求権を生じさせることを企図して、かような契約が締結されている。システム開発契約を請負契約と構成することは、こうした当事者意思をないがしろにする可能性もあるだろう。しかしながら、多段階契約方式で締結されたシステム開発契約は、工程ごとの個別契約のほかに、その基本契約において、いかなる開発手法で、どのようなスケジュールで、いつまでに当該システムを完成させるかが合意されている。つまり基本契約で合意された内容によるシステムの完成を前提として、各個別契約が締結されているといえる。また、ユーザも、成果として何も残らないにもかかわらず報酬を支払うことを想定していたとも思われない（27）。したがって、「全体として開発プロジェクト当初の提案書に示されているようなシステムの完成を目的として合意し、基本契約が締結されてシステム開発プロジェクトが開始される（28）」ということに鑑みれば、システム開発契約は基本契約締結段階で請負
契約とするべきである。
Ⅲ スルガ銀行・日本IBM訴訟
次に、スルガ銀行・日本 IBM 訴訟の概要を紹介しその判決内容の検討を行う。しかし、事案および判決は、複雑かつ膨大で論点も多岐にわたることから、本稿の問題対象たる「プロジェクト・マネジメント義務」に係る部分を中心に紹介することとする。
1 ．事案の概要
平成12年ごろ、スルガ銀行（原告、被控訴人。以下、X）は、基幹システムの刷新を図るため、日本 IBM（被告、控訴人。以下、Y）に新たな基幹システム構築の提案等の検討を依頼したところ、Y は、同年 9 月ごろから提案の検討を行った。
平成16年 3 月ごろ、X は Y から米国 FIS 社製の外銀向けパッケージソフトである
「Corebank」を採用するシステム開発プロジェクトの提案を受けた。そこで、同年 9 月に、X は、複数のシステム開発業者から提案されたシステムを比較検討した結果、X の基幹系オンラインシステムを Y が提供するバンキングシステムをもとに全面的に改良し、本件システムを構築すること、その初期費用として約95億円、保守費用として約 6 億2000万円（年額）を支出することを決めた。同年 9 月29日に本件基本合意書①と計画・要件定義＃1に係る IBM 支援サービス契約を、同年 12月29日に本件基本合意書②と IBM システムインテグレーション契約が締結され、計画・要件定義＃2が開始された。その後、平成17年 6 月に予定されていた最終合意書の締結は延期され、平成17年 9 月30日に最終合意書の締結がされた。サービスインは平成20年 1 月とされた。
ところが、平成17年12月に、Y が開発方法の「カスタマイズベース・アプローチ」から
「パッケージベース・アプローチ」への変更
と、プロジェクトの見直しを提案してきた。 X はこれを受け入れて、平成18年 3 月に旧 BRD（実質は要件定義のやり直し）が実施され、 6 月には Corebank の権利を保有するFIS社が深く関与する体制に改善された新 BRD
（実質は 2 回目の要件定義やり直し）が実施された。このため、同年 4 月に開始した実装工程（プログラミング）作業が中断した。
平成18年12月ごろ、Y から、X に対して開発スコープの削減と開発費用の追加負担として約34億円の支払いが提案され、その後、Yから、X の追加負担を20億円に減少させる案が提案された。これについては、XY 間で協議を重ねてきたが合意できない状態が続いた。さらに、Y は、平成19年 3 月に、平成22年 1 月までに 5 段階に分けて全面稼働させるスケジュールを提案したが、これも X に拒否される。
平成19年 4 月18日、Y から、基幹系パッケージソフトをCorebank から Temenos 社のTCBを採用する代替案が提案されるが、これも Xは拒否する。同年 5 月 9 日に至って、X は、 Y に対して、本件プロジェクトをいったん白紙に戻す旨の書面を交付し、同年 7 月18日には、本件最終合意及び本件個別契約を Y の債務不履行（履行不能）により解除する旨の意思表示をした。
そして、X は、本件システム開発が中止になったことにつき、Y に対して請負契約の債務不履行または不法行為に基づく損害賠償等を理由に、約116億円の賠償を求めた。これに対して Y は、反訴として、X に対して、本件未払個別契約の代金支払請求、および Xの協力義務違反に基づく損害賠償として約 125億円を請求した。
原審は本件システム開発契約が頓挫したのは、Y のプロジェクト・マネジメント義務違反によるものであるとして、Y に対し約74億円の損害賠償を支払うよう命じた。そこで、 Y が控訴。控訴審でもX の主張が認められた
が、損害賠償の認定額は、約41億円に減額された。X およびY は、ともにこれを不服として、直ちに上告したが、平成27年 7 月 8 日、最高裁は、X と Y の上告を棄却し、上告受理申立てを不受理とする決定をした。
2 ．判決
（1） 原審（東京地判平成24年 3 月29日 金法1952号111頁）（29）
原審は、以下のような理由で反訴請求をすべて棄却し、Y に対して約74億円の支払いを命じた。
まず、原告の主張する被告の債務不履行責任ないし、不法行為責任については、次のように判示する。「（最終合意書によれば）…原告の支払金額の法的拘束力については、原告と被告との間で本件プロジェクトの各局面における義務を定めた個別契約が締結されることを前提条件として生ずるものとされていると解すべきで…、個別契約の大半が未締結であることが認められる。そうすると、上記支払総額が法的拘束力を有するに至る程度に条件が充たされているとはいえないので、被告の債務不履行又は不法行為の成立をいう原告の上記主張は採用することができない。」
次に、原審は、本件では、xxxには以下に挙げるようなプロジェクト・マネジメント義務違反があり、そのためにシステム開発が頓挫したといえるので、ベンダに不法行為に基づく損害賠償責任を認めた。すなわち、 1）基幹系パッケージソフトとして選定された Corebank の検証・検討が不十分で、その上、Corebank のカスタマイズに必要な体制を整えていなかった。
2）X に対して、こうした事情について特に説明がなかった。
3）サービスインの時期が延期された。
4）最終合意締結後の合意を尊重する姿勢を表明していたにもかかわらず、変更、延期が繰り返された。さらに、別の基幹系パッケー
ジソフトの提案がなされた時点で、信頼関係は喪失した。
これに加えて、さらに原審は、本件システム開発について X には協力義務違反はないと判じている。
（2） 控訴審（東京高判平成25年 9 月26日金商判1428号16頁）（30）
控訴審では、原判決が変更、請求は一部認容され、Y に約41億円の損害賠償の支払いが命じられた。
本判決は、まず、本件システム開発判断枠組を、Ⅰ：企画準備から本件基本合意①締結前の段階（企画・提案）、Ⅱ：本件基本合意
①締結から本件基本合意②締結前の段階（計画・要件定義）、Ⅲ：本件基本合意②締結から本件最終合意締結前の段階（計画・要件定義）、Ⅳ：本件最終合意締結から本件システム開発終了の段階（計画・要件定義，実装）の 4 つの段階に分けて、各フェーズにおけるプロジェクト・マネジメント義務違反の検討を行った。
Ⅰの段階におけるプロジェクト・マネジメント義務違反の有無については、xxxには、自ら提案するシステムの機能や開発手法等、想定されたリスクについて、ユーザに説明する義務があるとされた。そして、このような義務は、「契約締結に向けた交渉過程におけるxxxに基づく不法行為法上の義務として位置づけられ、…ベンダとしてかかる義務（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる。」とした。しかし、この段階では、X は「本件システム開発の過程において一定の修正等があり得ることも当然想定されていたものというべき」なので、本件では「Ⅰの段階において，控訴人にプロジェクト・マネジメントに関する義務違反を認めることはできない」とした。そして、「本件システム開発において、
…控訴人は、前記各契約に基づき…本件シス
テム開発を担うベンダとして、被控訴人に対
し、本件システム開発過程において、適宜得られた情報を集約・分析して、ベンダとして通常求められる専門的知見を用いてシステム構築を進め、ユーザである被控訴人に必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整等を行いつつ、本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである」と述べつつ、
Ⅱ、Ⅲという最終合意締結以前の段階では Yにプロジェクト・マネジメント義務違反はなかったが、Ⅳ（最終合意締結後）の段階においては、このプロジェクト・マネジメント義務違反があるとして不法行為責任を認めた。すなわち、「前記義務の具体的な内容は、 契約文言等からxx的に定まるものではなく、システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。」として、「控訴人は、…被控訴人に対して、ベンダとしての知識・経験、本件システムに関する状況の分析等に基づき、開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直す必要があることについて説明し適切な見直しを行わなければ、本件システム開発を進めることができないこと、その結果、従来の投入費用更には今後の費用が無駄になることがあることを具体的に説明し、ユーザである被控訴人の適切な判断を促す義務があったというべきである。また、本件最終合意は，前記のような局面において締結されたものであるから、控訴人は、ベンダとして、この段階以降の本件システム
開発の推進を図り、開発進行上の危機を回避
するための適時適切な説明と提言をし、仮に回避し得ない場合には本件システム開発の中止をも提言する義務があったというべきである。」
こうして本件最終合意段階における不法行為が成立すると認められたことから、X は、 Y の義務違反により、本来、必要としなかっ
た費用の支出を強いられたものと認められ、 Y は、X に対し、「不法行為に基づきその費用相当額の損害賠償をする義務を負う」とされた。
さらに、Y の主張した本件未払個別契約等に基づく未払代金については、「…同契約について債務不履行（プロジェクト・マネジメントに関する義務違反。個別契約についても同様である。）があったものということができる。」として、本件未払金個別契約は「全部解除したとして控訴人の請求を拒むことができると解するのが相当である。」「ベンダのプロジェクト・マネジメントは、システム開発において、契約目的達成に不可欠の義務となるものであるから、同義務違反による解除は妨げられないというべきである」とされた。
（3） 考察
本件は原審、控訴審ともに「本件最終合意」に法的拘束力を認めなかったため、債務不履行責任は問題にならず、いずれも、ベンダたる Y の不法行為責任として処理された。つまり、ベンダのプロジェクト・マネジメント義務違反が不法行為に該当するとしてこれに基づく損害賠償請求を認めたのである。
原審は、Y の不法行為責任を認める前提として、Y に対して、プロジェクト・マネジメント義務違反を認定した。つまり、原審は、プロジェクト・マネジメント義務を、不法行為上の注意義務（xxx上の義務）であることを明らかにしたのである。
控訴審も、プロジェクト・マネジメント義務違反による不法行為責任に基づく損害賠償を認めるという大枠は原審と変わらない。しかしながら、Y の損害賠償額は約74億円から約41億円へ大幅に減額されている。これは、原審が、システム開発の企画設計の段階以降に生じた費用すべてを損害として認定しているのに対して、控訴審は、最終合意以降の費用にのみ損害を限定し、損害の対象となる費用の起算時期を遅らせて損害額を縮減したこ
とによる。
次に、プロジェクト・マネジメント義務違反の内容についても、原審と控訴審では異なる判断があった。原審は、基幹系パッケージソフトである Corebank の邦銀業務への適合性や Corebank を採用するとの判断が本件システム開発に適切であったか、開発手法が妥当であったか等について、Y が十分にこれを検討しなかったことをプロジェクト・マネジメント義務違反と認定し、X の実損害のほぼ満額を賠償対象としていた。
これに対して、控訴審は、Ⅰの段階におけるプロジェクト・マネジメント義務については、これを「契約締結に向けた交渉過程におけるxxxに基づく不法行為上の義務」と認定しつつ、ベンダの義務違反を認めなかった。このようなプロジェクト・マネジメント義務は、受発注前の段階では、契約目的に不確実性がみられることから、ベンダの「事前検証などの方法・程度はおのずと限られる」ので、「ユーザも業務分析とベンダの説明を踏まえてシステム開発に自らリスク分析することが求められる」とし、ユーザに応分のリスク負担を認めた。
Ⅱ・Ⅲ・Ⅳの段階におけるプロジェクト・マネジメント義務については、「各基本合意や個別契約に基づき、ベンダとして通常求められる専門的知見を用いてシステム構築を進め、ユーザに適宜説明を行いその了解を得ながら、修正、調整を行いつつ本件システム完成にむけて作業を行うことを適切に行う義務」としながらも、その具体的内容は、システム開発の遂行過程における状況に応じて変化するとした。その上で、Ⅳの段階において、本件システムを開発することが不可能であることが明らかになっていたとして、開発スケジュール等を抜本的に見直すか、それが困難ならば、開発そのものを断念するかを含めて決定しなければいけない局面だったと認定し、このような場合には、「システムの抜
本的変更必要性への説明義務」、または「中止等の提言すべき義務（中止提言義務）」があるとした。このように、プロジェクト・マネジメント義務をプロジェクトの進捗段階に応じて変化させ、具体化させていることは興味深いとの見解もある（31）。
そして、控訴審には、プロジェクト・マネジメント義務の根拠や内容を考察する上で、次のような意義があると思われる。
① ベンダのプロジェクト・マネジメント義務は必ずしも、契約上の義務というだけでなく、xxxにもとづいて発生する義務でもあり、その義務違反は不法行為責任を負うことが明らかになった。
② このxxx上のプロジェクト・マネジメント義務は、システム開発の企画提案段階
（契約締結前）でも存在するとされた。つまり、ベンダには企画提案段階でも、想定されるリスク等について説明する義務があることが明らかにされたのである。しかし、ユーザ自身のリスク分析も求められ、この段階ではベンダの義務は軽減される。
③ システム開発の上流工程と下流工程では開発手法等の不確実性を反映して内容が一様ではない。したがって、システム開発では、ベンダの果たすべきプロジェクト・マネジメント義務は各段階で変容していくものと認められる。
④ ベンダにはシステム開発が頓挫しうることが明らかになった場合は、プロジェクトの「抜本的見直し」や「中止」を提言すべき義務があることが示された。
⑤ 本判決は、代金未払個別契約に対する Yの代金支払請求を、Y のプロジェクト・マネジメント義務違反による X の契約解除を理由に排斥していることから、プロジェクト・マネジメント義務をシステム開発契約における付随的義務ではなく契約目的達成に不可欠な義務であることを明らかにした。
しかしながら、控訴審には以下のような問題点がある。そもそも、本件システム開発の失敗の最大の原因は、当初のパッケージソフトの選定ミスにあったのではないかと思われる。原審が認定したように、パッケージソフトの選定は開発対象たるシステムの根幹をなすものである。「パッケージソフトの選定こそ、専門的知識および経験を持つベンダとしてのプロジェクト・マネジメントの腕の見せ所」といわれるほど（32）、本件事案では重大な義務違反がここにはあったと思われる。したがって、この部分に関して、責任を問えないという控訴審の判断には疑問である（33）。
Ⅳ プロジェクト・マネジメント義務
1 ．プロジェクト・マネジメント義務とは
ここでは、まず、スルガ銀行・日本 IBM訴訟以前に、システム開発契約において、ベンダにシステム開発のプロジェクトを適宜管理等する義務を認めた裁判例をいくつか紹介するが、プロジェクト・マネジメント義務という用語が、最初に裁判例に現れたのは、東京地判平成16年 3 月10日（裁判例ⅴ）であった。
（1） 裁判例の紹介
（ⅰ）東京地判平成 9 年 9 月24日（判タ967号168頁）
システム開発を原告に依頼したユーザが稼働スケジュールの遅滞及び納品されたソフトの瑕疵を理由に債務不履行に基づいて契約を解除したことに対して、ベンダが解除の有効性と当該システム開発に係る代金支払いを請求した事例である。
判決は、「原告（ベンダ）は、コンピュータ関係の専門企業として、顧客（ユーザ）である被告から提供された資料及び聴取等の結果に基づき、本件システムの導入目的に適合したプログラムを作成すべきxxx上の義務
を負担するものといえる」として、ベンダの非を認めたものの、被告（ユーザ）もまた自ら積極的に本件システムへの切り替えにむけて原告に協力すべきxxx上の義務があったが、これを果たしてなく、スケジュール遅延の一因は被告にあるとして、契約解除は認めず、原告（ベンダ）の代金支払請求を認めた。
（ⅱ）広島地判平成11年10月27日（判時1699号101頁）
ユーザがベンダに対して、基幹業務システムソフトの製作請負もしくは製造販売契約に基づいてソフトの欠陥により被った損害の賠償を請求した事例である。裁判所は、xxxは、「コンピュータソフトの製作に関し自らが有する高度の専門的知識経験に基づき、販売管理、経営管理の迅速化や合理化を図るという本件システムの目的の実現に努めるべき責務を負」うので、専門技術的な視点から判断して必要と思われる事項の提案や指摘をする義務があると述べて、ベンダの納品したシステムには、機能を欠く債務不履行部分が有ると認定した。
（ⅲ ） 東京地判平成14年 4 月22日（34（） 判タ 1127号161頁）
ベンダがシステムを納品したにも関わらず、ユーザがその代金の一部を支払わなかったことにつき残代金の支払いを請求した。これに対してユーザは、ベンダによる不適切なシステム開発により損害を被ったとして損害賠償の反訴請求をした。裁判所は、「本件において、原告は、その提案書で、本件システムの目的について、販売管理及び経営管理の迅速化並びに合理化を図ることを提示しているのであるから、システム開発の専門家として、自らが有する高度の専門的知識経験に基づき、処理の迅速化という目的の実現に務めるべき責務を負っており、被告の要望事項の増加や被告のデータ運用方法の仕様が未確定である等、処理の迅速化を阻害する要因を認識した場合には、被告に対し、当該要因を指
摘し改善を求めるべき注意義務を負っていたというべきである」から、「原告が、システム開発業者として求められていた当該注意義務を果たしたと認めるに足りる証拠はなく、本件各瑕疵は、かかる原告の開発作業が原因で発生した蓋然性が高いと認めるのが相当」として、「原告によるシステム開発作業における注意義務違反にあるものと認めるのが相当である。」とした。
（ⅳ）東京地八王子支部判平成15年11月 5 日
（判時1857号73頁）
ユーザがベンダに対して納品されたシステムに瑕疵が有ったと主張して請負契約の解除に基づいて代金等の返還請求をするとともに、十分なヒアリングをしなかったことが専門家としての善管注意義務違反に当たるとして債務不履行に基づく損害賠償を請求した事例である。裁判所は「被告（ベンダ）は、コンピュータ・ソフトウェアの開発、販売、コンサルティング等の専門企業であり、システムを構築するについては、顧客である原告
（ユーザ）から、その業務の内容等必要な事項を聴取し、その結果に基づいて、原告のシステム導入目的に適うシステムを構築すべき義務」を負うとしたが、「…一方で、ユーザにもシステム構築に必要な情報を正確に提供すべきxxx上の義務を負う」として、本件は、ユーザが正確な情報を提供していないとして、ベンダの義務違反や瑕疵の存在を否定した。
こうしたベンダの「自ら有する高度に専門的知識経験」を理由とした開発プロジェクト管理やユーザへの注意義務に関する判決の流れを受けて、このようなベンダの義務を「プロジェクト・マネジメント義務」として定式化・精緻化した判例（35）として、次の判決が登場した。
（ⅴ ） 東京地判平成16年 3 月10日（36（） 判タ 1211号129頁）
ユーザが納入期限までにシステムが完成しなかったことを理由に債務不履行に基づいて契約解除を主張し支払い済みの委託料等の返還を請求したのに対し、ベンダが、納入期限までに完成しなかったのはユーザが協力義務に違反したことが原因であると主張し、反訴としてユーザの債務不履行に基づいて損害賠償を請求した事例である。
裁判所は、「被告（ベンダ）は、注文者である原告のシステム開発への関わりについても、適切に管理し、システム開発について専門的知識を有しない原告によって開発作業を阻害する行為がされることのないよう原告に働きかける義務（以下、これをプロジェクト・マネジメント義務という）を負っていたというべきである」として、具体的には、開発プロジェクトの推進に関してユーザが決定すべき事項等につき「…ユーザがこれを決定ないし解決できるよう導く義務を負い…」、開発プロジェクトに支障をきたすようなシステム機能追加や変更等の要求をユーザがしてきた場合には「…ユーザに適宜その旨説明して、要求の撤回や追加委託料の負担、納入期限の延期等を求めるべき義務」を、ベンダのプロジェクト・マネジメント義務として示した上で、本件被告ベンダの「プロジェクト・マネジメントは、不適切であったと言わざるを得ない」とした。一方、原告ユーザの協力義務違反もまた認定し、当該システム開発の頓挫は双方の不完全履行が相まって生じたものであるとして、ベンダとユーザの過失割合 6 対 4 と認定した。
（2） プロジェクト・マネジメント義務の具
体的内容
システム開発契約では、ベンダがプロジェクト・マネジメント義務を負い、その義務違反による責めを負うことに異論はない。また、プロジェクト・マネジメント義務は、裁判例の蓄積により、発展し、質的・内容的にも拡大してきたといえる。スルガ銀行・日本
IBM 訴訟控訴審は、さらに、プロジェクト・マネジメント義務について、プロジェクト進捗状況に伴う「変動性」を指摘した（37）。そこで、これまでの裁判例を概観することにより、プロジェクト・マネジメント義務とは、さしあたり、以下のような内容としてまとめられよう。
①開発プロジェクトの進捗状況管理義務
②開発プロジェクト阻害要因排除義務
③ユーザへのプロジェクト関与促進義務
④ユーザへの説明義務
⑤ユーザへの指導助言・提言義務
これらは、大別すると、ベンダ側のシステム開発プロジェクト進行を適時適切に運営する義務（①②）と、ユーザ管理・支援義務（③
④⑤）に分けることも可能である（38）。
システム開発プロジェクト失敗の要因には、ユーザによる業務要件確定の遅れや無理な機能追加といった、ユーザの対応が原因となる場合も多い。しかし、システム開発プロジェクトにおいて、ユーザがシステムに関する様々な要望をするのは当然であり、それに、委託料や追加の納入期限が必要かどうかは、専門的知識のないユーザが的確に判断するのは困難である。判決はこうした理由から、ベンダに③④⑤のような対応を求め、
「ユーザを支援する義務」がプロジェクト・マネジメント義務の一内容として盛り込まれているのだろうと考える（39）。
2 ．プロジェクト・マネジメント義務および義務違反の根拠
以上のように、プロジェクト・マネジメント義務の具体的内容は、裁判例ではそれぞれの事案に応じて、さまざまなものが見受けられた。しかし、プロジェクト・マネジメント義務の法的根拠について、判決文中で明らかにしているのは、請負契約上の義務であると判示した、上記裁判例（ⅳ）のみであった（40），（41）。
その他の判決の多くは、ベンダに「専門家
として自ら有する高度の専門的知識と経験」に基づく責任があると述べるのみで、その法的根拠は明らかではない（42）。確かに、システム開発には、何よりもまずシステム開発に関する有能な技術力（あるいは技術者の能力）が必要であり、かつ、ベンダは「開発プロジェクトを遂行するための標準化された開発手法および開発体制」も備えていなくてはならないとされる。それは、システム開発は、手工業的要素が強く、「人」に依存するため、有能なプロジェクト・マネジメント能力が必要だからである。裁判所が、「専門家として自ら有する高度の専門的知識と経験」という場合は、開発技術だけでなく、その開発手法・体制やプロジェクト・マネジメント能力を総称したものだといわれている（43）。
スルガ銀行・日本 IBM 事件控訴審でも、ベンダの専門家としての知識や経験等に基づいたプロジェクト・マネジメント義務論が展開されているが、当該システム開発契約の拘束性を否定したため、債務不履行責任としての判断はされず、ベンダに、プロジェクト・マネジメント義務違反による不法行為に基づく損害賠償責任を認めただけであった。これは、当該プロジェクト・マネジメント義務を、xxx上の一般的注意義務と位置付けたと考えられるが、そのような義務の発生根拠もまた法的には不明瞭である。
一方で、同控訴審は、プロジェクト・マネジメント義務をシステム開発において契約目的達成に不可欠の義務であるとして、同義務違反による契約解除を認め、最終合意締結後に締結された未払個別契約の解除も認めた。すなわち、プロジェクト・マネジメント義務違反による契約解除を認めることで、プロジェクト・マネジメント義務を、契約上の付随義務ではなく、いわゆる「給付義務（債権者に対して為すべく義務づけられている行為を為すべき義務）（44）」と解釈されたと考える。これには、プロジェクト・マネジメント
義務違反という 1 つの解除原因により個別の契約の解除を認めることになり、多段階契約であっても、複数の契約解除を認める判決という見方ができるという見解もあり（45）、このように考えるならば、多段階契約方式を採用するベンダのメリットが失われる可能性もあるだろう。
そこで、プロジェクト・マネジメント義務の法的根拠について、システム開発契約の法的性質から考察を試みる。
システム開発契約を準委任契約ないし準委任契約要素を持つ非典型契約と考えるならば、プロジェクト・マネジメント義務は、まさに委任契約上の善管注意義務の一内容ということになる。
一方、システム開発契約を請負契約ないし請負契約要素を持つ非典型契約と考えれば、プロジェクト・マネジメント義務は、請負契約上の義務ということが出来る。請負契約の基本的義務は「仕事完成義務」である。そこで、プロジェクト・マネジメント義務を、仕事完成義務の付随的義務であると捉えるならば、プロジェクト・マネジメント義務違反は、仕事完成義務における付随的義務違反ということになるだろう（46）。しかしながら、付随的義務は、債権者から履行の請求ができず、付随的義務違反に対する損害賠償請求が出来るだけであり（47）、したがって、債権者が付随的義務違反を理由に契約を解除することも出来ないと考える。だが、ユーザがベンダにプロジェクト・マネジメント義務の履行を請求できないこと、また、ベンダの不適切なプロジェクト・マネジメントのために、システム開発が中止に追い込まれた場合に、ユーザがプロジェクト・マネジメント義務違反を理由にシステム開発契約を解除できないということには疑問がある。
したがって、プロジェクト・マネジメント
義務は、請負契約の「要素たる債務（契約目的を達成するために必要不可欠な債務）」と
理解し、プロジェクト・マネジメント義務違反はベンダの仕事完成義務違反としてその責任を問うのが妥当ではないかと考える。つまり、プロジェクト・マネジメント義務を「仕事の完成」に向けて行う作為義務として、請負人の「仕事完成義務」に包摂されるものと捉え、その不履行により仕事完成という契約目的を達成できなくなるような債務と捉えるのである。
ある契約において、何が要素たる債務か、付随的債務なのかの区別は相対的なものであり、一般的・抽象的に定められるものではなく、契約ごとに判断されるべきであるといわれている（48）。そして、そのような判断は、社会通念に照らし、契約締結の際の事情をすべて考慮して客観的に決定した当事者の合理的意思を基準にして行われるべきであるとされる。その上で、契約の目的がどこにあったのかを明らかにし、その目的の達成に必要不可欠なものでなければ付随的債務であるし、目的達成に不可欠であって、それが履行されなければ契約の目的が達成されず、当事者は契約を締結しなかったろうと判断される場合には契約の要素をなす債務であるという（49）。
システム開発契約におけるプロジェクト・マネジメント義務についても、このような観点から検討すると、システム開発契約の目的は、終局的にはシステムの完成であるが、スルガ銀行・日本 IBM 訴訟控訴審でも言及されたように、これを達成するためには、適切なプロジェクト・マネジメントが不可欠といえる。プロジェクト・マネジメント義務違反は、必然的にシステム開発の失敗、つまり、仕事の未完成を導くからである。
確かに、「仕事の完成」そのものが債務であり、その履行過程について問われない請負契約にあって、「仕事の完成」に向けての具体的作為義務を要素たる債務として認めることはできないとの批判もあるだろう。しかし、「仕事の完成」の過程を問わないことが
「仕事の完成」への具体的作為義務がないという帰結にはならない。むしろ、「仕事の完成」に向けての具体的作為の積み重ねにより
「仕事の完成」という結果に至るからである。したがって、プロジェクト・マネジメント義務は、請負契約としてのシステム開発契約における要素たる債務、すなわち請負人の仕事完成義務の一内容と考えられる。
3 ．契約準備段階の義務と中止提言義務
スルガ銀行・日本 IBM 訴訟控訴審では、開発プロジェクト進捗管理義務やユーザ管理・支援義務といった従来の裁判例や原審で言及されていたプロジェクト・マネジメント義務に加えて、「企画・提案段階における説明義務」と「開発進行上の危機を回避し得ない場合のプロジェクト中止提言義務」を、プロジェクト・マネジメント義務の一内容として、ベンダに履行を求めている。とりわけ、ユーザの個別の要望の撤回にとどまらず、システム開発プロジェクトの全体的中止を提言することも、プロジェクト・マネジメントの一環と捉えられた点は注目に値する。
これは、従来のプロジェクト・マネジメン
ト義務と比べると、非常にxxな義務をベンダに課すことになる内容であるといえよう。もっとも、控訴審は「企画提案段階の説明義務」については、事実認定の上、ベンダに義務違反を認めなかった。しかし、「中止提言義務」については、このような義務を怠ったためにユーザの損害を拡大させたとして、ベンダに損害賠償責任が認められた。しかし、プロジェクト・マネジメント義務を、請負契約の「仕事完成義務」そのものと捉える私見からは、これらの義務をプロジェクト・マネジメント義務の 1 つとみなすことには、疑問がある。
まず、「企画提案段階の説明義務」については、あえてプロジェクト・マネジメント義務とする必要はなかったと考える（50）。これ
は、いわゆる「契約準備段階の説明義務」であり、「契約締結上の過失」法理の下、契約準備段階に認められたxxxに基づく不法行為法上の説明義務と構成しても問題はなかったと思われる（51）。
次に、システム開発プロジェクトに対する
「中止提言義務」もまた、あえてプロジェクト・マネジメント義務と位置づける必要はないと考える。前述したように、プロジェクト・マネジメント義務とは、システム開発に際して、システム開発の進捗状況を管理し、開発の進行を阻害する要因を適時に発見または排除し、ユーザに適時適切な説明や指導・提言を行うというベンダの義務である。これらは、まさに、ベンダが「システムの完成」という「仕事の完成」に向けて努力する義務である。しかしながら、システム開発中止提言義務は、「システムの完成」に向けられた義務とはいえない。
「中止提言義務」は、むしろ、ユーザの利益保護に向けられた義務である。つまり、契約相手方の完全性利益保護を目的とする保護義務と考えられる。そして、このような保護義務は、意思に基づかない債務として、主たる債務とは独立して存在するxxx上の債務として観念される（52）。したがって、「中止提言義務」は、請負契約上のプロジェクト・マネジメント義務の一内容と理解するのではなく、ユーザの利益保護に向けられた保護義務と理解するのが妥当であると考える（53）。
Ⅴ おわりに
以上、システム開発契約におけるベンダのプロジェクト・マネジメント義務について、スルガ銀行・日本 IBM 訴訟、ならびに最近の裁判例の動向を踏まえて、その義務内容と義務の発生根拠について検討してきた。プロジェクト・マネジメント義務は裁判例の蓄積によりその内容が具体化されてきたものだが、スルガ銀行・日本IBM 訴訟控訴審に至っ
て、システム開発にかかわったベンダのユーザに対するあらゆる義務が、プロジェクト・マネジメント義務の名の下に説明されることには疑問が生じた。
そこで、本稿では、プロジェクト・マネジメント義務の内容や発生根拠について、次のような結論を得た。第一に、システム開発契約を請負契約そのものと考える本稿では、プロジェクト・マネジメント義務は、請負契約の要素たる債務であり、仕事完成義務に包摂された具体的作為義務ということが出来る。第二に、このようにプロジェクト・マネジメント義務を請負契約の要素たる債務の 1 つとして仕事完成義務に包摂して考えるならば、システム開発の企画提案段階における説明義務や、開発プロジェクト中止提言義務は、プロジェクト・マネジメント義務の一内容とはいえない。これらの義務は、確かに、ベンダが負うべきユーザの利益保護義務ではあるが、プロジェクト・マネジメント義務とは法的発生根拠を異にする、別種の義務といえる。本稿では、システム開発契約の法的性質か らベンダのプロジェクト・マネジメント義務を検討したが、残された課題として、システム開発プロジェクトに向けられたユーザの協力義務との関係がある。ベンダのプロジェクト・マネジメント義務とユーザの協力義務は表裏一体の関係にあり、システム開発において、ユーザの協力義務もまた欠かせないものである。これに関しては、今後、別稿にて検
討の予定である。
システム開発の失敗をめぐる紛争はあとを絶たない（54）。判例理論のさらなる集積と学説上の議論の高まりによって、今後、システム開発契約やプロジェクト・マネジメント義務論の一層の進展が期待される。
注
⑴ xxx「システム開発における請負人のプロジェクト・マネジメント義務および損害賠償をめぐる争い」NBL990号（2012年）115頁。
⑵ 情報システム・ソフトウェア取引高度化コンソーシアム編「情報システム・ソフトウェア取引トラブル事例集」（2010年）10頁（xxxx://xxx.xxxx. xx.xx/xxxxxx/xx_xxxxxx/xxxxxxxxx/xxxxxxx%00xxxxx. pdf#search 最終アクセス2015年 6 月22日）。
⑶ xxxx「システム契約でもめないために」会社法務 A2Z2014年 8 号（2014年）21頁。
⑷ その他、スパイラル型、プロトタイピング型、アジャイル型という手法がある。スパイラル型、プロトタイピング型については、JISA 法的問題委員会契約部会編「新しいソフトウェア開発委託取引の契約と実務」（商事法務2003年）参照。アジャイル型については最近多くの論稿があるが、さしあたりxxxx「アジャイル開発の特性と契約ポイント」Business Law Journal 2013年 7 号（2013年） 40頁以下参照。
⑸ xxx「トンでも『IT 契約』に騙されるな」（日経 BP 社 2013年）20頁。
⑹ xx・前掲 5 26頁によれば、多段階契約方式の広まったきっかけの1つは当時の通商産業大臣の諮問機関である産業構造審議会情報産業部会が 1992年12月に公表した「緊急提言ソフトウェア新時代」という答申であるといわれている。
⑺ 「モデル取引・契約書」について詳細に検討を加えたものとして以下の文献がある。xxxx
「システム開発契約における典型契約の意義と債務内容の事後的判断基準─情報システム・モデル取引・契約書における役割分担を題材に─」法学新報114巻11・12号（2008年）751頁以下。xxによれば、「モデル契約書」に示される請負契約、準委任契約という典型契約類型の設定は、当事者の「あるべき役割分担」を示すことで、紛争予防的観点からは重要な意義を有するが、紛争発生後の事後的判断基準としては十分機能しないとのことである。
⑻ xx・前掲 7 761頁によれば、「モデル契約書」のフェーズごとに請負契約とするか準委任契約とするかの設定もこのような思考を前提としているようである。
⑼ xxxx「大規模システム開発の契約交渉とプロジェクト運営のポイント～紛争リスクを最小化
するために～」Business Law Journal 2011年12月号（2011年）25頁。
⑽ 松島・前掲 9 26頁。
⑾ xxxx「判批（スルガ銀行・日本 IBM 事件控訴審）」金融法務事情2001号（2014年）74頁。
⑿ xxxx「情報システム開発契約の多段階契約に関する新しいアプローチの必要性─スルガ銀行・日本IBM 事件─」NBL977号（2012年）4 頁。
⒀ 例えば、東京地判平成 3 年 2 月22日（判タ770号218頁）では、プログラム開発委託契約が請負契約か準委任契約かで争われたが、請負契約と認定され受託者の報酬支払請求は認められなかった。また、東京地判平成22年 9 月21日（判タ1349号136頁）は、コンピュータシステムに関するコンサルティング契約及びシステム開発契約について、当該契約書に準委任契約と書かれているとしてもシステム構築に係る部分は請負契約の要素を含むと判示された。
⒁ xxx「ソフトウェア開発委託契約紛争事例の研究（1）」現代法学10号（2006年）168頁。
⒂ xxx「ソフトウェア開発委託契約紛争事例の研究（2）」現代法学11号（2006年）95頁。
⒃ xxxx「判批（スルガ銀行・日本 IBM 事件原審）」私法判例リマークス47号（2013年）21頁。
⒄ xxxx「ソフトウェア開発委託契約」xxx・xxxx「非典型契約の総合的検討」（商事法務 2013年）171頁。
⒅ xxxx「情報システム・ソフトウェア開発委託契約の特殊性と紛争」帝塚山法学23号（2012年） 11頁。また、13頁以下では中国契約法における「技術開発合同（330条～ 341条）」の規定が紹介されている。
⒆ 東京地方裁判所プラクティス委員会第二小委員会「ソフトウェア関係訴訟の手引」判例タイムズ 1349号（2011年）7 頁では、ソフトウェア開発は、
①ソフトウェアの無体物、②契約締結段階での成果物の不確定性、③請負人と注文者の共同作業的性質、④システム納品後のバグ対応の必然性、⑤システム納品後の注文者への運用指導問題、といった実体法的に未解決の問題があるため、民法の請負に関する規定をそのまま適用して処理してよいのか、問題が有ると指摘する。
⒇ xxxx「請負人の債務（2）─プロジェクト・マネジメント義務をてがかりに─」福岡大学法学論叢59巻 1 号（2014年）143頁によれば、「特殊な
場合」とは、必ずしも成果物がはっきりしないような場合、ユーザとベンダの共同事業性が強い場合、実験的なソフトやシステムを開発するような場合とされる。
㉑ xxxx「注文者の協力義務─コンピュータソフト開発をめぐる最近の判例を中心に─」福岡大学法学論叢52巻 4 号（2008年）396頁。
㉒ xx・前掲20 144頁。
㉓ xxxx「民法総合5契約法」信山社（2007年） 552頁。
㉔ 例えば、xxxx「金融システム開発契約に係る法的諸論点の帰趨―東京地判平成24.3.29を契機として─」金融法務事情1952号（2012年）57頁では、システム開発契約は、システム開発という共通の目的に向けて協働するといった共同開発契約になるケースが多くなると指摘し、請負契約とは明らかに様相が異なると指摘している。
㉕ xx・前掲23 598頁。
㉖ 注文者の協力義務についての論考として、xxx「注文者の協力義務」xxxxxx『現代契約法の展開』（経済法令研究会 2000年）269頁、xx・前掲21が参考になる。
㉗ xx量一ほか「情報システムの開発・運用と法務～判例の蓄積状況と紛争処理実務の変化～」 NBL1050号（2015年） 9 頁（xx量一発言）。
㉘ xx量一ほか「情報システムの開発・運用と法務～判例の蓄積状況と紛争処理実務の変化～」 NBL1050号（2015年）8頁（xxx発言）。xx弁護士は、さらに、「仕事の完成に相当する内容が契約書に規定されているので、…実質的には請負契約の性質を有することになる」としつつも、「あまり契約類型に拘泥することは実益がないということは指摘をしておきたい」とも発言する。
㉙ 原審に関する判例研究としては、xxxx「スルガ銀行対日本 IBM 事件東京地裁判決のポイント解説」Business Law Journal 2012年 8 号（2012年）67頁、xxxx「スルガ銀行・日本 IBM 裁判が今後のシステム開発プロジェクトに及ぼす影響（上）・（下）」ビジネス法務2012年 8 月号（2012年）82頁、2012年 9 月号（2012年）82頁、xx・前掲12 4 頁、xx・前掲24 52頁、xxxx
「金融機関システム開発と法的問題─スルガ銀行対日本 IBM 事件を契機として─」銀行法務21 745号（2012年） 8 頁、xxxx「判批」新判例解説 Watch12号（2013年）87頁、滝沢・前掲16
18頁。
㉚ 控訴審の判例研究としては、xxxx「システム開発における法的責任の新たな枠組み─スルガ銀行・日本 IBM 事件高裁判決─ 」NBL1013号
（2013年） 4 頁、xxxx「判批」新・判例解説 Watch14号（2014年）91頁、xxxx「スルガ銀行対日本 IBM 事件東京高裁の分析」Business Law Journal 2014年 1 号（2014年 ）16頁、 同「スルガ銀行VS 日本IBM 事件」東京高裁判決の意義」金融財政事情2013年12月16日号（2013年）30頁、xx・前掲11 71頁、xxxx「システム開発の頓挫と開発業者の責任─スルガ銀行・日本 IBM事件第xxおよび控訴審判決をめぐって─」福岡大学法学論叢59巻3号（2014年） 1 頁。
㉛ xx・前掲11 73頁。
㉜ xxx「システム開発業者のプロジェクト・マネジメント義務」富山経済論集60巻 1 号（2014年） 65頁。
㉝ 同様の指摘をするものとして、xx・前掲32 65頁は、ベンダに選定したパッケージソフトに熟知した者がおらず、パッケージソフトの海外権利者に全面的に頼っていたベンダの対応も本件システム開発の失敗の要因に挙げている。
㉞ 本判決には次の評釈がある。xxxx「判批」私法判例リマークス29号（2004年）30頁。
㉟ xxxx「電算システム開発契約における注文者の協力義務と請負人のプロジェクト・マネジメント義務─東京地判平成16年 3 月10日判例タイムズ1211号129頁─ 」福岡大学法学論叢52巻 4 号
（2008年）483頁。
㊱ 本判決の判例評釈として、xx・前掲35 471頁。その他、xxx「判例から学ぶ『外部委託契約』」日経コンピュータ2007年10月15日号（2007年）54頁。
㊲ xx・前掲32 57頁。また、xx・前掲11 73頁は、判決が全体としてベンダにプロジェクト・マネジメント義務を想定しつつ、その内容をプロジェクトの進捗段階に応じて変化させていることを興味深いと述べる。
一方で、このような事前に義務の具体的内容が定まることのない（動態的・浮動的義務）ことに対する当事者への不意打ちリスクをどのように克服すべきであるかという問題については、xx・前掲20 141頁が、「ベンダは高度な専門的知識・経験に基づく開発・遂行能力でもって対価を得て
おり、xxxはこれを信頼して対価を支払うのだから、こうした『リスク』をも含めて報酬を得ているということから、浮動性を有するプロジェクト・マネジメント義務を正当化できる」という見解を述べる。
㊳ 同様に、プロジェクト・マネジメント義務を大別して紹介したものに、xxxx「システム開発訴訟における攻防」Business Law Journal 2013年 7 号（2013年）37頁。ここでxx弁護士は、「進捗管理・阻害要因排除義務」と「発注者管理義務」との分類方法を示している。
㊴ ベンダにこうした重い責任を課すのは酷であると考えることもできよう。しかし、xx・前掲35 484頁によれば、ベンダを請負人と理解した上 で、彼が専門的知識・経験を有していること、報酬の対価としての仕事完成義務の内容には請負業務を遂行するために必要な顧客への適切な助言・指導も当然に含まれていると解することもでき
る。
㊵ プロジェクト・マネジメント義務を「（ユーザの）システム導入目的にかなうシステムを構築すべき義務を本件請負契約に基づき負うものと解される」という。
㊶ これについて、裁判例（ⅳ）が、プロジェクト・マネジメント義務を請負契約上の付随義務として捉えたと評価するものとして、xxx・xxxx
「プロジェクト・マネジメント義務に関する問題点」ビジネス法務2013年 1 月号（2013年）100頁
㊷ この点、すでにxxxxは、請負人がその仕事について専門的知識をもつことを理由として、注文者のなした指図が不適当なものであるときは、請負人において注意を与える義務があると述べていることは、本稿のプロジェクト・マネジメント義務を考察するに当たり重要である。xxx「債権各論中巻二」（岩波書店 1962年）615頁。
㊸ xx・前掲 1 116頁。
㊹ xxxx「債権総論（増補版）」（悠々社 1992年）16頁。
㊺ xxxx「多段階契約・個別条項に与える影響」Business Law Journal 2014年 1 号（2014年） 47頁。
㊻ xx＝xx・前掲41 104頁は、プロジェクト・マネジメント義務を「システムを完成させるという中心的義務を達成するために必要な付随義務」としてxxxに基づいて発生するという。ま
た、xx・前掲20 146頁も「請負人の主たる義務である仕事完成義務に付随する義務」と考える。
㊼ xxxx「債権総論第三版」（岩波書店 2013年）113頁。
㊽ xxxx「契約規範の成立と範囲」（一粒社 1999年）216頁。
㊾ xxx「付随的債務の不履行と解除」『契約法大系Ⅰ』（有斐閣1962年）316頁。
㊿ 同様の指摘をするものとして、xx・前掲32 60頁。
このような契約準備段階の説明義務の存在を認めたものとして、最判平成23年 4 月22日民集65巻 3 号1405頁。
xx・前掲48 214頁。
xxx「システム開発におけるベンダのプロジェクト・マネジメント義務」国際商事法務42巻 7 号（2014年）1105頁は、中止提言義務に関して、契約当事者の損害軽減義務の観点からプロジェクト中止の要否や影響を説明する義務があることは容易に理解できると述べている。
例えば、本稿執筆時点では、システム開発中途挫折事例として、xxホールディングス・xx証券と日本 IBM との紛争（日経コンピュータ2014年11月27日号56頁）や、テルモ（医療機器大手）とアクセンチュアとの紛争（日経コンピュータ 2014年12月25日号50頁）が、共に東京地裁に係争中である。