スコープ・マネジメント

スコープ・マネジメントの対象

建設業者は工事現場に柵を立てて境界を示します。プロジェクトのスコープを定める目的も同じです。スコープ・マネジメントでは、プロジェクトに必要な作業を明確にし、合意した範囲内でチームがすべての作業を完了できるようにします。

スコープを特定し、管理し、コントロールする方法を事前に計画します。すべてのステークホルダーから要求事項を収集し、明確に定義したスコープについて正式な承認を得ます。スポンサーや少数の関係者からしか要求事項を収集しないと、適切なスコープを定められないおそれがあります。大規模なプロジェクトでは要求事項の収集により多くの時間、労力、資源がかかるため、明確な定義が特に重要です。

承認されたスコープを基準に、作業がスコープ・マネジメント計画の範囲内に収まるようにします。ゴールドプレーティング、つまり合意していない追加作業は禁止です。スコープを継続的に監視し、どの作業がプロジェクトの範囲内で、どの作業が範囲外かを誰もが判断できるようにします。

スコープの変更が時間、コスト、リスク、品質、資源、顧客満足度などの関連領域に与える影響を評価します。統合変更管理の手順に沿って変更を承認します。変更の提案者が変更要求書を更新し、変更管理台帳でその変更を追跡します。

原寸大の図を開く ↗

原寸大の図を開く ↗

プロダクト・スコープ

プロダクト・スコープは「顧客は何を求めているか」という問いに答えるものです。組織は、別のプロジェクトとしてプロダクト・スコープを定義することも、現在のプロジェクトで要求事項を収集しながら定義することもできます。

ソフトウェア・プロジェクトでは、「社内外の顧客の要求事項を満たす新しいワークフロー・アプリケーション」がプロダクト・スコープの例です。プロジェクトがそのスコープを満たしたかどうかを確かめるには、完成したアプリケーションを、要求事項文書とプロジェクト・スコープ記述書に記録した要求事項と照合します。

プロジェクト・スコープ

プロジェクト・スコープとは、プロダクト・スコープを実現するために必要な作業です。ソフトウェアの例では、アプリケーションの開発に加え、会議や報告など、その提供を支える計画、調整、管理の活動も含みます。これらの作業は、プロジェクトマネジメント計画と、その一部であるスコープ・マネジメント計画に記載します。プロジェクトやフェーズの終了時に、完了した作業をプロジェクトマネジメント計画のスコープ・ベースラインと照合し、合意したスコープを満たしたかを確認します。

スコープ・マネジメント計画

スコープ・マネジメント計画は、スコープの計画、実行、コントロールを扱います。ここで用いるプロセスの枠組みでは、チームはプロジェクトマネジメント計画の策定プロセスでスコープ・マネジメント計画を作成し、プロジェクトマネジメント計画に組み込みます。この計画で扱う項目は次のとおりです。

• プロジェクトでスコープを実現する方法。
• スコープの実現に必要なツール。
• チームが考慮すべき組織体の環境要因。
• チームに必要な組織のプロセス資産。
• プロジェクト全体を通じてチームがスコープを管理し、コントロールする方法。

組織はスコープ・マネジメント用のテンプレート、様式、または基準を用意しておくべきです。これらはプロジェクトの遂行に欠かせません。計画の一部は標準化できますが、プロジェクトごとに固有の計画が必要です。プロジェクトマネジャーは、スコープ・マネジメント計画を指針として、終結までプロジェクトを導き、その実績を測定します。

計画は段階的に策定し、計画作業中に改訂できます。まずスコープを定義する方法を決めます。プロジェクト全体の計画ができたら、そのスコープを実行し、コントロールする方法を決め、スコープ・マネジメント計画に追記します。その後、人的資源の計画などを進める中で追加のスコープが明らかになり、再度改訂が必要になることもあります。

計画を作成するには、プロジェクトマネジャーがスコープを十分に理解している必要があります。作業を始める前に、プロダクト・スコープとプロジェクト・スコープの両方を明確にします。スコープ・マネジメント計画の策定は、プロジェクトマネジメントに欠かせない作業です。

スコープ・マネジメントのプロセス

1. 要求事項を特定します。プロジェクト憲章に記載されたビジネスケースを参照し、各要求事項がプロジェクトを支えるかどうかを確認します。
2. プロダクト・スコープとプロジェクト・スコープを定義する際は、ステークホルダーのニーズを考慮します。
3. 作業分解構成図（WBS）を使い、スコープを管理しやすい小さな単位に分割します。
4. 顧客の視点でプロセスを設計します。
5. プロジェクトを通じてスコープの実績を測定し、必要に応じて調整します。

不要な作業は断れるようにしておきます。スコープを追加すると、コスト、時間、労力が増えます。

要求事項の収集

要求事項は、定めた目標を達成するためにプロジェクトや製品に何が必要かを示します。品質、業務プロセス、規制、コンプライアンス、プロジェクトマネジメントなどが対象になり得ます。要求事項の収集では、製品とプロセスの両方の要求事項を扱います。各要求を採用する前に、目標に合致するかを確かめます。

立ち上げ時に、プロジェクト憲章にプロジェクトと製品の概要レベルの要求事項を記載します。要求事項の収集では、すべてのステークホルダーからさらに詳しい情報と関連する前提条件を集めます。要求事項の漏れは、プロジェクトの失敗、度重なる変更、プロジェクト全体にわたる対立につながるおそれがあります。

まずステークホルダーを特定し、ステークホルダー登録簿に記録します。プロジェクトによってはステークホルダーが数百人に及び、グループごとに意見の集め方を変える必要があります。プロジェクト作業の開始前に、要求事項の収集に必要な時間と労力を確保します。収集が不十分だと、費用も手間もかかる変更が生じるおそれがあります。過去の情報や教訓が役に立ちます。プロジェクトとステークホルダーに合った手法を選びます。これらの手法はリスク・マネジメントでリスクを特定する際にも使えます。

過去の記録の確認

過去の記録と教訓から、類似プロジェクトで求められたことを把握し、関連するプロセスを特定できます。新しく参加した人が各チームの期待を理解するのにも役立ちます。また、他のプロジェクトマネジャーがスコープの定義時に犯した誤りが分かり、過去のプロジェクトで漏れた要求事項を拾い上げられることもあります。

インタビュー

インタビューは専門家インタビューとも呼ばれ、プロジェクトマネジャーがステークホルダーの製品やプロセスへの要求事項を把握するのに役立ちます。個別またはグループで、メール、電話、手紙などを通じて実施できます。

座談会

司会者または進行役が、選ばれたステークホルダーや分野の専門家から意見と要求事項を集めます。議論は製品全体を扱うことも、プロジェクトの一側面に焦点を当てることもあります。

進行役を置いたワークショップ

進行役を置いたワークショップでは、異なる視点を持つステークホルダーが集まり、製品やサービスの要求事項を定義します。

ブレーンストーミング

ブレーンストーミングでは、参加者が互いの発想を発展させ、短時間で多くの案を生み出します。たとえば、ある参加者がスコープの定義方法を提案し、それを受けて別の人が案を出し、その案がさらに次の発想につながります。組織の内外から、職務、経歴、視点の異なる人を招きます。

名目グループ法

ブレーンストーミングの後、参加者は有力な案に順位を付けます。

デルファイ法

この合意形成手法では、専門家が匿名で参加し、互いに顔を合わせません。専門家に情報提供を依頼し、回答をまとめたうえで、再検討のために結果を送り返します。専門家の意見が一致するまで繰り返します。

マインドマップ

マインドマップは、発想を広げ、論理的なグループに整理するのに役立ちます。中心に置いた発想から主要な案を枝として描き、そこから関連する案をさらに枝分かれさせます。

親和図

他の要求事項収集手法で出た案を、類似性に基づいてグループに分けます。要求事項の各グループに見出しを付けます。

原寸大の図を開く ↗

質問票とアンケート

質問票では、一連の質問への回答を集めます。質問票やアンケートを使えば、多数の人から意見を集められます。

観察

製品を利用する可能性のある人が作業する様子を観察します。

プロトタイプ

プロトタイプは、提案された製品の模型や試作品です。ステークホルダーに見せ、フィードバックを求めます。すべての要求事項を把握し、モデルを確定して承認するまでに、複数の版が必要になることもあります。

グループでの意思決定

多くのステークホルダーから意見を集めると、案が競合したり、混乱や対立が起きたりすることがあります。各案を確認、分析し、採否を決め、採用した案に優先順位を付けてからプロジェクト文書に記録します。

• 全会一致。 全員が要求事項に同意するので、容易に決定できます。
• 独断。 1人がグループ全体を代表して決定します。迅速に決定できますが、他のステークホルダーが同意しない場合があります。
• 過半数。 グループの構成員の半数を超える支持を得た案を採用します。
• 相対多数。 過半数を得た案がなければ、最も多くの支持を集めた案を採用します。
• 合意形成。 グループが受け入れられる決定に達します。別の案を支持していたメンバーも、最も多くのメンバーが支持する決定を受け入れる意思があります。

要求事項文書

チームが要求事項を収集したら、明確で解釈の余地がない形で文書化します。要求事項文書は、要求事項の収集プロセスのアウトプットです。記述が不十分だと、要求事項を誤解される可能性があります。文書化した要求事項が明示された目標を満たすことを、ステークホルダーに確認してもらいます。そのフィードバックにより、適切な要求事項を収集できたか、最終的な成果物が受け入れられるかを検証できます。

ステークホルダーの要求事項の調整

要求事項に優先順位を付け、対立を解消し、プロジェクトが目標を達成できるようにします。すべての要求事項を満たせない場合は、スコープ、時間、コスト、品質、資源、リスク、顧客満足度に関する競合する要求のバランスを取る方法を探します。

収集が終わっても要求事項の調整は続きます。後になって、一部のステークホルダーの要求事項がプロジェクトや別のステークホルダーの要求事項と対立することがあります。プロジェクトマネジャーは、それぞれのニーズをプロジェクトの利益に照らして検討し、対立を解決します。

明確なプロジェクト目標を設定し、要求事項の収集時に、すべてのステークホルダーからすべての要求事項を特定し、優先順位を付けます。この2つが、要求事項を調整するための前提です。

競合する要求事項の解決

部門ごとに、プロジェクトに対する利害が異なることがあります。たとえば、リスク管理チームはリスクを見つけてプロジェクトの進行を遅らせたい一方で、業務部門は早く終わらせたいことがあります。両部門が受け入れられる解決策を探します。

複雑な対立には経営陣の関与が必要です。プロジェクトマネジャーは、どの要求事項がビジネスケースを支えるかを確認し、プロジェクト憲章、スコープ記述書、制約条件を見直します。

プロジェクトの目標や承認済みの憲章の範囲外にある要求は、当初のプロジェクトの目的に関係していても却下します。憲章の変更を提案する場合は、スポンサーと協議して承認を求めます。コストが最大の制約なら、コストを増やす要求は承認されにくくなります。他の制約に大きな影響を与えず、コストを抑える要求は承認されやすくなります。これらの基準から外れる要求は、将来のプロジェクトで検討できます。

要求事項マネジメント計画

本章では、要求事項マネジメント計画を要求事項の収集プロセスのアウトプットとして扱います。この計画では、次の問いに答えます。

• どの方法で要求事項を特定するか。
• 各要求事項にどのような分析が必要か。
• 要求事項にどのように優先順位を付けるか。
• 要求事項をどのように管理するか。
• 要求事項をどのように追跡するか。
• 要求事項トレーサビリティ・マトリックスには、どのような情報を記載する必要があるか。

要求事項トレーサビリティ・マトリックス

大規模なプロジェクトでは、文書化が不十分だと要求事項が失われるおそれがあります。1つの要求事項から複数の詳細化や明確化が生じると、それぞれがどこから来たのか分かりにくくなります。要求事項が設けられた理由を見失うと、プロジェクトが目標を達成できなくなることがあります。

要求事項トレーサビリティ・マトリックスは、要求事項の収集プロセスのもう1つのアウトプットです。要求事項をプロジェクト目標、他の要求事項、またはその両方に結び付け、戦略目標の達成を支えます。プロジェクト全体を通して、プロダクト・スコープやプロジェクト・スコープの変更提案を分析する際に使います。

原寸大の図を開く ↗

スコープの定義

要求事項の収集で作成した要求事項文書、プロジェクト憲章、プロジェクトのリスク、前提条件、制約条件に関する情報を使って、プロダクト・スコープとプロジェクト・スコープを定義します。プロジェクトとその成果物に何を含めるか、何を除外するかを明記します。

計画は繰り返し見直します。要求事項が判明したら、スケジュールと予算を作成します。どちらかが経営陣やスポンサーの期待を満たさなければ、プロジェクトの制約を見直し、要求事項と予算、スケジュールのバランスを取ります。スコープ、時間、コストの目標を達成する選択肢を経営陣に示します。スケジュールの短縮、別の作業方法の検討、予算やスコープの調整などが考えられます。目的は、スコープを実現できる現実的なスケジュールと予算を策定することです。

プロダクト分析

顧客とスポンサーから提示された製品の目標と説明を分析し、具体的な成果物を特定します。

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

プロジェクト・スコープ記述書は、スコープの定義プロセスの主なアウトプットです。作成には時間がかかり、外部の専門家を含む複数のステークホルダーの意見が必要になる場合があります。次の2種類の除外事項を明記します。

1. 未承認のスコープ。 要望があったものの、スコープへの追加が承認されなかった作業を特定します。
2. 不要なスコープ。 誤解が生じやすい範囲の境界を明確にします。

プロジェクト・スコープ記述書は、WBSおよびWBS辞書と合わせて、プロジェクトマネジメント計画の一部であるスコープ・ベースラインを構成します。記述書には次の項目を含めることができます。

• プロダクト・スコープ。
• プロジェクト・スコープ。
• 成果物。
• 製品の受入基準。
• スコープ外のアクティビティ。
• 制約条件と前提条件。

作業分解構成図（WBS）の作成

規模の大小を問わず、すべてのプロジェクトにWBSが必要です。WBSはプロジェクトの全スコープを管理しやすい成果物に分割します。WBSがなければ、プロジェクトは予定の完了日を過ぎ、プロジェクトマネジャーが重要なアクティビティを見落とすおそれもあります。

原寸大の図を開く ↗

多くのプロジェクトマネジャーは、対応項目の一覧を作成します。一覧が長いと扱いづらく、成果物が抜け落ちることがあり、大規模なプロジェクトを管理しやすい単位に分割するのが難しくなります。読む人がプロジェクトの全体像を理解したり、一覧を作成した担当者を特定したりするのも難しい場合があります。

WBSはすべての対応項目を網羅します。階層構造から、作業がどのように作業パッケージに分かれ、成果物同士がどう関連しているかが分かります。ステークホルダーとチームの意見を取り入れると、協力を得やすくなり、実績の向上にもつながります。WBSを作ることで、チームは頭の中でプロジェクトの進行をたどり、計画を改善できます。実行が容易になり、リスクが減り、参加を促し、プロジェクトを達成できるという実感につながります。

WBSは組織図に似ていることがあります。目的は、プロジェクトと成果物を得るために必要な作業を、計画、編成、管理、コントロールが可能な単位に分けることです。最上位から始めて、成果物と作業を、作業パッケージと呼ばれる小さな単位に分解します。

WBSを作る際のルール

1. チームを参加させます。
2. さらに作業を分解する前に、第1階層を完成させます。
3. 各階層を、その上の階層を細分化したものにします。
4. WBSの全階層を合わせれば、プロジェクト全体を理解できるようにします。
5. このプロジェクトの成果物だけを含めます。

作業パッケージとコントロール・アカウント

次の条件を満たす成果物は、作業パッケージとみなすことができます。

1. 現実的かつ確実に見積もることができる。
2. 短期間で完了できる。
3. 作業の中断や追加情報の入手を伴わずに完了できる。
4. 適切な場合に、外注や業務委託ができる。

WBSが完成したら階層に番号を付け、各作業パッケージに識別子を割り当てます。プロジェクトによっては、作業パッケージより上位のコントロール・アカウントと呼ばれる階層でコストを管理します。

計画時、チームはスコープ記述書、WBS、WBS辞書を使い、作業パッケージを成果物の作成に必要なアクティビティに分割します。このアクティビティ一覧は、時間管理のアクティビティの定義プロセスで作成します。

WBSは、その後のプロジェクト計画全体の基礎です。図で階層を示し、すべての成果物を特定します。アクティビティをプロジェクトに含めるには、WBSに含まれる作業との関連が必要です。WBSはチームがプロジェクトの各部分を検討するのに役立ち、他のプロジェクトでも再利用できます。階層はWBSで示し、アクティビティ間の依存関係はスケジュール・ネットワーク図で示します。

プロジェクトマネジャーはWBSを使ってプロジェクトを分解します。ここでいう 解体 および 分解 は、同じプロセスを指します。

原寸大の図を開く ↗

WBS辞書

WBS辞書には、各作業パッケージで行う作業を記述します。これはWBSの作成プロセスのアウトプットです。スコープの際限のない拡大を防ぎ、成果物の内容を全員に明確に伝えるのに役立ちます。WBS辞書には次のような使い方があります。

• 作業パッケージの開始時期を示すことで、作業承認システムとして機能させる。
• スケジュール上のマイルストーン、受入基準、作業パッケージのその他の詳細を記録する。
• 実際に行う作業のコントロールに役立てる。
• 作業パッケージに必要な労力をステークホルダーが理解できるようにする。

原寸大の図を開く ↗

スコープ・ベースライン

ベースラインとは、プロジェクトマネジメント計画の一部を最終確定し、承認した版です。スコープ・ベースラインはスコープ記述書、WBS、WBS辞書から成ります。作業開始前に、経営陣とステークホルダーが3つすべてを承認する必要があります。実際の進捗をスコープ・ベースラインと比較します。

スコープ・ベースラインから逸脱する場合は、変更を要求します。統合変更管理の実施プロセスで要求を処理します。承認されたら、スコープ記述書、WBS、WBS辞書、その他影響を受ける文書や構成要素を更新します。要求事項とスコープ・ベースラインを満たしたかどうかがプロジェクトの成功を測る基準です。

スコープの確認

スコープの確認では、承認されたスコープに沿ってプロジェクトを進めます。顧客またはスポンサーと定期的に話し合い、完成した成果物の受け入れを求めます。

スコープの確認のインプット

• 品質管理の実施で妥当性を確認した成果物。
• スコープ記述書、WBS、WBS辞書。
• 要求事項トレーサビリティ・マトリックス。
• 要求事項文書。

スコープの確認のアウトプット

• 受け入れ済みの成果物。
• 変更要求。
• プロジェクト文書の更新。

スコープの確認は、各フェーズの終わりに行うことも、プロジェクト全体を通じて監視・コントロールの一環として行うこともできます。ここで顧客は中間成果物を正式に受け入れます。プロジェクトやフェーズ全体の最終受け入れや正式な承認は、プロジェクトやフェーズの終結で行います。

スコープのコントロール

スコープのコントロールには主に2つの役割があります。プロジェクト・スコープ、プロダクト・スコープ、またはその両方の実績を測定し、スコープ・ベースラインの変更を管理します。作業が計画どおりに進んでいるか、スコープを頻繁に確認します。

主要なインプットは、プロジェクトマネジメント計画のスコープ・ベースラインと、現時点までに完了した作業の2つです。要求事項文書と要求事項トレーサビリティ・マトリックスも役立ちます。ベースラインからの逸脱を特定し、是正処置や予防処置を提案します。変更が必要なら、変更要求を提出し、統合変更管理の実施プロセスを通し、必要な文書を更新します。

プロジェクトマネジャーは、プロジェクトマネジメント計画のベースラインに照らして、主体的にプロジェクトをコントロールします。スコープの変更にはすべて変更管理プロセスを適用します。