【プロジェクトスコープ】定義と5ステップ｜記述書例つき

約 23 分で読めます

プロジェクトスコープとは、目標・成果物・タスク・期限（タイムライン）・コスト・除外事項を定義し、プロジェクトの作業範囲の境界を明確にすることです。この記事では6つの構成要素から定義の5ステップ、記述書の記入例、スコープクリープの防止策までを解説します。

1. プロジェクトスコープとは？｜定義と6つの構成要素

プロジェクトスコープとは、プロジェクトで行う作業と行わない作業の境界を、目標・成果物・タスク・期限・コストの面から定義したものです。

「境界」という言葉がポイントです。多くの現場でトラブルになるのは、やるべきことが不明確だからではなく、やらなくていいことが明文化されていないからです。「これくらいは当然含まれていると思っていた」という一言が、数週間の遅延と数百万円の追加コストを生みます。スコープは、その「思っていた」を潰すための合意文書だと考えてください。

プロジェクト管理の全体像の中では、スコープは計画フェーズの最上流に位置します。ここが曖昧なままだと、後続のスケジュールも見積もりもリスク分析も、すべて砂上の楼閣になります。

プロジェクトスコープの6つの構成要素

• プロジェクト目標：このプロジェクトが解決する課題と、達成したい状態を言語化したものです。「売上を伸ばす」ではなく「既存顧客のリピート率を四半期で15%改善する」のように、達成／未達成が誰の目にも判定できる粒度まで落とし込みます。目標が曖昧なままだと、後続の全要素が判断基準を失います。
• 成果物（デリバラブル）：プロジェクトが最終的に引き渡す、目に見えるアウトプットです。システムそのものだけでなく、操作マニュアル、テスト報告書、運用手順書なども成果物に含まれます。「どの状態になったら完成とみなすか」の受け入れ基準もセットで書いておくのが実務のコツです。
• タスクと活動：成果物を作るために必要な作業の集合です。ここを一段ずつ分解したものが後述のWBSで、個々のタスクの粒度がそのまま見積もり精度に直結します。
• タイムラインとマイルストーン：作業の時間軸の設計と、進捗を検査する節目です。重要な節目を置かないスケジュールは、遅延を最終週まで検知できません。
• コストと予算：人件費、外注費、ライセンス費、予備費を含めた総額です。予備費（コンティンジェンシー）を明示しておくと、想定内の変動と想定外の変更を切り分けて議論できます。
• 除外事項（アウトオブスコープ）：6要素のうち最も軽視され、最もトラブルを防ぐ項目です。「本プロジェクトに既存データの移行は含まない」「多言語対応は次フェーズで扱う」と書いておくだけで、後日の「聞いていない」を封じられます。

プロジェクトスコープとプロダクトスコープの違い

読者がもっとも混同しやすいのがこの2つです。プロダクトスコープは「モノの仕様」、プロジェクトスコープは「モノを作る仕事の範囲」と覚えると整理できます。

両者は入れ子の関係です。プロダクトスコープが膨らめば（機能追加）、必ずプロジェクトスコープも膨らみます（工数追加）。逆に言えば、機能追加の要望が来たときに「それはプロダクトスコープの変更なので、プロジェクトスコープの再合意が必要です」と説明できることが、PMの防御線になります。仕様側の詰め方については要件定義の進め方も合わせて確認してください。

2. プロジェクトスコープが重要な理由｜建設プロジェクトの例で見る4つの効果

スコープを定義する価値は、次の4点に集約されます。

明確さと集中：チームが「今週やるべきこと」を自分で判断できるようになります。判断を毎回PMに確認しにくるチームは、たいていスコープが共有されていません。

ステークホルダーの整合：プロジェクト関係者は、それぞれ違う期待値を持ってプロジェクトに参加します。スコープ記述書は、その期待値を1枚に集約して差分を早期に炙り出す装置です。

リソース管理：範囲が決まって初めて、必要な人数・期間・予算を積算できます。範囲が決まらないうちの見積もりは、当てずっぽうです。

リスク管理：境界が引かれると、境界の外側にある不確実性（法規制、外部ベンダー、天候）が見えるようになります。

これが実際にどう効くのか、一例として住宅複合施設の建設プロジェクトを想定して考えてみます。例えばスコープに「地上8階・全42戸、専有部の内装仕上げは標準グレード、共用部はエントランス・宅配ボックス・駐輪場まで」と書かれ、除外事項に「外構の植栽は別発注」「入居者向けインターネット回線の敷設は含まない」と明記されているとします（数値は説明用の想定です）。

この1行があると何が起きるか。施主から「植栽も一緒にやってほしい」と言われた瞬間、それが追加契約の対象だと即座に説明できます。除外事項がなければ、現場は善意で対応し、原価は静かに膨らみ、竣工検査の直前に赤字が発覚します。建設業では材料規格や法令適合の範囲、元請と下請の作業分担も、同じ構造でトラブル化します。

実務では、この境界を「文書」ではなく「全員が毎日見る画面」に置けるかどうかが分かれ目になります。たとえば monday.com のボードに成果物ごとの行を作り、「スコープ内／変更申請中／対象外」というステータス列を1つ足すだけでも効果があります。Word の記述書は日常的に開かれませんが、ボードのステータスは毎日目に入るため、「これ、やるんでしたっけ？」という確認のやり取りを減らせます。

3. プロジェクトスコープを定義する5つのステップ｜今日から着手できる手順

ステップ1｜目標と成果物をSMART基準で明確にする

まず、プロジェクトが達成する状態を SMART（Specific／Measurable／Achievable／Relevant／Time-bound）で書き直します。「使いやすいアプリを作る」は目標ではなく願望です。例えば「初回起動から会員登録完了までの離脱率を30%以下に抑えたアプリを、10月末までにリリースする」まで書けて、はじめて判断基準になります。

成果物には必ず受け入れ基準を添えます。「ユーザーマニュアル一式」ではなく「主要12機能の操作手順を含み、発注者のレビューを1回経たPDF」と書けば、完成の解釈揺れが消えます。目標の言語化に自信がない場合は、ゴールの設定方法の考え方を先に押さえておくと精度が上がります。

ステップ2｜WBSでタスクを洗い出す

スコープ定義の核心はWBS（Work Breakdown Structure＝作業分解構成図）です。成果物を頂点に置き、下へ分解していきます。

実務で押さえるべき原則は3つです。

1. 100%ルール：下の階層をすべて足すと、上の階層とちょうど同じになるように分解します。足りなければ作業漏れ、はみ出せばスコープクリープの芽です。
2. 8/80ルール：最小単位（ワークパッケージ）は、8時間〜80時間で終わる大きさを目安にします。1日未満は管理コスト過多、2週間超は進捗が見えません。
3. 成果物ベースで分解する：「開発」ではなく「ログイン画面」「決済API連携」のようにモノで割ります。動詞で割ると、完了判定が曖昧になります。

WBSができると、最長経路の特定や工数見積もりが一気に現実的になります。逆にWBSなしで引いたスケジュールは、ほぼ必ず後半で崩れます。

ステップ3｜除外事項と制約を明記する

ここで「やらないこと」を紙に落とします。おすすめは、ステークホルダーに「このプロジェクトに含まれると思っているものを全部挙げてください」と聞き、出てきたリストを「含む／含まない」に仕分ける方法です。含まないと判定したものこそが、除外事項の素材になります。

同時に、前提（Assumption）と制約（Constraint）も書き分けます。前提は「発注者側のレビューは3営業日以内に返る」といった、崩れると計画が変わる仮定。制約は「予算は1,200万円まで」「本番リリースは繁忙期を避ける」といった動かせない枠です。この2つを書いておくと、後で計画が狂ったときに「前提が崩れたので再計画が必要」と論理的に説明できます。

ステップ4｜ステークホルダーを巻き込み合意形成する

スコープの最大の敵は、関係者が違う絵を見ていることです。営業は「機能が多いほど売れる」、開発は「範囲を絞りたい」、経営は「予算内で早く」。この非対称を放置したまま着手すると、途中で必ず衝突します。

対策は3つです。第一に、キックオフの場でスコープ案を読み合わせ、その場で異議を出し切ってもらうこと。第二に、承認者を1人に決めること（承認者が3人いるスコープは、実質誰も承認していません）。第三に、定例で「スコープに変化はないか」を議題に常設し、プロジェクトの現況と一緒に確認することです（進め方は後述の「定期レビュー」を参照）。

ステップ5｜記述書を作成し変更管理プロセスを設定する

最後に、ここまでの内容をスコープ記述書としてまとめ、同時に変更管理のルールも決めます。記述書だけ作って変更ルールを決めないのが、もっともよくある失敗です。スコープは必ず変わります。問題は変わることではなく、変わったことが記録も承認もされずに現場へ流れ込むことです。

記述書は、更新履歴が残り、全員が同じ最新版を見られる場所に置いてください。ファイルサーバーに置いたv3_final_改訂版.docx は、必ず誰かが古い版を読みます。

スコープは定期レビューで最新に保つ

スコープは一度書いたら終わりではありません。プロジェクト実行中は、隔週または月次など固定の頻度でスコープを見直す場を、最初からカレンダーに組み込んでおきます。レビューで確認するのは次の4点です。

• スコープが現在のプロジェクト目標・事業状況とまだ整合しているか（関連性の確認）
• 除外事項が今も有効か（外部環境や優先度の変化で前提が変わっていないか）
• 承認済みの変更が、記述書とWBSに漏れなく反映されているか
• 前提条件が崩れていないか（レビュー返却の遅れ、外部APIの仕様変更など）

見直しの結果、修正が必要になったら、口頭共有で終わらせずに版を上げて記述書を更新し、どこが変わったかを差分で関係者全員に伝えます。レビューの頻度を決めていないチームは、実質的にスコープを放置しているのと同じで、気づいたときには記述書と現場の実態が別物になっています。定義して終わりではなく、定期的に点検して更新するところまでがスコープ管理です。

4. スコープクリープとは？｜3つの原因と変更管理での防ぎ方

スコープクリープとは、正式な承認を経ないまま作業範囲がじわじわ拡大していく現象です。1回あたりは「ボタンを1つ足すだけ」の小さな話なので誰も止めず、気づいたときには工数が1〜2割膨らんでいる、ということが起こります。

スコープクリープが起きる3つの主な原因

原因1：要件が曖昧なまま着手した 「詳細は走りながら詰めましょう」で始まったプロジェクトは、詰める作業が全部スコープ拡大として現れます。曖昧さは消えるのではなく、後工程で追加要望の形をとって現れるだけです。

原因2：非公式ルートの依頼が通ってしまう 廊下やチャットで担当者に直接「ついでにこれも」と頼まれ、担当者が善意で引き受けるパターン。PMのレーダーに映らないため、最も発見が遅れます。窓口をPMに一本化するだけで、かなりの割合が防げます。

原因3：ゴールドプレーティング（作り込みすぎ） 依頼されていないのに、作り手が良かれと思って品質や機能を上乗せする現象。悪意ゼロで発生し、しかも「頑張った人」を叱れないため、対処が難しいタイプです。受け入れ基準を先に決めておくことが唯一の予防策になります。

変更管理プロセスでスコープクリープを防ぐ方法

止めるべきは「変更」ではなく「無承認の変更」です。次の5ステップを回してください。

1. 受付：すべての変更要望を1つの窓口（フォームやボードの申請アイテム）に集める
2. 影響分析：コスト・期間・品質・リスクへの影響を数字で出す（「3人日・リリース2日遅延」など）
3. 判断：承認者が採否を決める。却下も正式に記録する
4. 更新：承認された変更をスコープ記述書とWBSに反映し、版を上げる
5. 周知：チーム全員に新しい境界を共有する

このプロセスは、文章で長く書くよりもフローチャートなどの視覚的補助に落として共有するほうが浸透します。文書化が不十分になりがちなチームこそ、「受付→影響分析→判断→更新→周知」の流れを1枚の図にし、誰もが目にする場所（ボードの先頭やWikiのトップ）に置いておくと、非公式ルートの依頼が減ります。

重要なのは、ステップ2で必ず対価を提示することです。「その追加は可能ですが、リリースが2日遅れます。どちらを優先しますか」と返せば、依頼者自身が優先度の判断をしてくれます。「できません」と言うより通りますし、無承認の追加は消えます。

（受付フォームは monday.com の無料プラン でも作成できます。申請フォームからボードへ自動でアイテムが立つように設定しておくと、依頼内容と日時が記録として残り、「言った・言わない」の議論を避けやすくなります。）

5. プロジェクトスコープ記述書の書き方｜テンプレートと記入例

記述書に含めるべき8つの項目

【例】ソフトウェア開発プロジェクトのスコープ記述書サンプル

そのまま流用できるよう、一例としてモバイルアプリ開発（架空のプロジェクト）の記入例を示します。以下の数値は、書き方のイメージを掴むためのサンプルです。

プロジェクト概要：既存Webサービスの会員がスマートフォンから予約・変更を完結できないため、電話問い合わせが月間約400件発生している。これをアプリ化により削減する。

目標：初回起動から会員登録完了までの離脱率30%以下、リリース後3か月で電話問い合わせを40%削減する。

成果物：

• iOS／Android版アプリ（会員登録、予約、予約変更、プッシュ通知の4機能）
• 管理者向け操作マニュアル（PDF、発注者レビュー1回済み）
• テスト報告書（主要機能の正常系・異常系の結果を含む）

スコープに含む範囲：要件定義、UI設計、実装、単体・結合テスト、ストア申請、リリース後1か月の初期不具合対応

除外事項：

• 既存会員データの移行（別プロジェクトで実施）
• 多言語対応（日本語のみ、英語対応は次フェーズ）
• 決済機能の実装（現行Webの決済へ遷移する方式とする）
• リリース1か月経過後の運用保守（別途保守契約）

タイムライン：全6か月。要件定義完了（1か月目末）、UI設計承認（2か月目末）、開発完了（4.5か月目）、テスト完了（5.5か月目）、ストア公開（6か月目）

予算：開発1,000万円、テスト150万円、予備費130万円

前提条件と制約：発注者のレビューは3営業日以内に返却される／既存APIの仕様変更は発生しない／繁忙期（12月）のリリースは不可

変更管理：スコープ変更は所定フォームで受付。影響分析後、プロジェクトオーナーの承認をもって記述書を改版する。あわせて隔週の定例でスコープの妥当性をレビューし、更新点は全関係者へ周知する。

この記述書はドキュメントとして残すため、Notionのようなワークスペースに置くと相性が良いです。テンプレート化して次のプロジェクトで複製でき、更新履歴も残り、リンク1本で全員が同じ最新版を参照できます。記述書とプロジェクト計画書を同じ場所に並べておくと、参照コストがさらに下がります。

6. スコープ管理におすすめのツール｜チームに合うのはどれ？

スコープ管理に必要なのは、①境界を書き残す場所、②WBSを分解して進捗を追う場所、③変更を申請・承認する導線の3つです。これを別々のツールに散らすと、必ずどれかが最新でなくなります。

monday.com｜スコープの境界を「毎日見る画面」に変える

当サイトがイチオシとして紹介しているのが monday.com です。WBSの第2階層をグループ、ワークパッケージをアイテムとして並べ、「スコープ内／変更申請中／対象外」のステータス列を足すだけで、記述書が生きた管理表になります。

効果が出やすいのは自動化ルールです。ステータスが「変更申請中」に変わったらプロジェクトオーナーへ自動通知が飛ぶ設定にしておけば、変更要望が承認プロセスを飛ばして現場へ流れ込むのを防げます。担当者が善意で引き受けた追加作業は、通知の仕組みがないと定例会議まで発覚しません。自動通知が記録として残るため、無承認のまま進む追加作業に早い段階で気づけるようになります。

料金は無料プラン（最大2ユーザー・3ボード・3ドキュメント）から始められます。公式サイトの公開情報（本記事執筆時点）では、ベーシックが US$9/月、スタンダードが US$12/月、プロが US$19/月（いずれも年間払い時のユーザー単価表示）です。自動化やタイムライン表示を含む有料機能は、プロプランの無料トライアルで試せます。プラン構成・価格・トライアル条件は改定されることがあるため、申し込み前に公式サイトの最新情報を確認してください。日本語UIに対応している点も、社内展開時には安心材料です。

Notion｜記述書とWBSを1か所にまとめたいチームへ

スコープ記述書のように「文章で残す情報」が多いなら Notion が扱いやすいです。記述書ページの中にWBSのデータベースを埋め込めるので、文章とタスクが同じページで完結します。記述書をテンプレート化しておけば、次のプロジェクトは複製して固有名詞を差し替えるだけです。

公式サイトの公開情報（本記事執筆時点）では、フリープランは US$0、プラスが US$10/月、ビジネスが US$20/月（いずれも年間プラン時のユーザー単価）です。こちらも価格改定の可能性があるため、最新は公式サイトでご確認ください。少人数で「まずドキュメントを整えたい」段階なら、無料から十分始められます。

ClickUp：スコープをタスク階層で作り込みたいチームに

ClickUpは、スコープ記述書の成果物をそのままタスクの階層（スペース→リスト→タスク→サブタスク）に落とし込めるのが強みです。ドキュメントとタスクを同じ場所で扱えるため、記述書と実作業の乖離に気づきやすくなります。無料プランはメンバー数・タスク数が無制限（ストレージ上限あり）なので、まずチーム全員で試すハードルが低い点も魅力です。

有料プランは Unlimited が US$7/月、Business が US$12/月（いずれも年間払い表示のユーザー単価）。設定項目が多いぶん立ち上げに手がかかるため、管理を担当する人を1人決めてから導入するのがおすすめです。最新の料金は公式サイトでご確認ください。

ツール比較表

※料金・プラン内容は各社公式サイトの公開情報（本記事執筆時点）に基づく目安です。最新の条件は各公式サイトでご確認ください。

あなたのチームはどのタイプ？

• 5人以下・個人、まず記述書を形にしたい → Notion の無料プランから
• 5〜15人の部門横断プロジェクト、変更管理を仕組み化したい → monday.com（当サイトのイチオシ）
• 開発チームでスプリントを回している → ClickUp（無料プランから試せます）
• 15人以上・複数プロジェクトの横断管理 → monday.com の上位プラン（プロ以上）

なお、日々の工程の回し方まで含めて一元化したい場合は、記述書とボードを分けず、同じツール内で運用するほうが更新漏れが起きにくくなります。

まとめ

• プロジェクトスコープとは、目標・成果物・タスク・タイムライン・コスト・除外事項の6要素で、プロジェクトの作業範囲の境界を定義したものです
• プロダクトスコープ（モノの仕様）とプロジェクトスコープ（仕事の範囲）を切り分けて説明できると、機能追加の要望に論理的に対応できます
• 定義は5ステップ。SMARTで目標を決め、WBSで分解し、除外事項と制約を書き、関係者と合意し、記述書と変更管理プロセスをセットで用意します。実行中は隔週・月次など固定頻度でレビューし、更新は版を上げて全員に周知します
• スコープクリープは「曖昧な要件・非公式ルート・作り込みすぎ」の3つから生まれます。止めるべきは変更ではなく、無承認の変更です
• 記述書は8項目（概要・目標・成果物・含む範囲・除外事項・タイムライン・予算・前提と制約）を埋めれば完成します

次の一歩はシンプルです。この記事の方法論を実践に移すなら、まず monday.com でテンプレートから新しいボードを作り、成果物を1行ずつ入れて「スコープ内／変更申請中／対象外」のステータス列を追加してみてください。最初のプロジェクトの骨組みが10分で形になり、除外事項が目に見える場所に置かれます。境界が見えた瞬間から、チームの「これ、やるんでしたっけ？」は減り始めます。無料プランで試し、変更の自動通知まで使いたくなったら有料プランの無料トライアルで確かめる、という順番がおすすめです。

よくある質問

プロジェクトスコープとは簡単に言うと？

プロジェクトで「やること」と「やらないこと」の境界線です。目標、成果物、必要なタスク、期限、コスト、そして除外事項の6つを書き出して、関係者全員が同じ絵を見られるようにしたものだと考えてください。地図があるから道に迷わないのと同じで、スコープがあるからチームは「今週何をすべきか」を自分で判断できます。

スコープクリープとは何ですか？

正式な承認を経ないまま、プロジェクトの作業範囲がじわじわ拡大していく現象です。「ボタンを1つ足すだけ」「ついでにこの資料も」といった小さな追加が積み重なり、気づけば工数が膨らみ、納期が崩れます。主な原因は、要件が曖昧なまま着手すること、PMを経由しない非公式な依頼、そして作り手による過剰な作り込み（ゴールドプレーティング）の3つです。変更を禁止するのではなく、すべての変更を1つの窓口で受け、影響を数字で示して承認を取る流れを作ることが対策になります。

プロジェクトスコープステートメント（記述書）とは？

スコープの内容を正式な文書にまとめたものです。プロジェクト概要、目標、成果物と受け入れ基準、含む範囲、除外事項、タイムライン、予算、前提条件と制約の8項目で構成されます。作成のポイントは、承認者を1人に絞ること、除外事項を必ず書くこと、更新履歴が残る場所（共有ワークスペースなど）に置いて全員が同じ最新版を参照できるようにすること、そして定期的にレビューして最新の状況に合わせて改版することです。ファイルサーバー上の「最終版」ファイルは、ほぼ確実に誰かが古い版を読みます。

建設プロジェクトのスコープには何を含めるべき？

建設業では、IT系のプロジェクト以上に「境界の明文化」が利益を左右します。最低限、次の要素を含めてください。工事範囲（棟数・階数・戸数、専有部と共用部それぞれの仕上げグレード）、材料・仕様（使用する建材の規格と代替可否）、法令・許認可の対応範囲（申請業務を誰が担うか）、分担の線引き（元請・下請の作業区分、施主支給品の有無）、除外事項（外構や植栽、インターネット回線敷設、家具什器など、含まないものを具体的に列挙）、前提条件（近隣説明会の実施主体、天候による工期変動の扱い）。特に「施主支給品」と「外構」は追加請求のトラブル源になりやすいため、契約書とスコープ記述書の両方で同じ表現に揃えておくことをおすすめします。