#3-3　スコープの定義

前回（昨日）の記事に続き、スコープのお話です。

↓前回（昨日）の記事

要求事項がまとまったら、プロジェクトのスコープの内容を定義します。

「プロジェクト憲章」や「スコープ・マネジメント計画書」、「要求事項文書」を基に、プロジェクト（やプロダクト）に関する詳細な内容を記した「プロジェクト・スコープ記述書」を作成します。

集まった情報を基に、専門家の判断、分析、代替案の作成、ファシリテーション型ワークショップなどによって、具体的な内容を定めていきます。

プロジェクト文書一覧（『PM BOK』第７版より）

「プロジェクト・スコープ記述書」

プロジェクト・スコープ記述書には、以下の内容が記載されます。いわば、「要件定義書」。

　①プロダクト・スコープ（Prpduct Scope）
　　：プロダクトやサービス、所産の特性（仕様）。
　　　プロダクトやサービス、所産を特徴づける機能（フィーチャー/Feature）の範囲。

　②プロジェクト・スコープ（Project Scope）
　　：特有の機能を有するプロダクトやサービスを創造するために実行しなければならない作業の範囲。
　　　プロジェクトスコープを完了するための作業のこと。

　③主要成果物（Major Deliverables）

　④受入れ基準（Acceptance Criteria）
　　：開発者による納品と依頼者による受け入れ（外注の場合支払い）をスムーズに実施するために、どのようなチェック項目で、誰がどのように判断し、を完了するか、ということを具体的に明記しておきます。

　⑤プロジェクトからの除外事項（Project Exclusions）
　　：ステークホルダーが期待しないことや計画外の作業を承認を得ずに実施してしまうリスク予防のために明記する。

　⑥前提条件（Assumptions）
　　：計画プロセスにおいて、証拠や実証なしに確実であるとみなされた要因。仮定条件。
　　　未来の仮定に絶対はないので、基本的にリスクを伴うもの。
　
　⑦制約条件（Contraints）
　：予算やスケジュールなど、プロジェクトやプロセス実行に影響を与える制限要因。
　　　契約によって存在するプロジェクトの場合は、契約条項も制約条件になる。

↓前提条件と制約条件については、以下の記事にも。

優先順位付け

「プロジェクト・スコープ記述書」の作成の過程で、ステークホルダーの要求事項を収集すると、要求事項同士が対立することがあります。

例えば、開発費が5000万円であれば１年で完成できるけど、そんなに開発費をかけていたらプロジェクトとして赤字になってしまう。一方、市場動きやニーズ的には、１年後に完成させて発売するのが好機、というような状態です。
オリンピックやワールドカップ、選挙など、世界的な大きな動きに間に合せるという要求は、根拠として強くなりがちです。
１年で完成するという要求が、開発コストを3000万円以下にするという要求より優先される場合、5000万円の開発費で１年後の完成を目指す、という承認を得えて、プロジェクトのスコープの内容を決定していきます。

これは大まかな例ですが、プロジェクトの活動は不確実性を伴っていて、スタート地点に近ければ近いほど、不確実性は高いです。
そのため、要求が変わることは前提であり、その変更によって当初は対立しなかった他の要求事項とバッティングしてしまうことは良く起こります。

全ての要求事項に応えることは、ビジネスという制約とリソースが有限であることから不可能です。
優先順位の根拠を明確に提示して、ステークホルダーの承認を得ておくことで「こんな話聞いてなかった」というトラブルを予防することが出来ます。

「スコープの定義」は、プロジェクトマネージャーの「何とかする」スキルがより求められる場面かもしれません。