「納品後の修正」が増える本当の理由|品質定義の曖昧さを解決する方法

「納品後の修正」が増える本当の理由|品質定義の曖昧さを解決する方法
C
クリオ
Web制作ディレクター / フロントエンジニア

こんにちは!

今日は「なぜか納品後の修正が止まらない」という、現場あるあるの話をします。

納品後修正が増える本当の原因

僕も昔、まじでこれで悩みました。
納品したのに「ここのボタンの色、もっと濃くしてほしい」「このテキスト、小さく見えるんですが」って修正依頼がめっちゃ来るんですよ。
その時の僕は「要件に書いてなかったやん」って心の中で思ってました。

でもね、クライアントも悪気はないんです。
問題は、僕たちが「品質」と「要件」を曖昧なまま進めてたんですよ。

具体的には、こんな風に進めてました。

  • 「きれいなデザイン」「使いやすいUI」という抽象的な表現で合意している
  • 色や大きさの「基準」を共有していない
  • クライアントが「完成のイメージ」を持ったまま、僕たちは「最低限の実装」をしてる
  • 納品時に初めてズレに気づく

つまり、品質の定義が「人によって違う状態」で作ってたんです。
ほんまこれが修正地獄の入り口やったんですよ。

品質と要件を「言葉」で定義する大切さ

解決策は、シンプルなんです。
「品質とは何か」を、企画の段階で言葉にして、クライアントと一緒に確認することです。

僕が現場で使ってるのは「品質定義書」みたいなドキュメントです。
派手なものじゃなく、こんな感じのシンプルなもの。

  • ビジュアル品質:色のトーン、フォントサイズの階層、画像の品質基準など
  • 機能品質:レスポンシブの対応範囲、ブラウザ互換性、読み込み速度の目安
  • テキスト品質:文字数の上限、改行のルール、誤字脱字チェック体制
  • ユーザビリティ:クリック領域の最小サイズ、色彩コントラスト比など

これを初期打ち合わせで作成して、クライアントにも見てもらうんです。
「このレベルの品質を目指します」って言葉で約束することで、後々のズレが本当に減ります。

ここで大事なのは「完璧を目指さない」という判断もあるってことです。
例えば、スマートフォンの古いOSに対応させるのか、させないのか。
そういう妥協点も、あらかじめ決めておくんですよ。

現場で実践する3つのチェックリスト

では、実際にどう進めるのか。
僕が毎回やってることを、チェックリスト化しました。

  1. 企画段階で「これは対応する/しない」を明記する
    例えば「IE11は非対応」「画像最適化はquality=85で統一」みたいに、具体的に書くことです。
    曖昧なまま進めると、納品時に「対応できていない」って言われます。
  2. デザイン提出時に品質基準を添付する
    デザインファイルと一緒に「このボタンは40px以上」「テキストのコントラスト比は4.5:1以上」みたいなノートを付けるんです。
    エンジニアもクライアントも、同じルールで見られるようになります。
  3. 納品前に「品質チェックシート」で確認する
    「全ページで色のトーンが統一されているか」「モバイルでテキストが読みやすいか」「ボタンのサイズは基準内か」という項目を用意して、チェックするんです。
    これを通さないと納品しません。

僕のチームでは、この3つをルール化してから、納品後の修正がホントに減りました。
月に数件あった修正依頼が、今は「ほぼないレベル」になってます。

まとめ

Web制作の品質問題って、実は「技術的な問題」じゃなくて「コミュニケーション問題」なんですよ。
クライアントと僕たちの間に「品質のイメージのズレ」があるだけです。

それを埋める一番シンプルな方法が「言葉で定義すること」です。
企画段階で品質基準を決めて、それをドキュメント化して、チーム全員で確認する。
これだけで、本当に納品後のストレスが変わります。

最初は「そんなドキュメント、めんどくさいな」って思うかもしれません。
でも、僕からすると、これは「修正地獄から脱出するための最小限の工数」だと思ってます。

初心者の皆さんも、ぜひ試してみてください。
品質を「感覚」じゃなく「定義」で管理する。
これができれば、クライアント対応がめっちゃ楽になりますよ。

Web制作で困ったことがあったら、またこのブログを覗いてくださいね!

― クリオ