クライアントワーク慣れていないので、修正依頼の通知が来るたびに、心臓がドキッとしてしまいます。
最初の頃は、通知が来るたびに不安になったりして、向いていないのかなぁなんて考えたり。
「また何かやらかしたかも」「なにかヌケモレしてたかな？」「バグ？」そんな不安が毎回よぎるんですよね。
修正依頼が来るたびにメンタルやられるんだけど、みんなそうなの？
正直、僕も最初はそうでした。でも今は「一緒にサイトを良くするプロセス」だと思えるようになりましたよ
怖がって対応が遅れるほうが、信頼を失うリスクはよっぽど高いと感じています。
この記事では、フリーランスコーダーとして実際に修正依頼を受けてきた僕の体験談をもとに、怖さとの向き合い方や対応フローをまとめました。
- 修正依頼が来るたびに落ち込んでしまう人
- 無償対応と追加料金の線引きがわからない人
- クライアントとのやり取りに苦手意識がある人
- 修正依頼への対応フローを知りたい人
初めて修正依頼が来た時の正直な気持ち
初めてクライアントから修正依頼が来た瞬間のことは、今でもはっきり覚えています。
チャットの通知を見た瞬間、「やっちまった」と「申し訳ない」が同時に押し寄せてきました。
正直、自分のコーディングスキルを全否定された気分だったんですよね。
冷静に振り返ると、僕がやっていたのはデザインカンプからのズレた実装でした。
具体的にどんなミスだったの？
余白やフォントサイズを「だいたいこのくらいかな」で進めてしまっていたんです。Figmaの数値をちゃんと拾わずに感覚で組んでいました
デザインの意図を確認せず、自分の判断で進めてしまったのが一番の原因だったと思います。
今振り返ると、「迷ったらまず聞く」——これだけで防げたミスがほとんどでした。
当時の僕は「聞いたら迷惑かな」と思ってしまっていたんですよね。
ポイント: 修正依頼は「スキル不足の証明」ではなく「確認不足の結果」であることが多いです。聞く勇気を持つだけで、修正依頼の数はかなり減りました。
実際にどんな修正依頼が来たか
「修正依頼」と聞くとバグや致命的なミスを想像するかもしれませんが、実際はそこまで大ごとではないケースがほとんどでした。
僕が受けてきた修正依頼の多くは、デザイン調整やレイアウト変更がメインだったんですよね。
特に多かったのが、レスポンシブでの見え方に関するフィードバックです。
- 余白の調整（デザインカンプとの差異）
- フォントサイズの微調整
- スマホ表示でのレイアウト崩れ
- px指定を%やvwに変更する指示
- ホバーアニメーションの調整
ちなみに、コーディングがわかるクライアントからの指摘は、正直プレッシャーがすごかったです。
「ここのmargin-bottomを24pxにしてください」みたいに具体的に言われると、見られてるなあと感じました。
具体的に指摘されると余計に怖くない？
最初は怖かったんですけど、裏を返せば「何を直せばいいか明確」なので対応はしやすいんですよ。曖昧な指摘のほうがよっぽど困ります
振り返ると、修正依頼の9割は「確認すれば防げたもの」だったと思っています。
修正依頼が来た時の対応フロー
修正依頼が来ると焦ってすぐ手を動かしたくなるんですが、僕の場合はまず「内容を正確に理解する」ことを最優先にしています。
焦って的外れな修正をすると、二度手間になって余計に信頼を落とすんですよね。
だから最初にやるのは、修正内容を自分の言葉でまとめ直すことにしています。
- 修正内容を確認し、自分の理解を言葉にまとめる
- チャットで「こういう理解で合っていますか？」と確認を送る
- 必要ならFigmaで完成形イメージを共有する
- ローカル環境（Local by Flywheel）で修正・確認
- テストサイトにアップしてクライアントに共有
特に大事だなと感じているのが、ステップ2の「理解の確認」です。
「余白を広げてほしい」と言われたとき、どこの余白をどのくらい広げるのかは人によって違うんですよね。
Figmaで共有するってどういうこと？
修正後のイメージをFigma上でサクッと作って「こんな感じでいいですか？」って送るんです。口頭の説明より圧倒的に認識がズレにくくなりますよ
この「確認→修正→共有」のサイクルを回すようになってから、修正のやり直しがほぼなくなりました。
補足: テストサイトへのアップは、Local by Flywheelで作ったローカル環境をそのままXserverのテスト用サブドメインに反映しています。本番に影響しない環境で確認してもらうのがポイントです。
無償対応？追加料金？線引きの考え方
修正依頼で一番悩むのが、「これは無料で直すべきなのか、追加料金をもらうべきなのか」という線引きだと思います。
正直、僕も最初のうちはこの判断がまったくできませんでした。
初期の頃は実績作りを優先していたので、ほとんどの修正を無償で対応していたんですよね。
全部無料で直してたの？それって損じゃない？
最初のうちはお金よりも「きれいなサイトを作りたい」「実績にしたい」という気持ちが強かったんです。でも今は線引きをはっきりさせるようにしています
今の僕の判断基準はシンプルで、「元のデザインカンプにあったかどうか」で決めています。
- 無償対応: デザインカンプの再現ミス・余白やフォントサイズの調整・レスポンシブの崩れ修正
- 追加料金: 新規デザインの追加・機能追加（問い合わせフォームのカスタマイズ等）・アニメーションの方向性変更
デザインの再現はコーダーの仕事なので、そこのズレは基本的に無償で対応するのが筋だと思っています。
一方で、カンプにない要素を新たに追加する場合は、作業量を見積もって提示するようにしています。
この基準を自分の中で持っておくだけで、判断に迷う時間がかなり減りましたね。
ちなみに: 追加料金を提示するときは「この部分は元のデザインにはなかった内容なので、追加のお見積もりをお送りしてもよろしいでしょうか？」とやんわり聞くようにしています。いきなり金額を出すと角が立つので、ワンクッション入れるのがポイントです。
「ちょっと変えたい」が膨らむ問題への対処
Web制作をしていると、納品間際に「ここもちょっと変えたいんですけど」という追加要望が出てくることがあります。
正直、これは僕が一番苦手なパターンでした。
でも冷静に考えると、クライアントに悪気はないんですよね。
サイトが形になってくると「こうしたほうがいいかも」と新しいアイデアが浮かぶのは、むしろ自然なことだと思っています。
でも追加要望がどんどん増えたらキリがなくない？
そうなんです。だから僕は納期と作業量を理由にやんわりお伝えするようにしています。感情ではなく事実ベースで話すのが大切ですよ
僕がよく使うフレーズはこんな感じです。
伝え方の例:
「この修正は対応可能ですが、現在の納期だとスケジュールが厳しくなるため、納期を○日延長するか、別途お見積もりとさせていただければと思います」
このように感情ではなく「納期」と「作業量」を理由にすると、クライアントも納得しやすいと感じています。
それから、そもそも追加要望が出にくくなる工夫も大切だと思っていて。
- コーディング前にFigmaで完成形イメージを共有する
- セクションごとにテストサイトへアップして都度確認してもらう
- 「ここの部分は○○という理解で進めますね」とチャットで記録を残す
事前に共有しておけば、納品後の「思ってたのと違う」がかなり減りました。
修正依頼が怖い人へ——当然あるものとして備えよう
ここまで読んでくれた方には伝わっていると思いますが、修正依頼はフリーランスコーダーにとって「避けられないもの」なんですよね。
だからこそ、怖がるのではなく「当然あるもの」として備えておくのがいいと思っています。
僕が実際にやっているのは、修正対応のための時間を最初からスケジュールに入れておくことです。
どのくらいの時間を見ておけばいいの？
僕の場合は納品後に2〜3日の修正期間を確保するようにしています。空いたら自分の勉強や別の案件に使えばいいだけですよ
この「バッファ」を持っておくだけで、修正依頼が来ても焦らなくなりました。
「修正が来るかもしれない」と構えておくのと、「来ないだろう」と思っていて来るのでは、精神的なダメージが全然違うんですよね。
正直に言うと: 今でも修正依頼の通知音にはドキッとします。完全に平気になる日は来ないかもしれません。でも「対処法を知っている」という安心感があるだけで、怖さの質がまるで変わりました。
修正依頼を恐れるのではなく、「来たらこう動く」というフローを持っておくのが、僕にとっては一番の安心材料になっています。
まとめ
修正依頼が怖いのは、経験が浅いうちは誰でも同じだと思います。
最後に、この記事の要点を振り返っておきますね。
- 修正依頼は「失敗の通知」ではなく「一緒にサイトを良くするプロセス」
- 最初の修正依頼はショックだったが、原因は「確認不足」がほとんどだった
- 実際の修正内容はデザイン調整やレスポンシブ対応がメイン
- 対応フローは「内容確認→理解を送る→修正→テストサイトで共有」
- 無償か追加料金かは「元のデザインにあったかどうか」で判断
- 追加要望には感情ではなく「納期」と「作業量」で伝える
- 修正対応の時間をスケジュールに最初から組み込んでおく
修正依頼は、対処法を知っていれば怖くなくなります。
この記事が、同じように修正依頼に悩んでいる方の参考になれば嬉しいです。
コメント