業務範囲条項とは？委託内容の曖昧さを防ぐ契約実務のポイント｜Legal GPT

結論：業務範囲条項で決めるべき5要素

業務範囲条項とは何か：法的性質と契約不適合責任との関係

業務委託契約において、業務範囲条項とは「受託者が行うべき作業・役務・成果物の範囲を特定する条項」を指す。契約法上は、民法の規律の上に乗る当事者間の合意として機能し、受託者の義務内容と発注者の対価支払義務の範囲をともに規定する。

2020年（令和2年）4月施行の改正民法により、請負契約における責任のあり方は大きく整理された。旧法下の「瑕疵担保責任」は廃止され、現行法では「契約不適合責任」（民法562条以下）として再定義されている。現行法の考え方は「成果物が種類・品質・数量に関して契約の内容に適合しているかどうか」が基準であり、つまり「契約の内容をどう定めたか」が、責任の発生・不発生を決める。

請負型と準委任型で業務範囲条項の「本質」が変わる

業務委託契約は、法的性質として民法上の「請負」（仕事の完成を目的とする、民法632条）または「委任・準委任」（事務処理を目的とする、民法643条・656条）のいずれかの性質をもつ。この類型の違いは、業務範囲条項において何を最も精緻に定義すべきかに直結する。

実務上、一つの業務委託契約が請負と準委任の混合型になることも多い。例えば「月次で運用報告書を作成する（請負的要素）」と「日常的な問い合わせ対応を行う（準委任的要素）」が同一契約に含まれる場合だ。このような場合、それぞれの要素ごとに業務範囲の定義方法を使い分けることが望ましい。

5要素の詳細解説

① 委託業務の内容（作業記述）

最初に決めるべきは「受託者が何をするか」の具体的な作業記述だ。「システム開発業務」「マーケティング支援業務」「コンサルティング業務」といった上位概念だけでは機能しない。実務で問題になるのは、その「一般的名称」の下にある個別の作業項目が合意されていない場合だ。

作業記述には次の点を盛り込むことが望ましい。まず、作業の具体的な内容（工程・タスク・方法論の概要）を記すこと。次に、作業の頻度・量・工数の目安があれば明示すること。そして、作業の実施場所・方法（リモート可否、委託者施設での作業有無など）についても、後の運用上の認識齟齬を防ぐために明記しておくと有用だ。

② 成果物の特定 請負型で特に重要

請負型の業務委託では、成果物（deliverable）を具体的に特定することが特に重要となる。「何が成果物か」が不明確なまま納品期限を迎えると、「まだ未完成」vs「もう完成している」という認識の衝突が起きる。

成果物の特定に際しては、以下を明確にするのが実務上の標準だ。成果物の名称・種類・数量、成果物の品質基準または仕様（あるいはそれを定める別紙・仕様書への参照）、納品期限および納品方法、検収基準（何をもって契約の内容への「適合」とするか）、検収期間（委託者側の確認期間）。

③ 対象範囲と除外事項

業務範囲条項において、「何が含まれるか」と同等かそれ以上に重要なのが「何が含まれないか」の明示だ。除外事項を書くことは、発注者側にとって「後から範囲外のことを要求されたときの根拠」になる。

実務上、除外事項として明記しておくべき典型例としては、委託者側が本来行う内部調整・承認業務、第三者との交渉・契約締結行為、法令に基づいて委託者が自ら実施しなければならない手続、業務遂行に必要なライセンスやアカウントの取得費用負担、仕様変更に伴う追加作業などが挙げられる。

④ 前提条件（委託者側の提供義務）

業務範囲条項が「受託者の義務」だけを定める形になりがちだが、委託者側の協力義務・提供義務（前提条件）を明記することも実務上は重要だ。受託者が業務を遂行するために委託者が提供すべきもの（情報・データ・アクセス権・担当者のレビュー対応等）が所定のタイミングで提供されなかった場合、納品遅延や追加費用が生じることがある。

前提条件として記載しておくべき事項の代表例は、委託者が提供すべき資料・データ・システムアクセスの内容と提供期限、委託者側の担当者との連絡体制・対応頻度、業務遂行のために必要な委託者側の決裁・承認のタイミング、前提条件が履行されなかった場合の納期・費用への影響ルールなどだ。

⑤ 判断基準（範囲外の確認フロー）

どれだけ精緻に業務範囲を定義しても、実際の業務遂行中に「これは範囲内か範囲外か」という判断が求められる場面は必ず生じる。そのときに頼るべき判断フローを予め定めておくことが、スコープ膨張を防ぐ最後の砦となる。具体的には「範囲外と思われる作業依頼があった場合、受託者は書面で確認し、追加合意なく着手しない」という手続的なルールを契約内または変更管理条項に置くことが有効だ。

条文例比較：悪い例・良い例・改善例

悪い例①：内容が抽象的すぎる

悪い例②：「必要な対応」という包括表現

良い例・改善例：5要素を盛り込んだ設計

スコープ膨張が起きるメカニズム

スコープ膨張（scope creep）とは、当初合意した業務範囲が、契約変更の正式な手続きを経ることなく徐々に拡大していく現象を指す。IT開発プロジェクトやコンサルティング業務で頻繁に問題となるが、どのような業種の業務委託契約でも起きうる。

スコープ膨張の典型的なパターンとして、発注者側の担当者が口頭・メールで「ちょっとこれも」と追加依頼するケース、受託者が関係強化のために断れずに引き受けるケース、仕様変更・要件追加が正式な変更合意なく着手されるケース、成果物の品質基準が曖昧なため追加修正が繰り返されるケースなどが挙げられる。

「付随業務」をめぐる争点

実務で最も揉めやすいのは、明文化された作業そのものではなく、それに「当然付随する」と期待される業務（定例報告会議への出席、資料作成、進捗報告、メール対応等）をめぐる解釈の齟齬だ。

例えば、「A業務のコンサルティング」を委託した場合、定例会議への出席・議事録作成・質問対応等は「当然含まれる」と発注者側が期待していても、受託者側が「それは別途の工数だ」と主張するケースは珍しくない。

報酬形態（固定額 vs 精算型）と業務範囲の連動

業務範囲条項は単独で完結するものではなく、報酬条項と密接に連動する。報酬形態の違いによって、業務範囲条項で「何を最も精緻に定義すべきか」の力点が変わってくる。

SOW・仕様書・提案書・見積書との関係

業務委託契約における業務範囲の特定は、契約書本文だけで行われるわけではない。実務上は複数の文書が組み合わさって業務範囲を画する。これらの文書の位置づけと優先関係を整理しておかないと、文書間で内容が矛盾した場合に混乱を招く。

完全合意条項（Entire Agreement）との関係

契約書に「本契約は、本件に関する当事者間のすべての合意を構成し、本契約締結前の交渉・提案・見積書・その他の合意はすべて失効する」という趣旨の完全合意条項が含まれている場合、提案書や見積書は法的には参照不能となる。

文書間の優先順位の定め方

契約本文・SOW・仕様書・見積書の間に内容の矛盾が生じた場合に備え、優先順位条項を設けることが実務上の標準とされている。一般的には「本契約書本文 ＞ 個別契約・SOW ＞ 仕様書 ＞ 見積書・提案書」という優先順位が多いが、実際の優先順位は業務の性質によって設計を変える必要がある。

契約本文管理 vs 別紙管理の選択

業務範囲の詳細を契約本文に書くか、別紙（SOW・仕様書等）で管理するかは、契約の性質と運用の実態に応じて判断する。

変更管理条項との接続

業務範囲条項を精緻に設計しても、業務開始後に変更が生じないプロジェクトはほとんど存在しない。重要なのは「変更が生じた場合にどう処理するか」のルール（変更管理条項、Change Management Clause）を契約書に組み込み、業務範囲条項と論理的に接続しておくことだ。

変更管理条項に盛り込むべき事項は、変更依頼の提起方法（書面・所定フォームによる提起の義務付け）、受託者による変更内容の評価・見積提示の期限、変更合意の成立要件（書面による両者の合意）、変更合意前に追加作業への着手を禁止する旨の明記、変更に伴う報酬・納期の調整方法、そして下請法上の親事業者に該当する場合は変更後の3条書面（発注書）の再交付義務（下請法3条）への対応だ。

実務チェックリスト：発注前・締結時・運用中

発注者側がやりがちな6つの失敗パターン