クライアントと揉めずに修正とスコープ変更を料金化する方法

ミス修正、改訂、スコープ変更を分ける

ミス修正は、合意した要件を満たさない作業や自分の誤りを直すものです。通常は自分の責任です。含まれる改訂は、決められた回数の範囲で合意済み成果物を調整します。スコープ変更は、合意後に新しい成果物、挙動、対象者、形式、連携、判断を追加します。

依頼の見た目の大きさではなく定義で判断します。ボタン色の変更は含まれる改訂かもしれません。一方、ユーザーロール追加は一文で頼めても大きなスコープ変更になり得ます。「ほんの小さなこと」は測定単位ではありません。

• ミス修正：納品物が合意済み要件を満たしていない
• 含まれる改訂：合意済み結果と回数の範囲内の調整
• スコープ変更：新しい成果物、挙動、依存関係、受け入れ条件
• クライアント遅延：合意済みスケジュール条件に従う日程問題

プロジェクト開始前に修正回数の意味を定義する

「修正2回」とだけ書き、全員が同じ意味に解釈すると考えないでください。1ラウンドを、権限を持つ意思決定者から期限までに届く一つの統合フィードバックとして定義します。未使用ラウンドの扱い、メッセージや会議に分散したフィードバックの扱いも明記します。

変更の深さも定義します。デザイン修正にはタイポグラフィ、余白、視覚方向を含めても、新しいページ階層や事業モデルは含めない、といった境界です。無制限修正が成立するのは、厳密な境界を持つ高度に標準化されたサービスだけです。そうでなければ「無制限」が最初に利益を食べます。

3つの質問でスコープを判定する

まず、その依頼が書面の受け入れ条件を満たすために必要かを確認します。必要ならミス修正かもしれません。次に、既存の選択肢を置き換えるのか、新しい選択肢を追加するのかを確認します。最後に、依存関係、テスト、日程、責任が変わるかを確認します。新しい影響があるなら、多くの場合は新しいスコープです。

答えが曖昧なら、影響する作業を止め、解釈を書面にします。実装前の2分の確認は、請求時に「含まれていると思っていた」と判明するより安く済みます。

実装する前に変更価格を決める

内部の簡単な式は、変更価格 = 追加時間 × 適用単価 + 直接費 + 残る不確実性に対する固定価格リスク分です。緊急料金、専門料金、最低変更料金を事前合意していない限り、契約単価を使います。

短い書面の変更依頼を送ります。何が変わるか、元のスコープ外である理由、追加成果物、追加価格、スケジュールへの影響、新しい前提、承認方法を書きます。予算承認権のない人の👍だけで追加作業を始めないでください。

• 元のスコープまたは受け入れ条件への参照
• 要求された変更と追加成果物の説明
• 追加価格、税の扱い、支払時期
• 変更後のマイルストーンまたは納期
• 新しい依存関係、除外事項、承認方法

実例：ランディングページの小さな変更

承認済みスコープには標準リードフォームと2回の統合デザイン修正が含まれます。承認後、クライアントがCRM連携と分析イベントを持つ多段フォームを依頼しました。これは新しい挙動、新しい依存、追加テストであり、見た目の修正ではありません。

実装7時間、テスト2時間、連絡とリリース1時間、合計10時間と見積もります。単価80なら作業費800。外部直接費50と、まだ不確実なCRM接続に対する作業費の10%、80を追加します。変更価格は税前930で、納期は2営業日延びます。

一方、含まれるデザインラウンド中のボタン色変更は含まれたままです。判断基準は合意結果と影響であり、どちらかが「小さい」と強く主張するかではありません。

関係を守る言葉を使う

事実ベースで伝えます。「この依頼はCRM連携と新しいフォーム挙動を追加するため、合意済みスコープ外です。930で追加し納期を2営業日延長できます。または現状スコープと元の日付を維持できます。どちらを希望するか確認してください。」

これは拒否でも罰でもありません。予算、スコープ、時間についてクライアントに選択権を与えます。落ち着いた変更管理は信頼を高めやすく、代替は突然の請求、静かな不満、あるいはサービスの名の下の無償作業になりがちです。

承認後に変更を最後まで反映する

見積もり、タスクリスト、受け入れ条件、タイムライン、支払スケジュールを更新します。承認記録をプロジェクトに保存し、実装する全員が新しい境界を理解していることを確認します。

プロジェクト終了後、繰り返し出た依頼を確認します。毎回同じ追加を求められるなら、今後の提案でオプション化します。スコープ管理は防御だけではありません。少し地味な服を着たプロダクトリサーチでもあります。