重大インシデント後のポストモーテムを設計する――ゲーム開発チームのための事後検証と学習の方法論

オンラインゲームのサーバーが落ちる。配布したアップデートに重大なバグが混入する。アイテム調整やイベント設計がプレイヤーの期待を大きく外し、炎上する。アイテムなどを不正に複製するデュープによってゲーム内経済が壊れる。アカウント情報や個人情報に関わるセキュリティインシデントが起きる。

重大な事象が起きた直後、チームはまず復旧、告知、問い合わせ対応、補償、再発防止の暫定策に追われる。その後に必要になるのが、ポストモーテムである。ここでいうポストモーテムとは、重大インシデントの後に、何が起き、どのような影響があり、なぜその状況が生まれ、次に何を変えるかを、複数の視点から検証する一回性の振り返りである。

これは、スプリントの終わりに定期開催する KPT（Keep、Problem、Try）などの振り返り会とは目的が違う。ポストモーテムは、普段の仕事を少しずつ改善する場ではなく、通常の運用から大きく外れた事象を、組織の学習資産へ変換する場である。

本稿では、ゲーム開発チームがポストモーテムをブレームレスに設計し、事実を再構築し、アクションアイテムを実行まで追跡する方法を整理する。個別タイトルの失敗史やサービス終了の設計を詳しく扱うものではない。焦点は、重大事象の後に行うプロセスそのものに置く。

スプリントの振り返りとポストモーテムは何が違うのか

スプリントレトロスペクティブは、チームが一定期間ごとに仕事の進め方を検査し、品質と有効性を高める方法を計画するイベントである。Scrum Guide の説明でも、個人、相互作用、プロセス、ツール、完成の定義などを対象に、次のスプリントで実施する改善を決めるものとされている。[1] KPT は、そこに使える手法の一つである。

一方、ポストモーテムの起点は「スプリントが終わったこと」ではなく、「重大な望ましくない結果が発生したこと」である。Google SRE では、一定以上の利用者影響、データ損失、ロールバックなどの介入、解決時間の超過、監視が機能しなかった事象などを、ポストモーテムの契機として例示している。[2]

両者は対立しない。ポストモーテムで見つかった改善を、次のスプリントやバックログへ流し込むことはできる。ただし、重大事象を KPT の三列だけに押し込むと、影響範囲や意思決定の経緯、複数チームにまたがる要因が抜け落ちやすい。

ブレームレスは「責任をなくす」ことではない

「ブレームレス（blameless）」は、直訳すれば「非難しない」という意味である。重大事象の後に、結果を知った後から個人を責めるのではなく、その時点での情報、制約、判断、仕組みを調べ、再発防止につなげる考え方を指す。ただし、故意の不正や隠蔽まで責任を問わないという意味ではない。

事故調査から学ぶべきなのは、犯人ではなく条件である

米国の航空事故調査では、事故の事実、発生条件、推定原因、安全勧告を分けて扱う考え方が制度化されている。米国の NTSB は、調査の目的を事故に関係する事実や条件を明らかにし、推定原因を決定し、同様の事故を防ぐ勧告を出すことと説明している。また、調査は個人や組織の権利、責任、過失を決める目的ではないとしている。[3]

これはゲーム開発にそのまま法的制度として移植する話ではない。しかし、重大インシデントの調査で「誰が悪いか」と「何が起きたか」を最初から混ぜない、という原則は参考になる。航空業界で使われる Just Culture（公正な文化）は、正直なミスや報告を罰しない一方、故意の違反や無謀な行為まで免責する考え方ではない。FAA も、非難に偏らない協調的な問題解決と、根底にある安全上の問題を修正する必要性を説明している。[4]

ゲームチームでのブレームレスとは、次のような意味である。

• 対応時点で担当者が持っていた情報、制約、期待、判断基準を記録する
• 個人の性格や能力ではなく、判断を生んだ状況と仕組みを調べる
• 正直に話しても、意図しない結果だけを理由に処罰されないという前提を置く
• 故意の不正、隠蔽、重大な規程違反、安全上の無謀な行為は、別の責任管理の手続で扱う

「ブレームレスだから責任者を置かない」のではない。むしろ、改善策を実装する責任者、期限、検証方法を明確にすることで、個人攻撃をせずに組織の責任を具体化する。

NASAは物理的な故障だけでなく、管理と組織の文脈を調べた

NASAの事故調査は、重大な失敗を単一部品の故障へ還元しない事例として参照される。コロンビア号事故調査委員会は、物理的な損傷だけでなく、予算、歴史、組織文化、管理慣行、優先順位の変化を事故の文脈に含めた。NASAの公式説明でも、事故の物理的原因と同時に、スペースシャトル計画を監督した管理慣行が原因の一部だったと整理されている。[5]

NASAの一般的なミッション事故調査でも、調査委員会は何が起きたか、根本原因は何か、再発を防ぐために何を勧告するかを扱い、是正措置の計画まで確認する役割を持つ。報告書は公平、独立、非懲罰的な調査過程であることを確認する仕組みを備えている。[6]

ゲーム開発へ置き換えるなら、「報酬テーブルの値を間違えた」で止めないことが重要になる。なぜその値が本番へ入り、誰も止められず、プレイヤーへの影響が広がったのかを、データ入力、レビュー、権限、リリース時刻、監視、告知、補償判断まで追う必要がある。

EtsyとGoogleがソフトウェア開発へ運用可能な形を持ち込んだ

Etsyは2012年の公式記事で、事故に関与したエンジニアが、自分の行動、観測した結果、想定、前提、出来事の理解を、処罰を恐れずに詳しく話せることをブレームレスなポストモーテムの条件として説明した。人間のミスを個人の欠陥として扱う「最初の物語」から、なぜその判断が当時は合理的に見えたのかという「第二の物語」へ視点を移す考え方である。[7]

さらにEtsyは、事後検証を進行するためのファシリテーションガイドを公開し、ポストモーテムを「修理の会議」より先に「学習の機会」として扱う必要を述べている。すでに決めた単一の根本原因へ会話を急いで収束させると、複数の視点を失い、理解したつもりになる危険がある。[8]

Google SREは、ブレームレスなポストモーテムを文化論だけでなく、記録、共有、アクションアイテムの追跡まで含む運用として整理している。重大事象を記録し、影響と原因を理解し、再発の可能性や影響を下げる予防策を実装することが目的である。アクションアイテムには担当者、優先度、追跡番号、検証できる完了条件を持たせ、チームのバックログへ戻す。[9]

重大インシデントの判定を先に決める

「何でもポストモーテムにする」運用は、調査の質を下げる。逆に、誰かが強く要求したときだけ開催すると、組織の権力関係に左右される。事前に開催条件を決め、客観的なトリガーと、関係者が要求できる例外を併用する。

ゲーム開発で設定しやすいトリガーは次の通りである。

• 一定時間以上、ログイン、マッチング、課金、セーブなどの主要機能が使えなかった
• キャラクター、アイテム、進行、課金残高などのデータが失われた、巻き戻った、または不整合になった
• デュープ、チート、脆弱性悪用などにより、ゲーム内経済や競争の公平性が損なわれた
• 大量のプレイヤーに影響する重大バグがリリース後に判明した
• 個人情報、認証情報、決済情報、社内機密などへの不正アクセスが疑われる
• アイテム調整、イベント、補償、告知などの意思決定が、予想外の大規模な反発や信頼低下を招いた
• 対応の途中でロールバック、緊急メンテナンス、販売停止、告知訂正などの重大な介入が必要になった
• 復旧はできたが、同じ条件で再発する可能性が高い、または重大事故には至らなかったが条件が近かったニアミスだった

セキュリティや法務が関わる事案では、通常のチーム共有と同じ資料をそのまま配布してはならない。証拠保全、アクセス権、個人情報、脆弱性情報、外部公表の可否を、セキュリティ担当や法務と分けて設計する。ブレームレスは、機密管理をなくす合言葉ではない。

標準的なポストモーテムの構造

1. 開催前に、目的と安全条件を固定する

進行役は、インシデント対応の責任者と同じでなくてよい。対応中に判断を担った人が、そのまま自分の判断を評価する立場になると、見落としを認めにくくなる場合がある。少なくとも、次を事前に明記する。

• この会議は処罰や人事評価のためではなく、再発防止のための学習である
• 事実と解釈を分け、分からないことは「未確認」と書く
• 個人名を責める表現や、結果を知った後からの人格評価を使わない
• 故意の不正やハラスメントなど、別手続で扱う論点の入口を示す
• 参加者、記録の閲覧範囲、公開版と内部版の分離を決める

参加者は「関係者全員」では多すぎる場合がある。対応担当だけでなく、プレイヤー影響を説明できるCS、リリースやQAの担当、ゲームデータや経済を理解するプランナー、監視やインフラの担当、必要に応じてセキュリティ、法務、広報、意思決定者を含める。沈黙しやすい立場の人から事前に個別ヒアリングする方法も有効である。

2. タイムラインを再構築する

最初に原因を議論すると、参加者は自分の専門領域に引っ張られる。まず「いつ、何が観測され、誰が何を知り、どの判断をしたか」を並べる。

タイムラインの材料は、監視ログだけではない。チャット、チケット、プルリクエスト、リリースノート、管理画面の操作履歴、CSの問い合わせ、SNSへの公式投稿、会議メモ、意思決定の承認記録を突き合わせる。記憶に頼った「その時はこうだった」は仮説として扱い、証拠で補強する。

時刻の正確さが取れない場合は、分単位を装わない。「午前のメンテナンス後」「告知直後」のように不確実性を明記する方が、誤った精密さより安全である。

3. 影響範囲をプレイヤーの体験で記述する

「サーバー障害が発生した」だけでは不十分である。どの地域、プラットフォーム、バージョン、機能、プレイヤー状態、ゲーム内資産、売上、サポート窓口に、どのような影響が出たかを分ける。

• 利用不能：ログイン、マッチング、購入、受け取り、セーブができない
• データ影響：進行、所持品、ランキング、課金残高、フレンド情報が不整合になる
• 公平性影響：一部のプレイヤーだけが報酬、通貨、ランキング上の利益を得る
• 信頼影響：説明の訂正、補償の不公平感、事実と告知の食い違いが生じる
• 組織影響：長時間の対応、次のリリース延期、CSや広報の負荷、契約・法務対応が発生する

影響は確定値と推定値を分ける。数字を確定できないときは、範囲、集計条件、欠測、更新時刻を併記する。弱い数字を迫力のある数字へ加工してはならない。

4. 直接原因、寄与要因、背景要因を分ける

直接原因とは、結果の直前に起きた技術的・運用的な出来事である。根本原因とは、そこだけを直しても同じ種類の事故を防げない、より上流の条件を指す。実際には原因は一本の鎖ではなく、複数の条件が重なった因果の網になる。

たとえば、イベント報酬が重複配布された場合、次のように分けられる。

• 直接原因：報酬付与の再実行時に、同じ受け取り処理が二重に通った
• 寄与要因：再実行を検知する一意制約がなく、管理画面に処理済み状態が表示されなかった
• 背景要因：イベント開始前の負荷試験が通常報酬だけで、再接続・タイムアウト・再送を含んでいなかった
• 組織要因：経済影響を受けるデータ変更に、プランナー、エンジニア、QA、CSが同席する承認手順がなかった

5 Whys（なぜを繰り返して原因を深掘りする方法）は、原因を掘る入口として使える。ただし「5回聞けば唯一の根本原因に到達する」技法ではない。根本原因分析の手法を比較した資料でも、5という回数は固定的な基準ではなく、それ以上有用な答えが得られなくなるまで掘る方法として説明されている。[10]

「担当者が確認を忘れた」で止めず、「なぜ、その確認をしない判断が当時は成立したのか」を問う。仕様変更の通知が届かなかった、レビュー期限が短かった、権限が過剰だった、監視が結果ではなくCPUだけを見ていた、といった条件が見えてくる。

5. 対応の良し悪しと、設計の問題を別々に見る

事故が起きたことと、事故にどう対応したかは別の分析対象である。対応中の判断には、次の視点がある。

• 検知は早かったか。検知できなかったなら、どの観測が不足していたか
• 指揮系統と承認者は明確だったか
• ロールバック、販売停止、ログイン停止などの操作は安全に実行できたか
• プレイヤー向けの告知は、分かっていることと分からないことを分けていたか
• CS、広報、法務、セキュリティ、開発の情報が同期していたか
• 復旧後に再発や二次被害がないことを確認したか

初動が遅かったという結果だけを見て、「もっと早く動くべきだった」と書くのは、アクションになっていない。誰が、どの条件で、どの判断をするかを、ランブック（障害時の対応手順書）、権限、監視、演習、通知経路へ落とす。

6. アクションアイテムを仕事へ変換する

「注意する」「テストを増やす」「連携を強化する」は、完了を確認できない。Google SREが示す良いポストモーテムでは、アクションアイテムに担当者、優先度、追跡番号、検証可能な完了条件があり、再発防止、影響軽減、検知改善などのテーマに分けられている。[11]

アクションの数を増やすことが目的ではない。最も大きな再発確率や影響を下げる変更を優先する。人の注意力だけに依存する訓練より、自動停止、権限分離、同じ要求を繰り返しても結果が重複しない冪等性、一意制約、段階配信、可逆的な設定変更、監視の改善の方が、条件が変わっても効きやすい。

ゲーム業界で公開された事後分析から学ぶ

ゲーム会社が、内部のポストモーテム全文を、タイムライン、影響、原因、アクションアイテムまで公開する例は、SRE企業の公開資料ほど多くない。公開されるのは、プレイヤー向けの障害説明、公式ブログによる事後分析、またはGDCでの運用共有である。したがって、以下では「完全な内部報告書」と「事後検証に相当する公開資料」を区別して読む。

Guild Wars 2：復旧後に環境差と監視の穴を掘り下げた

ArenaNetは2021年、Guild Wars 2の大規模障害について、プラットフォームチームのリードによる公式のライブゲーム障害分析を公開した。記事によれば、2020年5月にデータベースがロールバックし、プレイヤーに不整合な情報が表示されたため、欧州リージョンのログインを停止し、データを正常な状態へ戻す必要が生じた。[12]

この事例の価値は、復旧手順だけで終わらず、復旧後に根本原因を調べ、開発環境とライブ環境の差を学びとして整理した点にある。サーバー更新後のドライバーとストレージの組み合わせが、高負荷のライブ環境で問題を起こし、開発環境では再現しなかった。ArenaNetは、データベースの重要なメトリクスへのアラートを増やし、ライブ運用の通知を改善し、インフラの記録にインスタンス種別だけでなく世代、ドライバー、ストレージ種別を含める変更を挙げている。[13]

ゲームプランナーが読むべき点は、技術的なドライバーの詳細ではない。「テスト環境で問題が起きなかった」という事実を、安心材料ではなく、環境差を検査する問いへ変えたことである。ゲーム側でも、イベントの本番データ、プレイヤー密度、復帰ユーザー、再接続、キャンペーン流入など、開発環境に存在しない条件をタイムラインと影響分析へ入れる必要がある。

画像引用（無改変）: Inside ArenaNet: Live Game Outage Analysis（ArenaNet公式、2021年7月15日公開）

ファイナルファンタジーXIV: 暁月のフィナーレ――障害の原因、暫定策、復旧手順を段階的に説明した

『ファイナルファンタジーXIV: 暁月のフィナーレ』の早期アクセスでは、ログイン上限とワールド間の移動負荷が高まり、ワールドが停止する事象が起きた。公式説明は、ワールド停止の理由として、各ワールドのログイン上限に達した状態で、同時にエリア移動するキャラクター数が非常に多くなり、ネットワーク負荷が高まったことを挙げている。対策として同時移動数や瞬間的なネットワーク負荷を制限し、停止時には原因の特定、負荷を下げる対策、再起動、GMによるログイン確認、再開という手順を示した。[14]

後続の公式説明では、ログインキュー中のエラーが一部ユーザーを列の末尾へ戻してしまう条件、ロビーサーバーの容量改善、将来的なワールド増設の必要性、ハードウェア調達の制約まで説明している。[15]

これは、社内向けポストモーテム全文ではない。しかし、プレイヤー向けの説明であっても、症状、原因、暫定策、復旧手順、根本対策の制約を段階的に出している。ゲームチームが公開版の事後報告を書く場合にも、原因を断定できない時点では暫定説明とし、後から判明した事実を更新履歴付きで追加する構造が参考になる。

Path of Exile：技術障害と運用上の判断ミスを同じ事後説明で扱った

Grinding Gear Gamesは2021年、Path of ExileのUltimatumリーグ開始時に、ログインキューが極端に遅くなった問題と、配信者にキューの優先権を与えた判断について、公式フォーラムで説明した。技術面では、ログイン時のキャラクター移行処理がオンデマンドで実行され、キュー処理に想定以上の時間がかかったと説明している。[16]

同じ投稿は、障害対応中に配信者のキューを飛ばす判断をしたことを明確に誤りと認め、今後はその扱いを行わないこと、マーケティング施策を将来の負荷に合わせて計画することを示した。ここでは、サーバーの技術原因だけでなく、プレイヤーが公平な開始を期待するゲーム運営上の約束と、広報施策の設計が同時に検証されている。

この事例は、炎上を「コミュニティが過敏だった」と片付けず、運用上の意思決定がどの期待を破ったかまで扱う例である。ゲームプランナーは、技術ログに加えて、イベント告知、販売条件、配信施策、プレイヤーへ約束した公平性を同じタイムラインへ置く必要がある。

BungieのGDC資料：重大度に応じて事後分析の深さを変える

BungieのDestiny 2運用を扱ったGDC 2024の講演概要は、影響と緊急度で対応順を決めるトリアージ、監視当番、対応レベル、通常のリリースを待たない緊急修正であるホットフィックスなどを扱うものだった。[17] 公開された講演資料では、キャラクターデータ消失や広範囲の接続断をCritical、進行不能や深刻なエクスプロイトをUrgentなどに分け、Criticalでは復旧と並行してチーム横断の根本原因分析を行い、Urgentでは機能チームのポストモーテムを行う運用例が示されている。[18]

これは、すべての不具合に同じ重さの調査を要求しない設計として参考になる。ゲームの重大度分類はタイトルごとに変わるが、「プレイヤー影響」「データや公平性への影響」「即時対応の必要性」「事後分析の深さ」をあらかじめ対応表にしておくと、発生時の議論を短くできる。

ポストモーテムが機能しなくなる失敗パターン

犯人探しへ変わる

「誰がマージしたか」「誰が承認したか」だけを追うと、個人名は見つかっても、同じ条件を別の人が繰り返す可能性は残る。人の行動は必要な事実として記録するが、人格評価ではなく、情報、権限、時間、通知、手順、期待、環境を併記する。

5 Whysが単一原因を作る儀式になる

因果が分岐しているのに、五回の「なぜ」で一本の答えへまとめると、監視、経済設計、QA、意思決定、コミュニケーションの要因が落ちる。必要なら、因果の木や複数の仮説を並べ、確定、可能性が高い、未確認を区別する。

アクションアイテムが精神論になる

「確認を徹底する」「連携を強化する」「気をつける」は、担当者も完了条件もない。自動検知、承認権限、段階配信、ロールバック、データの一意性、監査ログなど、仕組みの変更へ変換する。

実施が遅れ、記憶が結果に書き換えられる

Google SREは、ポストモーテムを早く書くほど記憶が新しく、説明の空白を憶測で埋められにくいと説明している。[19] ただし、復旧直後の担当者が疲弊している場合は、証拠保全と短い一次聞き取りを先に行い、正式な会議を適切な時期に置く。早さと回復の両方を設計する。

報告書を公開して終わる

公開記事が丁寧でも、アクションがバックログに入らず、次のリリースで優先順位を失えば学習にならない。定例の進捗確認、責任者による障害物の除去、完了条件の検証、再発時の効果測定までをポストモーテムの範囲に含める。

セキュリティとブレームレスを混同する

セキュリティ侵害では、調査中の脆弱性や個人情報を広く共有できない場合がある。一方で、秘密にすることと、個人を責めることは別問題である。アクセス範囲を制御した内部報告、経営・法務向けの記録、プレイヤー向けの公表、再発防止の技術チケットを分け、必要な学習を失わないようにする。

ゲームプランナーが担える実務

プランナーは、インフラのログを直接修正できなくても、ポストモーテムの質を左右する情報を持っている。とくに重大バグ、経済系エクスプロイト、イベント炎上では、仕様とプレイヤー体験の接続を説明できる人が必要である。

タイムラインを作る

仕様書、データ表、チケット、レビューコメント、告知、CSの問い合わせ、ゲーム内の変更履歴を、時系列に並べる。「仕様が存在した時刻」「最終変更時刻」「承認された時刻」「本番へ反映された時刻」「プレイヤーが影響を受けた時刻」を分けるだけでも、議論は具体的になる。

意思決定を条件付きで記録する

「イベントを予定どおり開始した」ではなく、「同時接続数がこの範囲なら開始できると判断し、未確認だったのは再接続時の報酬重複だった」と書く。結果を知った後からは愚かに見える判断でも、その時点の制約と期待が分かれば、次の判断基準を改善できる。

影響をゲームの状態で説明する

サーバーのエラー率だけでなく、ログイン済み、マッチ中、報酬受け取り前、課金直後、ロールバック対象、ランキング確定済みなど、プレイヤーの状態を分ける。補償や巻き戻しの設計では、この状態の違いが公平性を左右する。

アクションをバックログへ接続する

アクションアイテムは、ポストモーテム文書の中だけに置かない。ゲーム仕様、データ基盤、QA計画、リリース手順、CS FAQ、監視、権限設定など、実際に変更される場所へチケットを作る。プランナーは、影響を受けるユーザー状態、受け入れ条件、次回イベント前に必要な検証を記述できる。

完了ではなく効果を確認する

「一意制約を入れた」ことと、「同じ種類の二重処理を防げる」ことは同じではない。合成データ、負荷試験、再接続、タイムアウト、ロールバック、権限のない操作を含むテストを行い、アクションが想定したリスクを本当に下げたか確認する。

進行に使える最小テンプレート

重大インシデントの種類ごとに様式を増やす前に、次の最小構成から始めるとよい。

1. 概要：何が起き、いつ収束し、誰がどの機能に影響を受けたか
2. 影響：利用不能、データ、公平性、売上、CS、組織負荷の内訳
3. 検知：最初に誰が何を見て知ったか。監視か、プレイヤー報告か
4. タイムライン：観測、判断、行動、告知、復旧、再発確認
5. 対応：うまくいったこと、難しかったこと、偶然助かったこと
6. 原因：直接原因、寄与要因、背景要因、未確認の仮説
7. 学び：次に同じ条件が起きたとき、何を早く検知し、何を安全に止めるか
8. アクション：再発防止、影響軽減、検知改善、運用改善。担当、期限、完了条件、追跡先を持つ
9. 共有：内部版、関係部署版、プレイヤー向け説明の範囲と更新履歴
10. フォローアップ：アクションの進捗、効果、未完了の理由、類似事象への展開

進行役は、会議を「原因を言い当てる場」にしない。参加者が持つ異なる視点を集め、事実の確度を上げ、再発確率や影響を下げる変更へ変換する。優れたポストモーテムは、誰かの反省文ではなく、組織が次により良い判断をできるようにする設計書である。

まとめ

スプリントの振り返りは、定期的にチームの仕事を改善する場である。ポストモーテムは、重大な障害、重大バグ、エクスプロイト、炎上、セキュリティインシデントなど、一回性の重大事象を対象に、事実、影響、対応、原因、再発防止を深く検証する場である。

ブレームレスとは、責任を消すことでも、故意の不正を見逃すことでもない。結果を知った後から個人を裁くのではなく、その時点での情報、制約、判断、仕組みを調べ、改善を実装する責任を明確にする考え方である。

ゲーム開発では、技術障害だけでなく、経済の公平性、イベントへの期待、告知との整合、CS対応、セキュリティ、運営上の約束までが同じ事象に含まれる。だからこそ、タイムラインと影響範囲をゲームの状態で整理し、直接原因と背景要因を分け、アクションアイテムをバックログへ戻し、効果を確認する必要がある。

最終的な成果は、立派な報告書ではない。次に同じ種類の異常が起きたとき、より早く気づき、より安全に止め、より正確に説明し、プレイヤーへの影響を小さくできることである。

References

1. The Scrum Guide - Scrum Teamがスプリントレトロスペクティブで品質と有効性を高める方法を計画することを説明した公式ガイド。

2. Postmortem Culture: Learning from Failure - Google SREが重大事象のポストモーテムの契機、目的、ブレームレス文化を説明した公式資料。

3. The Investigative Process - NTSBが事故調査の事実収集、原因分析、最終報告、安全勧告を説明した公式資料。

4. Compliance Program - FAAが非難に偏らない問題解決、Just Culture、根本原因の是正を説明した公式資料。

5. Columbia Accident Investigation Board Report - NASAのコロンビア号事故調査委員会報告書の公式記録。

6. NPR 8621.1 NASA Procedures and Guidelines for Mishap Reporting, Investigating, and Recordkeeping - NASAの事故・ニアミス調査、報告、是正措置に関する手続資料。

7. Blameless PostMortems and a Just Culture - Etsyの公式エンジニアリング記事。ブレームレスな事後検証、第二の物語、状況要因を説明する。

8. Etsy’s Debriefing Facilitation Guide for Blameless Postmortems - Etsyが公開した事後検証の進行ガイドと、その背景説明。

9. Postmortem Practices for Incident Management - Google SRE Workbookのポストモーテム実践、共有、アクションアイテム、組織学習に関する資料。

10. Root Cause Analysis Compared - NASAケネディ宇宙センターの信頼性工学サイトにホストされている、Dean L. Gano氏による5 Whysを含む根本原因分析手法の比較資料。

11. Postmortem Practices for Incident Management: Why Is This Postmortem Better? - Google SREが、所有者、優先度、追跡番号、完了条件、ブレームレスな記述を良いポストモーテムの特徴として説明する箇所。

12. Inside ArenaNet: Live Game Outage Analysis - ArenaNetがGuild Wars 2の大規模障害と復旧経緯を公式に公開した記事。

13. Inside ArenaNet: Live Game Outage Analysis - Looking Backward and Forward - 同記事の原因分析と、監視、環境差、インフラ記録の改善に関する箇所。

14. Endwalker Congestion and World Status in Early Access - ファイナルファンタジーXIV公式の混雑・ワールド停止に関する原因、暫定策、復旧手順の説明。

15. World Login Errors and Resolutions - ファイナルファンタジーXIV公式のログインエラー、ロビーサーバー、ワールド増設に関する事後説明。

16. Ultimatum Launch: Server Issues and Streamer Priority - Grinding Gear GamesがPath of Exileのリーグ開始時のサーバー問題と運用上の判断を説明した公式フォーラム記事。

17. Live Service Release Planning: Maintaining ‘Destiny 2’ - BungieのDestiny 2運用におけるライブゲーム対応、トリアージ、監視、リリース計画を扱ったGDC講演概要。

18. Live Service Release Planning slide presentation - Bungie講演で公開されたライブゲーム対応レベル、根本原因分析、ポストモーテムの追跡に関するスライド資料。

19. Postmortem Practices for Incident Management: Promptness - Google SREが、事後検証を早く共有することの正確さと説明責任上の利点を説明する箇所。

この文書は、Perplexity、Claude、OpenAI Codex の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。