レビュー相手の決め方
ステータスページのレビュアーは最低でも「インフラエンジニア（技術的正確性）」「カスタマーサクセス（顧客への伝わり方）」「広報（ブランドトーンの一貫性）」の3役割をカバーすることを推奨する。特にカスタマーサクセスは「インシデント中に顧客が何を知りたがるか」を一番よく知っているため、デザインの前に文言のレビューを先行してもらうと手戻りが少なくなる。
エンタープライズ顧客の担当者に「このステータスページは使いやすいですか」と聞いてフィードバックをもらうことも有効だ。実際のインシデント時に閲覧する人の視点でレビューしてもらえるため、社内だけでは気づかない改善点が出てきやすい。ただしベータ版の特定顧客に限定し、広くオープンにしない。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
認証方式の選び方
社内のエンジニアとカスタマーサクセスが同一ドメインに属しているなら、会社ドメイン認証でURL1本を全員に送るだけでよい。追加の招待作業が不要なため、「Aさん、Bさん、Cさんに個別で送って」という手間が省ける。レビュー人数が多い場合ほどこの方法が効率的だ。
特定顧客のみを対象とする場合はメール認証が適切だ。顧客担当者のアドレスを許可リストに入れ、レビュー完了後は削除する。パスワード認証と組み合わせるとさらにセキュリティが上がるが、操作手順が増えて顧客に負担をかける可能性もあるため、相手の技術リテラシーに応じて判断する。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
フィードバック回収
ステータスページのレビューで最も重要なフィードバックは「インシデント発生時の第一印象」だ。「ページを開いた瞬間に状況が分かるか」「重大度の視覚表現が直感的か」「次のアクション（問い合わせ先・代替手段）がすぐ見つかるか」の3点を確認観点として明示する。
フィードバックはGoogleフォームで収集するよりも、ページのURLと一緒にNotionのコメント用ページのリンクを送る方が記録として整理しやすい。フォームの場合は自由記述が短くなりがちだが、Notionではスクリーンショットを貼ってコメントできるため、「この部分が分かりにくい」という指摘が視覚的に伝わる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
公開終了の処理
ステータスページのプレビューURLは本番デプロイと同時にアクセスを停止する。プレビューと本番が並存していると、古いデザインが本番として誤解されるリスクがある。停止と同時に「本番のURLはこちらです」というメッセージをレビュアー全員に送り、確認先をはっきり切り替える。
プレビュー期間中に集まったフィードバックは、反映した点・見送った点それぞれに理由を付けてドキュメント化する。次回のリニューアル時に「前回こういう意見があったが、なぜ反映しなかったか」を確認できると、同じ議論を繰り返さずに済む。
よくある質問
ステータスページのプレビューをモバイルでもレビューしてもらうには何を準備すればよいですか？
レビュアーへの依頼メールに「スマートフォンでもアクセスしてください」と明記し、モバイルで確認してほしい具体的な観点（文字の視認性・ボタンのタップしやすさ）を添えると、PCだけで確認されるのを防げます。
ステータスページに埋め込んだ外部サービス（例：稼働率グラフAPI）がプレビュー環境でも本番データを参照してしまう場合の対処法は？
プレビュー用のHTMLではAPIエンドポイントをスタブ（固定のモックデータ）に向け替えることを推奨します。本番データが誤って外部公開されるリスクと、レビュアーが実際の障害情報を目にするリスクの両方を回避できます。
ステータスページのレビューで「インシデント時の文言が冷たい」と指摘された場合、どう改善しますか？
「現在調査中です」を「お客様にご不便をおかけしており大変申し訳ございません。現在の状況と次の更新時刻：〇〇時」のように、謝意・現状・次の行動の3要素を含める形に書き換えると、顧客の安心感が高まります。