プロジェクト全体の成否を左右する、スコープ：メンバーに贈るプロマネ基礎講座（3）（2/3 ページ）

[田中亮，グローバル ナレッジ ネットワーク]

プロジェクト・スコープを作業レベルへ展開する〜「WBS作成」プロセス（第5章3項）

　プロジェクト・スコープ記述書には、プロジェクトで何をすべきか、どのような成果物を生成すべきかが定義されますが、具体的な作業レベルまでは定義されていません。

　そこで、このプロセスでプロジェクト・スコープをスケジュールやコストの見積もりが可能な作業の単位にまで分解し、WBSを作成します。分解されたWBSの最下位レベルの作業項目はワーク・パッケージと呼ばれ、ワーク・パッケージの単位でさまざまなマネジメント活動が行われます。下の表3は、システム開発プロジェクトにおけるWBSの例です。

WBS-ID	大分類	WBS-ID	中分類	WBS-ID	小分類
1	要件定義	…… （以下略）
2	設計	2.1	外部設計書	…… （以下略）
		2.2	内部設計書	…… （以下略）
		2.3	詳細設計書	2.3.1	モジュール1設計書
				2.3.2	モジュール2設計書
				2.3.3	モジュール3設計書
				…… （以下略）
3	プログラミング	…… （以下略）
4	テスト	…… （以下略）
5	移行	…… （以下略）
6	マニュアル	…… （以下略）
7	プロジェクトマネジメント	…… （以下略）

表3　システム開発プロジェクトにおけるWBSの例

　1つのワーク・パッケージは、プロジェクトの規模にもよりますが、一般的には、10人日（1人で作業して2週間かかる）程度の作業になります。

　　WBS作成のプロセスでは、プロジェクト・スコープを要素分解し、WBSを作成することに加え、「WBS辞書」を作成します、WBS辞書は、ワーク・パッケージなど、WBS構成要素の詳細を定義したものです。

【補足】スコープ・ベースライン
プロジェクト・スコープ・マネジメントの知識エリアにおいて、計画プロセス群に含まれるプロセスは、ここまでの3つのプロセス（「スコープ計画」「スコープ定義」「WBS作成」）であり、主要なアウトプットとして、「プロジェクト・スコープ記述書」「WBS」「WBS辞書」があります。この3つのアウトプットをまとめて、「スコープ・ベースライン」と呼びます。このベースラインがこの後、スコープ・マネジメントを行っていく際の基準になります。

成果物の受け入れ 〜「スコープ検証」プロセス（第5章4項）

　スコープ検証プロセスは、プロジェクトの活動によって生成された要素成果物に対し、プロジェクト・ステークホルダーが公式に承認し、受け入れをするプロセスです。

　プロジェクトの要素成果物の受け入れ基準はあらかじめプロジェクト・スコープ・マネジメント計画書に定義してありますので、これに基づいて、成果物のレビューを行い、問題がなければ、公式に受け入れられます。

　ところでPMBOKには、このスコープ検証に似たプロセスがもう1つ定義されています。次回以降に詳細を説明しますが、品質マネジメント知識エリアの「品質管理」プロセス（第8章3項）です。どこが似ているかというと、

（1）インプットに「要素成果物」が含まれる
（2）ツールと技法に「検査」が含まれる
（3）アウトプットに「確認済み（受け入れ済み）要素成果物」が含まれる

という点です（表4）。

	5.4 スコープ検証	8.3 品質管理
インプット	1.プロジェクト・スコープ記述書 2.WBS辞書 3.プロジェクト・スコープ・マネジメント計画書 4.要素成果物	1.品質マネジメント計画書 2. 〜6. (略) 7.要素成果物
ツールと技法	1.検査	1.〜8. (略) 9.検査 10.欠陥修正レビュー
アウトプット	1.受入れ済み要素成果物 2.要求済み変更 3.提案済み是正処置	1.〜8. （略） 9.確認済み要素成果物 10.プロジェクトマネジメント計画書（更新版）
表4　スコープ検証プロセスと品質管理プロセスの比較（一部省略）

　この2つのプロセスの違いを簡単に表現すると、品質管理プロセスは、プロジェクト・チーム内において「要素成果物」の品質を確認し、最終的なアウトプットとして外に出してよいかを判断するのに対し、スコープ検証プロセスは、プロジェクト・チームがアウトプットした要素成果物を最終的に受け入れるかどうかをジャッジする点にあります。例えば、システム開発ベンダがシステム構築を行った場合、スコープ検証のプロセスは、プロジェクト・チームではなく、発注元であるユーザー企業側で行う作業ということになります。

スコープの変更管理 〜「スコープ・コントロール」プロセス（第5章5項）

　最後に、スコープ・コントロールについて説明します。PMBOKによるとスコープ・コントロールとは、「すべての要求済み変更と提案済み是正処置が、プロジェクト統合変更管理プロセスを通して処理されていることを保証するもの」とあります。

　プロジェクトには変更が付き物です。なぜなら、プロジェクトには独自性という特徴があるため、プロジェクトの進ちょくに合わせて計画の見直しが必要になるからです。

　ただし、スコープ・コントロールのプロセスは、変更を管理するだけではありません。プロジェクト・スコープに変更を及ぼしそうな要因に対しても積極的に働き掛け、スコープ変更の影響をコントロールすることなども含みます。いわば、プロジェクトマネージャは、受身ではなく積極的に変更に関与していく必要があることを意味しています。

　また、プロジェクト・スコープに変更が発生した場合（例えば、システム開発プロセスの仕様変更や、仕様の追加が発生した場合）、プロジェクトのスケジュールやプロジェクトの予算にも影響を及ぼす可能性が高くなります。従って、スコープ・ベースラインを変更するような変更要求については、このプロセスだけで管理するわけではなく、「統合変更管理」プロセスを中心に、統合的に変更の管理を行う必要があります。スコープ・コントロールのプロセスの位置付けは、統合変更管理プロセスで承認された変更を実施する際、スコープに関する部分を担当すると考えれば分かりやすいと思います。