フレームワーク活用ガイドひとことで言うと#
プロダクトに存在するすべての機能を利用率・顧客価値・保守コストの3軸で棚卸しし、「強化する機能」「維持する機能」「廃止する機能」を客観的に判断するフレームワーク。機能を「足す」ことばかり考えがちなチームにとって、「引く」判断の根拠を与える。
押さえておきたい用語#
- Adoption（アドプション）
- 全ユーザーのうちその機能を1回以上使ったことがある割合を指す。機能の認知度・到達度を示す。
- Frequency（フリクエンシー）
- 機能を使っているユーザーがどれくらいの頻度で使うかを表す指標のこと。高Adoptionでも低Frequencyなら「試して放置」の可能性がある。
- ゾンビ機能
- 利用率も顧客価値も低いが保守コストだけかかり続けている機能のこと。フィーチャー監査で最も廃止対象になる分類。
- 技術的負債（Technical Debt）
- 短期的な対応の積み重ねで将来の開発速度を落とす要因である。ゾンビ機能の放置は技術的負債を増大させる。
フィーチャー監査の全体像#
こんな悩みに効く#
- 機能が増えすぎてプロダクトが複雑になり、新規ユーザーが使いこなせない
- どの機能にエンジニアリングリソースを投じるべきか判断できない
- 技術的負債が溜まっているが、どこから手をつけるべきか分からない
基本の使い方#
プロダクトに存在するすべての機能を一覧にする。
- 大機能→小機能の階層で整理する
- 各機能のリリース日を記録する
- 担当エンジニア（保守担当）を紐づける
ポイント: 意外と**「全機能のリスト」が存在しない**チームが多い。この時点で発見がある。
各機能がどれくらい使われているかをデータで把握する。
- 採用率（Adoption）: 全ユーザーのうち何%がその機能を使ったことがあるか
- 利用頻度（Frequency）: 使っている人はどれくらいの頻度で使うか
- リテンションへの寄与: その機能を使っているユーザーの継続率は高いか
ポイント: 分析ツール（Mixpanel、Amplitude等）のデータを活用。データがない機能は計測の仕組みを先に入れる。
利用率 × 顧客価値の2軸で機能を4つに分類する。
- スター（高利用率 × 高価値）: プロダクトの中核。積極的に強化する
- ポテンシャル（低利用率 × 高価値）: 価値はあるが認知・UXに問題。改善で化ける可能性
- コモディティ（高利用率 × 低価値）: 当たり前機能。維持するが追加投資は最小限
- ゾンビ（低利用率 × 低価値）: 廃止候補。保守コストだけかかっている
ポイント: 「顧客価値」はNPSへの寄与度やカスタマーサポートでの言及頻度で測定。主観ではなくデータで判定。
各象限の機能に対して具体的なアクションを決める。
- スター: 開発リソースの50%以上をここに集中。さらなる改善と拡張
- ポテンシャル: オンボーディングやUI改善で利用率を上げる施策を実施
- コモディティ: 安定運用に徹する。品質は保つが新規開発は最小限
- ゾンビ: 廃止のタイムラインを設定。段階的に非表示→削除
ポイント: ゾンビ機能の廃止は最も勇気がいるが、最もインパクトが大きい。コードベースの簡素化、テスト工数の削減、UIのシンプル化につながる。
具体例#
状況: 3年間で45機能をリリース。エンジニアの60%が保守・バグ修正に時間を取られ、新機能開発が進まない。
フィーチャー監査の結果:
| 分類 | 機能例 | 機能数 | アクション |
|---|---|---|---|
| スター | タスクボード、通知、コメント | 8 | リソース集中。AI自動分類等の拡張を検討 |
| ポテンシャル | ガントチャート、レポート機能 | 6 | UI改善+オンボーディングに組み込む |
| コモディティ | ユーザー管理、権限設定、ログ | 12 | 安定運用。バグ修正のみ |
| ゾンビ | タイムトラッキング、Wikiモジュール、カスタムフィールド（一部） | 19 | 段階的に廃止 |
ゾンビ機能の廃止計画:
- 利用率1%未満の7機能: 即日非表示（UIから削除、APIは3ヶ月間維持）
- 利用率1〜5%の8機能: 利用者に通知→代替手段の案内→3ヶ月後に廃止
- 利用率5〜10%の4機能: ヒアリング実施後、統合または廃止を判断
結果: 6ヶ月で19のゾンビ機能のうち15を廃止。エンジニアの保守工数が60%→35%に削減。空いたリソースでスター機能のAI拡張をリリース→NPS8ポイント向上。新規ユーザーの初回操作完了率が25%→40%に改善。
「機能を削る」ことでプロダクトの価値が上がった。45機能→30機能にしたことで、残った機能の体験が向上し、ユーザー満足度も開発速度も改善。
状況: MAU15万人のフィットネスアプリ。4年間で32機能を追加。新規ユーザーのアプリ削除率が初日40%と高く、「何から始めていいかわからない」という声が多い。
監査結果:
| 分類 | 機能例 | Adoption | アクション |
|---|---|---|---|
| スター | ワークアウト記録、体重グラフ、カレンダー | 65〜82% | トップ画面に集約 |
| ポテンシャル | 食事記録、睡眠トラッキング | 8% | オンボーディングで訴求 |
| コモディティ | プロフィール、設定、通知管理 | 95% | 維持のみ |
| ゾンビ | コミュニティ掲示板、チャレンジ機能、バッジ収集、友達検索 | 1.2〜3.8% | 段階的廃止 |
結果:
- ゾンビ4機能を3ヶ月で非表示化
- ホーム画面をスター3機能中心に再設計
- アプリサイズが180MB→120MBに縮小
| 指標 | 監査前 | 監査後3ヶ月 |
|---|---|---|
| 初日削除率 | 40% | 22% |
| 7日後継続率 | 28% | 41% |
| App Store評価 | 3.4 | 4.1 |
「機能が多い＝価値が高い」ではない。32機能→28機能に減らしただけで、初日削除率がほぼ半減した。
状況: 従業員500名の食品メーカー。15年間使い続けた社内業務システムに累計120の機能画面。年間保守費用が4,800万円。新機能追加のたびに「他の画面が壊れる」リスクが発生。
監査結果:
- 120画面のうち過去6ヶ月でアクセスゼロが38画面
- アクセスユーザーが5人以下の画面が27画面
- 全従業員が週1回以上使う画面はわずか18画面
アクション:
- アクセスゼロの38画面: 関係部署に確認後、3ヶ月で非公開化
- 5人以下の27画面: 個別にヒアリング→Excel代替で十分な12画面を廃止
- 残り65画面を新システムに段階的に移行
結果: 年間保守費用4,800万円→2,900万円（40%削減）。新機能追加時のテスト工数が60%減少。
「15年間誰も触れなかった画面」が全体の32%もあった。フィーチャー監査は新しいプロダクトだけでなく、レガシーシステムの最適化にも効く。
やりがちな失敗パターン#
- 利用率だけで判断する — 利用率は低いが、使っている人にとっては必須の機能（当たり前品質）がある。利用率と顧客価値の両方で評価する
- 廃止のコミュニケーションを怠る — 突然機能がなくなると顧客の信頼を失う。事前告知→代替手段の提示→移行期間のステップを踏む
- 一度きりで終わる — プロダクトは常に機能が増え続ける。半年に1回のフィーチャー監査を定例化する
- 「いつか使うかもしれない」で残し続ける — この思考がゾンビ機能を生む。明確な利用計画がなければ廃止し、必要になった時に再構築する方が効率的
まとめ#
フィーチャー監査は「機能を足す」ことに慣れたチームに「機能を引く」判断力を与えるフレームワーク。全機能を利用率と価値で4象限に分類し、スターに集中投資しゾンビを廃止する。プロダクトのシンプルさはユーザー体験の質に直結する。定期的な棚卸しで、プロダクトを健康な状態に保とう。