PMBOK第8版の「スコープ・パフォーマンス領域」を読み解くシリーズ。今回がこの領域の最後を締めくくる「2.2.5 結果の確認(Check Results)」の解説となります[1]出典:Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, 第2部 … Continue reading。
これまで定義し、管理してきたプロジェクトの「スコープ」が、本当に意図した成果や価値を生み出しているかを評価するためのチェックリストと、定量的な指標(数式)を見ていきましょう。
スコープ領域が目指す「5つの成果」とチェック項目
スコープ・パフォーマンス領域が最終的に達成すべき成果と、その確認方法はPMBOKで以下のように定義されています。
| 目標とする成果 | 確認のポイント(チェック項目) |
|---|---|
| 成果①:効果的な変更管理が適用されている | 予測型: 変更ログが適切に運用され、他領域への影響が包括的に考慮されているか。 適応型: バックログが活用され、ステークホルダーのフィードバックが優先順位付けされているか。 |
| 成果②:要求事項が明確に理解されている | 予測型: プロジェクト初期の要求事項に対する「変更要求が少ない」こと。 適応型: イテレーションごとの短期的要件が明確で、長期的要件が段階的に洗練されていること。 |
| 成果③:ビジネス目標および戦略と整合している | ビジネスケースやプロジェクト憲章との整合性を確認し、成果物が組織のビジネス目標(利益や戦略)に結びついていること。 |
| 成果④:ステークホルダーが成果物に満足している | エンドユーザーからの直接的なフィードバック、クレーム件数、返品率などで高い満足度が得られていること。 |
| 成果⑤:持続可能性がスコープで考慮されている | CO2排出量の管理や生物多様性への影響評価など、持続可能性を管理する活動がWBSやバックログに組み込まれていること。 |
スコープを測定する「3つの重要指標(数式)」

プロジェクトの活動の安定性や計画の精度を定量的に測るため、PMBOKでは以下の3つの計算式が示されています。プロジェクトの反省会(レトロスペクティブ)などで活用できる客観的な指標です。
スコープクリープ率(Scope Creep %)
計画外の無秩序なスコープ拡大(スコープクリープ)がどれくらい発生したかを測定します。
スコープクリープ率(%) = 計画外の成果物数 / 総成果物数 × 100
スコープクリープ率が0(または0に近い)ということは、「プロジェクト開始当初に決めた作業範囲や要件から、余計な追加作業や要件の肥大化が起きていない」ことを意味します。つまり、スコープに関しては完全に当初の計画通りに進んでいるという証拠になります。
スケジュールの遅延: 追加の要件がゼロ(スコープクリープ0%)であっても、当初予定していた作業そのものが難航し、スケジュールが遅れている可能性はあります。
コストの超過: 同様に、追加作業がなくても、トラブル対応や作業効率の低下などにより予算(コスト)をオーバーしている可能性もあります。
要求事項の安定性(Requirements Stability %)
プロジェクト開始時の要件が、途中でどれだけブレずに維持されたかを示します。
要求事項の安定性 = (変更されなかった要求事項数 / 総要求事項数) × 100
要件安定性は、100%に近いほど「計画が安定しており、当初の要件通りにプロジェクトが進んでいる」ことを意味します。
スコープ定義の正確性(Scope Definition Accuracy %)
初期に計画したスコープが、どの程度正確に(計画通りに)提供されたかを評価します。
スコープ定義の正確性 = 計画通り正しく提供されたスコープ項目数 / 計画された総スコープ項目数 × 100
スコープ定義の正確性が100%に近ければ、計画の初期段階で必要な作業範囲(スコープ)を正しく見抜いていたということになります。
【SSAITSの視点】指標を100%にすることが「目的」ではない
PMBOKで紹介されているこれらの指標は、プロジェクトの振り返りの題材として非常に有効です。しかし、マネジメント層が「これらの数値を100%に近づける(良くする)ことが大切だ」と勘違いしてしまうと、プロジェクトは本質を見失います。
スコープの成果確認というのは、現実には非常に難しいものです。
当然、初期の計画から逸脱しない(スコープ定義の正確性が100%である)に越したことはありませんが、現実のプロジェクトにおいてフタを開けてみたら「思いのほか必要なタスクが多かった」というのは日常茶飯事です。
また、いくら変更を抑え込んで「要件の安定性」や「スコープの正確性」を100%にしたとしても、出来上がったプロダクトが市場のニーズとズレていたり、思うような利益を上げられなかったりすれば、そのプロジェクトは「失敗」です。
真の評価基準は「利益(事業戦略)」との合致
そこで最も大切になるのが、5つの成果の③に書かれている「事業戦略と合致しているか」、そしてPMBOK第8版全体で繰り返し説かれている「価値(利益)」の観点です。
途中で仕様変更が相次ぎ、スコープクリープ率が高くなってしまったとしても、「スコープが増加した分、それ以上の利益(価値)を生み出すことができたのか?」という視点で判断する必要があります。
数字の良し悪しに一喜一憂するのではなく、常に「ビジネスとしての価値の最大化」に向かっているかを追跡することこそが、真のスコープマネジメントなのです。
まとめ:スコープ領域を終えて
「何をやるか、何をやらないか」を決めるスコープ・パフォーマンス領域。
WBSやバックログによる管理手法から、VBS(価値分解図)による価値の可視化、そして他領域との相互作用まで、プロジェクトの「骨格」となる非常に重要な内容でした。
スコープは生き物です。変更を恐れるのではなく、それを「より大きな利益を生むためのチャンス」と捉え、柔軟かつ戦略的にコントロールしていきましょう!
注
| ↑1 | 出典:Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, 第2部 セクション2.2.4(45-46頁)および セクション2.2.5(46頁)より筆者要約・翻訳。 |
|---|

