3-1. 要求の収集と定義：スコープ記述書の作成

プロジェクト憲章が承認された後、計画策定フェーズの最初の一歩は「スコープの定義」です。スコープとは、プロジェクトで実施する作業と、生み出される成果物の範囲を指します。

要求（要件）の収集プロセス

スコープを決定する前段階として、ステークホルダーがプロジェクトに対してどのようなニーズ、期待、目標を抱いているかを洗い出す「要求の収集（Collect Requirements）」を行います。顧客が思い描いているイメージを、測定可能で検証可能な仕様へと変換するプロセスです。

要求を収集するための主な技法は以下の通りです。

技法名	概要	メリット	デメリット・注意点
インタビュー	ステークホルダーに1対1で直接対話し、要求を聞き出す。	個人の本音や背景事情を深く掘り下げやすい。	時間がかかるため、多くの関係者から広く意見を集めるのには不向き。
ファシリテーション・ワークショップ	主要なステークホルダー（開発側と業務側など）を集めて討議する。	異なる立場間の意見対立をその場で調整し、合意を形成しやすい。	発言力の強い人に議論が左右されやすく、綿密なファシリテーションが必要。
アンケート調査	質問票を配布し、多数の回答を収集して集計する。	多数のユーザーから広範な要求を短時間で定量的に収集できる。	質問の設計が難しく、深い背景や個別のニーズを汲み取りにくい。
プロトタイピング	動く試作品（モックアップ）を作成し、触ってもらってフィードバックを得る。	具体的なイメージが湧くため、「思っていたのと違う」というズレを減らせる。	試作コストと時間がかかる。顧客の期待値が上がりすぎるリスクがある。

収集した要求を分析し、最終的に「プロジェクトで作成する成果物」と「そのために行う作業」を明文化した合意文書が「プロジェクトスコープ記述書（Project Scope Statement）」です。

スコープ記述書には、以下の項目が明確に記載されます。

スコープ記述書の主要構成要素

数多くのステークホルダーから集めた多種多様な「要求（ニーズ）」は、フィルタリングと受け入れ基準の定義を経て、明確な「スコープ（合意された境界）」へと整理されます。

図 3-1：不揃いな「要求」を合意された「スコープ記述書」へと整理する流れ

プロジェクトの課題としてよく挙げられるのが、途中で少しずつ要件が膨れ上がる「スコープクリープ（Scope Creep）」です。

ステークホルダーから仕様の追加要望を受け、そのまま引き受けると、スケジュールや予算に影響を及ぼす可能性があります。

これを防ぐために、スコープ記述書の「プロジェクトの除外事項」に「本プロジェクトには、モバイル決済機能の実装は含まれません。もし追加する場合は、別途見積もりと契約変更が必要となります」と明記し、発注側と合意しておくことで、計画外のスコープ拡大を防ぐことができます。