プロダクトを数年運営していると、「この機能、いまも使われているのだろうか」と感じる機能が少しずつ増えていきます。特定の顧客のために急いで作った機能、試しに出してみたものの反応が薄かった機能、新しい機能に役割を引き継いだはずの古い機能などです。
こうした機能は、放っておいても目に見える問題をすぐには起こしません。しかし、不具合の調査、仕様変更のたびの影響確認、問い合わせへの対応、新しく入ったメンバーへの説明など、少しずつ手間を生み続けます。少人数で開発しているチームほど、この手間は新しい取り組みに使える時間を直接削ります。
一方で、機能をやめる判断は、作る判断よりも難しく感じられます。使っている顧客が1社でもいれば、その顧客との関係が気になります。「いつか使われるかもしれない」という期待も残ります。結果として、判断が先送りされ、機能は増える一方になります。
本記事では、機能の廃止を判断するための5つの視点、「残す」と「やめる」の間にある選択肢、そして廃止を決めたあとの進め方を、少人数でプロダクトの判断を担っている方に向けて解説します。
なぜ「やめる」判断は後回しになるのか
機能を作る・優先する・断るという判断に比べて、やめる判断が後回しになりやすい理由は、主に3つあります。
1. やめても、すぐに数字が良くなるわけではない
新しい機能は、受注や利用の増加といった成果を期待できます。機能の廃止で得られるのは、「今後かからなくなる手間」です。目に見える成果として表れにくいため、他の仕事と比べたときに優先順位が下がります。
2. 残すことの負担が見えにくい
機能を1つ残しておく負担は、1回あたりではわずかです。不具合の調査に半日、仕様変更の影響確認に数時間といった単位で、少しずつ発生します。まとまった金額や時間として示されることがないため、「残しておいても困らない」という判断になりがちです。
3. 反対の声だけが具体的に聞こえる
機能をやめると伝えたとき、困る顧客は具体的に声を上げます。一方、機能が減ることで使いやすくなる顧客や、空いた時間で作られる次の機能を待っている顧客は、声を上げません。具体的な反対と、目に見えない利益を比べることになるため、判断は現状維持に傾きます。
この3つの事情があるため、機能の廃止は「余裕ができたら考える」テーマになり、余裕ができる日は来ないまま時間が過ぎていきます。判断の基準をあらかじめ持っておくことが、先送りを防ぐ出発点になります。
機能を残し続けることで生じる4つの負担
判断の前に、残すことの負担を整理しておきます。負担が言葉になっていると、廃止を検討する理由を社内や顧客に説明しやすくなります。
- 開発の負担：仕様変更や基盤の更新のたびに、その機能への影響を確かめる必要があります。使われていない機能のために、新しい機能の設計が制約を受けることもあります。
- 品質の負担：利用が少ない機能は、不具合に気づくのが遅れます。動作確認の対象からも漏れやすく、ある日突然、顧客からの指摘で問題が分かることがあります。
- 顧客対応の負担：営業やサポートは、すべての機能について質問に答えられる状態を保つ必要があります。古い機能ほど仕様を知る人が少なく、回答に時間がかかります。
- 使いやすさの負担：画面の項目やメニューが増えるほど、新しく使いはじめた顧客は、どれが自分に必要な機能なのかを見つけにくくなります。
開発の負担については、技術的負債の考え方とも重なります。使われていない機能のコードは、返済の対象として検討する価値のある負債の1つです。
機能の廃止を判断する5つの視点
ここからが本題です。ある機能を残すか、やめるかを考えるときは、次の5つの視点で順に確かめます。
視点1：どれくらい使われているか
最初に確かめるのは、利用の実態です。見ておきたいのは次の3点です。
- 直近3か月ほどの間に、その機能を使った顧客は何社か
- 使っている顧客は、どれくらいの頻度で使っているか
- 利用は増えているか、横ばいか、減っているか
注意したいのは、機能によって自然な利用頻度が違うことです。年に1度の決算時期にだけ使う機能は、月ごとの利用が少なくても役割を果たしています。確かめる期間は、その機能が本来使われる周期に合わせて決めます。
利用データを取得していない機能もあるはずです。その場合は、判断の前に、まず1〜2か月ほど利用の記録を取りはじめることをおすすめします。印象だけで「使われていない」と判断すると、実際には特定の顧客の業務に組み込まれていた、ということが起こります。
視点2：使っているのは誰か
利用している顧客の数だけでなく、どの顧客が使っているかを確かめます。同じ「3社が利用」でも、中身によって判断は変わります。
- 現在の重点としている顧客層か、そうでない顧客層か
- その顧客にとって、契約を続ける理由になっている機能か
- 契約時に、その機能の提供を個別に約束していないか
少数であっても、重点としている顧客の業務の中心で使われている機能は、利用数だけを理由にやめる対象にはなりません。反対に、現在の重点から外れた顧客層だけが使っている機能は、利用数がある程度あっても、見直しの候補になります。
契約上の約束については、営業の担当者や過去の提案資料を確かめます。個別の約束がある機能は、廃止の判断そのものではなく、進め方と時期に影響します。
視点3：維持にどれくらいの負担がかかっているか
次に、その機能を残しておくための負担を確かめます。正確な数字である必要はなく、開発の責任者やサポートの担当者に次の点を尋ねれば、おおよその大きさは分かります。
- この半年で、その機能に関する不具合対応や問い合わせは何件あったか
- 他の機能を変更するとき、その機能があるために余分にかかっている手間はあるか
- 外部サービスの利用料など、その機能のためだけに発生している費用はあるか
利用が少なく、負担もほとんどかかっていない機能は、急いでやめる必要はありません。優先して検討したいのは、利用が少ないにもかかわらず、負担が大きい機能です。
視点4：これからの方向と合っているか
4つめは、プロダクトがこれから向かう方向との整合です。現在の利用が一定あっても、今後の方向と合わない機能は、残すほど方向転換が難しくなります。
たとえば、対象とする顧客層を絞ることを決めた場合、絞る前の顧客層のために作った機能は、今後の開発のたびに考慮する対象として残り続けます。プロダクトの方向が言葉になっていれば、「この機能は、これから力を入れる領域に含まれるか」という問いで確かめられます。
方向そのものがまだ定まっていない場合は、機能の廃止よりも先に、方向を言葉にすることに時間を使うほうが効果的です。
視点5：代わりの手段を用意できるか
最後に、その機能がなくなったとき、使っている顧客が同じ目的を別の方法で果たせるかを確かめます。
- 新しい機能や、他の機能の組み合わせで同じことができるか
- データを書き出して、表計算ソフトなどで代わりの作業ができるか
- 代わりの手段に移るとき、顧客にどれくらいの手間がかかるか
代わりの手段がある機能は、移行の案内を丁寧に行えば、廃止による影響を小さくできます。代わりの手段がなく、顧客の業務が止まってしまう機能は、利用が少なくても、廃止の前に代わりの手段を用意する必要があります。
5つの視点をどう組み合わせるか
5つの視点は、点数をつけて合計するためのものではありません。順に確かめることで、「この機能をやめた場合に、誰に、どのような影響があり、自社は何を得るのか」を言葉にするためのものです。
目安としては、視点1と視点3で「利用が少なく、負担が大きい」と分かった機能を候補とし、視点2・4・5で「やめた場合の影響と、その和らげ方」を確かめる、という順で進めると整理しやすくなります。
判断の結果は「残す」と「やめる」の2択ではない
5つの視点で確かめた結果は、残すかやめるかの2択になるとは限りません。間には、いくつかの選択肢があります。
選択肢1：そのまま残す
利用があり、方向とも合っていて、負担も小さい機能です。確かめた結果として残すと決めた場合は、その理由を記録しておきます。半年後に同じ議論を繰り返さずに済みます。
選択肢2：新しい顧客への提供を止める
すでに使っている顧客にはそのまま提供を続け、新しく契約する顧客には提供しない、という形です。画面のメニューから外し、営業資料からも外します。利用者がこれ以上増えないため、将来の廃止がしやすくなります。既存の顧客への影響がないため、最初の一歩として選びやすい選択肢です。
選択肢3：別の機能に置き換える・統合する
役割が重なっている機能が複数ある場合や、新しい機能が古い機能の役割を引き継げる場合です。顧客には「なくなる」のではなく「こちらに移る」と伝えられるため、受け入れられやすくなります。ただし、移行のための案内や、データの引き継ぎの手間は発生します。
選択肢4：廃止する
期限を決めて、機能の提供を終えます。利用が少なく、負担が大きく、方向とも合わず、代わりの手段を示せる機能が対象です。
多くの場合、いきなり選択肢4を選ぶのではなく、選択肢2で新しい利用を止めたうえで、時間をかけて選択肢3または4へ進む形が、顧客への影響を抑えられます。
廃止を決めたあとの進め方：5つのステップ
廃止すると決めたあとは、進め方が顧客との関係を左右します。判断が妥当であっても、伝え方や時期を誤ると、信頼を損ねることがあります。
ステップ1：影響を受ける顧客を1社ずつ洗い出す
利用データをもとに、その機能を使っている顧客を一覧にします。顧客ごとに、利用の頻度、契約の内容、担当の営業やサポートを書き添えます。少人数のスタートアップであれば、対象は数社から十数社に収まることが多く、1社ずつ状況を把握できます。
ステップ2：社内で理由と代わりの手段をそろえる
顧客に伝える前に、営業とサポートの担当者に、廃止の理由、時期、代わりの手段を共有します。顧客から質問を受けたとき、担当者によって答えが違うと、不信につながります。理由は、「利用が少ないため」だけではなく、「その分の開発の時間を、何に充てるのか」まで含めて伝えられるようにします。
ステップ3：よく使っている顧客には、先に個別に伝える
全体への告知の前に、利用の多い顧客や、契約上の配慮が必要な顧客には、個別に連絡します。一斉の告知で初めて知るのと、事前に担当者から説明を受けるのとでは、受け止め方が大きく異なります。
この場では、廃止を伝えるだけでなく、その機能を何のために使っているのかを尋ねます。想定していなかった使い方が分かり、代わりの手段の案内を見直すことになる場合があります。影響が想定より大きいと分かった場合は、時期を延ばす、代わりの手段を先に整えるなど、計画を調整します。
ステップ4：期限を示して告知する
全体への告知では、次の点を伝えます。
- どの機能が、いつ終了するか
- 終了の理由
- 代わりの手段と、移行の方法
- データの書き出しが必要な場合は、その方法と期限
- 問い合わせ先
告知から終了までの期間は、顧客が業務の進め方を変えるのに必要な時間から決めます。業務に組み込まれている機能であれば数か月、補助的な機能であればそれより短い期間が目安になります。契約や利用規約に、機能の変更に関する通知期間の定めがある場合は、それに従います。
ステップ5：終了し、記録を残す
期限が来たら、機能の提供を終えます。画面から見えなくするだけでなく、関連するコードやデータの扱いも、開発チームと決めておきます。画面から消しただけでコードが残っていると、開発の負担は減りません。
あわせて、廃止の判断と経緯を記録に残します。どの視点で何を確かめ、どの顧客にどのような影響があり、どう対応したかを書いておくと、次に別の機能の廃止を検討するときの参考になります。
よくある失敗
- 利用データを見ずに、印象でやめる：「誰も使っていないはず」という思い込みで終了し、あとから重要な顧客の業務が止まっていたことが分かる、という失敗です。
- 告知なしに画面から消す：利用が少ない機能でも、予告なく消えると、プロダクト全体への信頼に影響します。「他の機能も突然なくなるのではないか」という不安を生みます。
- 1社の反対で、すべてを取りやめる：反対の声が出たときに判断そのものを撤回すると、以後、どの機能もやめられなくなります。その顧客への個別の対応と、廃止の判断は分けて考えます。
- やめる理由を「利用が少ないから」だけで伝える：使っている顧客にとっては、自分が使っている以上、納得しにくい理由です。空いた時間を何に充てるのかを添えることで、受け止め方が変わります。
- 一度に多くの機能をやめる：棚卸しの勢いで複数の機能を同時に終了すると、顧客への影響の把握と対応が追いつかなくなります。まずは1つの機能で進め方を確かめるほうが安全です。
具体例：帳票の出力機能を見直したケース
従業員12名のBtoB SaaSスタートアップを想定した例です。プロダクトの判断は経営者が担っており、開発は4名の体制でした。3年前、ある顧客の要望に応えて、独自の書式で帳票を出力する機能を作りました。その後、書式を自由に設定できる新しい出力機能を追加しましたが、古い機能も残したままになっていました。
基盤の更新を進める中で、開発の責任者から「古い出力機能の改修に、2週間ほどかかる」という報告が上がりました。これをきっかけに、5つの視点で確かめることにしました。
利用データを見ると、直近3か月で古い出力機能を使っていたのは4社でした。うち3社は月に1〜2回の利用で、新しい出力機能でも同じ書式を作れることが分かりました。残る1社は、作るきっかけとなった顧客で、毎週利用していました。維持の負担としては、半年で不具合対応が3件、そして今回の改修の2週間が見込まれました。今後の方向としては、書式を顧客自身が設定できる形に寄せていく方針でした。
確かめた結果、まず新しい顧客への提供を止め、4か月後に廃止することを決めました。毎週利用している1社には、全体への告知の前に、経営者と担当の営業が直接説明しました。話を聞くと、その顧客は出力した帳票を社内の別の仕組みに取り込んでおり、項目の並び順が変わると困るという事情が分かりました。そこで、新しい出力機能に同じ並び順の設定をあらかじめ用意し、移行を手伝うことにしました。
残りの3社には、告知とあわせて、新しい出力機能での設定手順を案内しました。4か月後に古い機能を終了し、関連するコードも削除しました。基盤の更新で見込んでいた2週間の改修は不要になり、判断の経緯は記録に残しました。
よくある質問（FAQ）
Q1. 利用データを取っていない機能が多くあります。どこから始めればよいでしょうか。
すべての機能を一度に調べる必要はありません。開発の責任者やサポートの担当者に「維持の手間がかかっていると感じる機能」を3つほど挙げてもらい、その機能から利用の記録を取りはじめることをおすすめします。負担の大きい機能から確かめるほうが、得られる効果も大きくなります。
Q2. 使っているのが1社だけの機能は、やめてもよいでしょうか。
その1社がどのような顧客かによります。重点としている顧客層で、契約を続ける理由になっている機能であれば、残す、あるいは代わりの手段を整えてから移行する判断が妥当です。重点から外れた顧客で、維持の負担が大きい場合は、丁寧に説明したうえでやめる判断もあり得ます。いずれの場合も、まずその顧客に使い方を尋ねることから始めます。
Q3. 廃止を伝えたら、解約すると言われました。どう対応すればよいでしょうか。
まず、その機能を何のために使っているのかを詳しく聞きます。代わりの手段で目的を果たせる場合は、移行を手伝うことで解決することがあります。それでも難しい場合は、その顧客の重要度と、機能を残す負担を比べて判断します。時期を延ばす、その顧客にだけ一定期間提供を続けるといった対応も選択肢になります。
Q4. 機能の見直しは、どれくらいの頻度で行えばよいでしょうか。
半年に1度ほど、ロードマップを見直す機会に合わせて行うと、無理なく続けられます。その際、すべての機能を確かめるのではなく、維持の負担が気になっている機能を数個取り上げる形で十分です。
Q5. そもそも、使われない機能を増やさないためにはどうすればよいでしょうか。
新しい機能を出すときに、「どのような状態になれば成功と言えるか」と「いつ確かめるか」を決めておくことが有効です。たとえば、「公開から3か月後に、対象の顧客の3割が月に1度以上使っている状態」のように決めておけば、届かなかった場合に、改善するか、やめるかを早い段階で検討できます。作る時点で確かめる時期を決めておくと、やめる判断も先送りされにくくなります。
まとめ
機能をやめる判断は、すぐに数字に表れず、残す負担が見えにくく、反対の声だけが具体的に聞こえるため、後回しになりがちです。しかし、使われていない機能は、開発、品質、顧客対応、使いやすさのそれぞれに、少しずつ負担を生み続けます。
判断するときは、(1)どれくらい使われているか、(2)使っているのは誰か、(3)維持にどれくらいの負担がかかっているか、(4)これからの方向と合っているか、(5)代わりの手段を用意できるか、の5つの視点で順に確かめます。結果は残すかやめるかの2択ではなく、新しい顧客への提供を止める、別の機能に置き換えるという選択肢もあります。廃止を決めたあとは、影響を受ける顧客を洗い出し、社内で理由をそろえ、よく使っている顧客には先に個別に伝えたうえで、期限を示して告知します。
まずは、開発の責任者に「維持の手間がかかっていると感じる機能を3つ挙げるとしたら何か」と尋ねてみてください。挙がった機能の利用状況を確かめるところから、見直しを始められます。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
