機能クローズの考え方とプロセス

プロダクトを企画し、開発を進め、リリースを行い、ユーザーに使ってもらうという過程は非常に困難を伴います。そのため、一度リリースされたプロダクトや機能が市場の変化や仮説と異なり、当初の期待に反して受け入れられなかった場合でも、機能やプロダクトを閉じるという判断は回避されがちです。さらに、閉じることによってアップサイドが得られないため、やりたい人が不在ということも珍しくありません。

では、プロダクトや機能を閉じる判断をどのようにすべきでしょうか？本記事では、プロダクトや機能の終焉に焦点を当て、その検討プロセスや意思決定のポイントについて解説していきます。

コスト

B2CやB2Bでもコンシューマーユースの場合、フリーミアムモデルを採用し、無料で広くユーザーに利用してもらっていることが一般的です。実は、無料で展開していても、様々なコストがかかっています。まずはプロダクトを運営していく上で、少なからずかかっているコストを確認していきましょう。

1.インフラ
まずはインフラです。B2Cだと、数百万のユーザーが使う可能性があるので、サービスを提供する上で、インフラのコストも看過できません。逆にB2Bではコンシューマーユースでもない限り、あまり多くのユーザが使うことを想定していないことが多いです。ただし、Marketing Automationなど大規模なデータセットを取り扱うことを前提にしている場合があり、このケースに限っては多大なインフラコストが掛かっていることがあります。

2.セキュリティ
インフラと同じく、運用という観点で、セキュリティの監視、検証のためのツールやシステムの利用料金がかかっています。

3.サポートコスト
追加開発を行わなくても、ユーザーが利用する以上、一定のサポートが必要になります。非注力になった時点で、対象となるプロダクトや機能をメインに据えたマーケティング活動を行わなくなるので、ユーザー数が増えることはあまりないのですが、サポートが全く不要になることはありません。

ユーザーからの問い合わせがあったときに、答えられるようにしておく必要があり、目に見えにくいのですが、意外とコストがかかるので注意が必要です。

4.開発コスト
追加開発をしなくても、一定のメンテナンスが発生することがあります。そのために、仕様の概要を把握し続けておく必要があります。非注力領域になり追加開発が行われなくなると、仕様を把握していた人が退職してしまうケースがあります。この際、きちんと引き継ぎを行っていないと、そもそもメンテナンスが不可避の場合、キャッチアップから行う必要が出てしまい、多大なリソースがかかってしまいます。

5.他開発への影響
非注力となったプロダクトや機能に対して、メンテナンス以外の追加開発を行うことは稀です。しかし、他の機能の開発を行う際、非注力のプロダクトや機能があることを前提に、設計を行うことになり、場合によって不必要な複雑性を産み、開発工数が膨れてしまうことがあります。

上記のように、新たなマーケティングを行わなくても、インフラ、セキュリティ、サポートは当然発生します。また、メンテンナンスや他開発案件への影響も出てしまい、場合によって多大なコストに繋がることもあります。

意思決定のタイミング

コストを念頭に置いて、プロダクトや機能を閉じる意思決定のタイミングを具体化していきたいと思います。

まず、インフラによるコストが大きいプロダクトの場合、マネタイズやユーザー数増加に関する検証を進め、限界だと判断し、非注力に落とすタイミングで、合せて閉じるかどうかの議論を行うケースが多いです。というのも、明確なランニングコストと捉えられ、収益が出ないのに、続けることに意味を見出しにくいからです。

セキュリティ面ではコストも重要なのですが、これまでの対応では、セキュリティリスクが高まることがあります。他プロダクトやプロダクト全体でリスクが上がっていれば、まとめて対策を打つことになりますが、対象となっているプロダクトや機能におけるセキュリティだけが問題になっているケースの場合、メンテナンスの域を超えて対応を進めることは難しいと判断することが多いように思います。

次に、サポートコストだけにより緊急度が上がり、プロダクトや機能を閉じるという判断を迫られることは少ないです。サポートコストは、プロダクト上の要因に伴い、結果的にかかってくるコストなので、意思決定を左右する主たる要素になることは少ないと言えるでしょう。

逆に、開発リソースは事業拡張を進めていく上で非常に貴重な経営資源なので、対応に多大な開発リソースがかかる場合、プロダクトや機能を閉じてしまうという判断に繋がりやすいです。具体的にはすでに追加開発をしていないプロダクトや機能に対して障害が発生したり、明らかに改修しなければならない案件がありますが、多大な工数がかかってしまうケースです。 他にも、他開発案件を進めるに辺り、非注力プロダクトや機能が存在していること自体により、影響範囲を広げてしまい、設計を困難にし、結果開発リソースを逼迫してしまうことがあります。このように開発リソースへの影響が具体化したタイミングで、重要性をあげて対応を進めることが多いです。

上記のように、ランニングコストや介在しているリスク、開発リソースへの影響など、それぞれのコストの性質に応じて、プロダクトや機能を閉じる議論を進め、意思決定を行うことになります。

プロダクトを閉じるプロセス

プロダクトや機能を閉じると、社内はもちろん、ユーザにも多大な影響がある場合が多く、閉じるプロセスは慎重に進める必要があります。

1.社内での意思決定
コストの性質を明確化し、その性質に合せてリスク、重要度、緊急度を把握した上で、まずは社内で意思決定することになります。その上で、閉じる理由、対象、影響範囲、ユーザが取りうる代替手段の有無とその内容をまとめた上で、開発工数やスケジュールを踏まえた上で、閉じる日時を決めます。

2.社外コミュニケーション
そして、社内の関係者だけでなく、閉じることにより影響があるステークホルダーに広く周知を行い、社外へのコミュニケーションプランを作成します。事前にプロダクト上の告知はもちろん、場合によってプレスリリースを活用したり、対象プロダクトや機能にヘビーユーザーがいる場合は個別に説明することもあります。このとき、ユーザーから時として痛烈なフィードバックをもらうこともありますが、振り返りという観点でも、今後のプロダクト開発においても、非常に価値の高いものなので、しっかりまとめ、関係者で読み合わせを行うことをお勧めします。

3.プロダクトや機能のクローズ
最後に、プロダクトや機能を出したときと同じように、しっかり閉じたことを称賛しましょう。結果として閉じることになったとは言え、関係者は非常にタフなワークロードをこなし、リリースしたことを忘れてはいけません。そして、閉じるという作業は様々なステークホルダーからネガティブなフィードバックを受けやすく、非常に困難なプロジェクトになることが多いです。ここでしっかり称賛できないと、プロダクトや機能を閉じる意思決定ができても、実行できず、コストを垂れ流し続けてしまいます。

まとめ

多大な労力をかけてリリースした機能を閉じる意思決定を行い、具体的に閉じていくには、様々なステークホルダーによる複雑な気持ちが交錯します。その中で、冷静にコストと価値を評価し、着実に閉じることが求められます。

プロダクトマネージャーは単に機能追加をするだけではなく、時に非情に閉じる意思決定を行い、身を挺して推進することで、さらなるプロダクトの進化、プロダクトビジョンの実現を手繰り寄せるきっかけになれば幸いです。