この記事で分かること
- 確認相手が判断できるよう、依頼前にそろえる情報
- 希望回答日と課題の完了期限を分ける方法
- 確認後の差し戻しと、当初範囲外の追加依頼の扱い
Web制作では、デザイン、原稿、実装内容などをクライアントやチーム内の担当者へ確認する場面が多くあります。しかし、「ご確認ください」とだけ送ると、何を判断すればよいのか分からず、質問や差し戻しが増えます。
確認依頼で大切なのは、資料を送るだけで終わらせないことです。確認対象・判断してほしい項目・必要な資料・希望回答日をそろえ、相手が判断できる状態にしてから依頼することが必要です。
確認依頼を出しただけでは判断してもらえない
確認相手は、制作担当者と同じ経緯や前提を把握しているとは限りません。リンクや画像だけを送っても、どこが変わったのか、何を回答すればよいのかを判断できない場合があります。
確認の往復が増えやすいのは、次のような依頼です。
- 確認してほしいページや箇所が分からない
- 変更前後の違いが説明されていない
- どの選択肢を決めてほしいのか分からない
- 判断に必要な原稿、画像、仕様がそろっていない
- 今回の対象外まで確認が必要に見える
- 希望回答日が伝わっていない
- 誰が最終的に決定するのか決まっていない
- 回答後に何を進めるのか分からない
回答が遅いと考える前に、相手が一度で判断できる情報がそろっているかを確認します。
何を確認してほしいか明確にする
最初に、確認対象と判断してほしい内容を分けて書きます。
たとえば、次のように整理します。
- 確認対象：トップページのファーストビュー
- 判断項目：見出し文、使用写真、ボタンの文言
- 確認方法：A案とB案から一つ選ぶ
- 回答後の作業：選ばれた案を下層ページへ展開する
「デザインをご確認ください」ではなく、「トップページの見出し文と写真について、A案・B案のどちらで進めるかご回答ください」のように、回答の形が分かる依頼にします。
自由な感想を求める場合も、「ブランドの印象に合っているか」「掲載内容に誤りがないか」など、見る観点を伝えます。
変更前後と判断理由を残す
修正内容を確認してもらう場合は、変更後だけでなく、何をどの理由で変えたのかを伝えます。
- 変更前：お問い合わせボタンをページ下部だけに表示
- 変更後：ヘッダーとページ下部に表示
- 変更理由：長いページの途中でも問い合わせへ進めるようにするため
Tasselが変更前後の差分を自動生成する前提にはしません。必要に応じて、変更前後のスクリーンショット、確認用URL、デザインデータ、対象箇所が分かる資料を用意します。
文章だけでは場所が分かりにくい場合は、スクリーンショットに印を付ける、ページ内の見出し名を伝えるなど、相手が対象箇所を探さずに済む形にします。
確認対象と対象外を分ける
確認用のページに未完成の箇所があると、今回の対象外まで指摘され、判断が広がることがあります。
依頼時には、次のように対象を分けます。
- 今回確認してほしいこと：トップページの見出し、写真、ボタン文言
- 今回は確認対象外：下層ページの文章、スマートフォン表示、フォームの動作
- 対象外の確認予定：次回の実装確認時に依頼する
対象外とする理由や、いつ確認する予定かも伝えます。「まだ見ないでください」だけではなく、確認の順番を共有すると、相手も判断範囲を理解しやすくなります。
ただし、重大な表示崩れや内容の誤りを見つけた場合まで報告を制限する必要はありません。今回の判断対象を絞りつつ、気づいた問題を伝えられる余地は残します。
判断に必要な資料をそろえる
確認依頼を送る前に、相手が判断するための資料がそろっているかを確認します。
- 確認用URL
- 変更前後のスクリーンショット
- デザインデータや原稿
- 仕様や制約が分かる資料
- 選択肢ごとの違い
- 関係する過去の決定事項
資料が複数の場所にある場合は、どの資料のどの箇所を見るかを課題の詳細またはコメントへ残します。リンク切れや閲覧権限がない状態で送らないよう、依頼前に確認します。
課題詳細へ、確認対象・判断項目・資料・回答後の作業をまとめます。
クライアント名、認証情報、未公開情報を添付・共有する場合は、共有相手と範囲を確認します。確認に不要な機密情報は含めません。
希望回答日と課題の完了期限を分ける
確認依頼では、相手に回答してほしい日と、制作側が課題を完了する日を分けます。
- 希望回答日：確認相手から回答を受け取りたい日
- 完了期限：回答を反映し、必要な作業と確認を終える日
たとえば、7月25日に課題を完了する必要があり、回答後に2日間の修正が必要なら、希望回答日を7月23日に設定します。
希望回答日は、課題の詳細またはコメントへ残します。Tasselの期限欄には、その課題自体を完了する期限を設定します。希望回答日を期限欄へ入れると、回答日と制作完了日が混ざり、期限超過やガントチャートの意味が分かりにくくなります。
完了期限をまだ決められない場合は、希望回答日を代わりに期限欄へ入れません。期限を決められない理由と次回確認日をコメントへ残し、期限未設定の課題を見直します。
回答する人と制作側の担当者を決める
内容について回答する人と、確認依頼を送り回答を管理する人は同じとは限りません。
- 回答する人：内容を確認し、意見や選択結果を返す人
- 制作側の担当者：確認依頼を送り、回答を確認し、必要なら再確認する人
クライアント側で複数人が関わる場合は、回答する人とは別に、誰が最終的に決定するのかを確認します。複数人から別々の回答が届くと、どの決定で進めるか分からなくなるためです。
クライアントがTasselへ参加している前提にはしません。実際の確認依頼はメールやチャットなど、合意している連絡手段で行います。Tasselには、依頼内容、連絡した日、希望回答日、待っている相手、回答後の作業を残します。
コメントへ、確認依頼を送った日・相手・内容・希望回答日を残します。
Tasselが確認依頼を自動送信したり、希望回答日に自動リマインドしたりする前提にはしません。制作側の担当者がコメントの記録を見て、必要なタイミングで再確認します。
確認依頼後は実際の進捗に合わせて状態を更新する
確認依頼を送ったという理由だけで、必ず「処理済」にするわけではありません。
- 担当者の作業が終わり、確認だけが残っている：処理済
- 担当者側の作業が残っている：処理中
- 回答を受けて修正や追加作業を再開する：処理中
- 必要な作業と確認がすべて終わった：完了
「確認待ち」という架空の状態があるようには案内しません。誰の何を待っているか、希望回答日、回答後の作業をコメントへ残します。
外部の返答を待つ間の見直し方法は、返答待ちのタスクを忘れないための確認ルールで詳しく紹介しています。
差し戻しは元の課題で経緯を残す
回答を受けて修正が必要になった場合は、まず当初の完了条件内の差し戻しかを確認します。
当初範囲内の修正であれば、同じ課題のコメントへ次の内容を残します。
- 回答を受け取った日
- 指摘された内容
- 修正する範囲
- 再確認が必要か
- 変更後の完了予定
状態を「処理中」に戻し、修正後に再度確認を依頼します。以前のコメントを消さず、依頼、回答、修正、再確認の経緯を時系列で残します。
一方、確認時に当初の完了条件を越える追加依頼が出た場合は、元の課題へ混ぜません。追加内容を別課題として登録し、元の予定や見積もりへの影響を確認します。詳しい整理方法は、クライアントから追加依頼が来たときのタスク整理方法で紹介しています。
小規模チームで続けやすい確認依頼の型
確認依頼前には、次の内容をそろえます。
- 確認してほしい対象
- 今回の変更内容と判断理由
- 判断してほしい項目と回答の形
- 今回は確認対象外の範囲
- 参照するURL・資料・スクリーンショット
- 回答する人と最終的に決定する人
- 希望回答日
- 回答後に進める作業
確認依頼を送ったら、コメントへ依頼日、連絡手段、相手、希望回答日を残します。回答後は結果と次の行動を記録し、実際の進捗に合わせて状態を更新します。
この項目を専用の入力フォームや自動承認フローとして案内するものではありません。課題の詳細やコメントに、相手が判断するために必要な内容を簡潔に残す運用です。
まとめ
Web制作の確認依頼では、確認対象、変更内容、判断してほしい項目、対象外の範囲、必要な資料、希望回答日をそろえてから依頼します。変更前後の比較は自動生成される前提にせず、URL、スクリーンショット、資料を用意します。
実際の連絡はメールやチャットで行い、Tasselには依頼日、相手、内容、希望回答日、回答後の作業を残します。希望回答日は期限欄へ入れず、課題自体の完了期限と分けます。
確認依頼後の状態は実際の進捗に合わせます。当初範囲内の差し戻しは同じ課題で経緯を残し、当初範囲外の追加依頼は別課題として整理すると、確認の往復を減らしながら、元の完了条件と予定を崩しにくくなります。