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

アジャイルソフトウェア開発宣言に記載されている価値を適用することで、インシデントレスポンスを破壊しユーザーの信頼を構築できます。

Shannon Winter Shannon Winter
Browse topics

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

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

インシデント対応にアジャイルの価値を適用する

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

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

インシデントコミュニケーションの原則: 人間中心のインシデントコミュニケーション

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

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

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

試してみますか?

Statuspage に登録またはログインする >> 

 

Statuspage で、エンドユーザーを登録し、インシデント中に効率的にコミュニケーションを図るベストプラクティスについてより詳しく学びましょう。

 

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

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

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

インシデントコミュニケーションの原則: バリアフリーページの作成とインシデントに関するアップデート

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

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

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

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

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

インシデントコミュニケーションの原則: インシデント中およびその後における透明なコミュニケーション

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

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

インシデントコミュニケーションの原則: アジャイルなふりかえり

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

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

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

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

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

プロからのヒント:

Atlassian Team Playbook のふりかえりのプレイを実施し、チームが安心してふりかえりを実行できる場所を用意して、今後の改善に向けて、うまくいっていることやうまくいっていないことについて話し合います。

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

人間の言語

製品の言語

仮定、希望、不安

タスク、課題、アクション

モチベーション、誤解、行動

スプリント、エピック、ストーリー、リリース

プリファレンス、関係、リスペクト

マイルストーン、依存関係、日付

役割と責任

ミーティング、カレンダー、メール、ファイル

信頼をお忘れなく

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