業務範囲書の作成方法（例文・テンプレート付き）

ある人にとっては、それは5ページの文書とすっきりとしたレイアウトを意味します。また別の人にとっては、ブログの移行、新しいランディングページ、コピーの更新、そして数ヶ月前から作り直したいと思っていたロゴを意味します。

業務範囲定義書があれば、その問題を解決できます。これには、プロジェクトで何が成果物として提供されるか、仕事がどのように行われるか、各部分の納期はいつか、何が承認されたものとみなされるか、そして契約の範囲外となるものは何かが明確に定義されています。

その明確さは、見た目以上に重要です。スタンディッシュ・グループの「CHAOSレポート」によると、予定通りに、かつ範囲内で完了するプロジェクトはわずか約31％にとどまることが明らかになりました。

ここで気まずい事実を指摘しておきます。こうした不一致のほとんどは、規律の問題ではありません。それは「ファイル管理」の問題なのです。業務範囲（SOW）に署名し、電子メールで送信し、ファイルに保管すると、その瞬間から、実際の仕事内容との乖離が生じ始めます。3週目になる頃には、文書には5ページと記載されているのに、実際のプロジェクトは15ページ分になっており、その乖離がどこで生じたのか、誰も特定できなくなってしまいます。解決策は、SOWを長くすることではありません。記述された仕事内容と常に接続し続ける業務範囲（SOW）を作成することです。

このガイドでは、見積もり、プラン、業務割り当て、承認、そしてキックオフ後の管理を行うのに十分な明確さを備えた業務範囲書の作成方法をご紹介します。

「業務範囲」とは何か？

作業範囲定義書（SOW）とは、プロジェクトで何を、どのように、いつまでに成果物として提供し、何が「完了」とみなされるかを明確に定義した文書です。これにより、クライアント、ベンダー、社内チームといったすべての関係者が、プロジェクト開始前に成果物について合意できるよう、作業範囲が明確に定められます。

その役割は、関係者の認識を一致させることです。SOWでは、目的を明記し、成果物をリスト化し、それらをタスクに分解してタイムラインに紐付け、各成果物がどのように完了とみなされるかを定めます。疑問や変更が生じた際、誰もが参照する基準となるのがSOWです。だからこそ、SOWはプロジェクト管理の基盤としても機能するのです。

「業務範囲（Scope of Work）」と「業務明細書（Statement of Work）」の違いとは？

「スコープ・オブ・ワーク（SOW）」は「やること」を定義するものであり、「ステートメント・オブ・ワーク（SOW）」は「両当事者がどのように協力してそれを行うか」を定義するものです。両者は同じ頭字語「SOW」を共有しており、しばしば同じ意味で使用されますが、その役割は異なります。

3つ目の類似用語として「プロジェクトの範囲（project scope）」があります。これは、仕事や仕事上の関係ではなく、プロジェクトそのものの境界、つまり何が含まれ、何が含まれないかを定義するものです。

実際には、ステートメント・オブ・ワーク（Statement of Work）が包括的な契約書であり、作業範囲（Scope of Work）はその中の、成果物を具体的に規定するセクションです。プロジェクトの範囲とは、これら両方の文書が記述するプランのことです。ステークホルダーから「SOW」と求められた場合、相手がどちらを指しているのか10秒ほど確認する価値があります。なぜなら、法的条件や支払い条件は「ステートメント」に規定されており、「作業範囲」には含まれていないからです。

業務範囲には何が含まれるのか？その中核となる要素

完全なSOWがあれば、仕事の理解、見積もり、プラン、承認が容易になります。重要な要素を一つでも見落とすと、後々混乱を招く余地が残ってしまいます。

以下に、記載すべき項目を挙げます：

仕事範囲の種類にはどのようなものがあるか？

作業範囲の定義は、通常4つの構造に分類されます。どの構造が適切かは、プロジェクトの予測可能性、成果物をどれだけ明確に定義できるか、そして双方がどのようなリスクを負う用意があるかによって異なります。

作業範囲をめぐる紛争の多くは、文書構成と実際の作業内容が一致していないことから生じます。成果物ベースのSOWは、固定されたウェブサイト構築には有効ですが、調査や戦略策定、ステークホルダーとの調整が必要なプロジェクトではリスクを伴う可能性があります。まだ成果物を具体的に挙げられない場合は、SOWの中で挙げられるふりをしないでください。不確実性を反映した構成を採用しましょう。

業務範囲書の作成方法（ステップバイステップの手順）

SOWを作成するには、目的を定義し、成果物と非成果物をリスト化し、それらをタスクに分解し、依存関係を含むタイムラインを設定し、受入基準を策定し、前提条件と変更管理プロセスを明記した上で、コストを追加し、承認を得ます。これら7つのステップにより、プロジェクトはキックオフから完了へと進みます。実際の運用では：

ステップ1：目的と成功基準を定義する

まずは、その仕事が存在する理由と、望ましい成果像から始めましょう。これがSOW全体の基盤となります。目的が曖昧であれば、成果物、タイムライン、承認プロセスも曖昧になってしまいます。

クライアントにも理解できる1～2文で目的を記述してください。「ブランドの認知度向上」や「マーケティング活動のサポート」といった社内用語や曖昧な表現は避け、その仕事がもたらす明確なビジネス成果と結びつけてください。

例えば：

次に、成功基準を追加します。特にクリエイティブなプロジェクトや、調査・検討の割合が高いプロジェクトの場合、必ずしも厳格なKPIである必要はありません。しかし、仕事が目的を果たしたかどうかを双方がどのように判断できるかを明確に説明する必要があります。

ステップ2：成果物と非成果物をリストアップする

次に、クライアントが受け取るすべての成果物を明記します。具体的かつ数値化可能で、率直な表現を心がけてください。

「管理する」「サポートする」「対応する」「最適化する」といった曖昧な動詞は、その具体的な内容を定義しない限り使用を避けてください。こうした言葉は提案書では有用に聞こえますが、SOW内ではスコープクリープの余地を生み出してしまうからです。

例：

より説得力のあるバージョンでは、クライアントに対して、何が提供されるのか、その量はどれくらいか、そして範囲の境界線がどこにあるのかを明確に伝えます。そして、同じセクションに「提供対象外事項」をリストします。ここでは、たとえ自分にとっては当然のことだと思えても、仕事に含まれない内容を具体的に明記する必要があります。

ブログプロジェクトの場合、成果物に含まれないものには次のようなものがあります：

ステップ3：成果物をタスクに分解する

各成果物をリストアップしたら、簡単なテストを行ってみてください：この行から、誰かが明日から仕事を開始できるでしょうか？

もし「いいえ」という答えなら、まだ範囲が広すぎます。

成果物を一つずつ取り上げ、動詞＋目的語のフォーマットを用いてタスクレベルの行動に分解してください。例えば、「ホームページのワイヤーフレームを作成する」、「法的文言を確認する」、「最終デザインを承認する」、あるいは「ブログ記事をCMSにアップロードする」などです。「ウェブサイトの仕事」、「コンテンツサポート」、「デザインの更新」といった曖昧なタスク名は避けてください。これらは誰が何を担当するのかが明確になりません。

ブログ記事の成果物（月4本のSEOブログ記事）の場合、タスクの内訳は次のようなものになるでしょう：

このタスク層は、成果物の背後にある実際の作業負荷を明らかにします。また、どこで遅延が発生しうるかも示しています。クライアント側の専門家（SME）が草案を期限内に確認しない場合、エディター、SEOスペシャリスト、コンテンツマネージャーの作業がすべて遅れてしまいます。こうした依存関係は、プロジェクト開始前に把握しておく必要があります。

大規模なプロジェクトでは、作業分解構成（WBS）を活用しましょう。これは、作業をフェーズごとにグループ化し、各フェーズを割り当てられたタスクに細分化することです。例えば、ウェブサイトのリニューアルでは、要件定義、サイトマップ、ワイヤーフレーム、コピー作成、デザイン、開発、品質保証（QA）、分析ツールのセットアップ、公開といったフェーズが含まれる場合があります。各フェーズは、所有者、期日、承認ポイントを明確にしたタスクレベルの作業に落とし込む必要があります。

このタスクマップは、以下のツールで作成できます：

ステップ4：タイムライン、マイルストーン、および依存関係の設定

次に、タスクリストをタイムラインにまとめましょう。開始日、終了日、主要なマイルストーン、および納期に影響を与える可能性のある依存関係を追加してください。

単に「プロジェクトの納期は6週間後」と書くだけでは不十分です。タイムラインを「要件定義」「初稿作成」「レビュー」「修正」「最終承認」「リリース」といったフェーズに分割しましょう。そして、どのマイルストーンが支払い、承認、または次の仕事フェーズのトリガーとなるかを明記してください。

例：

最も重要なのは、依存関係、特にクライアント側の依存関係を明確にすることです。プロジェクトの遅延の多くは、実際の仕事そのものに起因するものではありません。フィードバックの遅れ、ログイン情報の未提供、法務審査の遅延、関係者の不在、あるいはチームが仕事を開始した後に資産が提供されることなどが原因となっています。

仕事開始前に、これらを明確に定めておきましょう。

例：「プロジェクトのタイムラインは、クライアントからのタイムリーなフィードバック、必要なツールへのアクセス、および承認済みのブランドアセットの納品に依存します。フィードバック、承認、アクセス、または資料の提供に遅れが生じた場合、プロジェクトのタイムラインは、その遅延日数と同数の営業日分、ずれ込む可能性があります。」

ステップ5：すべての成果物について受け入れ基準を作成する

各成果物について、何が「承認済み」とみなされるかを明確に定義してください。この条項こそが、プロジェクトが「あと少し」という状態の修正の無限ループに陥るのを防ぐ鍵となります。

基準は、実際に確認可能な項目に結びつけてください。ウェブサイトの移行の場合、「公開準備完了」とは、リダイレクトのテストが完了し、アナリティクスが正常に動作し、お問い合わせフォームが機能し、承認済みのページがデスクトップとモバイルの両方で正しく表示されることを意味するかもしれません。一方、営業用プレゼン資料の場合、その意味は全く異なるものになる可能性があります。

「クライアントは仕事に満足している」といった、単なる主観に依拠した承認表現は避けてください。より適切な表現としては、次のようなものが挙げられます：

「成果物は、合意された基準を満たし、承認済みの修正作業を含み、かつクライアントからの書面による承認を得た時点で、受領されたものとみなされます。」

これにより、双方にとって明確な合意点が得られます。その後も新たな要望が生じる可能性はありますが、それらは当初の範囲を拡大するものではなく、変更依頼として扱われます。

ステップ6：前提条件、除外事項、および変更管理プロセスを明記する

ここで、プロジェクトが知らず知らずのうちに規模が拡大してしまうのを防ぎます。

前提条件

対象外事項

変更管理プロセス

この最後の点が最も重要です。ベンダーがまず追加の仕事を完了させてから、後で支払いの話し合いを行うような場合、変更依頼を履行させるのがはるかに難しくなります。

ステップ7：費用、支払い条件、承認事項を追加する

SOWの最後には、総額、請求体系、支払スケジュール、支払期日、支払遅延時の条件、および仕事の承認権限を持つ担当者といった商業条件を明記してください。

可能な限り、支払いを明確なマイルストーンに紐づけてください。例えば：

継続的な仕事については、月額の固定報酬、請求日、仕事範囲、およびクライアントが合意された時間数や成果物を超えた場合の対応について明記してください。

その後、書面による承認を得てください。承認されていないSOWは単なる作業草案に過ぎません。署名を行うことで、仕事開始前に、成果物、タイムライン、除外事項、支払い条件、変更手続きについて双方が合意していることが確認されます。

すぐに使えるこのテンプレートを使えば、数分でSoWを作成できます

ClickUpの「業務範囲（SOW）テンプレート」を使えば、プロジェクトの詳細、成果物、責任範囲、タイムライン、変更管理、予算、承認プロセスを1か所にまとめて記録できる既製のドキュメントが利用できます。SOWをプロジェクトのワークフローに組み込みたい場合に役立ちます。

無料テンプレートを入手する

このテンプレートを使う理由：

• 背景や目標、成果物、ベンダーの責任、クライアントの責任、タイムライン、コミュニケーションプラン、変更管理、予算、承認手続きなど、SOWの主要なセクションを最初から明確に整理しましょう。
• SOWを関連するClickUpの場所とリンクさせ、文書が実際のプロジェクトに接続されるようにします。
• 「リスト」、「ガントチャート」、「作業量」、「カレンダー」など15種類以上のカスタムビューを活用し、作成したスコープを、所有者、日付、依存関係が明確な、進捗管理可能な作業計画に変換しましょう。
• プロジェクトの進行に合わせて、承認の進捗状況、作業範囲の変更、予算の詳細、および関係者の責任を追跡するために、カスタムフィールドやステータスを追加できます。

業界別の仕事範囲例

SOWには、業界を問わず共通する主要なセクションがあります。具体的には、目的、成果物、タイムライン、前提条件、除外事項、受入基準、支払い条件、および承認です。

変化するのは「リスク」です。

ウェブサイトプロジェクトの失敗要因としては、通常、ページ数、修正回数、CMSの所有権、公開後のサポートなどが挙げられます。一方、建設工事の範囲定義における失敗要因としては、許可、現場の状況、検査、資材の変更などが挙げられます。

以下の例は、ご自身の業務範囲の形を定めるための指針としてご利用ください。契約書をそのまま書き写すためのものではありません。

クリエイティブエージェンシーやウェブサイトのリデザインにおけるSOW

ウェブサイトの仕事におけるリスクは、隠れた作業量です。SOWに特に記載がない限り、クライアントは、コピー作成、SEO移行、新規ページの作成、ストックフォト、カスタムグラフィック、CMSへのアップロード、公開後のサポートなどがすべて含まれていると想定してしまう可能性があります。

内容：

除外項目：

SOWのサンプル文例：

「ベンダーは、承認済みのサイトマップに基づき、8ページのウェブサイトを設計・開発する。各ページにつき最大2回の修正ラウンドが認められる。コピーライティング、ストック画像のライセンス取得、追加ページの依頼、SEO移行、および公開後のメンテナンスは、書面による変更依頼を通じて承認されない限り、本契約の対象外とする。」

建設業向けSOW

建設におけるリスクは、「建設」という言葉が建設そのもの以外のすべてのことまで含んでいると想定してしまう点にあります。許可、検査、現場へのアクセス、天候による遅延、資材費の高騰、所有者主導の設計変更などについては、明確に規定する必要があります。

内容：

除外項目：

SOWのサンプル文例：

「請負業者は、承認済みの図面および仕様書に基づき、現場の準備、骨組み工事、電気設備の粗配線、および仕上げ工事を完了するものとします。許可申請手数料、所有者からの変更依頼、予期せぬ現場の状況、および資材のグレードアップは対象外となり、変更指示書を通じて処理されるものとします。」

ソフトウェアまたは製品開発のSOW

ソフトウェア開発におけるリスクの一つは、機能の記述が曖昧であることです。「ダッシュボードを構築する」という表現は、ステークホルダー10人いれば10通りの意味に解釈される可能性があります。機能、テスト条件、環境、統合作業の責任範囲、およびリリース後のサポート期間を明確に定義してください。

内容：

除外項目：

SOWのサンプル文例：

「ベンダーは、付録Aに記載されたユーザーストーリーを開発し、クライアントによるレビューのためにステージング環境にデプロイする。付録Aに記載されていない機能、サードパーティのサブスクリプション料金、履歴データのクリーンアップ、および保証期間終了後のサポートは、変更依頼を通じて承認されない限り、本契約の対象外とする。」

マーケティングキャンペーンのSOW

マーケティングにおけるリスクは、成果物と成果を混同してしまうことにあります。キャンペーン戦略、資産、レポート作成、ローンチサポートなどの範囲を明確に定義することは可能です。ただし、ベンダーがメディア予算、ランディングページ、営業フォローアップ、追跡セットアップを管理していない限り、見込み客数、売上、CAC（顧客獲得単価）、ROAS（広告費用対効果）を約束することには注意が必要です。

内容：

除外項目：

SOWのサンプル文例：

「ベンダーは、キャンペーン戦略、3つの広告クリエイティブ案、ランディングページのコピー、2通のマーケティング電子メール、およびパフォーマンスレポート作成用ダッシュボードを提供する。有料メディアの広告費、インフルエンサーへの報酬、追加のクリエイティブバリエーション、および販売フォローアップは対象外とする。パフォーマンス目標は、承認済みの予算、追跡、およびキャンペーン管理と個別に紐付けられていない限り、あくまで目安とする。」

コンサルティングまたはリテーナー契約のSOW

リテーナー契約におけるリスクは、キャパシティが不明確であることです。SOW（業務範囲定義書）で作業時間、対応時間、ミーティングの頻度、および繰り越しルールを明確に定義しておかない限り、「継続的なサポート」は、無制限の問い合わせ、戦略立案、実行、レポート作成、さらにはその場限りの依頼へと発展してしまう可能性があります。

内容：

除外項目：

SOWのサンプル文例：

「ベンダーは、月あたり最大20時間のコンサルティングサポートを提供します。これには、週1回のアドバイザリーコール、合意済みの資料に対する非同期でのレビュー、および月次推奨事項の要約が含まれます。未使用の時間は翌月に繰り越されません。新規プロジェクト、当日依頼、および20時間を超える仕事については、書面による承認が必要となります。」

どの業界においても有効な手法は同じです。成果物を洗い出し、共通の前提条件を明確にし、後で依頼される可能性が最も高い事項について除外事項を明記することです。

考え方を変えよう：SOWは「提出済みのPDF」ではなく、「仕事の指針」として捉えよう

今や、その傾向は明らかです。署名済みのPDFだけでは、変化し続けるプロジェクトの進捗を追跡することはできません。したがって、真の課題は「より良いSOWの書き方」ではなく、「署名後のSOWがどのような役割を果たすか」という点にあるのです。

これを「1つ」ではなく「2つ」として捉えてください。署名済みの契約書は、当初双方が合意した内容の記録である「ベースライン」として固定されます。一方、その周囲の仕事（タスク、所有者、タイムライン、承認、予算、リスク、変更依頼など）は常に動的な状態を維持します。この2つが接続されていれば、新たな依頼がこっそりと無料の仕事になることはなく、ベースラインに対して「変更」として明確に反映されることになります。

その違いは以下の通りです：

署名済みのSOWは、何か変更があるたびに安易に編集すべきではありません。これは「仕事の拡散」という問題の縮図であり、更新内容がDMに送られ、SOWは別の文書にあり、タスクリストはまた別の場所に存在してしまうような状況です。

そこで、ClickUpのようなツールが役立ちます。SOWを、タスク、コメント、承認、期限、予算といった情報と併せて管理することができます。

この短いClickUpのClipでは、その具体的な内容や、チームがどのようにそれをまとめ上げているかが紹介されています。

ベストプラクティス：常にオリジナルバージョンを安定した状態に保ち、変更は明確な変更ログまたは承認済みの変更依頼を通じて管理してください。例えば、キャンペーン中にクライアントからランディングページを2つ追加してほしいと依頼があった場合、その依頼を単にプロジェクトボードに追加するだけではいけません。スコープの変更として記録し、コストやタイムラインへの影響を精査した上で、書面による承認を得てから、作業プランに追加する必要があります。

ClickUpで作業範囲を管理する方法

SOWは、文書、タスク、承認、タイムラインが接続されている方が管理しやすくなります：

ClickUp Docsを使用して、仕事が行われる場所でSOWを作成しましょう

ClickUp DocsでSOWの作成を始めましょう。このドキュメントを使用して、目的、成果物、対象外事項、タイムライン、検収基準、支払い条件などを記録できます。その後、プロジェクトが進むにつれて、このドキュメントは、それが管理するタスクやマイルストーンと接続した状態を維持できます。

例えば、ウェブサイトのSOWにおける「成果物」のセクションでは、ホームページのコピー作成、ワイヤーフレーム、デザインレビュー、開発、QA、最終承認といった各タスクがリンクされています。これにより、プロジェクトの進行中にSOWを参照しやすくなります。

成果物をClickUpタスクやサブタスクに変換する

SOWの作成が完了したら、ClickUpタスクを使って、各成果物をタスクまたはサブタスクのグループに変換しましょう。

例えば、「3つのランディングページ」という項目は、ページごとに個別のタスクに分割できます。各ページには、コピー作成、デザイン、開発、レビュー、QA、承認といったサブタスクを設定できます。

これにより、チームは各成果物の背後にある実際の仕事内容を把握できるようになります。また、黙って仕事範囲が拡大してしまうリスクも軽減されます。もしタスクリストに4つ目のランディングページが追加されたとしても、当初のSOWと一致しないため、すぐに気づくことができます。

リアルタイムのダッシュボードで進行中の作業範囲を監視

ClickUpのダッシュボードは、複数のSOWを同時に管理する際に役立ちます。

代理店、請負業者、または運用チームは、ダッシュボードを活用して、承認遅延、クライアントごとの仕事状況、今後のマイルストーン、未処理の変更依頼、作業量、予算の動向などを追跡できます。これにより、スコープに関するリスクが利益率の問題に発展する前に、早期に把握しやすくなります。

例えば、3件のクライアントプロジェクトがフィードバック待ちの状態にある場合、ダッシュボードを使えば、個別のタスクリストの中に埋もれさせることなく、アカウントごとの遅延状況をひと目で把握できます。

ClickUpのダッシュボードは、当社のエージェンシーにおける日々の業務運営のあり方を一変させました。3つの開発チームのキャパシティを監視し、遅延につながる前に障害要因を特定できるため、Slackのスレッドでステータスを確認するのに費やす時間を削減し、クライアントの仕事を実質的に前進させることに、より多くの時間を割けるようになりました。

ClickUp Brainを使って、草案の作成、要約、文脈の確認を行えます

ClickUp Brainは、プロジェクト概要からSOWの草案を作成したり、長時間のクライアントとの通話内容を要約したり、メモをスライドに変換したり、タスク、ドキュメント、チャット、連携されたワークスペースのチームデータを活用して質問に回答したりすることができます。

SOWに関しては、次のような質問をすることができます：

また、Brainは、自社のプロジェクト、ドキュメント、社員、会話、知識を基盤に構築されたAIを活用し、この文脈主導型のアプローチをさらに拡張しています。

スーパーエージェントに定期的なスコープチェックを任せてみましょう

プロセスがすでに定義されていれば、「スーパーエージェント」はさらに役立ちます。

例えば、チームはエージェントを設定して、毎週のスコープレビューの準備、承認遅延案件の要約、スコープステータスが未設定のタスクのフラグ付け、あるいはマイルストーンミーティング前のクライアント向け進捗報告書の草案作成などを行わせることができます。

具体的な活用例としては、次のようなものがあります：

「毎週金曜日、このクライアントプロジェクトに関して、未処理の変更依頼、今週追加されたタスク、承認が遅れている事項、およびリスクのあるマイルストーンをすべて要約してください。」これにより、プロジェクトマネージャーはより迅速にレビューを行うことができます。ただし、これは正式な承認に代わるものではありません。追加作業については、作業範囲に組み込まれる前に、依然として書面による承認が必要です。

避けるべき仕事範囲定義書のよくある間違い

作業範囲を「生き生きとしたシステム」にしましょう

優れたSOWは、3倍の価値をもたらします。作成過程で、曖昧な部分を具体的に明確化できます。プロジェクトの進行中、紛争がエスカレートする前に解決できます。そして、スコープクリープが発生した際、変更内容を可視化することで、見過ごされてしまうのを防ぎます。

しかし、その価値を最大限に活かすには、1つの条件があります。それは、その文書が受信トレイの中で埋もれてしまわないことです。

この文書を最大限に活用しているチームは、スコープを「生き物」のように扱っています。つまり、事前に明確に定義し、実際のタスクと接続し、仕事の進展に合わせて改訂していくのです。7つの構成要素を網羅し、すべての成果物を定量化し、対象外事項を明記し、文書が記述する仕事と常に密接に接続された状態を保ちましょう。

これを実践する最も手っ取り早い方法は、テンプレートをベースにして、それをプロジェクトに接続することです。ClickUpを無料で使い始め、DocsでSOWテンプレートをカスタムし、各成果物をそれを実現するタスクにリンクさせましょう。

仕事範囲に関するよくある質問

「業務範囲」と「プロジェクトの範囲」の違いは何ですか？

業務範囲（Scope of Work）とは、特定の契約やフェーズにおける成果物やタスクを明記した文書です。一方、プロジェクトの範囲（Project Scope）とは、プロジェクトの全範囲、つまり含まれるものと含まれないものをすべて定義する、より広範なプラン概念です。要するに、業務範囲は仕事の一部を記述するものであり、プロジェクトの範囲は、その仕事が収まる全体的な枠組みを記述するものです。

業務範囲とマスターサービス契約（MSA）の違いは何ですか？

MSA（マスターサービス契約）は、クライアントとベンダー間の継続的な関係を規定する包括的な法的および商業的条件を定めるものであり、業務範囲（SOW）は、その下にある特定のプロジェクトにおける成果物を定義するものです。一般的な階層構造としては、最上位にMSAがあり、その下に個別の業務明細書（SOW）が配置され、各業務明細書の中に業務範囲が組み込まれています。MSAは一度締結され、各案件ごとに新しいSOWが発行されます。

仕事範囲にはどのような4つの種類がありますか？

一般的な契約形態には、成果物ベース（特定の成果物に対して支払いが行われる）、時間・材料費ベース（仕事の進行に合わせて時間とコストを請求する）、努力ベース（一定期間における定額のキャパシティ、リテーナー契約で一般的）、および成果ベース（測定可能な成果に対して支払いが行われる）の4つがあります。 成果物の予測可能性に合わせて、適切な構造を選択してください。仕事に関する紛争の多くは、構造が仕事内容に合っていない場合に発生します。

業務範囲書は誰が作成するのでしょうか？

仕事範囲の文書は通常、仕事をこなす側（代理店、ベンダー、または社内のプロジェクトリーダー）が草案を作成します。その後、双方が内容を確認し、仕事開始前に合意します。自ら草案を作成することには、成果物、範囲の境界、および対象外事項を自社の条件に合わせて設定できるという利点があります。

仕事範囲は法的拘束力がありますか？

仕事範囲書は、契約書や作業明細書の一部として署名されると、法的拘束力を持ちます。単独では主に仕事内容を定義するものですが、署名済みの契約書に含まれることで、約束された内容の根拠となります。契約に関わる事項については、必ず有資格の専門家に拘束力のある条項の確認を依頼してください。

業務範囲定義書は社内プロジェクトにも使用できますか？

はい。業務範囲定義書は、クライアントとベンダーの間と同様に、社内のチーム間（例えば、マーケティング部門がデータダッシュボードの制作を依頼したり、運用部門が社内ツールの導入を依頼したりする場合）でも機能します。その構成要素は、目的、成果物、タイムライン、検収基準、および除外事項という点で全く同じです。唯一の違いは、承認が外部のクライアントではなく社内のステークホルダーから行われる点と、支払い条件が予算やリソースの割り当てに置き換えられる場合がある点です。

「仕事範囲」の別の言い方は何ですか？

業務範囲（Scope of Work）は、時には「業務明細書（Statement of Work）」や「プロジェクト範囲明細書（Project Scope Statement）」、あるいは単に「スコープ」と呼ばれることもありますが、これらは厳密な同義語ではありません。業務明細書はより広範な契約書を指し、プロジェクト範囲明細書は内部プラン用の文書です。誰かがこれらの用語を曖昧に使用している場合は、それに基づいて行動を起こす前に、相手が成果物（業務範囲）を指しているのか、それとも完全な契約書（業務明細書）を指しているのかを確認してください。

「業務範囲」と「作業分解構成（WBS）」の違いは何ですか？

業務範囲（SOW）は、何が成果物として提供されるか、およびそれに関する条件を明記したものです。一方、作業分解構成（WBS）は、それらの成果物を階層構造に従って、サブ成果物やタスクに分解したものです。SOWは合意事項であり、WBSはその下にある実行計画図です。SOWの成果物に基づいてWBSを構築することで、文書が実際のタスクと常に接続された状態を保ち、内容がずれることを防ぐことができます。