準備するもの
チェックリストを運用する前提として、案件ごとにスラッグ命名ルールを定義した社内wiki或いはNotion页を用意する。ルールが文書化されていないとチェックリストを埋めても担当者ごとに解釈が異なる。最低でも「英小文字・ハイフン区切り・30文字以内・リビジョン番号を末尾に付ける」という4点を明記しておこう。
チェックリストはGoogleスプレッドシートや社内チャットのブックマークに置き、案件開始時に担当者が複製して使う形が運用しやすい。Notionのデータベーステンプレートを使えば、案件名・スラッグ・有効期限・送付日を列として管理し、一覧で進捗を把握できる。
送付前に必要なアクセス情報（URL・パスワード・有効期限）をひとつのドキュメントにまとめておくと、チェック時に情報が分散して漏れるリスクが減る。特にパスワードを別メールで送る運用のときは「パスワード送付済み」を独立したチェック項目として設ける。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
実際の手順
チェックリストの使い方は「共有前チェック→送付→送付後確認」の3段階に分かれる。共有前チェックではスラッグの文字種・長さ・重複がないかを確認し、ブラウザ2種類（ChromeとSafari等）でURLを開いて表示崩れがないかを目視する。この段階でHTMLの外部送信コードも調べる。
送付段階では、チェックリストの「URL・パスワード・期限の3点が揃っているか」という項目を埋めてから送信ボタンを押す。送付後確認では、クライアントから「開けない」という返信が来る前に送信者自身がURLをスマホで開いて正常表示を確認する。所要5分以内の作業だが、これで「URLが誤コピーされていた」という凡ミスを事前に防げる。
失敗しやすい点
チェックリストを作っても「時間がないから今回は省略」と運用されなくなるケースが多い。対策として、チェックリストの完了がSlackの送付メッセージと紐付く仕組みにする。例えばSlackメッセージテンプレートに「チェックリスト完了: ✅」の行を必須項目として含めるだけでも、省略に対する心理的ハードルが上がる。
もう一つの失敗は「スラッグの重複確認」を省くことだ。同一クライアントの別フェーズ案件で偶然同じスラッグを付けてしまうと、後から発行したURLが前のコンテンツを上書きする場合がある。チェックリストに「発行済みスラッグ一覧との重複チェック」を必須項目として明記し、管理台帳とセットで運用しよう。
テンプレ文面
チェック完了後に使う送付メールのテンプレは、チェックリストの結果を受信者に伝える形にすると信頼感が増す。「デザインレビュー用URLを共有します。送付前に表示確認・情報漏洩チェック・期限設定の3点を完了しています。URL：https://…/yamada-corp-lp-r2 有効期限：2026年7月15日。」
修正差し替え時のテンプレは旧URLの無効化を明示するとクライアントの混乱を防げる。「修正版（r3）を公開しました。前回のURL（r2）は本日をもって無効化しております。最新URL：https://…/yamada-corp-lp-r3 ご確認よろしくお願いいたします。」のように旧URLを使わせない意図をはっきり示す。
よくある質問
チェックリストをPDF化して紙で管理するのと、デジタルツールで管理するのでは、どちらが案件管理に向いていますか？
複数案件を並行して進める場合はデジタルツール（NotionやGoogleスプレッドシート）が圧倒的に管理しやすい。過去案件のスラッグ一覧を検索でき、重複チェックや有効期限の一括管理が可能。紙は単発の小規模案件に限定するのが現実的だ。
チェックリストの「外部送信コードが残っていないか確認する」項目は、具体的にどのツールで確認すればよいですか？
Chromeの開発者ツール（F12）のNetworkタブを開き、ページをリロードして不審なドメインへのリクエストがないか確認する。analytics.google.comやfacebook.net等への通信がある場合はHTMLのscriptタグを検索して削除する。
チェックリストの運用を社内に定着させるコツはありますか？
最初の1か月は毎週15分のミーティングでチェックリストを声に出して確認する。「省略した結果クライアントから指摘された」事例を社内で共有すると、面倒でも続ける動機づけになる。チェック完了をSlackスタンプで可視化する仕組みも定着を助ける。