プロジェクトのスコープ定義書（SOW）の書き方｜業務範囲・成果物・前提・制約・除外事項を固める8項目テンプレート

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

「その作業、契約に含まれていると思っていました」——プロジェクトの後半でこの一言が出ると、追加費用や納期をめぐって現場が一気にこじれます。原因のほとんどは、能力でも誠意でもなく、最初に「どこまでやるか」を紙に固めていなかったことにあります。

結論から言えば、この認識ズレを防ぐ最強の道具が スコープ定義書（SOW＝Statement of Work／作業範囲記述書） です。SOWとは、プロジェクトでやること（作業範囲）・やらないこと（除外事項）・成果物・前提・制約・受入基準を1つの文書に明文化し、関係者全員の共通認識をつくるためのドキュメントです。これを立ち上げの早い段階で作り、ステークホルダーの承認を取っておけば、後からの「言った・言わない」をほぼ封じられます。

なぜSOWが効くのか。トラブルの多くは「範囲の境界線があいまい」なところで起きます。SOWは、その境界線を In-Scope（やること）／Out-of-Scope（やらないこと） として言葉にし、成果物と受入基準までセットで固める文書です。つまり「何を・どこまで作れば完了なのか」を全員で先に握るための地図なのです。この記事では、SOWに書くべき8項目を、書き方の5ステップと記入サンプルつきで、今日から自分でドラフトできるように解説します。

そもそもスコープ定義書（SOW）とは？なぜ必要か

SOW（Statement of Work＝作業範囲記述書）とは、プロジェクトで実施する作業・成果物・範囲・スケジュール・条件を明確に定義した文書です。関係者の共通認識をつくり、進行管理・スコープクリープの防止・納期や品質の担保に役立ちます。

SOWの役割は大きく3つあります。第一に 認識合わせ。発注側と受注側、あるいはPMとメンバーの間で「何をどこまでやるか」を先に一致させます。第二に 判断基準づくり。作業の途中で「この依頼は範囲内か外か」を迷ったとき、SOWに立ち返れば答えが出ます。第三に 完了の定義。受入基準を書いておくことで、「どこまで満たせば検収OKなのか」が明確になり、終わりのないプロジェクトを防ぎます。

SOWとプロジェクト憲章・スコープ記述書の違い

SOWは、似た文書と混同されがちです。役割の違いを整理しておきましょう。

文書	作成タイミング	目的	粒度
プロジェクト憲章	立ち上げの最初	プロジェクトの正式承認とPMへの権限付与	ハイレベル（1枚に要点）
スコープ定義書（SOW）	立ち上げ〜計画の入口	作業範囲・成果物・条件を明文化し合意する	詳細（やること／やらないことを具体化）
プロジェクト計画書	計画フェーズ	実行の詳細な計画（WBS・スケジュール・体制）	最も詳細

ざっくり言えば、憲章が「やると決めた」宣言、SOWが「どこまでやるか」の合意、計画書が「どう進めるか」の設計図です。SOWは憲章とWBSの“あいだ”に位置し、範囲の境界線を言語化する役割を担います。

なお、PMBOK系の用語では「プロジェクト・スコープ記述書（Project Scope Statement）」がほぼ同じ役割を果たします。実務では 社内プロジェクトなら「スコープ定義書」、発注・調達を伴う契約文書としては「SOW」 と呼ばれることが多い、と理解しておけば混乱しません。

SOWに書くべき8項目｜テンプレート

SOWに盛り込むべき中核項目は次の8つです。まずはこの型をコピーして、埋めていくところから始めてください。

#	項目	何を書くか
1	背景・目的	なぜこのプロジェクトをやるのか（解決したい課題とゴール）
2	作業範囲（In-Scope）	このプロジェクトでやることを具体的にリスト化
3	除外事項（Out-of-Scope）	あえてやらないことを明記し境界線を引く
4	成果物・納品物	完成時に引き渡すもの（ドキュメント・システム等）の一覧
5	スケジュール・マイルストーン	期間と主要な節目（着手・中間・納品・検収）
6	前提条件	「こうであるはず」という成立の土台（崩れたら見直す）
7	制約条件	変えられない固定枠（予算・納期・技術・体制）
8	受入基準・承認	何を満たせば検収OKか＋承認者・承認日

各項目の書き方のコツ

作業範囲（In-Scope）と除外事項（Out-of-Scope）を必ずセットで

SOWの心臓部が、この2項目です。「やること」と「やらないこと」を対で書くことで、境界線があいまいな作業を「含む／含まない」に振り分けられます。

コツは、判断が割れそうなグレーゾーンほど、あえてOut-of-Scopeに明記することです。たとえば「既存データの移行は行うが、移行後のデータ品質の目視チェックは発注側が実施（本プロジェクトの範囲外）」のように、もめそうな箇所を先回りして言葉にします。これが後の追加要求に対する「フィルター」になります。

前提条件と制約条件を書き分ける

この2つはよく混同されますが、性質が違います。

• 前提条件＝「こうであるはず」という崩れうる仮定。例：「要件は初回レビューで確定する」「発注側の担当者が週2日稼働できる」。崩れたらスコープ・スケジュールの見直しが要る＝リスクの源になります。
• 制約条件＝プロジェクトが変えられない固定枠。例：「予算は500万円以内」「本番リリースは9月末厳守」「既存の認証基盤を使う」。

前提は「今わかっていない・変わりうる」もの、制約は「動かせない」もの、と切り分けると迷いません。前提条件はすべてSOWに書き出しておき、後で「その前提が崩れた」と言えるようにしておきます。

受入基準は“完了の定義”として数値・条件で書く

受入基準（検収条件）とは、成果物を受け入れる前に満たしておくべき条件です。「動けばOK」ではなく、「主要12機能がテスト仕様書どおり動作する」「主要ブラウザ3種で表示崩れがない」のように、判定できる形で書きます。これが完了の定義そのものになり、「どこまでやれば終わりか」の争いを止めます。

SOWを書く5ステップ

1. 目的・背景を言い切る：解決したい課題とゴールを1〜2文で。ここがブレると範囲もブレます。
2. In-Scope／Out-of-Scopeを洗い出す：やることを列挙し、対でやらないことを明記。グレーゾーンを境界線に落とす。
3. 成果物とマイルストーンを紐づける：各成果物がいつの節目で出るかをセットにする。
4. 前提条件・制約条件を書き出す：崩れうる仮定と動かせない枠を分けて列挙する。
5. 受入基準を決め、承認を取る：完了の定義を判定可能な形にし、ステークホルダーの承認でベースライン化する。

記入サンプル｜Webシステム導入プロジェクトのSOW（抜粋）

イメージをつかむため、社内の受発注管理システム導入PJを例に、SOWの中核部分を抜粋します。

項目	記入例
目的	手作業のExcel受発注を廃し、入力工数を月40時間削減する
In-Scope	受注入力・在庫連携・帳票出力の3機能開発／既存データ移行／操作研修1回
Out-of-Scope	会計システム連携／スマホアプリ化／移行後のデータ目視精査（発注側実施）
成果物	要件定義書・設計書・本番環境・操作マニュアル・テスト結果報告書
マイルストーン	8/E要件確定・9/M結合テスト・9/E本番リリース・10/M検収
前提条件	要件は初回レビューで確定／発注側担当が週2日レビューに参加
制約条件	予算500万円以内／本番リリース9月末厳守／既存認証基盤を利用
受入基準	主要3機能がテスト仕様書どおり動作／主要ブラウザ3種で表示崩れなし

「Out-of-Scope」に会計連携やスマホ化を先に書いておくことで、途中で「ついでにこれも」と言われても、追加要求として正式に扱う入口をつくれます。

SOWを作るメリット・デメリット

デメリットの多くは「作って終わりにする」ことに起因します。**SOWは変更管理の起点となる“生きた文書”**であり、正式な変更があればSOWも更新する運用にすれば、形骸化を防げます。

SOW作成でよくある失敗5選

1. In-Scopeだけ書いてOut-of-Scopeを書かない：やらないことを書かないと境界があいまいなまま。グレーゾーンほど除外事項に明記する。
2. 前提と制約を混ぜて書く：崩れうる仮定と動かせない枠が混在し、後で「前提が違った」と言えない。必ず分けて列挙する。
3. 受入基準が「動けばOK」レベル：完了の判定ができず、検収でもめる。数値・条件で判定可能に書く。
4. 承認を取らずに着手する：関係者が目を通していないと「聞いていない」を防げない。次フェーズ前に必ず承認を取る。
5. 作りっぱなしで更新しない：正式な変更が反映されず実態とズレる。変更管理と連動させて更新する。

よくある質問（FAQ）

Q. SOWとプロジェクト憲章はどちらを先に作りますか？ A. 憲章が先です。憲章で「やると決めた」あと、SOWで「どこまでやるか」を具体化します。憲章はハイレベルな承認文書、SOWは範囲の詳細を固める文書、という役割分担です。

Q. SOWとスコープ記述書は違うものですか？ A. ほぼ同じ役割の文書です。PMBOK系では「プロジェクト・スコープ記述書」と呼び、実務の契約・発注文脈では「SOW（作業範囲記述書）」と呼ばれることが多い、という違いだと理解すれば十分です。

Q. 社内プロジェクトでもSOWは必要ですか？ A. 必要です。契約書のような厳密さは不要でも、「やること／やらないこと／成果物／受入基準」を1枚に固めるだけで、社内メンバー間の認識ズレが激減します。費用・支払い条件などは省いて構いません。

Q. どのくらいの分量で書けばいいですか？ A. プロジェクトの規模次第ですが、まずは8項目がA4数枚に収まる粒度で十分です。細かく書きすぎると承認に時間がかかるため、判断の分かれ目になる境界線を優先して具体化してください。

Q. SOWを書いた後に範囲を変えたくなったら？ A. その場でSOWを書き換えるのではなく、変更管理のプロセスに載せます。変更要求として影響（コスト・スケジュール）を評価し、承認されたらSOWを更新する——この順序を守ることでスコープの膨張を防げます。

まとめ｜SOWは「やらないこと」まで書いて初めて効く

スコープ定義書（SOW）は、プロジェクトの範囲をめぐる認識ズレを防ぐための、最初にして最強の合意文書です。押さえるべきポイントは次の3つです。

1. 8項目を型として埋める：背景・目的／In-Scope／Out-of-Scope／成果物／スケジュール／前提／制約／受入基準
2. 「やらないこと」と「完了の定義」を言葉にする：Out-of-Scopeと受入基準こそがSOWの価値
3. 承認を取り、変更管理と連動して更新する：作りっぱなしにせず“生きた文書”として運用する

まずは次のプロジェクトで、「やること」を書いたら必ずその横に「やらないこと」を1行書く——ここから始めてみてください。境界線が言葉になるだけで、後半のトラブルは驚くほど減ります。

SOWで固めた範囲を実際の作業に落とすには「WBSの作り方 完全ガイド｜階層分解の5ステップ」が、決めた範囲を守り続けるには「スコープクリープを防ぐ7つの実践テクニック」と「変更管理プロセスの設計」があわせて役立ちます。SOWの上流にある「プロジェクト憲章の書き方」もどうぞ。