プロジェクト全体の成否を左右する、スコープ：メンバーに贈るプロマネ基礎講座（3）（1/3 ページ）
本連載は、これからプロジェクトマネージャへの転身を考えている方、現在PMBOKベースでマネジメントされているプロジェクトに参加しているメンバーの方などを対象にしています。『プロジェクトマネジメント知識体系ガイド第3版（日本語版）』（以下、PMBOKガイド）の解説を行いながら、プロジェクトマネジメントの基本を解説していきます。なお、各小見出しの横には、対応するPMBOKガイドの章を記載していますので、PMBOKガイドを学習する際の参考にご利用ください。記事の最後には演習問題を用意しました。復習にご利用ください。
連載第2回「プロセスに着目し、統合マネジメントをイメージする」から、PMBOKの9つの知識エリアの学習が始まりました。今回は、「プロジェクト・スコープ・マネジメント」の知識エリアです。
PMBOKで理解する メンバーに贈るプロマネ基礎講座 各回のインデックス
第3回 プロジェクト全体の成否を左右する、スコーププロジェクト全体の成否を左右する、スコープ
プロジェクト・スコープ・マネジメントの学習のポイント
システム開発のようなIT系のプロジェクトでは、プロジェクトの進行に伴い「仕様変更」が頻繁に発生し、プロジェクトマネージャを悩ませることが多々あります。この仕様変更を、プロジェクトマネジメントの世界では、スコープの変更と考えることが可能で、プロジェクト・スコープ・マネジメントの知識エリアの管理対象といえます（表1）。
立ち上げプロセス群
なし
計画プロセス群
スコープ計画
スコープ定義
WBS作成
実行プロセス群
なし
監視コントロールプロセス群
スコープ検証
スコープ・コントロール
終結プロセス群
なし
| 表1 プロジェクト・スコープ・マネジメントのプロセス |
プロジェクトにおけるプロジェクト・スコープ・マネジメントの位置付け
プロジェクト・スコープは、プロジェクト内において「何をどこまでやるか」を定義します。これがどれほどの意味を持つかですが、スコープをどのように定義するかは、プロジェクトのスケジュール、予算、品質などすべての要素に影響を与えます。また、スコープ定義が杜撰（ずさん）だった場合、プロジェクトの途中で大きな手戻りや、追加の作業が発生したり、揚句の果てには、もともと予定した成果を上げられず、不満足なプロジェクトになってしまう可能性が考えられます。
例えば、「夏の家族旅行」プロジェクトを考えた場合、スコープは、「どこに行きたいか」「何をしたいか」などになります。計画段階では、「（東京から）伊豆に温泉旅行」としていたとします。もし、これを「（東京から）ハワイに旅行」に変更すると、予算やスケジュールに大きな影響を与えることは容易に想像ができます。たとえ、「伊豆に温泉旅行」の計画のままで進めたとしても、お父さんはゴルフをしたいとか、お兄ちゃんはダイビングをしたいといった要望も加味していかなければ、満足した結果は得られませんし、ちゃんと宿泊の計画や食事の計画を立てておかないと、宿探しやレストラン探しに無駄な時間を費やすなど、満足のいかない結果になることも想像できます。
このように、スコープをマネジメントするということは、プロジェクトそのものをマネジメントするといってもよいくらい、重要な意味を占めています。特に、ITプロジェクトでは、スコープ（どのようなシステムを構築するのか）が明確になっていないことも多く、結果的にはプロジェクトが進ちょくしていく中で、「あの機能が必要だ」とか、「これでは業務が回らない」とか、スコープが変動していくことで、予算超過やスケジュール遅延につながっていきます。
上記で、スコープ（どのようなシステムを構築するのか）という言葉が出てきましたが、そもそもスコープとは何でしょうか。
スコープとは何か
一般にプロジェクト・スコープの説明として、「プロジェクトの範囲」という説明を耳にします。しかし、ここでは少し別の表現をしてみたいと思います。
PMBOKガイドの用語集には、「プロジェクトにて提供するプロダクト、サービス、所産の総体」とあります。これを簡単に表現すれば、「プロジェクト活動で行う作業およびその成果物の集合体」ということです。なぜ、あえて「範囲」ではなく「集合体」としたかというと、スコープは「ここからここまで」という国境線のようなラインを表すものではなく、「あれとこれとそれ」といった、1つ1つ数えることができるものの集合体と考えた方が適切だからです。そして、行うべき作業（もしくは、その作業によって得られる成果物）の全体は、WBSという形で明確に定義されることになります。
スコープ・マネジメント方針の策定 〜「スコープ計画」プロセス（第5章1項）
スコープ・マネジメントの最初の作業は、「どのようにプロジェクトのスコープを管理していくか」を決定することから始まります（スコープ計画プロセス）。
具体的には、
- プロジェクト・スコープをどのように定義するのか
- プロジェクト・スコープ記述書をどのように記述するのか
- WBSをどのように作成するのか
- プロジェクトの成果物をどのように受け入れるのか
- プロジェクト・スコープの変更をどのように管理していくのか
などを、「プロジェクト・スコープ・マネジメント計画書」にまとめていきます。
計画書の作成に当たっては、プロジェクト憲章やプロジェクト・スコープ記述書暫定版のほかに、母体組織のマネジメント方針などもベースにします。
プロジェクト・スコープの詳細化 〜「スコープ定義」プロセス（第5章2項）
プロジェクト立ち上げの段階で、プロジェクトマネージャは、初期のプロジェクトへの要求事項をまとめた「プロジェクト・スコープ記述書暫定版」を作成しています。
スコープ定義プロセスでは、プロジェクトメンバーや主要なステークホルダーの意見なども交え、プロジェクト・スコープをより具体的なものへとまとめ、プロジェクト・スコープ記述書を作成していきます。プロジェクト・スコープ記述書に記載される内容には、下記のようなものがあります（表2）。
| プロジェクト・スコープ記述書の内容 | |
|---|---|
| プロジェクトの目標 | 関連するプロジェクトや定常業務の集まり |
| 成果物スコープ記述書 | プロジェクトで生成すべき最終成果物を記述する |
| プロジェクトに対する要求事項 | プロジェクトの要素成果物が満たすべき要件などを記述する |
| プロジェクトの境界 | プロジェクト作業に含まれるもの、含まれないものを明確化する |
| プロジェクトの要素成果物 | 要素成果物とは、最終のアウトプットに加え、マネジメント活動で生成される報告書なども含む |
| 成果物受け入れ基準 | スコープ検証プロセスで成果物を受け入れる手順や基準などを記述する |
| プロジェクトの制約条件、前提条件 | プロジェクトを遂行していくに当たって、予算やスケジュールなどの制約条件や、前提条件を明確化しておく |
| そのほか | 初期段階でのプロジェクト組織や、すでに明確になっているリスクなどを記述する |
| 表2 プロジェクト・スコープ記述書に記載される内容 | |
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。