ツールと技法
WBS の要素「1.3 テスト」の下位に「1.3.1 結合テスト」「1.3.2 システムテスト」だけを置いた。ところが計画では受入テストの支援も行うことになっている。100 パーセントルールの観点で何が問題か。
下位要素の合計が上位要素「テスト」の作業全体に一致しておらず、受入テストの支援が WBS から漏れている。
100 パーセントルールでは、ある要素の下位要素をすべて合わせると、その要素の作業を過不足なく表していなければならない。 受入テストの支援が WBS に無いと、見積りにも担当の割当てにも現れず、作業が抜けたまま計画が進む。 「1.3.3 受入テスト支援」を加えて、下位の合計を上位と一致させる。
ワークパッケージ「受注サブシステムの開発」が 6 か月・10 人規模の作業になった。このまま管理の単位にしてよいか。どうするか。
大きすぎるので、さらに要素分解する。
ワークパッケージは、期間とコストを見積もり、担当を割り当て、進捗と完了を確認できる大きさにする。 6 か月の塊では、途中で進捗を測りにくく、遅れに気付くのも遅れる。 「受注画面」「受注帳票」「受注データ連携」のように成果物を基準に分け、見積りと管理ができる大きさになるまで分解を続ける。 逆に、細かくしすぎると管理の手間が増えるので、管理できる最小限の大きさを目安にする。
開発メンバーが「この機能もあったほうが便利だろう」と、仕様に無い検索条件を自主的に追加した。顧客の要望ではないが、これもスコープクリープか。
スコープクリープに当たる。承認されていないスコープの拡大だからである。
スコープクリープは、変更の管理を通さないままスコープが少しずつ膨らむことで、顧客の要望から生じるとは限らない。 メンバーの善意の作り込みも、工数を使い、テスト対象を増やし、スケジュールやコストに影響する。 必要だと考えるなら変更要求として提案し、変更の管理で承認されてから取り込む。
スコープ（作業及び成果物）を要素分解で階層的に分け、最下層のワークパッケージを見積り・割当て・進捗管理の単位にする。分解は、下位要素の合計が上位要素と過不足なく一致する 100 パーセントルールを守る。承認を経ずにスコープが少しずつ膨らむプロジェクトスコープのクリープは、変更の管理を通すことで防ぐ。
スコープのツールと技法の役割
| 用語 | 何か | 主に使う場面 |
|---|---|---|
| スコープ（作業及び成果物） | プロジェクトが行う作業と作る成果物の範囲 | すべてのスコープのプロセス |
| 要素分解 | 上位の要素を、より小さく管理しやすい下位要素に分けていく技法 | WBSの作成、活動の定義 |
| ワークパッケージ | WBS の最下層の要素。見積り・割当て・進捗管理の単位 | WBSの作成、活動の定義 |
| 100パーセントルール | 下位要素の合計が上位要素と過不足なく一致するように分解する原則 | WBSの作成（分解の点検） |
| プロジェクトスコープのクリープ | 承認を経ずにスコープが少しずつ拡大していくこと | スコープの管理（防ぐ対象） |
要素分解・ワークパッケージ・100 パーセントルールは WBS を作るための道具であり、 スコープのクリープは作った WBS とスコープ規定書を基準にして防ぐ対象である。
スコープ（作業及び成果物）
Section titled “スコープ（作業及び成果物）”スコープは、プロジェクトが行う作業と、作り出す成果物の両方を含む範囲である。 成果物だけに目を向けると、テスト、移行、教育、プロジェクトマネジメントそのものといった、成果物として目に見えにくい作業が漏れやすい。 WBS もこの考え方で、成果物（受注画面、受注帳票など）と、それを作るための作業（テスト、移行など）を合わせて分解する。
要素分解は、スコープを上位から順に、より小さな要素へ分けていく技法である。手順は次のようになる。
- スコープ規定書から、主要な成果物と作業を最上位の要素として洗い出す
- 各要素を、それを構成する下位の要素に分ける
- 見積り・割当て・進捗管理ができる大きさ（ワークパッケージ）になるまで分解を繰り返す
- 100 パーセントルールで、分解に漏れや重複が無いかを点検する
分け方の基準には、成果物で分ける、開発の工程（フェーズ）で分ける、などがある。同じ階層の中では基準をそろえる。 活動の定義でも、ワークパッケージをさらに活動へ分けるときに要素分解を使う。
すべてを最初から最下層まで分解できるとは限らない。近い時期の作業は詳しく分解し、先の作業は大まかにしておき、 情報が増えた時点で詳しくしていく進め方（段階的詳細化）もとられる。
ワークパッケージ
Section titled “ワークパッケージ”ワークパッケージは、WBS の最下層の要素である。次のことができる大きさにする。
- 所要期間とコストを、根拠を持って見積もれる
- 担当者または担当組織を 1 つに割り当てられる
- 進捗を測り、完了したかどうかを判定できる
ワークパッケージは成果物寄りの単位であり、活動の定義で「何をするか」の単位である活動に分けられて、スケジュールに載る。 コストの見積りや進捗の把握も、ワークパッケージを単位にして積み上げることが多い。
100 パーセントルール
Section titled “100 パーセントルール”100 パーセントルールは、WBS を作るときの原則で、次の 2 つを意味する。
- ある要素の下位要素をすべて合わせると、その要素の作業を100 %、過不足なく表す
- WBS 全体は、プロジェクトのスコープの作業をすべて含み、スコープ外の作業を含まない
| 状態 | 例 | 結果 |
|---|---|---|
| 下位の合計 < 上位（不足） | テストの下位に受入テスト支援が無い | 作業が見積りと割当てから漏れる |
| 下位の合計 > 上位（超過） | スコープ外の機能追加が下位に含まれている | 承認されていない作業が紛れる |
| 下位が重複 | 同じ作業が 2 つの要素に入っている | 二重に見積もられる |
このルールを守れば、WBS に載っているものがスコープそのものになり、「WBS に無い作業はスコープ外」と判断できる。
プロジェクトスコープのクリープ
Section titled “プロジェクトスコープのクリープ”プロジェクトスコープのクリープ（スコープクリープ）は、変更の管理を通さないまま、スコープが少しずつ拡大していくことである。 1 件ずつは小さな追加でも、積み重なると、期間やコストが計画を超え、品質の確保も難しくなる。
主な原因と防ぎ方は次のとおりである。
- スコープの定義が曖昧 — スコープ規定書に受入れ基準と「含めないもの」を明記し、関係者と合意しておく
- 口頭での依頼をそのまま受ける — 依頼はすべて変更要求の形にして、変更の管理で影響を評価してから承認・却下を決める
- 担当者の自主的な作り込み — 仕様に無いものは作らない。必要と考えるなら変更要求として提案する
承認された変更によってスコープが広がるのはクリープではない。正式な手続を経たかどうかで区別する。
試験での注意
Section titled “試験での注意”- ワークパッケージは WBS の最下層の要素である。活動とは別物で、活動はワークパッケージをさらに分けたもの
- 100 パーセントルールは「漏れなく」だけでなく「スコープ外を含まない」ことも求める
- スコープクリープは顧客の要望だけでなく、メンバーの自主的な追加でも起こる。対策は「変更の管理を通す」が正解の筋になる
- 承認を経たスコープの拡大はクリープではない
なぜそうなっているのか
Section titled “なぜそうなっているのか”見積り、担当の割当て、進捗の測定は、大きな塊のままでは精度よく行えない。 要素分解でワークパッケージまで分ければ、それぞれを根拠を持って見積もり、進捗を確かめられ、積み上げて全体の計画にできる。 100 パーセントルールでスコープと WBS を一致させておくと、WBS がスコープの判断基準になり、範囲外の作業を見分けられる。