こんにちは。介護事業者向け経営支援サービス「カイポケ」でエンジニアリングマネージャーを担当している橋口(@gusagi)です。 今回は、少し前にカイポケの訪問看護チームで行った「システム障害対応訓練」について紹介します。
なお、システム障害対応訓練に関しては、今回の記事だけでなく裏側を中心に紹介する記事を掲載予定です。 今回の記事ではやったことを中心に紹介させてもらい、別の記事では準備期間・当日・ふりかえりの裏側でどんな動き・工夫があったのかを紹介する予定です。そちらもなるべく早く公開するつもりですので、ご期待いただけますと幸いです。
きっかけ
訪問看護チームでは、テックリードを中心とした体制で開発・運用を行っています。 この体制は現時点で機能していますが、ある時のふりかえりで「テックリードが不在の時に何らかの問題が起こったとしてもうまく連携して対応することができるか?」という指摘が上がりました。
テックリードが不在となった場合に心配なことは何かを具体的に挙げていったところ、票が一番多く集まったのがシステム障害が発生して対応を行う時でした。訪問看護チームではシステム障害対応のガイドラインも策定していたのですが、その中で対応時の指揮官(インシデントコマンダー*1)を毎回担っているのがテックリードであったため、不在の時にチームが同じように動けるのかが不安要素として挙がったのです。
特に、以下の課題に関しては早い段階で手を打つ必要がありそうでした。
- テックリード以外にインシデントコマンダーを担える人がいるかが分からない
- チームで行う対応がインシデントコマンダーの判断・指示に依存している
- QAチームとの連携がスムーズにできていない
そこで「テックリードが不在の時のシステム障害対応」という課題に対する対応案として、表題にもあるシステム障害対応訓練を実施するという取り組みがスタートすることとなりました。 このシステム障害対応訓練において期待する効果は以下です。
- 短期・直接的な成果:
- 障害対応の解像度を上げる
- インシデントコマンダーを担える人間を増やす
- 中長期的な期待:
- 各人がシステム障害対応に主体的に関われるようなチームへの成長
やることが決まるまで
システム障害対応訓練を行うということを決めて、そこからどんな内容にするかをチーム内で考えていく流れとなりました。 企画に名乗りを上げてくれた若手エンジニア2名を含めて打ち合わせをして、大枠として以下のことが決まりました。
- お客さまからのお問い合わせをトリガーとして、問題の調査や解決を進める流れとする
- 実際にシステム障害を起こしたりはせず、チーム内でシミュレーションを行う形とする
- ただし、ログや各種メトリクスの調査は、ある程度まで実際にやってみる
- そのシーンで実行できるアクションは選択肢を提示しつつも、それ以外にも参加者が考えて何をするか決めて良い
- インシデント時のガイドラインに則って専用のSlackチャンネル作成なども行う
- チーム外に不要な混乱が起きないよう、事前の周知を徹底する他、当日のSlackチャンネル名などにもシステム障害対応訓練であることを明記する
上記を満たす方法を検討した結果、テーブルトークRPG(TRPG)*2の形式を取るのが良さそうだという話になりました。
TRPGとは、ゲームマスター(GM)と呼ばれる進行役と、プレイヤー(PL)と呼ばれる参加者で協力して会話をベースとして物語を進行させていく遊びです。 実際には起きていないシステム障害に対するシミュレーションで、選択肢にない参加者の行動も柔軟に拾っていくことを考えた結果として、TRPGが良さそうだとなりました。 TRPGの形式が良いと判断した主な理由は以下です。
- リモートワーク中心の状況で実際にシステム障害に対応する場合でも、複数人で会話をしながら対応を進めることが予想されるため、近しい状態で訓練することができる
- シミュレーションによる訓練となるため、進行役としてGMが存在する方が柔軟に対応できる
- 訓練だからこそ、少しは遊び心を入れて楽しみながら取り組めるようにしたい
また、企画に名乗りを上げてくれたエンジニアがどちらもTRPGを知っていたこともスムーズに方針が決まった一因になったと思います。
当日までの準備について
まずは発生したとするシステム障害の内容と大枠のシナリオを決めることとしました。
訪問看護チームは、介護事業者向け経営支援プラットフォーム「カイポケ」のうち訪問看護の領域を開発・運用しています。従って、カイポケのサービスにおいて特にお客さまへの影響が大きく緊急性の高いシステム障害が発生したと想定する方が望ましいと考えました。 そこで、発生したシステム障害の内容を決めた上で「一部のお客さまから『診療報酬明細書(レセプト)が出力できない』というお問い合わせが来た」という状況からシナリオが始まるようにしました。
なお、シナリオにはフラグによってエンディングが分岐する仕掛けを入れておき、GoodエンドからBadエンドまで何種類かのエンディングを用意しました。
また、TRPGを知らない・詳しくない参加者がいることが予想されたため、企画に参加しているエンジニアのうち片方の人にGM役を、もう片方の人には参加者として他の人のフォローに入ってもらうことをお願いすると共に、参加者の人にはシナリオを伏せた状態で準備を進めるようにしました。 合わせて「ハンドアウト」と呼ぶ事前資料を用意して、目的を意識して訓練に臨んでもらえるようにしました。 ハンドアウトではシステム障害対応訓練の目的や進め方の説明と合わせて、TRPGに不慣れな人向けのロールプレイの説明や会話をしながら進めることの必要性なども記載しました。また、トレーラーと呼ぶようなシナリオの予告ストーリーも載せておき、訓練ではあるもののゲームとして楽しめるような遊び心も盛り込ませてもらいました。
当日の実施レポート
当日は、まずは訓練会場として用意したZoomに集合してGMから改めて当日の流れを説明しました。 その後、実際のお問い合わせを模した形で内容をJIRAのチケットとして起票し、Slackで運用担当者への確認依頼をGMから伝えて、訓練開始となりました。
初めてのシステム障害対応訓練、かつTRPG風というアレンジが入っていたことで、訓練の途中にルールへの質問が入ったり、対応に関する相談が想定以上に盛り上がり時間が押してしまうというハプニングもありましたが、PdM・エンジニア・運用・QAといった日頃の役割を超えて意見の交換が行われており、概ね成功したと言えるのではないかと思います。
なお、最後は駆け足気味になっていましたが押さえるべき観点をしっかり押さえた対応を行えており、シナリオの結果として一番良いエンディングに到達することができていました。 訓練の最中にも「このペースで問い合わせが来ているの、相当ヤバい状況だね」「どう動いたら早く・確実にこの事象を解消できそう?」という会話が出ており、訓練を通して参加者がしっかりとシステム障害対応に取り組むことが出来ていたのではないかと思います。
振り返りについて
訓練結果を有効に活用するため、訓練直後に簡単なアンケートに協力してもらい、その内容を事前に共有した上でYWT形式でふりかえりを行いました。
アンケートの回答では、訓練を実施したことそのものに対する好意的な意見、訓練を通して得た気付き、訓練の進め方に関する改善の提案、今後の希望など多くの回答がありました。 また、アンケート結果を踏まえてのふりかえりでも、書き出しの時間をそこまで取ることが出来なかったにも関わらず、想像を大きく超える数の付箋が書き出されました。内容も、やったこと(Y)よりも、そこからわかったこと(W)や次に行うこと(T)の数が圧倒的に多く、この点からも、参加者にも楽しんでもらうと共に、システム障害対応訓練で気付きを得てもらうことが出来たのではないかと思います。 公開できない情報もあるためお見せすることができないのが残念なくらいでした。
あとがき
ここまでで、訪問看護チームで行ったシステム障害対応訓練でやったことの紹介は終わりとなります。 ですが、冒頭にも書いたように、準備期間・当日・ふりかえりの裏側でどんな動き・工夫があったのかを紹介する別の記事も準備していますので、そちらもなるべく早く公開するつもりですので、ご期待いただけますと幸いです。
*1:インシデントコマンダーについてはAsanaの記事やAtlassianの記事が参考になります
*2:TRPGに興味のある人は富士見書房さまによる紹介ページやWikipediaの記事もご覧ください