プロジェクト終了後の振り返りは、いつも同じ展開をたどる。プロジェクトは3ヶ月遅延し、予算を40%オーバーした。クライアントは「エージェンシーが複雑さをどんどん追加した」と言う。エージェンシーは「クライアントが要件をコロコロ変えた」と言う。双方が失望したまま別れ、新しいベンダーが雇われ、6ヶ月後に同じことが繰り返される。
スコープクリープは、ソフトウェアプロジェクトが失敗する最も一般的な原因だ。そして最も誤解されている原因でもある——なぜなら、私たちがそれについて語るストーリーは、ほとんどの場合間違っているからだ。
「エージェンシーの問題」という語りが本質を見誤る理由
エージェンシーを責めるのは直感的に思える。請求書を送ってくるのは彼らだ。スケジュールを見積もるのも彼らだ。その両方が膨らんだとき、彼らが明らかな犯人に見える。
しかし、ほとんどのスコープクリープの状況で実際に起きていることはこうだ。開発開始時に要件が固まっていなかった。小さなリクエストが非公式に追加されていった。そして、その変更の積み重なった重さに誰も気づかないまま、予算が底をついた。
これはエージェンシーの自制心の失敗ではない。機能する変更管理プロセスなしにプロジェクトが走っていた、ということだ——そのプロセスの責任はエージェンシーと同様にクライアントにある。多くの場合、クライアント側により大きな責任がある。
エージェンシーは、あなたが指示したものを作る。指示内容が変わると——たとえ小さな変更でも、善意であっても——プロジェクトも変わる。問題は、それが危機になる前に誰かがその変更を追跡しているかどうかだ。
3つの根本原因（すべて予防可能）
スコープクリープはほぼ無から生じることはない。原因を遡ると、ほぼ必ず3つのうちのどれかから来ている。
開発開始前に要件が確定していなかった。 これが最も一般的な原因であり、最も認めにくい原因でもある。開発を始めることが前進しているように感じられるからだ。しかし、最初のスプリントが始まった時点でまだ機能リストが変化しているなら、それはビルドを開始しているのではなく——課金メーターが動いた状態で実験を開始しているのだ。不明確な要件はひとつひとつ、未来の変更指示書になって待ち構えている。
「あったら便利」な機能が明確にラベル付けされていなかった。 計画段階の会話では、すべてが同等に重要に聞こえる。「レポートのエクスポート機能も追加できますか？」は小さな追加のように聞こえる。でも3週間の作業かもしれない。これらのリクエストが明確に分類されないまま——必須、望ましい、あったら便利——すべてが要件として扱われ、プロジェクトはそれを収容するために膨らむ。
契約に正式な変更リクエストプロセスがなかった。 これが、他の2つの原因が積み重なることを許す構造的な失敗だ。契約でスコープ変更の扱い方が明確に定められていなければ——誰が提案し、どう見積もり、誰が承認し、承認時にスケジュールと予算はどうなるか——スコープは非公式に、見えないまま膨らみ、誰も責任を負わない。
コードを書く前の予防チェックリスト
複雑なことは何もない。必要なのは、「とにかく動き出せ」というプレッシャーがかかる前の、プロジェクト開始時の規律だ。
コードを書く前にスコープ文書を作成する。 百ページの仕様書である必要はない。プロダクトが何をするか、何をしないか、そして曖昧さなく誰かが構築できるレベルの詳細で主要機能を定義する必要がある。それが書けないなら、ビルドする準備ができていない。
すべての機能に対して「完了」を定義する。 「ユーザーがファイルをアップロードできる」は機能定義ではない。「ユーザーが10MBまでのPDFとJPEGファイルをアップロードでき、進捗インジケーターが表示され、アップロード失敗時にエラーメッセージが出る」が機能定義だ。完了は完了を意味する——「ほぼ完了」や「完了したが後で考えるエッジケースがある」ではない。
契約に変更指示プロセスを要求する。 スコープを追加、削除、または変更するリクエストはすべて、書面による変更指示プロセスを経るべきだ。エージェンシーがスケジュールとコストへの影響を見積もる。あなたが承認するか断るかを決める。非公式なSlackメッセージから何かが作られることはない。このプロセスは双方を守る——請求ショックからあなたを守り、あなた自身のリクエストによる遅延でエージェンシーが責められることを防ぐ。
現実的な予算バッファーを設ける。 しっかりしたスコープ文書と規律ある変更指示プロセスがあっても、ソフトウェアプロジェクトは本当の未知数に遭遇する。サードパーティ統合がドキュメントと違う動作をする。テスト中にセキュリティ要件が浮上する。本当のサプライズのために10〜15%を確保し、2週目の「あったら便利」な機能に使い込まないこと。
優れたスコープ管理が実践的にどう見えるか
予算内に収まるクライアントは、必ずしも優れたエージェンシーと仕事をしているわけではない。仕事の仕方が違うのだ。
彼らはキックオフミーティングに文書化されたブリーフを持ってくる。ローンチに本当に必要なものと後回しにできるものについて、すでに社内で議論している。開発中に新しいアイデアが浮かんだとき——それは必ず起きる——すぐに要求するのではなくバックログに入れる。変更指示書を承認する前に慎重に検討し、追加のたびに実際のコストがかかることを知っている。
これは特別な才能ではない。初めてのソフトウェアプロジェクトの前に誰も教えてくれない習慣の集まりだ——誰もが自明だと思い込んでいるから。でも、そうではない。
すべてを変えるリフレーミング
スコープクリープは双方が貢献する共通の問題だ。しかし、クライアントは自分が通常行使する以上の制御権を持つ位置にいる。要件を設定するのはあなただ。変更を承認するのもあなただ。変更指示プロセスが存在するかどうかを決めるのもあなただ。
これは責任を押し付けることではない。実際のレバレッジがどこにあるかを認識することだ——プロジェクト開始前に、予算が尽きた後ではなく。
一緒に仕事をする価値のあるエージェンシーは、プロジェクトにスコープの規律を積極的に組み込もうとする。曖昧な要件に反論する。非公式なリクエストに重大なスコープへの影響があるとき警告する。変更指示プロセスを提案する——なぜならそれは自分たちも守るから。
でも、あなたがその条件を作らなければ、彼らにはそれができない。それは明確なスコープ文書から始まる。変更の扱い方を定義した契約、そして計画と希望リストの違いを認識するという最初からのマインドセットから。
スコープの規律は、ソフトウェア開発において最も過小評価されているプロジェクト管理スキルだ。それをマスターすれば、エージェンシーとの仕事におけるほぼすべてのことが簡単になる。
