機能を減らす勇気 — プロダクトから機能を削除した話

はじめに

「この機能、本当に必要だろうか？」

プロダクトを開発していると、つい機能を追加したくなります。「あったら便利かも」「将来使うかも」—— そう考えて実装した機能が、気づけば誰にも使われていない。そんな経験はないでしょうか。

私は CancelNavi（解約手続きナビゲーター）を開発するなかで、あえて機能を「削除」する判断をしました。バグ報告機能を廃止し、別のプロダクトに移行したのです。

この記事では、その判断の背景と、機能を減らすことで得られた学びを共有します。

CancelNavi のバグ報告機能

CancelNavi は、サブスクリプションサービスの解約手続きをナビゲートするアプリです。ユーザーが解約したいサービスを選ぶと、具体的な解約手順を案内します。

リリース当初、アプリ内にバグ報告フォームを設置していました。ユーザーが不具合を見つけたら、その場で報告できるようにするためです。

フォームには以下の項目がありました：

• バグの種類（選択式）
• 詳細説明（テキスト）
• スクリーンショット（任意）

報告されたバグは Supabase のテーブルに保存され、管理画面から確認できる仕組みでした。

別プロダクトの登場

2026年1月、私は IdeaSpool という新しいプロダクトをリリースしました。

IdeaSpool は、アイデアやフィードバックを収集・整理するためのツールです。外部からの投稿を受け付ける機能があり、プロダクトへのフィードバック収集にも使えます。

ここで気づいたのです。

「CancelNavi のバグ報告機能、IdeaSpool に置き換えられるのでは？」

削除の判断

2026年1月24日、私は CancelNavi からバグ報告機能を削除する決断をしました。

開発日記にはこう書いています：

別プロダクトとして開発した「IdeasPool」をフィードバック収集に活用したい CancelNavi 内にバグ報告フォームを持つより、専用サービスに任せた方が効率的 IdeasPool の実績にもつながる

この移行案を Claude Code に相談しました。

Zeronova

CancelNavi のバグ報告機能を IdeaSpool に置き換えたい。フィードバック収集は IdeaSpool の方が機能が充実しているし、重複開発を避けたい。

Claude Code

移行の方向性は合理的です。IdeaSpool はフィードバックの分類・優先度付け・AI 分析を備えているので、CancelNavi の最低限のフォームより品質が上がります。ただし、既存のバグ報告データの扱いと、ユーザーへの導線設計を検討する必要があります。

Zeronova

なるほど。既存データは参照用に残して、新規報告は IdeaSpool 経由にしよう。IdeaSpool の実績にもなるし、プロダクト間のシナジーが生まれる。

この対話で移行の方針が固まりました。判断を後押しした理由は3つありました。

理由1: 重複開発の無駄

CancelNavi と IdeaSpool の両方にフィードバック収集機能を持つのは、開発リソースの無駄です。同じような機能を2箇所でメンテナンスするより、1箇所に集約したほうが効率的です。

理由2: 専用サービスの方が品質が高い

開発日記から：

「バグ報告」という機能は、専用サービスに任せた方が品質が高くなる

CancelNavi のバグ報告機能は「最低限」の実装でした。一方、IdeaSpool はフィードバック収集に特化して設計しています。分類、優先度付け、AI 分析など、CancelNavi には実装していない機能が揃っています。

理由3: プロダクト間のシナジー

開発日記にはこうも書いています：

自分の別プロダクトと連携させることで、両方の価値が上がる

CancelNavi から IdeaSpool へユーザーを誘導することで、IdeaSpool の認知度も上がります。逆に、IdeaSpool を使ってフィードバックを管理することで、CancelNavi の品質向上にもつながります。

具体的な移行作業

方針が決まったあと、Claude Code と具体的な移行方法を詰めました。

Zeronova

既存のバグ報告機能は完全に削除するか、IdeaSpool へのリダイレクトにするか。どちらがいい？

Claude Code

リダイレクトの場合、元のルーティングやコンポーネントを残す必要があり、コードベースの複雑さが残ります。完全に削除して IdeaSpool へのリンクに置き換えた方がシンプルです。過去データは Supabase テーブルに残して参照用にすれば問題ありません。

Zeronova

完全削除でいこう。中途半端に残すとメンテナンスコストが発生するだけだ。

この判断は正しかったと思います。開発日記にもこう記録しています：

既存のバグ報告機能をどうするか

• 完全に削除するか、IdeasPool へのリダイレクトにするか
• 結論: 完全に削除して IdeasPool へのリンクに置き換え

過去のバグ報告データの扱い

• Supabase に残っているデータは保持（参照用）
• 新規報告は IdeasPool 経由に

削除したもの

• バグ報告フォームのコンポーネント
• バグ報告用の API ルート
• フォームの送信ロジック

残したもの

• 過去のバグ報告データ（Supabase テーブル）
• 管理画面の閲覧機能（過去データの参照用）

追加したもの

• IdeaSpool へのリンク（フッターに配置）
• 「フィードバックはこちら」の案内文

Claude Code でフォームコンポーネントと API ルートの削除、フッターへの IdeaSpool リンク追加を一気に実装しました。削除作業自体は1時間もかからず、「作るより消す方がずっと早い」と実感しました。

削除時に悩んだこと

決断は簡単ではありませんでした。

「もったいない」という感情

「せっかく作った機能を消すのはもったいない」

この感情は強かったです。バグ報告機能を作るのに、それなりの時間をかけていました。削除するということは、その時間が「無駄」になるような気がしたのです。

しかし、冷静に考えると、使われていない機能を維持するコストの方が高い。メンテナンス、セキュリティアップデート、ドキュメント... 機能が存在するだけでコストは発生し続けます。

ユーザーへの影響

「バグ報告しようとしたユーザーが困るのでは？」

これも心配でした。しかし、実際のところ、バグ報告機能はほとんど使われていませんでした。リリースから数ヶ月で、報告件数は片手で数えられるほど。

それよりも、IdeaSpool への導線を作ることで、より充実したフィードバック体験を提供できると判断しました。

機能を減らすメリット

機能を削除してから、いくつかのメリットを実感しています。

1. コードベースがシンプルになった

バグ報告関連のコードがなくなり、コードベースが少しスリムになりました。ファイル数が減り、新しく開発に参加する人（といっても自分だけですが）が把握すべき範囲が狭くなりました。

2. 認知負荷の軽減

CancelNavi のアプリ内で、ユーザーが選択できるオプションが一つ減りました。「バグを報告する」ボタンがなくなることで、画面がシンプルになり、本来の機能（解約手続きのナビゲート）に集中しやすくなりました。

3. IdeaSpool の実績につながった

CancelNavi から IdeaSpool へのフィードバック導線を設けたことで、IdeaSpool の利用事例が一つ増えました。「自分のプロダクトでも使っている」と言えることは、IdeaSpool の信頼性向上につながります。

削除の判断基準

この経験から、機能を削除すべきかどうかの判断基準を整理してみました。

削除を検討すべき状況

削除を慎重に検討すべき状況

学んだこと

開発日記に書いた学びを改めて振り返ります：

機能を「減らす」判断も重要 自分の別プロダクトと連携させることで、両方の価値が上がる 「バグ報告」という機能は、専用サービスに任せた方が品質が高くなる

「追加」より「削除」が難しい

機能を追加するのは比較的簡単です。「あったらいいな」と思えば、作ればいい。しかし、機能を削除するのは難しい。過去の投資を手放す決断が必要だからです。

でも、使われていない機能を抱え続けることは、プロダクトの重荷になります。定期的に「この機能は本当に必要か？」と問い直す習慣が大切だと感じました。

自分のプロダクト同士を連携させる

複数のプロダクトを開発している場合、それらを連携させることで相乗効果が生まれます。

CancelNavi → IdeaSpool という導線を作ったことで：

• CancelNavi のユーザーは、より良いフィードバック体験を得られる
• IdeaSpool は、新しいユーザー獲得の機会を得られる
• 私は、重複機能の開発・メンテナンスから解放される

Win-Win-Win の関係です。

「専門家」に任せる

「なんでもできる」プロダクトより、「一つのことを極めた」プロダクトの方が強い。

バグ報告という機能は、CancelNavi にとっては「あればいい」程度のものでした。しかし IdeaSpool にとっては、コア機能の一部です。専門家に任せた方が、結果的に品質が高くなります。

おわりに

機能を削除することは、後ろ向きな決断ではありません。

プロダクトを「引き算」で洗練させることは、立派な開発行為です。むしろ、不要な機能を抱え続けることの方が、プロダクトの成長を妨げるかもしれません。

「この機能、本当に必要だろうか？」

この問いを定期的に自分に投げかけてみてください。答えが「NO」なら、削除する勇気を持ちましょう。

プロダクトが軽くなると、開発も、ユーザー体験も、きっと良くなります。