BLOG
インシデント対応でビジネス対応が必要な場合、誰に通知すればよいか

投稿:2022年3月25日   |    更新:2023年3月1日

単独のオンコールエンジニアがオンラインで問題解決に当たる場合もあれば、CTO、CISO、CIOといった上級技術者まで巻き込んだ大規模なチーム横断の取り組みまで、インシデントレスポンスチームは、顧客が気付く前に問題を解決できれば御の字です。しかし、顧客に影響が及ぶようなケースでは、営業やカスタマーサービスなど他のステークホルダーにも情報を提供し、最新情報を入手する必要があります。

インシデントレスポンスとは、システム内で発生した予期せぬ問題に対する技術的な対応を指します。問題発生を知らされたSME(Subject Matter Expert:専門家)が戦場に飛び込み、問題点を診断し、修正し、システムを正常な状態に戻します。

しかし、高度にデジタル化した今日の世界では、顧客向けアプリケーションで発生したインシデントは、対応する技術チームだけでなく、より広い範囲に影響を及ぼします。もちろん、お客様は自分のツール、アプリ、ポータル、ゲーム、ショップがなぜ動かなくなったのか不思議に思っています。そして、社内では、リーダーシップや他のビジネスラインのステークホルダーが答えを探しています。

この「偉い人の差し出口とちゃぶ台返し」は、状況報告のために作業を中断しなければならないレスポンダーにとっては迷惑で威圧的と思われるかもしれませんが、このコミュニケーションは見落とせないのです。コミュニケーションは、インシデント対応プロセスの重要な部分であり、特にハイブリッド/リモートワーク方式を採用しているチームでは、その重要性が増しています。そして、技術者と非技術者の双方がサポートと権限を得てインシデントを見届けるためのやり方があるのです。

ビジネスインシデント対応とは、深刻な技術的インシデントからビジネスへの影響を軽減するための非技術的な対応フレームワークです。ビジネスインシデント対応は、通常業務を緊急業務モードに移行させることと、外部の顧客や社内のステークホルダーとの積極的なコミュニケーションを管理することの2つの主要機能から構成されます。今回のブログでは、顧客とチームの両方の体験を向上させるためのコミュニケーション管理に焦点を当てます。

誰が知る必要があるのか

インシデント発生時には、何が起こっているのかについてさまざまなレベルの詳細を必要とする複数の関係者が存在します。舞台裏で起きていることについて顧客が深い技術的理解を必要とすることはまずないでしょう。また、顧客向けの短いコミュニケーションで経営陣が満足することはないでしょう。読み手に応じて、メッセージを調節することが大切です。

コミュニケーション作成に万能のアプローチはありませんが、事件の優先順位が高い場合には、コミュニケーションを検討すべき相手がいます。ここでは、念頭に置くべき5つの対象者を紹介します。

  • 経営陣。 経営幹部は、優先順位の高い問題について情報を得たいと考える最も一般的なステークホルダーですが、技術に最も明るいとは限りません。前もって最重要事項を伝えておくとよいでしょう。彼らが最も気にすることの1つは、顧客への影響です。また、ビジネス上必要であれば、SLA違反も気にかけるかもしれません。また、何かニーズやリソースがある場合は、早い段階で頻繁に問い合わせを行い、必要なサポートを受けられるようにする必要があります。
  • カスタマーサービスチーム。 これらのチームは、インシデントの最前線にいることが多いのですが、解決プロセスがどのように進んでいるのかが分からないまま置いてきぼりになっていると感じることがあります。カスタマーサービスチームは、サービスがいつ正常に戻るかについて、顧客とコミュニケーションを取りたいと考えています。このようなチームが、新しいインシデントの進展について最初に知ることができるようにすることが重要です。これは、顧客とエンジニアの間のコミュニケーションの橋渡しとなり、信頼を育むことにつながります。特に重要な顧客においては、このような配慮が解約と更新の分かれ目になることがあります。
  • その他の技術チーム。 自分が担当するサービスでのインシデントが、他のチームに影響を与えることがあります。彼らは、それについて積極的に何かをすることはできませんが、それでも情報共有されておく必要があります。優先度の高いインシデントでは、顧客への影響、関連する進捗状況を共有し、必要な支援(人手を増やす、システムの異常に注意を向ける)を求めるとよいでしょう。この連絡では、関係者がシステムの観点から何が起こっているかを理解する可能性が高いため、チームの理解を深めるのに役立つのであれば、技術的な詳細まで踏み込むことができます。
  • その他の事業チーム。 マーケティング、セールス、法務、財務などのチームは、自分たちのビジネスのやり方に影響を与える出来事について知っておく必要があるかもしれません。マーケティング部門は、壊れたウェブサイトに見込み客を誘導するようなキャンペーンを中止したいかもしれません。営業部門は、デモを延期したいと思うかもしれません。法務や財務は、SLAのペナルティーを先取りしたいかもしれません。これらのチームは、おそらく技術的な面にはあまり関心がなく、あなたの役に立つようなリソースを持っていないかもしれません。しかし、これらのチームは、顧客への影響を理解し、定期的に進捗状況を報告する必要があります。
  • 顧客。 顧客に影響を与えるインシデントは、信頼を損なうおそれがあります。信頼を維持する1つの方法は、顧客に影響を与えるインシデントについて、顧客と率直にコミュニケーションすることです。顧客基盤がどのように分かれているかにもよりますが、これを2つのカテゴリーに分けて行うことは理にかなっているかもしれません。1つは、戦略的顧客グループ。もう1つは、それ以外の顧客層です。戦略的な顧客は、より頻繁に、より詳細なアップデートを求めるかもしれません。その他の顧客層は、インシデントが発生したことを理解し、その解決に取り組んでいることと、サービスが正常に戻ったことの2種類のお知らせが必要かもしれません。これは、組織の標準的なトーンとブランドとの関係によって異なります。

これで、更新が必要な人物の見当がつきました。しかし、社内でこの情報を整理する最善の方法は何でしょうか。特にインシデントの解決が優先される場合、このようなコミュニケーションを即座に調整するのはストレスが溜まります。

ビジネスインシデント対応のための社内準備

ほとんどの大規模インシデントでは、コミュニケーションリードの役割を果たす人がいます。この担当者は、ステークホルダーに状況の最新情報を発信し、ビジネスが正しい方向に進んでいることを確認し、さらなる影響を軽減する方法を理解している必要があります。

その他のインシデントの場合、このコミュニケーションリードは、ビジネスインシデント対応リードとは別の人物となります。コミュニケーションリードは、チームとエンジニアリングまたはオペレーションのリーダーとの間の全ての技術的なコミュニケーションに対処し、ビジネスインシデント対応リードは、全ての非技術的なステークホルダーとコミュニケーションを取ります。この2人は密接に連携しながらも、コミュニケーションを明確かつ合理的にするために、役割をはっきりと分ける必要があります。いずれの場合も、コミュニケーションは事前に可能な限り準備する必要があります。

そのための1つの方法として、テンプレートがあります。テンプレートは、対象者ごとに伝えるべきことを理解するのに十分な構造を持ち、かつ状況が変化した場合に編集できる柔軟性を備えています。テンプレートをいくつ作成するかは、組織が何を適切と考えるかによります。いくつかの主要な対象者向けに1つのテンプレートを用意する組織もあれば、対象者ごとにテンプレートを用意する組織もあります。また、優先順位やインシデントの段階に応じて、それぞれの対象者に対応するテンプレートを用意する組織もあります。どの程度詳細な設定が必要かは、社内のステークホルダーと顧客にとって何が適切かによって異なります。

これらのテンプレートも、ただ闇雲に作成すればよいというものではありません。むしろ、社内のステークホルダーのニーズを満たしているか、当人たちに確認する必要があります。さらに、インシデントが発生したときに、顧客と一緒にテストを行い、フィードバックに基づいてテンプレートを変更することもできます。最後に、テンプレートを使用する前に、社内で承認が必要なチームがあるかもしれません。多くの場合、法務部や経営陣は、大規模なインシデントが発生したときにコミュニケーションが円滑に進むように、テンプレートを閲覧し、承認することを望みます。

ステークホルダーとの信頼と透明性の構築

ビジネスインシデント対応策を準備しておくことは、重要な情報を社内でよりよく伝達するのに役立ちます。さらに、インシデントの進行に伴い、情報や動向を積極的に共有することで、困難な状況下でも顧客の信頼を維持することができます。

上記のプロセスは、基本的なガイドラインですが、大規模な組織や成熟した組織では、プロセスの調整と簡素化を支援するツールが必要になります。PagerDutyは、ビジネス全体のチームが合理的な対応を調整し、特に数秒が重要なときに、全ての瞬間について顧客への影響を最小限に抑えることができるようにします。

14日間無料でお試しいただき、お客様のチームの改善にどのように貢献できるかをご確認ください。ビジネスインシデント対応についてもっと知りたい方は、こちらの「Ops Guide」をご覧ください。


この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

book-markカテゴリー :ベストプラクティス