結論：仕様変更は来る。問題は変更の数ではなく、変更を受け取ってから判断・反映・共有するまでの体制がないこと。影響の可視化・変更ログの記録・クライアント側の合意確認・スコープ境界の明示・変更バッファの確保、5 つの原則で変更を飲み込む体制が作れる。
案件が走り始めて 2 週間。「あのページ、やっぱり別の構成にしたいんですが」とクライアントから連絡が来る。
先週の「方向性は問題ない」から、1 週間で方向性が変わった。
外注デザイナーに伝えて、ワイヤーを作り直す。クライアントに確認を取る。今度は別の部署の担当者が「聞いていない」と言い出す。もう一度、方向を揃えることから始まる。
仕様変更は避けられません。クライアントの事情は変わる。社内合意が後から崩れる。そうやって動くことの積み重ねが、実際の案件の姿です。
この記事は、変更を「突発事態」ではなく「想定内の動き」として飲み込む、5 つの原則を整理します。
1. 仕様変更が「混乱」になる理由
仕様変更が混乱を引き起こすのは、変更の数ではなく、変更を受け取ってから動くまでのプロセスが設計されていないからです。
プロセスがないと、次のことが起きます。
変更の影響が把握できない。「この修正で、どのタスクに戻りが発生するか」が見えないまま、とりあえず修正に入る。後から「あのタスクも変わっていたんですね」と気づく。
変更の記録がない。誰がいつどんな変更を依頼したかが口頭のやり取りだけに残る。後から「そんなこと言いましたっけ」という場面が生まれる。
関係者の合意なしに変更が走る。クライアント窓口担当者が依頼した変更が、その担当者の上司には共有されていない。完成物を見せた段階で「え、こういう方向だったんですか」と初めて知られる。
これらはすべて、変更管理のプロセスがないことで起きます。プロセスを設計すると、変更は混乱ではなく、情報として扱えます。Web 制作・デザイン会社が変更管理の体制を整える具体的な方法はWeb制作・デザイン会社向けの活用ページでまとめています。
2. 原則 1：変更の影響を、具体的に可視化する
最初の原則は、変更依頼を受けたとき、その影響をタスクレベルで具体的に見える形にすることです。
「少し修正するだけ」と言われる変更でも、プロジェクト全体への連鎖があります。変更影響の可視化とは、次のような整理です。
- このページの構成変更によって、戻りが発生するタスク（ワイヤー・コピー・デザイン・実装）
- 各タスクに発生する追加工数の概算
- スケジュール上で影響が出る日程
これをクライアントに示すと、クライアント側も「この変更には、これだけのコストが伴う」と理解できます。感情的な押し付け合いではなく、コストと価値のトレードオフを一緒に検討できます。
変更の影響を可視化するには、タスクの依存関係がもともと見えている必要があります。タスク間のつながりがタスク管理ツール上に記録されていれば、変更が入った瞬間に「どこに影響するか」が参照できます。
3. 原則 2：変更ログを残す
2 つ目の原則は、変更依頼・変更合意・変更の反映を、タスク管理ツール上のコメントとして時系列で記録することです。
口頭・チャット・メールに散在した変更の記録は、後から参照できません。「言った」「聞いていない」の摩擦が起きるのは、変更のやり取りが一元管理されていないことが原因です。
変更ログに残す内容は、次のものです。
- 誰がいつ何の変更を依頼したか
- PM が影響を整理してクライアントに伝えた日時
- クライアントが変更を正式に承認した日時
- 変更を外注メンバーに展開した日時
- 変更が完了した日時
この記録があれば、後から「あの変更はどこで合意されたのか」をタスクのコメントから辿れます。関係者全員が同じ履歴を参照できる状態が、「言った・聞いていない」を構造的に防ぎます。
4. 原則 3：クライアント社内の合意を確認する
3 つ目の原則は、クライアント担当者が変更を依頼する前に、社内で合意を取っているかを確認することです。
多くの仕様変更は、クライアント側の社内合意が不完全な状態で発生します。窓口担当者は「いいと思う」と言っているが、上司はまだ知らない。制作物が完成した段階で、上司が別の方向性を持っていると発覚する。
これを防ぐには、変更依頼を受けたときに次を確認します。
- 「この変更は、御社内で関係者の確認は取れていますか？」
- 「〇〇部長も同じ方向性で合意していますか？」
この確認は失礼ではなく、後の「言った・聞いていない」を防ぐための誠実な手順です。クライアント担当者の社内を、外部から支える動きになります。
クライアント担当者の社内コーディネーションを支える設計は クライアントの窓口担当者を、外部から支える 3 つの動き に詳しく書いています。
5. 原則 4：スコープの境界を文書で示す
4 つ目の原則は、プロジェクトのスコープ（何をやる・やらないか）を文書で明示し、変更がスコープ内かどうかを判断できる状態にすることです。
スコープが口頭でしか共有されていない場合、変更が「修正」なのか「追加」なのかが判断できません。クライアントは「修正のつもり」で依頼し、制作側は「追加工数が発生する変更」として受け取る。この認識のずれが、関係性の摩擦になります。
スコープ文書に含めるのは、次の項目です。
- このプロジェクトで対象とするページ・機能・コンテンツの範囲
- 対象外の範囲（明示的に「やらない」リスト）
- スコープ外の依頼が来た場合の処理方法（別途見積もり or 次フェーズで対応）
このドキュメントを案件開始時にクライアントと共有し、変更依頼が来たときに「これはスコープ内の修正ですか、スコープ外の追加ですか」を一緒に確認できるようにします。
越境チームのキックオフでスコープを揃える設計は 越境チームのキックオフを成功させる 7 つのチェックリスト でも扱っています。
6. 原則 5：変更バッファをスケジュールに組み込む
5 つ目の原則は、変更が来ることを前提に、スケジュールにバッファを組み込むことです。
「変更ゼロで完走する」前提でスケジュールを組むと、変更が来た瞬間に納期が破綻します。変更がないことへの希望的観測をベースにしたスケジュールは、変更があった現実の前で崩れます。
具体的なバッファの組み方：
- 各フェーズの完了予定日を、実際の作業完了見込み日より 2〜3 日余裕を持って設定する
- 納期直前の 1 週間は、「仕様変更対応週」として新規作業を入れない
- クライアントへの共有日程は「完成した当日」ではなく、完成後 1〜2 日の余裕を持たせる
このバッファが、「完成したものを出したら翌日に修正依頼が来て、すぐ納期になる」という圧力から PM と外注メンバーを守ります。
PM が見えないところで行っているスケジュール調整の全体像は プロジェクトマネージャーが毎日やっている、報告以外の仕事 で扱っています。
まとめ
クライアントの仕様変更に振り回されるのは、変更の数の問題ではなく、変更を受け取ってから動くまでの体制の問題です。
5 つの原則：
- 変更の影響を、具体的に可視化する
- 変更ログを残す
- クライアント社内の合意を確認する
- スコープの境界を文書で示す
- 変更バッファをスケジュールに組み込む
これらを設計した体制では、変更が「突発事態」ではなく「想定内の動き」として飲み込まれます。仕様変更が来るたびに混乱するプロジェクトと、変更が来ても淡々と進むプロジェクトの差は、メンバーの能力ではなく、この体制の有無です。
関連記事
クライアント窓口担当者への伴走：クライアントの窓口担当者を、外部から支える 3 つの動き
キックオフでのスコープ設計：越境チームのキックオフを成功させる 7 つのチェックリスト
PM の見えない仕事：プロジェクトマネージャーが毎日やっている、報告以外の仕事
Paqut で、仕様変更を飲み込む体制を作る
Paqut なら 3 ステップで、変更ログ・影響の可視化・スコープ文書を一つの場所に集約できます。
- 無料プランで自社のワークスペースを 3 分で作る
- 案件グループに「スコープ文書」「変更ログ」タスクを常設で作る（追加料金 0 円）
- 次の変更依頼が来たとき、ログを残して影響をクライアントに示してみる
3 分で立ち上がります。