「納品後の修正」が増える本当の理由|品質定義の曖昧さを解決する方法
こんにちは!
今日は「なぜか納品後の修正が止まらない」という、現場あるあるの話をします。
納品後修正が増える本当の原因
僕も昔、まじでこれで悩みました。
納品したのに「ここのボタンの色、もっと濃くしてほしい」「このテキスト、小さく見えるんですが」って修正依頼がめっちゃ来るんですよ。
その時の僕は「要件に書いてなかったやん」って心の中で思ってました。
でもね、クライアントも悪気はないんです。
問題は、僕たちが「品質」と「要件」を曖昧なまま進めてたんですよ。
具体的には、こんな風に進めてました。
- 「きれいなデザイン」「使いやすいUI」という抽象的な表現で合意している
- 色や大きさの「基準」を共有していない
- クライアントが「完成のイメージ」を持ったまま、僕たちは「最低限の実装」をしてる
- 納品時に初めてズレに気づく
つまり、品質の定義が「人によって違う状態」で作ってたんです。
ほんまこれが修正地獄の入り口やったんですよ。
品質と要件を「言葉」で定義する大切さ
解決策は、シンプルなんです。
「品質とは何か」を、企画の段階で言葉にして、クライアントと一緒に確認することです。
僕が現場で使ってるのは「品質定義書」みたいなドキュメントです。
派手なものじゃなく、こんな感じのシンプルなもの。
- ビジュアル品質:色のトーン、フォントサイズの階層、画像の品質基準など
- 機能品質:レスポンシブの対応範囲、ブラウザ互換性、読み込み速度の目安
- テキスト品質:文字数の上限、改行のルール、誤字脱字チェック体制
- ユーザビリティ:クリック領域の最小サイズ、色彩コントラスト比など
これを初期打ち合わせで作成して、クライアントにも見てもらうんです。
「このレベルの品質を目指します」って言葉で約束することで、後々のズレが本当に減ります。
ここで大事なのは「完璧を目指さない」という判断もあるってことです。
例えば、スマートフォンの古いOSに対応させるのか、させないのか。
そういう妥協点も、あらかじめ決めておくんですよ。
現場で実践する3つのチェックリスト
では、実際にどう進めるのか。
僕が毎回やってることを、チェックリスト化しました。
- 企画段階で「これは対応する/しない」を明記する
例えば「IE11は非対応」「画像最適化はquality=85で統一」みたいに、具体的に書くことです。
曖昧なまま進めると、納品時に「対応できていない」って言われます。 - デザイン提出時に品質基準を添付する
デザインファイルと一緒に「このボタンは40px以上」「テキストのコントラスト比は4.5:1以上」みたいなノートを付けるんです。
エンジニアもクライアントも、同じルールで見られるようになります。 - 納品前に「品質チェックシート」で確認する
「全ページで色のトーンが統一されているか」「モバイルでテキストが読みやすいか」「ボタンのサイズは基準内か」という項目を用意して、チェックするんです。
これを通さないと納品しません。
僕のチームでは、この3つをルール化してから、納品後の修正がホントに減りました。
月に数件あった修正依頼が、今は「ほぼないレベル」になってます。
まとめ
Web制作の品質問題って、実は「技術的な問題」じゃなくて「コミュニケーション問題」なんですよ。
クライアントと僕たちの間に「品質のイメージのズレ」があるだけです。
それを埋める一番シンプルな方法が「言葉で定義すること」です。
企画段階で品質基準を決めて、それをドキュメント化して、チーム全員で確認する。
これだけで、本当に納品後のストレスが変わります。
最初は「そんなドキュメント、めんどくさいな」って思うかもしれません。
でも、僕からすると、これは「修正地獄から脱出するための最小限の工数」だと思ってます。
初心者の皆さんも、ぜひ試してみてください。
品質を「感覚」じゃなく「定義」で管理する。
これができれば、クライアント対応がめっちゃ楽になりますよ。
Web制作で困ったことがあったら、またこのブログを覗いてくださいね!
― クリオ