- マネジメント
スコープ定義の書き方 スコープ記述書テンプレートと対象外の例
スコープ定義とは、プロジェクトで「作るもの・やること」と「作らないもの・やらないこと」の境界線を文書にして、関係者が合意することです。 その文書がスコープ記述書です。書くときのコツは、含むものを並べる前に、対象外を具体的な名前で書くことです。
この記事では、そのまま貼れるスコープ記述書のテンプレート全文と、架空の「社内備品予約システム」の記入例、対象外の文例一覧、追加の依頼が範囲内か外かを判定するチェックリストを載せます。
この記事の結論
- 対象外を先に、具体名で書きます。 「その他の機能は対象外」ではなく「スマートフォン専用アプリは対象外」と書きます。
- 成果物には受入基準を1つずつ付けます。 「できた」と言える条件が線の位置を決めます。
- 追加の依頼は断るのではなく、変更依頼として受けます。 記述書に載っていないものは、影響を調べてから入れるかどうかを決めます。
- 承認欄に日付と名前を残します。 合意した版が1つに決まっていることが、後の判断の土台になります。
確認環境:掲載したテンプレートと表は、タブ区切りの列数がそろっていること、文例の件数が本文の記載と一致することを Python 3.11.15 で点検しています。確認日 2026-10-05。
スコープ定義の早見表
| 項目 | 書くこと | 書き方の要点 |
|---|---|---|
| 目的 | なぜやるか、何が良くなるか | 1〜3文。数字で確かめられる形にする |
| 成果物 | 納めるもの(システム、文書、データ) | 名詞で書き、番号を付ける |
| 受入基準 | 成果物ごとの「完成と言える条件」 | 確認の方法と合格の条件を書く |
| 対象外 | 作らないもの、やらないこと | 具体名で書く。理由か扱い先を添える |
| 前提 | 成り立つと見込んでいる条件 | 崩れたときに見直す、と書いておく |
| 制約 | 動かせない条件(期限、体制、環境) | 数字と日付で書く |
| 承認 | 誰がいつ合意したか | 版番号、日付、名前 |
| 変更の扱い | 追加・変更の受け付け方 | 窓口と判断する人を書く |
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「スコープ定義の書き方 スコープ記述書テンプレートと対象外の例」
スコープ定義の手順
- 目的を1〜3文で書く。 迷ったときに立ち返る基準になります。
- 対象外の候補を洗い出す。 関係者に「今回やらないと思っていること」を先に聞きます。期待のずれが早く見つかります。
- 成果物を名詞で並べ、受入基準を付ける。
- 前提と制約を分けて書く。 前提は「見込み」、制約は「動かせない条件」です。
- 変更の扱いを1段落で決める。
- 読み合わせて承認をもらう。 対象外の章は声に出して1行ずつ確認します。
含むものから書き始めると、書かれていないものの扱いが読む人によって分かれます。対象外から書くと、境界の両側が文書に残ります。
スコープ記述書のテンプレート(Markdown)
そのまま貼って使える全文です。
# スコープ記述書
| 項目 | 内容 |
|---|---|
| プロジェクト名 | |
| 版 | 1.0 |
| 作成日 | |
| 作成者 | |
## 1. 目的
(なぜ行うか。何がどう良くなるか。1〜3文)
## 2. 成果物と受入基準
| No | 成果物 | 内容 | 受入基準 | 確認する人 |
|---|---|---|---|---|
| D-01 | | | | |
| D-02 | | | | |
## 3. 対象範囲(やること)
| No | 分類 | 内容 |
|---|---|---|
| S-01 | 機能 | |
| S-02 | データ | |
| S-03 | 環境 | |
## 4. 対象外(やらないこと)
| No | 分類 | 対象外とするもの | 理由・扱い先 |
|---|---|---|---|
| X-01 | 機能 | | |
| X-02 | データ | | |
| X-03 | 環境 | | |
| X-04 | 時期 | | |
| X-05 | 運用 | | |
| X-06 | 教育 | | |
## 5. 前提
| No | 前提 | 崩れた場合の扱い |
|---|---|---|
| A-01 | | |
## 6. 制約
| No | 種別 | 制約 |
|---|---|---|
| C-01 | 期限 | |
| C-02 | 体制 | |
| C-03 | 環境 | |
## 7. 変更の扱い
この文書に記載のない作業、および対象外に記載した作業の依頼は、変更依頼として受け付ける。
- 窓口:
- 影響を調べる人:
- 入れるかどうかを決める人:
- 決まった内容はこの文書の版を上げて反映する。
## 8. 承認
| 役割 | 氏名 | 承認日 |
|---|---|---|
| 依頼側の責任者 | | |
| 開発側の責任者 | | |
## 改版履歴
| 版 | 日付 | 変更内容 | 承認者 |
|---|---|---|---|
| 1.0 | | 初版 | |
記入例:架空の社内備品予約システム
社員がノートPCやプロジェクターを予約・貸出・返却できるシステムを、新しく作る想定です。
# スコープ記述書
| 項目 | 内容 |
|---|---|
| プロジェクト名 | 社内備品予約システム構築 |
| 版 | 1.0 |
| 作成日 | 2026-10-05 |
| 作成者 | 山田(総務部) |
## 1. 目的
表計算の台帳で行っている備品の予約と貸出を、ブラウザから行えるようにする。
予約の重複を0件にし、総務部の貸出対応を月20時間から月5時間以下にする。
## 2. 成果物と受入基準
| No | 成果物 | 内容 | 受入基準 | 確認する人 |
|---|---|---|---|---|
| D-01 | 備品予約システム | 予約・貸出・返却・備品管理の4機能 | 受入テストのシナリオ12本がすべて合格 | 総務部 山田 |
| D-02 | 移行済みデータ | 備品台帳320件 | 件数が一致し、抜き取り30件の内容が台帳と一致 | 総務部 鈴木 |
| D-03 | 利用者向け手引き | 予約から返却までの操作(A4で8ページ以内) | 総務部以外の社員2名が手引きだけで予約を完了できる | 総務部 山田 |
| D-04 | 管理者向け手順書 | 備品の登録・変更・廃棄、利用者の追加 | 総務部の担当者が手順書だけで備品を1件登録できる | 総務部 鈴木 |
## 3. 対象範囲(やること)
| No | 分類 | 内容 |
|---|---|---|
| S-01 | 機能 | 備品の検索、予約、予約の変更・取消 |
| S-02 | 機能 | 貸出と返却の記録、返却期限を過ぎた利用者へのメール通知 |
| S-03 | 機能 | 備品マスタの登録・変更・廃棄(管理者のみ) |
| S-04 | データ | 現行の備品台帳320件の移行(1回) |
| S-05 | 環境 | 社内ネットワークからのPCブラウザ利用(本番1面、検証1面) |
| S-06 | 教育 | 管理者2名への操作説明(1回、60分) |
## 4. 対象外(やらないこと)
| No | 分類 | 対象外とするもの | 理由・扱い先 |
|---|---|---|---|
| X-01 | 機能 | スマートフォン専用アプリ | PCブラウザのみで目的を満たせる。第2期で検討 |
| X-02 | 機能 | 会議室の予約 | 既存の予定表で運用中。連携もしない |
| X-03 | 機能 | 備品の購入申請、棚卸し | 総務部の別の業務として現行のまま |
| X-04 | データ | 過去の貸出履歴の移行 | 台帳の書式が年ごとに違うため。台帳は総務部で保管 |
| X-05 | データ | 備品の写真の登録 | 稼働後に総務部が登録する。登録機能は対象範囲 |
| X-06 | 環境 | 社外からの利用 | 社内ネットワーク限定とする |
| X-07 | 環境 | 人事システムとの自動連携 | 利用者は月1回、CSVで取り込む |
| X-08 | 時期 | 稼働後の機能追加 | 稼働後1か月の不具合対応までを範囲とする |
| X-09 | 運用 | 稼働後の備品マスタの保守 | 総務部が手順書に沿って行う |
| X-10 | 教育 | 全社員向けの説明会 | 手引きの配布で代える |
## 5. 前提
| No | 前提 | 崩れた場合の扱い |
|---|---|---|
| A-01 | 備品台帳の最新版が10月16日までに提供される | 移行の日程を見直す |
| A-02 | 総務部の確認は依頼から3営業日以内に返る | 遅れた日数分、後続の日程を動かす |
| A-03 | 利用者は300名以内、同時利用は30名以内 | 性能の条件を変更依頼として見直す |
## 6. 制約
| No | 種別 | 制約 |
|---|---|---|
| C-01 | 期限 | 2027年1月12日に稼働する |
| C-02 | 体制 | 開発3名、総務部の窓口1名 |
| C-03 | 環境 | 社内の既存サーバーとPostgreSQLを使う |
| C-04 | 認証 | 社内の共通ログインを使う |
## 7. 変更の扱い
この文書に記載のない作業、および対象外に記載した作業の依頼は、変更依頼として受け付ける。
- 窓口:総務部 山田
- 影響を調べる人:開発リーダー 佐藤
- 入れるかどうかを決める人:総務部長 高橋
- 決まった内容はこの文書の版を上げて反映する。
## 8. 承認
| 役割 | 氏名 | 承認日 |
|---|---|---|
| 依頼側の責任者 | 高橋(総務部長) | 2026-10-09 |
| 開発側の責任者 | 佐藤(開発リーダー) | 2026-10-09 |
記入例のポイントは3つです。
- X-05のように、範囲内と範囲外が隣り合う箇所を分けて書く。「写真の登録機能は作る、写真を登録する作業は行わない」と線を引いています。
- 受入基準が人の感想ではなく確かめ方になっている。「使いやすいこと」ではなく「2名が手引きだけで予約を完了できる」です。
- 対象外に扱い先がある。「第2期で検討」「総務部が行う」と書くと、やらないことへの納得が得やすくなります。
対象外の書き方の文例一覧(分類別36例)
自分のプロジェクトに合わせて、名前と数字を置き換えて使えます。
機能
| No | 文例 |
|---|---|
| 1 | スマートフォン専用アプリは対象外とし、PCブラウザでの利用に限る |
| 2 | 多言語表示は対象外とし、日本語のみとする |
| 3 | 帳票は一覧表と明細表の2種類とし、それ以外の帳票は対象外とする |
| 4 | 承認の経路は1段階とし、複数段階の承認は対象外とする |
| 5 | 外部サービスとの連携は対象外とし、CSVの取り込みと出力で行う |
| 6 | 統計・分析の画面は対象外とし、CSV出力したデータを利用者が集計する |
データ
| No | 文例 |
|---|---|
| 7 | 移行するのは現在有効な備品のみとし、廃棄済みの備品は対象外とする |
| 8 | 過去の履歴データの移行は対象外とし、現行の台帳を保管して参照する |
| 9 | 移行データの誤りの修正は対象外とし、提供されたデータをそのまま取り込む |
| 10 | 移行は1回とし、稼働後の追加の取り込みは対象外とする |
| 11 | 画像・添付ファイルの移行は対象外とする |
| 12 | マスタの初期登録は依頼側が行い、開発側は登録用の画面とCSV取り込みを用意する |
環境
| No | 文例 |
|---|---|
| 13 | 対応するブラウザはEdgeとChromeの最新版とし、それ以外は対象外とする |
| 14 | 社外ネットワークからの利用は対象外とする |
| 15 | サーバーとネットワーク機器の調達・設定は対象外とし、依頼側が用意する |
| 16 | 環境は本番と検証の2面とし、研修用の環境は対象外とする |
| 17 | 利用者の端末の設定変更・ソフトの導入は対象外とする |
| 18 | 待機系への自動切り替えの構成は対象外とし、復旧は手順書による手動とする |
時期
| No | 文例 |
|---|---|
| 19 | 今回の範囲は第1期とし、第2期に挙げた機能は対象外とする |
| 20 | 稼働後の機能追加は対象外とし、別途の依頼として扱う |
| 21 | 不具合への対応は稼働後1か月までとし、それ以降は保守の取り決めによる |
| 22 | 2026年12月以降に決まる制度・規程の変更への対応は対象外とする |
| 23 | 受入テストの期間は10営業日とし、延長する場合は変更依頼とする |
| 24 | 稼働日の立ち会いは初日のみとし、2日目以降は問い合わせ窓口で対応する |
運用
| No | 文例 |
|---|---|
| 25 | 稼働後のマスタ保守は対象外とし、依頼側の管理者が行う |
| 26 | 利用者からの問い合わせの一次受付は対象外とし、依頼側の窓口が行う |
| 27 | 日々のバックアップの取得と確認は対象外とし、既存の運用の取り決めに従う |
| 28 | 稼働状況の監視は対象外とし、既存の監視の仕組みに登録する作業のみ行う |
| 29 | 利用者アカウントの追加・削除は対象外とし、管理者向け画面で依頼側が行う |
| 30 | 業務の規程・ルールの改定は対象外とする |
教育
| No | 文例 |
|---|---|
| 31 | 操作説明は管理者向けに1回(60分)とし、追加の説明会は対象外とする |
| 32 | 全利用者向けの集合研修は対象外とし、手引きの配布で代える |
| 33 | 動画の教材の作成は対象外とする |
| 34 | 手引きは操作手順のみとし、業務の進め方の解説は対象外とする |
| 35 | 手引きの稼働後の改訂は対象外とし、編集できる形式で納める |
| 36 | 新しく加わる利用者への説明は対象外とし、依頼側が手引きを使って行う |
書き方の直す前と後
| 直す前 | 直した後 | 変えた点 |
|---|---|---|
| その他の機能は対象外とする | 会議室の予約、備品の購入申請は対象外とする | 具体名にした |
| データ移行は必要最小限とする | 移行は有効な備品320件を1回とする | 数と回数を書いた |
| 軽微な修正は随時対応する | 文言と色の修正は受入テスト期間中に限り10件まで対応する | 種類・期間・上限を書いた |
| 主要なブラウザに対応する | EdgeとChromeの最新版に対応する | 名前を書いた |
| 運用支援を行う | 稼働後1か月、平日9〜17時に問い合わせに回答する | 期間と時間帯を書いた |
「等」「など」「必要に応じて」「随時」「適宜」が入っている文は、読む人によって範囲が変わります。見つけたら名前か数字に置き換えます。
依頼がスコープ内か外かを判定する質問チェックリスト
追加の依頼や「これも含まれますよね」という確認が来たら、上から順に答えます。
| No | 質問 | はい | いいえ |
|---|---|---|---|
| 1 | 対象外の表に、その依頼に当たる行があるか | 範囲外。変更依頼へ | 2へ |
| 2 | 成果物または対象範囲の表に、その依頼に当たる行があるか | 3へ | 範囲外。変更依頼へ |
| 3 | 受入基準を満たすために必要な作業か | 範囲内 | 4へ |
| 4 | 前提または制約のどれかを変えずに対応できるか | 5へ | 範囲外。変更依頼へ |
| 5 | 成果物の数、画面・帳票・項目の数、移行の件数が増えないか | 6へ | 範囲外。変更依頼へ |
| 6 | 合意した内容どおりに動かない箇所の修正か | 範囲内(不具合) | 範囲外。変更依頼へ |
判定の例です。
| 依頼 | 判定 | 根拠 |
|---|---|---|
| 予約一覧をスマートフォンで見やすくしてほしい | 範囲外 | 質問1。X-01に当たる |
| 返却期限の通知メールが届かない | 範囲内 | 質問6。S-02のとおりに動いていない |
| 貸出履歴も移行してほしい | 範囲外 | 質問1。X-04に当たる |
| 備品に「保管場所」の項目を足してほしい | 範囲外 | 質問5。項目の追加は合意した内容に無い |
| 利用者が350名になりそうだ | 範囲外 | 質問4。前提A-03が変わる |
| 手引きの誤字を直してほしい | 範囲内 | 質問3。D-03の受入基準に必要 |
範囲外と判定しても、そこで終わりにしません。「変更依頼として受け付け、影響(期間・工数・他の成果物)を調べてお返事します」と伝え、決める人が判断します。入れると決まったら、スコープ記述書の版を上げて対象範囲に行を足します。
スコープクリープを防ぐ5つの習慣
スコープクリープは、合意の手続きを通らずに範囲が少しずつ広がっていくことです。次の習慣で、広がりを「見える変更」に変えられます。
| 習慣 | やること |
|---|---|
| 版を1つに決める | 承認済みの版を1か所に置き、会議ではその版を開く |
| 口頭の依頼を記録する | 打ち合わせで出た追加の話は、その場で「変更依頼として起票します」と言う |
| 小さな依頼も数える | 1件ごとは小さくても、件数と合計の工数を週次で共有する |
| 対象外を読み返す | 工程の区切りごとに、対象外の表を関係者と読み返す |
| 入れるなら何かを動かす | 追加するときは、期限・体制・他の範囲のどれを動かすかを一緒に決める |
スコープ記述書・要件定義書・WBS・SOW・プロジェクト憲章の違い
名前が似ていて混同されやすい5つの文書を、「いつ・誰が・何を決めるか」で比べます。
| 文書 | いつ | 誰が作る | 何を決めるか | 細かさ |
|---|---|---|---|---|
| プロジェクト憲章 | 立ち上げ時 | 立ち上げを決めた責任者 | プロジェクトを始めること、目的、責任者と権限 | 1〜2ページ |
| スコープ記述書 | 計画の最初 | プロジェクトの責任者と依頼側 | 成果物と対象外の境界、受入基準 | 数ページ |
| 要件定義書 | スコープの合意後 | 依頼側と開発側 | 範囲の内側で、システムが満たす機能・性能の中身 | 数十ページ以上 |
| WBS | 範囲が決まった後 | 開発側 | 成果物を作るための作業の分解 | 作業1件ずつ |
| SOW(作業範囲記述書) | 契約の前後 | 発注側と受注側 | 委託する作業、納品物、期間、役割分担 | 契約に添える文書 |
使い分けの判断基準です。
| 決めたいこと | 使う文書 |
|---|---|
| そもそも始めてよいか、誰が責任者か | プロジェクト憲章 |
| 何を作り、何を作らないか | スコープ記述書 |
| 作るものが、具体的にどう動くか | 要件定義書 |
| 誰が、どの作業を、いつまでに行うか | WBS |
| 外部に委託する範囲と納品物 | SOW |
| 合意した後に範囲を変えたい | 変更依頼(決まったらスコープ記述書を改版) |
スコープ記述書は、この中で最初に線を引く文書です。要件定義書は線の内側を詳しく書き、WBSは線の内側を作業に分け、変更管理は線を動かすときの手続きを担います。小さなプロジェクトでは、プロジェクト計画書の1章として書いても役割は同じです。
表計算ソフトに貼れるタブ区切り版
成果物と対象外の表は、表計算ソフトで管理すると並べ替えや絞り込みができます。セルA1に貼り付けてください。
成果物と受入基準:
No 成果物 内容 受入基準 確認する人
D-01 備品予約システム 予約・貸出・返却・備品管理の4機能 受入テストのシナリオ12本がすべて合格 総務部 山田
D-02 移行済みデータ 備品台帳320件 件数が一致し、抜き取り30件の内容が台帳と一致 総務部 鈴木
D-03 利用者向け手引き 予約から返却までの操作 総務部以外の社員2名が手引きだけで予約を完了できる 総務部 山田
D-04 管理者向け手順書 備品の登録・変更・廃棄、利用者の追加 担当者が手順書だけで備品を1件登録できる 総務部 鈴木
対象外:
No 分類 対象外とするもの 理由・扱い先
X-01 機能 スマートフォン専用アプリ 第2期で検討
X-02 機能 会議室の予約 既存の予定表で運用中
X-03 機能 備品の購入申請、棚卸し 現行のまま
X-04 データ 過去の貸出履歴の移行 台帳は総務部で保管
X-05 データ 備品の写真の登録 稼働後に総務部が登録
X-06 環境 社外からの利用 社内ネットワーク限定
X-07 環境 人事システムとの自動連携 月1回のCSV取り込み
X-08 時期 稼働後の機能追加 稼働後1か月の不具合対応まで
X-09 運用 稼働後の備品マスタの保守 総務部が実施
X-10 教育 全社員向けの説明会 手引きの配布で代える
よくある質問
Q. スコープ定義とは何ですか? A. プロジェクトで作るもの・やることと、作らないもの・やらないことの境界を決めて合意することです。結果をスコープ記述書にまとめます。
Q. スコープ記述書と要件定義書の違いは何ですか? A. スコープ記述書は範囲の境界を決め、要件定義書はその内側の中身を詳しく決めます。順番はスコープ記述書が先です。
Q. 対象外はどこまで細かく書けばよいですか? A. 関係者の誰かが「含まれる」と考えそうなものを、名前で書きます。目安は分類ごとに1〜3行、全体で10行前後です。
Q. スコープクリープを防げないときはどうすればよいですか? A. まず追加の依頼を1件ずつ記録して件数と工数を見える形にします。そのうえで、入れるものと引き換えに動かすもの(期限・体制・他の範囲)を決める場を設けます。
Q. 途中でスコープを変えてもよいですか? A. 変えられます。変更依頼として影響を調べ、決める人が承認し、スコープ記述書の版を上げて反映します。
まとめ
- スコープ定義は「作るもの」と「作らないもの」の境界を合意することです。
- 対象外を先に、具体名で書きます。理由か扱い先を添えます。
- 成果物には受入基準を1つずつ付けます。
- 「等」「随時」「必要に応じて」は名前と数字に置き換えます。
- 追加の依頼は6つの質問で判定し、範囲外は変更依頼として受けます。
- 承認した版を1つに決め、変えるときは版を上げます。
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「スコープ定義の書き方 スコープ記述書テンプレートと対象外の例」
株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。
WE ARE HIRING
RJCで一緒に開発しながら、
成長を楽しみませんか?
RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください!
- 127日年間休日
- 12時間平均残業時間
- 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ!
ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨(休暇 or 金一封)、11期連続の黒字決算。