質問と背景
この質問では、振り返り（レトロスペクティブ）ではなく、インシデント対応中の判断力、文書作成能力、および調整力が試されます。影響がまだ拡大している可能性があり、インシデントマネージャー、テクニカルリード、コミュニケーション担当者が存在し、根本原因は不明であると想定してください。初期通知、定期的な更新頻度、緩和策および復旧のメッセージ、そして訂正プロセスが必要です。
これは、テクニカルリード、SRE、プラットフォームエンジニア、カスタマーエンジニア、およびチーム横断で調整を行う一般的な職種に適しています。社内のワークフローと公開ステータスページを明確に分離してください。未検証の仮説を結論として扱ったり、根本原因を待つ間に影響を受けている人々を情報のない状態に放置したりしないでください。
面接官が評価している点
優れた回答では、まずビジネスへの影響から重大度と対象読者を設定し、次に信頼できる唯一の情報源（Single Source of Truth）、コミュニケーション担当者、および更新頻度を定めます。何が判明していて、何が不明で、何が進行中であるか、そして次の更新がいつ行われるかを明記します。セキュリティ、データ損失、コンプライアンスへのエスカレーションに対応し、さらにチャネル間の一貫性、古いメッセージ、復旧、その後のポストインシデントレビュー（事後検証）にも言及します。
行うべき明確化のための質問
- どのユーザー、リージョン、機能、データが影響を受けていますか？影響範囲は全体ですか、一部ですか、それとも不明ですか？
- セキュリティ、プライバシー、データ損失、または規制上の義務に関係する可能性はありますか？それによって承認フローや通知経路が変わります。
- インシデントマネージャー、テクニカルリード、コミュニケーション担当者は誰ですか？社外向け文面の承認権限は誰にありますか？
- どのような社内・社外チャネルが存在し、顧客はステータスページや個別通知にアクセスできますか？
- どのような更新頻度が求められていますか？新しい証拠がない場合でも「調査中」の更新を送信すべきですか？
30秒の回答フレームワーク
「私はまず、影響度、重大度、セキュリティやデータのリスクを把握し、信頼できる唯一の情報源を中心にインシデントマネージャー、テクニカルリード、コミュニケーション担当者を任命します。判明している影響、現在の調査または緩和状況、次回の更新予定時刻を含めて迅速に問題を認識した旨を発信します。社内向けメッセージには役割、作業チャネル、エスカレーション経路を含め、社外向けメッセージには顧客に関連する事実とアクションのみを記載します。新しい結論が出ていなくても更新頻度を維持します。すべてのチャネルで同一のステータスとインシデントIDを使用し、復旧メッセージには確認内容、影響の概要、ポストインシデントレビューの予定を含めます。」
ステップごとの回答
ステップ 1: 影響とコミュニケーションの境界を評価する
誰が影響を受け、何が発生しており、いつ始まり、拡大しているかどうか、セキュリティやデータのリスクが存在するかを特定します。重大度によって、24時間365日の対応、経営陣へのエスカレーション、法務レビュー、またはプライバシー担当の関与が必要かが決まります。不明な点は不明として明示し、最も楽観的または危機感を煽るような推測で証拠を置き換えないでください。
ステップ 2: 役割と信頼できる唯一の情報源を設定する
インシデントマネージャーが優先順位と意思決定を統括し、テクニカルリードが仮説、緩和策、証拠を統括し、コミュニケーション担当者が社内および社外のメッセージを統括します。全員が単一のインシデントID、ステータスドキュメント、タイムラインを共有し、チャット、ステータスページ、メール、チケットは配信チャネルとして機能します。コミュニケーション担当が技術的事実を変更することはできず、エンジニアも承認ルート外で推測を公開してはなりません。
ステップ 3: 初期通知を送信する
インシデントが妥当に確認されたら、影響を受けている製品、現在の症状、調査状況、ユーザー側の一時的な対処法、次回更新予定を含む短いメッセージを公開します。社内向けメッセージには重大度、オンコールチャネル、担当者、エスカレーション経路を含めることができます。社外向け文面では社内用語や未検証の原因を避ける必要があります。セキュリティやデータへの影響が不明な場合は、評価中である旨を伝え、必要に応じて個別のセキュリティ通知プロセスを利用します。
ステップ 4: 更新頻度とテンプレートを設定する
重大度に合った更新頻度（例：30分ごとなど）を選択し、新たな証拠が得られた場合は予定より早く更新します。各メッセージは、現在のステータス、ユーザーへの影響、進行中のアクション、次回更新予定時刻に絞って記載します。新しい証拠がない場合でも、影響について引き続き調査または緩和中である旨を伝えます。社内と社外で詳細レベルが異なっていても、ステータス、時刻、影響内容は一致していなければなりません。
ステップ 5: チャネル間の不整合の解消と訂正
メッセージ間に齟齬が生じた場合は、古い文面のコピーをやめ、時刻、影響、ステータスについて信頼できる情報源に立ち戻ります。コミュニケーション担当者は、履歴を無断で上書きするのではなく、何が変更されたかを明記した訂正を発行します。すべての場所で同じインシデントIDとステータス遷移を使用し、古いページは解決済みとマークするか、最終サマリーへのリンクを掲載します。
ステップ 6: 緩和、復旧、残存リスクを伝える
緩和は完全な復旧ではありません。緩和措置、影響が残る可能性のあるユーザー、データ整合性チェック、次の検証作業を明確に区別します。復旧後は、確認時刻、影響期間、ユーザーが再試行や再サインインを行う必要があるか、ポストインシデントレビューが後日行われるかを明記します。影響範囲が後から判明した場合は、推測を最終確定として提示するのではなく、個別通知を送信します。
ステップ 7: コミュニケーションを改善ループにつなげる
初報までの時間、更新頻度の遵守、チャネル間の一貫性、サポートの問い合わせ件数、どの情報が混乱を招いたかを振り返ります。テンプレート、ステータスページへのアクセス、オンコール体制の役割、エスカレーション経路について、担当者を決めて検証可能なアクションを作成します。技術的なレビューと並行してコミュニケーションの改善を進めますが、対応中の公開アップデートを事後の根本原因の結論のように書かないでください。
優れた回答の例
「私ならまず、影響を受けるユーザー、リージョン、機能、発生時刻、データリスクを特定し、ビジネスインパクトから重大度を設定します。インシデントマネージャーが優先順位を統括し、テクニカルリードが仮説と証拠を管理し、コミュニケーション担当者がメッセージを管理します。3者全員が1つのインシデントID、ステータスドキュメント、タイムラインを共有します。
問題を確認した後、影響範囲、調査中か緩和中か、ユーザー側で可能な対応、次回の更新予定時刻を含む初期通知を迅速に送信します。社内向け文面には重大度、作業チャネル、エスカレーション先を追加し、社外向け文面には顧客に関連する事実を記載し、根本原因についての推測は避けます。新しい結論が得られない場合でも、約束した頻度で更新を継続します。
ステータスページ、メール、サポートの回答に食い違いが生じた場合は、信頼できる情報源を使用し、コミュニケーション担当者からインシデントIDを付与した訂正を発行させます。緩和、復旧、残存リスクを区別した上で、影響期間、再試行の案内、ポストインシデントレビューの予定を公開します。最後に、更新頻度、到達範囲、一貫性、サポート負荷を振り返り、担当者を割り当てて改善策を実施します。」
よくある間違い
- 根本原因がわかるまで通知を待つ → ユーザーがリスクを判断できない → まず判明している影響、アクション、次回更新予定を伝える。
- チャネルごとに個別に文章を作成する → ステータスや時刻の不整合が発生する → 信頼できる唯一の情報源とインシデントIDを維持する。
- 社内用語を社外向けにそのままコピーする → 顧客が何をすべきかわからない → 事実を維持しながら対象読者に合わせて言葉を調整する。
- 単に「緩和された」とだけ伝える → ユーザーが完全復旧したと思い込む → 緩和、復旧、検証、残存リスクを切り分ける。
- 更新頻度を提示しない → 沈黙は制御不能に見える → 更新頻度を約束し、新しい結論がなくても更新する。
- 誤ったメッセージを無断で編集する → 信頼性と監査可能性が低下する → タイムスタンプ付きの訂正を公開し、履歴を保持する。
フォローアップの質問と回答
フォローアップ 1: 原因が不明で、顧客からデータが安全かどうか尋ねられています。どう答えますか？
完了した確認作業と進行中の評価状況を伝えます（例：「現時点ではデータ漏洩の証拠は確認されておらず、セキュリティチームが引き続き調査を行っています」など）。「現時点で見つかっていない」を「絶対にない」と言い換えてはなりません。基準を満たしている場合は、セキュリティおよびプライバシーの通知ルートを使用します。
フォローアップ 2: 進捗がない場合でも更新すべきですか？
はい。約束を守り、影響に変化があったか、どの仮説を検証中か、どのような確認作業が保留中か、次回更新がいつになるかを伝えます。更新頻度を変更する場合は、新しい頻度とその理由を説明します。
フォローアップ 3: 一部の顧客のみが影響を受けています。公開ステータスページはパニックを引き起こしますか？
影響範囲と、個別チャネルで全員に迅速にリーチできるかに基づいて選択します。影響を受ける対象が不明な場合や通常のチャネルが利用できない場合は、公開ページで個別通知を補完できます。不要な内部詳細を省き、影響を受ける機能とユーザーに見える症状を説明します。
フォローアップ 4: ポストインシデントレビューはいつ公開すべきですか？
まず復旧の確認と判明している影響期間を公開します。証拠と影響分析が十分に出揃った段階でレビューを公開します。顧客が早期のコンテキストを必要としている場合は、不確実性がある旨を明記した暫定サマリーを提供し、後から検証済みのタイムラインとアクションを追加します。