アラートが鳴りました。
さて、誰が何をしますか。
この質問に即答できる現場と、できない現場があります。
正直に告白します。私が若いころにいた現場は、後者でした。
アラートが鳴ると、気づいた人が対応する。手が空いている人が見る。判断に迷ったら、誰かに聞く。その「誰か」が決まっていない。
結果どうなるか。対応が重複したり、逆に誰も動かなかったりします。夜間なら、なおさらです。
今回は、アラートが鳴った後の動き方——フロー設計について書きます。
監視項目をどこまで入れるかは別記事にまとめているので、設計段階から整理したい方はそちらも見てみてください。
フローがないと、何が起きるか
先に、決めていない場合の問題を挙げます。
1. 対応が重複する
複数人が同じアラートに反応して、同じ調査を始める。時間が無駄になるだけでなく、同時に設定変更をして事故が起きることもあります。
2. 誰も動かない
「誰かが見ているだろう」で放置される。特に、全員にメールが飛ぶ設定にしていると起きやすい現象です。
3. 判断が止まる
一次対応者が「これ、どうすればいいんだろう」となったとき、聞く相手が決まっていないと動けません。深夜なら、なおさら躊躇します。
4. 経験が蓄積されない
毎回その場の判断で動くので、ノウハウが個人に留まります。次の人が同じところで詰まる。
フロー設計で決めるべき5つのこと
整理すると、決めるべきは次の5点です。
- 誰が最初に受けるか（一次受付）
- 一次対応でどこまでやるか（対応範囲）
- いつ上げるか（エスカレーション基準）
- 誰に上げるか（エスカレーション先）
- 顧客にいつ連絡するか（報告基準）
順に見ていきます。
①誰が最初に受けるか
「全員に飛ばす」は、実質「誰も見ない」と同じです。
責任の所在を明確にするため、一次受付を決めます。
決め方のパターン
- 当番制：日替わり、週替わりで担当を回す
- システム別担当制：顧客・システムごとに主担当を固定
- 時間帯別：日中は当番、夜間は輪番
私のチームでやっていること
日中はシステム別の主担当が受け、夜間は当番制にしています。
日中は「詳しい人が早く動ける」ことを優先し、夜間は「特定の人に負担が集中しない」ことを優先する。 目的が違うので、体制も変えています。
大事なのは、今誰が担当かが全員に見えること。 カレンダーや共有ボードで、当番が一目でわかる状態にしておきます。
②一次対応でどこまでやるか
これを決めないと、一次対応者が判断に迷います。
明確にすべきこと
- 何をやっていいか（確認、再起動、ログ取得など）
- 何をやってはいけないか（設定変更、データ操作など）
- どこまでやったら上げるか
私のチームの基準
やっていいこと
- 状況確認（監視画面、ログ、プロセス）
- 手順書に記載のある定型対応
- サービスの再起動（手順書にある場合のみ）
- 関係者への一次連絡
やってはいけないこと
- 手順書にない設定変更
- データの削除・更新
- 復旧を急いだ独断の判断
「手順書にあるかどうか」を線引きにする。 これが一番わかりやすいと思っています。
判断に迷う余地を減らすことが、一次対応者を守ることにもなります。
③いつ上げるか（エスカレーション基準）
一番重要なのが、ここです。
時間で切るのが確実
「30分調べてわからなければ上げる」
能力や状況に依存しない基準なので、迷いません。そして、上げることをためらわせない効果があります。
一次対応者は「自分で解決したい」「上げたら迷惑かも」と考えがちです。時間という機械的な基準があれば、その葛藤が減ります。
内容で切る基準も併用
時間に関係なく、即座に上げるケースを決めておきます。
- サービスが完全に停止している
- 顧客業務に影響が出ている
- データに影響がある可能性がある
- 手順書にない事象が起きている
- 複数システムに同時に異常が出ている
この5つに当てはまったら、時間を待たずに上げる。 そう決めておくと、判断が速くなります。
エスカレーションの考え方は別記事にも書いたので、そちらも参考にしてください。
④誰に上げるか
エスカレーション先が曖昧だと、そこで止まります。
決めておくこと
- 一次対応者が上げる相手（リーダー、上位技術者）
- その人が不在のときの代替
- さらに上に上げる場合のルート
- 顧客側の連絡先
連絡手段も決めておく
夜間に「チャットを送ったが気づいてもらえない」では意味がありません。
時間帯によって手段を変えるようにしています。
- 日中：チャット
- 夜間：電話（つながるまでかける）
夜間に電話をかけることを、ためらわせない。 これも明文化しておくべきことです。「起こして申し訳ない」と思って連絡が遅れるほうが、結果的に被害が大きくなります。
⑤顧客にいつ連絡するか
技術的な対応とは別に、報告のタイミングを決めておきます。
私のチームの基準
- 即時連絡：サービス停止、業務影響あり
- 1時間以内：影響は限定的だが、復旧の見通しが立たない
- 翌営業日：自動復旧した、影響なし
**顧客が気にするのは「いつ知らされたか」**です。
復旧してから報告するより、発生時点で「調査中です」と一報を入れるほうが信頼されます。 遅れると「なぜすぐ言わなかったのか」になります。
そして、第一報は完璧でなくていい。 わかっている範囲で伝えて、続報を出す。これが実務的です。
夜間のフローは、別に設計する
日中と夜間では、前提が違います。
夜間特有の事情
- 対応できる人数が少ない
- 判断できる人がすぐつかまらない
- 顧客も対応できない
- 疲労で判断力が落ちている
夜間フローで決めること
- どこまでを翌朝対応にするか
- 夜間に必ず対応すべき条件は何か
- 顧客に連絡する基準（夜間に電話していいのか）
- 連絡がつかない場合の判断
「夜間は一次対応まで、復旧は翌朝」という割り切りも、選択肢です。
すべてに即時対応しようとすると、体制が持ちません。顧客と事前に合意しておけば、堂々と翌朝対応にできます。
夜間対応の実態については別記事に書いたので、体制を考えるときの参考になれば。
フローを作ったあとにやること
作って終わりではありません。
1. 見える場所に置く
フロー図を作っても、どこにあるかわからなければ使われません。監視画面の横、チャットのピン留め、手順書の冒頭——アラート対応中に見られる場所に置きます。
2. 新人に説明する
入ったばかりの人が一番迷います。「困ったら聞いて」ではなく、フローとして渡す。
3. 実際の対応を振り返る
「このケース、フローのどこにも当てはまらなかった」というのが出てきます。そのたびに追記していく。
フローは育てるものだと思っています。最初から完璧を目指さなくていい。
まとめ
アラート対応のフロー設計をまとめます。
決めるべき5つのこと
- 誰が最初に受けるか — 全員に飛ばすのは「誰も見ない」と同じ
- 一次対応でどこまでやるか — 手順書にあるかどうかを線引きに
- いつ上げるか — 時間（30分）＋内容（5条件）で切る
- 誰に上げるか — 代替ルートと連絡手段も決める
- 顧客にいつ連絡するか — 第一報は完璧でなくていい
夜間は別に設計する
- どこまでを翌朝対応にするか
- 顧客と事前に合意しておく
作ったあと
- 見える場所に置く
- 新人に説明する
- 実際の対応を振り返って追記する
アラート対応で一番よくないのは、その場の判断に依存することです。
判断できる人がいればいいですが、いつもいるとは限りません。フローがあれば、経験の浅い人でも最低限の動きができます。
そして、それは一次対応者を守ることにもなります。
「これでよかったのか」と悩まずに済む。それだけで、夜間対応の負担はかなり変わりますよ。
コメント