プロジェクトのスコープ管理を図解｜WBS・変更管理・スコープクリープ

1. お祭りの準備で「お願い」が増えたら？

地域のイベントを開くために、会場予約、登壇者の調整、告知ページ制作、配信サービスとの連携を計画しました。ところが準備の途中で、協賛企業から「多言語字幕も付けて」、運営から「配信システムの公開が延期された」と連絡が来ます。

どちらも大切な情報ですが、対応の仕方は異なります。字幕は新しい作業の追加、配信連携を別プロジェクトへ移すなら作業の除外です。予定表や担当者だけを書き換えて済ませると、いつの間にか約束した成果物が変わってしまいます。

2. プロジェクトスコープと成果物スコープ

成果物スコープは、完成する製品・サービス・成果物が備える機能や特徴の範囲です。イベントなら「定員100人、会場開催、受付、オンライン配信、終了後アンケート」などです。

プロジェクトスコープは、その成果物を提供するために必要な作業の範囲です。例えば会場契約、登壇交渉、機材テスト、当日運営、報告書作成などが該当します。両者は強く関係しますが同じではありません。

3. 「今回はやらない」を決める意味

範囲に含まれることだけでなく、除外事項（out of scope）を書いておくと期待のずれを防げます。例えば「参加者の受付システムは作るが、参加者用スマートフォンアプリは作らない」。この一文がなければ、関係者が後からアプリも当然作ると思うかもしれません。

スコープは「やることリスト」ではなく合意された境界です。境界の変更は費用や日程にも影響するため、黙って追加・削除するのは危険です。

4. 要求を整理し、成果物を分解する

関係者の要望（要求）から、受入基準を持つ成果物を定め、実施すべき仕事へ段階的に落とし込みます。要求の収集と確認を行い、成果物を実現するために必要な活動を漏れなく検討します。

この階層構造をWBS（Work Breakdown Structure／ワーク・ブレークダウン・ストラクチャー、作業分解構成図）と呼びます。大きな仕事を見積り・担当割当てが可能な単位まで分割すると、抜け漏れや二重作業を発見しやすくなります。

5. WBS・スケジュール・担当者表は違う

WBSは「何を納めるために、どんな作業があるか」を整理するための骨格です。一方、ガントチャートは作業をいつ行うか、役割分担表は誰が行うかを示します。

例えば「告知ページ作成」というWBSの作業を削除したなら範囲の変更です。ページは作るままで、完了日だけを3日後に動かすなら主に日程の変更です。同じ作業を別の担当者へ移すなら人員配置の変更です。

6. スコープベースライン：変更の比較基準

進行中のプロジェクトで、「当初の約束と何が変わったのか」を確認するには基準が要ります。承認されたスコープベースライン（scope baseline）は、スコープの変更管理に使う比較対象です。

この3点を組として扱う考え方があります。変更を承認した後は、正式な手続きに従ってベースラインや関連計画を更新し、古い版と新しい版を区別します。

7. 外部システムが延期された場合のスコープ変更

外部配信システムの公開が延期されると、予定どおりに連携機能を完成できません。ここで「配信との連携作業は別プロジェクトで実施する」と決めると、今回のプロジェクトで行う作業の範囲そのものが変わります。

ただし「別の仕事にすれば問題が解決する」とは限りません。顧客との合意、配信を除いたイベントの受入基準、後続プロジェクトへの引継ぎなども必要です。範囲外へ出した作業が必要なら、それを誰がいつ担うか決めます。

8. スコープの追加・削除・明確化

変更は追加だけではありません。「字幕機能を追加する」「オンライン配信を除外する」「曖昧だった申込条件を明文化する」など、内容も影響も異なります。

特に注意したいのがスコープクリープ（scope creep）です。正式な評価・承認を通さず、少しずつ作業や機能が増え続ける状態を指します。「ついでにこれも」の積み重ねは、納期や品質を圧迫します。

9. 変更要求は影響を評価してから決める

変更要求を受けたら、その場で「できます」と約束するのではなく、対象成果物、追加・削除される作業、費用、納期、資源、品質、リスク、外部依存関係への影響を整理します。プロジェクトによっては変更管理委員会（CCB: Change Control Board、チェンジ・コントロール・ボード）などが判断します。

承認しない変更要求にも判断理由を残すことが重要です。却下の理由が不明だと、同じ依頼が再び出たときに議論を繰り返してしまいます。

10. 3つの制約はつながっている

一般に、仕事の範囲を広げれば追加の時間や予算が必要になり得ます。納期を固定したまま作業を増やすと、人員投入、別作業の削減、品質面のリスクなどを検討しなければなりません。

これらは独立した数字ではありません。例えば配信連携の除外によって見積り作業量が減っても、残りの作業が同時進行なら、納期は同じかもしれません。作業量の合計（人日）とカレンダー上の工期（日数）は異なります。

11. 演習：イベントの変更管理を操作する

ここでは6つの作業からなるイベント計画を用意しました。要求を一つ選び、影響を読んで「承認」か「却下」を選びます。範囲を変更した場合は、ベースラインの更新も試してください。

12. 「スコープの妥当性確認」と「スコープの管理」

名前が似ている2つの活動を区別します。スコープの妥当性確認（Validate Scope）は、完成した成果物について顧客などから正式な受入れを得ることを中心に考えます。一方、スコープの管理（Control Scope）は、プロジェクトの実行中にスコープの状況を監視し、変更を管理する活動です。

13. 管理領域を混同しない

プロジェクトでは、一つの出来事が複数の領域に影響します。そこで「直接何を変更しているか」に注目すると、活動の種類を判別しやすくなります。

14. 計画型とアジャイルの違い

計画型のプロジェクトでは、合意したベースラインに対して変更を評価・承認する管理が重要です。一方、アジャイル型の開発ではプロダクトバックログの優先順位を継続的に見直すことで、価値を高める方向に作業内容を調整します。

ただしどちらの進め方でも「責任者が不明なまま仕事を増やす」「関係者が認識していない範囲変更を行う」ことが望ましいわけではありません。変更をどう判断し、合意し、可視化するかが本質です。

15. スコープ管理で残したい記録

良い変更記録には、①依頼内容、②変更理由、③対象の成果物・WBS項目、④日程・費用・品質などへの影響、⑤承認者と判断、⑥更新後の計画版、⑦周知先、を含めると追跡しやすくなります。

たとえば「外部システムが遅れるから連携を外した」だけでなく、「今回の受入条件から配信を除外したのか」「依存関係はどう引き継ぐのか」まで記載します。

16. 3つのチェックで判断する

新たな問題に出会ったら、まず何を変更するのかを確認します。続いて成果物やWBSの範囲そのものが変わるのかを見ます。変わるなら、最後に変更の承認とベースライン反映が必要かを確認します。