スコープマネジメントというと今一つ何のことかよくわからないかもしれませんが、スコープは直訳すると「範囲」という意味で、

何をやって、何をやらないか、の範囲を決める、ことです。

プロジェクトマネジャーの中の知識エリアの一つである、「プロジェクトスコープマネジメント」がそれに該当します。

この知識エリアで必要な項目は以下の３つです。
①提供するプロダクトやサービスの範囲を明確にする（プロダクトスコープ→要件定義書の作成）
②そのためにどんな作業が必要になるかを全部洗い出す（プロジェクトスコープ→WBSの作成）
③スコープの変更管理方法を決める（特にお客様と）

プロジェクトマネジメントの本に書いてないようなところだけ補足します。

①プロダクトスコープ
何といってもこれが一番大事で一番難しいのですが、お客様の要望を聞いて何を作るのかを決めること。お客様には”What”を聞いてください。
例えば、
・何がお困りごとですか？
・どんな課題をお持ちですか？
・何か改善したいことはありますか？
などです。”Howはこちらから提案する”のが基本です。
やらないことも明確にしてくださいね、これを怠ると納品した後にお客様から、「なんでそれできないの？」と言われてしまいますので。例えば「Windows7以前のMS製のOSは対象外」とかです。

それから、「非機能要件」を定義することも重要です。
機能要件はお客様の要望を機能という形で表現すれば書けますが、非機能要件はお客様に聞いても基本的には答えてくれない要件で以下の6項目です。
・可用性　：運用スケジュールなど
・拡張性/性能　：どこまで拡張できるようにするかなど
・保守性　：保守体制をどうするかなど
・移行性　：システムの入れ替えをどうやるかなど
・セキュリティー　：不正アクセスの防止など
・環境/エコロジー　：CO2排出量など
この非機能要件は開発側が決めて提案しないと明確になりませんし、実装するためにも必要な要件なのです。
一番まずいのはこれらを決めずになんとなくで開発することです。

②プロジェクトスコープ
プロダクトスコープで決めた範囲の開発を行うために、必要な成果物とそれらを作成するために必要な「作業」を分解して構造化したものをWBS（Work Breakdown Structure）と言います。
WBSを作成する上で重要な点は、
・100％ルール
・抜け漏れをできる限り無くすためにメンバーと一緒に洗い出す
です。スケジュール作成のベースがこのWBSなので、WBSに抜けがあるとスケジュールに記載されないので、”これいつやればいいの？”となります。
プロジェクトマネジャーが一人でやると必ず抜け漏れが発生します。

③スコープの変更管理方法を決める（特にお客様と）
どういうプロセスで仕様変更を管理するかを、あらかじめお客様と合意しておくこと。
仕様変更は、時間、コスト、スコープ、にトレードオフが発生することがあるので、その決め方を合意しておくということです。

次回は、タイムマネジメント、の予定です。