クライアントが「修正」と言う前に気づく品質チェックリスト｜現場で使える実践テクニック

こんにちは！

今日は「クライアントが指摘する前に自分たちで気づく品質チェックリスト」について解説します。

納品直前に修正地獄に陥る理由

Web制作を始めたばかりの頃、僕は納品日の前日になってクライアントにサイトをお見せして、そこからめっちゃ修正が出たことがあります。
それもほんま些細な修正ばっかり。
「ここのテキスト、もう一文字下がってません？」とか「このボタンの色、デザインと違う気がします」とか。

その時に気づいたんです。
「あ、これ全部、自分たちでチェックできてたやん」って。

現場でよく見るのは、開発者が「一応動いてるし大丈夫だろう」と思って納品しちゃうパターンなんですよね。
でも品質って、動くだけじゃなくて「意図した通りに動いてるか」「見た目はデザイン通りか」「ユーザーの操作感は大丈夫か」という部分なんです。

そこを意識的にチェックするかしないかで、納品後の修正対応の量が本当に変わってきます。

実際に使ってるチェックリスト

今の僕たちのチームで使ってるチェックリストを、ちょっと公開しちゃいます。
これは機能別チェックと見た目別チェック、2段階に分けてます。

第1段階：機能チェック（開発者が自分でやる）

• 全てのリンク（<a>タグ）が正しい遷移先を指してるか
• フォーム送信が実装通りに動いてるか（バリデーション含む）
• 画像は正しいパスで読み込まれてるか（/images/配下の確認）
• JavaScriptの処理が全ブラウザで動いてるか
• コンソールにエラーが出てないか（console.logも削除したか）
• 不要なconsole.errorや開発時のログが残ってないか
• ローカル環境でのパスを本番パスに直してるか

第2段階：見た目チェック（ディレクターとペアで確認）

• デザインと実装がピクセル単位で一致してるか
• フォントサイズ、色、line-heightはデザイン通りか
• レスポンシブ対応で各ブレークポイントが意図通りか
• ホバー状態、アクティブ状態が実装されてるか
• スペーシング（margin、padding）に違和感ないか
• テキストの改行位置がおかしくないか
• 画像の圧縮率は適切か（読み込み速度とクオリティのバランス）
• ダークモード対応があれば、その検証も含む

第3段階：ユーザー目線チェック

• 初めて見る人が「何のサイト」か理解できるか
• 重要なボタンは目立ってるか
• フォーム入力で迷う項目がないか
• エラーメッセージは親切か
• トップページからどこにでも戻れるか

ほんま重要なのは、この第3段階です。
機能と見た目はチェックしてるのに、「使いやすさ」はスルーしちゃう案件、めっちゃ多いんですよ。
でもこれがクライアント満足度に一番響くんです。

チェックリストを回す「タイミング」が大事

リストを作ったからいいわけじゃなくて、「いつ」それを使うかがメッチャ大事です。

僕も最初は「納品の前日に全部チェックしよう」って思ってたんですけど、これ効率悪いんですよ。
なぜなら、その時点で修正が見つかると、修正→テスト→再確認のサイクルが回って、納期にバタバタしちゃうから。

今はこのタイミングでチェックしてます。

1. 機能実装後すぐ：開発者が自分で機能チェックを完結させる（その日のうちに）
2. レイアウト実装後：ペアプログラミングか相互レビューで見た目をチェック
3. 納品3日前：ディレクターが全体的に見直す（この時点でやることほぼない状態に）
4. 納品前日：最終確認（本当に最終です）

早め早めでチェックを入れることで、修正も小さい単位で対応できるし、納期も守れるんです。

あと、よくあるのが「色が違う」っていう指摘なんですけど、これもデザイナーと開発者で色コードを共有するだけで防げるんですよ。
Figmaなら直接コードを確認できるし、色管理用のCSS変数（--primary-color: #3b79b7;みたいに）を使ってれば、あとで一括変更もできますしね。

まとめ

Web制作の品質って、実は難しくなくて、「意識的にチェックするか」「しないか」の違いだけなんです。
クライアントから指摘が来るってことは、僕たちの事前チェックが足りなかったってサインなんですよ。

最初は「チェックリスト作って使う」って手間に感じるかもしれませんけど、実際には修正対応の時間が圧倒的に減ります。
結果的に納期も守れるし、クライアント満足度も上がるし、チーム内のストレスも減るんです。

あなたのチームでも、まずは「機能チェック」と「見た目チェック」の2つだけでいいので、ちょっと意識的にやってみてもらえたら嬉しいです。
ほんまに変わりますよ。