フレームワーク活用ガイドひとことで言うと#
活動の直後に**「何を期待していたか」「実際に何が起きたか」「なぜ差が生じたか」「次はどうするか」**の4つの問いで振り返る、米軍発のシンプルな学習フレームワーク。
押さえておきたい用語#
- AAR（After Action Review）
- 活動直後に行う構造化された振り返りミーティングのこと。成功・失敗を問わず、あらゆる活動に適用できる。
- 期待と現実のギャップ（Gap）
- 事前に立てた計画や想定と、実際の結果との差分を指す。AARではこのギャップの原因分析が学びの核になる。
- 教訓（Lessons Learned）
- AARを通じて得られた再現可能な知見。個人の感想ではなく、チーム全体で共有・蓄積すべき具体的な行動指針である。
- ファシリテーター（Facilitator）
- AARの進行を担う中立的な司会者のこと。当事者が振り返りに集中できるよう、問いかけと時間管理を行う役割。
アフターアクションレビューの全体像#
こんな悩みに効く#
- プロジェクトが終わるたびに同じ失敗を繰り返している
- 振り返りをやっても「次がんばろう」で終わり、具体的な改善につながらない
- 成功した理由が分からず、たまたまの成功を再現できない
- チーム内で経験や教訓が共有されず、個人の中に閉じている
基本の使い方#
AARは記憶が鮮明なうちに行うのが鉄則。理想は活動終了から24時間以内。
- 参加者は実際にその活動に関わった全員（役職に関係なく）
- 所要時間は15〜30分が目安。長くても45分を超えない
- ファシリテーターを1名決める（当事者でもOKだが、中立に進行できる人が望ましい）
場所は会議室でもオンラインでも構わない。大事なのは「早く集まること」。
以下の4つの問いを、必ずこの順番で進める。
- 何を期待していたか: 当初の目標、計画、想定していた結果を確認する。ここがあいまいだと振り返りが空中戦になる
- 実際に何が起きたか: 事実ベースで、何がうまくいき、何がうまくいかなかったかを共有する。意見や評価ではなく、起きたことだけを話す
- なぜ差が生じたか: 期待と現実のギャップの原因を議論する。「誰が悪い」ではなく「何がそうさせたか」に焦点を当てる
- 次はどうするか: 学びを具体的なアクションに変換する。「次は気をつける」ではなく「次は○○を△△するまでに実施する」レベルまで落とす
話して終わりにしない。AARの結果は必ず文書化する。
- 記録フォーマットは最小限でいい。4つの問いとその回答、決まったアクションを箇条書きにするだけ
- チームのWiki、Slack、Notionなど普段使うツールに保存する
- 類似の活動をする他チームにも共有すると、組織全体の学習速度が上がる
記録がなければ、教訓は次のAARまでに忘れ去られる。
具体例#
都内のクラフトビール専門店（席数30）が、初めての「醸造家トークイベント」を開催した。
Q1 何を期待していたか
- 集客目標: 40名（立ち見込み）
- SNS投稿: 参加者の30%がInstagramに投稿してくれると想定
- 売上目標: 通常の土曜比で150%
Q2 実際に何が起きたか
- 来場者: 22名（目標の55%）
- SNS投稿: 3名のみ（参加者の14%）
- 売上: 通常の土曜比118%
Q3 なぜ差が生じたか
- 告知開始が1週間前と遅すぎた（常連客のスケジュールが埋まっていた）
- SNS投稿を促す仕掛け（フォトスポット、ハッシュタグ掲示）がなかった
- イベント限定メニューがなく、通常営業との差別化が弱かった
Q4 次はどうするか
- 告知は3週間前に開始し、LINE公式で予約を受け付ける
- 写真映えするイベント限定ビールフライトを用意する
- 参加者がSNSに投稿しやすいように、ハッシュタグ入りコースターを配布する
このAARは閉店後の30分で完了。次回イベントでは来場者38名を達成し、Instagram投稿も12件に増えた。
従業員200名のEC支援企業で、本番環境のデータベース障害が発生。復旧に4時間32分を要し、クライアント15社に影響が出た。
翌朝、障害対応に関わった6名でAARを実施（所要時間25分）。
Q1: 障害発生時の想定復旧時間は1時間以内（SLA基準）
Q2: 実際の復旧に4時間32分。原因特定に2時間、復旧作業に1時間、確認に1時間半かかった
Q3: 原因特定が遅れた理由は3つあった。
| 原因 | 詳細 |
|---|---|
| ログの検索性が低い | 構造化ログ未導入で、grepで手動検索していた |
| エスカレーションが遅い | 担当者が1人で30分間抱え込み、チームリードへの連絡が遅れた |
| ランブックが古い | 半年前のDB構成変更が手順書に反映されていなかった |
Q4で決まったアクション:
- 構造化ログ導入を次スプリントのバックログに追加（担当: 佐藤、期限: 4月末）
- 「15分で解決の見通しが立たなければエスカレーション」をインシデント対応ルールに明記
- ランブックのレビューを月次の定例タスクに追加
障害そのものは痛い経験だったが、このAARから生まれた構造化ログの導入により、次の障害では原因特定が2時間 → 18分に短縮された。
公立高校のバスケットボール部（部員16名）。県大会ベスト8を目標に臨んだが、3回戦で58-71で敗退しベスト16止まり。
顧問の提案で、試合翌日の練習前に全員でAARを実施した。
- 期待: 相手チームのエース（平均28得点）を20点以下に抑え、自分たちのペースで試合を運ぶ
- 現実: エースに31点を許し、第3クォーターで一気に引き離された
- 原因の議論で出てきたこと: ダブルチームの切り替えタイミングがバラバラだった。練習ではできていたが、試合の緊張と歓声で声が聞こえず、サインが伝わらなかった。第3クォーター開始時にベンチからの指示を待ってしまい、自分たちで修正できなかった
部員たちが自ら決めたアクションは2つ。ハンドサインを3パターン追加すること、そして練習試合で意図的にBGMを大音量で流して「聞こえない状況」を再現すること。
翌月の練習試合では、声が通らない場面でもハンドサインで守備の切り替えが機能するようになっていた。勝ち負けの前に「なぜそうなったか」を全員で言語化する習慣が、このチームの一番の収穫だったのではないか。
やりがちな失敗パターン#
- 犯人探しになる — 「誰のせいか」に議論が向くと、次回から正直に発言する人がいなくなる。ファシリテーターは「人」ではなく「プロセスや仕組み」に焦点を当て直すこと
- 時間を空けすぎる — 1週間後にやっても、記憶があいまいで「たぶんこうだった」という推測ばかりになる。鮮度が命なので、遅くとも翌営業日までに実施する
- アクションが抽象的すぎる — 「コミュニケーションを改善する」では何も変わらない。「毎朝9時にSlackで進捗を共有する」のように、誰が見ても実行できるレベルまで具体化する
- 記録を残さない — 話し合って満足し、議事録を取らないパターン。3か月後に同じ問題が再発して「前も同じ話したよね」となる。最低限、4つの問いの回答とアクションだけは記録する
まとめ#
アフターアクションレビューは、たった4つの問い――「何を期待していたか」「実際に何が起きたか」「なぜ差が生じたか」「次はどうするか」――で振り返りを構造化するフレームワーク。米軍が戦場で使い始めた手法だが、飲食店の集客からシステム障害対応、部活動まであらゆる場面で機能する。成功の鍵は24時間以内に実施すること、犯人探しではなく仕組みに目を向けること、そして教訓を必ず記録に残すこと。振り返りが「反省会」で終わっているチームこそ、まず1回試してみてほしい。