PagerDuty Challenge Cup 参加レポート
〜 実践的インシデント対応訓練を体験！ 〜

こんにちは、MSP開発の朝枝です。
2025年4月10日(木)に虎ノ門ヒルズで開催された「PagerDuty on Tour Tokyo 2025」内で行われた特別イベント、「PagerDuty Challenge Cup」にアイレットチームの一員として参加してきました。今回はその模様をレポートします。

なお「PagerDuty on Tour」の本編についてはクリスさんのレポートがありますのでぜひご覧ください！

【PagerDuty On Tour TOKYO 2025】参加レポート

PagerDuty Challenge Cupとは？

このイベントはPagerDuty社が主催するインシデント対応のスキルを競うコンテストです。私たち参加者は、架空の人気チャットサービス「ペイジーチャットJ」の運用チームとなり、次々に発生するインシデントに対して、PagerDutyを活用しながらいかに迅速かつ適切に対応できるかを競い合います。

配布された参加者マニュアルの見出し。ペイジー君がかわいいです。

コンテストの概要（事前案内より）

• 日時: 2025年4月10日(木) 14:50～16:30
• 場所: 虎ノ門ヒルズ森タワー5階 PagerDuty on Tour 東京2025 会場内
• 形式: 3名1チームでの対抗戦（全5チーム参加）
• 内容:
  • 各チーム専用の検証環境（PagerDuty, AWS, GitHub, Slack, New Relic等）を使用
  • 15分間のセットアップ後、様々なインシデントが発生
  • インシデント対応の速度（MTTA/MTTR）、品質、ステークホルダーとのコミュニケーション、事後レビューなどを総合的に評価

採点のポイント

• 障害対応（根本原因特定と解決）
• ステークホルダーとのコミュニケーション
• インシデント認知から対応開始までの速度（MTTA）
• ポストインシデントレビューの質

単に技術的な対応だけでなく、チームワークやコミュニケーション能力も問われる、非常に実践的な内容でした。

参加チームとチームメンバーの役割分担

当日は私たちアイレット（Team B）を含め、5チームが参加しました。
各社は Team A〜E に割り振られ、アイレットは「Team B」になりました。
次に配布資料で推奨されていた役割分担に従い、以下のように担当を決めました。

• インシデントコマンダー: 朝枝（MSP開発）
  • インシデント対応の指揮、判断。システムへの直接操作は行わず、レスポンダーへ指示。ステークホルダー対応も担当。
• レスポンダー: 後藤田（MSP/前半）→ 村上（セキュリティセクション/後半）
  • システムの調査、復旧作業担当。コマンダーやスクライブと密に連携。
• スクライブ: 村上（前半）→ 後藤田（後半）
  • 対応内容、判断、経緯の記録係。PagerDuty Notesやステータスアップデート、Slackへの記録を担当。

コンテストの途中でレスポンダーとスクライブは交代するルールでしたが、インシデントコマンダーは交代なしだったので、私は最後まで指揮とステークホルダー対応を担当しました。

予想外の連続！コンテスト体験記

当初は「AWS Game Day のPagerDuty版」のような内容を想像していましたが、実際に参加してみると、単なる模倣ではなく、PagerDutyならではの工夫が随所に凝らされていました。

開始前は「コンテストが始まったら、自分たちのPagerDutyサービスにインシデントが自動で起票されて、それをトリガーに対応を進めるのだろう」と漠然と考えていました。しかし、実際に始まってみると、一向にPagerDutyにインシデントが登録されません。

5分ほど経過した頃、ようやく動きがあったのはGitHub。管理しているサンプルアプリ(ペイジーチャットJ)に対して、明らかに不審な修正内容のプルリクエスト(PR)が作成されました。これが最初のインシデントのきっかけでした。が、、このPRが原因でアプリケーションの挙動がおかしくなっていることにすぐには気づけませんでした。アプリそのものの動作を確認していなかったのと、監視の仕組みがどう連携しているのか掴めなかったためです。しかしながら、PRの変更内容自体が不適切だと判断して(タイポや明らかに不要な修正があった)Revertしました。結果的にこれがアプリケーションのエラーを解消することにつながりましたが、先述のとおり挙動がおかしくなったと思われるタイミングで動作確認してなかったので、修正できたのかどうか比較する方法がなく(CloudWatchは使えず、ログもない)、現在の正常な状態をもって「インシデント対応完了」と報告せざるをえませんでした。

このように、コンテスト中には全部で3件のインシデントが発生しましたが、単純なシステム障害だけでなく、PagerDutyのスタッフさんが演じる「CTO」や「カスタマーサポート担当者」、「隣のチームの人」といったステークホルダーから、チャットや時には直接（！）高い温度感で状況説明を求められたり、対応方針について詰められたりする場面もありました。

インシデントコマンダーだった私は直接サーバーを触ることは少なかったので、レスポンダー（後藤田さん、村上さん）と連携して状況を把握したり、ステークホルダーへの説明にあたりました。スクライブ（村上さん、後藤田さん）は、その間の対応記録をPagerDutyインシデントの「Notes」やSlackに残していく必要があり、チーム一丸となった対応が求められました。

結果と学び

最終的に私たちTeam B（アイレット）は 62点を獲得し、4位 という結果でした。

コンテストの趣旨や全体の流れを素早く掴めず、特に最初のインシデント対応では戸惑いが大きく、初動が遅れてしまったのが悔やまれます。もっと早く「これは単なる技術チャレンジではなく、コミュニケーションや状況判断が重要」と気づけていれば、もう少し違った結果になったかもしれません。

しかし、この経験を通じて、

• インシデント発生の多様性（システム起因だけではなく、アプリ修正(PR)からCI/CDを通じての障害発生等）
• 技術的な対応と並行して行うステークホルダーとのコミュニケーションの重要性
• 限られた時間と情報の中で判断を下す難しさ
• PagerDutyを使ったインシデント管理プロセスの実践（ステータス更新、Notes活用、事後レビュー）
• チーム内での役割分担と連携のスムーズさ

などなど、普段の業務にも直結する多くの学びを得ることができました。私のインシデントコマンダーとして全体を俯瞰し、指示を出しながら外部とのコミュニケーションも担うという経験は、たびたび慌てながらも大変有意義で心に残るものでした。

おわりに

PagerDuty Challenge Cup は、単にPagerDutyの機能を学ぶだけでなく、インシデント対応における総合的なスキルを試される、非常にエキサイティングで学びの多いイベントでした。主催のPagerDuty社の皆様、特に企画担当の草間様（Jacopenさん）、そして当日熱演（？）してくださったステークホルダー役のスタッフの皆様、素晴らしい機会をありがとうございました。

今回得た経験と反省点を、今後の業務改善に活かしていきたいと思います。