プロジェクトスコープ記述書：定義・事例・テンプレート

プロジェクトスコープ記述書は、漠然としたプロジェクトアイデアを「チームが何を作るか、何には手を触れないか、完了とはどういう状態か」について合意・署名された共通文書へと変換するものです。これがなければ、新たな機能追加依頼やステークホルダーの要望はどれも正当に見え、スケジュールは静かに崩れていきます。

プロジェクトスコープ記述書とは

重要なポイント

• PMBOK第7版によると、スコープ記述書はプロジェクトスコープベースラインの基礎となり、WBS・スケジュール・予算に反映されます（PMI, 2021）。
• プロジェクトの**52%**でスコープクリープが発生しており、その主要原因はキックオフ時のスコープ記述書の不明確さまたは欠如です（PMI Pulse of the Profession, 2024）。
• キックオフ時に署名済みのスコープ記述書があるプロジェクトは、当初の予算を達成できる確率が39%高いとされています（Standish Group CHAOS Report, 2024）。

プロジェクトスコープ記述書とは、プロジェクトの境界を正式に定義した文書です。含まれる作業・明示的に除外される作業・作成される成果物・各成果物が適切に完了したと判断するための基準を記載します。計画フェーズで作成され、プロジェクトライフサイクル全体を通じてスコープに関するすべての意思決定の参照点となります。

これはプロジェクトチームとステークホルダーの間の契約書と捉えてください。答えを出さなければ必ず問題を招く3つの問いに応えるものです。

• このプロジェクトは何を生み出すか？
• このプロジェクトは何を生み出さないか？
• 各成果物がいつ完了したとみなすか？

スコープ記述書は、成果物を実行可能なタスクに分解する作業分解構成図（WBS）に直接つながります。また、スケジュール・予算・変更管理プロセスの基盤にもなります。スコープに変更があれば、下流のすべての計画を見直す必要があります。

スコープ記述書が重要な理由

スコープクリープは、プロジェクトが予算超過・期限超過に陥る最も一般的な原因です。少しずつ進みます。ステークホルダーが「小さな追加」をお願いし、チームが了承し、6週間後にはプロジェクトが当初の40%増となり、チームは疲弊しています。

署名済みのスコープ記述書は、変更依頼を止めるものではありません。ただ、プロジェクトマネージャーが依拠できる文書としてのベースラインを提供します。新たな要求が来たとき、チームはそれを記述書と照合して明確に伝えられます。「それは合意済みのスコープ外です。追加することは可能ですが、スケジュールと予算への影響はこうなります」という会話は、キックオフで何となく合意した内容を思い出そうとする会話よりはるかに楽です。

スコープ記述書はステークホルダーの認識合わせにも役立ちます。経営幹部・クライアント・デリバリーチームが作業開始前に同じ文書を読んで署名することで、期待のずれが早い段階で表面化します。費用が少ない段階です。後から表面化すると、対処コストが跳ね上がります。

この認識合わせは、Backlogが頻繁に変わるアジャイル手法を使うプロジェクトでも特に価値があります。アジャイルチームでも、Product Backlogの際限ない肥大化を防ぐ高レベルのスコープ境界は有益です。

スコープ記述書の構成要素（7つのコンポーネント）

完全なスコープ記述書は7つの領域を扱います。どれか1つを省略すると、スコープクリープが侵入する隙間が生まれます。

1. プロジェクト目標 -- プロジェクトが達成すべき測定可能な成果。目標は具体的で期限付きであるべきです。「8月31日までにリニューアルしたウェブサイトをローンチし、ホームページの直帰率を15%低減する」はプロジェクト目標です。「ウェブサイトを改善する」はそうではありません。

2. 成果物 -- プロジェクトが生み出す有形のアウトプット。ウェブサイトリニューアルの場合、新しいホームページ、5つの内部ページテンプレート、スタイルガイド、CMSトレーニング文書などが該当します。想定の余地がないよう、各成果物を名前で列挙してください。

3. 受け入れ基準 -- 各成果物が完了・承認されたとみなされるための具体的な条件。受け入れ基準は主観性を排除します。「ホームページが4G接続で2.5秒以内に読み込まれること」は受け入れ基準です。「ホームページが速く感じられること」はそうではありません。

4. スコープ内項目 -- プロジェクトが対応する作業・機能・システム・プロセス。このセクションにより、含まれるべき作業がチームに見落とされるのを防ぎます。

5. スコープ外項目 -- プロジェクトが明示的に対応しない作業・機能・システム。おそらく最も重要なセクションです。何をしないかを文書化することで、後から断る正当性が生まれます。

6. 制約事項 -- プロジェクトが従わなければならない既知の制限事項：予算上限、固定期限、特定の技術スタック、規制要件、チーム規模。制約事項は無視しても消えません。書き出すことで、全員が同じ現実を前提に計画できます。

7. 前提条件 -- スコープ定義時にチームが真であると仮定している条件。いずれかの前提条件が誤りであった場合、スコープを見直す必要があります。例：「クライアントはすべてのブランド素材を6月15日までに提供することを前提としています」。それらが2週間遅れれば、スケジュールに影響します。

スコープ記述書 vs プロジェクト憲章 vs WBS

この3つの文書は密接に関連しており、混同されがちです。違いは以下の通りです。

憲章が最初に来て概括的です。スコープ記述書はプロジェクト計画の段階で詳細を埋めます。WBSはその成果物を受けてスケジュール化可能な作業に分解します。

これらの文書は互いを代替するものではありません。スコープ記述書のない憲章は解釈の余地が大きすぎます。WBSのないスコープ記述書はチームが実行するには抽象的すぎます。

プロジェクトスコープ記述書の作成手順

ステップ1：プロジェクト憲章を確認する

すでに承認されている内容から始めましょう。憲章にはプロジェクトの目的、スポンサーの目標、既知の制約事項が含まれています。スコープ記述書は憲章と整合していなければなりません。矛盾があってはなりません。目標をそのまま抽出するか、測定可能な形に洗練させてください。

ステップ2：すべての成果物を列挙する

チームと主要ステークホルダーと協力して、プロジェクトが生み出すものをすべて挙げます。最終アウトプットだけでなく、プロトタイプ・テスト報告書・トレーニング資料などの中間成果物も含めてください。タスクではなく名詞句を使ってください（「モバイル対応ホームページ」「ユーザー受け入れテスト報告書」）。成果物はアクティビティではなく、ものです。

ステップ3：各成果物の受け入れ基準を定義する

各成果物について「承認された」状態がどのようなものかを書き留めます。その成果物を承認するステークホルダーを巻き込んでください。完了の定義があなたとは異なる可能性があるためです。今の段階で書面に残すことで、後の手戻りを防げます。

ステップ4：スコープ外の境界を定める

ほとんどのチームが省略して後悔するステップです。各成果物について「ステークホルダーが含まれると思い込む可能性がある隣接作業は何か？」を問いかけてください。それらを明示的にスコープ外として書き留めます。ウェブサイトリニューアルプロジェクトであれば、マーケティング部門がSEO監査も含まれると思い込む可能性があります。含まれないなら、明記してください。

このセクションはRACIマトリクスの作業とも連動します。正式な計画に含まれていなかった作業の責任者を割り当てようとする際に、スコープ外項目が浮かび上がることがよくあります。

ステップ5：制約事項と前提条件を記録する

実際の制約事項（予算・期限・技術・人員）をすべて列挙します。次に、依拠しているすべての前提条件を列挙します。両方について正直に記載してください。チームは不確実性を認めるような気がするため、前提条件を書くことを避けがちです。しかし、書かれていない前提条件は隠れたリスクです。書き留め、早期に検証する計画を立ててください。

ステップ6：ステークホルダーの署名を取得する

誰も署名していないスコープ記述書は単なるドラフトです。プロジェクトスポンサー・主要ステークホルダー・デリバリーチームに回覧します。署名後ではなく、署名前に不一致を解消してください。署名されると、変更依頼が照合される基準のベースラインとなります。

プロジェクトスコープ記述書テンプレート

このテンプレートをコピーしてプロジェクトに合わせて編集してください。

プロジェクトスコープ記述書

プロジェクト名： ［プロジェクト名］ プロジェクトマネージャー： ［PM名］ 承認日： ［日付］ バージョン： ［1.0］

---

プロジェクト目標 ［指標と期限に紐づけた、プロジェクトが達成すべき測定可能な成果を2〜4つ記載する。］

成果物

1. ［成果物名］：［簡潔な説明］
2. ［成果物名］：［簡潔な説明］
3. ［成果物名］：［簡潔な説明］

受け入れ基準

• ［成果物1］：［承認のための具体的・測定可能な条件］
• ［成果物2］：［承認のための具体的・測定可能な条件］
• ［成果物3］：［承認のための具体的・測定可能な条件］

スコープ内

• ［含まれる作業・機能・システム］
• ［含まれる作業・機能・システム］

スコープ外

• ［明示的に除外される作業・機能・システム］
• ［明示的に除外される作業・機能・システム］

制約事項

• 予算：［金額または上限］
• 期限：［固定終了日または制約事項］
• 技術：［必須または禁止のツール・プラットフォーム］
• リソース：［人員または スキルの制約事項］

前提条件

• ［真であると仮定している条件］
• ［真であると仮定している条件］

承認

役割	氏名	署名	日付
プロジェクトスポンサー
プロジェクトマネージャー
主要ステークホルダー

プロジェクトスコープ記述書の事例

4種類の一般的なプロジェクトタイプについて、成果物・スコープ内・スコープ外の分類をまとめます。

各「スコープ外」の列が、ステークホルダーが含まれていると思い込みやすい隣接作業を文書化していることに注目してください。この具体性こそが重要です。曖昧な除外事項は誰も守れません。

Scrumを使用するプロジェクトでは、スコープ記述書はエピックレベルに位置します。個々のSprintのスコープはBacklogで管理しますが、高レベルの境界は引き続き適用されます。

スコープ記述書でスコープクリープを防ぐ方法

スコープ記述書は、それを実施する変更管理プロセスと一体であって初めて力を発揮します。実際に機能させる5つの方法を紹介します。

1. 毎回の状況報告会議で参照する。 スコープ記述書をフォルダに入れて忘れさせないでください。週次の状況報告コールを、スコープ内・スコープ外の60秒のリマインダーから始めましょう。新たな依頼が上がる前に、ステークホルダーの頭にベースラインを新鮮に保ちます。

2. 変更依頼のフィルターとして活用する。 ステークホルダーが新しい作業を依頼してきたら、まず承認済みのスコープと照合します。スコープ外であれば、すぐに「ノー」と言わないでください。「それは現在のスコープ記述書の範囲外です。影響を評価しましょう」と伝えます。そのうえで、見直した見積もりとともに正式な変更依頼を処理します。余分な作業をサイレントに吸収することなく、誠実な姿勢を示せます。

3. スコープ外リストを名前で指摘する。 スコープ外として明記された内容を誰かが要求した場合、文書を参照してください。「実はスコープ記述書の4節にスコープ外として記載されています。追加するとXが必要になります。変更依頼を起票しますか？」という問いかけです。具体性が曖昧さを取り除き、会話をプロフェッショナルに保ちます。

4. 前提条件の変化をスコープ見直しのきっかけとする。 記載した前提条件が誤りであると判明した場合、すぐにスコープを再評価してください。チームは前提条件の失敗をサイレントに吸収し、正式な合意を見直さずに作業を調整することが多いです。これがスコープクリープが裏口から忍び込む方法です。

5. Ganttチャートやクリティカルパス分析と組み合わせる。 スケジュールへの影響を具体的に示すと、抽象的な反論が具体的になります。「CRM統合を追加すると、ローンチ日が10月1日から11月14日に移動します」という説明は、「それはスコープ外です」というだけよりはるかに説得力があります。

6. スコープ変更を予算承認に連動させる。 作業を追加する変更には予算レビューを伴わせましょう。追加スコープに金額が紐づくと、ステークホルダーはより慎重に検討します。個々の小さな変更は無害に見えますが、予算の明細で累積コストが可視化されます。

よくある失敗

ベストプラクティス

• スコープ内より先にスコープ外セクションを書く。除外事項から始めることで、プロジェクトが「何でないか」について明確になり、含む事項がより明確になります。
• 成果物は適切な詳細レベルに保つ：曖昧さがなく、しかしWBSに属するほど細かくない。プロジェクトあたり5〜15の成果物を目安にしてください。
• 文書のバージョン管理を行う。スコープが変わったら、バージョン番号と日付を更新します。何が変わったか、なぜ変わったかを追えるよう旧バージョンを保存してください。
• スコープ記述書をRACIマトリクスと連動させる。各成果物には明確な担当者が必要です。担当者のいない成果物はおそらくスコープ外です。
• Waterfallプロジェクトでは、詳細計画を始める前にスコープ記述書を確定させる。アジャイルプロジェクトでは、Backlogを固定せずに外側の境界を設けるSprintゼロの成果物として運用してください。
• 平易な言葉で書く。スコープ記述書はステークホルダーが流し読みする法律文書になると機能しません。新しいチームメンバーが初日に読んでも何がプロジェクトかすぐにわかる書き方を目指してください。
• 署名済みのスコープ記述書をすべてのプロジェクト状況報告書に添付し、デリバリー全体を通じて可視化を保つ。
• フェーズゲートのたびに前提条件を見直す。前提条件が無効化されていれば、チームがサイレントに影響を吸収し続けるのではなく、すぐに表面化させてください。

よくある質問

スコープ記述書とスコープベースラインの違いは何ですか？ スコープ記述書はプロジェクトの境界を書面で説明したものです。成果物・除外事項・受け入れ基準・制約事項・前提条件を含みます。スコープベースラインは正式に承認されたスコープ記述書にWBBSとWBS辞書を加えたものです。ベースラインはパフォーマンスを照合する基準であり、変更管理が守るものです。スコープ記述書を先に書き、承認されるとベースラインになります。

プロジェクトスコープ記述書を書くのは誰ですか？ プロジェクトマネージャーがスコープ記述書のオーナーですが、一人で書いてはいけません。効果的なスコープ記述書は、デリバリー上何が現実的かを知るプロジェクトチーム、成功がどのようなものかを知る主要ステークホルダー、技術的な実現可能性を知るSMEと共同作成されます。PMの役割はその会話を促進し、アウトプットをきれいな文書にまとめることです。

プロジェクト途中でスコープ記述書は変更できますか？ はい、ただし正式な変更管理プロセスを経る必要があります。ステークホルダーがスコープを変更する正当な理由を特定した場合、プロジェクトマネージャーはコスト・期限・リソースへの影響を評価し、変更依頼として文書化し、スコープ記述書を更新する前に承認を取得します。非公式なスコープ変更こそがスコープクリープの発生経路です。

スコープ記述書はどの程度詳細にすべきですか？ 曖昧さを排除できる詳細さを持ちながら、技術仕様書のように読まれるほど詳細にしない。目安として、2人の異なるステークホルダーがあるセクションを読んで含まれる内容について異なる解釈に至る可能性がある場合、さらに詳細が必要です。あるセクションが2段落を超えて実装の詳細まで含む場合は、おそらくスコープ記述書から参照リンクを貼った別の技術文書に属します。

スコープ記述書と作業範囲記述書（SOW）は同じですか？ いいえ。**作業範囲記述書（SOW）**は2つの組織（通常はクライアントとベンダー）の間で締結される法的拘束力のある契約であり、提供されるサービス・期限・支払い条件・義務を定義します。プロジェクトスコープ記述書はプロジェクトチームが何を構築するかを定義する内部計画文書です。SOWはスコープ記述書の参考になりますが、目的も対象読者も異なります。

まとめ

プロジェクトスコープ記述書はプロジェクトで書く中で最もわくわくする文書ではないかもしれません。しかし、プロジェクトが成功するか静かに崩れるかを左右する可能性が最も高い文書です。キックオフ時に正確なスコープ外リストを書くために費やす30分は、6ヶ月後のスコープ変更交渉に費やす時間よりはるかに価値があります。

早い段階で書いてください。署名をもらってください。頻繁に参照してください。そして誰かが「ちょっとした追加」をお願いしてきたときは、スコープ記述書を官僚的な障害ではなく味方として扱ってください。その文書こそが、チームが正しいことに「はい」と言い、それ以外に「いいえ」と言える根拠です。

スコープ定義の次のステップとして、作業分解構成図（WBS）を構築して成果物をスケジュール化可能なタスクに分解してください。そのうえでプロジェクト計画のテクニックを使い、キックオフ前に順序付けとリソース配分を行いましょう。