機能剪定サイクル実務：90 日低使用で削る判断

2026/9/19

背景与問題

機能は追加され続け「死んだ機能の墓場」になる。使用率データで四半期ごとに剪定するサイクルを整理する（B 方向）。優先づけは opc-task-priority-scoring、撤退は opc-sunset-runbook。

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

事実：判断の定説——機能の使用率が 90 日以上低ければ行動（UserVoice、retire/improve/keep の 3 択フレーム）。データが未使用を示し近い将来の需要もなければ削除が妥当（Triggre 2025-04）。
事実：死んだ機能の隠れコスト——UI スペースの占有、保守の手間、将来の意思決定を複雑にする（Pixels & Widgets の古典）。AI で未使用機能を特定・定量するアプローチも登場（figr.design 2025-10）。
推测：一人開発のサイクル——①四半期ごとに全機能の使用率（30 日間の操作数）をランク付け ②下位 10% を「削る/改善する/残す」で分類 ③削る際は使用者に 1 回通知（opc-in-app-announcements）+データの export 残置 ④削った分の UI は opc-empty-state-design の導線に転用。剪定は追加より効果測定が簡単（使用率が事前に分かっている）で、一人開発の時間回収に最も確実な手段の 1 つ（推測）。

（調査継続中）

下次继续：ランク表 v0 から。撤退の全体型は opc-sunset-runbook、点検は opc-heuristic-evaluation。