スコープ管理とWBSの作り方
プロジェクトが遅れた原因を辿っていくと、多くの場合スケジュールの引き方ではなく、「何を作るのか」の決め方に行き着きます。作るものが曖昧なまま日程だけを精緻に引いても、その日程は根拠を持ちません。スコープ管理は、プロジェクトマネジメントのすべての土台にあたる活動です。
■ スコープには2種類ある
スコープとは、プロジェクトで扱う範囲のことです。実務では次の2つを分けて考えます。
プロダクトスコープ：成果物そのものが持つ機能や特性。「このシステムは何ができるのか」
プロジェクトスコープ：その成果物を生み出すために必要な作業。「そのために何をするのか」
プロダクトスコープが決まらなければ、プロジェクトスコープは決められません。ところが現場では、作るものが固まらないうちに体制と納期だけが先に決まることが珍しくありません。スコープ管理の難しさの多くは、この順序が逆転しているところから生まれます。
■ なぜスコープが要になるのか
スコープは、品質・コスト・納期（QCD）すべての起点です。スコープが動けば、必要な工数も期間も品質基準も動きます。
逆に言えば、「納期は動かせない、コストも増やせない」と言われたとき、交渉の材料として残るのはスコープだけです。何を落とすか、何を後続フェーズに送るかという会話を成立させるためには、スコープが文書として固定されている必要があります。固定されていなければ、削る対象すら特定できません。
■ スコープ管理の流れ
PMBOKガイド第6版では、スコープ・マネジメントは次の6つのプロセスとして整理されていました。
スコープ・マネジメントの計画（進め方そのものを決める）
要求事項の収集
スコープの定義（スコープ記述書の作成）
WBSの作成
スコープの妥当性確認（成果物の正式な受入）
スコープのコントロール（変更への対応）
第7版以降は知識エリアという分類を取らず、計画やデリバリーといったパフォーマンス領域の中で扱われる形に変わりました。ただし実務でやるべきことは変わりません。この6つの流れは、いまも手順として有効です。
■ 要求事項の収集でつまずくところ
スコープが崩れるプロジェクトは、ほぼ例外なくこの段階でつまずいています。典型的なのは次の3つです。
聞く相手を間違える：実際に使う人ではなく、話しやすい人・時間を取ってくれる人に聞いてしまう
言われたことをそのまま要求事項にする：要望の背後にある目的を確認しないため、もっと簡単な解決策を見落とす
決裁者が最後に出てくる：現場と合意したつもりが、最終確認で覆る
対策として有効なのが、要求事項トレーサビリティ・マトリクスです。要求の一つひとつに、誰が出したか、なぜ必要か、どの成果物で実現するか、どのテストで確認するかを紐づけておきます。作るのは手間ですが、後工程で「この機能は何のためだったか」を辿れる価値は大きいものです。
■ スコープ記述書で最も重要な項目
スコープ記述書に書くべき項目のうち、実務で最も効くのは除外事項です。
「含まれるもの」は誰でも書きます。しかしトラブルになるのは、ほぼ常に「含まれていないもの」の側です。「〜は本プロジェクトの対象外とする」と明記しておかないと、後から「当然入っていると思っていた」が発生します。書きにくい項目ほど、書く価値があります。
あわせて、前提条件・制約条件・受入基準を記載します。受入基準では「誰が、何をもって完了と判断するか」まで書き切ります。判断者が書かれていない受入基準は、実質的に機能しません。
■ WBSの作り方
WBS（Work Breakdown Structure／作業分解構成図）は、スコープを階層的に分解したものです。作るときのポイントは5つあります。
成果物で分解する：「設計する」「開発する」という動詞ではなく、「基本設計書」「ユーザー管理機能」という成果物の名前で分けます。動詞で分けると進捗が「だいたい終わった」になり、測れなくなります
100%ルールを守る：下位の要素を合計したとき、上位の要素が過不足なく表現される状態にします。足りなければ作業の抜け、多ければ重複です
分解しすぎない：最下位のワークパッケージは8〜80時間で終わる粒度が目安です（8/80ルール）。細かすぎると、管理そのものがコストになります
WBS辞書を添える：各ワークパッケージについて、作業内容・成果物・担当・完了条件を一行ずつ書きます。図だけでは必ず解釈が割れます
一人で作らない：実際に作業する人と一緒に作ります。分解の精度が上がるうえ、後から「聞いていない」が出にくくなります
業務システム開発であれば、次のような形になります。
「3.2 申請機能」のような単位まで分解したうえで、それぞれにWBS辞書で完了条件を添えます。ここまで来てはじめて、進捗を数字で追えるようになります。
■ WBSでよくある失敗
組織図になっている：「設計チーム」「開発チーム」で分けてしまうと、成果物が見えなくなり、抜けに気づけません
ガントチャートから逆算して作る：先に引いた日程に合わせて作業を切ると、抜けが日程の中に隠れてしまいます
一度作ったきり更新されない：スコープが変われば、WBSも変わります。更新されないWBSは、実態と乖離した時点で誰も見なくなります
■ スコープクリープへの対処
スコープクリープとは、正式な変更手続きを経ないまま、スコープが少しずつ膨らんでいく現象です。一つひとつは小さく、断りにくい依頼の形でやってきます。
防ぐための要点は、断ることではなく見えるようにすることです。
PMが一人で抱えて吸収してしまうと、影響が誰にも見えないまま進みます。その結果、遅れが表面化したときには打てる手が残っていない、という状況になります。判断を自分で抱えないことが、結果的にプロジェクトを守ります。
■ 着手前のチェックリスト
除外事項が文書に書かれているか
受入基準に「誰が判断するか」が書かれているか
WBSが成果物の単位で分解されているか
最下位の作業に、担当者と完了条件があるか
変更が来たときの手続きが、あらかじめ決まっているか
スコープが固まれば、スケジュールもコストも見積もれるようになります。逆に、ここが曖昧なまま先に進んだプロジェクトは、どこかで必ず引き返すことになります。最初に時間をかける価値のある工程です。