技術的負債の返済週：週 1 時間の継続返済と四半期 1 回の半日返済
B 方向·OPC 最佳实践（维度：負債の返済規律）。負債（技術面）索引 0 命中——opc-weekly-operations-rhythm（運営周期）·opc-post-launch-30days（listen 期間）の開発側の健全性。xmm 本轮不可用。
背景と問題
「急いで実装した」コードが積み上がる——solo にコードレビューはなく、負債は静かに増えて発売後の変更を遅くする。返済しない規律だと負債は常に入力の最後尾になる。
发现（访问 2026-09-15）
- 20-25% 返済が定番：各 sprint の 20-25% を技術的負債の返済に充てるのが最も一般的な推奨（40% の性能改善·deploy 問題 70% 減の報告例あり）（Medium/Serious Scrum、LinkedIn の 25% 則，访问 2026-09-15）。
- dedicated debt sprint も正統：集中的な返済週（hackathon 型）を四半期に 1 回置くパターンも認知された手法（ZenHub）——チーム型と solo 型の両方が正統。
- backlog に負債を項目化し明示的な返済ポリシーを持つ（Scrum.org/Simon Guest）——「いつか直す」の管理外放置を防ぐ。
推测
- 我々の規律【推测】：週次 5.5 時間のうち 1 時間/週を返済に（18%——20% 則に近い）+四半期 1 回の debt half-day（3 時間の集中返済）——研究日（月次）と開発週（週次）のリズムに埋め込む。
- 負債の棚を実験ノートと同じフォーマットで管理：箇所/理由/影響/直す価値の 4 列——「直す価値」が低い負債は書かない（記録も過剰は負担）。
结论
可行动启发：
- 週 1 時間の返済枠を週次リズムに常設：開発週の最後の 1 時間——リリース新機能の前の習慣として固定（18%≈20% 則）。
- 四半期 1 回の debt half-day：3 時間の集中返済——小さい積み重ねで解けない負債（構造の変更）をこの日で処理。
- 負債棚 4 列を lightweight に：箇所/理由/影響/直す価値——postmortem と実験ノートと同じノート文化で管理（新しいツールを作らない）。
- 「直す価値なし」も記録しない：影響が小さい負債は放置を許可——solo の時間は有限、負債管理自体のコストを最小に。
待办 / 下次继续
关联
- opc-weekly-operations-rhythm（週次枠の置き場所）、opc-postmortem-ritual（失敗からの負債発生源）、opc-growth-experiment-log（同じノート文化）、opc-solo-launch-first-product-go-no-go-checklist（発売前の負債確認）。