功能冻结：发布前 1-2 周的稳定期设计

2026/9/20

背景与问题

solo のリリース遅延の主因は「リリース直前にもう一つ機能を足す」こと。feature freeze（新機能追加の停止点）を自分に課す運用の設計。

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

事実（[Wikipedia「Freeze (software engineering)」](https://en.wikipedia.org/wiki/Freeze_(software_engineering))）：feature freeze=新機能の追加を停止し、全てを bug 修正と UX 改善に振り向ける時点。
事実（Pragmatic Engineer）：実務の freeze はリリース前後の 1-2 週間が相場——solo にも適用できる長さの基準。
事実（Agile Alliance）：freeze 期間はstability 作業に全振りする期間として設計する。
事実（Reddit の注意点）：freeze 解除後に即 churn（新機能）を再開すると freeze の意味が消える——freeze の価値は「次サイクルへの繰り越し規律」に依存。
推测：solo の freeze が破られる瞬間は「小さいから大丈夫」という追加——freeze 中の新規アイデアは「次サイクルの backlog」に書くだけにするルールが必要（書くのは自由、実装しない）。
推测：freeze 期間はバグが出る（出す）期間——予定より余計なバグ修正が発生するのが正常と割り切り、freeze 中は修正以外に責任を持たない。

運用ルール：リリース予定 2 週間前に feature freeze（バグ修正・文案・テストのみ可）——新規アイデアは backlog へメモするだけ。
freeze の長さ：小更新=1 週、メジャー更新=2 週（実務相場に合わせる）。
解禁の儀式：リリース完了を確認してから backlog を見る——リリース前の backlog 覗き見は freeze 破りの入口。
効果測定：freeze 導入前後の「リリース後 48h の緊急 hotfix 回数」を比較——0 回なら freeze が機能している（推测）。