TRPG風な障害対応訓練をやってみた

ボードゲーム大好きな検索チームの tanker です。最近は社内部活で (テキサスホールデム) ポーカー部ができたので、ボードゲーム部と掛け持ちしながら参加しています。

検索チームでは半年毎にオフサイトをやっています。今回は、TRPG風な障害対応訓練をやってみました。

過去のオフサイトの記事も参照ください。 tech.visasq.com tech.visasq.com

Wheel of Misfortune(不運のルーレット)とは、Googleなどで行われている障害対応訓練の手法で、ゲームマスターが障害のシナリオを用意し、障害対応を行うメンバーと会話形式で実施していきます。 TRPGやマーダーミステリーのようなイメージです。

参加人数: 5人 (+ GM)
プレイ時間: 90分
ツール:
- PC (各プレイヤーが spreadsheet や slack を利用するため)
- spreadsheet (公開情報、各人の非公開情報、GMとプレイヤーとの非公開なやり取り)
- slack (プレイヤーのテキストコミュニケーション、共同編集可能なドキュメント [Slack Canvas])
- 紙 (進行管理表)
- サイコロ
あらすじと目的:
- 2025/1/28 [火] 0:00 に slack に通知が飛ぶ。スマホでゲームをしていた「検索エンジニアA」はその通知に気づきました
- 12ターンで終了 (AM 1:00)
- 終了時点で障害復旧できている必要があります
- 人によっては追加ミッションがあり、その場合はそれも含めてクリアしておく必要があります

検索チームリーダー [GM]
- ヨーロッパへ向かう機内のため連絡がつかないです
プロダクトマネージャー [上長]
- 友達と居酒屋で飲んでいて、PCは自宅にありスマホしか持っていません。自宅までの道のりは長いかもしれません
- 障害対応するための権限は持っていませんが、追加ミッションとして「発生日時、障害内容、影響サービス、原因」を報告する義務があります
インフラエンジニア
- 自宅で読書中。slackでメンションされればスマートウォッチで通知に気づけます
- アプリケーションのリリース権限はありませんが、 terraform の変更をリリースするためにはこの人が必要です
検索エンジニアA
- 自宅でスマホゲーム中。通知の第一発見者
検索エンジニアB
- 自宅で入浴中。お風呂から上がろうか迷っています
検索エンジニアC
- 自宅で晩酌中。酔っているため、たまにアクションが失敗します

ダイスロール (ターン参加判定)
- 参加条件を満たしていない場合はダイスを振ります
- エンジニアCに関しては、酔っているか判定のために3ターン毎にダイスを振ります
ターン開始 (3分間)
- ターンに参加しているプレイヤーは Slack 上でコミュニケーションを自由にとれます
  - 前ターンでGMから共有された内容などを伝えたり、他の人に指示をしたり
  - 通話アプリの利用宣言済みの人は口頭によるコミュニケーションも取れます
- アクションを宣言する (区別できるように :mega: をつける)
  - ログを見るや修正PR を作るなど、slack 上できないことはアクション宣言を消費します
  - 各ターン一人1回まで宣言できます
  - ターン中に書き込めなかった場合は無効です
GM はアクションの結果を各プレイヤーに伝達
- 各プレイヤーと GM が閲覧できる spreadsheet 上でプライベートに共有します
次のターンへ

過去の実際の障害やヒヤリハットなどを複数組み合わせてシナリオを作りました
アクションは5分作業を基準に組みました。なので実際の障害対応で5分以上かかりそうなものは、次のターンを休みにして 2ターン消費するようにしています
ダイスを使って遊び要素を増やしています。一方で、プレイ中は障害対応に集中してもらいたかったのであくまでも参加条件判定でのみの利用に留めています
プレイヤーによって参加タイミングを意図的にずらすようにしました。過去の障害のポストモーテムで、途中から参加した人が現状把握や自分に何ができるのかがわからなかったという反省がでたためです
上長にも参加してもらったのですが、あえて指示出しに徹してもらうように権限を制限してみました。判断できる立場の人が手を動かしてしまうとその人に作業が集中してしまいがちという過去の反省を踏まえたものです

GM側
- シナリオや想定質問集の調整にかなり準備時間がかかりました
- (想定問答集にない) 質問にも答えられるようにGM側はある程度経験値必要だと感じました
- ルールが複雑でイメージできないというコメントを最初にいただいたので、最初の2ターンを実際にプレイしてイメージをつかんでもらいました
プレイヤー側
- アクションが自由記述なため、選択式などの方がよかった (実際にアクションしてもらった後、GMからどういう意図のアクションかを聞きなおすことがありました)
- 3分間という時間制限は緊張感があってちょうどよかった
  ランチのカレー

ビザスクではエンジニアの仲間を募集しています！少しでもビザスク開発組織にご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！ developer-recruit.visasq.works

VISASQ Dev Blog