SOWとは？契約での使い方と記載項目｜請負・準委任の書き分け

ベンダーから提示された契約ドラフトに「別紙：SOW（作業範囲記述書）」という書類が添付されていて、中身を読んでも「これで本当に大丈夫なのか」が判断できない。あるいは社内の法務や購買から「作業範囲が曖昧なので、この内容では稟議を通せない」と差し戻されてしまった。そんな状況で「SOWとは」と検索された方は少なくないはずです。

検索すれば SOW の定義や「記載すべき項目リスト」はすぐに見つかります。しかし実際に困るのは、その先です。手元にある RFP や見積書と SOW はどう違うのか。SOW に書いたことに法的な拘束力はあるのか。契約書と矛盾したらどちらが優先するのか。そして何より、発注側として「どこまで細かく書けば後から揉めないのか」という判断基準が、項目リストを眺めても出てこないのです。

この判断が難しいのは、SOW が「書式」ではなく「合意の設計」だからです。同じ項目を埋めても、請負契約で使うのか準委任契約で使うのかによって、書くべき内容は変わります。書きすぎれば偽装請負を疑われ、書き足りなければ追加費用を請求される。その間のどこに線を引くかは、テンプレートを埋める作業では決まりません。

本記事では、SOW を「揉めないための合意装置」として捉え直し、発注側の視点から整理します。RFP・要件定義書・WBS・契約書との関係、必ず詰めるべき8つの記載項目、請負契約と準委任契約での書き分け、そして押印前に確認すべきチェックポイントまでを解説します。読み終えたときに、ベンダー提示の SOW を自分で読み解き、社内に説明できる状態を目指します。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

SOWとは？契約で作業範囲・成果物・責任分担を定める文書

SOWとは、Statement of Work の略で、日本語では「作業範囲記述書」または「作業明細書」と訳されます。発注者と受注者が、プロジェクトの目的・成果物・作業範囲・スケジュール・役割分担・責任範囲を、契約の一部として文書で合意するためのものです。読み方は「エスオーダブリュー」が一般的ですが、「ソウ」と読む現場もあります。

ここで押さえておきたいのは、SOW の本質が「何を作るか」を書くことではない、という点です。何を作るかは、提案書にも見積書にも書かれています。SOW が担う固有の役割は、「何を作らないか」「どちらがやるか」を言語化することにあります。

たとえばシステム開発で「受発注管理機能を開発する」と書いただけでは、既存システムからのデータ移行が含まれるのか、操作マニュアルの作成が含まれるのか、現場担当者への操作研修が含まれるのかが決まりません。この決まっていない部分が、プロジェクト終盤に「追加費用」や「検収拒否」という形で現れます。

前回の発注で「言った／言わない」の議論になり、追加費用を請求されて社内で責任を問われた経験がある方は、おそらく SOW が存在しなかった、もしくは存在していても範囲の外側が書かれていなかったケースに該当します。SOW は、そのすり合わせを押印前に強制的に行わせる装置だと考えると、以降の判断がしやすくなります。

SOWが定める4つの要素

SOW の記載項目は十数項目にわたることが一般的ですが、機能の観点で整理すると次の4要素に集約できます。この4要素のどれかが欠けている SOW は、合意装置として機能しません。

多くの解説記事は1番目と2番目に紙幅を割きますが、発注側が社内説明で詰まるのは3番目と4番目です。「発注者側は何をいつまでにやる必要があるのか」「仕様が変わったらどういう手続きで決めるのか」が書かれていない SOW は、結果的に発注担当者が板挟みになります。

契約の場面でSOWが必要になるのはいつか

SOW を作成・確認するタイミングは、大きく2つあります。

ひとつは、提案を受領してから契約を締結する前です。ベンダーの提案書と見積書を受け取った段階では、両者の理解にはまだずれが残っています。そのずれを文書に落として相互に確認し、確認済みの内容を契約に取り込むのが SOW の役割です。この順序が逆になり、契約締結後に SOW を作ろうとすると、金額が確定した後に範囲を議論することになり、交渉力が落ちます。

もうひとつは、工程ごとに個別契約を結ぶ場合の各工程の入口です。システム開発では、要件定義・外部設計・内部設計以降の実装といった工程ごとに契約を分ける進め方があります。IPA（独立行政法人情報処理推進機構）が公開している情報システム・モデル取引・契約書（第二版）でも、発注者と受注者の双方がリスクを評価する機会を確保する観点から、工程ごとに契約を締結する多段階契約と、工程ごとの再見積もりが示されています。この方式を採る場合、工程が変わるたびに作業範囲と成果物を定義し直す必要があり、各工程の入口で SOW（もしくはそれに相当する個別契約の別紙）を作ることになります。

逆に言えば、「全工程を一括契約で発注するのに、SOW が1枚もない」という状態は、範囲の合意が提案書の表現だけに委ねられていることを意味します。社内法務から差し戻されたのであれば、その指摘は妥当です。

SOWと要件定義書・RFP・WBS・契約書の違い

発注担当者が最も混乱するのは、SOW 単体の意味ではなく「手元にある他の書類との関係」です。ここを整理しないまま SOW を読もうとすると、「これは要件定義書と何が違うのか」という疑問で止まってしまいます。

まず、発注プロセスの時系列に並べてみます。

この並びで見ると、SOW は「提案と契約の間」に位置し、要件定義より前にあることが分かります。ここが実務上の重要点です。要件定義の中で範囲が決まると考えていると、範囲の交渉が金額確定後にずれ込みます。

RFP（提案依頼書）との違い

RFP と SOW は、作成主体と時点が異なります。RFP は発注者が作成し、発注者側の期待を示す文書です。対する SOW は、提案を受けた後に双方で確定する、合意された提供範囲を示す文書です。

この違いは実務に直結します。RFP に「操作研修を含むこと」と書いたとしても、提案の過程で研修が範囲外に落ちていれば、合意されたのは SOW の内容です。RFP に書いたから当然含まれる、という前提は成り立ちません。RFP で挙げた要望のうち、どれが SOW に残り、どれが落ちたのかを突き合わせる作業は、押印前に発注者が自分で行う必要があります。

要件定義書との違い

SOW と要件定義書は、答える問いが違います。SOW が答えるのは「どこまでやるか」という範囲の問いで、要件定義書が答えるのは「何をどう作るか」という仕様の問いです。

この順序が崩れると、紛争に発展します。範囲が曖昧なまま要件定義を始めると、要件定義の場が「範囲の交渉」と「仕様の確定」の二重作業になり、どこまでが契約済みの作業なのか誰も説明できなくなります。システム開発では、要件が固まらないまま進行したことを起点に訴訟に至った例が実際にあります。発注者の責任分担が争点になった判例については、要件定義の失敗事例で詳しく整理しています。

なお、成果物としてどの工程でどんなドキュメントが作られるのかを把握しておくと、SOW の成果物欄の妥当性を判断しやすくなります。工程別のドキュメント体系についてはシステム開発の成果物をご覧ください。

WBS（作業分解構成図）との違い

WBS は、合意された作業を実行可能な単位まで分解した管理ツールです。SOW が「合意文書」である一方、WBS は「実行計画」であり、両者は上下の関係にあります。SOW を根拠に WBS を作る、という向きです。

したがって、WBS に書かれているタスクが SOW の範囲を超えている場合、それは契約外の作業がスケジュールに混入していることを意味します。逆に、SOW に書かれた成果物が WBS のどこにも現れていなければ、受注者がその作業を計画に入れていない可能性があります。SOW と WBS の突き合わせは、プロジェクト開始直後にできる実務的なチェックのひとつです。

基本契約書・個別契約書との関係とSOWの法的拘束力

「SOW に法的拘束力はあるのか」は、発注担当者が社内法務から必ず問われる論点です。結論を先に言えば、SOW 単体に拘束力があるのではなく、契約書との結びつき方によって決まります。

典型的な構造は次の4階層です。

ここで確認すべきことは3点あります。

第1に、個別契約書の本文から SOW が引用されているかです。「別紙1（作業範囲記述書）を本契約の一部とする」のような条項があれば、SOW の記載は契約内容として拘束力を持ちます。この引用がなく、提案資料の一部として添付されているだけの場合、参考資料としての位置づけにとどまり、争いになったときの根拠としては弱くなります。

第2に、矛盾したときの優先順位が定められているかです。SOW と要件定義書、SOW と基本契約書の記載が食い違うことは実際に起こります。多くの契約書には「本契約書と別紙の内容が矛盾する場合は本契約書の記載を優先する」といった優先順位条項が置かれますが、その順序が自社に不利になっていないかは確認が必要です。たとえば SOW で詳細に詰めた検収基準が、基本契約書の抽象的な検収条項に劣後する構成になっていると、せっかく詰めた内容が機能しません。

第3に、改訂の手続が定められているかです。SOW は進行中に改訂される前提の文書です。誰が署名すれば改訂が有効になるのか（プロジェクトマネージャー同士の合意で足りるのか、契約締結権限者の押印が必要なのか）が決まっていないと、改訂版の有効性自体が争点になります。

この3点は、法務の専門知識がなくても契約書を検索すれば確認できます。押印前に確認しておくと、社内説明の材料になります。

SOWの記載項目と書き方｜発注側が必ず詰める8項目

SOW の記載項目を網羅的に列挙した解説は多くありますが、十数項目を均等に詰めようとすると現実的には破綻します。限られた時間の中で発注側が優先すべきなのは、揉めたときに自社が損をする順に詰めることです。

その観点で8項目に再編したものが以下です。曖昧な書き方と具体的な書き方の対比を添えます。

このうち、実務で最もトラブルにつながりやすいのが2番目・4番目・6番目です。以下で個別に掘り下げます。

対象外範囲（Out of Scope）の書き方

「対象外」を書くことに心理的な抵抗を感じる発注担当者は少なくありません。わざわざ範囲を狭めることになるのではないか、と考えてしまうためです。しかし実際には逆で、対象外を書かないと「含まれると思っていた」側が無償対応を求め、求められた側が拒否するという対立が生まれます。先に線を引いておくほうが、双方にとって安全です。

書き漏らすと無償対応を期待されやすく、後から追加費用の議論になりやすい典型項目は次のとおりです。

• データ移行：既存システムからのデータ抽出・変換・投入。誰がデータをクレンジングするのかまで書く
• 既存システムの改修：連携先システム側の修正が必要になった場合の扱い
• マニュアル作成：操作マニュアル・運用手順書の作成有無と、作成する場合の対象読者と粒度
• ユーザー教育：現場担当者への操作研修の実施有無、回数、会場・機材の負担
• 本番リリースの立会い：リリース作業そのものと、深夜・休日作業の扱い
• リリース後の軽微修正：検収後に発生した不具合以外の「ちょっとした変更」への対応範囲と期間

書き方としては、「対象外とする作業」の見出しを立てて箇条書きで列挙するのが最も明快です。「本 SOW の対象範囲は第2項に定めるものに限られ、以下の作業は対象外とする。対象外の作業が必要となった場合は、第8項の変更手続に従い別途協議する」のように、対象外の列挙と変更手続への接続を1文で結んでおくと、対象外の作業が発生したときの進め方まで決まります。

検収基準を「測定可能」に落とす書き方

検収基準が「正常に動作すること」としか書かれていない SOW は珍しくありません。この書き方の問題は、何をもって正常と判断するかが人によって変わることです。結果として、検収のタイミングで支払いが止まります。

測定可能な検収基準にするには、少なくとも次の4点を書き込みます。

1. 判定の対象：合意済みテストケースの合格率（原則として全件合格、軽微な不具合の扱いを定義する場合はその基準も）
2. 確認する環境：対象ブラウザ・OS・端末、本番環境か検証環境か
3. 確認の期間：納品後何営業日以内に発注者が確認を完了するか
4. みなし検収の条件：確認期間内に発注者から書面で指摘がない場合、検収が完了したものとみなすか

4番目は発注者にとって不利に見えますが、この条項があることで「発注者が確認しないまま時間が経過してプロジェクトが止まる」状況を避けられます。重要なのは、みなし検収の有無そのものより、確認期間が自社の体制で現実的に守れる長さになっているかです。社内の確認に関係部署の承認が必要なのに、確認期間が3営業日に設定されていれば、実質的に確認せず検収したことになってしまいます。

発注者側の作業と承認期限もSOWに書く

SOW は受注者の作業を定める文書だと受け取られがちですが、発注者側の作業も記載対象です。発注者が担うのは、たとえばマスタデータの提供、既存システムの仕様情報の開示、テスト環境へのアクセス権付与、設計書レビューの回答、関係部署との調整などです。

これらに期限が書かれていないと、プロジェクト終盤でスケジュールが遅れたときに、遅延の原因がどちら側にあるのかを事実で示せなくなります。逆に「発注者はマスタデータを〇月〇日までに提供する」「レビュー回答は提示から5営業日以内とする」と書いてあれば、遅延の所在は明らかになります。

あわせて、発注者側の遅延がスケジュールに与える影響の取り扱いも定めます。「発注者の提供物の遅延により作業が停止した場合、停止期間に応じて納期を延長する」という条項が置かれるのが一般的ですが、延長の算定方法（停止日数と同日数か、再開に要する準備期間を含むか）までは書かれていないことが多いです。ここを確認しておくと、後の交渉が楽になります。

契約形態別のSOWの使い方｜請負契約と準委任契約の書き分け

ここが本記事で最も強調したい点です。SOW に書くべき内容は、契約形態によって変わります。請負契約で使う SOW のテンプレートをそのまま準委任契約に流用すると、意図しない責任を受注者に負わせる解釈を招いたり、逆に偽装請負を疑われる記載を生んだりします。

まず、民法上の建付けを確認します。請負は、当事者の一方が仕事の完成を約し、相手方がその結果に対して報酬を支払う契約です（民法第632条）。つまり、受注者は「完成させる義務」を負います。一方、準委任は委任の規定が準用される契約で、受注者が負うのは委任事務を善良な管理者の注意をもって処理する義務（善管注意義務）であり、仕事の完成そのものは義務ではありません。

この違いが SOW に与える影響を整理すると次のようになります。

請負契約のSOW

請負契約では、「完成」の定義が争点の中心になります。したがって SOW では、成果物の特定と検収基準に最も紙幅を割きます。

加えて確認すべきなのが、契約不適合責任の期間です。2020年4月施行の改正民法では、請負人が種類または品質に関して契約内容に適合しない目的物を引き渡した場合、注文者が不適合を知った時から1年以内にその旨を通知しなければ、履行の追完請求・報酬減額請求・損害賠償請求・契約解除ができないと定められています（民法第637条）。

実務上は、契約書でこの期間を変更する条項が置かれることが多く、「引渡しから6か月」のように期間を短縮する例もあります。SOW の検収基準と、契約書の契約不適合責任の期間はセットで読む必要があります。検収基準を厳格に書いても、不適合責任の期間が極端に短ければ、検収後に見つかった問題への対応を求められません。

準委任契約のSOW

準委任契約の SOW で注意したいのは、成果物を無条件に書き込むと、完成責任を事実上負わせる合意と解釈されうる点です。準委任は仕事の完成を目的としない契約形態ですが、SOW に「〇〇システムを納品する」「〇月〇日までに全機能を完成させる」と書けば、契約書の表題が準委任であっても、合意の実質は請負に近いと読まれる余地が生まれます。これは受注者にとって不利であると同時に、発注者にとっても「契約形態と実態が乖離している」という指摘を受けるリスクになります。

したがって準委任契約の SOW は、次の4点を主軸に構成します。

1. 作業内容：担当する業務領域（例：受発注管理機能の設計・実装支援、技術的助言）
2. 稼働前提：想定する体制（人数・役割）と月あたりの稼働時間、期間
3. 体制：双方の責任者・連絡窓口、受注者側のチーム構成
4. 報告内容：週次・月次の報告頻度と報告する内容（作業実績・課題・次週の計画）

成果物を書く場合は、「作業の過程で作成される資料」として位置づけ、「本作業において作成する資料は以下のとおりとする」のように、納品義務ではなく作業の内容として記述します。完成を保証する表現（「完成させる」「納品する」「〇〇が動作する状態とする」）は避けます。

準委任型の契約では、体制の増減を前提にした運用設計も SOW に書き込む対象になります。秋霜堂株式会社が提供する TechBand は月額制の準委任型契約で、1か月単位で体制の縮小・拡大が可能な設計としており、リリース後の修正は契約を延長することで対応する運用です（出典: TechBand 公式 FAQ、https://syusodo.co.jp/services/techband）。このような体制伸縮を前提とする場合、SOW には「稼働の増減は前月〇日までに書面で通知する」といった手続を定めておくと、体制変更のたびに契約条件を再交渉する必要がなくなります。

偽装請負を招かないための記載上の注意

準委任契約や請負契約で外部の技術者に作業を依頼する場合、記載内容が偽装請負と評価されるリスクに注意が必要です。偽装請負とは、契約の形式は請負・準委任でありながら、実態として発注者が受注者の労働者を直接指揮命令している状態を指します。

労働者派遣と請負のどちらに該当するかは、契約の形式ではなく実態に即して判断されます。厚生労働省は判断の基準として「労働者派遣事業と請負により行われる事業との区分に関する基準」（いわゆる37号告示）を定め、あわせて関係疑義応答集を公開しています。この疑義応答集にはシステム開発業務の取扱いに関する補足説明も含まれており、発注実務の参考になります。

SOW の記載という観点では、次のような内容を書き込まないよう注意します。

• 指揮命令系統：発注者が受注者の作業者に直接作業指示を出す体制（「発注者のプロジェクトマネージャーが受注者の作業者に日次で作業指示を行う」等）
• 始業終業時刻・勤務時間の管理：「作業者は発注者の就業時間に従う」「出退勤を発注者に報告する」等
• 個人指名での作業指示：特定の個人を名指しして作業を割り当てる記載。要員要件はスキル・経験で記述する
• 発注者による勤怠・服務の管理：休暇取得の承認、残業の指示など

代わりに書くべきなのは、双方の責任者を窓口とする連絡体制です。「発注者の指示・要望は発注者側責任者から受注者側責任者を通じて行う」と定め、作業者への具体的な作業配分は受注者側の責任者が行う構成にします。これは契約文言の工夫というより、実際の運用をその形に合わせるためのものです。記載と実態が乖離していれば、記載だけでは守りになりません。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

SOWが曖昧なまま契約すると起きるトラブル

ここまで「書くべきこと」を見てきましたが、裏返して「書かないと何が起きるか」を具体化しておくと、優先順位の判断がしやすくなります。曖昧な SOW が引き起こすトラブルは、大きく3類型に整理できます。

第1は、スコープクリープによる追加費用と工期の延伸です。範囲の境界が決まっていないため、小さな依頼が積み重なり、気づいたときには当初想定を大きく超えた作業量になっています。発注者からすれば「当然含まれる範囲」でも、受注者からすれば「範囲外の追加作業」です。

第2は、検収で揉めて支払いが止まるケースです。検収基準が測定可能でないため、発注者が「これでは使えない」と判断しても、受注者は「仕様どおり納品した」と主張します。支払いが止まると受注者側のキャッシュフローが悪化し、関係が一気に悪化します。

第3は、要件定義段階での紛争化・訴訟です。範囲が確定していない状態で要件定義に入ると、要件が膨らみ続けてプロジェクトが停止します。この類型は実際に訴訟に至っており、発注者側の協力義務の範囲が争点になった判例も存在します。詳しくは要件定義の失敗事例をご覧ください。

重要なのは、これらが「ベンダーが悪い」「発注者が悪い」で起きているわけではないという点です。どちらも合意していないことを合意済みだと思い込んでいた結果であり、押印前に SOW で潰せた問題です。

作業範囲の曖昧さが追加費用に変わるまでの流れ

スコープクリープは、だいたい同じ経路をたどります。

1. 範囲の境界が書かれていないため、グレーゾーンの作業が発生する（例：画面の項目を1つ追加したい）
2. 初回は好意で無償対応される。双方とも「これくらいは」という認識で処理する
3. 無償対応が前例となり、同種の依頼が繰り返される
4. 受注者側の工数が計画を超過し、どこかの時点で「これは範囲外です」と線が引かれる
5. 発注者側は「今までやってくれていたのに」と受け取り、合意の不在が対立として表面化する
6. 追加見積が提示され、予算の追加承認が必要になる。あるいは納期が延伸する

この流れを断つポイントは2番目と3番目です。無償対応そのものが問題ではなく、無償対応したことが記録されず、判断基準が共有されないまま前例になることが問題です。SOW に変更手続が定められていれば、グレーゾーンの作業が発生した時点で「これは変更手続に乗せるか、軽微として処理するか」の判断が行われ、記録が残ります。

契約設計そのものでこのリスクを抑える方法もあります。たとえば秋霜堂が提供する TechBand では追加見積もりは発生せず、仕様変更が生じた場合のスコープ調整をスケジュールで吸収する運用としています（出典: TechBand 公式 FAQ、https://syusodo.co.jp/services/techband）。この設計では「追加費用が出るかどうか」の交渉が発生しない代わりに、「何を後回しにするか」の優先順位判断が発注者側に求められます。どちらの設計が自社に合うかを押印前に理解しておくことが、トラブルの予防になります。

仕様変更が出たときSOWは作り直すのか

プロジェクトが進めば仕様変更は必ず発生します。そのとき SOW をどう扱うかには、実務上3つのパターンがあります。

実務では、1番目で積み重ねて、累積したところで3番目に移行する運用が現実的です。重要なのは、どのパターンを採るかを事前に決めておくことと、版数管理をすることです。SOW が複数版存在し、どれが有効な版なのか分からない状態は、SOW がない状態と大差ありません。

変更手続を実際に回す具体的な進め方については、システム開発の変更管理で仕様変更のステップと要求書の書き方を整理しています。

SOWの作り方とレビュー手順｜押印前のチェックリスト

最後に、発注側の実務に落とします。発注者が SOW に関わる場面は、「ベンダーから提示された SOW をレビューする」ケースと、「自社主導で SOW を作る」ケースの2つです。

ベンダー提示のSOWを押印前に確認する6つのチェックポイント

ベンダーが作成した SOW を受け取ったら、次の6点を順に確認します。各項目に、ベンダーへの確認の仕方も添えます。

1. 作業範囲が機能・工程の単位で特定されているか

「〇〇システムの開発」のような粒度で止まっていないかを見ます。確認の仕方は「この範囲に含まれる機能を、画面または業務プロセスの単位で列挙いただけますか」です。

2. 対象外範囲が明記されているか

対象外の項に、データ移行・既存システム改修・マニュアル作成・ユーザー教育・リリース立会い・リリース後の軽微修正が記載されているかを確認します。記載がなければ「この6項目について、対象／対象外の扱いを明記いただけますか」と依頼します。含まれないこと自体は問題ではなく、書かれていないことが問題です。

3. 検収基準が測定可能か

「正常に動作すること」で止まっていないかを確認します。「検収の合否をどのテスト結果で判断するのか、確認期間は何営業日か、期間内に指摘がない場合の扱いはどうなるかを明記いただけますか」と確認します。あわせて、確認期間が自社の承認プロセスで現実的に守れる長さかを社内で検証します。

4. 変更手続が定められているか

変更要求の提出方法、影響評価の提示期限、承認権限者が書かれているかを見ます。なければ「作業範囲の変更が生じた場合の手続を明記いただけますか。特に、影響評価をいただくまでの期間と、どなたの承認で確定するかを知りたいです」と依頼します。

5. 発注者側の作業と期限が書かれているか

自社が何をいつまでにやる必要があるのかを確認します。書かれていなければ、自社の負担が無限定になっているか、逆に自社の遅延が全面的に自社責任として扱われる可能性があります。「当社側で準備が必要なもの（データ・環境・レビュー回答）とその期限を明記いただけますか」と依頼し、提示された期限が自社の体制で守れるかを必ず社内確認します。ここは発注者側が最も見落としやすい項目です。

6. 契約書との結びつきと優先順位条項を確認する

個別契約書の本文に「別紙（作業範囲記述書）を本契約の一部とする」という引用があるか、矛盾時の優先順位条項がどうなっているか、SOW の改訂手続が定められているかを確認します。契約書の条文を検索すれば確認できる内容なので、法務に相談する前に自分で当たりを付けられます。

この6点を確認した結果を一覧にまとめると、社内法務や購買への説明資料になります。「作業範囲と対象外は明記されており、検収基準に確認期間の記載がないため追記を依頼中」といった形で状況を示せれば、稟議の差し戻しは防げます。

自社でSOWを作る場合の進め方

自社主導で SOW のドラフトを作る場合は、ゼロから書くのではなく、手元の書類から落とし込みます。

ステップ1：RFP と提案書を突き合わせる

RFP で挙げた要望のうち、提案書で触れられているものと触れられていないものを分けます。触れられていないものは、提案の過程で範囲外に落ちた候補です。これを「対象外」に書くか、改めて範囲に入れるかを判断します。

ステップ2：見積書の内訳を範囲に翻訳する

見積書の明細は、ベンダーが想定している作業範囲の反映です。明細にない作業は、ベンダーの想定に入っていません。明細の各行を「作業範囲」の記述に書き換えていくと、抜けが見えます。

ステップ3：成果物と検収基準を社内の受入体制から逆算する

誰がどの成果物を確認し、承認するのかを決めてから、検収基準と確認期間を書きます。社内の承認プロセスを無視して検収期間を書くと、実際には確認できない基準になります。

ステップ4：発注者側の作業と期限を自分で書く

受注者に書かせるのではなく、自社で書きます。自社が守れる期限でなければ意味がないためです。守れない期限であれば、その前提でスケジュールを引き直す必要があります。

ステップ5：法務・購買に確認する

確認を依頼する際は、SOW 単体ではなく契約書とセットで渡し、次の3点を論点として明示します。(1) SOW が契約の一部として引用されているか、(2) 矛盾時の優先順位が自社に不利になっていないか、(3) 契約形態（請負／準委任）と SOW の記載内容が整合しているか。論点を絞って渡すと、確認が早く進みます。

まとめ｜SOWは「何を作らないか」まで書けて初めて機能する

SOWとは、発注者と受注者が作業範囲・成果物・役割分担・合意の手続を契約の一部として確定する文書です。本記事で繰り返してきたのは、SOW の価値が「何を作るか」を書くことではなく、「何を作らないか」「どちらがやるか」「どうやって変更を決めるか」を書くことにある、という点でした。

そして、書くべき内容は契約形態によって変わります。請負契約では成果物と完成の定義、検収基準、契約不適合責任の期間が中心になります。準委任契約では作業内容・稼働前提・体制・報告内容が中心であり、成果物を完成義務と読まれる形で書くことは避けます。どちらの場合も、発注者が作業者に直接指揮命令する体制を SOW に書き込まないことが、偽装請負リスクを避ける前提になります。

手元に契約ドラフトがある方が、明日すぐに確認できることは3点です。

1. 契約書に SOW が別紙として引用されているかを確認する。引用がなければ、SOW の内容は契約上の根拠として弱い
2. 対象外範囲と検収基準の記述を読み直す。対象外が書かれていない、検収基準が「正常に動作すること」で止まっている場合は、追記を依頼する
3. 変更手続条項の有無を確認する。変更要求の出し方・影響評価の期限・承認権限者が書かれていなければ、追記を依頼する

この3点が確認できていれば、「この範囲で本当に大丈夫か」という社内の問いに、根拠を持って答えられます。曖昧なまま押印して1人で責任を背負う状態から、確認すべき点を把握した状態へ移ることが、SOW を使う最大の意味です。

関連情報

業務委託契約の実務でチェックすべき論点を体系的に確認したい方は、フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイドもあわせてご覧ください。契約形態の選び方や発注時に確認すべき項目を整理しています。

外部ベンダーへの発注や開発体制の組み方についてご相談されたい場合は、お問い合わせフォームからお寄せください。作業範囲の整理や契約形態の検討段階からご相談いただけます。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。