開発会社から見積書と契約書のひな形が届いた。金額は予算に収まっている。ところが、打ち合わせで話した「今のExcelのデータを移してほしい」「操作説明を1回してほしい」が、どの書類のどこに書いてあるのか見当たらない。開発会社の担当者からは「詳細はSOWで詰めましょう」と言われたが、SOWが何を指すのか分からない——初めてシステム開発を外注する担当者が、契約の直前に立ち止まりやすいところです。
結論から書きます。
- SOW（Statement of Work、作業範囲記述書）は、開発会社が「どこまでやるか」と、発注者が「何を用意するか」を、契約前に書面で合意するための文書です。見積書が金額の根拠、契約書が権利と責任のルールを示すのに対し、SOWは作業そのものの中身を決めます
- 書類の名前は問題ではありません。「作業範囲」「含まない作業」「発注者側の作業」「成果物」「前提条件」「検収と変更の手続き」の6つが、見積書の別紙や個別契約書のどこかに書かれていれば、SOWの役目は果たせます
- 確認で最も見落とされるのは「含まない作業」と「発注者側の作業」です。データ移行、テスト用データの準備、社内への説明などは、どちらがやるか書かれていないと、後から追加費用か、社内の誰かの残業になります
この記事の表とチェックの順番を使えば、手元の書類に何が欠けているかを確かめ、開発会社に何を書き足してもらうかまで決められます。
SOWとは何か。見積書・契約書・要件定義書とどう違うのか？
SOWは、作業の範囲・成果物・分担・前提条件をまとめた合意文書です。金額の内訳を示す見積書や、権利・責任を定める契約書とは役割が分かれています。
システム開発の発注では、似た書類がいくつも行き交います。役割の違いを並べると次のとおりです。
| 書類 | 主に決めること | 作る人 |
|---|---|---|
| 見積書 | 金額と、その内訳（工数・単価など） | 開発会社 |
| 契約書 | 契約の種類、支払い、権利の帰属、責任の範囲、解除の条件 | 両社で合意（ひな形は開発会社が出すことが多い） |
| SOW（作業範囲記述書） | 開発会社がやる作業、やらない作業、発注者がやる作業、成果物、前提条件、スケジュール | 開発会社が作り、発注者が確認することが多い |
| 要件定義の成果物（要件定義書） | システムに持たせる機能や性能 | 要件定義の工程で両社が作る |
要件定義書は「どんなシステムを作るか」、SOWは「その仕事を誰がどこまでやるか」を書く、と分けると整理しやすくなります。小さな案件では要件定義書が作られず、SOWの中に機能の一覧が入ることもあります。
日本の契約実務では、SOWという書類名が使われないことも多くあります。IPA（情報処理推進機構）と経済産業省が公開している「情報システム・モデル取引・契約書」（第二版、2020年12月22日公開）のひな形にも「SOW」という語は出てきません。その代わり、基本契約の第4条で、個別の業務ごとに「個別契約」で定める取引条件を次のように挙げています。
- 具体的作業内容（範囲、仕様等）
- 契約類型（請負・準委任）
- 作業期間又は納期、作業スケジュール
- 発注者と開発会社の役割分担
- 連絡協議会（定例の打ち合わせ）の運営に関する事項
- 発注者が開発会社に提供する情報、資料、機器、設備等
- 作業環境
- 納入物の明細及び納入場所
- 委託料及びその支払方法
- 検査又は確認に関する事項
この並びが、実質的にSOWの中身にあたります。手元の書類が「個別契約書」「見積書別紙」「作業仕様書」という名前でも、これらがそろっていれば同じ働きをします。
SOWがないと、どこで揉めやすいのか？
揉めやすいのは、作る機能そのものより、その周りの作業です。データ移行、テストの準備、操作説明、サーバーの設定、打ち合わせの回数が、誰の仕事か決まらないまま進むと、後から費用か手間のどちらかで表に出ます。
開発会社の見積もりは、担当者が想定した作業の範囲で積み上げられています。発注者が当然含まれていると思っている作業が、見積もりの前提に入っていないことは珍しくありません。よく起きる食い違いを挙げます。
| 発注者の思い込み | 開発会社側の前提 | 表に出るタイミング |
|---|---|---|
| 今のExcelのデータは移してくれる | データ移行は発注者が行う、または別見積もり | 本番稼働の直前 |
| テスト用のデータは用意してくれる | 発注者が実データに近いデータを提供する | テスト工程の開始時 |
| 社員向けに操作説明をしてくれる | マニュアルの納品のみ。説明会は含まない | 納品の直後 |
| サーバーやドメインの設定も込み | 発注者が契約済みの環境に載せるだけ | 公開の直前 |
| 打ち合わせは必要なだけ開ける | 月2回・1回1時間までを想定 | 要件が固まらず打ち合わせが増えたとき |
どれも、片方が間違っているわけではありません。書面になっていないために、双方が自分に都合のよい前提を持ったまま契約してしまう、という構造の問題です。契約前に「後戻りできない項目」を確かめる手順は発注前チェックリスト（契約・権利・データ・保守）で整理しています。この記事では、そのうち作業範囲の書面をどう読み、どう書き足してもらうかに絞って扱います。
SOWには何を書くのか？
「作業範囲」「含まない作業」「発注者側の作業」「成果物と納品」「前提条件とスケジュール」「検収と変更の手続き」の6項目を押さえれば、中小企業の発注では足ります。
モデル契約が個別契約で定める項目を、発注者が確認しやすい6つにまとめ直すと次のようになります。
| 項目 | 書く内容 | 確認の観点 |
|---|---|---|
| 1. 作業範囲 | 工程（要件定義・設計・開発・テスト・移行・導入支援など）ごとに、開発会社が行う作業 | 見積書の工程名と一致しているか |
| 2. 含まない作業 | 今回の契約では行わない作業 | 打ち合わせで話題に出た作業が、範囲か除外のどちらかに入っているか |
| 3. 発注者側の作業 | 発注者が行う作業と、その期限（資料の提供、テストデータの準備、確認・承認など） | 社内の誰が担当するか決められるか |
| 4. 成果物と納品 | 納品物の一覧（プログラム、ソースコード、設計書、マニュアルなど）、形式、納品場所 | ソースコードと設計書が入っているか |
| 5. 前提条件とスケジュール | 利用者数、対応する端末やブラウザ、既存システムとの連携、作業期間、主な日程 | 前提が変わったときの扱いが書かれているか |
| 6. 検収と変更の手続き | 検収の方法と期間、範囲が変わるときの手続き | 「誰が」「何を見て」完了と判断するか |
この中で特に書き方に差が出るのが、2と3です。次の章で記入例を示します。
成果物の一覧に何を入れておくべきかは、納品の場面から逆算すると決めやすくなります。プロジェクト完了時に受け取るものは納品完了時に受け取るべきもの一覧で一覧にしています。
「含まない作業」と「発注者側の作業」は、どう書けばよいか？
含まない作業は「やらないこと」を作業名で具体的に書き、発注者側の作業には担当と期限を付けます。「その他必要な作業」のような包括的な言い方は、どちらの側にとっても範囲を決めたことになりません。
以下は、社内の受注管理をExcelからWebシステムに移す案件を題材にした記入例です。実際の案件の書類ではありません。自社の業務に置き換えて、どの行が当てはまるかを確かめてください。
記入例：含まない作業
| 含まない作業 | 補足 |
|---|---|
| 既存Excelからのデータ移行作業 | 移行用の取り込み機能は作る。データの整形と取り込みの実行は発注者が行う |
| 社員向けの操作説明会 | 操作マニュアル（PDF）の納品は範囲に含む |
| サーバー・ドメインの契約と費用 | 発注者名義で契約し、開発会社は設定作業のみ行う |
| 稼働後の問い合わせ対応・不具合修正 | 検収後は別途の保守契約で扱う |
記入例：発注者側の作業
| 発注者側の作業 | 担当 | 期限 |
|---|---|---|
| 現在の受注管理Excelと帳票の見本を提供する | 業務担当 | 要件定義の開始時 |
| 画面イメージを確認し、可否を回答する | システム担当 | 提示から5営業日以内 |
| テスト用データ（実データの氏名等を置き換えたもの）を用意する | 業務担当 | テスト開始の2週間前 |
| 受け入れテストを行い、結果を伝える | 業務担当・システム担当 | 納品から10営業日以内 |
発注者側の作業に期限を書くと、開発会社に約束させるだけの書類でなくなります。モデル契約の第8条も、ユーザ（発注者）とベンダ（開発会社）の双方が分担作業を誠実に行い、相手の作業に協力することを定めています。発注者の確認が遅れて納期がずれた場合、その遅れをどう扱うかも、この表があれば話し合えます。
「含まない作業」を書くと、開発会社が後から追加費用を請求しやすくなるのでは、と心配する人もいます。実際には逆で、含まない作業が明記されていれば、発注者は契約前に「この作業も頼みたい」と見積もりに加えるか、社内でやるかを選べます。書かれていないまま進んだ場合のほうが、追加費用の交渉は発注者に不利になりがちです。
開発会社からSOWが出てこないときは、どうするか？
見積書の別紙や個別契約書で同じ内容を出してもらうよう依頼します。それでも出てこなければ、発注者が6項目の表を作り、「この認識で合っていますか」と確認を取る方法があります。
小さな開発会社や個人の開発者では、SOWにあたる書面を作る習慣がないこともあります。その場合でも、次の順番で進めれば、作業範囲を書面に残せます。
- 見積書の工程名・項目名を、作業範囲の表に書き写す
- 打ち合わせのメモから「話題に出たが見積書にない作業」を抜き出し、含まない作業の欄に仮置きする
- 自社で用意するものを、発注者側の作業の欄に書き、期限の案を入れる
- 開発会社に送り、「範囲に入れるもの」「除外でよいもの」を一つずつ回答してもらう
- 回答を反映した表を、見積書の別紙として契約書に添付するか、メールで合意した記録として保存する
手順4の依頼は、次のような書き方で足ります。
お見積もりありがとうございます。契約の前に、作業の範囲について
認識を合わせたく、別添の表をお送りします。
「含まない作業」に仮置きした項目のうち、御社の範囲に入るものが
あれば教えてください。発注者側の作業の期限についても、
ご都合の悪いものがあればご指摘ください。発注の前に自社の要望を整理していれば、この表はすぐに作れます。開発会社に渡す要望の整理の仕方はRFP（提案依頼書）は中小企業に必要かで解説しています。RFP（提案依頼書）を作っていなくても、要望の一覧と打ち合わせのメモがあれば、手順1〜3は進められます。
開発会社の反応も、判断材料になります。範囲を一緒に詰めることを面倒がる、あるいは「やってみないと分からない」とだけ答えて書面化を避ける場合は、契約の後にも同じやり取りが続くと考えておいたほうが安全です。
受け取ったSOWは、どの順番で確認するか？
成果物、含まない作業、発注者側の作業、前提条件、検収、変更の手続きの順に読みます。後になるほど修正が難しく、費用への影響が大きい項目から先に見る、という順番です。
| 順番 | 確認する項目 | 自分に問うこと |
|---|---|---|
| 1 | 成果物の一覧 | ソースコードと設計書は入っているか。将来ほかの会社に保守を頼むときに困らないか |
| 2 | 含まない作業 | 打ち合わせで頼んだつもりの作業が、ここに入っていないか |
| 3 | 発注者側の作業と期限 | 社内の誰がやるか、期限までにできるか |
| 4 | 前提条件 | 利用者数、端末、連携するシステムが、自社の実態と合っているか |
| 5 | 検収の方法と期間 | 何を確認したら完了とするか、確認に使える期間は足りるか |
| 6 | 変更の手続き | 範囲が変わるとき、誰がどの書面で合意するか |
1の成果物は、契約書の権利の条項と一緒に読みます。ソースコードが成果物に入っていても、著作権が開発会社に残る契約であれば、使える範囲が限られることがあります。権利の確認の仕方は、先に挙げた発注前チェックリストの権利の章で扱っています。
5の検収は、検収の期間が短すぎないかを見ます。業務の担当者が通常の仕事をしながら確認するため、数日では試しきれないことがあります。前の章の記入例では「納品から10営業日以内」としましたが、自社の繁忙期と重なっていないかも確かめてください。
契約の後で範囲が変わるときは、どう扱うか？
口頭やチャットで済ませず、変更の内容・費用・日程への影響を書面にしてから合意します。モデル契約は、この書面を「変更管理書」と呼び、記載事項を定めています。
開発が始まると、画面を見てから「やはりこの項目も欲しい」という要望が出るのは珍しくありません。範囲が変わること自体は問題ではありません。問題になるのは、変わったことの記録が残らないまま進むことです。
モデル契約の第37条は、変更を提案された側が、次の事項を書いた変更管理書を相手に渡し、定例の打ち合わせで変更の可否を協議することを定めています。
- 変更の名称、提案の責任者、年月日
- 変更の理由
- 変更に係る仕様を含む変更の詳細事項
- 変更のために費用を要する場合はその額
- 検討期間を含めた変更作業のスケジュール
- その他、作業期間又は納期、委託料、契約条項等に与える影響
中小企業の発注で、この形式どおりの書面を毎回作る必要はありません。ただ、この6点がメールに書かれていれば、後から「その変更はいくらで、納期がどう動いたのか」を説明できます。変更の伝え方と追加費用の考え方は仕様変更・追加要望の正しい伝え方と追加費用の考え方で詳しく扱っています。
SOWを作っておくと、この場面で役に立ちます。要望が出たときに「最初の範囲に入っていたか」を書面で確かめられるため、追加費用の要否で揉める時間が短くなります。
請負と準委任で、SOWの書き方は変わるか？
変わります。請負契約では「何を完成させるか」を成果物の一覧で細かく書き、準委任契約では「どんな作業を、どれだけの時間・頻度で行うか」と報告の方法を書くのが中心になります。
| 契約の種類 | SOWで特に詳しく書く項目 | 書き方の例 |
|---|---|---|
| 請負 | 成果物の一覧と、完成の判断基準（検収の条件） | 「受注登録・一覧・帳票出力の3画面を、受け入れテストの項目表に沿って確認する」 |
| 準委任 | 作業の内容、作業時間の上限、報告の頻度と形式 | 「要件定義の支援として月40時間まで。週1回、決まった事項と未決事項を書面で報告する」 |
1つの案件の中で、要件定義は準委任、設計と開発は請負、というように工程ごとに契約の種類が分かれることもあります。その場合は、SOWも工程ごとに分けたほうが読み違えが起きにくくなります。契約の種類の違いそのものは請負契約と準委任契約の違いで解説しています。
もう一つ、発注者の会社の規模によっては、法律上の書面の義務が関わります。2026年1月1日に施行された中小受託取引適正化法（取適法。旧・下請法）は、資本金や従業員数の区分に当てはまる発注者に、委託の内容や代金の額などを書面または電子メール等で明示することを求めています。プログラムの作成を外注する取引も対象になり得ます。自社が当てはまるかは、公正取引委員会の取適法のページで確認してください。作業範囲を書面にしておけば、この明示の土台にもなります。
まとめ：「含まない作業」の欄を埋めてから契約する
SOWについて押さえたいのは、次の3点です。
- SOWは、作業範囲・含まない作業・発注者側の作業・成果物・前提条件・検収と変更の手続きを決める書面。名前が違っても、この6つがそろっていればよい
- 揉めやすいのは機能の周りの作業。データ移行、テストデータ、操作説明、サーバー設定を、範囲か除外のどちらかに必ず入れる
- 開発会社から出てこなければ、発注者が表を作って確認を取る。範囲が変わるときは、内容・費用・日程への影響を書面で合意する
手元に見積書があるなら、打ち合わせで「お願いした」と思っている作業を3つ書き出し、見積書の項目と照らし合わせてみてください。見積書に見当たらない作業があれば、それが開発会社に「範囲に入りますか」と尋ねる最初の項目です。見積書の金額そのものの読み方は、システム開発の見積書の内訳の見方とあわせて確認すると、範囲と金額の両方から契約前の判断ができます。
