Post-mortem ritual：失败的事后检证——blameless は「自分にも」適用する

2026/9/15

B 方向·OPC 最佳实践（维度：失敗の学習ループ）。postmortem 索引 0 命中——opc-premortem-ritual（発布前の失敗预演）の対の半分。xmm 本轮不可用。

背景と問題

launch が外れた/機能が使われない/退会が急増——solo は失敗を「胸のつかえ」として抱えたまま次に進む。事後検証の型を持たないと、同じ失敗を別の形で繰り返す。

blameless の原則は solo にも効く：責めの言語（誰が悪いか）は分析を止める——solo の場合は「自分を責める自己対話」が同じ効果を持つ（Google SRE Book の postmortem 文化、Beebole guide，访问 2026-09-15）。
型の共通骨子：①何が起きたか（事実·タイムライン）②なぜか（根本原因——「急いだから」で止めず「なぜ急いだか」まで）③何を変えるか（1 つだけ、具体的に）④プロセスに戻す（テンプレ/チェックリスト更新）。
postmortem vs retrospective の区別：事後の深掘り（イベント駆動）と定期的な振り返り（期間駆動）は別物（IndieHackers 整理）——週次リズムの金曜 3 分分類（opc-inquiry-reduction-playbook）は retrospective、本課題はイベント駆動の深掘り。
終わりは必ず具体的な 1 変更で：レッスンリーンドの羅列で終わらない（TeamRetro/UptimeRobot テンプレの共通点）。

solo の発動基準【推测】：①想定の 5 割以下の成果（D+30 時点）②同じ問題の 2 回目発生 ③感情が 3 日以上残る——この 3 つで 30 分の postmortem。小さすぎる失敗は週次 retrospective で拾う。
公開/非公開の線引きを先に決める：postmortem の一部（「直した」という事実）は信頼素材になるが、根本原因の詳細は競合に読まれる（opc-threat-intel-publication-policy の公開線引きと同じ枠）——「公開するのは事実と対策のみ、原因の詳細は非公開」を初期設定に。

可行动启发：

Post-mortem テンプレ v1 を作る（30 分版）：事実タイムライン（10 分）/根本原因 5 なぜ（10 分）/変更 1 つ（10 分）——研究ノートのフォルダ規則に postmortem/ を追加し、発動 3 条件を先頭に書く。
blameless を自分に適用する文面：「〜しなかった自分が悪い」を禁止し「プロセスのどの部分がそうさせたか」だけ書く——テンプレの冒頭に固定文として入れる。
変更 1 つは必ずプロセス側に：「気をつける」でなくチェックリスト/テンプレ/自動化のどこかを 1 行変える——Go/No-Go checklist（opc-solo-launch-first-product-go-no-go-checklist）や premortem（opc-premortem-ritual）へのフィードバックで閉じる。
公開は「事実+対策」だけ：note/X に載せる場合の線引き（原因詳細は非公開）を opc-threat-intel-publication-policy と同じ原則で運用——失敗の学習と競合防御の両立。