スコープ管理とは?

『スコープ管理』とは、PMBOK準拠の弊社プロジェクト管理方法論PMM※1で定義されている、プロジェクトマネジメントの管理領域の1つである。計画フェーズにおいてスコープ管理計画の作成およびスコープ定義を実施し、後続フェーズにおいて要件のトレーサビリティ維持やスコープ検証等のスコープ管理業務を実施する。

※1 Hitachi Consulting Project Management Methodology

図1: スコープ管理 ～ PMM より

今回はこのスコープ管理に関連したお話である。

スコープ定義から曖昧さをなくす

スコープ定義はプロジェクトの成功を左右する非常に重要な作業である。

定義されたスコープが曖昧だと後続作業において変更や手戻りが頻発することになり、逆に定義されたスコープが明確であれば、後は要求開発と要求管理を両輪とした開発プロセスの確立に注力することで、安定したスコープ管理を行うことができる。

つまり、スコープ管理のポイントは『(1)明確な要求仕様(スコープ)を定義すること』と『(2)定義された要求をベースとした要求開発および要求管理のプロセスを確立すること』の2点に整理できるが、(2)は(1)を前提としている。よってスコープ定義が何よりも重要な作業に位置づけられるのである。

ではシステム開発を伴うプロジェクトを例にとって、スコープ定義の実際を考えてみよう。

プロジェクトにおいてスコープを定義するのはユーザー企業の役割である。一般的には、自社ビジネスの現況を背景として課題やニーズを洗い出し、これらを整理・優先付けを行った上でプロジェクトのスコープを定めていくことになるが、定めたばかりのスコープには往々にして曖昧さが潜在している。プロジェクトの大半が自社において初めての取組みであり、参考になる過去の経験値が蓄積されていないのだから当然である。最初から明確なスコープを定義できることのほうが稀と考えておいたほうが良い。

この曖昧さを含むスコープに対して、RFPが作成され、以後のプロジェクトのパートナー選びが始まるわけだが、選ばれる側のベンダーが上記の点を理解しているかどうかがポイントとなる。

システム開発を伴うプロジェクトであればRFPの提示先はシステムインテグレーターとなるわけだが、システムインテグレーターの多くはRFPに記述されたスコープを正としてそのまま提案書作成に移っていく。提案書においては、曖昧さに対する前提条件を置いてリスクを回避しつつ、自社が担当する作業のスコープを明確にしていく。スコープ定義の重要性は、プロジェクトマネジメントにいち早く取り組んだシステムインテグレーターのほうが強く認識しているのである。

こうして作成された提案書を受け取り、場合によっては複数の提案書を比較し、諸条件を勘案の上、パートナーとなるシステムインテグレーターを決定する。あとは提案書に記されたスコープを中心にプロジェクトが開始～実行されていくことであろう。最初にスコープを定義したのはユーザー企業であっても、明確なスコープを最後に定義したのはシステムインテグレーター側である。

上記の例において、以後、安定したスコープ管理が実施されていくだろうか？ここには一つ落とし穴がある。それはユーザー企業が定義した元々のスコープに曖昧さの火種が残っているところである。

本質的な課題が認識されていなかったが故に曖昧さが残っていたのだとすれば、プロジェクトが進行していく中で、実はこうしたかった、これを先に解決する必要がある、といった変更要求が発生する可能性がある。

筆者が所属するコンサルティングファームではこういった問題を回避するために、ユーザー企業のRFPを鵜呑みにせず、RFPの背景にある本質的な課題を見抜き、プロジェクトのスコープをユーザー企業とともに再定義することに多くのエネルギーを使っている。ユーザー企業の視点に立ってスコープ定義の曖昧さをなくす作業こそが何よりも重要なのである。

ユーザー企業の責務

明確なスコープが定義されたら、後続は要求開発と要求管理の仕組みづくりである。ユーザー企業と選ばれたパートナー企業との間でプロセスと役割分担を明確にする必要がある。

まず要求開発について、要求開発の実作業をどちらが実施するかは状況によるが、次の役割は最低限ユーザー企業側が担わなければならない。

  • 要求開発のインプットとなる要求の特定、文書化、優先順位付け
  • 全ての要求が仕様化されており、仕様が実装されれば要求が全て満たされることの確認
  • 要求仕様がステークホルダー間でベースラインとして共有・合意されていることの確認

同様に要求管理についても、次の役割は最低限ユーザー企業側が担わなければならない。

  • 要求仕様に対する変更の適用可否判断
  • 承認された変更が各種文書に反映されたことの監査
  • 承認された変更を含む仕様に対するテスト検証条件および検証結果の確認

特にプロジェクト規模が大きくなればなるほど、ユーザー企業単体でこれらの役割を担うことは難しくなる。最近では、この役割をサポートするために、弊社がPMO※2要員としてプロジェクトに参画することも増えている。もしスコープ管理の重要性を痛感しつつもリソース不足に陥っているのであれば、外のリソースの活用も積極的に検討いただければと思う。

※2 Program/Project Management Office