目次
はじめに
本記事のねらい
本記事では、プロジェクトで「何を作るか」「どこまでやるか」をはっきりさせるための文書、プロジェクトスコープ記述書について解説します。難しそうに聞こえますが、やることリストと約束ごとを一枚にまとめたものと考えると分かりやすいです。ビジネスの新商品開発、社内の業務改善、学校の文化祭、地域イベントの運営など、規模や分野を問わず役立ちます。
なぜ必要なのか
プロジェクトが迷走する多くの原因は、期待のズレと作業の膨張にあります。「それもやってくれると思っていた」「そこまでは頼んでいない」などの食い違いは、最初に範囲を言葉で固めていないと起きやすいです。スコープ記述書を用意すれば、関係者が同じ地図を見て進めます。締切や予算の見通しも立てやすくなります。
身近な例でイメージする
引っ越しを例にすると、スコープ記述書は「運ぶ荷物の一覧」「運ばない物」「当日の条件（エレベーターの有無、養生の要否）」「制約（車両は1台のみ、作業時間は2時間）」「完了の基準（全荷物が新居の指定場所に置かれている）」を明記した紙に近いです。これがあると、追加料金の判断や作業手順の相談がスムーズになります。
本記事で扱う内容
次のポイントを順に取り上げます。
- スコープ記述書の定義と全体像
- 記載する主な項目（成果物、作業範囲、前提条件、制約条件、除外事項、受け入れ基準など）
- 文書の役割と効果（合意形成、変更管理、品質の担保）
- 作成のステップとコツ（聞き取り、たたき台、レビュー、合意）
- 試験対策で問われやすい「適切な説明」の押さえどころ
どんな人に役立つか
- 初めてプロジェクトを任された方
- 進行中の案件で手戻りが多いと感じている方
- 資格学習で要点を整理したい方
日頃の業務で使える具体例を交え、専門用語はできるだけ噛み砕いて説明します。
読み進め方
まず全体像をつかみ、その後に各項目の意味と書き方を確認します。最後に、試験問題で問われやすい表現を整理します。読みながら、自分の現場に置き換えてメモをとると理解が深まります。
次の章に記載するタイトル: プロジェクトスコープ記述書とは何か
プロジェクトスコープ記述書とは何か
前章のおさらい
前章では、本記事の目的と、プロジェクトで「範囲を決めること」の大切さを確認しました。ゴールを曖昧にしたまま進めると、手戻りや無駄な作業が増えるという前提を共有しました。
一言でいうと
プロジェクトスコープ記述書は、「このプロジェクトで何をするか／しないか」を一枚で示す設計図のような文書です。達成したいゴール、作るもの（成果物）、やる作業の範囲、やらない作業、前提や制約をまとめ、関係者の認識をそろえます。
なぜ必要か
- 期待の食い違いを防ぎます：あとから「それもやってくれると思っていた」を減らします。
- 優先順位を決めやすくなります：限られた時間と予算で、何に力を注ぐか判断できます。
- 合意のよりどころになります：議論が迷子になったとき、原点に立ち返れます。
どんな場面で役立つか
- 新商品サイトを作るとき：公開日に間に合わせるため、初回リリースの内容を限定します。
- オフィス移転：必須の工事と、後回しにできる内装を分けます。
- 社内イベント：企画から当日運営まで、どこまで担当するかを明記します。
例でイメージする
カフェ開店プロジェクトの例です。
- 目的：開店から3か月で常連客を50人作る。
- 成果物：店舗内装、メニュー表、公式サイトの基本ページ。
- 含む作業：内装工事、メニュー開発、スタッフ採用、簡易サイト制作。
- 含まない作業（除外）：デリバリーアプリ連携、通販の開始、2号店の検討。
- 前提：物件契約が完了している。
- 制約：予算上限500万円、開店日は8月1日固定。
- 受入の目安（基準）：保健所の許可取得、試食会での評価3.5/5以上。
こうして書くと、関係者は同じ絵を見ながら話せます。したがって、意思決定が速くなります。
他の文書との違い（よく混同する点）
- 計画書との違い：計画書は「いつ・誰が・どう進めるか」。スコープ記述書は「何をやる／やらないか」。
- 要件定義との関係：要件は「望む機能や条件の一覧」。スコープ記述書は、そのうち「今回扱う範囲」を線引きします。
- 契約書との関係：契約書は法的な約束。スコープ記述書は実務の合意メモで、契約の添付資料になることもあります。
作るタイミングと更新のしかた
- タイミング：プロジェクトの初期に作ります。企画のたたき台をもとに、関係者の合意を取りつけます。
- 更新：変更が出たら、その理由・影響・最新の範囲を追記し、再合意します（変更の記録を残します）。
形式と分量の目安
- 書式は自由で構いません。1〜2ページでも十分です。
- 読む人を想定し、専門用語は避け、短い文で要点を箇条書きにします。
- 図や簡単な一覧があると、初めての人にも伝わりやすいです。
よくある失敗と避け方
- 曖昧な言い回し：「適宜」「できるだけ」などは避け、具体的な数・日付・条件を書きます。
- 除外事項の書き漏れ：やらないことほど明記します。あとからの追加要求を防げます。
- 関係者のレビュー不足：実務担当・決裁者・利用者代表の視点で確認します。
- 更新されない：最新でない文書は混乱のもとです。変更があれば必ず更新します。
活用の流れ（シンプル版）
1) 作る → 2) 関係者で合意する → 3) 変更があれば更新する → 4) 日々の判断や最終受け入れの基準として参照する
注意点
スコープ記述書は詳細すぎても読まれません。重要な決めごとに絞り、後から深掘りする資料（計画書や設計書）と役割分担をさせます。必要なら付録に詳細を逃がし、本体は軽く保ちます。しかし、受け入れ条件や除外事項だけは具体的に書き切ることをおすすめします。
次の章に記載するタイトル：プロジェクトスコープ記述書に含まれる主な内容
プロジェクトスコープ記述書に含まれる主な内容
前章の要約：プロジェクトスコープ記述書は、プロジェクトの範囲と合意事項を一つにまとめ、関係者の行き違いを減らす土台となる文書であることを紹介しました。どんな成果を目指し、何をやるか・やらないかを明らかにする点が要でした。
本章では、実際にどんな項目を入れるのかを、具体例とともに解説します。
1. 成果物の明確化（完成条件・品質基準を含む）
- 目的：最終的に「何を受け渡すのか」をはっきりさせます。
- 含める内容：
- 成果物一覧（例：Webサイト本体、管理画面、操作マニュアル、月次レポート）
- 完成の定義（受け入れ基準）
- 例：「会員登録フォームで必須項目が未入力の場合、エラー表示が出る」「テスト項目100件中100件合格」
- 品質基準
- 例：「主要3ブラウザの最新2バージョンで表示崩れなし」「平均応答時間2秒以内」
- 書き方のコツ：成果物ごとに「状態が確認できる表現」を使います（OK/NGがはっきり判断できる文）。
2. 作業範囲の特定（WBSの考え方）
- 目的：「どんな作業をどの粒度まで行うか」を具体化します。
- WBSとは：作業を大きい塊から小さな手順へと分解した一覧です。難しい図でなく、箇条書きでも機能します。
- 例（簡易）
- 計画：要件確認、スケジュール策定
- 設計：画面設計、データ設計
- 製作：コーディング、コンテンツ作成
- 試験：単体テスト、結合テスト、受け入れテスト
- 移行・公開：データ移行、リリース作業
- 教育・運用：操作説明、初期運用サポート
- 書き方のコツ：作業名は「誰が見ても同じ作業を想像できる」単語にします。必要に応じて前後関係（順番）も示します。
3. 前提条件・制約条件（予算・納期など）
- 前提条件：成立していると見なして進める事項。
- 例：「外部APIが予定どおり提供される」「既存データは整備済みである」
- 制約条件：外せない枠やルール。
- 例：予算上限、納期（公開日固定）、利用可能なツールの制限、セキュリティ基準、法令やガイドライン遵守
- 書き方のコツ：数字や日付を具体的に入れ、曖昧さを避けます（例：「予算上限800万円」「β公開は9月30日まで」）。
4. 除外事項（対象外の作業や成果物）
- 目的：後から「それもやってくれると思っていた」を防ぎます。
- 例：
- スマホアプリは対象外（今回はWebのみ）
- 既存データのクレンジングは対象外
- 24時間の有人サポートは対象外（平日9〜18時のみ）
- 書き方のコツ：対象外の理由や代替案があれば添えます（例：「アプリは次期計画で検討」「夜間はチャットボット対応」）。
5. ステークホルダーの要求事項（関係者の期待）
- 誰の声を載せるか：発注者、利用者代表、運用・保守チーム、経営層、法務・セキュリティ担当など。
- 含める内容：
- 要求の概要と背景（なぜ必要か）
- 優先度（高・中・低）
- 受け入れ基準（何が満たされれば要求が満たされたと言えるか）
- 例：
- 利用者代表：「購入手続きは3画面以内」→ 試験で平均完了時間が2分以内なら合格
- 運用チーム：「障害時の連絡手順を1ページで」→ マニュアルにフローチャートを掲載
- 書き方のコツ：要求をそのまま羅列するのではなく、目的と合格ラインを一緒に記します。
6. プロジェクトの目的・ゴール（成功の物差し）
- 目的：なぜこのプロジェクトを行うのか（背景・解決したい課題）。
- ゴール：いつまでに、何を、どの状態にするか。数値が置けるなら置きます。
- 例：
- 「問い合わせ対応を改善し、平均返信時間を3か月で30%短縮」
- 「ECサイトの売上を四半期で10%伸ばすため、新規会員登録率を2ポイント向上」
- 書き方のコツ：ゴールはチームが日々判断に使える表現にします（迷ったらゴールに照らす）。
7. 補足しておくと便利な要素
- リスクのメモ（例：キーパーソンの長期不在の可能性）
- コミュニケーションの窓口（例：承認者、問い合わせ先）
- 変更が起きたときの合意方法（例：変更申請の手順）
上記の項目を押さえると、誰が読んでも「何を作り、どうなれば終わりか」が一目で分かる文書になります。項目名は組織に合わせて調整してかまいませんが、完成条件と対象外の明記だけは欠かさないようにします。
プロジェクトスコープ記述書の役割・意義
プロジェクトスコープ記述書の役割・意義
前章の振り返り
前章では、スコープ記述書に入れる主な項目（目的、対象範囲と除外範囲、成果物、受入基準、制約・前提、体制、変更や承認の手続き）を、身近な例とともに整理しました。本章では、それらの項目が実務でどのように効くのか、役割と意義に焦点を当てて説明します。
なぜ重要なのか（全体像）
プロジェクトスコープ記述書は、関係者の合意を形にする土台です。これがあると、方向性や作業の範囲がはっきりし、認識のズレや追加作業の雪だるま（スコープクリープ）を防げます。進行中の新しい要望が出ても、最初の合意に立ち返って判断でき、終わりに「できたか」を確認する基準にもなります。
役割1：合意形成の土台になる
- 目的やゴールを一枚の文書にまとめ、関係者の視点をそろえます。
- 会議で意見が割れても、文書を拠り所にして早く合意に到達できます。
役割2：スコープクリープ（追加作業の膨張）を防ぐ
- やること／やらないことを明記して、作業の線引きをはっきりさせます。
- 新しいアイデアが出ても、今やるのか後回しにするのかを判断できます。
役割3：変更管理の基準になる
- 変更の可否を「目的・成果物・受入基準」に照らして評価します。
- 影響（予算・納期・品質）を見える化し、合意のうえで反映します。
役割4：検収と終結の判定基準になる
- 受入基準に沿って成果物を確認し、完了を公正に判断できます。
- 手戻りを減らし、関係者の納得感を高めます。
役割5：コミュニケーションの共通言語になる
- 専門用語を最小限にし、同じ言葉で話せるようにします。
- 新しく参加したメンバーへの説明資料としても機能します。
役割6：リスクを下げ、コストと時間を守る
- 早期に認識の差を見つけ、手直しのコストを抑えます。
- 優先順位が明確になり、重要な作業から着手できます。
具体例で見る効果
- 例1：企業サイトの改修
- 記述書で「トップページと採用ページのみ対象」「問い合わせ機能は既存のまま」と定めました。途中で「ニュース機能も追加してほしい」と依頼が来ましたが、影響（2週間の延長と追加費用）を提示し、次フェーズへ回す判断ができました。
- 例2：社内イベントの企画
- 「参加200名まで、会場は社内ホール、飲食は軽食のみ」と明記。後日「外部ゲスト50名追加」の案が出ましたが、警備や予算の増を根拠に別企画として切り分け、当初の計画を守れました。
よくある誤解と防止策
- 誤解：「詳細は後で詰めればよい」
- 防止策：最低限の受入基準（合格ライン）だけは先に決めます。
- 誤解：「書類は作ったら終わり」
- 防止策：変更があれば日付と理由を追記し、最新版を常に共有します。
- 誤解：「関係者が多いと合意形成に時間がかかる」
- 防止策：意思決定者と相談役を分け、承認ルートを簡潔に定めます。
意義のまとめ（実務で得られる価値）
- 判断が速くなります。迷ったら記述書に立ち返ればよいからです。
- 無駄な作業が減ります。やる・やらないの線が明確になるからです。
- 納期と品質を守りやすくなります。優先順位が固定されるからです。
- 関係者の満足度が上がります。何をもって成功とするかが共有されるからです。
したがって、プロジェクトスコープ記述書は「最初に作って終わりの文書」ではなく、開始から終結まで意思決定を支える実用的な道具です。
次の章に記載するタイトル：プロジェクトスコープ記述書の作成ステップ
プロジェクトスコープ記述書の作成ステップ
前章の要点の引き継ぎ
前章では、プロジェクトスコープ記述書が関係者の共通言語となり、意思決定の基準になり、手戻りや無駄を減らす羅針盤になることを説明しました。この章では、実際にどのような手順で作成するかを具体的に示します。
全体の流れ
- ニーズ・要求の収集
- 目標・成功基準の明確化
- 成果物・作業範囲・除外事項・制約条件の記述
- リスク・変更管理の方針化
- レビューと承認、公開と保守
ステップ1：関係者の把握とニーズ・要求の収集
まず、影響を受ける人や組織（例：依頼元、利用者、運用担当、外部ベンダー）を洗い出します。次に、話を聞き、既存資料を見て、必要なことを集めます。
- 収集方法の例：短いインタビュー、共同ワークショップ、アンケート、既存契約や規程の確認
- 聞く観点：誰が、何のために、いつまでに、どのように使うか、満足の基準は何か
- 出力のコツ：箇条書きで「要望」「理由」「優先度（高・中・低）」をセットで残す
例）「カート画面を2クリックで購入完了にしたい（離脱防止のため／優先度：高）」
ステップ2：目標と成功基準の明確化
集めた声をもとに、到達したい状態を一文でまとめ、測れる指標を置きます。
- 目標の例：「オンライン注文の完了率を今期末までに10%向上させる」
- 成功基準の例：注文完了率、ページ表示速度、問い合わせ件数などの具体的な数値や範囲
- 検収・受け入れの観点：「何ができたら完了か」を先に書く（例：主要3ブラウザでの購入完了テストに全て合格）
ステップ3：成果物の定義（作るものを具体化）
作るものを「名前」「中身」「完成の条件」で書きます。画像や画面一覧、マニュアルなど、目に見える単位に分けます。
- 例：
- 「購入フローの画面一式：トップ、商品詳細、カート、決済、完了」
- 「利用者マニュアル：PDF 20ページ程度、検索機能付き」
- 完成の条件の例：「文言レビュー完了」「表示崩れなし」「誤字ゼロ」
ステップ4：作業範囲の分解（やることを細かくする）
大きな作業を扱いやすい小さな塊に分けます。誰が担当か、順番やつながりも書きます。
- 分解の例：設計／作成／テスト／移行／教育／リリース／広報
- 役割分担：内製か外注か、依頼元の確認が必要な点は何か
- 依存関係：外部決済サービスの仕様確定後に連携開発を開始、など
ステップ5：除外事項の明記（やらないことをはっきり）
期待の食い違いを防ぐため、対象外を明記します。
- 例：「モバイルアプリは対象外」「越境ECは今回の範囲に含めない」「新規倉庫システムとの連携は行わない」
ステップ6：制約条件と前提条件の整理
動かせない条件（制約）と、成り立つための条件（前提）を書きます。
- 制約の例：総予算上限、納期、利用する既存システム、社内規程や法令
- 前提の例：商品データは依頼元が提供、撮影は外部会社が担当、テスト用アカウントは1週間前に発行
ステップ7：主要リスクと備え
起こりそうな困りごとと、そのサイン、備えを書きます。
- 例：データ移行に時間がかかる → 早めにサンプルで試す、移行手順を事前に作ってリハーサルを実施
- 例：承認が滞る → 代理承認者を決め、締切をカレンダーに登録
ステップ8：変更管理の方針
途中で内容が変わる可能性に備えて、手順を決めます。
- 申請→影響確認（費用・期間・品質）→承認→記録→通知の流れ
- 誰が承認するか（例：発注側の担当者とプロジェクト責任者）
- 版管理の方法（例：日付と版番号を付ける、変更履歴を冒頭に書く）
ステップ9：レビューと合意形成（承認）
関係者に読み合わせを依頼し、疑問や反対意見を整理します。誤解が残らない表現に直し、承認者からOKをもらいます。
- レビューの工夫：紙1枚の概要版を先に配る、コメント期限を決める、判定は「承認／差戻し」の二択にする
- 合意の見える化：承認者名、日付、版番号を明記し、保管場所を共有
ステップ10：公開と保守
決定した文書をアクセスしやすい場所に置き、更新ルールを決めます。
- 置き場所の例：社内ポータル、共有ドライブ、チケット管理ツール
- 更新のタイミング：大きな変更時、四半期ごとの見直し
サンプル文面（そのまま使える例）
- 目的：本プロジェクトは、オンライン購入体験を改善し、今期末までに注文完了率を10%向上させることを目的とします。
- 成果物：購入フローの画面一式、管理画面の設定、利用者マニュアル（PDF）。
- 範囲：設計、作成、テスト、移行、教育、リリース後1か月の初期対応。
- 除外：モバイルアプリ開発は対象外とします。
- 制約：総予算は○○万円、リリースは○月末、既存会員IDは変更不可。
- 前提：商品画像は依頼元が提供します。
- 変更管理：変更は申請書に記入し、発注側担当者とプロジェクト責任者の承認を得ます。
チェックリスト（提出前の最終確認）
- 誰のためのプロジェクトか、関係者が全員載っているか
- 目標に数字や具体的な基準があるか
- 成果物が名前で特定でき、完成条件があるか
- 作業範囲と除外事項を分けて書いているか
- 制約と前提を区別しているか
- 主要リスクと備えを書いたか
- 変更管理の手順と承認者が明確か
- 版番号、日付、保管場所が明記されているか
よくある落とし穴と回避策
- あいまいな表現：「適切に」「なるべく」を避け、数値や条件で置き換える
- 関係者の抜け：運用担当やサポート窓口など、後工程の人も含める
- 手段への飛びつき：先に「何を達成したいか」を固め、方法はその次に決める
- 将来の願望の混入：今回やることと次回以降に回すことを分けて書く
- 除外の書き忘れ：誤解されやすい境界線は必ず「対象外」で明記
- 難しい言葉：専門用語は避け、一般的な言い回しに言い替える
小さなケースでイメージを固める
社内ポータル刷新の場合：
- 目標：社員が探し物を1分以内に見つけられる状態にする
- 成果物：トップページ、検索、部門ページのテンプレート、利用ガイド
- 除外：スマホ専用アプリは対象外
- リスク：既存記事の移行が遅れる → 自動移行ツールを試し、移行用チェックリストを準備
進め方のコツ
- 1〜2時間の短い打合せを複数回に分け、早い段階からドラフトを見せる
- 図や箇条書きを多用し、1文を短くする
- 用語の定義を冒頭に置き、迷いやすい言葉をそろえる
試験問題等で求められる「適切な説明」
試験問題等で求められる「適切な説明」
前章のふりかえり
前章では、プロジェクトスコープ記述書を作る手順を、目的と成果物の確認、作業の洗い出し、除外・前提・制約の明文化、関係者レビューと合意の流れで整理しました。具体例を交えて、誰が読んでも同じ理解になる書き方を重視しました。
試験での正解フレーズ（まず覚える）
「プロジェクトの成果物や作業範囲、除外事項、前提条件・制約条件を明確に記述し、関係者の認識合わせや合意形成に使う文書」です。これを軸に選択肢を見比べます。
言い換えに強くなる（出題でよく使われる表現）
- 関係者＝ステークホルダー、関係部門
- 認識合わせ＝共通理解、すり合わせ
- 合意形成＝合意、了承取得
- 前提条件＝成り立つための条件、前提
- 制約条件＝守るべき決まり・制限、条件
- 作業範囲＝実施範囲、対象範囲、含むもの
- 除外事項＝含めないもの、対象外
よくある誤り選択肢と見分け方
- 「詳細なスケジュールやコストをまとめる文書」
- 範囲ではなく計画全体の管理に寄っています。計画書の領域です。
- 「変更要求の受付方法や手順を定める文書」
- 変更管理の話です。スコープ記述書は“何をやる/やらない”を決めます。
- 「運用手順や保守手順を説明する文書」
- これは運用マニュアルです。
- 「品質基準だけを定める文書」
- 品質は要素の一つですが、スコープは範囲全体を示します。
- 「作業の手順書や担当者割り当てを示す文書」
- 手順や担当は別資料で扱うことが多いです。スコープ記述書は範囲の定義が中心です。
しかし、選択肢に一部正しい要素（例: 成果物の説明）が含まれていても、範囲・除外・前提・制約・合意の観点が欠けていれば不正解になりやすいです。
判断のコツ（2軸で見る）
- 軸1: 範囲を定義しているか（成果物、作業範囲、除外）
- 軸2: 条件を明確にして合意に使うか（前提、制約、認識合わせ）
したがって、この2軸を満たす説明を選びます。
例題と解説
【例題1】「プロジェクトスコープ記述書」に関する説明として適切なものはどれか。
A. プロジェクトの実行順序と担当者を割り当てる文書
B. 変更要求の受付窓口と流れを定める文書
C. 成果物・作業範囲・除外・前提・制約を明確にし、関係者の合意に使う文書
D. 完成品の品質試験の方法だけをまとめた文書
- 正解: C
- 解説: Cは範囲と条件、合意の要素を押さえています。Aは進め方、Bは変更管理、Dは品質試験に限定されており不適切です。
【例題2】次の記述は正しいか。
「プロジェクトスコープ記述書は、プロジェクトで実施する作業の順序と担当者を定める文書である。」
- 正解: 誤り
- 解説: 作業の順序や担当は計画・スケジュールの領域です。スコープ記述書は“何をやる/やらない”と“その条件”を定め、合意に使います。
直前チェックリスト（10秒）
- 成果物・作業範囲・除外が言及されているか
- 前提・制約が明記され、合意や認識合わせに使うと書いてあるか
- スケジュールやコスト、手順の詳細に偏っていないか
まとめと注意点
まとめと注意点
前章の要約と本章のねらい
前章の冒頭では、スコープをあいまいにしたまま進めると手戻りや納期遅延、コスト増につながること、そして初期段階で十分に定義し関係者で合意する重要性を確認しました。本章では、その考えを踏まえつつ、実務で役立つ要点と注意点を整理します。
おさらい：この記事の要点
- スコープ記述書は「やること・やらないこと・完了条件」を一枚にまとめる土台です。
- 早い段階で関係者が読み合わせ、同じイメージを持てるまで言葉をそろえます。
- 変更が出たら更新し、版数・日付・承認者を残します。
- 受け入れ基準は測れる言葉にし、誰がどう確認するかまで書きます。
- 目的（達成したい姿）と成果物（形になるもの）を分けて書きます。
注意点（落とし穴と回避策）
- あいまいな表現
- 落とし穴: 「使いやすい」「早い」など主観的な言葉だけで書く。
- 回避策: 「主要操作は3クリック以内」「平均応答0.8秒以下」のように測れる基準を添えます。
- ツール名や解決手段で固定する
- 落とし穴: 「○○ツールで実装する」と手段に縛られる。
- 回避策: まず目的と要件を書き、手段は別資料に切り出します。
- 関係者の抜け
- 落とし穴: 現場ユーザーや運用担当の声が反映されない。
- 回避策: 利用者代表、運用、セキュリティ、経理などの役割をリストし、レビュー者を明記します。
- 受け入れ基準があいまい
- 落とし穴: 完了の合図が人によって違う。
- 回避策: 試験観点、確認手順、判定者をセットで書きます。
- 更新されない文書
- 落とし穴: 初版のまま現場は口頭で変更。
- 回避策: 変更申請→影響評価→承認→版上げ→通知の流れを決め、履歴を残します。
現場で使えるチェックリスト
- 目的は一文で言えますか（誰が・何のために）。
- やること・やらないことが対で書かれていますか。
- 成果物の一覧に、受け入れ基準と責任者が紐づいていますか。
- スケジュールの節目（マイルストーン）と判断基準がありますか。
- リスクと前提条件に、対応方針と見直し時期が書かれていますか。
- 変更手順、承認者、連絡方法が明記されていますか。
- 版数、日付、作成者、レビュワーが最新ですか。
コミュニケーションと運用のコツ
- 15分レビューを定例化します。毎週短く読み合わせ、誤解を早期に潰します。
- 図を1枚入れます。全体像（対象範囲の枠）や関係図があるだけで理解が進みます。
- 言葉の辞書を付けます。用語集に3〜5語だけでも定義するとズレが減ります。
- 合意のサインをもらいます。メールの「承認」でも十分です。証跡を残します。
ミニ例：Webサイト改修のスコープ
- やること: トップページのデザイン刷新、主要導線の見直し、スマホ表示の最適化。
- やらないこと: 会員機能の追加、決済システムの変更、既存CMSの入替。
- 成果物: 新デザイン一式、スタイルガイド、テスト結果レポート。
- 受け入れ基準: 主要ページの読み込み平均1.0秒以下、CVRを現状比+10%、スマホでの主要操作3クリック以内。
- 体制・合意: マーケ責任者が受け入れ判定、運用担当が公開可否を承認。
継続的な見直しのすすめ
プロジェクトは進むほど学びが増え、優先度も変わります。スコープ記述書も一度で終わりではありません。変更要求の窓口を一本化し、影響や費用と合わせて判断し、合意した内容だけを反映します。小さく頻繁に更新し、常に最新版を共有することが成功への近道です。
最後に
スコープ記述書は、チームの共通言語であり、迷ったときの北極星です。「やること・やらないこと・完了条件」を明確にし、合意と更新を丁寧に積み重ねれば、多くのトラブルは未然に防げます。今日から使えるチェックリストとミニ例を参考に、自分の現場に合わせて磨き上げてください。