143システム開発契約におけるプロジェクト・マネジメント義務
─専門家の視点からの一考察─帷
１

はじめにコンピュータ・ソフトウェアや情報処理システム

子翔太

ネジメント義務違反を理由に，債務不履行または不法行為責任を追及する場合（契約上の義務または不法行為上の注意義務として主張する。
）。の開発契約（以下「システム開発契約」という。）②

を巡り，システム開発の依頼を受けた開発業者（以システム開発の報酬の一部（出来高）を反訴で請求下「ベンダ」という。）とシステム開発の依頼者する，またはシステム開発が頓挫した原因はユーザ（以下「ユーザ」という。）との間で紛争が生じるこが同開発に協力しなかったことにあり，このようなとが多々ある。

協力義務の違反を理由として損害賠償を請求する場

システム開発契約は，ユーザとベンダの共同作業

上記①のようなユーザの請求に対し，ベンダが合（契約上の義務または不法行為上の注意義務としであって，双方が信頼関係をもって協力し合わなけて主張する。
）。

れば成功はおぼつかないと言われている。このよう③な当事者の協力というものは，法的な義務とされ，部（出来高）を請求したところ，ユーザが上記①記ベンダのプロジェクト・マネジメント義務（以下載の請求を反訴として請求する場合。

ベンダがユーザに対しシステム開発の報酬の一「プロジェクト・マネジメント義務」という。）及び上記のような紛争における重要な問題点は，シスユーザの協力義務（以下「協力義務」という。）とテム開発が頓挫してしまった責任をベンダまたはして各種裁判例（後掲東京高判平成25年 ９ 月26日金

ユーザのいずれが負担するべきなのかという点にあ判1428号16頁等 ）においても認められている。こると考えられる。すなわち，ベンダ側は，ユーザがのような当事者の義務違反が問題となるような紛争協力義務に違反してシステム開発に必要な協力をしの類型は，以下のように，システム開発が途中で頓なかったため頓挫したと主張する一方，ユーザ側挫してしまった場合に見受けられる。

は，ベンダがプロジェクト・マネジメント義務に違①

システム開発が途中で頓挫し，システムの構築反したためにシステム開発が頓挫したと主張するたに至らなかったため，ユーザがベンダに対し，シスめ，契約当事者のいずれがシステム開発が頓挫した

テム開発の過程におけるベンダのプロジェクト・マ場合の責任を負担すべきであるのかという点が重要

（1）

（1）

その他の裁判例として，東京地判平成 ９ 年 ９ 月24日判タ967号168頁，広島地判平成11年10月27日判時1699号101頁，東京地判平成14年 ４ 月22日判タ1127号161頁，東京地八王子支判平成15年11月 ５ 日判時1857号73頁，
東京地判平成16年 ３ 月10日判タ1211号129頁，東京高判平成26年 １ 月15日公刊物未登載（平成25年（ネ）第3952号／平成25年（ネ）第5742号），東京地判平成28年 ４ 月28日判時2313号29頁，札幌高判平成29年 ８ 月31日
判例時報2362号24頁等がある。

144

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

な問題点になると考えられるのである。

2019. 1

されていない場合に，同責任分担を規律するためにこのようなシステム開発契約においてシステム開重要になると考えられるシステム開発契約の当事者発が頓挫した場合の責任分担を考えるにあたっての義務のうち，ベンダのプロジェクト・マネジメン

は，当事者間の契約において，システム開発が頓挫

ト義務に関して，裁判例等を参考に，ベンダがシスした場合の責任分担に関する何らかの合意（プロテムの開発について専門的知見や経験を備えた専門ジェクト・マネジメント義務及び協力義務に関する業者であるという専門性に着目した考察をすること合意を含む。
）がなされていれば同合意の解釈・適ができないかどうかについて，検討を試みたい。

用によって規律されることになると考えられるが，当事者間においては明確に合意がなされていない場合も少なくない。

２

システム開発契約の概要等⑴

システム開発契約におけるプロジェクトの進め方

当事者間において上記のような合意がなされていシステム開発の手法は様々であり，一概にはいえない場合において，システム開発が頓挫した場合の

（2）

（3）

責任分担を規律する上では，ベンダが通常履践すべないが，基本系を示すと以下のような形となる。

きであると考えられるプロジェクト・マネジメント①

義務またはユーザが通常履践すべきである協力義務

ステムの再構築計画

を念頭において，同義務を尽くしていたと評価でき②ベンダへの開発依頼るのかどうかという観点からの判断が必要になって③

ベンダによるユーザからの要求聴取，システムくるものと考えられる。同観点からの判断にあたっ化に必要な要件の分析ては，プロジェクト・マネジメント義務及びユーザ④

ユーザによる業務のシステム化計画又は既存シシステムの仕様の確定（要件定義を含む）＊の協力義務を一定程度具体化，類型化し，その水準

要件定義：システム化計画を受けて，業務上を一定程度明確にする必要があるものと考えられ，の要求を業務要件に，システムに実装すべきシステ

そのためには，プロジェクト・マネジメント義務及ムの機能要件・非機能要件を定義する段階

び協力義務の根拠，内容及び両者の関係等が重要に⑤

基本設計を行い，開発の製造工程に入るなると考えられる。また，プロジェクト・マネジメ

⑥

テスト工程

（4）

ント義務及び協力義務を一定程度具体化・類型化することができれば，システム開発契約の内容の合理化も図ることができるのではないかと考えている。
本稿は，未定稿での研究ノートとして作成したものであるが，以下では，システム開発契約の概要等について確認した上で，当事者間において，システム開発が頓挫した場合の責任分担に関する合意がな（2）

司法研修所編『民事訴訟における事実認定─契約分野別研究（製作及び開発に関する研究）─』（法曹会，2014）92頁，東京地方裁判所プラクティス委員会第二小委員会「ソフトウェア開発関係訴訟の手引」判タ1349号 ４ 頁（2011）参照（3） ㈳情報サービス産業協会法的問題委員会契約部会『新しいソフトウェア開発委託取引の契約と実務』（商事法務，2002）32頁以下参照（4） 経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む），保守運用）〈第一版〉」33
頁（2006）（http://www.meti.go.jp/policy/it_policy/softseibi/index.html#05）

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

145

（5）

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

基本契約

個別契約
要件定義

⑶

基本設計

開発

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

（7）

①
⑵

契約形態（多段階契約方式と一括契約方式）

ア

一括契約方式

専門的知見の必要性

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

システム開発の全プロセスを一括して契約する方②（9）仕様の不確実性，システムの不可視性完成すべきシステムの仕様が当初から定まっておら式のことをいう。

ず，抽象度が高く，概括的であって，可視性も低い。
要件定義

基本設計

開発

システム
テスト

③

ユーザとベンダの協力関係の必要性
ユーザの業務内容ニーズとベンダの専門知識や技イ

多段階契約方式

能とを照らし合わせる等の協力関係が必要で（シス

開発工程を分けて，それぞれの工程を取引単位とテムの内容は千差万別でありオーダーメイド的性格した個別契約を設定し，それら全体に共通する事項を有するものであるから，ユーザからデータその他等を定めた基本契約を締結した上で，最初の個別契の提供，ユーザとベンダの間の円滑な意思疎通な約を契約し，当該工程が終了するとその後順次後続

ど， 緊 密 な 協 力 関 係 が な け れ ば 構 築 は 困 難 に なの個別契約を締結して開発を進行する方式。多段），両者の協力関係を前提に，変更及び調整をる。

階契約方式は，開発規模の大きい場合に用いられる重ねながら，システムの仕様を具体化していくことことが多く，工程ごとに委任契約または請負契約がが要求される。

（6）

使い分けられる。

（10）

このように，システム開発契約においては，専門的知見を要し，システムの仕様がもともと抽象的・概括的であり，ユーザとベンダが協力して内容を段

（5）
（6）

経済産業省・前掲注（４）31頁㈳電子情報技術産業協会ソリューションサービス事業委員会『ソフトウェア開発モデル契約書の解説』（商事法務，2008）37頁は，基本契約では全体的事項や共通事項等を約定し，個別契約では各工程における契約金額，納期等を約定するとする。
（7） 田中俊次ほか「ソフトウェア開発関連訴訟の審理」判タ1340号 ５ 頁（2011）（8） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（１）７ 頁は，「ベンダーはＩＴの専門家であるが，ユーザーの業務について必ずしも十分に理解しているとは限ら」ないとし，「二重の意味での専門性が内在している」と指摘する。
（9） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（１）７ 頁参照（10） 生田敏康「システム開発の頓挫と開発業者の責任─スルガ銀行・日本ＩＢＭ事件第 １ 審および控訴審判決をめぐって─」福岡59巻 ３ 号539頁（2014）

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

146

（11）

2019. 1

階的に定めていくという点に特色がある。また，

種の非典型契約であり，その取引形態は，請負型，ユーザとベンダとの間で形成されたシステムに関す委任型，派遣型の ３ つに分けられるが，その取引契る合意は，個々の項目ごとではなくシステム全体と約の目的・内容に応じて契約類型に当てはめられるの関係で有機的一体としての合意が形成されているとし，実際の取引では請負型で取引されることがと評されている。

多いが，目的物であるソフトウェアの性質上，完成⑷

システム開発契約の実体的法律関係すべき仕事の内容にユーザとベンダとの間で認識のア

裁判実務ずれが生じやすい等の問題があり民法の請負契約と（12）システム開発契約は，民法制定当時予想されてい（16）（17）同様に扱うことは無理があるという。

なかった契約類型であるが，実務的には，請負契②約，準委任契約または労働者派遣契約のいずれかでである点，契約の目的となるのは知的給付であり物処理されているとされる。

ではないという点，注文者が通常の請負契約以上にイ

仕事完成に向けて協力義務を負う点及びどの段階を

（13）

学説
学説においては，以下のような見解が示されてい基本契約と複数の個別契約が一体になった契約もって仕事の完成をしたと考えるべきか不明である
（18）

る。

点から，非典型契約であるとする見解

ア

請負契約とする見解③①

ソフトウェアは完成しなければ無意味であるとを提案する見解

契約の特殊性を考慮した法整備・法政策の導入（19）

して，特殊な場合を除き，システム開発契約は請負

ウ契約であるとする見解

であるとする見解（14）②

請負契約の仕事完成は有形的な場合に限られず無形的な仕事を中心とした場合も考えられること，ユーザは仕事の完成に報酬を支払うこと等から請負（15）

開発過程・段階に応じて柔軟に性質決定すべき
（20）

３
⑴

裁判例を参考にした義務の検討
裁判例に現れたプロジェクト・マネジメント義（21）

契約の一類型とする見解

務イ

非典型契約とする見解

以下では，スルガ銀行と日本ＩＢＭが当事者とし①

請負や準委任などの典型契約構成を併せ持つ新て争った東京高判平成25年 ９ 月26日金判1428号16頁（11） 武川幸嗣「判批」リマークス53号38頁（2016）（12） 司法研修所編・前掲注（１）108頁（13） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（１）５ 頁（ただし，同文献27頁は，「請負か準委任かで択一的に判断すること自体が果たして適当か否かが問題となり得るところであり，この点についても十分な議論が必要なように思われる。」とも指摘する。）（14） 生田敏康「注文者の協力義務」福岡52巻 ４ 号396頁（2008）（15） 栗原由紀子「システム開発契約における開発業者のプロジェクト・マネジメント義務」青森法政論叢16号４ 頁（2015）（16） 内布光「ソフトウェア開発委託契約紛争事例の研究（ １ ）』現代法学10号168頁（2006）（17） 内布光「ソフトウェア開発委託契約紛争事例の研究（ ２ ）』現代法学11号95頁（2006）（18） 芦野訓和「ソフトウェア開発委託契約」椿寿夫・伊藤進編『非典型契約の総合的検討』（商事法務，2013）169頁（19） 小柴昌也「情報システム・ソフトウェア開発委託契約の特殊性の紛争」帝塚山法学23号11頁（2012）（20） 滝澤孝臣「判批」リマークス47号21頁（2013），同「システム開発契約の裁判実務からみた問題点」判タ
1317号 ５ 頁（2010），小林秀之「金融機関のシステム開発契約と法的問題」銀法745号10頁，15頁（2012），同「金融システム開発契約に係る法的諸論点の帰趨」金法1952号57頁（2012）。また，これに賛成するものとして，難波修一ほか『裁判例から考えるシステム開発紛争の法律実務』（商事法務，2017）52～53頁。
（21） その他の裁判例については前掲注（１）を参照。

システム開発契約におけるプロジェクト・マネジメント義務（帷子）147を参考に，プロジェクト・マネジメント義務についび開発内容の変更を提案し，平成18年 ３ 月から同年て検討する。なお，同裁判例は，事案及び判決いず８ 月まで要件定義の実質的な見直しが行われ，これれも複雑かつ膨大で多岐に渡るため，本稿に関連す

ま で の 開 発 手 法 に 代 え て， Ｘ の 業 務 プ ロ セ ス をる部分を簡単に説明すると，以下のようである。

CoreBank に合わせて変革し個別プログラムの作成

アは最小限に抑える手法が採られた。

事案の概要
Ｘ（スルガ銀行，原告，被控訴人）は，銀行業務

Ｙは，Ｘに対し，平成18年10月，総額 １ 億1000万全般に関する基幹システムを刷新するために，平成円ドルの追加費用のうち3000万ドルの負担を求めた

12年頃，Ｙ（日本ＩＢＭ，被告，控訴人）に対し，が，Ｘはこれを拒否し，また，同年12月に追加費用

オープンプラットフォームによる基幹系システム構

約34億円（減額後は20億円）の追加費用負担を提案

築の提案及び同システムの運用，開発にかかるトーしたが，Ｘはこれも拒否した。また，Ｙは，平成19タルコスト削減の検討を依頼した。Ｘは，平成16年

年 ３ 月，Ｘに対し，新システムを ５ 段階に分けて全３ 月頃，Ｙから，米国 FIS 社が権利を保有するパッ面稼働させるスケジュールを提案したが，Ｘは拒否

ケージソフトである CoreBank を採用するシステムした。

開発の提案を受けた。Ｘは，複数のシステム開発業

Ｙは，平成19年 ４ 月，Ｙに対し，パッケージソフ者からの提案を比較検討し，Ｙの提案に基づいてシトを CoreBank から Temenos 社製の TCB に変更すステム開発を進めることとした。

ることを提案したが，Ｘはこれを拒否するととも

Ｘ及びＹは，同年 ９ 月29日に，システム開発の立に，同年 ５ 月 ９ 日には，プロジェクトを一旦白紙に案や要件定義作業の方針決定・策定等に関する基本戻す旨回答し，さらに同年 ７ 月18日には，各個別契合意（本件基本合意①）及び個別契約を締結し，同約の解除の意思表示をした。

年12月29日にはＸの現行システムの分析，同現行シＸは，Ｙに対し，Ｙの債務不履行または不法行為

ステムと CoreBank を用いたシステムの差異の分析に基づき115億8000万円の損害賠償の支払いを請求等に関する基本合意（本件基本合意②）及び個別契したところ，ＹはＸに対し，反訴として，未払代金約を締結した。なお，システム開発の手法は，Ｘの請求及び協力義務違反を理由とした損害賠償として

現 行 シ ス テ ム が 有 す る 機 能 を ベ ー ス と し て，総額125億円を超える金員の支払いを求めて反訴をCoreBank が有する機能を利用できる場合はそのま提起した。

ま利用し，CoreBank が有しない機能については個

原審はＹのプロジェクト・マネジメント義務違反別にプログラムを作成することで進めるという手法を認定し，約74億円の支払いを命じたところ，Ｙがが採用された。

控訴した。

Ｘ及びＹは，平成17年 ９ 月30日に最終合意書（本イ

判決件最終合意書）を締結した。なお，同合意書 ８ 条但控訴審では，原判決が変更され，Ｘの請求の一部書には，「各個別契約（第 １ 条記載の個別将来契約が認容されて，Ｙに約41億円の損害賠償の支払いがを含むがこれらに限定されない。）が締結され，各命じられた。

関連個別契約の中で両当事者の各局面における義務

控訴審は，まず，「本件システム開発の経緯は，が規定されるまでは，いずれの当事者も本合意書に次のとおり ４ つの段階に分けることができる。
」と基づく何らの法的義務を負わないものとする。」とし，「Ⅰ規定されていた。

階（企画・提案），Ⅱその後，同年12月にはＹがＸに対し，開発方法及企画準備から本件基本合意①締結前の段
本件基本合意①締結から本件基本合意②締結前の段階（計画・要件定義），Ⅲ

148

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

2019. 1

本件基本合意②締結から本件最終合意締結前の段階

因等について，企画・提案段階において漏れなく予（計画・要件定義），Ⅳ本件最終合意締結から本件測することはもとより困難であり，この段階におけシステム開発終了の段階（計画・要件定義，実装）」

る検証，説明等に関する義務も，このような状況にの各段階に分けてプロジェクト・マネジメント義務おける予測可能性を前提とするものであるというべ違反を検討している。

きである。その意味では，ベンダとユーザーの間次に，Ⅰの段階に関して，控訴審は，「企画・提で，システム完成に向けた開発協力体制が構築され案段階においては，プロジェクトの目標の設定，開る以前の企画・提案段階においては，システム開発発費用，開発スコープ及び開発期間の組立て・見込技術等とシステム開発対象の業務内容等について，みなど，プロジェクト構想と実現可能性に関わる事

情報の非対称性，能力の非対称性が双方に在するも項の大枠が定められ，また，それに従って，プロのといえ，ベンダにシステム開発技術等に関する説ジェクトに伴うリスクも決定づけられるから，企明責任が存するとともに，ユーザーにもシステム開画・提案段階においてベンダに求められるプロジェ

発の対象とされる業務の分析とベンダの説明を踏まクトの立案・リスク分析は，システム開発を遂行しえ，システム開発について自らリスク分析をするこていくために欠かせないものである。そうすると，とが求められるものというべきである。このようなベンダとしては，企画・提案段階においても，自らことからすると，企画・提案段階におけるシステム提案するシステムの機能，ユーザーのニーズに対す開発構想等は，プロジェクト遂行過程において得らる充足度，システムの開発手法，受注後の開発体制れるであろう情報，その過程で直面するであろう事等を検討・検証し，そこから想定されるリスクにつ態等に応じて，一定の修正等があることを当然に想いて，ユーザーに説明する義務があるというべきで定するものといえ，企画・提案段階の計画どおりシある。このようなベンダの検証，説明等に関する義ステム開発が進行しないこと等をもって，直ちに企務は，契約締結に向けた交渉過程における信義則に画・提案段階におけるベンダのプロジェクト・マネ基づく不法行為法上の義務として位置づけられ，控ジメントに関する義務違反があったということはで訴人はベンダとしてかかる義務（この段階におけるきない。」として，義務違反については否定していプロジェクト・マネジメントに関する義務）を負うる。

ものといえる。
」として，ベンダが企画・提案からまた，控訴審は，「控訴人は，前記各契約に基づ契約締結までのプロジェクト・マネジメント義務をき，本件システム開発を担うベンダとして，被控訴負うことは認めつつも，「ベンダは，システム開発人に対し，本件システム開発過程において，適宜得技術等に精通しているとしても，システム開発の対られた情報を集約・分析して，ベンダとして通常求象となるユーザーの業務内容等に必ずしも精通してめられる専門的知見を用いてシステム構築を進め，いるものではない。企画・提案段階における事前検ユーザーである被控訴人に必要な説明を行い，その証を充実させることにより，システム開発構想の精了解を得ながら，適宜必要とされる修正，調整等を度を高め，想定外の事態発生の防止を図り得ると考行いつつ，本件システム完成に向けた作業を行うこ

えられるが，受注が確定していない段階における事と（プロジェクト・マネジメント）を適切に行うべ

前検証等の方法，程度等は自ずと限られ，ユーザーき義務を負うものというべきである。また，前記義側の担当者等から得られる情報や協力にも限界があ

務の具体的な内容は，契約文言等から一義的に定まることは明らかである。そのため，プロジェクトがるものではなく，システム開発の遂行過程における開始され，その後の進行過程で生じてくる事情，要状況に応じて変化しつつ定まるものといえる。すなシステム開発契約におけるプロジェクト・マネジメント義務（帷子）149

わち，システム開発は必ずしも当初の想定どおり進

ジェクト・マネジメント義務の根拠の １ つとしていむとは限らず，当初の想定とは異なる要因が生じるると考えられる。

等の状況の変化が明らかとなり，想定していた開発⑵（23）

プロジェクト・マネジメント義務の流動性等

費用，開発スコープ，開発期間等について相当程度

前掲東京高判平成25年 ９ 月26日からプロジェクの修正を要すること，更にはその修正内容がユー

ト・マネジメント義務には以下のような変容性・流ザーの開発目的等に照らして許容限度を超える事態動性を指摘できると考えられる。

が生じることもあるから，ベンダとしては，そのよ

企 画・ 提 案 か ら 契 約 締 プ ロ ジ ェ ク ト 遂 行 段 階

うな局面に応じて，ユーザのシステム開発に伴うメ

結 ま で の プ ロ ジ ェ ク の プ ロ ジ ェ ク ト・ マ ネ

リット，リスク等を考慮し，適時適切に，開発状況

ト・マネジメント義務の分析，開発計画の変更の要否とその内容，更には① 企 画・ 提 案 段 階 に ②おける説明義務開発計画の中止の要否とその影響等についても説明することが求められ，そのような説明義務を負うものというべきである。」と判示して，ベンダのプロジェクト・マネジメント義務を認めつつ，「本件シジメント義務
進捗状況管理③

阻害要因排除④

関与促進⑤

説明，指導助言⑥

中止提言

ステム開発においては，少なくとも，本件最終合意

前掲東京高判平成25年 ９ 月26日がプロジェクト・を締結する段階において，本件システムの抜本的なマネジメント義務をプロジェクトの進捗段階に応じ変更，または，中止を含めた説明，提言及び具体的て変化させ，流動的にその具体的内容を判断するのリスクの告知をしているとは認めがたいから，控訴は，当事者間の契約内容に加えて，前記システム開人に義務違反（プロジェクト・マネジメントに関す発契約の特色を考慮してのものと思われる。プロる義務違反）が認められるというべきである。」とジェクト・マネジメント義務は，契約文言等から一判示し，Ⅱ及びⅢの段階における義務違反は否定し義的に定まるものではなく，開発の進行段階やユーつつも，Ⅳの段階における同義務違反を肯定した。

ザの協力の度合いにおいてその内容が定まるような

４

裁判例の考察⑴

プロジェクト・マネジメント義務の根拠性格ものであり，かつプロジェクトには予期せぬ要因による変更等を余儀なくされるものであることから，事前に義務の具体的な内容を確定することが困

前掲東京高判平成25年 ９ 月26日は，当事者間の契難ないわば能動的・浮動的な義務ということにな約内容のみならず，ベンダに求められる専門的知見る。これは，プロジェクト・マネジメント義務のについて言及し，専門家として有する専門的知識と位置づけや根拠等について，システム開発契約の特経験に基づく責任等を踏まえていると考えられ，そ色の １ つである仕様の不確実性，システムの不可視の他の裁判例においても概ね同様の言及がなされて性を考慮してのことであり，この点も根拠の １ つといることから，ベンダの専門性（ベンダがシステしていると思われる。

ムの開発について専門的知見や経験を備えた専門業⑶（22）者であること。以下同様の意味で用いる。）をプロ（24）

プロジェクト・マネジメント義務検討の視点
前記検討を踏まえると，プロジェクト・マネジメ（22） 前掲注（１）の各裁判例参照。
（23） 生田敏康「請負人の債務（ ２ ・完）─プロジェクト・マネジメント義務を手掛かりに─」福岡59巻 １ 号153
頁（2014）は，ベンダの「有する高度の専門的知識・経験に対する信頼がプロジェクトマネジメント義務の根拠の中心であることは否定できない」とする。
（24） 生田・前掲注（23）140頁

150

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

2019. 1

ント義務の根拠は，当事者間の契約内容のみなら①ず，①ベンダの専門性と，②システム開発契約の特具体化，類型化 及びベンダの負う義務の水準の一色が挙げられると考えられる。また，当事者間の契定程度の明確化

約内容の解釈のみならず，同各根拠に応じた視点か②ら，プロジェクト・マネジメント義務を検討する余のように責任を分担し合うのかについての指針の提地があるものと考えられる。

示

５

ベンダの専門性に着目した検討⑴

ベンダの専門性に着目した検討の意義

プロジェクト・マネジメント義務の一定程度の（26）

（27）

⑵

ベンダとユーザがシステム開発契約においてどいわゆる専門家との契約との共通性等
医師等の専門家との契約形態については，典型契約として委任契約や請負契約あるいはこれに類似す（28）

これまでは，システム開発契約の性質等を踏まる無名契約といった類型が利用されるところ，シスえ，例えば請負契約であるとするならば仕事完成義

テム開発契約についても，法的性質が明らかにされ務との関係でプロジェクト・マネジメント義務をどていないものの，当てはまると考える余地がある。のように位置づけるか，どのように根拠づけるかとまた，専門家契約の特色として，一般的に以下のよいった点から考察がされてきたと考えられる。必うな点が挙げられている。そして，これらについずしもベンダの専門性に着目した検討は十分に行わても，システム開発契約について当てはまると考えれていない。また，前掲東京高判平成25年 ９ 月26日

る余地がある。

（25）

（29）

が契約締結前の企画・提案段階においてもプロジェクト・マネジメント義務を肯定していることからして，ベンダとユーザ間で締結された契約のみに根拠を求めるのではなく，裁判例にて言及されるベンダの専門性に着目した検討が必要になるのではないかと考えられ，同ベンダの専門性に着目した検討には，以下のような意義が見出せるのではないかと考えている。

（25） 生田・前掲注（23）157頁は，システム開発契約が請負契約とした場合のプロジェクトマネジメント義務につき，請負人の債務は仕事完成義務であるものの，履行過程において仕事完成のための具体的義務の １ つがプロジェクトマネジメント義務であるとする。また，栗原・前掲注（15）12～13頁は，システム開発契約を請負契約であると解し，プロジェクトマネジメント義務を仕事完成に向けて行う作為義務として請負人の仕事完成義務に包摂されるものとする。
（26） 生田・前掲注（23）153頁は「専門家ごとに形成されてきた具体的義務の類型は，プロジェクトマネジメント義務の内容を具体化・精緻化するにあたって参考になるものである。」とする。
（27） 山川一陽「専門家責任─総論的記述にかえて─」山川一陽・根田正樹編『専門家責任の理論と実際』（新日本法規出版，1994）19頁は，専門家の職務について技術水準とか専門知識の高度化が顕著化し，これを前提とする注意義務が類型化ないし精緻化されていくことを指摘し，このような義務を前提に，「専門家という観点からの職業基準というものの客観化ないし基準化というものを確立する努力がなされることが求められるべきであると思われる。」とする。
（28） 山川・前掲注（27）８ 頁（29） 下森定「専門家の契約責任」川井健・塩崎勤編『新・裁判実務体系 専門家責任訴訟法』（青林書院，2004）18頁（なお同文献19頁は，第 ４ の特色として利他性・公共性を挙げるが，医師，弁護士，建築家といった職務の特色として挙げているものと考えられる。）

システム開発契約におけるプロジェクト・マネジメント義務（帷子）専門家との契約の特色

システム開発契約
ベンダはシステム開発の専① 契約当事者間の原 門家である一方，ユーザは則的非対等性

システム開発契約について
素人
ユーザの求めるシステム開② 専門家の裁量

プロジェクト・マネジメント義務の位置付け
システム開発契約の性質については争いのあるところではあるが，プロジェクト・マネジメント義務は，当該契約の性質や内容のみと関わっているので手法を用いるか等につき，付けられると考えることができるのではないだろう

ユーザと協力して進めると

（30）

えられる。
ユーザは，ベンダの専門的③ 信頼関係を基盤と 知見や経験等を信頼して契約を締結し，システム開発を依頼するといえる。
⑶⑷

はなく，ベンダの専門性に立脚した注意義務に位置ては一定の裁量があると考する契約のではないだろうか。

発をするため，どのようなはいえ，その選択等につい

（31）

151

専門家の責任を参考にした検討等
専門家の責任においては，各分野に共通するもの（32）

として，注意義務が指摘される。また，専門家にか。これは，ベンダが多種多様のプロジェクト・マネジメント義務を負うことの実質的根拠を与えるとともに，前掲東京高判平成25年 ９ 月26日が，契約締（34）結以前 の企画・設計段階においてもベンダにプロジェクト・マネジメント義務を負わせつつ，その変容性・流動性を認めていることとも整合するのではないかと考えられる。

６

結びに代えて⑴

要約

高度の注意義務が課されることの根拠として，専門

本稿では，前掲東京高判平成25年 ９ 月26日等の検家の職業に対する一般的信頼関係及び契約関係に基討を通じたプロジェクト・マネジメント義務の根拠礎を置いた個別・具体的信頼関係が挙げられ，上を踏まえて，ベンダの専門性の視点から，プロジェ記の通り同信頼関係についてはシステム開発契約にクト・マネジメント義務を考察できないかどうかにおいてもあてはまると考える余地がある。

ついて検討を試みた。システム開発契約におけるベ（33）

そこで，ベンダの専門性に着目した検討を通じンダのプロジェクト・マネジメント義務は，裁判例て，システム開発契約におけるベンダのプロジェクがベンダの専門性に言及するとともに，専門家とのト・マネジメント義務についても，専門家としての契約にみられる特色があてはまると考える余地があ注意義務に位置づけることができるのではないか，ることから，ベンダの専門性という視点からの検討そして，注意義務としてのプロジェクト・マネジメが可能ではないかと考えられる。

ント義務の具体的内容は，契約内容やプロジェクト⑵の進捗状況等によって定まると考えることができる

今後の検討課題
プロジェクト・マネジメント義務は，協力義務と（30） 高田寛「システム開発業者のプロジェクトマネジメント義務」富山大学紀要60巻 １ 号57頁（2014）は，ベンダがどのようなプロジェクト・マネジメントをとるかどうかにおける裁量に言及する。
（31） 前掲注（29）18頁は「専門家集団への信用を背景として契約関係に入っていく」点を指摘し，また，依頼者と専門家との契約関係について，「第一次的には，免許資格制に裏打ちされた当該専門家集団に対する客観的信頼関係，そして，第二次的には当該受任者に対する具体的信頼関係という二重の信頼関係に基づく高度の信頼関係を基盤として成立する契約だという特色を指摘できよう。」とする。
（32） 川井健「専門家責任の意義と課題」川井健・塩崎勤編『新・裁判実務体系 専門家責任訴訟法』（青林書院，2004）10～11頁（33） 下森定「日本法における『専門家の契約責任』」川井健編『専門家の責任』（日本評論社，1993）16～17頁（34） 円谷俊「専門家の不法行為責任」川井健・塩崎勤編『新・裁判実務体系 専門家責任訴訟法』（青林書院，2004）30頁は，専門家が契約成立前においても注意義務が課されていることを指摘する。

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

152

表裏の関係にあると解され，両者の関係も問題になり，また，この点からの考察も必要になると考えられる。すなわち，ベンダがユーザの業務内容等について十分に理解していない点を捉えて，二重の専門（35）性との指摘もなされ，ユーザとベンダの協力関係の必要性からユーザが十分な情報を提供しなければシステム開発が頓挫してしまうため，システム開発契約は医師等のいわゆる専門家との契約とは異なる側面があるではないかとも考えられる一方で，例えば，医師等の専門家であっても患者側等から十分な情報を得ることができなければ適切な診療行為等が難しくなるといった点を捉えて，共通する側面もあると考える余地もある。また，ベンダであればユーザから，医師であれば患者から，必要な情報を積極的に取得すべきであるのか，そのための措置を講ずるべきであるのか，それともユーザや患者の側から提供すべきものであるのかといったように，いずれの側から考察するのかによって検討の視点も異なってくる可能性がある。このような点も踏まえて，ベンダの専門性の視点からの考察が可能かどうかについて検討することが今後の課題である。
以上（35） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（２）７ 頁

2019. 1