Feature flag 運用の solo 版（flag 債務を残さない）

背景与問題

OPC（B 方向）。完成前の機能を本番に隠して入れる feature flag は、small team こそflag の掃除忘れが最大の事故源。solo 用に「2 つの規則」だけの最小運用を決める。store 側の段階配信は opc-staged-rollout が既存で、本课题はアプリ内機能単位の制御。

发现

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

• 段階展開の定石：1%→5%→10% と漸増させてから全量（GrowthBook）。canary release が古典型（Kodus）、セグメント単位で出す（Flagsmith）。
• 小さく始める理由は負荷増加下の挙動観察と早期の問題検知（LaunchDarkly）。
• flag 債務対策の実務：各 flag に明確なオーナーを置き、「追加のチケット+除去予定の事前スケジュール済みチケット」の 2 枚を作る（r/ProductManagement の実務議論）。小規模チームこそ lifecycle 管理が重要（Zylos research）。
• 推测：solo ではオーナーは自分しかいない分、「除去予定日」の記録だけが唯一の防御装置。

结论

1. solo の規則は 2 つだけ：①flag には必ず除去予定日を入れる ②段階は 1%→10%→全量の 3 段でよい（2 ticket 原則の solo 縮約）。予定日を過ぎた flag は「生かすか殺すか」を強制決定する。
2. flag 管理 SaaS は使わない：自前の設定 JSON 1 ファイル+起動時取得で足りる（opc-tool-cost-audit の方針と整合）。段階の制御も設定値 1 つで。
3. opc-staged-rollout（store による配信段階）と feature flag（アプリ内の機能段階）は別物として使い分け：store は 7 日の配信段階、flag は機能の見え方。両方を使う時の説明を runbook に 1 行書いておく。
4. flag の棚卸しを年越し点检（opc-year-end-checklist）に 1 項目追加：全 flag の除去予定日リストを出し、予定日超過を潰す。

待办 / 下次继续

• 設定 JSON の項目設計（flag 名・除去予定日・段階%）を 1 回書く。
  
• 現行コードに残っている「隠し機能」の棚卸し。
  

关联

opc-staged-rollout opc-tool-cost-audit opc-year-end-checklist opc-old-version-support-policy