誰がやるかではなく、どう解決するかのパス回し — 障害対応のチームワーク
自信のないチームは、そもそもチームとして対応できていないこともあります。チームとは名ばかりの、個人の集まりになってしまっていることが多いのです。障害対応におけるチームとは、組織図上の存在ではありません。障害が起きたときに、信頼関係をもって分担できるかどうかが重要です。
1人で抱え込まないための、エスカレーションという信頼の行為
障害対応で最も危険なパターンの一つが、1人で抱え込むことです。
責任感から「自分で解決しなければいけない」と考えてしまったり、「エスカレーションしたら無能だと思われる」という恐れから抱え込んでしまうことがよくあります。ですが、これが対応時間を引き延ばし被害を拡大させてしまいます。また、このような状況は心身共に負担が大きく、個人の疲弊や、最終的には離職につながりかねません。
障害対応は、スポーツと同じチームプレーだと考えてください。サッカーで言えばパス回しに当たるのがエスカレーションです。ゴールを決めるために最も効果的な人にボールを渡す行為であり、信頼の表現です。そしてエスカレーションされた側が「よく判断したね」と応えるチームこそ、インシデントに強い組織といえるでしょう。
エスカレーションの障壁を下げるために有効なのは、明文化されたエスカレーションポリシーです。Xの条件を満たしたらYにエスカレーションする、というルールが明確であれば、個人の判断を超えた仕組みとして機能します。
インシデント対応の指揮官、インシデントコマンダー
こんな光景に心当たりはないでしょうか？ インシデント対応中、全員がそれぞれのターミナルでログを追いかけ、Slackで断片的な情報を投げ合い、誰も全体像を把握していない。誰が判断を下すのか分からない。
この混乱を解消するのがインシデントコマンダーという役割です。コマンダーの特徴は、手を動かさないことにあります。自らはコードを読まず、ログを追わず、代わりに以下の三つを担います。
一つ目は、状況の把握と意思決定です。今の影響範囲は何か、どのチームが動いているか、次のアクションは何か。こうした問いを投げ続けることで、チーム全体の認知を揃えます。
二つ目は、コミュニケーションのハブです。社内ステークホルダーへの状況報告、顧客対応チームへの情報提供、経営層への判断仰ぎ。これらを一手に引き受けることで、対応メンバーは技術作業に集中できます。
三つ目は、タイムキーピングです。対応が長引く場合の交代要員の手配、エスカレーションの判断、一旦ロールバックするという撤退の決断も、コマンダーの権限に含まれます。
手を動かさない人間なんて非効率では、と思うかもしれません。しかし全員が手を動かして全体を見渡す人がいない状態こそ、最も非効率な障害対応の形です。ここでもサッカーに例えてみますが、ボールを持たないプレーヤーが無駄かというと、そんなことはないですよね。ボールを持たなくとも、全てのプレーヤーのポジションに意味があります。
インシデントコマンダー不在のインシデント対応は、転がるボールにみんなが群がる小学生のサッカーのようなものです。サッカーでいえばゴールを決める、インシデントであれば収束させるという目的を達成するには、司令塔を中心に役割分担を行い、適切にパス回ししていくことが大事です。
オンコールシフトの持続可能な設計
オンコールという言葉にストレスを感じるエンジニアは多いです。シフトに入っても必ず呼び出されるとは限りませんが、いつ呼び出されるかわからない緊張感は、たとえ手を動かしていなくても休息できません。
持続可能なオンコール設計のコツは3つあります。
第一に、ローテーションの公平性です。特定の人に負荷が集中しない仕組みを作りましょう。日ごとに変わったり、週次、隔週といったローテーションが一般的ですが、チームの規模に応じて調整してください。少なくとも連続オンコールは絶対に避けるべきです。
第二に、補償の明確化です。オンコール手当、代休の取得ルール、深夜対応後の翌日フレックスなど、オンコールに対する補償を制度として設けます。やって当たり前という空気は、確実にチームを蝕みます。
第三に、ランブック（手順書）の整備です。オンコール担当者が夜中に一人で判断に迷わないよう、主要なアラートに対する対応手順を文書化しておきましょう。このアラートが鳴ったらまずここを確認し、この条件ならエスカレーションといったガイドがあるだけで、心理的負担は劇的に下がります。
オンコールの持続可能性は、エンジニアの定着率に直結します。ここを軽視するチームは、いずれ人材流出という最大のインシデントに直面することになるでしょう。
