無限修正回避策

どうも、くまだです。

Web制作のコーディング案件で、ときどき出会う無限修正(しかも無料)の回避策。

無限修正回避策

私も駆け出しのころ無限修正(無料)をやらされていたことがありますので、無限修正は経験済。

そもそもとして、しっかりしたものを納品することが大事です。納品したものが悪いのは、こちらの手違いなのでそれに関しての修正は対応すべきです。

無限修正が発生するいくつかの理由を考えると、例えば、

  • 仕様が確定していない
  • デザインが確定していない
  • 実装してみたら心変わりして変更になる(例:デザインカンプどおり実装してるけど、画面みたらなんか文字が大きい気がする→やっぱり変えたいなど)
  • 修正と変更の区別のついていない

などかなと。

確定していないものは、(仮)で実装したとてやっぱり変更になる、ということも想定されます。

「確定したもの」を実装してみたら心変わりして変更になる、というのはデザインカンプどおりコーディングして実装しているはずなんですが、実際画面で見てみたら思っていたよりも文字が大きいor小さい、要素やパーツが大きいor小さい、余白感が広いor狭い…など(心変わり)の理由で修正になる、ことがあります。

そういった修正はたいがい軽微なため、無料で対応しがちです。

無限修正の回避策としては、

  • 回数制限を設ける
  • 細かい対応でも料金を請求する
  • 「変更」は修正でないので、料金を請求する

回数制限は自分はやったことがないのでわかりませんが、「3回まで無料、それ以上は有料になります」みたいな回数制限を設けて無限修正を回避している人もいるようです。

自分は今はやっていないのですが、月額で定額いくらで、「修正対応費(軽微な追加も含む)」で対応したことがあり、その形になると無限修正も有料になるので定期的な収入に変わります。この「修正」というのも「実装してみたら心変わりして変更になる」パターンがほとんどです。

もちろん、例えば下層ページ追加は「追加」なので別途料金が発生します。他にも、例えば片側スライドショーから、左右チラ見せスライドに仕様変更みたいなものも、別途料金発生します、みたいな形にすればいいです。

こんな感じで結局料金が発生するように仕向けると、無限修正もだんだんなくなっていきます。

ここまで読んでくださりありがとうございました。

この記事を書いた人