PMBOK第8版の「7つのプロジェクトマネジメント・パフォーマンス領域」を読み解くシリーズ。今回は、プロジェクトにおいて「何を作るのか(そして何を作らないのか)」を定義する「スコープ(Scope)」のパフォーマンス領域について解説します。
今回の第8版アップデートにおいて、このスコープ領域には実務家にとって非常に興味深い「ある変更」が加えられました。
それが「品質(Quality)管理の統合」です。
スコープとは「必要なことだけをやる」こと
まず、スコープの基本についておさらいしましょう。
プロジェクトの価値は、スコープ(範囲)に合致した成果を提供することで生み出されます。そのため、スコープ・パフォーマンス領域では以下の2点を確実にコントロールすることが求められます。
- 必要なすべての作業が含まれていること(漏れがない)
- 必要な作業のみが行われ、不要な作業が行われないこと(無駄がない)
プロマネにとって「スコープ管理」とは、単なる作業リスト作りではありません。良かれと思って頼まれてもいない過剰な機能を追加する「金メッキ(不要な作業)」を防ぐための防波堤です。
やらないことを明確にすることが、コストとスケジュールの最適化に直結します。
【SSAITSの視点】なぜ「品質」がスコープに統合されたのか?
PMBOK第8版における最大の目玉は、このスコープを定義し管理する領域の中に「プロジェクトの品質(Quality)」が組み込まれたことです。
前バージョンの第7版では、品質は「デリバリー(納品)」のパフォーマンス領域の一部として扱われていました。つまり、「最後の仕上げとして、ちゃんとしたものを届けましょう」というニュアンスが強かったのです。
しかし、実際の現場ではどうでしょうか?
品質というのは、最後にテストを頑張れば良くなるものではありません。「目的の品質を達成するためには、そもそもどのような作業(スコープ)が必要なのか?」を最初の計画段階で明確にしておかなければ、絶対に高い品質は実現できないのです。
- 要件を満たし、顧客の期待に応えること=「品質」
- そのために必要な作業を過不足なく定義すること=「スコープ」
この2つは決して切り離せるものではなく、表裏一体の存在です。第8版で品質がスコープ領域に統合されたのは、「品質は最後に確認するものではなく、最初から作業範囲として組み込んでおくべきものだ」という、極めて実務的で本質的なメッセージだと私は捉えています。
スコープ領域を構成する「6つのプロセス」
このスコープと品質を定義し、管理し、検証するために、本領域には以下の6つのプロセスが含まれています。
スコープ・マネジメントの計画 (Plan Scope Management)
スコープと品質をどのように定義し、コントロールしていくかという「ルール(計画書)」を文書化します。
要件の引き出しと分析 (Elicit and Analyze Requirements)
ステークホルダーが何を求めているのか(ニーズと要件)をヒアリングし、分析・文書化します。
スコープの定義 (Define Scope)
引き出した要件をもとに、「プロジェクトで何を作るのか」の詳細な記述を作成します。ここで成果物の「品質基準」も明確に特定されます。
スコープ構造の構築 (Develop Scope Structure)
プロジェクトの成果物と作業を、チームが管理・実行しやすい小さな単位に細分化します。
- 予測型(ウォーターフォール): WBS(作業分解図)を作成します。
- 適応型(アジャイル): ユーザー・ストーリーとして「プロダクト・バックログ」にまとめます。アジャイルにおける品質基準である「完了の定義(DoD)」もここで設定されます。
スコープの監視・コントロール (Monitor and Control Scope)
作業が進む中で、スコープの状況を監視します。勝手に作業範囲が広がっていないか(スコープ・クリープの防止)を管理し、成果物の品質を測定します。
スコープの妥当性確認 (Validate Scope)
完成した成果物が本当に要件(品質基準)を満たしているかを確認し、顧客から「正式な受け入れ」を得るプロセスです。
まとめ
スコープ・パフォーマンス領域は、プロジェクトの「価値」と「品質」を守るための中心的な役割を担っています。
「良いもの(品質)を作ろう」という掛け声だけでは、プロジェクトは成功しません。それを実現するための作業を過不足なくスコープとして定義し、それ以外の不要な作業は勇気を持って切り捨てる。
このスコープと品質の一体管理こそが、プロジェクトの予算とスケジュールを最適化し、真の価値を提供する第一歩なのです。

