英語でSOW(作業範囲記述書)を作るよう求められたとき、何をどこまで書けばいいか迷った経験はないだろうか。
SOWは「誰が・何を・いつまでに・いくらで」やるかを明文化する契約関連文書だ。グローバルなベンダー取引では英語が基本になるが、7つのセクション構成さえ押さえれば英語でも問題なく書ける。
この記事では、SOWに必要な7つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに実務で活用できる。
SOWに必要な7つの構成要素
SOW(Statement of Work)は委託作業の範囲・成果物・スケジュール・支払い条件を定義するドキュメントだ。以下の7つが標準的な構成要素になる。
- 基本情報(Document Info)
- プロジェクト概要・目的(Background & Objectives)
- 作業範囲(Scope of Work)
- 成果物(Deliverables)
- スケジュール・マイルストーン(Timeline & Milestones)
- 体制・役割分担(Roles & Responsibilities)
- 支払い条件・前提条件(Payment & Assumptions)
なぜSOWが重要なのか
SOWが曖昧だと「это作業範囲に含まれているはず」という認識齟齬が必ず発生する。スコープ・成果物・除外事項を書面で明確にすることで、追加費用やスケジュール遅延のトラブルを未然に防げる。
「書いていないことはやらない」が国際取引の原則だ。
SOWとRFPの違い
RFP(提案依頼書)は「ベンダーを選ぶため」に発注側が要件を提示する文書だ。一方、SOWは「選んだベンダーと合意するため」に作業内容を確定する文書になる。RFP→提案→ベンダー選定→SOW締結という流れが標準的だ。
RFPの書き方は英語RFP(提案依頼書)の書き方でも確認してほしい。
テンプレートをダウンロード(Word)
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード(Word)
📥 Download English Template (Word)
日本語版テンプレート(コピペOK)
基本情報
| 項目 | 内容 |
|---|---|
| 文書名 | (例:〇〇システム開発 作業範囲記述書) |
| 発注者 | (例:株式会社〇〇) |
| 受注者 | (例:〇〇ソリューションズ株式会社) |
| 契約期間 | (例:2026年7月1日〜2026年12月31日) |
| バージョン | v1.0 |
| 作成日 | YYYY-MM-DD |
| ステータス | Draft / In Review / Signed |
プロジェクト概要・目的
| 項目 | 内容 |
|---|---|
| 背景 | (例:既存の受発注システムが老朽化し、保守コストが増大している) |
| 目的 | (例:受発注システムをクラウドネイティブ構成で刷新し、運用コストを30%削減する) |
| 成功基準 | (例:2026年12月末までに新システムへ全面移行し、既存機能を100%カバーする) |
作業範囲
| 区分 | 内容 |
|---|---|
| 含まれる作業1 | (例:受発注システムの設計・開発・テスト) |
| 含まれる作業2 | (例:既存システムからのデータ移行(顧客・受注・商品マスタ)) |
| 含まれる作業3 | (例:運用チームへの引き継ぎドキュメント作成とトレーニング2回) |
| 除外事項1 | (例:既存システムの改修・バグ修正は本SOWに含まない) |
| 除外事項2 | (例:本番運用開始後の保守・運用は別契約とする) |
| 変更管理 | (例:作業範囲の変更は変更要求書を提出し、双方の書面合意を必要とする) |
成果物
| # | 成果物 | 形式 | 納期 | 受入基準 |
|---|---|---|---|---|
| 1 | 基本設計書 | PDF+編集可能ファイル | 2026年7月末 | 発注者レビューで重大指摘ゼロ |
| 2 | 開発済みシステム一式 | ソースコード+実行環境 | 2026年10月末 | 受入テスト項目の95%以上合格 |
| 3 | データ移行結果報告書 | 2026年11月末 | 移行データの整合性100% | |
| 4 | 運用引き継ぎドキュメント | Wiki+PDF | 2026年12月中旬 | 運用チームの承認 |
スケジュール・マイルストーン
| マイルストーン | 期日 | 完了条件 |
|---|---|---|
| M1:要件確定 | 2026年7月15日 | 要件定義書の双方承認 |
| M2:設計完了 | 2026年7月31日 | 基本設計書の受入完了 |
| M3:開発完了 | 2026年10月31日 | 結合テスト完了・受入テスト開始可能 |
| M4:移行完了 | 2026年11月30日 | 本番環境への移行と整合性確認完了 |
| M5:プロジェクト完了 | 2026年12月19日 | 全成果物の受入完了 |
体制・役割分担
| 役割 | 担当 | 責任範囲 |
|---|---|---|
| プロジェクトオーナー | 発注者:〇〇 | 最終意思決定・予算承認 |
| プロジェクトマネージャー | 受注者:〇〇 | 進捗管理・課題エスカレーション |
| 開発リード | 受注者:〇〇 | 設計・開発の品質責任 |
| 業務担当 | 発注者:〇〇 | 要件確認・受入テスト実施 |
| 週次定例 | 双方 | 毎週〇曜日に進捗・課題を確認する |
支払い条件・前提条件
| 項目 | 内容 |
|---|---|
| 契約金額 | (例:総額〇〇円(税抜)) |
| 支払い方式 | (例:マイルストーン払い。M2完了時30%・M3完了時40%・M5完了時30%) |
| 支払い条件 | (例:請求書受領後30日以内に銀行振込) |
| 前提条件1 | (例:発注者は要件確認の質問に3営業日以内に回答する) |
| 前提条件2 | (例:既存システムのドキュメント・テスト環境は発注者が提供する) |
| 準拠法 | (例:日本法。紛争時は〇〇地方裁判所を第一審の専属的合意管轄とする) |
英語版テンプレート(コピペOK)
Document Info
| Field | Value |
|---|---|
| Document Title | (e.g., Statement of Work: [System Name] Development) |
| Client | (e.g., ABC Corporation) |
| Vendor | (e.g., XYZ Solutions Inc.) |
| Contract Period | (e.g., July 1, 2026 – December 31, 2026) |
| Version | v1.0 |
| Created Date | YYYY-MM-DD |
| Status | Draft / In Review / Signed |
Background & Objectives
| Item | Details |
|---|---|
| Background | (e.g., The existing order management system is aging, and maintenance costs are increasing.) |
| Objectives | (e.g., Rebuild the order management system with a cloud-native architecture and reduce operational costs by 30%.) |
| Success Criteria | (e.g., Complete full migration to the new system by the end of December 2026, covering 100% of existing features.) |
Scope of Work
| Category | Details |
|---|---|
| In Scope 1 | (e.g., Design, development, and testing of the order management system.) |
| In Scope 2 | (e.g., Data migration from the legacy system (customers, orders, product master).) |
| In Scope 3 | (e.g., Handover documentation and two training sessions for the operations team.) |
| Out of Scope 1 | (e.g., Modifications or bug fixes to the legacy system are not included in this SOW.) |
| Out of Scope 2 | (e.g., Post-launch maintenance and operations are covered under a separate contract.) |
| Change Management | (e.g., Scope changes require a change request and written agreement from both parties.) |
Deliverables
| # | Deliverable | Format | Due Date | Acceptance Criteria |
|---|---|---|---|---|
| 1 | High-level design document | PDF + editable files | End of July 2026 | No critical findings in client review. |
| 2 | Developed system | Source code + runtime environment | End of October 2026 | 95%+ pass rate on acceptance test cases. |
| 3 | Data migration report | End of November 2026 | 100% data integrity verified. | |
| 4 | Operations handover documents | Wiki + PDF | Mid-December 2026 | Approval by the operations team. |
Timeline & Milestones
| Milestone | Date | Completion Criteria |
|---|---|---|
| M1: Requirements Sign-off | July 15, 2026 | Requirements document approved by both parties. |
| M2: Design Complete | July 31, 2026 | High-level design accepted. |
| M3: Development Complete | October 31, 2026 | Integration testing complete; ready for UAT. |
| M4: Migration Complete | November 30, 2026 | Production migration and integrity check complete. |
| M5: Project Complete | December 19, 2026 | All deliverables accepted. |
Roles & Responsibilities
| Role | Assigned To | Responsibility |
|---|---|---|
| Project Owner | Client: [Name] | Final decision-making and budget approval. |
| Project Manager | Vendor: [Name] | Progress management and issue escalation. |
| Development Lead | Vendor: [Name] | Quality of design and development. |
| Business Lead | Client: [Name] | Requirements clarification and UAT execution. |
| Weekly Meeting | Both | Review progress and issues every [day of week]. |
Payment & Assumptions
| Item | Details |
|---|---|
| Contract Amount | (e.g., Total of $XXX,XXX (excluding tax)) |
| Payment Schedule | (e.g., Milestone-based: 30% at M2, 40% at M3, 30% at M5.) |
| Payment Terms | (e.g., Bank transfer within 30 days of invoice receipt.) |
| Assumption 1 | (e.g., The client responds to requirement questions within 3 business days.) |
| Assumption 2 | (e.g., The client provides legacy system documentation and a test environment.) |
| Governing Law | (e.g., Japanese law. Disputes are subject to the exclusive jurisdiction of the [City] District Court.) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいセクションを解説する。
作業範囲(Scope)の書き方
スコープで最も重要なのは除外事項(Out of Scope)だ。「含まれる作業」だけ書くと、書いていない作業の扱いで必ず揉める。除外事項を明記することで認識齟齬を防げる。
| 日本語 | 英語 |
|---|---|
| 〇〇は本SOWの範囲に含まれます | [Work] is included in the scope of this SOW. |
| 〇〇は本SOWの範囲外です | [Work] is out of scope for this SOW. |
| 範囲の変更は書面合意が必要です | Scope changes require written agreement. |
| 〇〇は別契約で対応します | [Work] will be covered under a separate contract. |
| 前提条件が満たされない場合、納期を再調整します | If assumptions are not met, the timeline will be adjusted. |
受入基準の書き方
成果物には必ず「受入基準(Acceptance Criteria)」を数値で設定する。「高品質なシステム」のような曖昧な表現はトラブルの元になる。
| 日本語 | 英語 |
|---|---|
| 受入テストの95%以上に合格すること | Pass at least 95% of acceptance test cases. |
| 重大な不具合がゼロであること | No critical defects remain open. |
| 発注者の書面承認をもって受入完了とする | Acceptance is complete upon written client approval. |
| 受入期間は納品後10営業日とします | The acceptance period is 10 business days after delivery. |
| 期間内に指摘がない場合、受入完了とみなします | Deliverables are deemed accepted if no issues are raised within the period. |
スコープの認識齟齬を防ぐフレーズはエンジニアの英語スコープ管理術でも確認してほしい。
SOWでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
SOW・契約の基本用語
| 日本語 | 英語 |
|---|---|
| 作業範囲記述書 | Statement of Work (SOW) |
| 作業範囲 | Scope of Work |
| 除外事項 | Out of Scope / Exclusions |
| 成果物 | Deliverables |
| 受入基準 | Acceptance Criteria |
| マイルストーン払い | Milestone-based Payment |
| 前提条件 | Assumptions |
| 変更要求 | Change Request |
| 準拠法 | Governing Law |
ベンダーとの確認・交渉フレーズ
| 日本語 | 英語 |
|---|---|
| SOWのドラフトを送付します | I’m sending over the draft SOW for your review. |
| この作業は範囲に含まれていますか | Is this work included in the scope? |
| 除外事項を明記してください | Please specify the exclusions explicitly. |
| 受入基準について合意が必要です | We need to agree on the acceptance criteria. |
| 双方署名のうえ作業を開始します | Work will begin once both parties have signed. |
ベンダーとの交渉フレーズはエンジニアの英語ベンダー交渉術でも参考にしてほしい。
まとめ:英語SOWは7つのセクションと「除外事項」で完成する
英語SOWに必要な構成要素を整理した。
- 作業範囲は「含まれる作業」と同じ熱量で除外事項を明記する
- 成果物には「形式・納期・受入基準」を数値でセットにする
- マイルストーンと支払い条件を連動させ、双方のリスクを分散する
- 前提条件で「発注者側の協力義務」も明文化する
テンプレートをコピーして、案件の規模や契約形態に合わせて項目を追加・削除してほしい。特に除外事項と受入基準の2点を明確にすることで、国際取引のトラブルを大幅に減らせる。


コメント