機能追加と機能削除の非対称性

みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。

プロダクトの開発に生成AIを使うようになって、新機能の追加が以前と比べて素早く簡単になりました。

目先はそれでよいこともありますが、新機能の追加をずっと続けると、コードベースの劣化、認知負荷の増大、サポートコストの増加、テスト工数の増大、UI/UXの一貫性の欠如、新しいメンバーのオンボーディングの長期化など、さまざまな問題が起きるようになります。生成AIを使うようになって、破綻までの時間が短くなった、なんて言われたりもしていますよね。

このような問題を防ぐ唯一の方法は、不要な機能を削除することです。拍子抜けするくらい当たり前の話かもしれません。

でも、実際に、プロダクトの「機能を削除した」という話をあまり見かけないんですよね。リリースノートとかプレスリリースとかを見ても「新機能」ばかり並ぶのが普通です。

なぜこうなるかというと答えは単純で、機能の追加と削除のあいだには、構造的な非対称性があるからです。この非対称性を理解せずに機能を削除しようと号令をかけても、うまく進みません。

非対称性はいくつかの領域に分類できるので、順番に紹介していきましょう。

1. コストの非対称性

機能の追加の主要な作業は、設計と実装です。これは、生成AIを使うと短時間で終わらせることができます。一方で、機能の削除では、既存ユーザーへの影響調査、移行のサポート、データ移行、ドキュメント更新、サポート対応、場合によっては、契約書の見直しなど、何倍もの工数がかかります。しかも生成AIで済まない人間系のものも多いです。

つまり「サクッと作る」はあっても、「サクッと消す」が存在しないことになります。

2. 心理の非対称性

行動経済学の理論の1つに「損失回避」があります。「人は同額の利益から得られる喜びよりも、損失から受ける痛みを2倍以上大きく感じ、損を避けるために不合理な意思決定をする」というものです。つまり、機能削除をネガティブに考えて、それを避けるような行動をするわけです。プロダクト開発の場合、1人の「使ってるのに！」という強い声が、99人の「使ってない」という沈黙より大きく届く、という形で現れます。意思決定者に届くのは、ほぼ反対の声です（削除対象の機能を使っているユーザーを担当する営業が声をあげるのが、よくあるシーンです）。

3. 情報の非対称性

「使われている」ことは、ログを見たり、追加要望が来たりすればわかります。一方で「使われていない」ことは沈黙なのでわかりにくいんですよね（沈黙に関しては、満足と不満の度合いでも同じ話があって、不満のほうが書かれやすいです。口コミ系のサービスを見ると不満のほうが多いし、不満があるから腹いせで書くわけです）。

今どきはあまりないと思いたいですが、利用状況のログを取っていないプロダクトだと、そもそも削除の判断材料自体が存在しないことになります。結果として、追加の要望（圧力？）ばかりが届きます。

4. 政治とか評価の非対称性

機能を追加したとき、「その機能を担当したプロダクトマネージャーは◯◯さん」みたいな感じで、称賛されたり、評価されたりします。役員肝いりのプロダクトなんかも同じで、「私（役員）が主導して、新しいプロダクトを作った」みたいな感じでアピールの材料に使われます（クソです）。でも、機能の削除にはそういうのがありません。下手すると社内や既存ユーザーを敵に回す「悪者」になります。

評価制度ってだいたい新しいことをやる、アウトプットを生み出す側のプラスのほうが大きく評価されがちなんですよね。なので、「今期はこの機能を消しました」と書いても、評価がプラスになりにくいです。評価がプラスにならないことをやっても仕方ない、と考えるのはある意味当然です。

5. 依存の非対称性

機能Aの上に機能Bを作り、さらにそれをもとに機能Cを作っているとします。となると、機能Aを消したいときは、機能Bと機能Cをどうするかを考えなければいけません。

時間が経つほど、削除したい機能の上に新しい機能が積み重なって、削除コストは複利で増えていきます。 先送りすればするほど、削除はますます難しくなるわけです。

6. 時間軸の非対称性

追加の効果は短期で見えます。政治とか評価の非対称性で触れた内容のとおりです。

でも、削除の効果はどちらかというと長期的な話で、しかも数値化しにくいものも多いです。複雑性の低減、保守性の向上、オンボーディングの早さ、バグの減少などがこれにあたります。短期的な（目先の）目標管理で動いている組織だと、追加が常に勝ち、削除は常に後回しになります（リファクタリングが後回しになる組織も、同じ要因によります）。

この6つの非対称性は、放っておけば全部「機能の追加」側に有利に働きます。これを防ぐためには、意図的に逆方向の力を働かせる必要があります。単に「意識しましょう」はまったく役に立たないので、以下のような仕組みを取り入れるとよいのではないかと思います。

機能の追加時に廃止条件を決める: 「リリース後一定期間の利用率が基準値を下回ったら廃止する」といった撤退条件を検討段階で決めておく
利用ログを最初から取得する: 削除の判断材料がなければ、そもそも削除の議論が始まらない
プロダクトバックログに「機能の削除」を入れる: 「複雑性の低減」を明確な価値として合意して、それを見える化する
削除を成果とする: リリースノートに「廃止した機能」の項目を作ったり、評価の紙で機能の削除を明示したりする
プロダクトオーナーの責務として「捨てる」を明示する: Noを言うだけでなく、過去のYesを取り消すのもプロダクトオーナーの仕事（そもそも仮説が外れただけ）

ということで、生成AI時代では、機能をバンバン増やせる組織なんてまったく珍しくありませんし、それだけで競争力が高いわけでもありません。機能が多いと顧客やユーザーが喜ぶというのも傲慢な思い込みです。組織として機能を削除できることは、プロダクトの強さを維持するための道具だと捉えるといいのではないかと思います。

まぁ言うのは簡単で、やるのはとっても難しいんですがw