post-mortems-retrospectives

事後検証と振り返り

11 人のプロダクトリーダーのフレームワークを活用して、真の学びにつながる効果的な事後検証と振り返りをユーザーが実施できるよう支援します。

支援の進め方

ユーザーから事後検証や振り返りについて支援を求められたら、次のように対応します。

1. 状況を把握する - 失敗、成功、定期的なチェックポイントのいずれを受けた振り返りかを尋ねます
2. 適切な雰囲気を作る - 責任追及ではなく、学びに焦点を当てた取り組みとして位置づけられるよう支援します
3. 洞察を得られる構成にする - 実行可能な学びを引き出す形式へと導きます
4. 確実に実行につなげる - 学びを行動に移す仕組みづくりを支援します

基本原則

プリモーテムでは中止基準が必要です

Annie Duke：「プリモーテムは、『中止基準』、つまり方向転換や中止の引き金となる事前に定めたシグナルが設定されて初めて効果を発揮します。」プリモーテムの段階でプロジェクトが失敗しつつあることを示す早期シグナルを特定し、そのシグナルが見られた場合の具体的な対応をあらかじめ決めておきます。

失敗を成長の機会と捉え直す

Carole Robin：「頭字語は A-F-O-G、つまり『もう一度のクソみたいな……もう一度の成長のためのクソみたいな機会』です。何かがうまくいかなかったときや、誰かが失敗を経験したとき、私が最初に必ず尋ねるのは、『それで、何を学びましたか？』です。」失敗が起きたら、つらい挫折の最中でも視点を保てるよう、すぐに「ここから得られる教訓は何ですか？」と尋ねます。

「事後検証」ではなく「振り返り」と呼ぶ

Eeke de Milliano：「何かを事後検証と呼ぶのではなく、振り返りと呼びましょう。そうすれば、前向きな取り組みになります。『ねえ、これから学ぼう』というように。」言い換えることで失敗を当たり前のものとして捉えやすくなり、責任追及ではなく、チームの学びに焦点を当てられます。

学びのレビューを制度化する

Ben Williams：「私たちはチーム単位で、インパクトと学びをレビューしています……チームはデータ探索、実験、ユーザーリサーチから得た学びを継続的に記録しています。」状況報告ではなく洞察に焦点を当てた「インパクトと学び」のレビューを毎週実施し、学びを会社全体に共有します。

OKR はパフォーマンスではなく学びのために評価する

Christina Wodtke：「大切なのは、なぜ 80％だったのかということです。学びにしっかり焦点を当てましょう……評価よりも振り返りを優先してください。」OKR を評価する価値は、目標を達成したかどうかの数字そのものではなく、その理由を振り返って分析することにあります。四半期末の振り返りを行い、システム上の障害要因を特定します。

責任を追及しない

目的は、何が起きたのか、なぜ起きたのかを理解することであり、責任を押しつけることではありません。罰を恐れることなく、率直に話せる心理的安全性を作ります。

ユーザーを支援するための質問

• 「このプロジェクトを始める前には知らなかったことで、何を学びましたか？」
• 「開始時と同じ情報を持ったまま、もう一度取り組むとしたら、何を変えますか？」
• 「早い段階でどんなシグナルに気づいていたのに、無視したり見逃したりしましたか？」
• 「今回の結果につながったシステム上の問題のうち、対処すべきものは何ですか？」
• 「今後、同様のプロジェクトにどのような中止基準を設けるべきですか？」
• 「こうした学びを今後の意思決定に確実に反映するには、どうすればよいですか？」

よくある間違いとして指摘すべきこと

• 責任追及を軸にした構成 - システムを理解するのではなく、責任の所在を探す取り組みにしてしまう
• 実行につなげない - 振り返りを行っても、そこから得た学びを実行に移さない
• 失敗だけを振り返る - 成功から学び、それをもたらした要因を理解する機会を逃す
• 学びではなくスコアを最適化する - OKR の達成率ではなく、なぜ達成できたのかに焦点を当てる
• 一度きりの取り組みにする - 振り返りを大きな失敗のときだけ行い、定期的な習慣にしない

詳細

11 人のゲストによる 13 の洞察については、references/guest-insights.md を参照してください。

関連スキル

• running-effective-meetings
• running-decision-processes
• planning-under-uncertainty