スコープクリープは悪意から生まれない。「ちょっとこれも」が積み重なって、気づいたとき利益がゼロになっている。防ぐのは断ることではなく、変更を見えるようにする仕組みだ。
「ちょっとこれも対応してもらえますか」
その一言は、誰も悪意を持って言っていない。クライアントは本当に小さな追加だと思っている。社内の担当者も、せっかくだからと親切心で仕様を広げる。外注先も、関係を壊したくないからと受け入れてしまう。
結果として、最初の見積もりから作業量が1.5倍になっているのに、請求金額は変わっていない。それがスコープクリープだ。複数の外注案件を同時に回すディレクターたちが、ある時点で「なぜこんなに疲弊しているのか」と気づく原因のひとつが、ここにある。
スコープクリープには2つの発生源がある
外注案件のスコープが膨らむルートは、大きく2つある。
ひとつは「クライアント発」だ。プロジェクトが進む中で、クライアントが新しい要件を思いつく。「やっぱりこのページも必要」「ここのデザインをもう少し変えたい」。個々の要求は小さくても、積み重なると当初の定義から大きくずれる。
もうひとつは「社内発」だ。担当者が良かれと思って仕様を広げる。「ここも直した方が品質が上がる」「あの資料も渡しておこう」。予算やスコープの確認なしに、勝手に作業が増えていく。どちらも、最終的に外注先への発注量や社内の作業量を押し上げ、利益率を削っていく。
なぜ「その場で断る」だけでは機能しないか
「追加作業は受けないようにする」という方針を立てても、現場では機能しにくい。関係性への配慮、その場の雰囲気、相手の期待感——それらが重なると、個人の判断で断り続けることは難しい。
必要なのは、「個人が断る」のではなく、「仕組みとして変更を可視化する」ことだ。変更依頼が出た瞬間に、それが新しいコスト議論のスタートラインであることを、プロセスとして示せるかどうかが鍵になる。
土台になる考え方：各タスクにスコープを定義する
スコープクリープを防ぐ仕組みの起点は、タスクの定義だ。「何をやるか」ではなく「何をやらないか」まで書いてあるタスクが、スコープを守る最初の防壁になる。
たとえばランディングページの制作タスクであれば、「ページ数：1ページ」「修正回数：2回まで」「対応ブラウザ：Chrome / Safari 最新版のみ」「コーディングは含まない」といった除外項目を最初から明記しておく。これがないと、後から「コーディングもお願いできますか」という会話が生まれやすくなる。
業務委託のスコープ定義について詳しくは別の記事で整理しているが、ここで重要なのは「定義したスコープをどこに置くか」だ。口頭で共有するだけでは、後から「そんな話は聞いていない」になる。タスク管理ツールの中に、関係者全員が参照できる形で残しておく必要がある。
Paqutでのスコープ置き場の作り方
Paqutでは、タスクの説明欄に「対応範囲」と「対応外」を明記するフォーマットを作ることができる。外注先もゲストとして無料で招待できるので、発注側と受注側が同じタスクを見ながら仕事を進められる。
「このタスクで何をやるか」を共有ドキュメントではなくタスク自体に書いておくことで、認識のずれが起きにくくなる。ゲストリンクで招待した外注先も、同じ定義を見ながら作業するので、「聞いていなかった」が起きる余地が減る。
変更依頼を「別タスク」として切り出す
スコープを定義した後の運用で、最も重要なのがこのステップだ。追加要望が来たとき、それを既存タスクに書き足すのではなく、「変更依頼」として別タスクに切り出す。
既存タスクに要望を追記していくと、いつの間にかスコープが膨らんでいる。変更依頼タスクを別立てにすることで、「これは最初の合意に含まれていない新しい依頼だ」という認識が、関係者全員に自然に共有される。
変更管理の仕組みについて詳しくは専門の記事があるが、実際の運用としてはシンプルだ。「変更依頼：〇〇の追加」というタスクを作り、そこに「元のスコープ」「追加の内容」「見積もりの要否」を記載する。これだけで、追加が発生した事実とその内容が記録として残る。
変更依頼タスクが持つ心理的な効果
変更依頼を別タスクにする運用は、実はコスト交渉をしやすくする効果もある。「このタスクに追記された内容を見てください」ではなく、「変更依頼タスクを確認してください」と言えるからだ。
別タスクとして立てられた時点で、それが「最初の合意の外」であることは見た目で伝わる。担当者が個人的に断る必要はなく、「このタスクは別見積もりが必要な範囲です」と仕組みを指し示せばいい。
スコープ拡大を伝えるための会話スクリプト
仕組みを作っても、実際の会話でどう伝えるかに詰まることがある。以下は、実際に使えるスクリプトだ。
クライアントから「ちょっとこれも追加してもらえますか」と言われたとき。
「ありがとうございます。今回ご依頼いただいた内容は、当初のスコープ外になりますので、変更依頼として別タスクに起票させていただきます。追加のお見積もりをお出しした上で、進めるか確認させてください。」
社内の担当者が仕様を広げようとしているとき。
「品質を上げたい気持ちはわかります。ただ、この部分は当初の発注スコープに入っていないので、追加分として別タスクに起票して、予算確認を先にしましょう。承認が取れてから進める形にします。」
外注先から「ここも一緒にやっておきましょうか」と言われたとき。
「ありがとうございます。ただ、そこは別タスクとして起票させてください。今回のスコープに含めると、見積もり外の作業になってしまうので、改めて確認した上でお願いするかを判断します。」
どのケースも、断っているのではなく「プロセスに乗せている」だけだ。クライアントへのスコープ変更対応に詳しい記事もあるが、核心は「個人の判断ではなく仕組みとして処理している」という姿勢を示すことにある。
利益率を守ることは、外注先を守ることでもある
スコープクリープの問題は、発注側だけが損をするわけではない。外注先も、追加作業を断れずに無償で対応し続けることで、案件の採算が悪化する。良い外注先ほど、スコープが明確でない発注元を避けるようになっていく。
スコープを明確にして変更依頼を適切に処理する運用は、外注先にとっても「ここはちゃんとした発注元だ」という信頼の証拠になる。信頼があれば、優先的に対応してもらえる。急な相談にも乗ってもらいやすくなる。仕組みを整えることは、関係性を壊すどころか、強化することにつながる。
複数の外注案件を回しながら、それぞれに誠実であろうとしているディレクターたちにとって、スコープの見通しをよくすることは、自分を守ることでも外注先を守ることでもある。
「ちょっとこれも」を機会に変える
スコープ外の依頼が来たとき、それを潰さなければならない問題として見るのは損だ。変更依頼として起票し、適切に見積もりを出すことができれば、それは追加の売上機会になる。
「このクライアントは追加費用を払う意思がある」「この外注先はここまでカバーできる」——そういった情報が変更依頼タスクの履歴として蓄積されていくと、次のプロジェクトの見積もりや提案の精度が上がる。
スコープを整理することは、仕事を制限することではない。何をやって何をやらないかが見えると、むしろ動きやすくなる。追いかけなくても回る外注管理の土台は、こうした地味な定義と運用の積み重ねの上に立っている。
「ちょっとこれも」が来たとき、それを適切に処理できる仕組みがあれば、その一言は焦りではなく「起票しますね」という一行で終わる。それが、案件を増やしながら疲弊しない働き方への入口だ。