Web制作の修正回数は何回が正解？決め方の基準

3年目、まだ現場に慣れきっていなかった頃の話です。私が担当したあるサイト制作案件で、見積書には「デザイン修正は2回まで」とだけ書いていました。それ以上の細かい取り決めはしていませんでした。

案件が始まると、担当者さんからチャットで少しずつ修正依頼が届きます。

「ボタンの色を少し変えたい」
「やっぱり見出しの位置を戻したい」
「上司に見せたら雰囲気を変えてほしいと言われた」

1件1件は小さな依頼でした。私は「これはまだ1回目の途中だろう」と思って全部対応していたのですが、気づけば1週間で10通近いやり取りになっていて、デザイナーの手も止まりっぱなしでした。

先方に「そろそろ2回目に入っています」と伝えたところ、「え、まだ1回も直してもらってない感覚です」と言われてしまい、その場の空気が一気に気まずくなったのを覚えています。原因は回数の少なさではなく、「何を1回と数えるか」を最初に決めていなかったことでした。

結論:基準は「2〜3回」。ただし回数より先に決めるべきことがある
1. なぜ2〜3回が現場感覚に合うのか
2. 回数を減らすことより、「何を1回とカウントするか」の方が重要
修正回数に「含めるもの」「含めないもの」
2〜3回という基準を、案件に当てはめる考え方
現場でよくある「回数のカウント」トラブルと防ぎ方
1. 「指示ベース」ではなく「提出ベース」で数える
クライアントへの伝え方(見積書・提案書の書き方例)
1. 見積書に入れる一文の例
2. 3回目を超えそうなとき、実際にどう切り出すか
まとめ
1. ディレ和尚のひとこと

結論:基準は「2〜3回」。ただし回数より先に決めるべきことがある

結論から言うと、修正回数の基準は「2〜3回」で問題ありません。これは業界的にもよく使われている水準で、特別な理由がない限りここを大きく外す必要はないと考えています。

なぜ2〜3回が現場感覚に合うのか

1回目：方向性のズレを直す(トンマナ、レイアウトの大枠)
2回目：細部の調整(色味、文言、余白など)
3回目：最終確認レベルの微調整

この3段階で大半の案件は着地します。逆に4回、5回と回数が伸びていく案件は、回数の問題というより「最初の要望のすり合わせ不足」か「承認フローの混乱」が原因になっていることがほとんどです。私の経験でも、揉めた案件の共通点は「回数が少なかった」ことではなく、「回数の数え方が曖昧だった」ことでした。

回数を減らすことより、「何を1回とカウントするか」の方が重要

冒頭の失敗談がまさにそうですが、回数そのものより、何をもって「1回」とするかの定義がないと、どんな数字を設定しても揉めます。ここが今回、一番お伝えしたいポイントです。

修正回数に「含めるもの」「含めないもの」

私は、修正回数の枠に含めるかどうかを、次の基準で分けています。

種類	内容	回数にカウントするか
不備対応	指示通りになっていない箇所の直し(誤字、表示崩れ、リンク切れ、仕様の実装漏れなど)	含めない
修正	すでにOKした内容の範囲内での微調整(色味、文言、余白など)	含める
変更	一度確定した内容を、後から方向転換する(コンセプト自体を変える、ターゲットが変わるなど)	含める(むしろ別途相談・見積もりの対象)

含めない:指示通りになっていない箇所の直し

こちらの実装ミスや確認漏れは、そもそも「正しい状態」がすでに合意されているものを直しているだけなので、修正回数には含めません。これは何回目だろうが対応すべきものです。ここを回数に含めてしまうと、クライアントは不具合の指摘すらしにくくなり、結果的に品質チェックの機会を失うことになります。

含める:一度確定した内容を後から変える「変更」

一方で、「やっぱり全体的にもっと明るい印象に」「ターゲット層が変わったので構成から見直したい」といった、確定済みの内容を覆すものは「変更」です。

これは通常の修正枠とは別に扱うべきで、場合によっては追加のお見積もりが必要になる旨を、あらかじめ伝えておくのが安全です。

この線引きを最初に伝えておくことが、揉め事を防ぐ一番の近道

回数の数字だけを提示するのではなく、「この3つはこう区別しています」という説明を先に済ませておくこと。これだけで、後々の「これは何回目ですか」という気まずいやり取りはかなり減ります。

2〜3回という基準を、案件に当てはめる考え方

基準値はあくまで初期値です。実際の案件では、次の3つの軸で微調整しています。

①予算・工数から逆算する

小規模なLPやコーポレートサイトのTOPページ程度であれば2回、ページ数が多く関係者が複数いる案件であれば3回、というように、修正にかけられる時間が予算にどれだけ含まれているかで決めます。

②工程ごとに回数を分ける

デザイン段階と、コーディング後の確認段階では、修正の意味がまったく違います。私は以下のように分けることが多いです。

デザイン：2〜3回(方向性・トンマナの調整)
コーディング後：1回程度(表示確認レベルの微調整のみ。不備対応は別枠)

「修正は全体で◯回まで」とひとまとめにしてしまうと、デザインで使い切った後にコーディング後の不具合対応ができなくなる、という不自然な状態になります。工程ごとに分けておくと、この矛盾を防げます。

③超過したときのルールを先に決めておく

回数を超えた場合にどうするかを、事前に一文入れておきます。

上記の回数を超える修正につきましては、別途ご相談のうえ追加費用を頂戴する場合がございます。

「断る」ためではなく、「選んでもらう」ための一文です。この一言があるだけで、いざというときに気まずさなく話を切り出せます。

現場でよくある「回数のカウント」トラブルと防ぎ方

「指示ベース」ではなく「提出ベース」で数える

修正の指示が3件来たとしても、こちらがまとめて1回で反映して提出すれば、消化は1回とカウントします。逆に、指示のたびに1回消化する数え方にすると、細かい依頼のたびにクライアントの回数が減っていき、不満が溜まりやすくなります。提出ベースにしておくと、「指示はまとめて出したほうが得」という動機がクライアント側にも生まれ、結果的にやり取りの回数自体が減ります。

なお、実際に仕様変更そのものが発生してしまった場面での初動対応については、仕様変更にも慌てない。Webディレクターがまずすべき「止める・聞く・伝える」の初動で詳しく整理していますので、あわせて読んでいただくと、事前のルール決め(今回)と発生時の対応(そちらの記事)の両方をカバーできます。