プロジェクトマネジメント義務とは？ベンダーの責任の範囲と主な裁判例を弁護士が解説

システム開発が遅れたり途中で止まったりしたとき、ベンダーとユーザーのどちらが責任を負うのか。その判断の物差しになってきたのが、プロジェクトマネジメント義務です。明文の規定はありませんが、裁判所は多くの事件でこの義務を前提に判断してきました。

一方で、ベンダーが義務を尽くしていたと判断され、ユーザー側の請求が退けられた高裁判決も続いています。義務の中身と限界を押さえておくと、契約書に何を書き、トラブルの最中に何を残すべきかが見えてきます。

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

プロジェクトマネジメント義務とは、システム開発を受託したベンダーが、開発を計画どおり進めるために進捗を管理し、障害となる事情を見つけて対処し、専門知識のないユーザーにも必要な判断や協力を働きかける義務をいいます。法律に明文の規定はなく、裁判例が契約と信義則（互いに誠実に行動すべきという民法の原則）から導いてきた考え方です。プロマネ義務、PM義務と略されることもあります。

▼ ベンダーが負うプロジェクトマネジメント義務の主な内容

法的根拠は契約と信義則

プロジェクトマネジメント義務の根拠は、契約を結んだ後と前とで分かれます。契約を結んだ後は、契約に付随する義務や善管注意義務として扱われ、違反すれば債務不履行（民法415条）として主張されるのが一般的ですが、不法行為として構成された例もあります。

契約を結ぶ前の提案や見積りの段階には、まだ契約上の義務がありません。それでも、権利の行使と義務の履行は信義に従い誠実に行わなければならないという信義則（民法1条2項）を根拠に、交渉過程での説明義務を負う場合があります。違反すれば不法行為（民法709条）の責任を問われ、東京高判平成25年9月26日がこの考え方をとっています。

参考：e-Gov法令検索「民法」

準委任の善管注意義務や請負の完成義務との関係

システム開発の契約は、準委任契約か請負契約で結ばれることがほとんどです。準委任では、ベンダーは善良な管理者の注意をもって業務を処理する義務、いわゆる善管注意義務を負います（民法656条・644条）。プロジェクトマネジメント義務は、この善管注意義務の中身を、システム開発の場面に即して具体的にしたものと整理できます。

請負は、仕事の完成を約束する契約です（民法632条）。完成義務を負う以上、完成に向けて工程を管理することもベンダーの役目に含まれると考えられています。準委任でも請負でも、契約形態によってプロジェクトマネジメント義務がなくなるわけではありません。もっとも、義務の範囲は契約で決めた役割分担で変わり、ユーザーがPMOを置く体制や複数のベンダーが並行する体制では限られることがあります。

プロジェクトマネジメント義務と対になるユーザーの協力義務

ユーザーにも、開発に協力する義務があります。東京地判平成16年3月10日は、オーダーメイドのシステム開発ではベンダーだけでシステムを完成させることはできないとして、ユーザーが担うべき役割を具体的に挙げました。

▼ ユーザーが負う協力義務の主な内容

ベンダーのプロジェクトマネジメント義務とユーザーの協力義務は、裏表の関係にあります。もっとも、ユーザーが協力しなくても、ベンダーが判断や協力を働きかけていなければ、ベンダーの義務違反とされることがあります。一方で、ユーザーの協力義務違反を理由にベンダーから賠償を求められる場合もあり、旭川医大事件がその例です。仕様変更や追加作業をめぐる協力義務は、次の記事で解説しています。

プロジェクトマネジメント義務が争われた主な裁判例

プロジェクトマネジメント義務は、ベンダーの責任を認める方向にも、否定する方向にも使われてきました。代表的な4件は次のとおりです。

▼ プロジェクトマネジメント義務が争われた主な裁判例

東京地判平成16年3月10日 義務の内容を示した判決

東京地判平成16年3月10日は、義務の内容を具体的に示した判決として、現在も広く引用されています。

被告は，納入期限までに本件電算システムを完成させるように，本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務を負うものと解すべきである。そして，システム開発は注文者と打合せを重ねて，その意向を踏まえながら行うものであるから，被告は，注文者である原告国保のシステム開発へのかかわりについても，適切に管理し，システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務（以下，これらの義務を「プロジェクトマネージメント義務」という。）を負っていたというべきである。

東京地方裁判所 平成16年3月10日判決（判例タイムズ1211号129頁）

もっともこの事件では、裁判所は双方の債務不履行を否定しました。そのうえで、ユーザーの解除を注文者による解除（民法641条）とみて、ベンダーへの損害賠償を認めています。賠償額は、過失相殺の規定（民法418条）を類推して6割減らされました。

東京高判平成25年9月26日 契約前の提案段階にも及ぶ義務

いわゆるスルガ銀行事件の控訴審判決です。銀行の基幹系システムの開発が途中で中止された事件で、判決は契約前の企画・提案段階について次のように述べました。

（前略）ベンダとしては，企画・提案段階においても，自ら提案するシステムの機能，ユーザーのニーズに対する充足度，システムの開発手法，受注後の開発体制等を検討・検証し，そこから想定されるリスクについて，ユーザーに説明する義務があるというべきである。このようなベンダの検証，説明等に関する義務は，契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務として位置づけられ，控訴人はベンダとしてかかる義務（この段階におけるプロジェクト・マネジメントに関する義務）を負うものといえる。

東京高等裁判所 平成25年9月26日判決（金融・商事判例1428号16頁）

契約前であっても、ベンダーは想定されるリスクをユーザーに説明する義務を負うとされました。ただし本件では、企画・提案段階の違反は認められませんでした。違反とされたのは、開発が行き詰まった後に結び直した最終合意の段階です。ベンダーは費用、範囲、期間を抜本的に見直す必要を具体的に説明し、危機を避けられなければ開発の中止も提言すべきだったとされました。

一方で、受注前のベンダーが知り得る情報には限りがあり、ユーザーも自らリスクを分析すべきだとも述べています。この判決は、最高裁が上告を退けて確定しました。

札幌高判平成29年8月31日 ベンダーが義務を尽くしたとされた例

いわゆる旭川医大事件です。電子カルテを含む大学病院の病院情報管理システムを開発する中で、現場から追加の要望が相次ぎ、引渡しが予定の期日に間に合いませんでした。ユーザーとベンダーが互いに賠償を求めました。

ベンダーは追加要望の一部を受け入れたうえで、それ以降は追加の開発要望を出さないという仕様凍結の合意をユーザーと結んでいました。高裁は、追加要望に応じれば納期を守れないことを明らかにし、仕様凍結を含めた対応をとったことを、プロジェクトマネジメント義務の履行と評価しました。それを超えて、さらに追加要望をしないようユーザーを説得したり、不当な追加要望を毅然と拒否したりする義務まではないとして、ベンダーの責任を否定しています。

一審の旭川地判平成28年3月29日は頓挫の責任をユーザー2割、ベンダー8割としていましたが、高裁はこれを変更し、ユーザーに約14億円の支払を命じました。プロジェクトマネジメント義務は、プロジェクトが失敗したらベンダーが責任を負うという結果責任ではありません。

参考：裁判所「裁判例結果詳細 平成28(ネ)189 札幌高等裁判所 平成29年8月31日判決」

東京高判令和3年4月21日 ユーザーの変更要求と義務の限界

野村ホールディングスと野村證券が日本IBMを訴えた事件の控訴審です。資産運用サービス向けのシステム開発が、稼働開始に間に合わないおそれから中断され、ユーザー側が断念しました。

高裁は、ベンダーが工数の削減に努め、体制も適切な時期に点検していたと認めました。基本設計に入った後の度重なる変更要求には凍結を求めるなど、可能な限度でプロジェクトマネジメントを行っていたとしています。計画が崩れた原因は、ユーザー側が変更要求を繰り返し、適切に対応しなかったことにあると判断しています。

結論として、一審が認めた約16億円の賠償を取り消してユーザー側の請求を退け、ベンダーが逆に請求していた報酬のうち1億1224万5000円の支払をユーザーに命じました。旭川医大事件と合わせると、変更要求の影響を説明して凍結を求めたベンダーの対応が、義務の履行として評価されています。

参考：裁判所「裁判例結果詳細 平成31(ネ)1616 東京高等裁判所 令和3年4月21日判決」

プロジェクトマネジメント義務違反の効果

プロジェクトマネジメント義務違反が認められると、ベンダーは損害賠償や契約解除の責任を負う可能性があります。

ベンダーが義務に違反した場合

ベンダーに義務違反があった場合、ユーザーはベンダーに対して損害賠償（民法415条）や契約の解除（民法541条・542条）を主張することになります。ただし、不履行がユーザーの責めによるときは解除できません（民法543条）。損害賠償も、ユーザー側の落ち度によってはベンダーの責任が否定されたり、過失相殺（民法418条）で減額されたりする可能性があります。

契約前の説明義務違反のように不法行為（民法709条）として扱われるものでも、ユーザーの過失が考慮されることがあります（民法722条2項）。実際の事件では、どちらか一方だけに責任があると判断されるとは限らず、双方の落ち度に応じて賠償額が増減することもあります。

開発が途中で止まったときの報酬の精算

開発が途中で止まったとき、ベンダーがどこまで報酬を受け取れるかは、契約形態と、どちらの責任で止まったかで変わります。

▼ 開発が途中で止まった場合の報酬の扱い

もっとも、システム開発で何が可分な部分なのか、履行の割合をどう測るのかは、事前には決めにくいものです。契約書に中途解約や精算の定めがあれば、原則としてそちらによります。工程ごとに個別契約を結び、工程ごとに委託料を支払う形にしておくと、途中で止まったときの精算の争いを小さくできます。

プロジェクトマネジメント義務を契約書で定めるポイント

プロジェクトマネジメント義務には明文がないため、何をすれば義務を果たしたことになるのかは、最終的に裁判所が事実から判断します。契約書で役割と手続を決めておけば、何をもって義務を果たしたとみるかの基準を、当事者の側で示せます。経済産業省とIPAが公表している情報システム・モデル取引・契約書（第二版）には、次の条項があります。

▼ モデル契約でプロジェクトマネジメントに関わる主な条項

連絡協議会の議事録や変更管理書は、紛争になったとき、どちらが何を求め、何に同意したかを示す証拠になります。旭川医大事件で評価された仕様凍結の合意も、変更管理の手続に乗せておけば書面で残ります。モデル契約では中止の提言は「できる」と定められていますが、状況によっては提言しないこと自体が義務違反とされることがあります（スルガ銀行事件）。

モデル契約はひな型であり、そのまま使えば足りるものではありません。開発手法、パッケージを使うかどうか、工程ごとに契約を分けるかどうかによって、条項の手直しが必要です。

参考：IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開・2026年9月11日最終更新）

プロジェクトマネジメント義務をめぐる紛争に備えて残す記録

プロジェクトマネジメント義務を果たしたかどうかは、議事録やメールなど、プロジェクトの最中に残された記録から認定されます。

ベンダー側が残すべき記録

ベンダーが残すべきなのは、ユーザーに判断を求めた記録です。決めるべき事項と期限、遅れた場合の納期や費用への影響を、議事録や書面で伝えておきます。追加要望を受けたときは、受け入れるのか、断るのか、別の費用とスケジュールで受けるのかを、変更管理の手続に乗せて書面にします。議事録は相手方の確認を受け、承認や異議の有無まで残します。

課題管理表も残しておきます。課題の発生日、対応者、ユーザーの回答日が分かれば、遅れの原因がどちらにあったかを示せます。口頭で伝えただけの警告は、後から立証するのが難しくなるためです。紛争の兆しが出たら、メールやチャットも消さずに保全し、記録を後から書き換えないでください。

ユーザー側が残すべき記録

ユーザーが残すべきなのは、自社が協力義務を果たした記録と、ベンダーから受けた説明の内容です。要件を決めた日や質問に回答した日が分かれば、協力が遅れていなかったことを示せます。

ベンダーの提案書や見積りの前提条件、リスクについての説明の有無も保存しておきます。スルガ銀行事件のように、提案段階の説明が争点になることがあるからです。社内から要望が増え続けているときは、正式に依頼する前に、スケジュールと費用への影響をベンダーに見積もってもらい、その回答を記録に残します。

プロジェクトマネジメント義務に関するよくある質問

アジャイル開発でもプロジェクトマネジメント義務はありますか

アジャイル開発でも、ベンダーが進め方について専門家として負う義務はなくなりません。ただし、ユーザーの役割は大きくなります。IPAのアジャイル開発版モデル契約は、準委任契約としてベンダーに完成義務を負わせていません。そのうえで、善良な管理者の注意をもって業務を行い、要求事項の優先順位への助言や技術的なリスクの説明に努めると定めています（第5条）。要求事項とその優先順位を決めるのはユーザー側の役割です。

参考：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月31日公開）

プロジェクトマネジメント義務違反の損害賠償に上限はありますか

契約書に責任制限条項があれば、賠償額がその範囲に限られる可能性があります。モデル契約の第53条も賠償の累計額に上限を設けていますが、故意または重大な過失による場合には適用しないとしています。条項に明記がなくても、故意や重大な過失があれば制限が及ばないと判断されることがあります。

プロジェクトマネジメント義務違反の請求はいつまでできますか

債務不履行による損害賠償の請求権は、権利を行使できることを知った時から5年、行使できる時から10年で時効にかかります（民法166条1項）。契約前の説明義務違反のように不法行為として扱われるものは、損害と加害者を知った時から3年、不法行為の時から20年です（民法724条）。2020年3月31日以前に結んだ契約には、改正前の規定が適用されることがあります。請負で引き渡された後の不具合は、知った時から1年以内に通知しないと権利を失うおそれもあります（民法637条）。契約書で請求期間を短く定めている例もあるため、確認が欠かせません。

まとめ：プロジェクトマネジメント義務をめぐるトラブルは弁護士に相談を

プロジェクトマネジメント義務は、ベンダーが進捗を管理し、障害に対処し、ユーザーに判断と協力を働きかける義務です。

一方で、ベンダーが変更要求の影響を説明し、仕様の凍結を求めていた事件では、プロジェクトが失敗しても責任が否定されています。その対応は議事録などの記録で裏づけられていましたが、結論は個別の事情で変わります。開発が遅れ始めた段階で弁護士に相談すれば、記録の残し方から中止の判断まで、手を打てる範囲が広がります。

当事務所による対策のご案内

モノリス法律事務所は、IT・インターネット・AI分野を中心とする東京都大手町の企業法務系法律事務所です。システム開発契約書の作成・レビューから、開発が遅延・中断した際の交渉や訴訟対応まで扱っています。ユーザー、ベンダーどちらのお立場のご相談もお受けしています。