自分の開発手法やワークフローを自己改善させたいとき、新しい振り返り儀式を作るより、すでに機能している改善ループの入力側（シグナルの記録）を落穂拾いする方が効く。実際「摩擦→分析→改訂」のループは非公式には回っていて、欠けていたのはシグナルの記録が記憶頼みだった点だけだった（たまたま分析した摩擦は改訂に繋がり、しなかった摩擦は蒸発する）。

設計（手法自身の原則を自己適用: 記録は即時に安く、反映は1バッチ）:

1. 即時の1行記録 — run ごとに実測フッタ（差し戻し回数・レビューラウンド数・逸脱など）を完了報告に1行。数字は自己申告の概算で十分（n が小さく傾向が見えれば足りる）。
2. 摩擦ログ — 手順から逸脱した/手順が実態と合わなかった瞬間に1行追記。逸脱は「手順が実態と合っていない」最強のシグナル。
3. 改訂トリガーは定期でなく件数 — ログがN件たまるか同型が2回続いたら改訂を1バッチで回す。cron 的な定期振り返りにしないのは、件数トリガーなら使用頻度にトリガーが自動追従するから（使わない時期は振り返りも発生せず、多用する週は早く回る）。

各指標は手法側の弱点に対応させる（差し戻し多し→完了条件が曖昧、計画補完発生→計画の完成条件チェックが甘いなど）と、記録が改善の入力になる。

却下した代替案: ①transcript の自動解析やメトリクス自動収集は、個人・小 n では自動化コストが分析価値を上回る。②専用の振り返り儀式/ツールは、ログが実際に溜まって集計が痛くなるまで不要。③記録漏れの後追いは既存のセッション走査ツールで補えるので回収機構も不要。