「自社に欠けている成長の秘訣は、機能の追加ではなく、実は『機能を減らすこと』かもしれない。」こんな風に考えたことはありますか？

一般的に、企業は新しいプロダクトや機能のリリースに注力します。昇進したいPMは何をリリースしたかをアピールし、営業はそれを材料にしばらく連絡を取っていない潜在顧客に声をかけ、開発部隊を評価する際には、最近何を開発したかを見ます。

しかし、機能が増えると、顧客体験がより複雑になり、顧客のタスク完了率低下→顧客離反→売上低下という負のスパイラルに陥りかねません。その機能が利用率や売上に明確に寄与していれば良いですが、そうでない場合は、何のためにこれを維持しているのかよく分からない状態に陥ります。

また、機能の維持にはコストがかかります。そもそもプログラムの保守コストは開発コストの40%と言われており、欠陥の修復、使用環境の変更など、日々のメンテナンスを必要とします。私の周りでは、開発チームが面倒を見たくないが、引き取り手がいない機能は「Orphaned features（捨て子達）」と呼ばれていました（ヒドイ。。。）。

提供停止を判断するための5つの基準

有用な機能を時期尚早に終了すると、成長の芽を失ったり、コア顧客の怒りを買う可能性があります。一方、不要な機能を長く維持すると、貴重な時間がインパクトの低い作業に浪費されてしまいます。機能を提供停止（＝「サンセット」）すべきか、どう判断すれば良いのでしょうか？

目安として、プロダクトや機能が以下の5項目のうち3つ以上に該当する場合は、サンセットの検討が必要と考えられます：

低い利用率：顧客企業の5%未満しか使用していない
高い維持コスト：チームの時間の10%以上をメンテナンスに費やしている
顧客体験への悪影響：重要なフローの完了や新機能の追加の妨げになっている
戦略との不整合：現在の戦略に沿っておらず、1年後もそうである可能性が高い
声の大きい・コア顧客がほとんどいない：大きな反発や収益減少リスクがない

① 低い利用率

プロダクトや機能を誰も使用していないのであれば、サンセットの有力候補となります。「低い」水準とは、全顧客の5%未満が目安ですが、ローンチ前の成功の定義と照らし合わせるのが最も適切です。当時、どの程度の利用率を成功と捉え、今その基準からどれ程乖離しているか？を比較してみましょう。

利用率で気を付けたいのは、顧客が受動的に機能を使っている場合です。実はなくなっても問題ない場合は、利用率が高く見えても、より積極的にサンセットに踏み切る必要があります。本当の利用率を把握する最適な方法は、過去にそのサービスに不具合があった時、どれほど苦情が来たか？です。苦情が来ていないのであれば、残念ながら、誰もそれを必要としていないということになります。

② 高い維持コスト

サンセットの提案は、通常、ほとんど使用されていない機能のメンテナンスを担当しているエンジニアやPMから出てきます。特に、自分達で作ったものでないのに他チームから譲り受けた場合は、なおさら時間の無駄だと感じることが多いです。

「高い」コストとはどれくらいなのでしょうか？目安、チームの時間の10%を閾値として考えると良いです。10人に1人のエンジニアが投資予定のないレガシー機能のメンテナンスに費やされている場合、サンセットの有力候補と言えるでしょう。

また、新たなアーキテクチャで提供インフラを刷新する場合は、そちらへの切り替えが完了次第、速やかにレガシーシステムのサンセットを進めましょう。これにより、チームのメンテナンス負荷を下げることができます。

ソフトウェアの寿命におけるバグの月間発生数。リリース後一旦落ち着くが、古くなると次第に維持コストが上がる

③ 顧客体験への悪影響

通常、プロダクトの最初のバージョンはシンプルです。そこから、品質、体験、利便性の面でより「堅牢」になりますが、ある転換点を超えると、「堅牢」が「複雑」にいつの間にか変わってしまいがちです。

プロダクトが複雑すぎるサインは、以下のようなものがあります：

多くの機能をローンチしたが、どれも削除していない
UI上に新機能を置く物理的なスペースがない
ユーザーのタスク完了率を下げている

ある機能が一貫してユーザーの重要なタスクの達成を妨げている場合、あるいは新機能の構築を困難にしている場合は、サンセットの有力候補となります。

④ 戦略との不整合

プロダクトや機能の利用頻度が低く、メンテナンスが難しく、顧客体験を低下させていても、会社の長期戦略に必要な場合は維持する価値があるかもしれません。将来的に投資するかもしれない、あるいは顧客やメディアに対する広範なストーリーにおいて重要である可能性もあります。

例えば、Airbnbは、これまで数多くの機能をサンセットしてきていますが、Superhostプログラムは、「Hostをパートナーとして扱い、ゲストが素晴らしい宿泊場所を見つけやすくする」長期戦略に合致していました。そのため、リリース当初は特にインパクトもなく、維持に多くの労力を要しましたが、Airbnbのコア機能として継続されました。

Airbnbのスーパーホストプログラム。導入時は効果が限定的だったが、良い顧客体験に不可欠という考えのもと継続

一方、プロダクトや機能が全社戦略にあまり関係がなく、ただそこにあるだけの場合、それはサンセットの有力候補となります。

⑤ 声の大きい・コアな顧客がほとんどいない

最後に重要な検討事項は、サンセットした場合にどの程度の反発があるか？です。

（例）2011年、Netflixでは会員の10%程しかDVDをレンタルしていませんでした。同社は、DVD郵送サービス（Qwikster）を分離し、会員が2つのサイトを利用する必要があること、そしてストリーミングとDVDを両方利用する人には大幅な値上げをすることを発表しました。すると、80万人の顧客が退会し、時価総額は400億ドルから100億ドルに下落したため、そのタイミングでは結局実行せず終わりました。（最終的にDVDレンタルを止めたのは、2023年9月でした。割と最近ですね。）

また、少数の顧客にとって、その機能がどれ程大事なのかを調査することも重要です。見落としがないか確認した上で、大きな反対理由がなければ、反発を押し切る方に注力するのが得策かもしれません。それにより、顧客体験をよりシンプルで使いやすいものにできます。

サンセットは継続的な業務

サンセットは、身動きが取れなくなってからやるものではなく、継続的にモニタリング・実行していくべきものです。「常にやること」として習慣化するには、以下のようなトラッキングシートに候補を入れて定期的に議論することをおススメします。

サンセットを促すためのコツ

最後に、チーム間でサンセットを促すための5つのコツを紹介します。

① 新機能を提案する度に、削る機能も提案する（Feature In, Feature Out = FIFO）

成長を目指すとついつい機能を追加したくなりますが、複雑さが最大の問題である場合もあります。新しい機能を提案する度に、削る機能も考えることで、その視点を習慣化することができます。

② データを基本の判断基準とする

サンセットの大きな障壁は、そのプロダクトや機能への愛着、サンクコスト意識や、関係者の抵抗です。関係者間で合意したデータを基本の判断軸とすることで、「誰の意見を採用するか」という視点から離れやすくなります。

③ リバースA/Bテストを行う

意思決定が難しい場合は、新機能を展開するときと同様に、A/Bテストを行うのが効果的です。コントロール群は既存の体験、介入群はサンセット後の体験とし、その影響をデータ化することで、意思決定がしやすくなります。

④ プロダクトマーケティングの発信材料とする

プロダクトや機能のサンセットは、究極的には顧客のためにやることです。どんな考えで顧客体験を合理化しているのかを伝え、顧客の利用度に合わせて伝え方を工夫する（例：コンサルテーションを提供する）ことで、顧客の納得感が醸成できます。

尚、サンセットで最もよくある失敗は、顧客へのコミュニケーション不足です。メール、アプリ内メッセージなど、あらゆる方法で顧客にサンセットのメッセージを伝えていくことが重要となります。

⑤ サポートチームに必要な情報を提供する

最前線で顧客と話すチームは、自らサンセットの理由を理解し、それに関する変更点を顧客に効果的に伝えられるよう、準備が必要です。今後の変更の詳細な説明や、顧客へのメリット等の情報を提供し、不足している点はサポートチームがプロダクトチームに即時に相談できるようなコミュニケーション体制を用意しましょう。

あなたの会社は「プロダクトの断捨離」をしていますか？