#3-9　スコープ・ベースラインとスコープ検証

前回（昨日）までの記事で扱った
　「プロジェクト・スコープ記述書」
　「WBS」
　「WBS辞書」
をまとめて、スコープ・ベースラインといいます。

プロジェクトマネジメント計画書一覧（『PM BOK』第７版）

スコープ・ベースラインが（一旦）完成したら、スコープ・ベースラインを基にしたスケジュールとコストのベースラインを計画します。それらをまとめて、関連ステークホルダーから無事に承認が得られたら、ベースラインとして確立されます。
確立後は、正式な承認を経た場合のみ、変更が可能になります。

この辺の取り決めは、会社ごとにルールがあることが多いと思います。
実際、私も経験上、会社のルールに則って作業を進めていたら、
（用語は違いますが）プロジェクト憲章とベースラインの承認を得て、実行のプロセスに進むようになっています。
実行後に、プロジェクト憲章やベースラインに変更が生じる場合に、正式な承認を得ないと変更が許可されないのも同様です。

スコープ・クリープ

スコープ・ベースラインを基にスケジュールの作成に進みますが、様々な要因で、計画に入っていない作業が行われてしまうことがあります。
これを、「スコープ・クリープ」と言います。
クリープ（creep）とは、時間・コスト・リソースを、調整することなく、またプロダクトやプロジェクトのスコープをコントロールすることなく拡大することです。
プロマネのセオリー的には、「スコープ・クリープ」は時間・コスト・リソースの無駄遣いになるとされています。
このような事態が起こるのを防ぐためには、変更管理プロセスをメンバーが守るように指導することが大事です。
要は、「計画にない作業を勝手にしないで」という話です。

当たり前のようですが、スコープの定義で「除外事項」（プロジェクトではしないこと）をわざわざ明記する必要があるくらい、実際の現場では、開発者の悪気なく、スコープ・クリープは起こるリスクがあります。

スコープ・クリープを発見した場合は、クリープを外すように作業指示が出されるか、クリープを正当なものとして計画書の方を変更するか、になりますが、どちらにしてもリスクがあるので、十分な検討が必要です。

スコープ検証

計画プロセスの先の話になるのですが、スコープがプロジェクトの活動の中でどのように扱われていくかを触れておきたいと思います。


スコープ・ベースラインが完成し、計画書に基づいて実行が行われ、成果物を検査するプロセスを経たら、最後にスコープ検証が行われ、公式な受け入れになります。

プロジェクトマネジメントのプロセスマップ
スコープの監視・コントロールプロセス

つまり、監視・コントロール期に至るまで、実際の成果物を検査するまで、スコープ・ベースラインの内容は確定せず、プロジェクトが終結するまでコントロールの対象になります。

スコープの監視・コントロールプロセスでは、下記を行います。
　・スコープの妥当性確認
　・スコープのコントロール

スコープを検証するために、主に以下のような観点で確認を行います。
　・完了の定義（Definition of DONE）
　：成果物の準備が整い、顧客が成果物を使用できると判断するために満たす必要のある基準が全てリストアップされたチェックリスト
　・受け入れ基準
　：成果物を受け入れてもらうために事前に満たしておく必要がある条件
　・差異分析
　：ベースラインと実際のパフォーマンスの差異を確認し、違いが生じた要因と差異の度合いを判定する
　・傾向分析
　：数学的アプローチで、過去の所産に基づいて将来の成果を予測する