はじめに

システム障害が発生すると、現場ではさまざまな報告や連絡が飛び交います。例えば、「現在、障害を調査しています」「原因はまだ分かっていません」「復旧作業を開始しました」「影響範囲を確認しています」のようにです。

このような報告を、メールやチャット、電話、会議などを使って関係者に伝えます。しかし、これだけ報告しているにもかかわらず、「結局、どういう状況なのか分からない」と言われた経験はないでしょうか。

システム障害では、情報システム部門やSIerの担当者だけで対応が完結することは多くありません。事業部門、サービスの責任者、経営層、営業部門、カスタマーサポートなど、さまざまな関係者が関わります。それぞれ立場が違えば、知りたい情報も違います。

システム担当者が「データベースのコネクション数が上限に達しています」と説明しても、事業部門が知りたいのは、「それで、顧客はサービスを利用できる状態なのか」「いつ復旧するのか」「代替手段はあるのか」ではないでしょうか。一方で、経営層が知りたいのは、「事業への影響はどの程度なのか」「重大な問題なのか」「今後さらに拡大する可能性はあるのか」「経営として何か判断する必要があるのか」ということかもしれません。

では、障害対応におけるコミュニケーションは、専門用語を使わず、適度な頻度で報告すれば、それだけでうまくいくのかというと、それだけでは不十分でしょう。

重要なのは、情報を伝えることではなく、受け取り手が必要なことを理解し、判断や行動につなげられることです。

そのためには、障害対応が始まってから頑張って報告するのではなく、平常時からコミュニケーションそのものを設計しておく必要があります。

「報告しているのに伝わらない」のはなぜか

障害対応においては、次のような技術的な情報が次々に集まります。「APIのレスポンスが遅い」「CPU使用率が上昇している」「DBの接続数が上限に達している」「バッチ処理がタイムアウトしている」「ネットワーク経路に異常がある」

これらは、技術担当者にとって重要な情報です。しかし、その情報をそのまま別の関係者に伝えれば、相手が状況を理解できるとは限りません。

例えば、あるECサイトで障害が発生し、システム担当者が「決済APIのタイムアウトが増加しています」と報告したとします。技術担当者にとっては、かなり重要な情報です。

しかし、事業部門の担当者は、「つまり、お客様は商品を買えるのですか」「注文は成立しているのですか」「売上への影響は出ていますか」と聞きたくなるでしょう。

この二つの説明は、どちらが正しいという話ではありません。相手が必要としている情報のレイヤー、粒度が違うのです。障害対応では、「正しい情報を伝える」だけでは足りません。「その相手にとって意味のある情報に変換して伝える」必要があります。

関係者によって、知りたいことは違う

障害対応の運用設計においては、コミュニケーション設計と情報設計が重要です。

コミュニケーション設計においては、誰に連絡するのか、どの手段で連絡するのか、どのような体制でエスカレーションするのか、誰が意思決定するのかを事前に考えることがポイントです。情報設計では、「関係者が必要としている情報は何か」「その情報を誰がどのように収集するか」「その情報をもとに誰がどのような判断をするか」まで考えます。

ここで重要なのは、「関係者」という言葉を一括りにしないことです。例えば、システム障害が発生したとき、システム保守担当者が知りたいことと、ITサービスマネージャが知りたいこと、事業部門が知りたいことは同じではありません。

システム保守担当者なら、原因究明や復旧に必要な情報が重要でしょう。ITサービスマネージャなら、影響範囲、緊急度、対応状況、次に必要なアクションなどが重要になります。事業部門なら、顧客や業務への影響、代替手段、復旧見込みなどが重要になるでしょう。経営層であれば、事業インパクトやリスク、意思決定の必要性などが重要かもしれません。

つまり、同じ障害について報告していても、全員に同じ情報を同じ粒度で伝える必要はありません。むしろ、全員に同じ情報を送り続けることは、冒頭に紹介したコミュニケーションの目的である、伝わって理解される、行動に繋げるという目的を阻害する場合があります。

「専門用語を使わない」だけでは不十分

これまでの経験で上司や先輩から、「障害報告は専門用語を使わず、分かりやすく書くこと」と教えられたことはないでしょうか。これはこれで正しいアドバイスです。しかし、専門用語を一般的な言葉に置き換えるだけでは、十分ではありません。

例えば、「データベースのコネクションエラーが発生しています」を、「データベースに接続できない問題が発生しています」と書き換えたとしても、事業部門が知りたいことが分からなければ、コミュニケーションとしては不十分です。

こういう時は、「現在、一部の注文処理が完了しない状態です。原因を調査中ですが、注文受付への影響が続いています。代替手段について事業部門と確認しています」のように、技術的な事象を、相手が判断するための情報に変換する必要があります。

つまり、コミュニケーション設計で考えるべきなのは、「難しい言葉を使わないこと」ではありません。相手が、その情報を何に使うのかを考えることです。

「原因」を伝えるより、「影響」を伝える

障害が発生すると、技術担当者は原因を調査します。原因が分かれば、それを報告したくなります。

例えば、「アプリケーションサーバーのメモリリークが原因でした。」という原因がわかったとします。これは重要な情報です。しかし、障害発生中の事業部門にとって、それだけでは十分ではありません。

実際は、「その結果、何が起きているのか」「誰が困っているのか」「どの程度困っているのか」「いつ頃までに戻りそうなのか」「利用者は何をすればよいのか」といった情報が必要になります。

障害対応プロセスとしては、発生事象の事実把握や原因・影響の調査と、収集した情報と判断基準をもとにアクションを決定することがポイントになります。これは、情報を集めることと、その情報をもとに判断することは別だということも意味しています。

そして、コミュニケーションの目的も、「情報を集めたから報告する」ではなく、「必要な人が必要な判断をできるようにする」と考えたほうが、障害対応全体がうまく設計できます。

報告頻度には「正解」はない

もう一つ、障害対応でよく問題になるのが報告頻度です。例えば、「30分ごとに報告する」「1時間ごとに定例報告する」といったルールを設けることがあります。

これは有効な場合もありますが、頻度だけ決めても十分ではありません。例えば、重大障害が発生しているのに「次回報告は1時間後です」と言われたら、受け取り手は不安になります。

逆に、状況がほとんど変わっていないのに5分おきに同じ内容の報告が来れば、対応している側も報告を読む側も疲弊します。

重要なのは、時間だけでなく、状況の変化に応じて報告することです。

例えば、「影響範囲が拡大した」「重大度が変わった」「復旧見込みが変わった」「新しい事実が判明した」「意思決定が必要になった」といったタイミングでは、定例報告を待たずに共有する。一方、状況に大きな変化がない場合は、一定間隔で状況を伝える。

このように、「時間による報告」と「イベントによる報告」を組み合わせると、より実務に合った設計になります。

「誰に、何を、どの粒度で、いつ伝えるか」を決める

ここまでの話を整理すると、コミュニケーション設計では、少なくとも四つのことを考える必要があります。

一つ目は、誰に伝えるのかです。システム担当者なのか、ITサービスマネージャなのか、事業部門なのか、経営層なのか。それぞれの関心事を考えます。

二つ目は、何を伝えるのかです。技術情報、影響範囲、復旧状況、リスク、意思決定事項など、相手が必要とする情報を整理します。

三つ目は、どの粒度で伝えるのかです。同じ情報でも、技術担当者向けと経営層向けでは必要な詳細度が違います。

四つ目は、いつ伝えるのかです。定期的に伝えるのか、状況が変化したときに伝えるのか、判断が必要になったときに伝えるのかを決めます。

これらを整理しておけば、障害が起きたときに担当者が毎回ゼロから悩む必要がありません。

コミュニケーション設計は「信頼」をつくる

ここまで読むと、コミュニケーション設計は、単なる障害対応の効率化だと思われるかもしれません。しかし、もう一段深く考えると、コミュニケーション設計は「信頼」にもつながります。

例えば、障害が発生したときに、「原因は調査中です」という報告だけが何度も届くケースを考えてみてください。受け取り手は、次第に不安になります。「本当に対応できているのだろうか」「状況を把握できているのだろうか」「いつになったら復旧するのだろうか」と考えるからです。

一方で、「現在確認できている影響はAとBです。原因は調査中ですが、Cの可能性を調査しています。現時点では影響範囲の拡大は確認されていません。次にDを確認し、15時を目途に復旧見込み時間を更新します」と伝えられれば、原因がまだ分かっていなくても、受け取り手は状況を理解できます。

信頼とは、すべての答えを持っていることによって生まれるのではありません。分かっていること、分かっていないこと、次に何をするのかを、適切なタイミングで共有することによっても生まれます。

障害対応では、原因がすぐに分からないことがあります。復旧時間を断言できないこともあります。だからこそ、「分からないことを分からないまま、どう伝えるか」が重要になります。

コミュニケーションは障害発生前に設計できる

もしかすると、「障害が起きたときの報告は、その場で考えるしかない。状況によって様々なパターンがあるので限界がある」、そう考えている組織もあるかもしれません。

しかし、障害発生時は、ただでさえ情報が不足しています。原因も分からない。影響範囲も分からない。復旧見込みも分からない。その状態で、「誰に何を伝えるか」までゼロから考えるのは簡単ではありません。

だからこそ、平常時に設計しておく価値があります。例えば、「このサービスで障害が発生したら、最初に誰へ連絡するのか」「重大度が上がったら、誰へ追加で連絡するのか」「事業部門には、どのような情報を伝えるのか」「経営層には、どのような粒度で報告するのか」「どの状況になったら定例報告を待たずに連絡するのか」といったことを、あらかじめ整理しておきます。

つまり、コミュニケーションは「担当者のコミュニケーション能力」に任せるものではなく、ある程度は仕組みとして設計できるのです。

「伝える」から「理解してもらう」へ

障害対応では、技術的な問題を解決することに目が向きがちです。しかし、障害が大きくなるほど、技術だけでは解決できない問題が増えていきます。例えばこのような問いです。サービスを継続するのか。一部機能を停止するのか。顧客へ告知するのか。事業部門へ代替手段を依頼するのか。経営層へ報告するのか。

こうした判断には、多くの関係者が関わります。だからこそ、障害対応におけるコミュニケーションは、単なる「報告・連絡」ではありません。情報を必要な人につなぎ、その人が状況を理解し、必要な判断や行動を取れる状態をつくる活動です。

そのためには、報告先の組織が何を気にしているのかを理解しなければなりません。システム担当者には技術的な情報が必要ですが、事業部門には業務や顧客への影響を気にしています。経営層からは事業インパクトを聞かれるでしょう。

同じ障害でも、見るべき切り口は違います。「誰に、何を、どの粒度で、いつ伝えるのか」を考える。そして、実際の障害対応を振り返りながら、その設計を少しずつ改善していく。これが、障害対応におけるコミュニケーション設計の勘所なのではないでしょうか。

次に障害が発生したとき、まず「どんな報告を書こうか」と考えるのではなく、「この報告を受け取る人は、何を知りたいのだろうか」と考えてみてください。その小さな視点の変化だけでも、報告の内容は変わります。そして、報告が変われば、関係者の判断も変わります。

障害対応において、すべての問題を一人で解決する必要はありません。必要な情報を、必要な人につなぐことができれば、組織全体で対応することができます。

コミュニケーションとは、障害対応の「付随業務」ではありません。組織として障害に対応するための、重要な仕組みそのものです。

だからこそ、次の障害が起きる前に、一度、自分たちの報告や連絡を見直してみてはいかがでしょうか。「誰に、何を、どの粒度で、いつ伝えるのか」。この問いから始めるだけでも、障害対応は少しずつ変えていけるはずです。