プロンプトと背景
あるB2B SaaSにおいて、サービスがダウンしているのではないかという顧客からの問い合わせが頻発しています。サポートチームの報告によると、チケットの約30%が可用性の確認です。エンジニアリングチームは公開ステータスページの導入を提案していますが、営業チームはインシデントの公開が契約更新に悪影響を与えるのではないかと懸念しています。立ち上げるべきかどうかを判断し、設計、メトリクス、安全対策を説明してください。
面接官が見ているポイント
この質問は、「ページを作るべきか？」という問いを、顧客の信頼、インシデントコミュニケーション、運用体制に関するプロダクト判断へと昇華できるかを評価しています。優れた回答は、単に機能を列挙するのではなく、対象ユーザーをセグメント化し、開示範囲の境界を設定し、信頼できる唯一の情報源（source of truth）と責任者を明確にし、測定可能なロールアウト基準（ゲート）を定義します。
最初に明確にすべき質問
確認すべき点は4つあります。顧客の大半が一般ユーザーなのか、規制対象のエンタープライズなのか、あるいは少数の大口顧客なのか。契約に可用性や通知に関するコミットメントが含まれているか。モニタリング、オンコール、インシデント指揮体制の成熟度はどの程度か。そして、顧客が必要としているのはセルフサービスの状況確認なのか、更新通知の購読なのか、それとも根本原因の説明なのかです。
また、社内向けや特定顧客向けのステータスページがすでに存在するかどうかも確認します。公開、非公開、オーディエンス別のページはそれぞれ異なる対象に対応します。1つの公開モデルだけで対応しようとすると、インシデント情報を過度にさらしすぎるか、顧客に必要な情報が不足するかのどちらかになりかねません。
30秒での回答構成
まず、顧客が信頼できる外部シグナルを必要としているかを検証し、そのうえで公開、非公開、またはセグメント化された公開範囲を選択します。チケットの30%という割合が事実であり、チームが正確な更新を一貫して発信できる体制にあるなら、まずは顧客向けの3〜4個のコンポーネントから始めます。ページにはアクションにつながるステータスと次回更新予定時刻を表示し、インシデントコマンダーが掲載を担当し、セキュリティに関わる機密情報は非公開のままにします。初回更新までの時間、定時更新率、重複チケット数、信頼度フィードバックを測定した後にのみ公開範囲を拡大します。情報源や責任体制が不安定な場合は、一般公開する前にインシデント運用の改善を優先します。
ステップごとの詳細分析
ステップ1：ユーザーの課題と対象読者を定義する
チケットを「影響の確認」「次の確認タイミングの把握」「回避策の確認」に分類します。管理者はコンポーネント単位のステータスを必要とする場合がありますが、一般ユーザーはログインや主要業務が機能しているかどうかを知るだけで十分です。営業、サポート、パートナーでは、必要な通知登録や履歴ビューが異なる可能性があります。公開範囲を選択する前に、契約形態、リージョン、プロダクトモジュール、インシデントの影響範囲によってセグメント化します。
ステップ2：公開、非公開、セグメント別公開を選択する
公開ページは、大多数の顧客が1つの共通した情報源を必要としている場合に適しています。重複した問い合わせを減らし、透明性の高い期待値設定ができる一方で、障害発生状況、メンテナンス時間枠、内部コンポーネント名が外部にさらされることにもなります。非公開ページは従業員や社内運用に有用です。オーディエンス別ページは、エンタープライズ顧客に対してより詳細なコンポーネントや通知を提供できますが、権限管理、保守、整合性維持のコストが増加します。公開をデフォルトとするのではなく、判断基準を説明することが重要です。
ステップ3：コンポーネント、ステータス、情報の境界を設計する
Login、API、File export、Consoleなど、顧客にとって分かりやすいコンポーネントを公開し、内部サービス名は掲載しません。operational、degraded performance、partial outage、major outage、maintenanceといったステータスを定義し、移行ルールを明確にします。インシデントは、investigating、identified、monitoring、resolvedの順で進行します。根本原因、脆弱性の詳細、特定顧客の限定情報は、セキュリティや顧客個別対応のワークフロー内に留めます。ステータスページ自体がシステムを監視するわけではないため、検証済みのモニタリングまたはインシデント指揮からの入力が必要です。
ステップ4：掲載フローをインシデント対応と連携させる
影響が検知された後、インシデントコマンダーが影響を受けるコンポーネント、対象ユーザー、初報メッセージを確認し、investigatingを公開します。原因が特定されたらidentifiedへ更新し、復旧作業中はmonitoringを使用し、サービスが復旧した後にのみresolvedとマークします。15分ごとなどの更新頻度を設定し、サポート、営業、ステータスページがすべて同一の情報源を参照するようにします。Google SREでは、チャネル、対象リスト、役割を事前に準備しておくことを推奨しています。ページを設けたからといって、それらの責任体制を代替できるわけではありません。
ステップ5：信頼、運用、セキュリティのメトリクスを定義する
初回更新までの時間、定時更新率、訂正率、通知到達率、ステータスページのセルフサービス訪問数、重複可用性チケット数、信頼度フィードバックを設定します。重複チケットの10%削減を目標とする場合は、誤検知（false positives）や見逃し（false negatives）も注視し、チケット減少の裏で顧客体験が悪化していないかを確認します。セキュリティメトリクスには、不適切な情報開示、内部名称の漏洩、権限エラーなどが含まれます。リスクが高い場合は自動公開を停止し、人間の承認を必須とします。
ステップ6：Go/No-Go基準を設けて段階的に展開する
まず社内リハーサルを実施し、次に3〜4個のコンポーネントのページと通知登録を少数の顧客コホートに限定公開します。Goの条件は、明確なオンコールおよび掲載責任者、追跡可能なステータス入力、繰り返しの訓練における安定した更新、サポートと営業の間での共通言語の確立です。初報が継続して目標時間を超過する場合、ステータス入力にズレがある場合、またはセキュリティレビューを通過できない場合はNo-Goとします。一般公開後は、インシデント履歴とポストモーテム（事後検証）へのリンクを保持しつつ、顧客にとって有益でなくなった社内詳細は削除します。
質の高い回答例
私は「立ち上げるか否か」から始めるのではなく、まず顧客が信頼できる外部シグナルを欠いているかどうかを検証します。チケットの30%がサービス状況の問い合わせである場合、セルフサービスでの可視化は有効ですが、不正確な情報を発信すれば被害を拡大させることになります。
段階的な計画を採用します。まず社内リハーサルを行い、その後Login、API、File export、Consoleを少数の顧客コホートに公開します。ステータス、影響、次回更新予定時刻、通知購読オプションを表示し、内部サービス名、脆弱性の詳細、未確認の原因は記載しません。インシデントコマンダーがinvestigating、identified、monitoring、resolvedの順で15分ごとに更新を発信し、サポートと営業も同じ情報源を参照します。
成功の指標としては、初報レイテンシ、定時更新率、重複可用性チケット数、通知到達率、訂正率、信頼度フィードバックをトラッキングします。テスト目標である重複チケット10%削減が達成され、正確性が基準を満たしていれば全顧客へ拡大します。データソース、責任者、セキュリティ境界に懸念がある場合は、まずインシデント対応体制を改善します。このページは独立したフロントエンドプロジェクトではなく、信頼の構築とコミュニケーション成果のために機能すべきものです。
よくあるミスと改善点
- 「透明性は常に信頼を築く」と決めつける：ユーザーセグメント、開示に伴うコスト、測定可能な判定基準を追加する。
- ステータスページをモニタリングツールとして扱う：モニタリングやインシデント指揮からの入力が必要であることを明記する。
- すべてのインシデントを自動公開する：深刻度、人間の承認、セキュリティ上の例外を定義する。
- 「正常/停止」のみを表示する：影響度、次回更新予定時刻、顧客が取れるアクションを追加する。
- 直ちにチケットが減少すると約束する：コホートで検証し、ページ訪問と根本的な問題解決を区別する。
想定される追加質問と回答
すべてのインシデントを公開すべきですか？
いいえ。顧客への影響に関する検証済みの有用な事実のみを公開します。セキュリティ上機密性の高い内容、従業員限定の情報、特定顧客に関わる詳細は適切な非公開チャネルに留めます。公開範囲は影響度と開示リスクに応じて決定します。
ステータスデータが不正確な場合はどうしますか？
自動公開を停止し、インシデント責任者をアサインして次回更新時刻を添えた訂正を公開します。誤検知率および見逃し率をトラッキングし、正確性が確保されていることを全体展開の必須条件（ゲート）とします。
セキュリティ詳細の漏洩をどう防ぎますか？
顧客向けの分かりやすいコンポーネント名と、承認済みのメッセージテンプレートを使用します。可用性に関するコミュニケーションとセキュリティインシデントのプロセスを分離し、詳細を開示する前にセキュリティレビューを実施します。
サポート負荷の軽減をどのように証明しますか？
立ち上げ前後で類似のインシデントコホートを比較します。重複可用性チケット数、初報回答時間、セルフサービス訪問数、通知購読のエンゲージメント、信頼度フィードバックなどを測定します。10%の削減は検証目標値であり、確約ではありません。