この記事は最初に『learningfromincidents.io』に掲載されました。
Photo by Jared Erondu on Unsplash
Indeed の Site Reliability Engineer (SRE) として、インシデントの後のレトロスペクティブという振り返りの工程に数多く参加しています。Indeed では2015年後半頃から導入されているレトロスペクティブは、我々のエンジニアリングカルチャーの一部になっています。その重要性に疑問を感じたことはありませんでしたが、最近のレトロスペクティブでは次のような傾向が見られるようになり、レトロスペクティブの本来の利点が活かされていないのではないかと思い始めました。
- 割り当てられた時間の30% 程度しか活用していない。
- 出席しなくても、インシデントのチケットやレトロスペクティブの議事録などを見れば、内容がわかる。
- インシデントを「引き起こした」条件に時間が割かれすぎている。
- レトロスペクティブ開催の要否の判断基準が、影響が大きいものや、ビジビリティの高いインシデントに偏りがちである。
- 参加者は新しい事を学んでいるのか? インシデントに基づく学びの機会を最大限に活用できていない。
私は、なぜこのように感じたのか、どうしたら改善できるのか考えることにしました。
典型的なレトロスペクティブとは
Indeed のレトロスペクティブは通常1時間で、多い時は70〜80人が参加します。社内の誰でも参加できますが、インシデントのレスポンスに関わった人やインシデントの結果に関心がある人たちが参加することが多いです。
ファシリテーターは次のような、あらかじめ決められた手順に従ってレトロスペクティブを進行させます。
- タイムラインの振り返り
- テンプレート内の改善項目の確認
- 改善項目の担当者の決定
- 質疑応答
改善点
2018年の夏、Indeed のテックオフィスでレトロスペクティブに数回参加し、最近のインシデントについて話し合いました。私は SRE なので、レトロスペクティブに参加するのは珍しいことではありませんし、当該インシデントに関するテクノロジーは、私の専門分野でした。
ファシリテーターは5分ほどタイムラインに触れ、8 〜10分かけて改善項目を確認し、インシデントの原因と結果に関わるテクノロジーについての質疑応答でレトロスペクティブを終えました。新たな学びはありませんでした。インシデントのチケット、レトロスペクティブの議事録やスライドを見れば同じ情報を得ることができました。総力を結集して問題に立ち向かおう、という意欲を持った熱心なメンバーが1つの会議室に集まるという滅多にない機会でしたが、そのチャンスを最大限に活かすことはできませんでした。
どのレトロスペクティブもこうだと言うわけではありません。出席者が詳細な情報を提供し、議論が1時間というタイムリミットを越え、最後には会議室の外で身を寄せ合って話し続けるようなレトロスペクティブに参加したこともあります。
先ほどのファシリテーターは、レトロスペクティブをきちんと進行させてはいましたが、時間を30％程度しか活用できていませんでした。レトロスペクティブのやり方そのものに改善が必要なことは、明らかでした。
セーフティカルチャーを育てる
改善点を把握するため、レトロスペクティブを行う理由を聞くことから始めました。集まった主な意見は次のとおりで、ソフトウェア開発に携わる人たちには馴染みのあるものだと思います。
- アウテージの原因を解明するため
- 影響の大きさを測定するため
- アウテージの再発防止を徹底するため
- 改善項目をリストアップし、担当者を決めるため
これらの意見には、Indeed 社員の強い当事者意識が表れています。あるサービスがインシデントに関係していた場合、そのチームは、自分たちが思っていた以上に障害発生が近かったのかもしれないという懸念を持ちます。優先順位を一時的に変更し、チームのメンバーはプロセスや設計の選択肢をより注意深く検討するようになります。
重要なのは、このような機会を活用して Indeed のシステム (人とテクノロジーの両方) と立てた推測をより詳しく分析するように労力をシフトさせることです。これまでとは異なる Indeed 社内でのセーフティカルチャーへのこのようなアプローチはまだ比較的新しく、広がりを見せ始めている段階です。
提案: 改善をレトロスペクティブから切り離す
私は、改善項目の作成プロセスの変更を提案しました。レトロスペクティブは、改善項目のリストアップと担当者の決定を促すための会議ではありません。
プロダクション環境が安定してから改善項目のピックアップが行われるのを日々目にしますが、インシデント発生後には、たくさんの修正が必要になってきます。
「発生後」のアクティビティをレトロスペクティブから切り離すべきだと考える理由は一つではありません。
- 改善項目のピックアップは、暗黙の停止地点となり、それ以降のより詳しい調査を止めてしまう。
- 改善項目の担当者決定の責任は、インシデントの担当者と確実に結びつけられるべき。
- レトロスペクティブは、任意のアクティビティとすべき。担当チームは、義務だから、チェックリストにあるから、ではなく、参加する価値があるかどうかで参加を決定する。
- 参加者は、改善項目のピックアップや浅薄な説明といった負担から解放され、より深い調査ができるようになる。
提案: テンプレートの柔軟性を高める
レトロスペクティブ用のテンプレートの変更は有益でした。
レトロスペクティブ用のテンプレートを使用すると、空欄に情報を入力するだけの作業になってしまいます。自由な議論ではなく、アクティビティを完結させることに焦点が向けられてしまいます。テンプレートではなく、何も書かれていない白紙のドキュメントを使用すると、別の形での共有が始まります。白紙のドキュメントに変えただけで回答者のモチベーションが高まり、自分の意見や説明を共有し、詳細な分析を書いてくれたことが何度かありました。
もし、インシデントが雪の結晶のような形をしていたら、インシデントごとの特徴を捉えられるテンプレートを作成するのは不可能です。テンプレートを使用すると、詳しく説明しようとした時に制約が出てしまい、回答選択式の質問を使用した説明になってしまいます。白紙というキャンバスであれば、自由に答えられます。テンプレートは、深い分析の妨げになる、もうひとつの暗黙の停止地点なのです。インシデント分析にテンプレートを応用するのはおすすめですが、レトロスペクティブでは白紙のドキュメントをおすすめします。
組織的な変化を促す
急成長を続ける Indeed では、変化を促すことで、多くのことを学んできました。社内での経歴や、何百というインシデントに立ち会った経験、そのドキュメントとの関わりなどが、自分の取り組みに役立ちました。前進はしていますが、まだまだやることがあります。
ここまでの前進は、社内で賛同者を見つけ、連絡を取り続けてきたから実現できたと思っています。
賛同者を見つける
賛同者は、同じ目標を持っている同僚たちで、改善できる点を指摘してくれ、どう改善できるかというビジョンを共有してくれます。こうした賛同者を見つけるのにはまったく苦労しませんでした。同僚たちは、熱心に話を聞いてくれ、自分とは異なる視点を受け入れられる広い心と忍耐強さを持っています。組織内のリーダーや関係者とも何度も1対1で話し合いましたし、ミーティングでもこのようなトピックを提案する機会がありました。世界各地の Indeed のテックオフィスに行くときは、テックトークを行い、潜在的な賛同者に働きかけてきました。
何度も伝える
自分が取り組んでいることをしっかり伝えられていると自分では思っていましたが、十分には伝わっていませんでした。何度も何度も伝える必要があるのだと気づきました。複数の方法でくり返し伝えてきたので、私の身近にいた人たちは、同じことばかり、何度も言っているなと思ったでしょう。しかし、こうでもしないと私の話が耳に入らないような、社内でも遠く離れた誰かには伝わりませんでした。メールや社内ブログにすべて目を通す時間がある人ばかりではないからです。
先を見据える
こうした変更への反応は、おおむね好意的です。レトロスペクティブでの焦点は、人的要素に注目すべき場合でも、やはり技術的な要素に向けられています。こうした取り組みをさらに多くの人たちに広めて効果をあげるために、さまざまな方法を検討しています。これには、Instructional Design チームと連携したデブリーフのファシリテータープログラムの作成、より頻繁に幅広くコミュニケーションを取ること、さらなるプロセスの変更、継続したチームの生産性向上の支援と質の高いドキュメントの共有、教育の機会の提供などがあります。現時点では、この取り組みはまだ始まったばかりですが、成果が楽しみです。
投稿者の紹介
Alex Elman は、Indeed の Site Reliability Engineering (SRE) チームの創立メンバーです。現在は、Resilience Engineering チームと、Job Search という Indeed の主要プロダクトのチームのリーダーです。過去8年間にわたり、複雑さを増しつづけるシステムの拡張に対応するために、信頼性の施策の導入支援を行っています。Alex を Twitter でぜひフォローしてみてください。 @_pkill.
