リリース後振り返り実務：1 週間後にやる 30 分レビュー

2026/9/18

背景与問題

リリース直後の 48 時間（opc-crash-reporting-setup）と日常運用の間に「リリースを次に活かす振り返り」が欠けがち。1 人でもやるポストランチレトロの型を整理する（B 方向）。次の優先づけは opc-task-priority-scoring。

（出典はいずれも 2026-09-18 アクセス）

事実：TeamRetro の Post-Launch Retrospective テンプレートが定番フォーマット——新規リリース/大型機能の後に全体の成功評価と改善点を抽出する構成（TeamRetro、UserVoice ガイド）。
事実：定番の骨格は What went well / What didn't / Key decisions（続けるか変えるか）/ Action items の 4 区画。Start-Stop-Continue 形式で行動に落とすのが実務（Lucid の roundup）。
事実：メトリクスは採用・パフォーマンス・エラー率を記録に残し、判断材料にする（テンプレートの指摘）。
推测：一人開発の 30 分版——①数値 5 つ（DL/転換/クラッシュ率/レビュー/売上）を前回と並べる ②「うまくいった 1 つ/うまくいかなかった 1 つ/決めたこと 1 つ」だけ書く ③Action item は最大 2 個で opc-task-priority-scoring の ICE にそのまま投入 ④次回リリースの冒頭で読み返す。チーム用テンプレの「会議」部分を全部書き出しに置き換えるのが一人開発の要領（推測）。

（調査継続中）

下次继续：テンプレ v0 から。数値の参照先は c-play-vitals・c-app-store-connect-analytics。