失敗したときのためのアジャイル: インシデント対応計画に欠けているもの

アジャイルのメソッドは、従来のソフトウェア開発以外にもあらゆるビジネス分野において使用されるようになってきています。これには、マーケティングも含まれます。インシデント管理の世界にとってアジャイルはどう映るのでしょうか?Atlassian では、アジャイルをプロジェクト管理と製品開発における構造的で反復的なアプローチとして定義しています。アジャイルはチームを強化し、脱線することなく変化に対応できるようにします。

本番環境のバグ、インシデント、ダウンタイムは「脱線」した回数として分類されるため、チームが脱線しないように構築されたアジャイルのような方法は、インシデント管理に役立つはずです。特にインシデント コミュニケーションにおいて威力を発揮するでしょう。

チームがインシデントを検知、アラート、収集、解決するためのツールはあればあるほどいいものですが、ツールだけでは関係者への明確なコミュニケーションは成り立ちません。また、現実的には、リスクも高くなります。評判、顧客の減少、ダメージ管理に費やされた時間といったリスクです。アジャイルのメソッドはこれらのリスクをできる限り軽減します。

多くの方はアジャイル マニフェスト の4 つの原則をすでにご存知でしょう。1) プロセスやツールよりも個人と対話を、2) 包括的なドキュメントよりも動くソフトウェアを、3) 契約交渉よりも顧客との協調を、4) 計画に従うことよりも変化への対応を、という 4 つの原則です。これらをもう少し詳しく見ていき、よりアジャイルなインシデント コミュニケーションにどう活用できるかを確認しましょう。

この原則はアジャイルの価値に基づいています。個人とプロセスおよびツールをめぐるやりとりです。プロセスとツールはすべてのインシデント管理プロセスにおいて重要ですが、それを使用しようとしている人々や、その周りに構築された文化から離れれば、何の価値もありません。人、プロセス、ツールの隙間を埋めるものは何でしょうか。もちろん、コミュニケーションです。

本番稼働環境の小さなバグでも、重大なシステム障害でも、課題が発生したときにコミュニケーションは必要不可欠です。完璧なインシデント計画であっても、解決に達し信頼を維持するためには、より頻繁なコミュニケーションが必要です。

インシデントの最中、影響を受けたユーザーはフラストレーションがたまり、時には神経を消耗するようなエラーに遭遇し、可能な限り速やかに何が起こったか知りたいと考えます。すでに多くの人がメールしたり、ツイートしたり、問題に関するチケットに記入したりしているため、あなたが事情を把握し修正中であることを示すメッセージを迅速に公開することが重要です。Atlassian では、Statuspage を使用して、ダウンタイム中に内部および外部の関係者とコミュニケーションをとっています。インシデントに関する情報を迅速にユーザーに伝えたい場合、Statuspage の価値をご理解いただけるはずです。実のところ、Statuspage は、ユーザーによるインシデント コミュニケーションの速度を 50% 向上させています。

顧客への情報伝達に使用するツールが何であれ、人間を中心としたコミュニケーションは重要です。問題の向こう側にいるのは、あなたのサービスに依存し、問題が生じた時にはその情報を伝えてほしいと願っている人間なのです。完璧な世界ではテンプレートもいいものですが、物事がうまくいっていないときに顧客との信頼関係を築くには、明確かつ端的で、共感性が高く、関連性のあるメッセージを作成できる人材が必要です。Dyn の例を見てみましょう。Dyn は歴史上有数の DDoS 攻撃において大規模な障害を経験しましたが、誠実さを持って顧客対応をしたため、サービスがダウンしている間もユーザーは Dyn に感謝の意を示しました。

AWS の最高技術責任者 Werner Vogels 氏は 2017 年 2 月、AWS の S3 に発生した大規模障害について議論しているとき、こう発言しました。

「お客様は『何もなさらず、お待ちください』という助言を好みません。お客様はそんな答えを望んでいないのです。本当に価値のある情報を提供し、何が起こっているか説明する必要があります。サービスがいつオンラインに戻るか予測できる情報が手元にあるなら、それを通知するべきです」

この原則では、「包括的なドキュメントよりも動くソフトウェアを」というアジャイルの価値に注目します。製品に関する文書は明確で、ユーザー フレンドリーでなければいけません。インシデント アップデートもしかりです。何が起こっていていつ修正される予定なのかを知るために、ユーザーが行間を読んだり、長い段落に目を通したりしなければいけないというのは間違っています。インシデント アップデートに思いを込め、共感性が高く人間らしいコミュニケーションを心がける必要はあるものの、複雑な承認体制や度重なる見直しが、頻繁かつ真摯なアップデートの妨げとなってはいけません。

Dyn のインシデントをふりかえると、チームが時間を無駄にすることなく、ユーザーにアップデートを伝えたのだとわかります。11 時間超のインシデントにおいて、Dyn はステータス ページを 11 回更新しました (平均更新間隔は 61 分)。ステータス ページは Dyn にとって、インシデントについて通知する唯一の場となったため、メール送信のためにメーリング リストを探したり、アップデートを Twitter で伝えるために 140 文字にまとめたりする必要はありませんでした。つまり、サービスの復旧にフォーカスしつつ、ユーザーにメッセージを伝えることができたのです。

型にはまらないステータスコミュニケーションツールの素晴らしい点は、きちんとしたページを立ち上げるのに多くの時間を費やす必要はないというところです。ステータスページは 30 分以下で作成でき、アジャイルと同じく段階的なものにすることが可能です。またそうあるべきです。顧客のために作業中のページを公開し、その後改善していくことを検討してください。ステータスページがプロセスの一部となったのちにいくつかインシデントを経験し解決すれば、その後はサービスを提供しながらページを改善できます。

独自のステータス ページを作成する準備はできましたか?Statuspage に登録またはログインしてください >>

次にインシデントが発生するまでステータス ページの作成を待たないでください。今数分の時間をとって作成すれば、障害が発生した時に最善の対処ができるようになります。しかも、ページが機能するために多くの時間を費やす必要はありません。

• ステータス ページのカスタマイズ方法をご覧ください。
• 優れたステータス ページのデザインとカスタマイズの例を見てインスピレーションを得ましょう

「契約交渉より顧客との協調を」というアジャイルの価値は、顧客と協業して可能な限り最高の製品とエクスペリエンスを提供することを重視しています。Atlassian にとってそれは、適切なフィードバック チャネルを設定することでした。そうすることで、顧客は懸念を表明したり、体験した課題について (Jira Service Management や Twitter などのツールを使用して) フィードバックできるようになります。グローバル企業は、顧客がフィードバックへの反応を求めており、製品の改善やインシデント レスポンス プロセスに参加したいのだということを理解しています。共感や説明は非常に効果があり、顧客は明確に説明を求めています。以下のツイートには、それがよく表れています。

また、これはアップタイムに透明性を維持し、登録したユーザーがサービス内容を把握できるようにすることを意味します。クラウド サービスに登録するユーザーは、サービスが信頼性の高いものであると信用しています。常に物理的な契約があるわけではありませんが、顧客とサービス提供者間では固有の契約が交わされます。障害が発生したときなどには両者は協調して迅速な解決を心がけ、調査から解決に至るまで、関係者全員が最新情報を入手するとされています。次に、「変化への対応」という最後の価値に話を移しましょう。

画餅に帰すということわざがあります。アジャイルの価値「計画に従うことよりも変化への対応を」を思い返してみましょう。よく練られた計画でさえ、インシデントの発生中や発生後には変更が必要になります。即座に変更でき、製品と文化を改善する迅速かつ頻繁なフィードバックを得られるというのがアジャイルのメリットです。

インターネット動画と分析ホスティング企業である Wistia は、2013 年に、統計インフラストラクチャが停止するという予期しない障害に見舞われた際、アジャイルでいることの重要性を実感しました。Wistia では対応の準備ができておらず、不満を抱えた顧客からのサポート チケットで溢れかえってしまいました。Wistia がとった最初の方向転換は、このような状況において対応しやすくなるように、独自のステータス ページを作成することでした。しかし独自のステータス コミュニケーション ツールを作ることで、コア製品以外の新たな製品をもサポートしなければならなくなってしまったのです。当時 20 人だった従業員だけで対処しきれないことは明白でした。2 つ目の方向転換は、独自のページを廃止し、Statuspage へ移行することでした。

Wistia のサポート エンジニア、Jordan Munson 氏はこう振り返ります。「数か月の間、ほとんど機能はないものの役立つ独自ソリューションに対してわずかに不満を感じ続けており、何か他のことをしなければいけないと考えました。それほど手間のかからない何かです。そこで Statuspage を採用したのです。Statuspage に移行して以来、やりたいと思っていたこと、つまりアプリケーションのステータスに関する最新情報を迅速かつ簡単に顧客に伝えることができるようになりました。大規模な障害と、新しい製品の構築の後にようやく実現したのです。現在、障害から数年が経過していますが、Wistia のプロセスはよりスムーズに進化しています。障害が発生すると、顧客は Wistia から直接アップデートを受け取り、どこにアップデートが記載されるのか知ることができます。Wistia のステータス ページのアップデートは直接さまざまな場所にも通知されます」

Munson 氏のチームは 2013 年の障害という苦い経験を学びに変え、新しく改善された拡張可能なインシデント コミュニケーション プロセスを生み出しました。これが変化に対するアジャイルなレスポンスです。

ふりかえりも、アジャイルの価値の重要な一部分です。ふりかえりは、チームにとって一歩引いた観点から、インシデント コミュニケーションにおいてうまくいったことは何か、うまくいかなかったことは何か、そして何よりも、同じ問題の発生を防ぐために何ができるかを話し合う機会です。インシデントが解決した後や、チームが優れたパフォーマンスを発揮したと感じたときに、ふりかえりを省略しないでください。インシデント コミュニケーションには常に改善の余地があり、ユーザーとより良い信頼関を構築する機会でもあるのです。

最初のアジャイルソフトウェア開発宣言を確認すると、ふりかえりを成功させ、持続的な結果を導き出すには人間中心型のコミュニケーションが必要だと書いてあります。ふりかえりミーティングにおいてインシデント解決がどう機能したかを議論する際には、以下の言語に関するポイントを考慮します。これらの言語の一部は、サービスが復旧したあとにユーザーに送信される、事後分析や事後インシデントレビュー (PIR) にも引き継がれるべきです。アジャイルであるということは、インシデント関連のタスクの実行だけではなく、チームメートとの共感やストレスフルな状況における役割の遂行の方法においても継続的に改善するということです。

アジャイルでは信頼性がよく話題になりますが、このケースも同様です。効率的なインシデント コミュニケーションには信頼と自信が必要です。組織をまたぐチームは、承認やインシデントに関するユーザーとのコミュニケーションに必要な知識によって自信を持つべきです。個人も、インシデント対応中に全員が割り当てられた責任を果たすこと、また予期せぬ事態が発生した場合プロセスを中止できることを信頼できなければいけません。チームを信頼しインシデントについて効率的にコミュニケーションをとることで、顧客はより迅速に情報を入手できるようになります。これはユーザーからの信頼やサービスへの忠誠心につながります。(67% の Statuspage の顧客が、Statuspage はユーザーの信頼を向上させる役割を果たしたと述べています。)真の Win-Win です。