プロンプトと背景
このプロダクト面接の質問では、「利用率の低さ」を検証可能なプロダクト判断へと落とし込めるかを評価します。機能の廃止（サンセット）は、ユーザージョブ、営業上のコミットメント、サポートワークフロー、エンジニアリング保守に影響を与えるため、単一の利用率の数値だけでは不十分です。問題を定義し、影響を受けるグループを特定し、保守コストと移行コストを比較した上で、段階的な検証と撤退コントロールを設計する必要があります。
面接官が見ているポイント
- 低頻度だが極めて重要なジョブと、真に価値の低い機能とを区別できているか。
- 単一の画一的な基準ではなく、セグメント、代替パス、顧客エビデンスを活用しているか。
- ディスカバリー、検証、移行、コミュニケーション、シャットダウンを段階的に設計できるか。
- 顧客価値、商業リスク、技術コスト、成功指標を総合して説明できるか。
行うべき確認の質問
まず、「3%」の背景にある分母と対象期間を明確にします。すべてのアカウントか、アクティブアカウントか、それとも機能の利用資格があるアカウントでしょうか？ユーザーの利用頻度、タスク成功率、更新状況、契約上のコミットメントはどうなっているでしょうか？その機能はAPI、エクスポート、監査、サポートワークフローなどを通じて間接的に使用されていますか？同等の代替手段は存在し、その完了率と移行コストはどの程度ですか？また、バージョンの依存関係、地域ごとのコンプライアンス要件、顧客への事前通知期間、許容されるシャットダウンの時期についても確認します。
30秒の回答フレームワーク
3%という数字だけで判断することはありません。分母、ユーザージョブ、収益やコンプライアンスへの影響を検証した上で、顧客を高価値な重要ユーザー、実用的な代替手段を持つ低頻度ユーザー、効果の上がっていない利用にセグメント化します。保守の継続、新規有効化の制限、移行、完全なシャットダウンを比較し、小規模なグループで元に戻すことが可能な移行パイロットを実施してタスク成功率を測定します。代替手段があらかじめ設定した基準を満たし、重要顧客が計画に合意し、サポートと営業の準備が整い、明確なリカバリおよび例外対応ルートが確保された段階でのみ、機能を段階的に廃止します。
ステップごとの詳細解説
1. 低利用率をユーザージョブに変換する
アカウント、ロール、地域、プラン、契約上のコミットメント、利用の直近性によってセグメント化します。ジョブ、頻度、成功率、失敗の理由を観察します。アクセスログだけでなく、APIコール、エクスポート、チケット、営業の約束、コンプライアンス記録も調査します。利用頻度が低い理由は、「極めて重要な瞬間にしか使われない」からかもしれませんし、発見しにくさやユーザー体験の不備によるものかもしれません。これらには異なるプロダクトアクションが必要です。
2. コストと代替手段の条件を定義する
保守継続、読み取り専用での保持、移行、シャットダウンのコストモデルを構築します。エンジニアリング保守、インシデントリスク、サポートトレーニング、機会費用を含め、これらを解放される開発リソース、削減される複雑性、解消されるエラーパスと比較します。単一のグローバルな導入率ではなく、タスク完了率、移行成功率、重要顧客の合意、サポート量、更新リスクなど、観察可能な代替手段のしきい値を設定します。
3. ロールバック可能なパイロットで影響を検証する
まずは社内アカウントやオプトインした低リスク顧客向けに入口を無効化します。移行ツール、エクスポート機能、人的サポートを提供し、タスク成功率、完了時間、エラー率、問い合わせ数を比較します。エンタープライズアカウントにおいてランダムな割り当てが不可能な場合は、前後比較やセグメントごとのインタビューを用い、エビデンスで確定できない点を記録します。パイロットは、広範で元に戻せない移行を行う前に、一時停止およびロールバックが可能でなければなりません。
4. 重要顧客、契約、信頼リスクに対処する
更新価値が高い顧客、明確な契約上の約束がある顧客、コンプライアンス上の依存がある顧客、実用的な代替手段がない顧客のための例外リストを作成します。カスタマーサクセス、営業、サポート、エンジニアリング、法務の間で、通知内容、移行日、データ保持期間、エスカレーション先について合意を形成します。少数の大口顧客の意見だけで全体の決定を下してはならず、平均的な数値を改善するためだけに重要なジョブを強制終了させてはなりません。例外には期限、コスト、終了条件を設ける必要があります。
5. 段階的にシャットダウンし、結果を検証する
新規顧客への機能提供を停止し、既存顧客には移行リマインダーと読み取り専用期間を提供し、最終的に書き込みとアクセスポイントを無効化します。各フェーズにおいて、一時停止基準を設けた上で、タスク完了、移行の失敗、サポートチケット、パフォーマンス、返金、更新シグナルを監視します。リリース後は、隠れたAPIコール、異常なデータアクセス、顧客による回避策の有無を確認します。コードとデータの削除は、結果が安定し、監査ログや移行ドキュメントが保持されていることを確認した後にのみ行います。
優れた回答例
3%という数値は、その機能に価値がないことを証明するものではありません。私なら分母と対象期間を検証し、アカウント価値、ユーザージョブ、契約コミットメント、利用可能な代替手段によってセグメント化し、API、チケット、営業の約束、コンプライアンスの依存関係を調査します。保守、読み取り専用での保持、移行、シャットダウンの各コストを比較し、タスク成功率、移行成功率、重要顧客の合意、サポート量に関する基準値を設定します。エクスポート、移行ツール、人的サポートを備えた小規模でロールバック可能なパイロットを実施し、高リスクな顧客には明確なコストと終了条件を設定した期限付きの例外を提供します。パイロットが成功した場合、新規の有効化を停止し、既存顧客向けの移行および読み取り専用期間を設けた上で、失敗、チケット、返金、更新を監視しながらアクセスを段階的に廃止します。実装とデータの削除はエビデンスが安定した後にのみ行い、監査ログを保持します。
よくある間違い
- 重要な瞬間でのジョブや間接的な利用を確認することなく、利用率の低さを価値の低さと決めつけること。
- アカウント価値、プラン、地域、ロール、契約でセグメント化せず、平均値のみに頼ること。
- 代替手段を見つけて検証する前に廃止を発表し、移行コストを顧客に押し付けること。
- 再現可能な行動エビデンスを、一度のインタビューや1社の大口顧客の要求で代替してしまうこと。
- 移行、読み取り専用、通知、例外、ロールバックの各段階を踏まずに機能を削除すること。
- タスクの失敗、サポート量、収益、信頼性のガードレールを無視して、削減されたエンジニアリング工数のみを報告すること。
追加の質問と回答
年に1回しか使われない機能も廃止すべきでしょうか？
頻度だけで判断すべきではありません。その利用が監査、コンプライアンス、ディザスタリカバリ、または高価値なビジネスタスクを支えているか、そして代替手段が信頼できるかを確認します。オンデマンドでの有効化、読み取り専用での保持、低コストな保守の方が適している場合もありますが、その選択にはタスク成功率とリスクのエビデンスが必要です。
重要顧客が移行を拒否した場合はどうしますか？
阻害要因が機能の不足なのか、移行コストなのか、契約上の約束なのかを特定します。限定的な個別対応、移行支援、または期間を定めた互換性維持期間を提供します。コスト、担当者、期限、終了条件を記録し、レガシーな仕組みを無期限に残さないようにします。
シャットダウンが更新に悪影響を与えなかったことをどう証明しますか？
移行完了率、重要ジョブの成功率、サポートチケット、返金、ヘルススコア、更新状況をセグメントごとに追跡し、移行していない類似アカウントや過去の期間と比較します。完全な因果関係を主張することはできませんが、事前に異常値のしきい値と一時停止アクションを定義しておくことは可能です。
エンジニアリング側がコードの即時削除を希望した場合はどうしますか？
削除によるメリットと、移行、通知、データ保持、ロールバックのリスクを1つの意思決定記録（Decision Record）にまとめます。顧客や契約上のリスクが残っている場合は、まず新規有効化を停止するか読み取り専用に移行し、移行の検証を完了させた後に削除します。終了条件を省略することなく、明確な削除日を設定することは可能です。