（4） 経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む），保守運用）〈第一版〉」33頁（2006）（http://www.meti.g o.jp/policy/it_policy/softseibi/index.html#05）

143

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

─専門家の視点からの一考察─

x x x x

１ はじめに

コンピュータ・ソフトウェアや情報処理システムの開発契約（以下「システム開発契約」という。）を巡り，システム開発の依頼を受けた開発業者（以下「ベンダ」という。）とシステム開発の依頼者

（以下「ユーザ」という。）との間で紛争が生じることが多々ある。

システム開発契約は，ユーザとベンダの共同作業であって，双方が信頼関係をもって協力し合わなければ成功はおぼつかないと言われている。このような当事者の協力というものは，法的な義務とされ，ベンダのプロジェクト・マネジメント義務（以下

「プロジェクト・マネジメント義務」という。）及びユーザの協力義務（以下「協力義務」という。）と

して各種裁判例（後掲東京高判平成25年 ９ 月26日金

（1）

判1428号16頁等）においても認められている。こ

のような当事者の義務違反が問題となるような紛争の類型は，以下のように，システム開発が途中で頓挫してしまった場合に見受けられる。

① システム開発が途中で頓挫し，システムの構築に至らなかったため，ユーザがベンダに対し，システム開発の過程におけるベンダのプロジェクト・マ

ネジメント義務違反を理由に，債務不履行または不法行為責任を追及する場合（契約上の義務または不法行為上の注意義務として主張する。）。

② 上記①のようなユーザの請求に対し，ベンダがシステム開発の報酬の一部（出来高）を反訴で請求する，またはシステム開発が頓挫した原因はユーザが同開発に協力しなかったことにあり，このような協力義務の違反を理由として損害賠償を請求する場合（契約上の義務または不法行為上の注意義務として主張する。）。

③ ベンダがユーザに対しシステム開発の報酬の一部（出来高）を請求したところ，ユーザが上記①記載の請求を反訴として請求する場合。

上記のような紛争における重要な問題点は，システム開発が頓挫してしまった責任をベンダまたはユーザのいずれが負担するべきなのかという点にあると考えられる。すなわち，ベンダ側は，xxxが協力義務に違反してシステム開発に必要な協力をしなかったため頓挫したと主張する一方，ユーザ側は，ベンダがプロジェクト・マネジメント義務に違反したためにシステム開発が頓挫したと主張するため，契約当事者のいずれがシステム開発が頓挫した場合の責任を負担すべきであるのかという点が重要

（1） その他の裁判例として，東京地判平成 ９ 年 ９ 月24日判タ９67号168頁，広島地判平成11年10月27日判時16９９号101頁，東京地判平成14年 4 月22日判タ1127号161頁，東京地xxxx判平成15年11月 5 日判時1857号73頁，

東京地判平成16年 3 月10日判タ1211号12９頁，東京高判平成26年 1 月15日公刊物未登載（平成25年（ネ）第

3９52号／平成25年（ネ）第5742号），東京地判平成28年 4 月28日判時2313号2９頁，札幌高判平成2９年 8 月31日判例時報2362号24頁等がある。

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

このようなシステム開発契約においてシステム開発が頓挫した場合の責任分担を考えるにあたっては，当事者間の契約において，システム開発が頓挫した場合の責任分担に関する何らかの合意（プロジェクト・マネジメント義務及び協力義務に関する合意を含む。）がなされていれば同合意の解釈・適用によって規律されることになると考えられるが，当事者間においては明確に合意がなされていない場合も少なくない。

当事者間において上記のような合意がなされてい

ない場合において，システム開発が頓挫した場合の

されていない場合に，同責任分担を規律するために重要になると考えられるシステム開発契約の当事者の義務のうち，ベンダのプロジェクト・マネジメント義務に関して，裁判例等を参考に，ベンダがシステムの開発について専門的知見や経験を備えた専門業者であるという専門性に着目した考察をすることができないかどうかについて，検討を試みたい。

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

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

システム開発の手法は様々であり，一概にはいえ

（2） （3）

責任分担を規律する上では，ベンダが通常履践すべ きであると考えられるプロジェクト・マネジメント義務またはユーザが通常履践すべきである協力義務を念頭において，同義務を尽くしていたと評価できるのかどうかという観点からの判断が必要になってくるものと考えられる。同観点からの判断にあたっては，プロジェクト・マネジメント義務及びユーザの協力義務を一定程度具体化，類型化し，その水準を一定程度明確にする必要があるものと考えられ，そのためには，プロジェクト・マネジメント義務及び協力義務の根拠，内容及び両者の関係等が重要になると考えられる。また，プロジェクト・マネジメント義務及び協力義務を一定程度具体化・類型化することができれば，システム開発契約の内容の合理化も図ることができるのではないかと考えている。本稿は，未定稿での研究ノートとして作成したも のであるが，以下では，システム開発契約の概要等について確認した上で，当事者間において，システム開発が頓挫した場合の責任分担に関する合意がな

ないが，基本系を示すと以下のような形となる。

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

② ベンダへの開発依頼

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

④ システムの仕様の確定（要件定義を含む）

＊ 要件定義：システム化計画を受けて，業務上の要求を業務要件に，システムに実装すべきシステ

（4）

ムの機能要件・非機能要件を定義する段階

⑤ 基本設計を行い，開発の製造工程に入る

⑥ テスト工程

（2） 司法研修所編『民事訴訟における事実認定─契約分野別研究（製作及び開発に関する研究）─』（法曹会， 2014）９2頁，東京地方裁判所プラクティス委員会第二小委員会「ソフトウェア開発関係訴訟の手引」判タ

134９号 4 頁（2011）参照

（3） ㈳情報サービス産業協会法的問題委員会契約部会『新しいソフトウェア開発委託取引の契約と実務』（商事法務，2002）32頁以下参照

（4） 経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む），保守運用）〈第一版〉」33頁（2006）（xxxx://xxx.xxxx.xx.xx/xxxxxx/xx_xxxxxx/xxxxxxxxx/xxxxx.xxxx#00）

（5）

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

基本契約

要件定義 基本設計 開発

システムテスト

個別契約

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

ア 一括契約方式

⑶ システム開発契約の特色

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

（7）

① 専門的知見の必要性

システムは無形の存在であり製作や内部の仕組み

（8）

に関する専門的知見を要する。

システム開発の全プロセスを一括して契約する方式のことをいう。

要件定義 基本設計 開発

システムテスト

イ 多段階契約方式

開発工程を分けて，それぞれの工程を取引単位とした個別契約を設定し，それら全体に共通する事項等を定めた基本契約を締結した上で，最初の個別契約を契約し，当該工程が終了するとその後xx後続

（6）

の個別契約を締結して開発を進行する方式。多段

階契約方式は，開発規模の大きい場合に用いられることが多く，工程ごとに委任契約または請負契約が使い分けられる。

（9）

② 仕様の不確実性，システムの不可視性

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

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

ユーザの業務内容ニーズとベンダの専門知識や技能とを照らし合わせる等の協力関係が必要で（システムの内容は千差万別でありオーダーメイド的性格を有するものであるから，ユーザからデータその他の提供，ユーザとベンダの間の円滑な意思疎通など，緊密な協力関係がなければ構築は困難にな

（10）

る。），両者の協力関係を前提に，変更及び調整を

重ねながら，システムの仕様を具体化していくことが要求される。

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

（5） 経済産業省・前掲注（4）31頁

（6） ㈳電子情報技術産業協会ソリューションサービス事業委員会『ソフトウェア開発モデル契約書の解説』（商事法務，2008）37頁は，基本契約では全体的事項や共通事項等を約定し，個別契約では各工程における契約金額，納期等を約定するとする。

（7） xxxxほか「ソフトウェア開発関連訴訟の審理」判タ1340号 5 頁（2011）

（8） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（1）7 頁は，「ベンダーはＩＴの専門家であるが，ユーザーの業務について必ずしも十分に理解しているとは限ら」ないとし，「二重の意味での専門性が内在している」と指摘する。

（9） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（1）7 頁参照

（10） xxxx「システム開発の頓挫と開発業者の責任─スルガ銀行・日本ＩＢＭ事件第 1 審および控訴審判決をめぐって─」福岡5９巻 3 号53９頁（2014）

（11）

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

ユーザとベンダとの間で形成されたシステムに関する合意は，個々の項目ごとではなくシステム全体との関係で有機的一体としての合意が形成されている

（12）

と評されている。

⑷ システム開発契約の実体的法律関係

ア 裁判実務

システム開発契約は，民法制定当時予想されていなかった契約類型であるが，実務的には，請負契約，準委任契約または労働者派遣契約のいずれかで

（13）

処理されているとされる。

イ 学説

学説においては，以下のような見解が示されている。

ア 請負契約とする見解

① ソフトウェアは完成しなければ無意味であるとして，特殊な場合を除き，システム開発契約は請負

（14）

契約であるとする見解

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

（15）

契約の一類型とする見解

イ 非典型契約とする見解

① 請負や準委任などの典型契約構成を併せ持つ新

種の非典型契約であり，その取引形態は，請負型，委任型，派遣型の 3 つに分けられるが，その取引契約の目的・内容に応じて契約類型に当てはめられる

（16）

とし，実際の取引では請負型で取引されることが

多いが，目的物であるソフトウェアの性質上，完成すべき仕事の内容にユーザとベンダとの間で認識のずれが生じやすい等の問題があり民法の請負契約と

（17）

同様に扱うことは無理があるという。

② 基本契約と複数の個別契約が一体になった契約である点，契約の目的となるのは知的給付であり物ではないという点，注文者が通常の請負契約以上に仕事完成に向けて協力義務を負う点及びどの段階をもって仕事の完成をしたと考えるべきか不明である

（18）

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

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

（19）

を提案する見解

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

（20）

であるとする見解

３ 裁判例を参考にした義務の検討

⑴ 裁判例に現れたプロジェクト・マネジメント義

（21）

務

以下では，スルガ銀行と日本ＩＢＭが当事者として争った東京高判平成25年 ９ 月26日金判1428号16頁

（11） xxxx「判批」リマークス53号38頁（2016）

（12） 司法研修所編・前掲注（1）108頁

（13） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（1）5 頁（ただし，同文献27頁は，「請負か準委任かで択一的に判断すること自体が果たして適当か否かが問題となり得るところであり，この点についても十分な議論が必要なように思われる。」とも指摘する。）

（14） xxxx「注文者の協力義務」福岡52巻 4 号3９6頁（2008）

（15） xxxxx「システム開発契約における開発業者のプロジェクト・マネジメント義務」青森法政論叢16号 4 頁（2015）

（16） xxx「ソフトウェア開発委託契約紛争事例の研究（ 1 ）』現代法学10号168頁（2006）

（17） xxx「ソフトウェア開発委託契約紛争事例の研究（ 2 ）』現代法学11号９5頁（2006）

（18） xxxx「ソフトウェア開発委託契約」xxx・xxxx『非典型契約の総合的検討』（商事法務，2013） 16９頁

（19） xxxx「情報システム・ソフトウェア開発委託契約の特殊性の紛争」帝塚山法学23号11頁（2012）

（20） xxxx「判批」リマークス47号21頁（2013），同「システム開発契約の裁判実務からみた問題点」判タ 1317号 5 頁（2010），xxxx「金融機関のシステム開発契約と法的問題」銀法745号10頁，15頁（2012），同

「金融システム開発契約に係る法的諸論点の帰趨」金法1９52号57頁（2012）。また，これに賛成するものとして，xxxxほか『裁判例から考えるシステム開発紛争の法律実務』（商事法務，2017）52～53頁。

（21） その他の裁判例については前掲注（1）を参照。

を参考に，プロジェクト・マネジメント義務について検討する。なお，同裁判例は，事案及び判決いずれも複雑かつ膨大で多岐に渡るため，本稿に関連する部分を簡単に説明すると，以下のようである。 ア 事案の概要

Ｘ（スルガ銀行，原告，被控訴人）は，銀行業務全般に関する基幹システムを刷新するために，平成 12年頃，Ｙ（日本ＩＢＭ，被告，控訴人）に対し，オープンプラットフォームによる基幹系システム構築の提案及び同システムの運用，開発にかかるトータルコスト削減の検討を依頼した。Ｘは，平成16年 3 月頃，Ｙから，米国FIS社が権利を保有するパッケージソフトであるCoreBankを採用するシステム開発の提案を受けた。Ｘは，複数のシステム開発業者からの提案を比較検討し，Ｙの提案に基づいてシステム開発を進めることとした。

Ｘ及びＹは，同年 ９ 月2９日に，システム開発の立案や要件定義作業の方針決定・策定等に関する基本合意（本件基本合意①）及び個別契約を締結し，同年12月2９日にはＸの現行システムの分析，同現行システムとCoreBankを用いたシステムの差異の分析等に関する基本合意（本件基本合意②）及び個別契約を締結した。なお，システム開発の手法は，Ｘの現行システムが有する機能をベースとして， CoreBankが有する機能を利用できる場合はそのまま利用し，CoreBankが有しない機能については個別にプログラムを作成することで進めるという手法が採用された。

Ｘ及びＹは，平成17年 ９ 月30日に最終合意書（本件最終合意書）を締結した。なお，同合意書 8 条但書には，「各個別契約（第 1 条記載の個別将来契約を含むがこれらに限定されない。）が締結され，各関連個別契約の中で両当事者の各局面における義務が規定されるまでは，いずれの当事者も本合意書に基づく何らの法的義務を負わないものとする。」と規定されていた。

その後，同年12月にはＹがＸに対し，開発方法及

び開発内容の変更を提案し，平成18年 3 月から同年

8 月まで要件定義の実質的な見直しが行われ，これまでの開発手法に代えて，Ｘの業務プロセスを CoreBankに合わせて変革し個別プログラムの作成は最小限に抑える手法が採られた。

Ｙは，Ｘに対し，平成18年10月，総額 1 億1000万円ドルの追加費用のうち3000万ドルの負担を求めたが，Xはこれを拒否し，また，同年12月に追加費用約34億円（減額後は20億円）の追加費用負担を提案したが，Ｘはこれも拒否した。また，Ｙは，平成1９年 3 月，Ｘに対し，新システムを 5 段階に分けて全面稼働させるスケジュールを提案したが，Ｘは拒否した。

Ｙは，平成1９年 4 月，Ｙに対し，パッケージソフトをCoreBankからTemenos社製のTCBに変更することを提案したが，Ｘはこれを拒否するとともに，同年 5 月 ９ 日には，プロジェクトを一旦白紙に戻す旨回答し，さらに同年 7 月18日には，各個別契約の解除の意思表示をした。

Ｘは，Ｙに対し，Ｙの債務不履行または不法行為に基づき115億8000万円の損害賠償の支払いを請求したところ，ＹはＸに対し，反訴として，未払代金請求及び協力義務違反を理由とした損害賠償として総額125億円を超える金員の支払いを求めて反訴を提起した。

原審はＹのプロジェクト・マネジメント義務違反を認定し，約74億円の支払いを命じたところ，Ｙが控訴した。

x 判決

控訴審では，原判決が変更され，Ｘの請求の一部が認容されて，Ｙに約41億円の損害賠償の支払いが命じられた。

控訴審は，まず，「本件システム開発の経緯は，次のとおり 4 つの段階に分けることができる。」とし，「Ⅰ 企画準備から本件基本合意①締結前の段階（企画・提案），Ⅱ 本件基本合意①締結から本件基本合意②締結前の段階（計画・要件定義），Ⅲ

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

（計画・要件定義），Ⅳ 本件最終合意締結から本件システム開発終了の段階（計画・要件定義，実装）」の各段階に分けてプロジェクト・マネジメント義務違反を検討している。

次に，Ⅰの段階に関して，控訴審は，「企画・提案段階においては，プロジェクトの目標の設定，開発費用，開発スコープ及び開発期間の組立て・見込みなど，プロジェクト構想と実現可能性に関わる事項の大枠が定められ，また，それに従って，プロジェクトに伴うリスクも決定づけられるから，企画・提案段階においてベンダに求められるプロジェクトの立案・リスク分析は，システム開発を遂行していくために欠かせないものである。そうすると，ベンダとしては，企画・提案段階においても，自ら提案するシステムの機能，ユーザーのニーズに対する充足度，システムの開発手法，受注後の開発体制等を検討・検証し，そこから想定されるリスクについて，ユーザーに説明する義務があるというべきである。このようなベンダの検証，説明等に関する義務は，契約締結に向けた交渉過程におけるxxxに基づく不法行為法上の義務として位置づけられ，控訴人はベンダとしてかかる義務（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる。」として，ベンダが企画・提案から契約締結までのプロジェクト・マネジメント義務を負うことは認めつつも，「ベンダは，システム開発技術等に精通しているとしても，システム開発の対象となるユーザーの業務内容等に必ずしも精通しているものではない。企画・提案段階における事前検証を充実させることにより，システム開発構想の精度を高め，想定外の事態発生の防止を図り得ると考えられるが，受注が確定していない段階における事前検証等の方法，程度等は自ずと限られ，ユーザー側の担当者等から得られる情報や協力にも限界があることは明らかである。そのため，プロジェクトが開始され，その後の進行過程で生じてくる事情，要

因等について，企画・提案段階において漏れなく予測することはもとより困難であり，この段階における検証，説明等に関する義務も，このような状況における予測可能性を前提とするものであるというべきである。その意味では，ベンダとユーザーの間で，システム完成に向けた開発協力体制が構築される以前の企画・提案段階においては，システム開発技術等とシステム開発対象の業務内容等について，情報の非対称性，能力の非対称性が双方に在するものといえ，ベンダにシステム開発技術等に関する説明責任が存するとともに，ユーザーにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ，システム開発について自らリスク分析をすることが求められるものというべきである。このようなことからすると，企画・提案段階におけるシステム開発構想等は，プロジェクト遂行過程において得られるであろう情報，その過程で直面するであろう事態等に応じて，一定の修正等があることを当然に想定するものといえ，企画・提案段階の計画どおりシステム開発が進行しないこと等をもって，直ちに企画・提案段階におけるベンダのプロジェクト・マネジメントに関する義務違反があったということはできない。」として，義務違反については否定している。

また，控訴審は，「控訴人は，前記各契約に基づき，本件システム開発を担うベンダとして，被控訴人に対し，本件システム開発過程において，適宜得られた情報を集約・分析して，ベンダとして通常求められる専門的知見を用いてシステム構築を進め，ユーザーである被控訴人に必要な説明を行い，その了解を得ながら，適宜必要とされる修正，調整等を行いつつ，本件システム完成に向けた作業を行うこと（プロジェクト・マネジメント）を適切に行うべき義務を負うものというべきである。また，前記義務の具体的な内容は，契約文言等からxx的に定まるものではなく，システム開発の遂行過程における状況に応じて変化しつつ定まるものといえる。すな

わち，システム開発は必ずしも当初の想定どおり進むとは限らず，当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり，想定していた開発費用，開発スコープ，開発期間等について相当程度の修正を要すること，更にはその修正内容がユーザーの開発目的等に照らして許容限度を超える事態が生じることもあるから，ベンダとしては，そのような局面に応じて，ユーザのシステム開発に伴うメリット，リスク等を考慮し，適時適切に，開発状況の分析，開発計画の変更の要否とその内容，更には開発計画の中止の要否とその影響等についても説明することが求められ，そのような説明義務を負うものというべきである。」と判示して，ベンダのプロジェクト・マネジメント義務を認めつつ，「本件システム開発においては，少なくとも，本件最終合意を締結する段階において，本件システムの抜本的な変更，または，中止を含めた説明，提言及び具体的リスクの告知をしているとは認めがたいから，控訴人に義務違反（プロジェクト・マネジメントに関する義務違反）が認められるというべきである。」と判示し，Ⅱ及びⅢの段階における義務違反は否定しつつも，Ⅳの段階における同義務違反を肯定した。

４ 裁判例の考察

⑴ プロジェクト・マネジメント義務の根拠

前掲東京高判平成25年 ９ 月26日は，当事者間の契約内容のみならず，ベンダに求められる専門的知見について言及し，専門家として有する専門的知識と経験に基づく責任等を踏まえていると考えられ，その他の裁判例においても概ね同様の言及がなされて

（22）

いることから，ベンダの専門性（ベンダがシステ

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

ジェクト・マネジメント義務の根拠の 1 つとしてい

（23）

ると考えられる。

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

前掲東京高判平成25年 ９ 月26日からプロジェクト・マネジメント義務には以下のような変容性・流動性を指摘できると考えられる。

企画・提案から契約締	プロジェクト遂行段階
結 ま で の プ ロ ジ ェ ク	のプロジェクト・マネ
ト・マネジメント義務	ジメント義務
① 企画・提案段階に	② 進捗状況管理
おける説明義務	③ 阻害要因排除
	④ 関与促進
	⑤ 説明，指導助言
	⑥ 中止提言

前掲東京高判平成25年 ９ 月26日がプロジェクト・マネジメント義務をプロジェクトの進捗段階に応じて変化させ，流動的にその具体的内容を判断するのは，当事者間の契約内容に加えて，前記システム開発契約の特色を考慮してのものと思われる。プロジェクト・マネジメント義務は，契約文言等からxx的に定まるものではなく，開発の進行段階やユーザの協力の度合いにおいてその内容が定まるような性格ものであり，かつプロジェクトには予期せぬ要因による変更等を余儀なくされるものであることから，事前に義務の具体的な内容を確定することが困難ないわば能動的・浮動的な義務ということにな

（24）

る。これは，プロジェクト・マネジメント義務の

位置づけや根拠等について，システム開発契約の特色の 1 つである仕様の不確実性，システムの不可視

性を考慮してのことであり，この点も根拠の 1 つとしていると思われる。

⑶ プロジェクト・マネジメント義務検討の視点

前記検討を踏まえると，プロジェクト・マネジメ

（22） 前掲注（1）の各裁判例参照。

（23） xxxx「請負人の債務（ 2 ・完）─プロジェクト・マネジメント義務を手掛かりに─」福岡5９巻 1 号153頁（2014）は，ベンダの「有する高度の専門的知識・経験に対する信頼がプロジェクトマネジメント義務の根拠の中心であることは否定できない」とする。

（24） xx・前掲注（23）140頁

ント義務の根拠は，当事者間の契約内容のみならず，①ベンダの専門性と，②システム開発契約の特色が挙げられると考えられる。また，当事者間の契約内容の解釈のみならず，同各根拠に応じた視点から，プロジェクト・マネジメント義務を検討する余地があるものと考えられる。

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

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

これまでは，システム開発契約の性質等を踏まえ，例えば請負契約であるとするならば仕事完成義務との関係でプロジェクト・マネジメント義務をどのように位置づけるか，どのように根拠づけるかと

（25）

いった点から考察がされてきたと考えられる。必

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

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

（26）

具体化，類型化及びベンダの負う義務の水準の一

（27）

定程度の明確化

② ベンダとユーザがシステム開発契約においてどのように責任を分担し合うのかについての指針の提示

⑵ いわゆる専門家との契約との共通性等

医師等の専門家との契約形態については，典型契約として委任契約や請負契約あるいはこれに類似す

（28）

る無名契約といった類型が利用されるところ，シス

テム開発契約についても，法的性質が明らかにされていないものの，当てはまると考える余地がある。また，専門家契約の特色として，一般的に以下のよ

（29）

うな点が挙げられている。そして，これらについ

ても，システム開発契約について当てはまると考える余地がある。

（25） xx・前掲注（23）157頁は，システム開発契約が請負契約とした場合のプロジェクトマネジメント義務につき，請負人の債務は仕事完成義務であるものの，履行過程において仕事完成のための具体的義務の 1 つがプロジェクトマネジメント義務であるとする。また，xx・前掲注（15）12～13頁は，システム開発契約を請負契約であると解し，プロジェクトマネジメント義務を仕事完成に向けて行う作為義務として請負人の仕事完成義務に包摂されるものとする。

（26） xx・前掲注（23）153頁は「専門家ごとに形成されてきた具体的義務の類型は，プロジェクトマネジメント義務の内容を具体化・精緻化するにあたって参考になるものである。」とする。

（27） xxxx「専門家責任─総論的記述にかえて─」xxxx・xxxx編『専門家責任の理論と実際』（新日本法規出版，1９９4）1９頁は，専門家の職務について技術水準とか専門知識の高度化が顕著化し，これを前提とする注意義務が類型化ないし精緻化されていくことを指摘し，このような義務を前提に，「専門家という観点からの職業基準というものの客観化ないし基準化というものを確立する努力がなされることが求められるべきであると思われる。」とする。

（28） xx・前掲注（27）8 頁

（29） xxx「専門家の契約責任」xxx・xxx編『新・裁判実務体系 専門家責任訴訟法』（青林書院， 2004）18頁（なお同文献1９頁は，第 4 の特色として利他性・公共性を挙げるが，医師，弁護士，建築家といった職務の特色として挙げているものと考えられる。）

専門家との契約の特色	システム開発契約
① 契約当事者間の原則的非対等性	ベンダはシステム開発の専門家である一方，ユーザはシステム開発契約について 素人
② 専門家の裁量	ユーザの求めるシステム開発をするため，どのような手法を用いるか等につき，ユーザと協力して進めるとはいえ，その選択等につい ては一定の裁量があると考 （30） えられる。
（31） ③ 信頼関係を基盤と する契約	ユーザは，ベンダの専門的知見や経験等を信頼して契約を締結し，システム開発 を依頼するといえる。

⑶ 専門家の責任を参考にした検討等

専門家の責任においては，各分野に共通するもの

（32）

として，注意義務が指摘される。また，専門家に

高度の注意義務が課されることの根拠として，専門家の職業に対する一般的信頼関係及び契約関係に基

（33）

礎を置いた個別・具体的信頼関係が挙げられ，上

記の通り同信頼関係についてはシステム開発契約においてもあてはまると考える余地がある。

そこで，ベンダの専門性に着目した検討を通じて，システム開発契約におけるベンダのプロジェクト・マネジメント義務についても，専門家としての注意義務に位置づけることができるのではないか，そして，注意義務としてのプロジェクト・マネジメント義務の具体的内容は，契約内容やプロジェクトの進捗状況等によって定まると考えることができる

のではないだろうか。

⑷ プロジェクト・マネジメント義務の位置付け

システム開発契約の性質については争いのあるところではあるが，プロジェクト・マネジメント義務は，当該契約の性質や内容のみと関わっているのではなく，ベンダの専門性に立脚した注意義務に位置付けられると考えることができるのではないだろうか。これは，xxxが多種多様のプロジェクト・マネジメント義務を負うことの実質的根拠を与えるとともに，前掲東京高判平成25年 ９ 月26日が，契約締

（34）

結以前の企画・設計段階においてもベンダにプロ

ジェクト・マネジメント義務を負わせつつ，その変容性・流動性を認めていることとも整合するのではないかと考えられる。

６ 結びに代えて

⑴ 要約

本稿では，前掲東京高判平成25年 ９ 月26日等の検討を通じたプロジェクト・マネジメント義務の根拠を踏まえて，ベンダの専門性の視点から，プロジェクト・マネジメント義務を考察できないかどうかについて検討を試みた。システム開発契約におけるベンダのプロジェクト・マネジメント義務は，裁判例がベンダの専門性に言及するとともに，専門家との契約にみられる特色があてはまると考える余地があることから，ベンダの専門性という視点からの検討が可能ではないかと考えられる。

⑵ 今後の検討課題

プロジェクト・マネジメント義務は，協力義務と

（30） xxx「システム開発業者のプロジェクトマネジメント義務」富山大学紀要60巻 1 号57頁（2014）は，ベンダがどのようなプロジェクト・マネジメントをとるかどうかにおける裁量に言及する。

（31） 前掲注（2９）18頁は「専門家集団への信用を背景として契約関係に入っていく」点を指摘し，また，依頼者と専門家との契約関係について，「第一次的には，免許資格制に裏打ちされた当該専門家集団に対する客観的信頼関係，そして，第二次的には当該受任者に対する具体的信頼関係という二重の信頼関係に基づく高度の信頼関係を基盤として成立する契約だという特色を指摘できよう。」とする。

（32） xxx「専門家責任の意義と課題」xxx・xxx編『新・裁判実務体系 専門家責任訴訟法』（青林書院，2004）10～11頁

（33） xxx「日本法における『専門家の契約責任』」xxxx『専門家の責任』（日本評論社，1９９3）16～17頁

（34） xxx「専門家の不法行為責任」xxx・xxx編『新・裁判実務体系 専門家責任訴訟法』（青林書院， 2004）30頁は，専門家が契約成立前においても注意義務が課されていることを指摘する。

表裏の関係にあると解され，両者の関係も問題になり，また，この点からの考察も必要になると考えられる。すなわち，ベンダがユーザの業務内容等について十分に理解していない点を捉えて，二重の専門

（35）

性との指摘もなされ，xxxとベンダの協力関係

の必要性からユーザが十分な情報を提供しなければシステム開発が頓挫してしまうため，システム開発契約は医師等のいわゆる専門家との契約とは異なる側面があるではないかとも考えられる一方で，例えば，医師等の専門家であっても患者側等から十分な情報を得ることができなければ適切な診療行為等が難しくなるといった点を捉えて，共通する側面もあると考える余地もある。また，ベンダであればユーザから，医師であれば患者から，必要な情報を積極的に取得すべきであるのか，そのための措置を講ずるべきであるのか，それともユーザや患者の側から提供すべきものであるのかといったように，いずれの側から考察するのかによって検討の視点も異なってくる可能性がある。このような点も踏まえて，ベンダの専門性の視点からの考察が可能かどうかについて検討することが今後の課題である。

以上

（35） 東京地方裁判所プラクティス委員会第二小委員会・前掲注（2）7 頁