スコープ定義書の書き方｜対象外・前提・完了条件まで合意する

2026年10月12日

「申請業務を効率化する」「顧客情報を一元管理する」。方向性としては分かっても、この言葉だけでは、どこまで作れば終わりなのかを判断できません。スコープ定義書では、目的に加えて、今回の対象・対象外・前提・成果物・受け入れる条件を合意します。

以下は社内申請の改善を題材にした一般的な実務解説です。記入例は説明用で、実在の案件や契約内容ではありません。契約に関わる範囲は、自社の責任者と締結済みの文書を確認してください。

Contents

「やること」だけを書くと境界が残る

「申請フォームを作る」と書いても、過去データの移行、スマートフォン対応、承認ルートの変更まで含むのかは分かりません。対象に含むものを詳しくするだけでなく、関連するが今回は行わないものも明示します。

ただし、対象外の一覧を長く並べればよいわけではありません。関係者が含まれると考えそうなもの、後で追加依頼になりそうなものを優先します。「その他はすべて対象外」という書き方では、説明不足を解消できません。

説明用の依頼「申請を便利にしたい」を、次のように整理できます。数字や条件は例であり、推奨値ではありません。

小さい画面では表を横にスクロールできます。

対象外にした業務でも、日常業務から消えるわけではありません。紙申請を移行しないなら、過去申請を照会する運用を残す必要があります。「作らない」ことが別の運用負担を生む場合は、その負担を受ける部門にも確認します。

前提は、計画を組むために置いた条件です。制約は、守る必要がある条件です。未決は、まだ判断できていない事項です。この三つを一つの欄に入れると、誰も確認していないことが確定事項に見えてしまいます。

「既存の認証が利用できる」は、未検証なら前提です。技術確認の担当と期限を置きます。「社外へ個人情報を出さない」は、該当する社内規程等に基づく制約です。「対象拠点を増やすか」は、判断者と必要情報を持つ未決事項として残します。

未決があるから会議ができない、と考える必要はありません。何が未決で、どの見積もりに影響するかを示し、仮置きしてよい範囲と確定を待つ範囲を分けます。仮置き条件が変われば再見積もりすることも合意しておきます。

開発担当の了承だけでは、利用部門の期待や運用担当の引き受け条件まで揃ったとは言えません。逆に、利用部門の期待だけで決めると、技術・費用・納期の成立性を置き去りにします。

定義書のレビューでは、対象範囲ごとに作成者・利用者・運用者を確認します。そのうえで、全体として範囲を承認する権限者を特定します。参加者全員の「異議なし」と、正式な承認は同じとは限りません。

合意記録には、対象版・判断日・承認者・条件を残します。コメントを反映して文書が変わった場合は、修正前の合意をそのまま最新版へ引き継がず、影響する箇所を再確認します。

開始後に「別拠点でも使いたい」と言われたら、まず定義書の利用対象と照合します。単なる設定変更なのか、新しい権限、説明、テスト、運用が必要なのかを確認し、必要なら変更要求へ進めます。

次の短い確認文は説明用です。

今回の対象は国内拠点の備品申請です。
追加拠点への展開は現行の対象外となっています。
権限・運用・確認作業への影響を調べ、日程と対応案を提示します。
範囲を変更する場合の判断者と、判断が必要な日を確認させてください。

最初から細部を過剰に固定するより、境界と変更の扱いを明確にする方が実務で使いやすくなります。目的は依頼を拒むことではなく、追加するなら何を変える必要があるかを双方が判断できる状態を作ることです。

対象・除外範囲を明確にする基本概念の確認に使用しています。業務例は独自の説明用です。 Atlassian：Project Scope（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。

背景と目的の違いも必要な作業に合わせて参照してください。

アイキャッチ写真：Gabriel Cox / Unsplash。職場の実写ではなくイメージ写真です。

よかったらシェアしてね！