チェックバックの進め方｜制作会社がステージング確認を漏れなく回す手順
Contents
公開前のチェックバックは、制作会社の品質を左右する工程です。
ステージングURLを送っただけで「確認お願いします」と書くと、クライアントはどこを見ればよいか分からず、返信は「だいたい問題ないです」で終わります。
その直後に、別の決裁者から細かい指摘が届く——よくある失敗です。
本記事は、Web制作会社・制作機能を持つ広告代理店のディレクター向けに、チェックバックを漏れなく回す手順をまとめます。
発注側の社内説明にも転用できますが、主眼は制作側の進行管理です。
チェックバックで制作会社が負けるパターン
「見ました」と「承認した」が混ざる
クライアントから「OKです」と返ってきても、それは見た感想なのか、公開してよい承認なのかが曖昧なことがあります。
後から「営業部長はまだ見ていない」と言われ、手戻りになります。
チェックバックの依頼文では、次を分けて書きます。
- 今回の確認範囲（ページ一覧、端末）
- 欲しい回答の種類（指摘一覧 / 公開承認）
- 期限と、期限後の扱い
指摘の受け口が散らばる
メール本文、Slackのスレッド、口頭、スプレッドシート——受け口が複数だと、制作側の一次受けが漏れます。
チェックバック期間中は、指摘の受付場所を一つに宣言することが先です。
修正と再確認のラウンドが定義されていない
1回のチェックバックで全部終わる想定は危険です。
修正後の再確認を誰が・いつまでに行うかを先に決めておかないと、公開日直前に第二ラウンドが始まります。
依頼前に制作側が揃えるもの
確認用の環境情報
次をセットで渡します。
- ステージングURL（Basic認証があればID/PASS）
- 確認対象ページの一覧（優先度付き）
- 推奨確認端末（PC / スマホの幅）
- テスト用アカウント（会員機能がある場合）
ページ数が多い案件では、全ページ一括より「公開必須ページ」と「後追い可」を分けると回収率が上がります。
確認観点のガイド（短くてよい）
クライアントに完璧なQAを求める必要はありません。
次のような短いガイドで十分です。
- 文言・画像・価格など事実情報の誤り
- スマホでの見切れ・押しにくさ
- 主要導線（問い合わせ・申込）の分かりやすさ
- 社内で必ず見る決裁者の視点（法務・ブランドなど）
「デザインの好みを全部書いてください」は、収拾がつかなくなります。
観点を先に絞りましょう。
チェックバック依頼の文例（制作会社→クライアント）
件名やチャットの冒頭に使える文例です。
お世話になっております。
○○サイトの公開前確認（チェックバック）をお願いします。■確認環境
URL: …
認証: …■今回見てほしい範囲
・トップ、サービス、お問い合わせ（優先）
・スマホ表示を中心に■回答期限
○月○日（○）17:00まで■回答方法
指摘は△△へご記入ください（1件ずつ、該当画面が分かる形で）。
「公開してよい／要修正」の判断もあわせてご共有ください。期限後に追加でいただいた内容は、公開後対応または別見積となる場合があります。
「だいたい問題ない」だけが返ってきたときは、公開判断の有無を確認する一文を送ります。
指摘を受け取ったあとの社内フロー
トリアージをディレクターが先に行う
届いた指摘をすぐ実装へ流すと、優先度の低い修正に工数が吸われます。
制作会社側で次の分類をします。
| 区分 | 例 | 扱い |
|---|---|---|
| 公開前必須 | 誤情報、導線不能、重大な崩れ | 今回対応 |
| 公開後可 | 微細な余白、好みの調整 | バックログへ |
| 要確認 | 仕様変更に近い要望 | 影響と条件を返答 |
クライアントには、分類結果を短く返すと信頼が上がります。
「すべて対応します」より、「公開前に6件、公開後に4件」の方が進捗が見えます。
修正単位をページと要素で固定する
「全体的に明るい感じに」のような指摘は、実装タスクに分解します。
担当（デザイン / コーディング）、対象URL、完了条件をセットにします。
ここが曖昧なままチャットで流すと、スクショ赤入れが流れる問題と同じ失敗になります。
再確認は差分だけ見せる
全ページの再チェックを求めると、クライアントの負担が大きく、返信が遅れます。
修正した箇所の一覧と、確認用URLを添えて「差分確認」にします。
チェックバック期間中のデイリー運用
制作会社側は、期間中に次だけ回すと漏れが減ります。
- 朝：新規指摘をトリアージし、公開前必須だけ実装レーンへ
- 昼：対応済みを差分リストへ追記
- 夕：クライアントへ「本日対応N件／残M件」を短く共有
長い報告書は不要です。
件数と次の確認タイミングが分かれば十分です。
指摘の受け口がチャットのままだと、このデイリーも破綻しやすいです。
受け口を一つにしたうえで回しましょう。
公開判断を残す
チェックバックのゴールは指摘回収だけではありません。
制作会社としては、次を記録に残します。
- 誰が（役割）
- どの範囲を
- いつ
- 公開可としたか
口頭の「大丈夫です」だけだと、後工程の責任分界が曖昧になります。
メールの一文でも、レビューツール上の承認でも構いません。
残すこと自体が重要です。
ページ単位の合意形成まで含める場合は、サイトマップと承認の一体管理の考え方も併せて検討できます。
まとめ：チェックバックは「依頼設計」が本体
制作会社のチェックバックは、URL送付では始まりません。
確認範囲・回答方法・期限・指摘の受け口を先に設計し、届いた指摘をトリアージしてから実装に回します。
修正後は差分確認に絞り、公開判断を記録する。
この型があれば、「だいたいOK」のあとの炎上を減らせます。
Revoolなら、チェックバックの指摘と進捗を同じ画面で追える
指摘の受け口を一つにするとき、画面上の位置と対応状況をセットで残せるかがポイントです。
タスクテーブルでは、チェックバックで届いた指摘をステータス別に管理できます。
検索・メッセージ・更新も同じ一覧で完結します。
ラウンドが進むほど、「誰の残件がどれだけあるか」が見えにくくなります。
ダッシュボードなら、全体の進捗率とメンバー別の進み具合を把握しやすいです。
チェックバック期間の公式な指摘置き場として使うと、チャットやメールへの散逸を防げます。
詳しい機能の流れはRevoolトップから確認できます。
