インシデントは「体験した人の記憶」に閉じた瞬間に腐る。再利用できる形に変換するかどうかが、組織の学習速度を決める。
この記事の使い方
決めること：失敗記録をどの粒度で構造化し、どのタイミングで参照ルートに乗せるか。
決めないこと：ポストモーテムの書式や使用ツール（Notion／Confluence／GitHub Issues は問わない）。
前提：チームが3人以上いて、同じ種類のミスが半年以内に2回以上起きたことがある。
結論を先に
| 問い | 答え |
|---|---|
| なぜ記録が再利用されないのか | 「何が起きたか」だけ書いて「次に何を確認するか」を書いていないから |
| 最小の構造は何か | 発火条件・見落とした判断ゲート・次回の検知トリガー の3フィールド |
| いつ書くか | 収束から72時間以内。それ以降は記憶が「結果」に引っ張られて歪む |
| 誰が読む形にするか | 当事者ではなく「次に同じ状況に入る人」を読者に設定する |
| 効果が出る最小サイクルは | 月1回の「札の棚卸し」を3ヶ月続けると参照率が上がり始める |
まず用語の地図
| 用語 | この記事での意味 |
|---|---|
| 失敗カード（札） | 1インシデント＝1枚の構造化メモ。日記でも議事録でもない |
| 発火条件 | 「どんな状況が揃ったときに問題が起きたか」の再現可能な記述 |
| 判断ゲート | 本来ここで止まれたはずの確認ポイント。事後に特定する |
| 検知トリガー | 次回、同じ発火条件が揃ったときに気づくための観測シグナル |
| 棚卸しサイクル | 蓄積した札を定期的に読み返し、陳腐化・統合・昇格を判断する作業 |
| 昇格 | 個別の失敗カードが「チェックリスト」や「設計原則」に格上げされること |
なぜ記録は「読まれない文書」になるのか
ポストモーテムが機能しない組織に共通するパターンは、書き方の問題ではなく読まれる設計がないことだ。
3つの腐敗モード
モード1：物語化 「〇〇さんが気づいて対処した」という英雄譚になる。再現性がゼロ。次に同じ状況が来ても「あのときの〇〇さん」がいなければ詰む。
モード2：原因の単数化 「設定ミスが原因でした」で終わる。設定ミスを誘発した判断ゲートの欠落、レビュー手順の曖昧さ、時間的プレッシャーの連鎖が消える。
モード3：アーカイブ化 書いた直後だけ共有され、その後は検索されない。参照ルートに乗っていないので、新しいメンバーは同じ穴を掘り直す。
札の構造：7フィールドと書き方の粒度
失敗カードは「読む人が当事者でない」ことを前提に設計する。以下が最小かつ実用的なフィールド構成だ。
失敗カード テンプレート
## [ID] タイトル（発火条件を動詞句で）
### 発火条件
- 状況A が成立し
- 状況B が重なったとき
- 行動Cを取ると問題が起きる
### 見落とした判断ゲート
- ゲート1：〇〇を確認していれば止まれた
- ゲート2：〇〇のシグナルを無視した
### 実際の損害
- 定量（時間・コスト・影響範囲）
- 定性（信頼・チームの疲弊）
### 検知トリガー（次回用）
- 「〇〇が起きたら」この札を引く
### 暫定対処
- 収束までに取った手順（再現用）
### 恒久対策の状態
- [ ] 未着手 / [ ] 進行中 / [x] 完了
- 対策の内容と担当
### 昇格候補
- チェックリスト化 / 設計原則化 / 不要（単発）
タイトルの書き方が最重要。「本番DBに誤ってDROPを実行した」ではなく「マイグレーションスクリプトを本番環境で直接実行したとき」と書く。発火条件が動詞句になっていると、検索と照合が格段に速くなる。
フィールドごとの粒度チェックリスト
- 発火条件は「状況の組み合わせ」で書いてあるか（単一原因になっていないか）
- 判断ゲートは「本来止まれた場所」として特定されているか
- 損害は定量値が1つ以上入っているか
- 検知トリガーは「次の人が読んで照合できる」具体性か
- 恒久対策の状態は更新日付付きで記録されているか
棚卸しサイクルの設計
札は書いた時点では半製品だ。月1回の棚卸しで初めて資産になる。
棚卸しの4動作
| 動作 | 判断基準 | 所要時間の目安 |
|---|---|---|
| 読む | 全員が5分で内容を把握できるか | 1枚あたり3分 |
| 統合する | 発火条件が80%以上重複する札は1枚にまとめる | 該当ペアあたり10分 |
| 昇格させる | 3回以上参照された札はチェックリストか設計原則に格上げ | 1件あたり20分 |
| 陳腐化させる | 技術スタックや体制が変わり再現不能になった札にタグを打つ | 1枚あたり2分 |
棚卸しを「会議」にしない方が続く。非同期で各自がコメントを付け、月末に15分だけ同期して昇格判断だけ合議する形が現実的だ。
昇格の判断マトリクス
参照頻度 高 ┃ チェックリスト化 │ 設計原則化
┃ （手順が明確） │ （判断基準が必要）
┣━━━━━━━━━━━━━━━━━━━━━━━━
参照頻度 低 ┃ 保留（様子見） │ 陳腐化タグ
┃ │
┗━━━━━━━━━━━━━━━━━━━━━━━━
汎用性 低 汎用性 高
具体例：失敗カードでの検証ゲート
切り口は「同じ穴に二度落ちない」。抽象論で終わらせず、次の三行をチケットに残す。
- 通ったら終わり — 観測可能な完了条件（数値・ログ・画面のどれか）。
- 壊れたらこう見える — 失敗1件と、人間が止める地点。
- 誰が責任を持つか — 客先／本社／ベンダーの分界を一文で。
この三行がない縦スライスは、速さ優先でも信頼優先でもない——ただの未定義作業だ。週次では、ベンダー比較表より先にこの三行を埋める。レビューでは「どのモデルか」より「どのゲートで止めたか」を先に聞く。止める地点が共有されていないチームほど、同じ失敗を別の肩書きで繰り返す。
持ち帰るチェック
- 受け入れ条件は数値か、画面の状態か、ログの一文か——どれか一つに固定する。
- 失敗モードは「起きてほしくないこと」ではなく「起きたときに見えること」で書く。
- 権限を広げた理由がログに残っていない変更は、本番相当に入れない。
- デモ環境と本番相当でデータが違うなら、完了定義も別物として書く。
- 同じ論点が再燃したら、ツール比較より用語表とゲート一覧を先に開く。
よくある偏り
| 偏り | 症状 | 修正の一手 |
|---|---|---|
| 書く人が固定される | 特定メンバーだけが書き、他は読まない | 「インシデントに関わった人が書く」をルール化。関与度で分担する |
| 対策だけ書く | 「〇〇を導入した」で終わり、発火条件が消える | テンプレートの発火条件フィールドを必須にする |
| 責任追及の文書になる | 誰が何をしたかの記述が中心になる | 主語を「状況」に統一するレビューを棚卸し時に行う |
| 量が増えて検索できない | 50枚を超えたあたりで参照が止まる | タグ設計（技術領域・発火条件の種類）を最初から入れる |
| 完璧を求めて書かない | 「まだ整理できていない」で72時間が過ぎる | 発火条件・判断ゲート・検知トリガーの3行だけでも出す |
いまの一手
本気で仕組みを作る人へ
- 過去6ヶ月のインシデントを洗い出し、上記テンプレートで5枚だけ書く
- 5枚を書いた時点で「発火条件の重複」を探す。重複があれば統合し、タグ設計の仮説を立てる
- 棚卸しの日程を今月中にカレンダーに入れる（15分で十分）
- 3ヶ月後に「参照回数が1回以上ある札の割合」を計測する。50%を下回っていれば検知トリガーの書き方を見直す
まだ様子見の人へ
次にインシデントが起きたとき、収束から24時間以内に「発火条件・見落とした判断ゲート・検知トリガー」の3行だけ書いてみる。ツールはメモアプリで構わない。それを3回繰り返したとき、書かなかった場合との差分が判断材料になる。
失敗カードの設計は、チームの意思決定の質を記録する行為でもある。どんな判断ゲートを「見落とせる構造」にしていたかが蓄積されると、採用・育成・プロセス設計の議論に使える素材になる。その延長線上の話は ventures（事業判断）シリーズ でも扱っている。
シリーズハブ → hacks（ハックと技法）
Alex Ishiguro
編集長
MakuakeやCAMPFIREで話題になった商品の「その後」を追うメディアを運営。約束されたものが実際に届いたのか、消えてしまったのかを記録する。
この記事に追加情報や訂正がある場合は、お問い合わせよりご連絡ください。