project-retrospective

プロジェクトの振り返りライター

プロジェクトの組織的な知見、特に失敗から得た知見を記録する LESSONS.md ファイルを作成します。自分たちのプロジェクトについて記事を書くジャーナリストのように考え、具体的かつ率直に、実際に起きたミスを明記してください。

振り返りの枠組み：完全な非難なしではなく、非難の偏りを意識する

インシデント分析の執筆における 2024～2026 年の合意（PagerDuty、J. Paul Reed、Lorin Hochstein によるもの）では、完全に非難をなくすことは神経生物学的に非現実的であり、人間は非難する傾向があるとされています。より健全な枠組みは、非難への偏りがあることを認め、それに意識的に対抗することです。出典：https://postmortems.pagerduty.com/culture/blameless/

明示的に対抗すべき認知バイアス：

• 根本的な帰属の誤り：システムが許容していた失敗について、個人を非難する
• 確証バイアス：あらかじめ形成された筋書きを裏付ける証拠を探す
• 後知恵バイアス：当時は得られなかった知識に基づいて、過去の判断を評価する
• ネガティビティバイアス：うまくいったことより、うまくいかなかったことを過度に重視する

声のルールは「非難しない」ではなく、「人の行動だけでなく、その行動を許容したシステムを明記する」です。

単一の根本原因という枠組みを捨てる

Allspaw による定番の批判（2024～2026 年も依然として主流の見解）では、5 つのなぜ／単一の根本原因分析は「魅力的で納得感があり、単純明快だが、誤りである」とされています。分析者を直線的な因果関係の連鎖に閉じ込め、個人の非難で終わらせてしまいます。出典：https://www.kitchensoap.com/2014/11/14/the-infinite-hows-or-the-dangers-of-the-five-whys/

代わりに「どのように」を軸とする説明を用い、次の 4 つの問いに沿って情報を集めてください。

• 手がかり：どのようなシグナルが得られていたか、誰がいつ目にしたか？
• 解釈：人々はそのシグナルをどのように理解したか？
• 目標：人々は何を達成しようとしていたか？
• 行動：何を行い、何が起きると予想していたか？

振り返りの目的は、根本原因を断定することではなく、寄与した要因を明らかにすることです。

振り返りを実施するタイミング

インシデントが起きてからではなく、起きる前にトリガーを定義してください。Google SRE では、ユーザーに影響する停止が一定のしきい値を超えた場合、データ損失が発生した場合、オンコール担当者がロールバックした場合、監視の不具合を手作業で発見する必要があった場合、関係者から依頼があった場合などが基準として定められています。出典：https://sre.google/sre-book/postmortem-culture/

ジャーナリズムの文脈に置き換えると、次のようになります。

トリガー	例
ライブイベントの失敗	選挙当日のライブブログ停止、速報記事への埋め込みコンテンツの不具合、調査報道の最中に起きたペイウォールの不具合
編集プロセスの失敗	訂正期限の逸失、情報源の管理に関する違反、ファクトチェックプロセスの迂回
購読者に影響するツールの不具合	CMS 移行による不具合、読者の >X% に影響するペイウォールのロジック
関係者からの依頼	編集者／発行者／情報源から「何が起きたのか」と明示的に尋ねられた場合

あらかじめトリガーを定めておけば、日常業務に対する形だけの振り返りを防ぎ、実際の失敗について確実に振り返りを実施できます。

タイミング：1 週間以内を目指す

Google の良い振り返りと悪い振り返りの比較では、寄稿者の記憶が薄れていたため、品質面で問題のある例として「4 か月後」が挙げられています。出典：https://sre.google/workbook/postmortem-culture/

推奨される実施時期：

プロジェクトの種類	目標期間
ライブイベントの振り返り（選挙当日、速報記事）	当日中に振り返り、48 時間以内に文書化
ツール／CMS のインシデント	1 週間以内
調査報道または記事公開の開始	プロジェクト終了から 1 か月以内
継続中の取り組みの年次レビュー	年 1 回、個別の意思決定点に範囲を絞って実施

実証的に確認できている最低条件は、「寄稿者の記憶が新しいうち」です。1 週間を過ぎると、物語は記憶からではなく再構成されるようになります。

イベント形式の振り返りには、AAR の構成を使います

米陸軍のアフター・アクション・レビュー（FM 7-0 付録 K）は、進行役が主導するイベント後の振り返りのために設計されており、プロジェクト終了時のテンプレートよりも、ニュース速報の現場に適しています。出典：https://www.first.army.mil/Portals/102/FM%207-0%20Appendix%20K.pdf

4 つの問い：

1. 何が起こるはずでしたか？
2. 実際には何が起こりましたか？
3. その違いについて、何が正しく、何が間違っていましたか？
4. 次回、基準どおりに実行するにはどうすればよいですか？

イベントの直後に、参加者全員、選挙報道のニュースルームチーム、ライブブログ担当者、速報デスクとともに AAR を実施します。このためには event.md テンプレートを使ってください。プロジェクト終了時のテンプレートは、ライブイベントの振り返りには適していません。

重要なセクション：「本当の問題」

これは、どの振り返りでも最も価値のある部分です。次の問いに答えます。

「私たちが作ろうと考えていたものと、実際に必要だったものは何か？」

良い例：

編集者向けの管理ダッシュボードを作りましたが、実際に必要だったのは Slack ボットでした。編集者は Slack を使っているため、ウェブアプリを開かせるのは受け入れられない手間でした。ダッシュボードの月間アクティブユーザーは 2 人ですが、1 日で作った Slack ボットのプロトタイプは 47 人に使われています。

悪い例：

ユーザー調査の重要性を学びました。

テンプレートの構成

# LESSONS.md

## Project
- **Name:** [Project name]
- **Dates:** [Start - End]
- **Status:** [Completed / Abandoned / Ongoing]
- **Author:** [Your name]
- **Retrospective written:** [Date, should be within timing window above]

## Summary
[One paragraph: what it did, what impact it had, why it matters]

## What worked

### Technical wins
- [Specific decision and WHY it worked]
- [Tool/pattern that saved time]

### Process wins
- [Methodology that helped]
- [Communication pattern that worked]

## What didn't work

For each item below, separate the system layer from the people layer.
"What did the system permit or require?" comes before "What did the
people inside that system do?"

### Critical failures
- **System:** [What the architecture / process / tooling permitted]
- **People:** [What humans did inside that constraint]
- **Cost:** [Quantified impact: hours, subscribers affected, money]

### Technical debt
- [Shortcut that hurt later, and why it was the rational choice at the time]
- [Complexity that wasn't needed]

### External factors
- [Things outside your control that impacted the project]

## The real problem

What we thought: [Initial assumption]
What was actually needed: [Reality]
The gap cost us: [Time / effort / money wasted]

## Action items

Each item must have an owner, a deadline, a tracker URL, and a priority.
"Postmortems without subsequent action are indistinguishable from no postmortem."
- Google SRE

| # | Action | Owner | Deadline | Tracker | Priority |
|---|--------|-------|----------|---------|----------|
| 1 | [Specific change] | [Name] | [Date] | [Issue URL] | P0 / P1 / P2 |
| 2 | [Specific change] | [Name] | [Date] | [Issue URL] | P0 / P1 / P2 |

Failure modes to avoid:
- Ambiguous wording ("make automation better")
- Equal priority across all items (defeats the purpose of priority)
- No tracker bug or issue URL (action items vanish)
- Fixes targeting human behavior instead of system redesign ("be more careful")

Add a 30/60/90-day check-in note: who reviews progress on these, and when.

## Reusable artifacts

| Component | Why it's valuable |
|-----------|-------------------|
| [Name] | [Specific reuse potential] |
| [Name] | [Why someone else should use this] |

## Questions for next time
- [Unanswered questions worth investigating]
- [Things you'd research before starting]

文体のガイドライン

• 正直で、具体的で、少し自虐的にします
• プロジェクトに予想の 2 倍の時間がかかった理由を、友人に説明するような口調にします
• システムが何を許容していたかを述べ、そのうえで人々がその中で何をしたかを述べます
• 漠然とした「課題」ではなく、具体的なミスを記します
• 能動態を使います。誰が何を決めたかを隠す「ミスがあった」のような受動態は避けます

情報源選定の振り返り（ジャーナリズムに根ざしたもの）

標準的な SRE／AAR／Allspaw のフレームワークでは、調査に必要な編集判断の振り返りを扱えません。research-project.md テンプレートには、「情報源の判断を再検討する」セクションが追加されています。

• どの情報源を信頼し、その理由は何でしたか？
• どの情報源を採用せず、その理由は何でしたか？
• どのような基準で情報を黒塗りしましたか？その基準は妥当でしたか？
• 調査をもう一度行うなら、何を再検討しますか？
• 次の調査に引き継ぐべきパターンは何ですか？

ニュースルームのエンジニアリングブログ（NYT Open、ProPublica News Apps、WaPo Engineering）はプロジェクトの説明を公開していますが、振り返りの方法論を取り上げることはほとんどありません。そのため、これは前例から借用したものではなく、システムにジャーナリズムに根ざした拡張を加えるものとして扱います。

含めるものと除外するもの

含めるもの	除外するもの
数値で状況を示した具体的な失敗	漠然とした「学び」
ミスにかかった実際の時間／コスト	個人への非難
システムが許容していたこと（その後、人間が何をしたか）	「ミスがあった」という受動態
役に立った、または妨げになったツールの名称	一般的なベストプラクティス
今なら覆す判断と、その理由（当時ではなく今の理由）	当たり前の記述
意外な発見	ほかの文書にすでに記載されている情報

具体性のテスト

「うまくいかなかったこと」の項目ごとに、次の点を確認します。

• 具体的な判断を挙げられますか？
• 影響を数値で示せますか？
• システムが許容していたことと、人々がしたことを分けて説明しましたか？
• これを読んだ人が同じミスを避けられますか？

どれか 1 つでも「いいえ」なら、さらに具体的にします。

書く際の危険信号

次のような表現を書きそうになったら、いったん止めて、さらに具体的にしてください。

• 「コミュニケーションが重要です」
• 「～の重要性を学びました」
• 「今後は～すべきです」
• 「課題には～が含まれていました」
• 「～にいくつか問題がありました」
• 「ミスがあった」（誰が、どのようなシステムでミスをしたのでしょうか？）

これらは、真の気づきを記すための仮置き表現です。具体的な内容に置き換えてください。

良い記載例と悪い記載例

悪い例、曖昧すぎます：

• コミュニケーションがもっと良ければよかった
• 複雑さを過小評価していました
• テストが不十分でした

良い例、具体的で実行に移せます：

• データインポートスクリプトのスキーマ検証ステップが CI で無効になっており（システム）、新しい記事を取り込んだフリーランスの記者は無効化されていたことを知りませんでした（人）。損失：公開済みの 12 件の記事でサイレント障害を引き起こしたタイプミスのデバッグに 3 時間。
• ブラウザー標準の入力欄で対応できたのに、独自の日付ピッカーを作りました。トラッカー：ENG-1247。担当者：K. Park。2 日を浪費しました。

ジャーナリズム向けテンプレート

テンプレートは templates/ ディレクトリにあります：

テンプレート	用途
research-project.md	調査、データジャーナリズムのプロジェクト（情報源選定の振り返りを含む）
event.md	カンファレンス、ワークショップ、キャンペーン（AAR 構成を使用）
publication.md	ニュースレター、ポッドキャスト、継続的なコンテンツ
editorial-tool.md	ニュースルームのソフトウェア、AI ツール

テンプレートの選択

What kind of project?
├── Investigation/analysis → research-project.md
├── Conference/workshop/election night → event.md (use AAR)
├── Newsletter/podcast → publication.md
└── Newsroom tool → editorial-tool.md

最終確認日

2026-05-09。確認済みの情報源：kitchensoap.com（Allspaw「Infinite Hows」）、postmortems.pagerduty.com、sre.google/sre-book および /workbook、first.army.mil FM 7-0 Appendix K、adaptivecapacitylabs.com。

---

最高の振り返りを書くのは、痛い経験をし、同じ目に遭う人を減らしたいと願う人たちです。