結論：修正のキャッチボールを減らす設計は、修正依頼の入り口を 1 つに集約・バージョン管理をタスク名に明記・修正回数を契約で合意・クライアント社内の意見集約を窓口担当者の責任にする、の 4 点で実装する。
「ヘッダーの色をもう少し赤くしてください」（A さん、月曜の朝メール）
「やっぱりヘッダー、現状の方が良いと思います」（B さん、月曜の昼 Slack）
「ヘッダーの形を四角からカーブに変えませんか」（A さん、火曜の朝メール）
デザインフェーズで、こういう断片的な修正依頼が複数の窓口からバラバラに届くのは、ほとんどの制作会社が経験する状況です。デザイナーは「結局どれを反映すればいいのか」と判断停止し、修正対応に時間が削られ、本来の制作時間が圧迫されます。
この記事は、デザインフェーズで発生する「修正のキャッチボール」を構造的に減らす設計を解説します。
なぜ修正のキャッチボールが起きるか
修正のキャッチボールが多くなる構造には、4 つの要因があります。
修正依頼の入り口がバラバラ。クライアントの A さんはメールで、B さんは Slack で、C さんは電話で修正を投げてくる。窓口が分散すると、デザイナー側で「今届いている修正依頼の全体像」を把握できない。
バージョン管理が曖昧。「先週送ったデザイン」が v1 なのか v2 なのか、どの修正がどの版に対するものか、双方の認識がずれる。修正したら違うバージョンに対する依頼だったと後で気づく。
修正回数の上限が合意されていない。修正は無制限に受けるのか、3 回までなのか、追加修正は別料金なのか、これが曖昧だと「際限なく続く可能性」が常にあって、デザイナーは精神的に消耗します。
クライアント社内の意見集約がされていない。A さんと B さんで意見が割れているのを、個別に制作側に投げてくる。制作側で矛盾する指示を吸収する役割が発生する。
これら 4 要因のどれかが残っているだけで、修正のキャッチボールは構造的に発生し続けます。
修正依頼を「タスク」として受ける
最初の解決策は、修正依頼の入り口を 1 つに集約することです。
メール・Slack・電話で来た修正依頼を、すべてタスク管理ツール上のタスクとして受け直す。「ヘッダーの色変更」「フッターのアイコン差し替え」「メインビジュアルの構図変更」、それぞれが 1 つの修正タスク。
クライアント側に「修正依頼はこちらのツールで」と最初に依頼するのが理想ですが、慣れない場合は制作側で代理タスク化する運用でも構いません。メールで届いた修正依頼を、PM がタスクに変換して、コメントで「以下の修正依頼を受領しました。担当：田中。対応予定：水曜まで」と返す。
これで、修正対応の状態が「どこにいるか分からない」から「タスクとして見える」に変わります。クライアント側も自分の依頼が確実に受け取られたことを確認できます。
バージョン管理を明示する
修正タスクには、対象のバージョンを明記します。
タスク名の例：
- v2 ヘッダーの色を #FF0000 に変更
- v2 フッターのアイコンを A 案から C 案に差し替え
- v3 メインビジュアルの構図変更（送付資料参照）
「v2」「v3」のプレフィックスがあるだけで、どの版に対する依頼かが明確になります。納品物のファイル名・URL も「Design_v2.fig」のように統一して、タスクとファイルの対応関係を見える形にします。
バージョン管理が明示されると、「あの修正、どの版で反映済みでしたっけ」という確認の往復が消えます。
修正回数とスコープの合意
キックオフ時点で、修正回数の目安と追加修正のラインを合意しておきます。
例：
- ロゴデザイン：3 回までの修正を含む。4 回目以降は追加見積もり（1 修正あたり ¥X）
- Web サイトの主要ページ：各ページ 2 回までの修正を含む
- スコープ外の追加要望は別タスクで扱い、追加見積もりを案内
この合意があると、修正回数を超えそうなときに「次の修正は追加見積もりの対象になります」と自然に伝えられます。クライアントも「あといくつ修正できるか」を把握しながら指示を整理できる。
修正回数を最初に決めずに進めると、際限なく対応する流れになって、デザイナーの労力と利益率の両方が削れます。
クライアント社内の意見集約は、相手側にお願いする
クライアント社内で意見が割れている状態を制作側に持ち込まれると、矛盾する指示の吸収役を制作側が担うことになります。これは構造的に解決不可能な状況です。
キックオフ時に「修正依頼はクライアント側で意見を集約してから、1 つにまとめて渡してください」という合意を取っておきます。窓口担当者がクライアント社内の調整役を担う、という役割分担です。
A さんと B さんで意見が割れた場合、A さんと B さんで先に話し合って合意してから、合意した内容を制作側に伝える。これがクライアント側の責任範囲。制作側はその合意された依頼に対して、修正を実施する。
合意取りを最初にしていないと、後から「整理してから渡してください」と言うのが気まずくなります。最初に決めるのが安価です。
デザイナーの集中時間を守る
修正対応は集中力を必要とする創造作業の対極にあります。デザイナーが朝から夕方まで断続的に修正依頼を処理していると、まとまった創作時間が取れません。
タスク管理ツールに修正依頼が集約されると、「修正対応する時間」と「制作に集中する時間」をデザイナー側で分けられるようになります。例えば、午前は新規制作の集中時間、午後 14 時以降にタスク管理ツールを開いて修正タスクをまとめて処理する、というリズム。
リアルタイムのチャットでバラバラに対応するのと、タスクとしてまとめて処理するのとでは、生産性が変わります。クライアント側にも「修正対応は当日 14 時以降にまとめて反映します」と最初に伝えておくと、即応を期待しなくなって、お互いに無理がない関係になります。
修正のキャッチボールを完全に消すことはできない
最後に注意点として、修正のキャッチボールを完全にゼロにすることはできません。クライアントワークの本質的な往復は避けられないからです。
この記事の目標は、構造的な無駄を減らすことです。窓口の分散、バージョンの混乱、回数の曖昧さ、意見集約の負担、これらを取り除けば、本質的な創造的議論のための往復だけが残ります。それは健全なコラボのキャッチボールです。
関連記事
クライアントとの共有運用全体の設計は クライアントに進捗を見せる仕組みの作り方、キックオフでの合意項目は クライアントとのキックオフをタスク管理で仕組み化する を参照してください。
外部メンバーとの仕事を回す全体像は 外部メンバーとのチームタスク管理 完全ガイド にまとめています。
Paqut で、修正タスクを集約する
この記事で書いた修正対応の集約は、Paqut なら 3 ステップで運用できます。
- 「v2 ヘッダーの色変更」のようにバージョン明記でタスクを作る
- クライアントを招待リンクで呼んで、修正依頼はタスクのコメントで受ける
- 完了したら次バージョンのタスクへ。議論履歴がタスクと一緒に残る
3 分で立ち上がります。