『それも当然やってもらえると思ってました』を防ぐスコープ管理：要求事項トレーサビリティ表とスコープ記述書の型

型：要求事項トレーサビリティ表・スコープ記述書・変更ルート判定フローをまず置く

終盤になって「それも当然やってもらえると思っていました」が出てくるプロジェクトには、共通する手前の状態があります。誰が何を要求したのかがどこにも書かれておらず、合意したスコープが担当者の記憶の中にしかない状態です。下の3点は、この状態を防ぐために着手の早い段階で手元に置く型です。要求事項を成果物とスコープ記述書のどこに当たるかまで線でつなぎ、変更が来たときにどの経路で判断するかを先に決めておきます。

3点セットは単独では機能しません。要求事項トレーサビリティ表で要求の出どころを固定し、スコープ記述書で何をやり何をやらないかを文章にし、変更ルート判定フローで新しい要望が来たときの通り道を決める。この3つが揃って、終盤の『言った・言わない』に根拠のある答えが出せるようになります。

型：スコープ記述書の6項目

要求事項トレーサビリティ表で要求の出所を固定したら、次はスコープ記述書に落とし込みます。6項目を埋めれば、何をやり何をやらないかが1つの文書で判定できる状態になります。

型：変更ルート判定フロー

要望が来てから、それを正式な変更として扱うかどうかの判断を都度その場の空気で決めると、スコープは静かに膨らんでいきます。来た要望すべてに例外なく、次の4段階を適用します。

なぜこの記事が必要か：憲章とWBSの間に、誰も見ていない隙間がある

WBSの記事は成果物をどう分解するかを扱い、プロジェクト憲章の記事はスコープ概要を1〜3行でどう決めるかを扱ってきました。しかし『要求をどう集め、どう文章にし、変更が来たらどの経路で判断するか』という、両者の間を埋める手順はまだ扱っていません。ここが曖昧なまま残ると、憲章に書いた大枠とWBSに並んだ成果物の間に、誰も見ていない隙間ができます。終盤の『それも当然』は、たいていこの隙間から出てきます。

PMBOK® ガイド（Project Management Institute, Inc. の登録商標）第6版の知識エリア「プロジェクト・スコープ・マネジメント」は、スコープマネジメントの計画、要求事項収集、スコープ定義、WBS作成、スコープの妥当性確認、スコープのコントロールという6つのプロセスで整理されています。本記事は、リスク管理の実務や品質管理の実務と同じく、この6プロセスの骨格を実務の手順として使います。WBS作成はすでに別記事で扱っているため、ここでは要求事項収集、スコープ定義、スコープのコントロールの3つに絞ります。

要求事項収集：この時点では絞り込まない

要求事項収集は、ステークホルダーの要望や要求を特定し、要求事項文書にまとめるプロセスです。インタビュー、アンケート、ブレーンストーミング、ベンチマーキングなど複数の手段を組み合わせて洗い出します。重要なのは、この段階では要求事項の絞り込みや取捨選択をしないことです。『それは予算的に無理だ』という判断は、次のスコープ定義プロセスで行います。収集の段階で早々に却下してしまうと、後になって『検討した記録がない』という別の問題が生まれます。

独立行政法人情報処理推進機構（IPA）は、ユーザー企業向けの要件定義ガイドの紹介文で、システム開発の遅延の過半は要件定義の失敗にあると言われていることを紹介しています。要求事項を集める段階そのものを軽く扱うと、この種の遅延につながります。収集した要求は、ビジネス要求事項、ステークホルダー要求事項、ソリューション要求事項（機能・非機能）、品質要求事項などに分類して整理します。分類が終わった時点で作るのが、要求事項トレーサビリティ表です。要求事項の出どころから、それを満たす成果物までを1本の表でつなぎます。表が大きくなりすぎると管理自体が目的化するため、実務では全件を精密に追跡する必要はありません。金額が大きい要求、複数部署にまたがる要求、対立する利害関係者が関わる要求から優先して記入すれば、終盤の『言った・言わない』の大半は防げます。

この表の効果が出るのは、要求が却下されたときです。『この機能は不要』と判断した理由と日付が表に残っていれば、同じ要求が別の担当者から再提出されたときに、検討済みであることをすぐに示せます。記録がなければ、同じ議論を毎回ゼロからやり直すことになります。

スコープ定義：スコープ記述書は憲章より1段階具体的に書く

要求事項が集まったら、プロジェクト・スコープ記述書としてまとめます。プロジェクト憲章のスコープ概要が『やること・やらないこと』を1〜数行で書く着手前の合意文書であるのに対し、スコープ記述書は要求事項収集の結果を踏まえて、プロダクト・スコープ記述、成果物、受入基準、除外事項、制約条件、前提条件の6項目を具体的に書き下ろす文書です。憲章が『方向性の合意』だとすれば、スコープ記述書は『範囲の確定』にあたります。

この6項目の中で、実務上もっとも省略されやすいのが除外事項です。省略の理由はたいてい『書くことがない』ではなく、『角が立つから書きにくい』です。しかし除外事項を書かないままプロジェクトが進むと、終盤に出てくる要望がすべて『当然やること』として扱われ、スコープクリープに直結します。『既存システムとの自動連携は本プロジェクトの範囲外とし、次期フェーズで検討する』のように、時期つきで書けば、拒否ではなく優先順位の話として受け止められます。この書き方は憲章のスコープ概要でも使える手ですが、憲章が扱うのは1〜3個の大枠にとどまるため、個々の機能レベルの除外事項はスコープ記述書の役割です。

成果物の欄は、WBSの最上位の枝と対応させておきます。スコープ記述書に書いた成果物の名前と、WBSに並んだ成果物の名前が違うと、両方の文書を見比べて『これは同じものを指しているのか』を確認する作業が、プロジェクトのたびに発生します。

スコープの妥当性確認：検収のための確認と、内部の品質確認は別工程

完成した成果物をスポンサーや顧客に正式に受け入れてもらうプロセスが、スコープの妥当性確認です。品質コントロールが成果物を合格基準と照らして検査する内部の作業であるのに対し、妥当性確認は検査済みの成果物を発注者側に見せ、検収してもらう対外的な作業です。品質管理の実務で扱った品質コントロールが先、スコープの妥当性確認が後という順序を取り違えると、品質確認が済んでいない成果物を検収に出すことになり、手戻りが検収の場で起きます。

検収の基準は、スコープ記述書の受入基準を使います。ここで受入基準が数値化されていないと、検収する側とされる側で『できている』の基準がずれ、検収会議が合否の議論ではなく基準のすり合わせに使われてしまいます。

スコープのコントロール：承認のない変更をどこで止めるか

スコープのコントロールは、プロジェクトおよびプロダクトのスコープの状態を監視し、スコープ・ベースラインへの変更を管理するプロセスです。ここでいう監視とは、WBSに並んだ作業が、スコープ記述書で合意した範囲からずれていないかを定期的に確認することです。ずれが見つかったとき、そのずれを『正式な変更』として扱うか『そのまま続ける』かを判断する場所が、このプロセスにあたります。

承認のない変更が静かに積み重なる状態を、スコープクリープと呼びます。スコープクリープは一度に大きく起きるものではなく、たいてい次の5つの経路を通って進みます。

スコープが静かに膨らんでいく5つの経路

第1は、小さな要望を『これくらいならいいか』とその場で引き受けることです。個々の判断は妥当でも、積み重なると当初のスコープ記述書からどれだけ増えたかが誰にも分からなくなります。

第2は、引き受けた要望を変更管理ログに記録しないことです。口頭で合意した内容は、要求事項トレーサビリティ表に載らないまま、作業だけが積み上がっていきます。

第3は、変更の影響度を見積もらないまま着手することです。小さく見える変更ほど、後工程のどこまで波及するかが誰にも分からないまま、合意していないはずの作業が、気づかないうちに『当然やってもらえる』という期待になっていきます。

第4は、変更を口頭で承認することです。『それくらいならいいですよ』という一言が、後から『正式に合意した変更』として扱われてしまいます。

第5は、ベースラインの一部だけを更新することです。承認した変更をスコープ記述書には反映したのに、WBSや予算には反映し忘れる。この状態は本人も気づきにくく、第三者のレビューでしか見つかりません。

まとめ：要求の出所から、ベースライン更新までを一本につなぐ

要求事項トレーサビリティ表で要求の出所を固定し、スコープ記述書で何をやり何をやらないかを文章にし、変更ルート判定フローで新しい要望の通り道を決める。この3つを順番に回せば、プロジェクト憲章で決めた大枠とWBSで分解した作業の間にあった隙間が埋まります。

明日やることは3つです。まず、いま進行中の要望・要求を1つの表に書き出し、出所の欄が埋まらないものから優先してヒアリングします。次に、スコープ記述書の除外事項の欄を開き、空欄なら今日中に最低1項目書きます。最後に、次に来る変更要求をどの経路で判断するかを、憲章のPM権限3段階と照らして決めておきます。この3つが揃えば、スコープ管理の骨格は動き始めます。