はじめに
この記事は『LITALICO Engineers Advent Calendar 2025』のシリーズ3の11日目の記事です。
株式会社LITALICOでエンジニアをやっている@marie-yです。
リリース直後にアラートが鳴った瞬間、冷や汗が吹き出す感覚。エンジニアなら誰しも経験があるのではないでしょうか。私はあります。
「最近自分がリリースした機能でのバグかもしれない😨」
「早く直さないと😨」
今年に入ってから、自分が主体となって障害対応を行う機会が増えました。最初はとにかく焦って上記のようなことを考えてしまい、うまく対応することができていませんでした。しかし、何度か冷や汗をかく経験を経て、「バグを早く直すこと」よりも、「関係者やユーザーの困りを最小限にすること」や「その場で適切な判断をすること」が重要だと痛感しました。
この記事では、障害対応に苦手意識を持っていた私が、チームでの「振り返り」を通じて少しずつ見えてきた、「焦らずに対応するためのフロー」 と 「失敗から学んだ工夫」 を共有します。
この記事の対象読者
- 障害対応のアラートが鳴ると、冷や汗が止まらない方
- 対応中に「次に何をすべきか」迷ってしまいがちな方
- チームとしての障害対応フローを改善したいと考えている方
前提：障害に対する向き合い方
まず、チームで認識を合わせている大前提があります。もちろん障害は起きないに越したことはありません。しかし、システムである以上、一定の確率で発生することは避けられません。
起きてしまった事実は変えられません。ですが、そこからのリカバリーの品質はいかようにも高められます。
「気合で乗り切る」のではなく、過去の失敗を「振り返り」で洗い出し、それを 「テンプレート（型）」 や 「仕組み」 に落とし込んでおく。そうやって「準備」をしておくことが、最大の精神安定剤になると学びました。
障害対応フロー（改善版）
まずは、振り返りを経て改善しつつある、理想的な動き方を図にしてみました。
ここからは、実際に失敗して、振り返りで修正してきた各段階のリアルな 「Before / After」 を紹介します。
🚀 検知・初動
アラートが鳴ったり、連絡が入ったりした直後の、一番焦る時間帯です。
❌ Before：関係者のメンション先が明確でない
障害の一次報告の際に、関係者をメンション先に含めて連絡ができていませんでした。CS（カスタマーサクセス）や営業担当への連絡が必要なことは分かっているのですが、焦っていると頭から抜けたり、「この場合、誰に連絡すればいいんだっけ？」と迷ったりして、結局連絡が遅れてしまうことがありました。
⭕️ After：連絡先の「仕組み化」
「誰に連絡するか」をその場で考えるのをやめました。Slackに障害報告用のグループメンションを作成し、あらかじめCSや営業の関係者を入れておく運用に変更しました。これにより、いざという時はそのグループへメンションするだけで済みます。
👥 体制・役割分担
人が集まってくれた後の動き方です。
❌ Before：役割が曖昧なまま障害対応が始まる
以前から障害対応テンプレートには、以下のような役割記入欄があったのですが、障害対応中には活用されておらず、障害対応後にまとめる際に記載していました。集まったメンバーで役割が曖昧なまま対応が始まり、全員が同じ問題に対して調査してしまうなど、役割分担が曖昧で効率が悪い状態でした。
- 指揮（全体把握・コマンダー）
- 連絡
- 記録
- メイン調査
⭕️ After：役割分担を「意識的に」行う
振り返りの場で「役割分担が曖昧だった」「誰が指揮をとるかを明確にした方が良い」という議論がありました。そこで、形骸化していたテンプレートの役割記入欄を再認識し、対応開始時に意識的に役割を決めることをチームで再認識しました。
特に重要なのが「指揮（コマンダー）」という役割の定義です。
技術的に詳しい人が調査に没頭するために、あえて別のメンバーが「全体把握に専念する（作業をしない）」役割を担います。「今何がわかっていて、何がわかっていないか」を整理し、タスクを割り振る役です。また、「記録」担当が状況を逐一「対応メモ」に残すことで、情報が属人化するのを防ぎます。
現在進行形で改善中
正直なところ、自分はまだ役割分担がうまくできるわけではありません。「誰がやるか」で迷ったり、「何をすべきか」についてうまく指示が出せなかったりすることもあるので、改善中です。
🛠 復旧作業・判断
原因調査から復旧に向かう段階です。
❌ Before：原因特定に時間をかけてしまう
エンジニアとしては、どうしても「なぜバグったのか？」という根本原因が気になります。「原因がわからないと報告できない」と思い込み、原因調査に時間をかけすぎてしまうことがありました。
⭕️ After：「事象把握」や「影響範囲の特定」、「暫定対応」を優先する
「原因特定」をする前にまずは「事象把握」や「影響範囲の特定」を優先して実施しました。特に「影響範囲の特定」は抜け漏れていたのですが、誰に影響があるのか、どのくらいの数のユーザーに影響しているのかによって、事業への影響度が変わるため、先に特定することが重要です。
根本原因がわからなくても、「機能を一時的にOFFにする」「リリースをRevertする」といった「暫定対応」を実施する判断をして、まずはユーザーへの被害を止めることを優先することもできます。「暫定対応」がそもそもできない場合は「原因特定」をして「恒久対応」を実施します。
📝 Tips：障害票テンプレート
最後に、チームで使っている障害対応テンプレートの工夫を紹介します。
最大の特徴は、「対応メモ」というフリースペースが最上部にあることですが、まずはテンプレート全体の構成を紹介します。
テンプレートの構成要素
エンジニアチームでは、Googleドキュメントで以下の項目を設けて障害票テンプレートを作成しています。GitHubのissueではなく、Googleドキュメントで作っている理由は、CSや営業の方でも閲覧できるようにするためです。
-
タイトル:
yyyymmdd_【インシデントレベル】_タイトルの形式で記載。 - 対応メモ: 障害対応で行ったこと、検討したことを逐次「全て」記入するフリースペース。今誰が何を調べているか、外部から見て状況がわかるように意識する（後述）。
- インシデントレベルの判断根拠: レベル判断の理由、根拠、およびSlackでの報告URLを記載。
- 1. 不具合概要: 発生期間、対象ページ、内容を、対応の場にいなかった人でもわかるように記入。
- 2. 不具合発生原因: Biz職の人でもわかる説明と、必要に応じてエンジニア向けの詳細説明を記入。
- 3. 影響範囲: 発生期間、影響を受けたユーザー数などを記入。
-
4. 対応（暫定/恒久/再発防止）:
- 4.1 暫定対応: Biz職の人でもわかるように記入。
- 4.2 恒久対応: 現時点での見立てや、担当者・対応タイミングを記載。
- 4.3 再発防止策: 発生プロセスを振り返り、再発防止のために行うべきことを記入。
- 5. 不具合発生/発覚/対応経緯: 時系列で記入し、関連する議事録やSlackのリンクも貼る。
なぜ「対応メモ」があるのか？
発生原因や影響範囲をきれいにまとめるのは、事態が収束した後で十分です。
対応中は、とにかくスピードが重要です。チームでは、「対応メモ」に、以下のように時系列で情報をどんどん書いています。
14:00 〇〇さんからSlackで報告あり。ハドルに集合
14:05 ログ確認。XXのエラーが出ていることを確認。
- https://xxxx のページで以下のようなXXのエラーが発生している
（スクショ）14:15 Slack で報告（報告URL: XXXX）
14:15 △△さんにヘルプ要請
...
メリット1：初動のスピードが落ちない
形式を気にする必要がないので、思考を止めずに情報を書き出せます。途中から合流したメンバーも、このメモを上から追えば「何が試されて、何がダメだったか」が一目でわかります。
メリット2：振り返りの資産になる
時系列のログが残っていることで、後日の振り返りで「この時の判断、もう少し早くできたかもね」「ここでこの情報が出ていたなら、次はこう動こう」という、非常に精度の高いフィードバックが可能になります。記憶に頼った振り返りでは得られない学びが、ここにはあります。
おわりに
障害対応に、万能な「正解」はありません。状況によって最適解は変わります。
だからこそ、振り返って対応の質を改善していくことが大事だと思います。
「焦った」「うまく対応できなかった」で終わらせず、チームで話し合って「テンプレート（型）」をアップデートしたり、仕組み化をする。このサイクルを回すことで、過度な不安がなくなり、よりユーザーに向き合った最適な対応ができるようになっていくと思います。
この記事が、アラートが鳴った時のあなたの「焦り」を、少しでも和らげるヒントになれば嬉しいです 
明日は、@komakitaさんの記事です。ぜひ明日の記事も読んでみてください！