第3回：業務委託契約における委託内容の重要性

おすすめ資料を無料でダウンロードできます ✅ ひと目でわかる要チェック条文 業務委託契約書編

※この記事は、2023年11月31日時点の法令等に基づいて作成されています。

業務委託契約における委託内容（総論）

第1回目において解説したとおり、昨今、社会情勢の急激な変化やITの急速な発展に伴い、新しい形態の業務委託契約が増えています。

そのような中で、業務委託契約においては、目的条項をどのように規定するかが重要になります。委託する業務の内容や範囲について明確に定めなければ、受託者としては、何をもって債務を履行したことになるのか判然とせず、受託者の法的安定性を害してしまいます。

また、目的条項は、契約不適合責任との関係でも重要です。次回以降に詳しく解説する予定ですが、契約の内容に適合するか否かは、当事者がどのような経緯、動機、目的で当該契約を締結したのかといった点も判断要素となります。

業務委託契約における委託内容の定め方は、契約書によってさまざまです。基本契約と個別契約で構成される契約の場合は、基本契約書においては大まかな記載にとどめ、個別契約において詳細を記載することが考えられます。また、

• 契約書に定義や条件とともに委託内容を列挙する例
• 別紙として設けた明細書や仕様書に委託内容を詳細に記載する例

もあります。

委託内容に関する条項の重要性―システム開発委託契約書を参考に―

今回は、業務委託契約の典型例である「システム開発委託契約書」を参考に、委託内容に関する条項の重要性を解説していきます。

システム開発委託契約と一口に言ってもその様相は多様化しています。例えば、

• ある程度パッケージ化されたシステムを提供するもの
• ユーザ（委託者）の要望に応えカスタムしたシステムをベンダ（受託者）が開発・提供するもの
• 大規模なシステム開発から小規模なシステム開発に至るもの
• ベンダが一業者のものから複数業者のもの（マルチベンダ方式）
• 従来から行われてきたウォーターフォールモデルのもの
• 近年注目されてきている非ウォーターフォールモデル（アジャイル型など）のもの

などが存在します。

システム開発委託契約を締結するに当たっては、これら多様な類型のうち、どの類型を採用するのかを意識し、個別の契約書に反映させる必要があります（システム開発委託契約の類型につき、長谷川俊明編著『業務委託契約の基本と書式〔第2版〕』中央経済社、2022年、27頁以下が詳しい）。

また、システム開発委託契約においては、委託者と受託者との間で委託業務の内容や仕様に関する認識のズレが生じてトラブルになることがあるため、委託の範囲を具体的に定めることが求められます。

システム開発委託契約の契約類型

業務委託契約は、請負型（成果物あり）と委任・準委任型（成果物なし）に分けられます。第2回目において解説したとおり、システム開発委託契約においても、その契約類型を巡って法的トラブルになった事例があります。

この点、システム開発委託契約の契約類型について、独立行政法人情報処理推進機構と経済産業省が公表する「～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第二版〉」56頁は、以下のように説明しています（注釈は省略）。

請負ではベンダは仕事（受託業務）の完成の義務を負うのに対し、準委任ではベンダは善良な管理者の注意をもって委任事務を処理する義務を負うものの、仕事の完成についての義務は負わない。別の観点からいえば、請負に馴染むのは、業務に着手する前の段階でベンダにとって成果物の内容が具体的に特定できる場合ということになる。したがって、内部設計やソフトウェア設計などのフェーズは、請負で行うことが可能である。
これに対して、システム化計画や要件定義のフェーズは、ユーザ側の業務要件が具体的に確定しておらず、ユーザ自身にとってもフェーズの開始時点では成果物が具体的に想定できないものであるから、ベンダにとっても成果物の内容を具体的に想定することは通常不可能である。そのため、請負には馴染みにくく、準委任が適切ということになる。

独立行政法人情報処理推進機構・経済産業省「～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第二版〉」56頁

この説明によると、システム化計画や要件定義の段階では、委託者と受託者の双方にとって成果物を具体的に想定できないため準委任型が適切である一方、内部設計やソフトウェアなどの段階では、具体的な成果物を想定できるため請負型がなじむということです。

もっとも、具体的な成果物を想定できるか否かという判断基準は、あくまでも目安に過ぎず、結局は個別具体的に判断することになるでしょう。例えば、経済産業省が公表する「AI・データの利用に関する契約ガイドライン」48頁は、「従来型のソフトウェア開発の場合とは異なり、学習済みモデル生成の場合はどの段階においても準委任型の契約が親和的である」と説明しています。

AI技術は発展途上であり、たとえ成果物を具体的に想定できるからといって、受託者に対して、“何らのバグも生じ得ないAIシステム”の完成を求め、請負型とするのはあまりに酷でしょう。

このように、システム開発委託契約の契約類型を検討するに当たっては、契約書の文言や成果物の有無はもちろん、成果物の実現可能性などを加味することになるのでしょう。

委託内容の定め方

今回紹介する契約書式例は、会社がコンピュータシステムの構築とこれに関連する業務を、システム開発業者に委託する場合で、ウォーターフォールモデルを前提とする中規模のものを想定しています。

ここでは、委託内容について定めた1条と2条を紹介します（その他の条項については、前掲・長谷川俊明編著101頁以下を参照）。

システム開発委託契約書 　●●●●株式会社（以下「甲」という。）と、株式会社××××（以下「乙」という。）は、甲の○○○システムの開発に関する業務について、甲を委託者、乙を受託者として、以下のとおり契約（以下「本契約」という。）を締結する。   第1条（定義） 　　本契約において使用される用語の定義は、次の各号に定めるとおりとする。 　⑴　「委託業務明細書」とは、本契約に別紙1として添付される「委託業務明細書」1から3までを総称していう。 　⑵　「本業務」とは、委託業務明細書に記載されたすべての業務を総称していう。 　⑶　「本システム」とは、委託業務明細書1の記載に従って乙によって開発されるべきハードウェア、ソフトウェア及び付帯設備を含む情報システムを総称していう。 　⑷　「企画支援業務」とは、本システムの構築のための甲が行う企画、設計及び仕様書の作成等に関して乙が甲に対して提供する準委任形態の支援業務で、委託業務明細書2に記載された業務をいう。 　⑸　「システム構築業務」とは、委託業務明細書3及び本契約第4条に従って決定される「最終仕様書」に基づいて乙が甲に対して提供する本システムを構築する請負形態の業務をいう。 　⑹　「本プログラム」とは、本システムのうち本システムのために乙によって新たに開発されるプログラムをいう。 　⑺　「運用支援業務」とは、本システムの甲による導入、運用等に関して乙が甲に対して提供する準委任形態の支援業務で、委託業務明細書3に記載された業務をいう。 　⑻　「原始資料」とは、本業務のために甲が乙に対して提供する別紙2「原子資料目録」〔省略〕記載の資料及び本契約の履行過程において随時必要に応じて甲から乙へ提供される資料をいう。 　⑼　「本業務担当者」とは、本業務の遂行に関する甲及び乙の各責任者で、別紙3「業務担当者名簿」〔省略〕に記載された者をいう。 　⑽　「本作業スケジュール」とは、別紙4「作業スケジュール」〔省略〕に記載された本業務の遂行に関する時間的なスケジュールをいう。   第2条（本業務の委託） 　甲は、乙に対し、本契約に定める条件に従って本業務を委託し、乙は、これを受託する。 （以下、略）

第1条は、本契約例において使用される用語の定義を定める規定です。
システム開発委託契約においては、対象となる業務の内容や範囲等に関してトラブルになることが多いため、できるだけ明確かつ詳細な定義を定めることが望ましいです。

ウォーターフォールモデルでは、要件定義等の基本計画が重要になると考えられるため、別紙形式を用いて詳細な定義を定めています。

それでは続いて、本契約例に別紙1として添付される「委託業務明細書」（本明細書）を見ていきましょう。当然のことながら、本明細書も本契約例の一内容となり、委託者と受託者を拘束します。

委託業務明細書   1　本業務の範囲 甲が乙に対して委託する本業務の内容は、次項及び第3項に掲げるものとする。   2　企画支援業務 　⑴　乙は、本システム構築のために甲が行う企画、設計及び仕様書の作成を支援するサービスを提供する。 　⑵　乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査・分析・整理・提案及び助言を行うものとする。   3　システム構築業務 　⑴　システム構築業務の内容は、次に掲げるとおりとする。 　　ア　プログラム開発 　　イ　単体・結合テスト、システムテスト 　　ウ　プログラム導入計画・実施 　⑵　次に掲げる業務は、システム構築業務の対象又は範囲に含まれないものとする。 　　ア　○○○○ 　　イ　○○○○ 　　ウ　○○○○ 　⑶　システム構築業務の成果物は、次に掲げるとおりとする。 　　ア　プログラムソースコード 　　イ　テスト仕様書 　　ウ　テスト結果報告書 　　エ　運用手順書 　　オ　最終仕様書

本契約例において、委託者（甲）が受託者（乙）に委託する業務は、

• 企画支援業務（1条4号）
• システム構築業務（同条5号）

に分けられます。

企画支援業務については、準委任型であることを前提に、乙が受託する業務を特定するとともに、乙が善管注意義務（民法644条）を負うことを定めています。

システム構築業務については、請負型であることを前提に、乙が受託する業務（とそれに含まれない業務）を列挙するとともに、乙が甲に対して提出する成果物を列挙しています。

このように、システム開発委託契約書（や明細書・仕様書）において委託内容を詳細に定めることで、委託者と受託者との間で生じる可能性のある“トラブルの芽”を摘むことができるでしょう。

システム開発委託契約におけるトラブル

システム開発委託契約に関するトラブルは、いったん紛争が生じると長期化することが多い上、損害賠償額も高額化する傾向にあると指摘されています（近藤圭介編著『業務委託契約書作成のポイント（第2版）』中央経済社、2022年、121頁）。

システム開発委託契約書の仕様書に記載のない機能が委託の内容に含まれるとした事例－東京地裁平成16年6月23日判例集未搭載

事案の概要

本件の事案を簡略化して時系列順に並べると、以下のようになります。

①H11.03.25	Y社・X社	本件ソフト開発契約を締結 （ステップ1） 　　格安航空券の購入ページプログラム 　　土産・旅行用品の購入ページプログラム 　　決済プログラム （ステップ2） 　　ホテル予約及び決済 　　保険の加入受付及び決済
②	X社⇒Y社	Y社が発注した機能を、でき上がったとする部分から徐々に引き渡し
③H11.04.01 　H11.05.12	Y社⇒X社	ステップ1について、代金全額（1512万円）支払い ステップ1について、要件分析費用等（109万2000円）支払い
④H11.07	Y社⇒X社 X社⇒Y社	「■■■」とリンクしたウェブサイト「△△△」に関するホームページサーバーの構築とメールサーバーの構築等を委託（本件業務委託契約1） 環境設定作業、メールアカウント増設作業、メールアカウントホスティング作業を実施して引き渡し
⑤H12.04.15	Y社⇒X社 X社⇒Y社	H11.04.15以降の本件ソフトの運用保守管理を目的とする業務を委託（本件業務委託契約2） A社にサーバー2台を設置し、本件ソフトの運用保守管理業務を行った
⑥	Y社⇒X社	H12.04～08.21までの間の代金187万9624円を支払わない
⑦H11.11.29	Y社⇒X社	本件ソフトの不完全履行若しくは瑕疵を理由として本件ソフト開発契約を解除する旨の意思表示
⑧	X社⇒Y社 Y社⇒X社	⑴本件ソフト開発契約に基づき残代金929万2348円、⑵本件業務委託契約1に基づき代金24万2348円、⑶本件業務委託契約2に基づき残代金187万9624円を請求（本訴） ⑴本件ソフト開発契約につき支払い済みの代金2571万2000円からY社が支払い義務を認めている本件業務委託契約1に基づく代金24万2348円を控除した2546万9652円、⑵本件業務委託契約2につき支払い済代金452万0303円の支払いを請求（反訴）

なお、裁判所が認定した事実によると、本件ソフト開発契約書においては、次のような条項が定められていました。

第9条　（中略） 　⑵　Y社は、成果物について、X社・Y社別途合意する方法で検査を行い、納入された日から10日以内に検査結果をX社に通知するものとする。 　⑶　前項に定める検査の合格をもって、成果物の検収完了とし、成果物の検収完了をもって本業務の完了とする。 　⑷　第2項に定める期間内に検査結果の通知がなされない場合、又はY社が成果物を検査以外の目的に使用した場合には、その時点をもって成果物の検収が完了したものと見做す。

争点

本件の争点は多岐にわたりますが、今回のテーマである委託の内容という点に絞ると、次の2点が挙げられます。

①本件ソフト開発契約に遠隔操作機能追加の合意が存在したか否か
②X社が本件ソフトを完成させたか否か

判旨

1　本件ソフト開発契約に遠隔操作機能追加の合意が存在したか否か 　　「本件ソフト開発契約の仕様書……には、遠隔操作機能について記載されていない〔が〕、もともとソフトウエアの仕様書は複雑なものであり、専門家でなければ容易にわかり得ないものであるから、仕様書に記載がないからといって、契約の内容になっていないということはできない」。「証拠……によれば、旅行業界においては、例えば航空券の場合、時期によって料金が異なったり、料金が変更されたりするため、その都度これを原告に依頼して行うのではなく、遠隔操作機能によって、被告が直接サーバーのデータを変更することが不可欠とされていること、Y社も、そのような観点から、契約締結に先立ち、X社との打ち合わせの過程で、そのことをX社に伝え、X社の了解を得ていたこと、その結果、X社が作成した構成図……には、『リモートメンテ機』として、遠隔操作機能を示す記載がされていること、また、X社が作成した「■■■　作業項目について」と題する書面……及び「■■■　残作業項目」と題する書面……にも、『リモートデータメンテ』として、遠隔操作機能を示す記載があること」が認められる。 　　本件の事実関係に照らすと、「遠隔操作機能については、本件ソフト開発契約の仕様書には記載がないものの、X社は、Y社から、口頭で、遠隔操作機能の開発依頼も受けた」といえる。   2　X社が本件ソフトを完成させたか否か 　　「Y社にとって、本件ソフトは、決済機能が十分に機能し、かつ、遠隔操作できるものでなければ意味のないものであったところ、本件ソフトは、このような決済機能が十分に作動せず、遠隔操作もできないものであったものであるから、そのようなソフトによっては、Y社は、契約の目的を達したことにはならず、本件ソフトは、Y社にとって欠陥が著しいものであり、未だ完成したものとはいえない」。 　　「X社は、Y社が、成果物納入の日から10日以内に検査結果の通知を行わなかったから、……成果物を検収したものとみなされる旨主張する。しかし、このような結果が行われるためには、X社の協力が不可欠であるところ、X社は、Y社に対し、このような検査のための協力を行っていないと認められるから、本件においては、Y社が、成果物納入の日から10日以内に検査結果の通知を行わなかったからといって、……Y社が本件ソフトを検収したものとみなされるものではない。」

コメント

本件において、本件ソフト開発契約の受託者であるX社は、委託者であるY社に対して、請負代金の支払いを求める本訴を提起しました。これに対し、Y社は、X社に対して、主位的には本件ソフト開発契約の不完全履行解除による原状回復請求権に基づき、予備的には瑕疵担保解除による原状回復請求権に基づき、損害賠償の支払いを求める反訴を提起しました。

Y社は、X社の不完全履行の根拠として、本件ソフトに遠隔操作機能追加への拡張性がなかったことを主張しました。これに対して、X社は、遠隔操作機能については仕様書に記載がないため、本件ソフト開発契約における委託の内容ではないと反論しました。

ところで、本件ソフトは、Y社のウェブサイトに、航空券等の申し込みや、決済等の機能を追加することを目的としていました。航空券はその性質上、時期によって料金が異なったり変更されたりするため、Y社が直接サーバーのデータを変更することが不可欠とされていました。契約締結前の打ち合わせにおいて、Y社はX社に対してこの点を伝え、X社も了解していました。また、X社が作成した書面においても、遠隔操作機能を示す記載が複数ありました。

これらの事情に照らし、裁判所は、遠隔操作機能について、本件ソフト開発契約の仕様書に記載はないものの、X社とY社の間において委託の内容になっていた、と認定しました。

前述のとおり、委託者と受託者の間に生じるトラブルを未然に防止することを目的として、システム開発委託契約書や明細書・仕様書において委託内容を詳細に定める必要があります。しかし、本件のように、問題となっている機能がシステムを稼働する上で不可欠なものであり、両当事者間で口頭の合意がなされている場合は、システム開発委託契約書に明記されていなくても、当該機能も委託の内容に含まれる可能性があります。

本件は、システム開発委託契約書に明記されていない業務を委託の内容に含めたという点で、委託者に有利な判決と言えます。

ただし、システム開発委託契約の中に完全合意条項（いったん契約書面を作成したらこれが当事者の合意を唯一最終のものとして尊重しなければならず、後になって、実はこれに反する口頭の約束があったなどと主張することがゆるされなくなるというもの）が定められている場合、本判決の射程は及ばないでしょう。