こんにちは Topotal エンジニアの高谷(@nerdyboy_cool)です。
今回も「Incident Management For Operations」を題材に IMS(インシデントマネージメントサービス) について書いていきたいと思います。
過去の記事についてはこちらからご覧いただけるので、ぜひご一読ください！
前回まで
前回の記事では、Incident Commander（以下: IC）というロールとその難しさについて紹介しました。IC がとるべきコミュニケーションパスや状況に応じたコミュニケーションの変化が求められることから、このロールの難しさをお伝えしました。
今回は、IC がインシデント対応中に一番コミュニケーションをとる SME（Subject Matter Expert: 個々の領域の専門家）とどのように対話・議論していけば良いのかを「CAN レポート」のようなフレームワークについて触れながら、その「難しさ」とどう対峙するのかについて考えていきたいと思います。
リーダーシップの原則
まず、各メンバーとコミュニケーションを取る前に、IC として意識しておくべきポイントをまとめてみます。
戦略（Strategy）と戦術（Tactics）の違いを理解すること
まず初めに、IC は戦略と戦術の違いを理解しておく必要があります。図にすると下記のようになります。
戦略（Strategy）は、全体的な目標と方向性を定める長期的な計画です。一方、戦術（Tactics）は、その戦略を実行するための具体的なアクションを指します。
IC は戦略に集中し、戦術は SME の仕事です。 IC が問題解決の細かい部分に入り込んでしまうと、本来の役割である全体の指揮に集中できなくなります。
なぜこれを改めて強調するかというと、IC が陥りがちな「罠」として以下が挙げられるからです。
- マイクロマネジメント：細かい作業内容にまで口を出してしまう
- スケジュール・クリープ：本来注力すべき問題よりも対応範囲を広げすぎてしまう
MTTR を最短にしようとするあまり、ロールの境界線を超えて細かい作業に深入りしてしまったり、本来注力すべき問題よりも対応範囲を広げすぎてしまったりして、かえって状況を混乱させてしまうことがよくあります。
僕自身、過去に IC として振る舞うべきインシデントにおいて Backend Engineer として細かい作業の戦術を同時並行で考えてしまい、戦略なき戦術ばかりの対応をしてしまったことがあります。そういったケースの場合は大概、解決までの方向性が一貫していることはなく、バラバラな修正方針を数多く試して精神的に疲弊してしまうことが多かったように感じます。
全体の指揮に集中するため、細かい技術的な詳細に入り込まないようにする、もしリソース的な問題で兼務せざるを得ない場合は、自分がどのロールで対応を行っているのかを客観的な目でチェックし続けることが非常に重要だと思います。
評価と評価までにかかる時間を問い続けること
また本著では、IC は「今何が起きているかを把握しつつ、次に何が起こりそうかも常に気にかける」ことを非常に重要視しています。
「戦術 or 戦略」でも触れたように、場当たり的な対応にならないよう、先を見越したアクションプランに関心を持ち続けることが求められます。 インシデントの重大度が高い場合は、解決にもそれ相応の複雑さが伴います。そのため、最初のプランだけに固執せず、複数のプランを比較検討しながらベストな選択をすることが必要です。
未来に関心を持ち続けているかを自答する方法として、本著では以下のチェックが取り上げられています。
- 常に代替案を考える
- このプランがうまくいかなかった場合はどうするか？
- MTTR に対する関心を維持し続ける
- プラン実行後、結果を判断するまでどれくらい待つべきか？
これらの問いは、IC が冷静に状況を俯瞰し、次の一手を常に準備しておくために不可欠です。
カオスを統制するためのコミュニケーション
次に、実際のインシデントではどのようなコミュニケーションパターンが存在するのかを整理してみます。
IC と SME のコミュニケーションのパターンとしては、以下のようなパターンが紹介されています。
- IC to SME: 個別のメンバーへの具体的な指示
- IC to SME Group: 複数のメンバーやステークホルダーへの情報共有
- SME to SME: 複数メンバーによる多角的な議論を求めるオープンフォーラム
それぞれのコミュニケーションパターンについて、詳しく見ていきましょう。
曖昧さを排除した指示（IC to SME）
メンバーに指示を出すときは、抽象的な言い方ではなく具体的に伝えることが重要です。
- 誰にタスクを依頼するか明確にする（名前や役割を指定する）
- 何のためにやるのか、目的をはっきり伝える
- 依頼内容を相手と確認することで、認識のズレを防ぐ
- いつまでに完了してほしいか、具体的な時間を伝える
このプロセスにより、タスクの理解にズレが生じることを防ぎ、誰が何に責任を持つかを明確にします。このようなコミュニケーションはインシデント対応以外でも非常に重要ですが、インシデント対応中は心拍数が上がるイベントです。どうしても早く解決に辿り着こうとするあまり、不正確な意図で情報が伝わってしまい、より問題を大きくしてしまうことが多々あります。(僕もたまにやってしまいます。)
インシデント対応中は下記の金言を常に復唱するといいかもしれません。(僕もそうします...)
(IC は) 迅速な決定ではなく、最短時間で最善の決定を下す
効率化された情報共有 C: 状況 A: 行動 N: ニーズ（IC to Group）
新しいフェーズに移るときや、関係者が増えたときに、IC から情報を伝達します。これは以下のような場合に必要となります。
- 新しいメンバーが対応に加わったとき
- ステークホルダーが増えたとき
- 経営メンバーへの報告
- ベンダーとの連携
- 顧客への説明
IC は定期的に下記の CAN レポートを実施し、関係者全員に状況を共有します。
- C: 状況（Condition） - 今何が起きているのか
- A: 行動（Action） - 今何をしていて、これから何をするのか
- N: ニーズ（Needs） - 何が必要なのか
CAN レポートは、情報の透明性を保ち、全員が同じ認識を持つために不可欠です。 また、「悪いニュースは時間が経っても良くならない」という事実を受け入れ、状況を取り繕おうとせず、正直に共有することが重要ですね。
Waroom における CAN レポートの実現
何度も紹介してしまい大変恐縮ですが、CAN レポートを Waroom で実現する方法として State Document が存在します。
このレポート機能にはテンプレートを設定することができるので、設定した項目に沿った形で AI が自動でレポートを作成してくれます。 「IC to SME Group」のような頻繁に起こるコミュニケーションについても、各メンバーがこのレポートを見るだけで情報が共有できる機能となっています。
行き詰まったときのオープンフォーラム（SME to SME）
原因が不明確で、色々な視点から検討が必要な場合に使用します。この形式では、IC はファシリテーターおよび聞き役として参加します。
オープンフォーラムは議論が脱線しやすいため、適切にファシリテーションする必要があります。IC は以下のようなルールを設定し、環境をコントロールします。
- 時間制限を設ける
- 事実と推測を分けること - 生のデータはそのままでは使えず、文脈を理解して初めて役立つ情報になります。IC は、根拠のない意見や推測は控えるよう促し、事実ベースで話すよう導きます
- 傾聴 - IC は、アクティブリスナーであること
問題や解決策について知っていることは、チーム全体の利益のために自由に共有することが非常に重要です。 誰かの意見を妨げたり、感情的に意見を押し通すようなことがあってはいけません。そういった行動はインシデント対応には不要です！！！！
最後に
今回は、以下のポイントについて説明しました。
- IC の心構え
- 戦略と戦術の違いを理解し、IC は戦略に集中すること
- 相手に合わせたコミュニケーション方法
- CAN レポートによる定期的な情報共有
- オープンフォーラムでのファシリテーションのポイント
次回は、STAR によるインシデントの状況把握のフレームワークについて触れる予定です。
最後に少し宣伝をさせてください..
Topotal では「インシデント対応を楽にする」Waroom バックエンドエンジニア（Ruby on Rails）を募集しています。
Topotal はメンバーのほとんどがエンジニアをバックグラウンドとするメンバーです。(ちなみに営業メンバーも GitHub を使いこなしています。)企画の立ち上げからオープンな議論もエンジニア起点で行える裁量の大きい会社です。 エンジニアとしてインシデント対応中にあったらいいな！と思える機能も積極的に取り組んでいますので、ぜひ気になった方はカジュアル面談の予約をお願いします！
