フィーチャーファクトリー（アンチパターン）

Before（フィーチャーファクトリー状態）:

• 四半期で12機能をリリース（チームは「頑張った」と思っている）
• リリースした機能のうち、月間利用率が5%以上あるのは3個だけ
• 残りの9機能は誰も使っていないが、メンテナンスコストは発生し続ける
• ロードマップは「大口顧客からの要望リスト」で埋まっている

転換のアクション:

1. ロードマップを「機能リスト」から「解きたい問題リスト」に変更
2. 各施策に「成功指標」を必須項目として設定
3. リリース4週間後に「成果レビュー」を実施
4. 利用率3%以下の既存機能を10個削除

After（アウトカム志向）:

作る量を減らして質に集中した方が、ユーザーにも開発者にも良い結果になった。「たくさん作る」から「正しいものを作る」への転換がすべて。

状況: 月間アクティブ80万人のモバイルゲーム。毎月4つの限定イベントを投入するが、DAUは横ばい。開発チーム12名の80%がイベント制作に追われ、コアゲーム体験の改善が後回しに。

診断: フィーチャーファクトリーの症状8つ中6つに該当。「月のイベント数」が唯一のKPIで、各イベントの参加率・完走率・収益貢献は誰も追っていなかった。

転換:

• 過去12ヶ月のイベントデータを分析 → 参加率50%以上はわずか15%
• 「月4イベント」を「月2イベント＋コア改善1施策」に変更
• 各イベントに「参加率40%以上」「課金率前月比+5%」の成功基準を設定

結果（6ヶ月後）:

• イベント参加率: 平均28% → 52%
• 月間課金額: +18%
• DAU: 横ばい → 月3%成長に転換

イベントの数を半分にしたら、売上が**18%**伸びた。「量を減らしたら成果が出なくなるのでは」という恐怖は、データで覆された。

状況: 従業員2,000人のメーカーの社内システム開発部門（15名）。営業・製造・経理から月40件の機能要望が来て、来た順に対応。「全部対応しているのに満足度調査は毎年低下」という矛盾。

診断: 典型的なフィーチャーファクトリー。部門の評価基準が「要望対応件数」で、要望の効果検証は一切なし。

転換:

1. 過去1年の要望対応120件の利用率を調査 → 月1回以上使われているのは34件（28%）
2. 月40件の要望を受けるのをやめ、四半期ごとに「解くべき業務課題TOP5」を各部門と合意
3. 各課題に「業務時間○○%削減」等の成果指標を設定
4. リリース後1ヶ月で効果を計測し、結果を全社に報告

「全部に応える」より「本当に効く課題に集中する」方が満足度が上がる。社内システムもプロダクトマネジメントの考え方が効く好例。