after-action-report

事後レビュー

リリース、インシデント、完了したプロジェクトを体系的に振り返ります。文書を作るだけでなく、実行可能な教訓を導き出します。

このスキルは、事後分析に使用します。進行中のインシデント対応には incident-response を、リリースの計画には launch-runbook を使用してください。

---

使用するタイミング

• インシデント発生後（重大度を問いません）
• 重要なリリースのたびに
• プロジェクトの終了時（スプリントの振り返り、四半期ごとの振り返り、プロジェクトの完了時）
• 繰り返し発生する問題について、調査が必要なほど発生したとき
• ある判断が期待どおりの結果にならず、チームがそこから学びたいとき

使用しないタイミング

• インシデント対応中（incident-response を使用してください）
• リリース前の計画時（launch-runbook を使用してください）
• 広範な分析を必要としない、単発のバグ修正

---

必要な入力

• 分析対象の出来事（インシデント、リリース、プロジェクト）
• ログ、チャット、チケットをもとに再構成したタイムライン
• 参加者が観察したこと、実行したことについての説明
• 結果と影響（ユーザーやビジネスに実際に何が起きたか）

---

フレームワーク：責任を問わない分析

最も重要な原則は、誰かを責めないことです。これがなければ、振り返りでは情報が隠され、実効性のある教訓ではなく、見せかけの教訓が生まれます。

誰かを責めないとは

• 個人ではなく、システムに注目します
• その時点で各自が知っていた情報を前提に、全員が妥当な判断をしたと考えます
• 問うべきなのは「誰が失敗したのか？」ではなく、「なぜこの判断は妥当だったのか？」です
• システムを修正することで、同じ状況に置かれた次の人が、今回はできなかったことをできるようにします

誰かを責めないことが意味しないもの

• 説明責任がないこと（アクションアイテムには引き続き担当者を割り当てます）
• 厳しい事実を避けること（システムに明らかな問題がある場合もあります）
• 基準がないこと（失敗のパターンによっては、システムではなく個人に起因することもあります）
• 不快さがないこと（真剣な振り返りには不快さが伴います）

---

フレームワーク：6 つのセクション

AAR は、次の 6 つのセクションで構成されます。

1. 概要

2～3 段落で全体像をまとめます。次の内容を含めます。

• 何が起きたか
• 影響（ユーザー、ビジネス、時間）
• 根本原因（平易な言葉で）
• 主要なアクションアイテム

経営陣が読むのはこの部分です。このセクションだけを読んだ人にも、最も重要な情報が伝わるようにします。

2. タイムライン

出来事の時系列を再構成します。

インシデントの場合：

• T-0：検知
• T+X：確認
• T+Y：重大度の評価、IC の任命
• T+Z：調査開始
• …緩和、連絡、解決に関する出来事
• T+N：解決を宣言

リリースの場合：

• リリース前の判断とマイルストーン
• リリース当日の出来事
• リリース後の監視での観察事項

プロジェクトの場合：

• 主要なマイルストーン、判断、方向転換
• 計画されたものと、途中で生じたものの両方

タイムラインが信頼できる唯一の情報源です。何が起きたかについて意見が食い違う場合は、ここで解決します。

3. 根本原因分析

何が原因だったのかを、平易な言葉で説明します。

次のいずれか、または両方を使います。

なぜなぜ分析。 表面的な症状から始め、「なぜ？」と問いかけます。5 回繰り返すか、真の根本原因にたどり着くまで続けます。それぞれの「なぜ？」には、同語反復ではなく、実質的な回答が必要です。

例：

• なぜサイトがダウンしたのか？データベースの接続プールが枯渇した。
• なぜ接続プールが枯渇したのか？バックグラウンドジョブが接続を開きすぎた。
• なぜバックグラウンドジョブが接続を開きすぎたのか？エラー発生時に接続をクリーンアップするコードが実行されなかった。
• なぜエラー発生時にクリーンアップが実行されなかったのか？当初のコードレビューでエラー経路を確認していなかった。
• なぜレビューでエラー経路を確認しなかったのか？レビューのプロセスにエラー処理のチェックリストがなかった。

5 つ目の「なぜ？」から、システムを改善する方法が見えてくることがよくあります。この場合は、レビューのプロセスを改善します。

因果関係の連鎖。 複数の要因が組み合わさって起きたことを示します。

• 要因 1：バックグラウンドジョブが接続を開きすぎた（技術）
• 要因 2：実際のトラフィックに対して接続数の上限が低すぎた（設定）
• 要因 3：接続プールの飽和を知らせるアラートがなかった（監視）
• 要因 4：インフラのキャパシティレビューなしに、直近のトラフィックが 2 倍になった（プロセス）

単一の修正ではインシデントに対処できません。複数の不備に対処する必要があります。

4. 寄与要因

事象の原因ではないものの、状況を悪化させたり、事象を検知できたはずの安全策を機能しなくした要因です。

• 監視の不備
• ドキュメントの不備
• プロセスの不備
• ツールの不備
• 知識の不足

「もし〜であれば、もっと早く検知できていた」という要因です。

5. うまくいったこと

真の教訓を得るには、失敗だけでなく、成功も記録する必要があります。

• どの検知が機能しましたか？
• どの対応が機能しましたか？
• どの判断が適切でしたか？
• どのツールやプロセスが期待どおりに機能しましたか？

これは慰めではありません。適切な評価です。今回うまくいったことは、強化し、再現すべきです。

6. アクションアイテム

具体的で、担当者と期限が明確なものにします。

アクション	担当者	期限	種類
接続プールの飽和に対するアラートを追加する	[name]	[date]	監視
PR テンプレートにエラーハンドリングのチェックリストを追加する	[name]	[date]	プロセス
同様の問題がないか、ほかのバックグラウンドジョブを監査する	[name]	[date]	コード

アクションアイテムの基準：

• 具体的であること。 「監視を改善する」では実行可能ではありません。「接続プールの飽和に対するアラートを追加し、しきい値を 80％に設定して、オンコール担当者に通知する」のようにします。
• 担当者がいること。 氏名を記載します。「チーム」ではいけません。
• 期限があること。 実際の日付を記載します。「近日中」ではいけません。
• 規模が明確であること。 工数の目安を時間、日、週で示します。
• 完了条件が明確であること。 完了の定義を明確にします。

合意した期間内に完了しなかったアクションアイテムは、次回の AAR で再度取り上げます。未完了のアクションが繰り返される場合は、より深刻な組織上の問題が示唆されます。

---

ワークフロー

1. AAR を予定する

事象から 1〜2 週間以内に行います。感情が落ち着き、事実が集まる程度に時間を置きつつ、記憶が新しいうちに実施します。

インシデントの場合：対応手順であらかじめ決めておきます。 ローンチの場合：ランブックに予定を記載します。 プロジェクトの場合：プロジェクトの完了時に予定します。

2. 情報を集める

会議の前に、以下を用意します。

• 再構成したタイムライン（記録係がいた場合は、そのメモを使うことがよくあります）
• ログ、チャットの記録、チケット、インシデントの更新情報
• 各参加者の個別の説明（会議の前に書面で作成）
• 影響データ（影響を受けたユーザー数、継続時間、売上への影響など）

3. 会議を実施する

一般的な議題（60〜90 分）：

• 作成した概要を読む（5 分）
• タイムラインを全員で確認する。修正を加え、意見の食い違いを解消する。（20〜30 分）
• 根本原因について話し合う。5 つのなぜ、または因果関係の連鎖を使う。（15〜20 分）
• 寄与要因について話し合う。（10 分）
• うまくいったことについて話し合う。（10 分）
• アクションアイテムを特定する。担当者と期限を決める。（10 分）

会議の進行役を置きます。インシデントの場合は IC、プロジェクトの場合はプロジェクトリードが務めることがよくあります。進行役は記録係ではありません。

4. ドキュメントを作成する

会議から数日以内に作成します。AAR 全文には、6 つのセクションすべてを含めます。

5. 共有する

社内では、既知の場所に投稿します。検索可能にし、オンボーディング時に参照できるようにします。

重大度の高いインシデントでは、社外向けの概要を公開するのが適切な場合があります（ステータスページ、顧客向けメール、公開ブログなど）。

6. アクションアイテムを追跡する

すべてのアクションアイテムを、完了まで追跡します。次回の AAR で未完了の項目を再度取り上げます。

---

失敗につながるパターン

• 「小さな」インシデントの AAR を省略する。 パターンを見落とします。
• 個人を名指しで責める。 非難を恐れると、本当の教訓が隠されます。
• 一般的すぎるアクションアイテム。 具体的なテストの変更ではなく、「テストを改善する」とすること。
• 完了しないアクションアイテム。 登録されても忘れられ、同じインシデントが再発します。
• 形だけの振り返り。 本気で考えず、形式的に進めること。
• 「うまくいったこと」を省略する。 何が機能しているかを適切に評価できなくなります。
• 責任を外部に押し付ける。 「ベンダーが失敗した」で終わらせず、ベンダーリスクに対応する自社の仕組みを考えます。
• 一人だけで AAR を作成する。 一人がすべてを書き、ほかの視点を見落とします。
• 失敗の場合にしか AAR を行わない。 成功したローンチにも AAR が必要です。成功から得られる教訓にも価値があります。
• 先延ばしにする。 記憶は薄れ、話し合いの熱も冷めます。2 週間以内に完了させます。

---

出力形式

aar-[date]-[event-name].md に保存する Markdown ドキュメントです。

構成：

# AAR: [Event name]

**Date of event:** [YYYY-MM-DD]
**AAR date:** [YYYY-MM-DD]
**Severity / scope:** [SEV-1 / Major launch / Project closeout]
**Facilitator:** [Name]
**Participants:** [Names]

## Summary
[2 to 3 paragraphs]

## Impact
- Users affected: [number, segment]
- Duration: [time]
- Revenue / business impact: [if applicable]

## Timeline
[Timestamped events]

## Root cause analysis
[Five whys or causal chain]

## Contributing factors
[List]

## What went well
[List]

## Action items
| Action | Owner | Due | Type | Status |
|---|---|---|---|---|
| | | | | |

## Lessons
[Reflections that don't fit elsewhere. Often the most quotable section.]

---

必要なデータを利用できない場合

このスキルの出力は、スキル自体では生成できないデータ、測定値、またはツールの結果に依存します。必須の入力、ツール、またはデータソースを利用できない、あるいは検証できない場合に認められる出力は、その不足を明記した成果物です。つまり、何が必要だったのか、実際に何を取得または検証できたのか、出力のどの部分に影響するのかを記載します。成果物を完成させるために必須の数値を捏造、推定、または補間することは、決して認められません。不足を明記すれば、それだけで完全な回答です。

---

参考ファイル

• references/aar-template.md - インシデント、ローンチ、プロジェクトを対象とした記入式の AAR テンプレート。