定義
SOW（Statement of Work：作業範囲記述書）とは、ベンダーがクライアントに提供するサービスについて、プロジェクト固有の活動、成果物、スケジュール、および価格を定義した、正式かつ法的に拘束力のある文書です。これは、プロジェクトの成功と支払いの条件を正確に定める運用の青写真となります。
解説
B2Bサービスセクター（ITコンサルティング、エージェンシー、MSPなど）において、SOWは署名する文書の中で最も重要な商業文書です。
提案書が買い手の心をつかむための営業・マーケティング文書であるのに対し、SOWはビジネスを守るためのリスク管理文書です。不適切な提案書は案件を失う原因になるかもしれませんが、不適切なSOWは、利益の出ない終わりのない作業に縛り付けられることで、ビジネスそのものを危うくする可能性があります。
SOWは、スコープクリープ（作業範囲の肥大化）や利益の漏洩（マージンリーク）に対する最大の防御策です。クライアントが「あと一つだけ機能を追加してほしい」と要求してきたとき、プロジェクトマネージャーが「それは素晴らしいですね。では、そのための変更管理（Change Order）を作成しましょう」と指し示すことができる文書こそがSOWなのです。
完璧なSOWに不可欠な構成要素
プロフェッショナルレベルのSOWが商業的に有効であるためには、以下のセクションを含める必要があります。
- プロジェクトの目的: プロジェクトが達成するビジネス目標の概要。
- サービス範囲: ベンダーが実行する具体的なタスク（可能な限り数値化すること）。
- 成果物: 具体的なアウトプット（例：「5画面を含むFigmaプロトタイプ 1式」）。
- スケジュールとマイルストーン: 特定のフェーズがいつ始まり、いつ終わるか。
- 価格と支払い条件: 費用と支払いのトリガー（例：「着手金30%、UAT完了時40%、本番稼働時30%」）。
- 前提条件とクライアントの責任: ベンダーがクライアントに依存する事項（例：「クライアントは第1週までにAPIアクセス権を提供すること」）。
- 除外事項（範囲外）: 含まれないものを明示的に記載。
- 検収基準: 最終的な支払いをトリガーする「完了」の客観的な定義。
SOWと提案書の図解
```mermaid graph LR A[提案書] -->|目的: 説得| B(焦点: なぜ当社を選ぶべきか？) A -->|トーン: マーケティング| C(指標: ROIと価値)
D[SOW] -->|目的: 保護| E(焦点: 具体的に何を行うか？) D -->|トーン: 法的・運用的| F(指標: 成果物とマイルストーン) ```
SOWレビューのための商業的チェックリスト
署名する前に、SOWは以下のテストを通過しなければなりません。
- 「いくつ」テスト: すべての成果物が数値化されているか？（例：「テンプレートを3つデザインする」であり、「テンプレートをデザインする」ではないこと）。
- 「遅延」テスト: クライアントがドキュメントの確認に3週間かかった場合、SOWはスケジュールを保護し、チームが手待ち状態になるのを防げるか？
- 「検収」テスト: クライアントが恣意的に成果物を拒否できないよう、基準は客観的か？
- 「変更」テスト: 変更管理（Change Order）のプロセスが明記されているか？
関連概念
段落を貼り付けてください。リアルタイムでリスクを検出します。
SOWとMSAの違いは何ですか？+
MSA（基本サービス契約）は、すべてのプロジェクトに共通する全体的な法的関係（責任、知的財産権、支払い条件、機密保持など）を規定するものです。一方、SOW（作業範囲記述書）はMSAの下位文書であり、特定のプロジェクトごとの具体的な作業範囲、成果物、スケジュール、価格を定義します。
SOWには法的拘束力がありますか？+
はい。両当事者が署名した時点で、SOWは法的拘束力を持つ契約となり、何を提供し、何に対して支払いを行うべきかを厳密に規定します。
誰がSOWを作成すべきですか？+
営業部門が初期の提案書を作成することはありますが、最終的なSOWは、業務遂行の責任を負うデリバリーチームやプリセールスエンジニアが作成するか、厳密にレビューを行う必要があります。