青森法政論叢16号（2015年）

システム開発契約における開発業者のプロジェクト・マネジメント義務
栗原由紀子
目次
Ⅰ

はじめに

Ⅱ

システム開発契約の概観

Ⅲ

スルガ銀行・日本 IBM 訴訟

Ⅳ

プロジェクト・マネジメント義務

Ⅴ

おわりに

がって、システム開発では、ベンダとユーザⅠ

はじめに両当事者の共同作業的側面が、そのほかの請

近時、コンピュータ・ソフトウェアや情報

負契約や委託取引よりも強い。つまり、シス

処理系システムの開発（以下、システム開発）

テム開発に際しては、ベンダは専門家として委託取引を巡って、システム開発業者（以の高度な技術と知識を最大限駆使してシステ

下、ベンダ）と発注者（以下、ユーザ）とのム完成に向けて開発業務に従事する一方で、間の紛争が増加している。こうしたシステム

ユーザは、積極的にシステムを導入する業務

開発においてベンダとユーザとの間で紛争が内容、期待する効果、業界慣習をベンダに伝生じる原因には、以下のものが考えられる。

えるなど、ベンダの開発作業等に協力する義第一に、契約交渉過程において、開発すべき務がある。このような協力体制および密接なシステムの仕様が確定していないことがあ

連携が適切にとられなければ、当該システムる。つまり、当該システム開発に関する要件を完成させることは実質的に不可能なのであ定義等が具体的に定まらぬまま、包括的な契る。

約締結や受発注となることが多く（1）、契約締

それゆえ、ベンダにはシステム開発に向け結段階に至っても、当事者間に完成させるべての技術的作業だけではなく、当該システム

きシステムの内容が「見えていない」ことが開発プロジェクトの適切な管理が求められ多い。結局、完成させるべきシステムの仕様る。つまり、開発作業に伴って生じる課題や内容等は、契約締結後、ベンダとユーザとの問題点を調整して開発工程を運営し、場合に協議を経ながら、開発工程の進捗状況に応じ

よっては、当該システム開発に必要な情報をて、徐々に確定していくことになる。これ提供するようユーザに指導・助言・提言しなが、「システム開発においては契約締結後のければならない。こうしたベンダによるシス作業において変更が必ず発生する。変更がおテム開発プロジェクトの管理業務は、近時のこることがあるというのではなく、変更は必裁判例によりシステム開発契約におけるベンず起こる」といわれる所以である 。

ダの業務のひとつとして認められた。このよ（2）

第二に、ユーザが技術やシステム開発の進

うな義務を、「プロジェクト・マネジメント

め方に関する情報に乏しい一方、ベンダも義務」という。そして、システム開発プロ

ユーザの業務が属する業界の情報に乏しいとジェクトが途中で頓挫しシステムが完成しな

いう「情報の非対称性」、つまり、二重の意

かったような事例では、ベンダのプロジェク

味での情報格差の存在が挙げられる 。した

ト・マネジメントが適切におこなわれていた

（3）

― 1 ―

青森法政論叢16号（2015年）

か、すなわち、ベンダの「プロジェクト・マ

従来、システム開発契約はこの開発プロ

ネジメント義務」違反の有無が問われた。例

ジェクトにかかわる業務を一括して一つの契えば、その巨額な損害賠償請求が認められた約書で結ぶ一括契約方式が一般的であった。

ことで世間の耳目を集めたスルガ銀行・日本

し か し、 最 近 は、 プ ロ ジ ェ ク ト を 複 数 のIBM 訴訟は、海外製勘定系パッケージソフ

フェーズにわけ、そのフェーズごとの業務をトをカスタマイズした上で導入するはずだっ対象とした個別契約と、全体を対象とした基たシステム開発の失敗により、ユーザである

本契約を締結するケースが主流になってい銀行とシステム開発業者であるベンダが、当る（5）。このような契約方式を「多段階契約」

該システム開発プロジェクトの頓挫した責任という（6）。経済産業省は、2007年 4 月に対等の所在を争った事件であるが、原審および控な交渉力を有するベンダとユーザを対象とし訴審は、ベンダのプロジェクト・マネジメン

た「情報システム・モデル取引・契約書〈第ト義務違反の有無について詳細に検討を行っ一版〉」を、2008年 4 月には、中小企業の取た事案であった。

引の多数を占めるパッケージ等の取引についそ こ で 本 稿 は、 こ の ス ガ ル 銀 行・ 日 本て「重要事項説明書」を活用した簡易・透明IBM 訴訟をてがかりに、システム開発契約

な取引モデルを前提条件とする「情報システ

における開発業者（ベンダ）のプロジェク

ム・モデル取引・契約書〈追補版〉」を策定・

ト・マネジメント義務について検討し、最近公表したが、これらも多段階契約方式が採用

とりわけ注目されるシステム開発頓挫事例にされている（7）。

おける問題解決の一助としたい。

さて、一括契約方式では、システム開発の全プロセスを一括で契約する。したがって、

Ⅱ

システム開発契約の概観

契約締結事務は一度で済み、簡便である。また、途中で開発プロジェクトが頓挫した場合

1 ．多段階契約方式と一括契約方式には成果物を受け取らないので、ユーザは報システム開発の手法はいくつかあるが 、酬支払いを拒否することも出来るし、既払金

我が国では大規模システム開発においてはについても、ベンダに返還請求をして原状回ウォーターフォール型という開発手法が一般復が可能である。しかし、開発対象が定まっ（4）的に採用される。これは、要件定義から始ていない段階での契約締結となるので、見積

まって外部設計、内部設計、プログラミング

もりが比較的高額となりやすい欠点があっ

工程、テストを経て運用という開発工程を、た。

あたかも「waterfall（滝）」のように、上流

これに対して、多段階契約方式は、基本契から下流へと流れて各工程を順次進めて開発約の締結とともに、工程ごと、業務ごとにそする開発手法である。この一連の工程を管理

れぞれ分割して個別契約を締結する。そしすることが、ベンダのプロジェクト・マネジて、各工程では主体的に関与する当事者がメントであり、ベンダは、成果をあげるため

ユーザかベンダか変わってくるので、工程ごに、最適な知識、技術、道具、技法を用いるとに、請負契約か準委任契約かを使い分け必要がある。他方、ユーザは、最上流においる。つまり、ユーザが主体的に取り組むべきて、いわゆる RFP（提案要求書）を作成し、工程である要件定義工程や外部設計工程は準何のために、何の業務を、どんな形でシステ

委任契約を、内部設計工程やシステムテスト

ム化したいのか明確にするためにベンダと打工程などのベンダだけで作業が完結する工程

ち合わせ、プロジェクトを立ち上げる。

は請負契約を選択するということになる（8）。
― 2 ―システム開発契約における開発業者のプロジェクト・マネジメント義務

この方式は、システム開発契約の不確定要因

学説上は、システム開発契約を非典型契約

リスクを低減し、開発プロジェクトの進捗状と理解する見解が有力に主張される。ソフト

況を把握しやすいという利点がある。また、ウェア開発委託契約についての考察ではある

ベンダにとっては、プロジェクト途中の開発

が、かような委託契約を請負や準委任などの費等の増大リスクをユーザへと転嫁できる点

典型契約構成を併せ持つ新種の非典型契約とや、成果物の完成義務を負う請負の業務をでする見解によれば、その取引形態は「請負型」

きる限り減らして、完成義務を負わない準委「委任型」「派遣型」の三つに分けられるが、任の作業を多くできるなどのメリットがあ

その取引契約の目的・内容に応じて契約類型る。一方で、こうしたベンダの回避したリスが当てはめられるという（14）。実際の取引でクは、ユーザが負うことになり、ユーザは増は、請負型で取引されることが多いが、仕事加した費用、工期の延長を受け入れざるを得の目的物である「ソフトウェア」の性質上、ない（9）。とはいえ、開発プロジェクトの適切ユーザとベンダの間で「完成すべき仕事の内な運営管理が実現される点に鑑みればユーザ容」に認識のずれが生じやすい等の問題があにとっても多段階契約方式が望ましいというり、民法の請負契約と同様に取り扱うことに見解もあるは無理があるという（15）。

。

（10）

多段階契約方式は、元来、一括契約方式にシステム開発契約を、準委任契約から請負おけるユーザの「丸投げ」意識の防止と、プ契約へと法的性質が流動していく契約と捉え

ロジェクト開始当初に確度の高い見積もりをる見解もある。この見解は、システム開発契行うことがきわめて困難である契約目的物の約の段階的・発展的にその内容が確定して、性質に対処するために、提唱されたもので積み重ねられていくという特徴に着目して、あった。大規模取引や債務内容が抽象的で不契約当初は委任契約としてスタートし、その確定なものについての合意形成としては、そ内容が確定して、積み重ねられていくのに応れほどめずらしいものではないともいわれてじて、委任契約の要素が減少し、最終的にはいるが、ベンダは、この多段階契約方式（11）

を損害賠償額制限条項と組み合わせてリスク請負契約としてゴールするという理解が説得的であるとする（16）。

回避を図ろうとすることも多いことから、ユーザの反発を招きやすい

また、これもソフトウェア開発委託契約に関する論稿であるが、かような契約が基本契

。

（12）

約と複数の個別契約とが一体になった契約で2 ．法的性質

ある点、契約の目的となるのは開発されるべシステム開発契約の法的性質については、

き「知的給付」であり「物（有体物）」ではこれを請負契約とするか準委任契約とするかないという点、注文者が通常の請負契約以上（13）争われることがある。請負契約であれば、に仕事の完成に向けて協力義務を負うことにベンダは仕事完成義務を負うので、当該シスなる契約である点、及び、どの段階をもってテムが完成しなければユーザから報酬を支払

仕事の「完成」したと考えるべきか不明であわれない（民法632条）。一方、準委任契約でることから、典型的な請負契約ではなく非典あれば、ベンダは成果物につき完成責任を負型契約であると主張する見解もある（17）。こ

わないので、当該システムが未完成あるいはの見解によれば、「ソフトウェア開発委託契システム開発が頓挫したとしても、開発業務

約は、受託者が債務内容の実現に努力するとに従事した分の報酬支払いを割合的に請求出いう点では（準）委任契約的な要素を有して来る（民法648条 3 項）。

いるといえるが、その努力は成果（物）の完― 3 ―青森法政論叢16号（2015年）

成に向けてであり、その点では請負契約の要

確かに、システム開発契約では、ユーザが素を有している」ことから、請負契約の要素

システム開発工程にある程度関与することもと準委任契約の要素を有する混合契約というあり、ベンダとユーザの間には共同作業的側ことになろう。

面が存在することから、システム開発契約をさらに、「ソフトウェア開発業界の慣行や請負契約と構成することに異論もある（24）。

その導入コスト等に鑑みて、…現在の民法のしかし、かような共同作業的側面は、いかな

典型契約である請負契約や準委任契約においる請負契約にも、ある程度は存在するであろて解釈するのは無理がある」と述べて、我がうし、注文者に情報提供等の協力義務を課す

国にも、かような契約の特殊性を考慮した、

ことは、信義則上の注意義務として請負契約

法整備・法政策の導入を提案する見解もあ上も認める余地はある（25）。このことが、シる（18）。

ステム開発契約の請負契約構成を阻害する要このように、システム開発契約を非典型契因にはならないだろう（26）。

約と解する諸見解は、システム開発契約におまた、最近のシステム開発契約の多くは工ける多段階契約方式の採用やシステム開発に

程ごとに個別契約を締結する多段階契約方式

おけるユーザとベンダの共同作業の側面とがとられており、このような契約方式を採用いったシステム開発契約の有する独自性を理する当事者（とりわけベンダ）の意図は、ベ由に、典型契約として構成するのは困難であンダのリスク回避にある。つまり、個別契約ると主張しているの出来るだけ多くを準委任とすることで、ベ

。

（19）

これに対して、「ソフトウェアは完成しなンダが仕事完成義務を負うことなく、個別契ければ無意味」であるとして、特殊な場合（20）約ごとに定められた業務終了段階で対価請求を除き、システム開発契約は請負契約とする権を生じさせることを企図して、かような契見解が主張されている（21）。この見解によれ約が締結されている。システム開発契約を請ば、合意された品質・機能を有するシステム

負契約と構成することは、こうした当事者意を完成させることが契約の目的であるのはい思をないがしろにする可能性もあるだろう。

うまでもなく、ベンダの有するシステム開発

しかしながら、多段階契約方式で締結された能力をもってビジネス展開する以上、結果をシステム開発契約は、工程ごとの個別契約の実現する義務があり、ユーザもそれを信頼しほかに、その基本契約において、いかなる開て代金を支払うということをもって、請負契発手法で、どのようなスケジュールで、いつ約構成が妥当であるというまでに当該システムを完成させるかが合意さ

。

（22）

請負契約とは、請負人がある仕事を完成すれている。つまり基本契約で合意された内容

ることを約し、注文者がその仕事の結果に対によるシステムの完成を前提として、各個別して報酬を支払うことを約することにより成契約が締結されているといえる。また、ユー

立する契約類型である。
「仕事の完成」とは、ザも、成果として何も残らないにもかかわら労務の提供により一定の結果を実現することず報酬を支払うことを想定していたとも思わであるが、これは有形的な結果の実現に限られない（27）。したがって、「全体として開発プ

ず、無体的な仕事を中心としたものも考えら

ロジェクト当初の提案書に示されているようれる。システム開発契約もまた、ベンダなシステムの完成を目的として合意し、基本の約した「仕事の完成（システム完成）」に契約が締結されてシステム開発プロジェクト

対してユーザがその報酬を支払うことから、が開始される（28）」ということに鑑みれば、私見もこれを請負契約の一類型と理解する。

システム開発契約は基本契約締結段階で請負

（23）

― 4 ―

システム開発契約における開発業者のプロジェクト・マネジメント義務と、プロジェクトの見直しを提案してきた。

契約とするべきである。

X はこれを受け入れて、平成18年 3 月に旧
Ⅲ

スルガ銀行・日本IBM訴訟

BRD（実質は要件定義のやり直し）が実施さ

次に、スルガ銀行・日本 IBM 訴訟の概要

れ、 6 月には Corebank の権利を保有する FISを紹介しその判決内容の検討を行う。しか社が深く関与する体制に改善された新 BRD

し、事案および判決は、複雑かつ膨大で論点（実質は 2 回目の要件定義やり直し）が実施

も多岐にわたることから、本稿の問題対象たされた。このため、同年 4 月に開始した実装

る「プロジェクト・マネジメント義務」に係

工程（プログラミング）作業が中断した。

る部分を中心に紹介することとする。

平成18年12月ごろ、Y から、X に対して開発スコープの削減と開発費用の追加負担とし

1 ．事案の概要て約34億円の支払いが提案され、その後、Y

平成12年ごろ、スルガ銀行（原告、被控訴から、X の追加負担を20億円に減少させる案人。以下、X）は、基幹システムの刷新を図が提案された。これについては、XY 間で協るため、日本 IBM（被告、控訴人。以下、Y）

議を重ねてきたが合意できない状態が続いに新たな基幹システム構築の提案等の検討をた。さらに、Y は、平成19年 3 月に、平成22依頼したところ、Y は、同年 9 月ごろから提年 1 月までに 5 段階に分けて全面稼働させる案の検討を行った。

スケジュールを提案したが、これも X に拒平成16年 3 月ごろ、X は Y から米国 FIS 社

否される。

製の外銀向けパッケージソフトである

平成19年 4 月18日、Y から、基幹系パッケー「Corebank」 を 採 用 す る シ ス テ ム 開 発 プ ロ

ジソフトを Corebank から Temenos 社の TCB

ジェクトの提案を受けた。そこで、同年 9 月を採用する代替案が提案されるが、これも Xに、X は、複数のシステム開発業者から提案は拒否する。同年 5 月 9 日に至って、X は、されたシステムを比較検討した結果、X の基

Y に対して、本件プロジェクトをいったん白幹系オンラインシステムを Y が提供するバ紙に戻す旨の書面を交付し、同年 7 月18日にンキングシステムをもとに全面的に改良し、は、本件最終合意及び本件個別契約を Y の本件システムを構築すること、その初期費用

債務不履行（履行不能）により解除する旨のとして約95億円、保守費用として約 6 億2000

意思表示をした。

万円（年額）を支出することを決めた。同年

そして、X は、本件システム開発が中止に

9 月29日に本件基本合意書①と計画・要件定なったことにつき、Y に対して請負契約の債義＃1に係る IBM 支援サービス契約を、同年

務不履行または不法行為に基づく損害賠償等

12月29日に本件基本合意書②と IBM システを理由に、約116億円の賠償を求めた。これ

ムインテグレーション契約が締結され、計に対して Y は、反訴として、X に対して、本画・要件定義＃2が開始された。その後、平件未払個別契約の代金支払請求、および X

成17年 6 月に予定されていた最終合意書の締の協力義務違反に基づく損害賠償として約結は延期され、平成17年 9 月30日に最終合意

125億円を請求した。

書の締結がされた。サービスインは平成20年
1 月とされた。

原審は本件システム開発契約が頓挫したのは、Y のプロジェクト・マネジメント義務違ところが、平成17年12月に、Y が開発方法

反によるものであるとして、Y に対し約74億の「カスタマイズベース・アプローチ」から円の損害賠償を支払うよう命じた。そこで、「パッケージベース・アプローチ」への変更

Y が控訴。控訴審でも X の主張が認められた― 5 ―青森法政論叢16号（2015年）

が、損害賠償の認定額は、約41億円に減額さ

ジソフトの提案がなされた時点で、信頼関係れた。X および Y は、ともにこれを不服としは喪失した。

て、直ちに上告したが、平成27年 7 月 8 日、

これに加えて、さらに原審は、本件システ

最高裁は、X と Y の上告を棄却し、上告受理

ム開発について X には協力義務違反はない

申立てを不受理とする決定をした。

と判じている。
（2） 控訴審（東京高判平成25年 9 月26日

2 ．判決

（1） 原審（東京地判平成24年 3 月29日

（30）
金商判1428号16頁）

金（29）
法1952号111頁）

控訴審では、原判決が変更、請求は一部認
容され、Y に約41億円の損害賠償の支払いが原審は、以下のような理由で反訴請求をす命じられた。
本判決は、まず、本件システム開発判断枠べて棄却し、Y に対して約74億円の支払いを組を、Ⅰ：企画準備から本件基本合意①締結

命じた。
まず、原告の主張する被告の債務不履行責前の段階（企画・提案）、Ⅱ：本件基本合意

任ないし、不法行為責任については、次のよ①締結から本件基本合意②締結前の段階（計うに判示する。「（最終合意書によれば）…原

画・要件定義）、Ⅲ：本件基本合意②締結か告の支払金額の法的拘束力については、原告ら本件最終合意締結前の段階（計画・要件定と被告との間で本件プロジェクトの各局面に義）、Ⅳ：本件最終合意締結から本件システおける義務を定めた個別契約が締結されるこム開発終了の段階（計画・要件定義，実装）とを前提条件として生ずるものとされているの 4 つの段階に分けて、各フェーズにおけると解すべきで…、個別契約の大半が未締結でプロジェクト・マネジメント義務違反の検討あることが認められる。そうすると、上記支を行った。

払総額が法的拘束力を有するに至る程度に条Ⅰの段階におけるプロジェクト・マネジメ

件が充たされているとはいえないので、被告ント義務違反の有無については、ベンダにの債務不履行又は不法行為の成立をいう原告

は、自ら提案するシステムの機能や開発手法の上記主張は採用することができない。」

等、想定されたリスクについて、ユーザに説次に、原審は、本件では、ベンダには以下明する義務があるとされた。そして、このよに挙げるようなプロジェクト・マネジメント

うな義務は、「契約締結に向けた交渉過程に義務違反があり、そのためにシステム開発がおける信義則に基づく不法行為法上の義務と頓挫したといえるので、ベンダに不法行為にして位置づけられ、…ベンダとしてかかる義基づく損害賠償責任を認めた。すなわち、

務（この段階におけるプロジェクト・マネジ

1）基幹系パッケージソフトとして選定されメントに関する義務）を負うものといえる。」

た Corebank の検証・検討が不十分で、そのとした。しかし、この段階では、X は「本件上、Corebank のカスタマイズに必要な体制

システム開発の過程において一定の修正等がを整えていなかった。

あり得ることも当然想定されていたものとい

2）X に対して、こうした事情について特にうべき」なので、本件では「Ⅰの段階におい説明がなかった。

て，控訴人にプロジェクト・マネジメントに

3）サービスインの時期が延期された。

関する義務違反を認めることはできない」と

4）最終合意締結後の合意を尊重する姿勢をした。そして、「本件システム開発において、表明していたにもかかわらず、変更、延期が…控訴人は、前記各契約に基づき…本件シス繰り返された。さらに、別の基幹系パッケー

テム開発を担うベンダとして、被控訴人に対― 6 ―システム開発契約における開発業者のプロジェクト・マネジメント義務し、本件システム開発過程において、適宜得た費用の支出を強いられたものと認められ、られた情報を集約・分析して、ベンダとして

Y は、X に対し、「不法行為に基づきその費通常求められる専門的知見を用いてシステム

用相当額の損害賠償をする義務を負う」とさ構築を進め、ユーザである被控訴人に必要なれた。

説明を行い、その了解を得ながら、適宜必要

さらに、Y の主張した本件未払個別契約等とされる修正、調整等を行いつつ、本件シスに基づく未払代金については、「…同契約に

テム完成に向けた作業を行うこと（プロジェついて債務不履行（プロジェクト・マネジメ

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

ントに関する義務違反。個別契約についてもを負うものというべきである」と述べつつ、同様である。）があったものということがで

Ⅱ、Ⅲという最終合意締結以前の段階では Yきる。」として、本件未払金個別契約は「全にプロジェクト・マネジメント義務違反はな

部解除したとして控訴人の請求を拒むことがかったが、Ⅳ（最終合意締結後）の段階におできると解するのが相当である。」「ベンダのいては、このプロジェクト・マネジメント義プロジェクト・マネジメントは、システム開務違反があるとして不法行為責任を認めた。

発において、契約目的達成に不可欠の義務とすなわち、「前記義務の具体的な内容は、なるものであるから、同義務違反による解除

契約文言等から一義的に定まるものではなは妨げられないというべきである」とされた。

く、システム開発の遂行過程における状況に（3） 考察応じて変化しつつ定まるものといえる。」と

本件は原審、控訴審ともに「本件最終合意」

して、「控訴人は、…被控訴人に対して、ベに法的拘束力を認めなかったため、債務不履

ンダとしての知識・経験、本件システムに関

行責任は問題にならず、いずれも、ベンダたする状況の分析等に基づき、開発費用、開発

る Y の不法行為責任として処理された。つスコープ及び開発期間のいずれか、あるいはまり、ベンダのプロジェクト・マネジメント

その全部を抜本的に見直す必要があることに義務違反が不法行為に該当するとしてこれについて説明し適切な見直しを行わなければ、基づく損害賠償請求を認めたのである。

本件システム開発を進めることができないこ

原審は、Y の不法行為責任を認める前提とと、その結果、従来の投入費用更には今後のして、Y に対して、プロジェクト・マネジメ

費用が無駄になることがあることを具体的にント義務違反を認定した。つまり、原審は、説明し、ユーザである被控訴人の適切な判断

プロジェクト・マネジメント義務を、不法行を促す義務があったというべきである。ま為上の注意義務（信義則上の義務）であるこ

た、本件最終合意は，前記のような局面におとを明らかにしたのである。

いて締結されたものであるから、控訴人は、

控訴審も、プロジェクト・マネジメント義ベンダとして、この段階以降の本件システム

務違反による不法行為責任に基づく損害賠償開発の推進を図り、開発進行上の危機を回避を認めるという大枠は原審と変わらない。しするための適時適切な説明と提言をし、仮にかしながら、Y の損害賠償額は約74億円から回避し得ない場合には本件システム開発の中約41億円へ大幅に減額されている。これは、止をも提言する義務があったというべきであ

原審が、システム開発の企画設計の段階以降る。」に生じた費用すべてを損害として認定していこうして本件最終合意段階における不法行るのに対して、控訴審は、最終合意以降の費為が成立すると認められたことから、X は、用にのみ損害を限定し、損害の対象となる費Y の義務違反により、本来、必要としなかっ

用の起算時期を遅らせて損害額を縮減したこ― 7 ―青森法政論叢16号（2015年）

本的変更必要性への説明義務」、または「中とによる。
次に、プロジェクト・マネジメント義務違止等の提言すべき義務（中止提言義務）」が反の内容についても、原審と控訴審では異なあるとした。このように、プロジェクト・マ

る判断があった。原審は、基幹系パッケージ

ネジメント義務をプロジェクトの進捗段階にソフトである Corebank の邦銀業務への適合

応じて変化させ、具体化させていることは興性や Corebank を採用するとの判断が本件シ味深いとの見解もある（31）。

ステム開発に適切であったか、開発手法が妥

そして、控訴審には、プロジェクト・マネ

当であったか等について、Y が十分にこれをジメント義務の根拠や内容を考察する上で、検討しなかったことをプロジェクト・マネジ

次のような意義があると思われる。

メント義務違反と認定し、X の実損害のほぼ①

満額を賠償対象としていた。

ベンダのプロジェクト・マネジメント義
務は必ずしも、契約上の義務というだけでこれに対して、控訴審は、Ⅰの段階におけなく、信義則にもとづいて発生する義務でるプロジェクト・マネジメント義務についてもあり、その義務違反は不法行為責任を負は、これを「契約締結に向けた交渉過程におうことが明らかになった。

ける信義則に基づく不法行為上の義務」と認②

この信義則上のプロジェクト・マネジメ

定しつつ、ベンダの義務違反を認めなかっ

ント義務は、システム開発の企画提案段階た。このようなプロジェクト・マネジメント（契約締結前）でも存在するとされた。つ義務は、受発注前の段階では、契約目的に不まり、ベンダには企画提案段階でも、想定確実性がみられることから、ベンダの「事前されるリスク等について説明する義務があ

検証などの方法・程度はおのずと限られる」

ることが明らかにされたのである。しかので、「ユーザも業務分析とベンダの説明をし、ユーザ自身のリスク分析も求められ、踏まえてシステム開発に自らリスク分析する

この段階ではベンダの義務は軽減される。

ことが求められる」とし、ユーザに応分のリ③

システム開発の上流工程と下流工程では開発手法等の不確実性を反映して内容が一スク負担を認めた。
Ⅱ・Ⅲ・Ⅳの段階におけるプロジェクト・様ではない。したがって、システム開発でマネジメント義務については、「各基本合意

は、ベンダの果たすべきプロジェクト・マ

や個別契約に基づき、ベンダとして通常求め

ネジメント義務は各段階で変容していくもられる専門的知見を用いてシステム構築を進のと認められる。

め、ユーザに適宜説明を行いその了解を得な④

ベンダにはシステム開発が頓挫しうるこ

がら、修正、調整を行いつつ本件システム完とが明らかになった場合は、プロジェクト

成にむけて作業を行うことを適切に行う義の「抜本的見直し」や「中止」を提言すべ務」としながらも、その具体的内容は、シス
テム開発の遂行過程における状況に応じて変き義務があることが示された。
⑤

本判決は、代金未払個別契約に対する Y化するとした。その上で、Ⅳの段階においの代金支払請求を、Y のプロジェクト・マ

て、本件システムを開発することが不可能でネジメント義務違反による X の契約解除あることが明らかになっていたとして、開発を理由に排斥していることから、プロジェ

スケジュール等を抜本的に見直すか、それがクト・マネジメント義務をシステム開発契

困難ならば、開発そのものを断念するかを含約における付随的義務ではなく契約目的達

めて決定しなければいけない局面だったと認成に不可欠な義務であることを明らかにし定し、このような場合には、「システムの抜

た。

― 8 ―

システム開発契約における開発業者のプロジェクト・マネジメント義務を負担するものといえる」として、ベンダの
しかしながら、控訴審には以下のような問非を認めたものの、被告（ユーザ）もまた自題点がある。そもそも、本件システム開発のら積極的に本件システムへの切り替えにむけ

失敗の最大の原因は、当初のパッケージソフて原告に協力すべき信義則上の義務があった

トの選定ミスにあったのではないかと思われが、これを果たしてなく、スケジュール遅延る。原審が認定したように、パッケージソフの一因は被告にあるとして、契約解除は認め

トの選定は開発対象たるシステムの根幹をなず、原告（ベンダ）の代金支払請求を認めた。

すものである。「パッケージソフトの選定こ（ⅱ）広島地判平成11年10月27日（判時1699

そ、専門的知識および経験を持つベンダとし

号101頁）てのプロジェクト・マネジメントの腕の見せ所」といわれるほどユーザがベンダに対して、基幹業務システ（32）、本件事案では重大

ムソフトの製作請負もしくは製造販売契約にな義務違反がここにはあったと思われる。し基づいてソフトの欠陥により被った損害の賠

たがって、この部分に関して、責任を問えな償を請求した事例である。裁判所は、ベンダいという控訴審の判断には疑問である（33）。

は、「コンピュータソフトの製作に関し自らが有する高度の専門的知識経験に基づき、販Ⅳ

売管理、経営管理の迅速化や合理化を図るとプロジェクト・マネジメント義務

いう本件システムの目的の実現に努めるべき

1 ．プロジェクト・マネジメント義務とは責務を負」うので、専門技術的な視点から判

ここでは、まず、スルガ銀行・日本 IBM

断して必要と思われる事項の提案や指摘をす訴訟以前に、システム開発契約において、ベる義務があると述べて、ベンダの納品したシンダにシステム開発のプロジェクトを適宜管

ステムには、機能を欠く債務不履行部分が有理等する義務を認めた裁判例をいくつか紹介ると認定した。

するが、プロジェクト・マネジメント義務と（ⅲ ） 東 京 地 判 平 成14年 4 月22日（34）（判 タ

いう用語が、最初に裁判例に現れたのは、東1127号161頁）

京地判平成16年 3 月10日（裁判例ⅴ）であっベンダがシステムを納品したにも関わらた。

ず、ユーザがその代金の一部を支払わなかっ（1） 裁判例の紹介たことにつき残代金の支払いを請求した。こ（ⅰ）東京地判平成 9 年 9 月24日（判タ967

れに対してユーザは、ベンダによる不適切なシステム開発により損害を被ったとして損害号168頁）
システム開発を原告に依頼したユーザが稼賠償の反訴請求をした。裁判所は、「本件に働スケジュールの遅滞及び納品されたソフト

おいて、原告は、その提案書で、本件システの瑕疵を理由に債務不履行に基づいて契約をムの目的について、販売管理及び経営管理の解除したことに対して、ベンダが解除の有効迅速化並びに合理化を図ることを提示してい性と当該システム開発に係る代金支払いを請るのであるから、システム開発の専門家とし求した事例である。

て、自らが有する高度の専門的知識経験に基判決は、「原告（ベンダ）は、コンピューづき、処理の迅速化という目的の実現に務めタ関係の専門企業として、顧客（ユーザ）でるべき責務を負っており、被告の要望事項のある被告から提供された資料及び聴取等の結増加や被告のデータ運用方法の仕様が未確定

果に基づき、本件システムの導入目的に適合である等、処理の迅速化を阻害する要因を認したプログラムを作成すべき信義則上の義務

識した場合には、被告に対し、当該要因を指― 9 ―青森法政論叢16号（2015年）

摘し改善を求めるべき注意義務を負っていたユーザが納入期限までにシステムが完成しというべきである」から、「原告が、システなかったことを理由に債務不履行に基づいて

ム開発業者として求められていた当該注意義

契約解除を主張し支払い済みの委託料等の返務を果たしたと認めるに足りる証拠はなく、還を請求したのに対し、ベンダが、納入期限

本件各瑕疵は、かかる原告の開発作業が原因までに完成しなかったのはユーザが協力義務で発生した蓋然性が高いと認めるのが相当」に違反したことが原因であると主張し、反訴として、「原告によるシステム開発作業におとしてユーザの債務不履行に基づいて損害賠ける注意義務違反にあるものと認めるのが相償を請求した事例である。

当である。」とした。

裁判所は、「被告（ベンダ）は、注文者で（ⅳ）東京地八王子支部判平成15年11月 5 日（判時1857号73頁）

ある原告のシステム開発への関わりについても、適切に管理し、システム開発について専ユーザがベンダに対して納品されたシステ

門的知識を有しない原告によって開発作業をムに瑕疵が有ったと主張して請負契約の解除

阻害する行為がされることのないよう原告にに基づいて代金等の返還請求をするととも働きかける義務（以下、これをプロジェクに、十分なヒアリングをしなかったことが専

ト・マネジメント義務という）を負っていた門家としての善管注意義務違反に当たるとしというべきである」として、具体的には、開て債務不履行に基づく損害賠償を請求した事

発プロジェクトの推進に関してユーザが決定例である。裁判所は「被告（ベンダ）は、コ

すべき事項等につき「…ユーザがこれを決定

ンピュータ・ソフトウェアの開発、販売、コ

ないし解決できるよう導く義務を負い…」、ンサルティング等の専門企業であり、システ

開発プロジェクトに支障をきたすようなシスムを構築するについては、顧客である原告

テム機能追加や変更等の要求をユーザがして（ユーザ）から、その業務の内容等必要な事きた場合には「…ユーザに適宜その旨説明し項を聴取し、その結果に基づいて、原告のシて、要求の撤回や追加委託料の負担、納入期

ステム導入目的に適うシステムを構築すべき限の延期等を求めるべき義務」を、ベンダの義務」を負うとしたが、「…一方で、ユーザ

プロジェクト・マネジメント義務として示しにもシステム構築に必要な情報を正確に提供た上で、本件被告ベンダの「プロジェクト・すべき信義則上の義務を負う」として、本件マネジメントは、不適切であったと言わざるは、ユーザが正確な情報を提供していないとを得ない」とした。一方、原告ユーザの協力

して、ベンダの義務違反や瑕疵の存在を否定

義務違反もまた認定し、当該システム開発のした。

頓挫は双方の不完全履行が相まって生じたものであるとして、ベンダとユーザの過失割合

こうしたベンダの「自ら有する高度に専門的知識経験」を理由とした開発プロジェクト

6 対 4 と認定した。
（2） プロジェクト・マネジメント義務の具管理やユーザへの注意義務に関する判決の流体的内容れを受けて、このようなベンダの義務を「プシステム開発契約では、ベンダがプロジェ

ロジェクト・マネジメント義務」として定式

クト・マネジメント義務を負い、その義務違化・精緻化した判例（35）として、次の判決が反による責めを負うことに異論はない。ま

登場した。

た、プロジェクト・マネジメント義務は、裁（ⅴ ） 東 京 地 判 平 成16年 3 月10日 （判 タ（36）1211号129頁）

判例の蓄積により、発展し、質的・内容的にも拡大してきたといえる。スルガ銀行・日本― 10 ―

システム開発契約における開発業者のプロジェクト・マネジメント義務

IBM 訴訟控訴審は、さらに、プロジェクト・として自ら有する高度の専門的知識と経験」

マネジメント義務について、プロジェクト進に基づく責任があると述べるのみで、その法捗状況に伴う「変動性」を指摘した。そ的根拠は明らかではない（42）。確かに、シス

こで、これまでの裁判例を概観することによ

テム開発には、何よりもまずシステム開発に（37）

り、プロジェクト・マネジメント義務とは、関する有能な技術力（あるいは技術者の能さしあたり、以下のような内容としてまとめ力）が必要であり、かつ、ベンダは「開発プられよう。

ロジェクトを遂行するための標準化された開①開発プロジェクトの進捗状況管理義務

発手法および開発体制」も備えていなくては②開発プロジェクト阻害要因排除義務

ならないとされる。それは、システム開発③ユーザへのプロジェクト関与促進義務

は、手工業的要素が強く、「人」に依存する④ユーザへの説明義務

ため、有能なプロジェクト・マネジメント能⑤ユーザへの指導助言・提言義務力が必要だからである。裁判所が、「専門家

これらは、大別すると、ベンダ側のシステとして自ら有する高度の専門的知識と経験」

ム開発プロジェクト進行を適時適切に運営すという場合は、開発技術だけでなく、その開る義務（①②）と、ユーザ管理・支援義務（③発手法・体制やプロジェクト・マネジメント④⑤）に分けることも可能である能力を総称したものだといわれている（43）。

。

（38）

システム開発プロジェクト失敗の要因に

スルガ銀行・日本 IBM 事件控訴審でも、は、ユーザによる業務要件確定の遅れや無理

ベンダの専門家としての知識や経験等に基づな機能追加といった、ユーザの対応が原因といたプロジェクト・マネジメント義務論が展なる場合も多い。しかし、システム開発プロ

開されているが、当該システム開発契約の拘ジェクトにおいて、ユーザがシステムに関す束性を否定したため、債務不履行責任としてる様々な要望をするのは当然であり、それの判断はされず、ベンダに、プロジェクト・に、委託料や追加の納入期限が必要かどうか

マネジメント義務違反による不法行為に基づは、専門的知識のないユーザが的確に判断す

く損害賠償責任を認めただけであった。これるのは困難である。判決はこうした理由かは、当該プロジェクト・マネジメント義務ら、ベンダに③④⑤のような対応を求め、を、信義則上の一般的注意義務と位置付けた「ユーザを支援する義務」がプロジェクト・と考えられるが、そのような義務の発生根拠

マネジメント義務の一内容として盛り込まれもまた法的には不明瞭である。

ているのだろうと考える

一方で、同控訴審は、プロジェクト・マネ

。

（39）

2 ．プロジェクト・マネジメント義務および義務違反の根拠

ジメント義務をシステム開発において契約目
的達成に不可欠の義務であるとして、同義務違反による契約解除を認め、最終合意締結後

以上のように、プロジェクト・マネジメンに締結された未払個別契約の解除も認めた。

ト義務の具体的内容は、裁判例ではそれぞれ

すなわち、プロジェクト・マネジメント義務の事案に応じて、さまざまなものが見受けら違反による契約解除を認めることで、プロれた。しかし、プロジェクト・マネジメント義務

ジェクト・マネジメント義務を、契約上の付の法的根拠について、判決文中で明らかにして随義務ではなく、いわゆる「給付義務（債権いるのは、請負契約上の義務であると判示し者に対して為すべく義務づけられている行為

た、上記裁判例（ⅳ）のみであった（44）を為すべき義務）」と解釈されたと考え

。

（40），
（41）

その他の判決の多くは、ベンダに「専門家る。これには、プロジェクト・マネジメント― 11 ―

青森法政論叢16号（2015年）

義務違反という 1 つの解除原因により個別の理解し、プロジェクト・マネジメント義務違契約の解除を認めることになり、多段階契約

反はベンダの仕事完成義務違反としてその責であっても、複数の契約解除を認める判決と任を問うのが妥当ではないかと考える。つまいう見方ができるという見解もあり（45）、こり、プロジェクト・マネジメント義務を「仕のように考えるならば、多段階契約方式を採事の完成」に向けて行う作為義務として、請用するベンダのメリットが失われる可能性も負人の「仕事完成義務」に包摂されるものとあるだろう。

捉え、その不履行により仕事完成という契約

そこで、プロジェクト・マネジメント義務の法的根拠について、システム開発契約の法目的を達成できなくなるような債務と捉えるのである。
ある契約において、何が要素たる債務か、的性質から考察を試みる。
システム開発契約を準委任契約ないし準委付随的債務なのかの区別は相対的なものであ

任契約要素を持つ非典型契約と考えるならり、一般的・抽象的に定められるものではな

ば、プロジェクト・マネジメント義務は、まく、契約ごとに判断されるべきであるといわれさに委任契約上の善管注意義務の一内容といている（48）。そして、そのような判断は、社会うことになる。

通念に照らし、契約締結の際の事情をすべて

一方、システム開発契約を請負契約ないし考慮して客観的に決定した当事者の合理的意

請負契約要素を持つ非典型契約と考えれば、

思を基準にして行われるべきであるとされプロジェクト・マネジメント義務は、請負契る。その上で、契約の目的がどこにあったの約上の義務ということが出来る。請負契約のかを明らかにし、その目的の達成に必要不可

基本的義務は「仕事完成義務」である。そこ

欠なものでなければ付随的債務であるし、目で、プロジェクト・マネジメント義務を、仕的達成に不可欠であって、それが履行されな事完成義務の付随的義務であると捉えるならければ契約の目的が達成されず、当事者は契ば、プロジェクト・マネジメント義務違反

約を締結しなかったろうと判断される場合には、仕事完成義務における付随的義務違反とは契約の要素をなす債務であるという（49）。

いうことになるだろう（46）。しかしながら、システム開発契約におけるプロジェクト・

付随的義務は、債権者から履行の請求ができ

マネジメント義務についても、このような観ず、付随的義務違反に対する損害賠償請求が点から検討すると、システム開発契約の目的出来るだけであり（47）、したがって、債権者

は、終局的にはシステムの完成であるが、スが付随的義務違反を理由に契約を解除するこルガ銀行・日本 IBM 訴訟控訴審でも言及さとも出来ないと考える。だが、ユーザがベンれたように、これを達成するためには、適切

ダにプロジェクト・マネジメント義務の履行なプロジェクト・マネジメントが不可欠といを請求できないこと、また、ベンダの不適切える。プロジェクト・マネジメント義務違反

なプロジェクト・マネジメントのために、シは、必然的にシステム開発の失敗、つまり、ステム開発が中止に追い込まれた場合に、仕事の未完成を導くからである。

ユーザがプロジェクト・マネジメント義務違

確かに、「仕事の完成」そのものが債務で反を理由にシステム開発契約を解除できないあり、その履行過程について問われない請負契約にあって、「仕事の完成」に向けての具ということには疑問がある。
したがって、プロジェクト・マネジメント

体的作為義務を要素たる債務として認めるこ

義務は、請負契約の「要素たる債務（契約目とはできないとの批判もあるだろう。しか的を達成するために必要不可欠な債務）」とし、「仕事の完成」の過程を問わないことが― 12 ―

システム開発契約における開発業者のプロジェクト・マネジメント義務「仕事の完成」への具体的作為義務がないとは、いわゆる「契約準備段階の説明義務」でいう帰結にはならない。むしろ、「仕事の完あり、「契約締結上の過失」法理の下、契約成」に向けての具体的作為の積み重ねにより準備段階に認められた信義則に基づく不法行「仕事の完成」という結果に至るからである。

為法上の説明義務と構成しても問題はなかっ

したがって、プロジェクト・マネジメント義たと思われる（51）。

務は、請負契約としてのシステム開発契約に

次に、システム開発プロジェクトに対するおける要素たる債務、すなわち請負人の仕事「中止提言義務」もまた、あえてプロジェク

完成義務の一内容と考えられる。

ト・マネジメント義務と位置づける必要はな
いと考える。前述したように、プロジェク

3 ．契約準備段階の義務と中止提言義務

ト・マネジメント義務とは、システム開発に

スルガ銀行・日本 IBM 訴訟控訴審では、

際して、システム開発の進捗状況を管理し、開発プロジェクト進捗管理義務やユーザ管開発の進行を阻害する要因を適時に発見また理・支援義務といった従来の裁判例や原審では排除し、ユーザに適時適切な説明や指導・言及されていたプロジェクト・マネジメント

提言を行うというベンダの義務である。これ

義務に加えて、「企画・提案段階における説らは、まさに、ベンダが「システムの完成」

明義務」と「開発進行上の危機を回避し得なという「仕事の完成」に向けて努力する義務い場合のプロジェクト中止提言義務」を、プである。しかしながら、システム開発中止提ロジェクト・マネジメント義務の一内容とし言義務は、「システムの完成」に向けられたて、ベンダに履行を求めている。とりわけ、

義務とはいえない。

ユーザの個別の要望の撤回にとどまらず、シ「中止提言義務」は、むしろ、ユーザの利ステム開発プロジェクトの全体的中止を提言

益保護に向けられた義務である。つまり、契することも、プロジェクト・マネジメントの

約相手方の完全性利益保護を目的とする保護一環と捉えられた点は注目に値する。

義務と考えられる。そして、このような保護

これは、従来のプロジェクト・マネジメン

義務は、意思に基づかない債務として、主たト義務と比べると、非常に広範な義務をベンる債務とは独立して存在する信義則上の債務

ダに課すことになる内容であるといえよう。

として観念される（52）。したがって、「中止提もっとも、控訴審は「企画提案段階の説明義

言義務」は、請負契約上のプロジェクト・マ

務」については、事実認定の上、ベンダに義ネジメント義務の一内容と理解するのではな

務違反を認めなかった。しかし、「中止提言

く、ユーザの利益保護に向けられた保護義務義務」については、このような義務を怠ったと理解するのが妥当であると考える（53）。

ためにユーザの損害を拡大させたとして、ベンダに損害賠償責任が認められた。しかし、

Ⅴ

おわりに

プロジェクト・マネジメント義務を、請負契

以上、システム開発契約におけるベンダの約の「仕事完成義務」そのものと捉える私見

プロジェクト・マネジメント義務について、

からは、これらの義務をプロジェクト・マネ

スルガ銀行・日本 IBM 訴訟、ならびに最近

ジメント義務の 1 つとみなすことには、疑問の裁判例の動向を踏まえて、その義務内容とがある。

義務の発生根拠について検討してきた。プロ

まず、「企画提案段階の説明義務」についジェクト・マネジメント義務は裁判例の蓄積ては、あえてプロジェクト・マネジメント義によりその内容が具体化されてきたものだ

務とする必要はなかったと考えるが、スルガ銀行・日本 IBM 訴訟控訴審に至っ

。これ

（50）

― 13 ―

青森法政論叢16号（2015年）て、システム開発にかかわったベンダのユー

注⑴

ザに対するあらゆる義務が、プロジェクト・

高田寛「システム開発における請負人のプロ
ジェクト・マネジメント義務および損害賠償をめ

マネジメント義務の名の下に説明されること

ぐる争い」NBL990号（2012年）115頁。

には疑問が生じた。

⑵

そこで、本稿では、プロジェクト・マネジ

情報システム・ソフトウェア取引高度化コン
ソーシアム編「情報システム・ソフトウェア取引

メント義務の内容や発生根拠について、次のトラブル事例集」（2010年）10頁（http://www.meti.

ような結論を得た。第一に、システム開発契

go.jp/policy/it_policy/softseibi/trouble%20cases.

約を請負契約そのものと考える本稿では、プ

pdf#search

ロジェクト・マネジメント義務は、請負契約⑶

最終アクセス2015年 6 月22日）。

伊藤雅浩「システム契約でもめないために」会
社法務 A2Z2014年 8 号（2014年）21頁。

の要素たる債務であり、仕事完成義務に包摂⑷

された具体的作為義務ということが出来る。

その他、スパイラル型、プロトタイピング型、
アジャイル型という手法がある。スパイラル型、第二に、このようにプロジェクト・マネジメ

プロトタイピング型については、JISA 法的問題委員

ント義務を請負契約の要素たる債務の 1 つと会契約部会編「新しいソフトウェア開発委託取引のして仕事完成義務に包摂して考えるならば、契約と実務」（商事法務2003年）参照。アジャイ

システム開発の企画提案段階における説明義ル型については最近多くの論稿があるが、さしあ

務や、開発プロジェクト中止提言義務は、プたり梅本大祐「アジャイル開発の特性と契約ポイ

ロジェクト・マネジメント義務の一内容とはント」Business Law Journal 2013年 7 号（2013年）

いえない。これらの義務は、確かに、ベンダが負うべきユーザの利益保護義務ではあるが、プロジェクト・マネジメント義務とは法的発生根拠を異にする、別種の義務といえる。

40頁以下参照。
⑸

経 BP 社⑹

2013年）20頁。

上山・前掲 526頁によれば、多段階契約方式の広まったきっかけの1つは当時の通商産業大臣

本稿では、システム開発契約の法的性質かの諮問機関である産業構造審議会情報産業部会がらベンダのプロジェクト・マネジメント義務

1992年12月に公表した「緊急提言ソフトウェア新を検討したが、残された課題として、システ
ム開発プロジェクトに向けられたユーザの協

上山浩「トンでも『IT 契約』に騙されるな」（日時代」という答申であるといわれている。
⑺ 「モデル取引・契約書」について詳細に検討を加えたものとして以下の文献がある。吉田祈代

力義務との関係がある。ベンダのプロジェク「システム開発契約における典型契約の意義と債

ト・マネジメント義務とユーザの協力義務は

務内容の事後的判断基準─情報システム・モデル

表裏一体の関係にあり、システム開発におい取引・契約書における役割分担を題材に─」法学て、ユーザの協力義務もまた欠かせないもの

新報114巻11・12号（2008年）751頁以下。吉田にである。これに関しては、今後、別稿にて検よれば、「モデル契約書」に示される請負契約、討の予定である。

準委任契約という典型契約類型の設定は、当事者システム開発の失敗をめぐる紛争はあとをの「あるべき役割分担」を示すことで、紛争予防絶たない（54）。判例理論のさらなる集積と学的観点からは重要な意義を有するが、紛争発生後の事後的判断基準としては十分機能しないとのこ

説上の議論の高まりによって、今後、システとである。

ム開発契約やプロジェクト・マネジメント義⑻

務論の一層の進展が期待される。

吉田・前掲 7761頁によれば、「モデル契約書」のフェーズごとに請負契約とするか準委任契約とするかの設定もこのような思考を前提としているようである。
⑼

松島淳也「大規模システム開発の契約交渉とプ
ロジェクト運営のポイント～紛争リスクを最小化― 14 ―

システム開発契約における開発業者のプロジェクト・マネジメント義務するために～」Business Law Journal 2011年12月

場合」とは、必ずしも成果物がはっきりしないよ号（2011年）25頁。

うな場合、ユーザとベンダの共同事業性が強い場⑽

松島・前掲 9⑾26頁。

合、実験的なソフトやシステムを開発するような

河上正二「判批（スルガ銀行・日本 IBM 事件控訴審）」金融法務事情2001号（2014年）74頁。

⑿

場合とされる。
㉑

生田利康「注文者の協力義務─コンピュータソ

桶田大介「情報システム開発契約の多段階契約

フト開発をめぐる最近の判例を中心に─」福岡大に関する新しいアプローチの必要性─スルガ銀

学法学論叢52巻 4 号（2008年）396頁。

行・日本 IBM 事件─」NBL977号（2012年）4 頁。

㉒

生田・前掲20

例えば、東京地判平成 3 年 2 月22日（判タ770㉓

平野裕之「民法総合5契約法」信山社（2007年）⒀

号218頁）では、プログラム開発委託契約が請負
契約か準委任契約かで争われたが、請負契約と認

144頁。

552頁。
㉔

例えば、小林秀之「金融システム開発契約に係定され受託者の報酬支払請求は認められなかっる法的諸論点の帰趨―東京地判平成24.3.29を契機た。また、東京地判平成22年 9 月21日（判タ1349

として─」金融法務事情1952号（2012年）57頁で号136頁）は、コンピュータシステムに関するコ

は、システム開発契約は、システム開発という共ンサルティング契約及びシステム開発契約につい通の目的に向けて協働するといった共同開発契約て、当該契約書に準委任契約と書かれているとしになるケースが多くなると指摘し、請負契約とはてもシステム構築に係る部分は請負契約の要素を明らかに様相が異なると指摘している。

含むと判示された。
⒁

内布光「ソフトウェア開発委託契約紛争事例の㉕

平野・前掲23㉖

注文者の協力義務についての論考として、笠井研究（1）」現代法学10号（2006年）168頁。
⒂

修「注文者の協力義務」好美清光古稀『現代契約内布光「ソフトウェア開発委託契約紛争事例の法の展開』（経済法令研究会

研究（2）」現代法学11号（2006年）95頁。
⒃㉗

原審）」私法判例リマークス47号（2013年）21頁。

三村量一ほか「情報システムの開発・運用と法
務～判例の蓄積状況と紛争処理実務の変化～」

芦野訓和「ソフトウェア開発委託契約」椿寿夫・伊藤進編「非典型契約の総合的検討」（商事法務⒅

2000年）269頁、生田・前掲21が参考になる。

滝沢孝臣「判批（スルガ銀行・日本 IBM 事件

⒄

598頁。

NBL1050号（2015年） 9 頁（三村量一発言）。
㉘

2013年）171頁。

三村量一ほか「情報システムの開発・運用と法
務～判例の蓄積状況と紛争処理実務の変化～」

小柴昌也「情報システム・ソフトウェア開発委

NBL1050号（2015年）8頁（上山浩発言）。上村弁

託契約の特殊性と紛争」帝塚山法学23号（2012年）

護士は、さらに、「仕事の完成に相当する内容が11頁。また、13頁以下では中国契約法における「技契約書に規定されているので、…実質的には請負

術開発合同（330条～ 341条）」の規定が紹介され契約の性質を有することになる」としつつも、
「あ

ている。

まり契約類型に拘泥することは実益がないという⒆

東京地方裁判所プラクティス委員会第二小委員
会「ソフトウェア関係訴訟の手引」判例タイムズ

ことは指摘をしておきたい」とも発言する。
㉙

原審に関する判例研究としては、吉田正夫「ス1349号（2011年）7 頁では、ソフトウェア開発は、

ルガ銀行対日本 IBM 事件東京地裁判決のポイン①ソフトウェアの無体物、②契約締結段階での成ト 解 説 」Business Law Journal 2012年 8 号（2012

果物の不確定性、③請負人と注文者の共同作業的年）67頁、松島淳也「スルガ銀行・日本 IBM 裁

性質、④システム納品後のバグ対応の必然性、⑤判が今後のシステム開発プロジェクトに及ぼす影システム納品後の注文者への運用指導問題、と響（上）・（下）」ビジネス法務2012年 8 月号（2012

いった実体法的に未解決の問題があるため、民法年）82頁、2012年 9 月号（2012年）82頁、桶田・
前 掲12

よいのか、問題が有ると指摘する。

「金融機関システム開発と法的問題─スルガ銀行⒇の請負に関する規定をそのまま適用して処理して4 頁、 小 林・ 前 掲2452頁、 小 林 秀 之

生田敏康「請負人の債務（2）─プロジェクト・対日本 IBM 事件を契機として─」銀行法務21

マネジメント義務をてがかりに─」福岡大学法学745号（2012年） 8 頁、一木孝之「判批」新判例

論叢59巻 1 号（2014年）143頁によれば、「特殊な解説 Watch12号（2013年）87頁、滝沢・前掲16― 15 ―

青森法政論叢16号（2015年）

18頁。
㉚

おり、ユーザはこれを信頼して対価を支払うのだ

控訴審の判例研究としては、桶田大介「システから、こうした『リスク』をも含めて報酬を得てム開発における法的責任の新たな枠組み─スルガいるということから、浮動性を有するプロジェク

銀 行・ 日 本 IBM 事 件 高 裁 判 決 ─ 」NBL1013号

ト・マネジメント義務を正当化できる」という見（2013年） 4 頁、仮屋篤子「判批」新・判例解説
Watch14号（2014年）91頁、吉田正夫「スルガ銀解を述べる。
㊳

同様に、プロジェクト・マネジメント義務を大行 対 日 本 IBM 事 件 東 京 高 裁 の 分 析 」Business

別して紹介したものに、松島淳也「システム開発

Law Journal 2014年 1 号（2014年 ）16頁、 同「ス訴訟における攻防」Business Law Journal 2013年

ルガ銀行 VS 日本 IBM 事件」東京高裁判決の意義」

7 号（2013年）37頁。ここで松島弁護士は、「進金融財政事情2013年12月16日号（2013年）30頁、

捗管理・阻害要因排除義務」と「発注者管理義務」

河上・前掲1171頁、生田敏康「システム開発のとの分類方法を示している。

頓挫と開発業者の責任─スルガ銀行・日本 IBM㊴

事件第一審および控訴審判決をめぐって─」福岡

ベンダにこうした重い責任を課すのは酷であると考えることもできよう。しかし、生田・前掲35

大学法学論叢59巻3号（2014年） 1 頁。
㉛

河上・前掲11㉜

484頁によれば、ベンダを請負人と理解した上73頁。

で、彼が専門的知識・経験を有していること、報高田寛「システム開発業者のプロジェクト・マ

酬の対価としての仕事完成義務の内容には請負業

ネジメント義務」富山経済論集60巻 1 号（2014年）

務を遂行するために必要な顧客への適切な助言・65頁。

指導も当然に含まれていると解することもでき㉝

同様の指摘をするものとして、高田・前掲32

る。

65頁は、ベンダに選定したパッケージソフトに熟㊵

プロジェクト・マネジメント義務を「（ユーザ知した者がおらず、パッケージソフトの海外権利の）システム導入目的にかなうシステムを構築す

者に全面的に頼っていたベンダの対応も本件シスべき義務を本件請負契約に基づき負うものと解さ

テム開発の失敗の要因に挙げている。
㉞

れる」という。

本判決には次の評釈がある。芦野訓和「判批」㊶

私法判例リマークス29号（2004年）30頁。
㉟

これについて、裁判例（ⅳ）が、プロジェクト・
マネジメント義務を請負契約上の付随義務として

生田敏康「電算システム開発契約における注文捉えたと評価するものとして、上山浩・小川尚史

者の協力義務と請負人のプロジェクト・マネジメ「プロジェクト・マネジメント義務に関する問題

ント義務─東京地判平成16年 3 月10日判例タイム
ズ1211号129頁 ─ 」 福 岡 大 学 法 学 論 叢52巻 4 号

点」ビジネス法務2013年 1 月号（2013年）100頁㊷（2008年）483頁。
㊱

471

文者のなした指図が不適当なものであるときは、頁。その他、上山浩「判例から学ぶ『外部委託契請負人において注意を与える義務があると述べて約』」日経コンピュータ2007年10月15日号（2007

いることは、本稿のプロジェクト・マネジメント年）54頁。

義務を考察するに当たり重要である。我妻栄「債㊲

本判決の判例評釈として、生田・前掲35

この点、すでに我妻博士は、請負人がその仕事について専門的知識をもつことを理由として、注

高田・前掲3257頁。また、河上・前掲11

73

権各論中巻二」（岩波書店

1962年）615頁。

頁は、判決が全体としてベンダにプロジェクト・㊸

高田・前掲 1

マネジメント義務を想定しつつ、その内容をプロ㊹

奥田昌道「債権総論（増補版）」（悠々社

ジェクトの進捗段階に応じて変化させていること

1992年）16頁。

を興味深いと述べる。

㊺

一方で、このような事前に義務の具体的内容が北岡弘章「多段階契約・個別条項に与える影響」Business Law Journal 2014年 1 号（2014年）

定まることのない（動態的・浮動的義務）ことに対する当事者への不意打ちリスクをどのように克

116頁。

47頁。
㊻

上 山 ＝ 小 川・ 前 掲41104頁 は、 プ ロ ジ ェ ク

服すべきであるかという問題については、生田・ト・マネジメント義務を「システムを完成させる

前掲20

141頁が、「ベンダは高度な専門的知識・という中心的義務を達成するために必要な付随義経験に基づく開発・遂行能力でもって対価を得て務」として信義則に基づいて発生するという。ま― 16 ―

システム開発契約における開発業者のプロジェクト・マネジメント義務

た、生田・前掲20

146頁も「請負人の主たる義務である仕事完成義務に付随する義務」と考える。
㊼

中田裕康「債権総論第三版」（岩波書店

2013年）113頁。
㊽

本田純一「契約規範の成立と範囲」（一粒社

1999年）216頁。
㊾

浜田稔「付随的債務の不履行と解除」『契約法大系Ⅰ』（有斐閣1962年）316頁。
㊿

同様の指摘をするものとして、高田・前掲3260頁。



このような契約準備段階の説明義務の存在を認めたものとして、最判平成23年 4 月22日民集65巻
3 号1405頁。



本田・前掲48



原田肇「システム開発におけるベンダのプロ

214頁。

ジェクト・マネジメント義務」国際商事法務42巻
7 号（2014年）1105頁は、中止提言義務に関して、契約当事者の損害軽減義務の観点からプロジェク
ト中止の要否や影響を説明する義務があることは容易に理解できると述べている。


例えば、本稿執筆時点では、システム開発中途挫折事例として、野村ホールディングス・野村証
券と日本 IBM との紛争（日経コンピュータ2014

年11月27日号56頁）や、テルモ（医療機器大手）とアクセンチュアとの紛争（日経コンピュータ
2014年12月25日号50頁）が、共に東京地裁に係争中である。

― 17 ―