プロダクトマネージャー面接：機能の提供終了（サンセット）をどのように判断するか？

質問と想定シナリオ

あなたはB2BアナリティクスSaaSを担当しています。レガシーなPDF定期送信メール機能は、アクティブワークスペースのわずか3%にしか月次で利用されていませんが、そのユーザーには全社ARRの18%を占めるエンタープライズ顧客14社が含まれています。そのうち9社は今後6か月以内に契約更新を迎えます。この機能は古いレンダラーに依存しており、四半期ごとに約3人月のエンジニア維持コストが発生し、レポート関連のサポートチケットの22%を占めています。

同社はレガシーワークフローの約80%をカバーするダッシュボードサブスクリプション機能をローンチしましたが、カスタムブランディングや添付ファイル配信にはまだ対応していません。レガシー機能を維持するか、再投資するか、新規拡大を停止するか、あるいは最終的に提供終了（サンセット）とするかを判断してください。検証すべきデータ、移行計画、コミュニケーションの頻度、成功指標、および一時停止条件を説明してください。

すべての数値は面接用の前提条件であり、業界のベンチマークではありません。3%の利用率は機能を削除すべき根拠にはならず、18%のARRも永久に維持すべき根拠にはなりません。候補者は、低い利用率の背後に隠された依存関係を明らかにし、維持と移行の総コストを比較し、不可逆的な削除をテストや一時停止が可能な一連の意思決定プロセスへと落とし込む必要があります。

2026年のプロダクトマネージャー向け質問集でも、どのプロダクトを改善し、どのプロダクトを廃止するかを問う質問は依然として出題されています。別のPM面接評価基準では、データを用いてどのように機能をサンセットしたか、利用頻度の低さと小規模セグメントにとっての価値をどう区別したか、抵抗にどう対処したか、混乱をいかに最小限に抑えたかが明示的に問われます。これは、ポートフォリオのトレードオフ、顧客セグメンテーション、ライフサイクル判断、部門横断的な実行力を試すプロダクト上の問いです。

面接官が評価するポイント

第一に、候補者がデータ定義を検証しているかという点です。優れた回答では、3%の分母にすべてのアクティブワークスペースが含まれているのか、機能権限を持つワークスペースのみなのか、あるいは初期設定を完了したものだけなのかを確認します。また、APIコール、管理者による手動送信、スケジュールジョブが、測定対象となっているUIパスをバイパスしていないかもチェックします。不適切な分母や不完全なテレメトリは結論を無効にします。

第二に、導入率（利用頻度）と依存度（価値）を切り離して考えられるかです。月に1回送信されるコンプライアンスレポートは、頻度は低くても監査や取締役会のプロセスにおいて不可欠な場合があります。セグメンテーションは、平均イベント数だけでなく、ワークフローの重要度、移行の難易度、アカウント価値、契約上のコミットメント、契約更新のタイミングを考慮する必要があります。

第三に、現実的な選択肢を比較できているかです。回答は「維持」か「削除」の二者択一にとどまるべきではありません。

• 現行機能を維持する。
• 修復または再構築する。
• メンテナンスモードに移行し、既存の依存ユーザーをサポートしつつ新規導入を停止する。
• 移行期間中に代替機能のギャップを埋める。
• 少数の顧客向けに期限付きの例外を設けながら段階的に廃止する。

第四に、移行を1つのプロダクトデリバリーとして扱っているかです。期日を発表しただけでは移行は完了しません。優れた回答では、代替機能のギャップ、アカウント担当者、データエクスポート、移行ツール、通知の受領確認、サポート導線、コホートごとのシャットダウン、ロールバックの判定基準を定義します。

第五に、収益とプロダクトの健全性の間の緊張関係を解決できるかです。14社でARRの18%を占めているため、即座の強制停止はリスクが高すぎます。一方で、この機能は年間約12人月を消費し、レポート基盤の統合を妨げています。候補者は「顧客が重要だから」や「技術的負債が大きすぎるから」で終わらせず、現時点の推奨策と、それを変更し得るエビデンスを提示する必要があります。

回答前に確認すべき明確化のための質問

• 3%という分母とテレメトリは信頼できるか？ UIのクリックのみを測定し、スケジュール、API、管理者設定が漏れている場合は、判断を下す前にデータを修正します。
• 顧客はこの機能でどのようなジョブ（目的）を達成しているか？ コンプライアンスのアーカイブ、外部クライアントへの送付、社内週次レポート、単発の試用では、中断に伴うコストが大きく異なります。
• エンタープライズ顧客14社の依存度はどの程度深いか？ 継続利用ユーザー、散発的ユーザー、移行可能だがまだ実施していない顧客を分類します。
• 18%のARRは相関関係か、直接起因しているか？ 機能を利用しているからといって、契約総額がその機能に依存しているとは限りません。解約意向、更新リスク、契約上の約束を検証します。
• 不足している20%には何が含まれているか？ ブランディングや添付ファイルが契約上の必須条件である場合、80%のカバレッジでは廃止を正当化できません。限定的な移行ブリッジを用意することで判断が変わる可能性があります。
• レガシー機能の総コストはいくらか？ 年間12人月に加え、インシデント、サポート、セキュリティ、アクセシビリティ、インフラ、ロードマップの機会費用を含めます。
• セキュリティ、コンプライアンス、データ整合性のリスクはあるか？ 重大なリスクがある場合は前倒しでのシャットダウンが正当化されます。通常の保守コストだけでは、適切な事前通知と移行プロセスを省略する理由にはなりません。
• 契約や顧客通知に関する制約はあるか？ 更新時期、利用規約、調達時の約束によって、アナウンスのタイミング、例外措置、最終シャットダウンの順序が決まります。

30秒回答フレームワーク

「利用率が3%であることだけを理由に機能を削除することはしません。ユーザー層にARRの18%を占めるエンタープライズ顧客が含まれており、代替機能に重要なギャップがあるためです。テレメトリと適切な分母を検証した上で、ワークフローの重要度、切り替えの負荷、契約内容、更新リスクに基づいて14社の顧客をセグメンテーションします。

現状の事実に基づき、まずは新規顧客へのレガシー機能の販売および有効化を即座に停止し、メンテナンスモードへ移行します。並行して約4週間の依存関係監査と移行パイロットを実施し、ブランディングや添付ファイルのギャップを解消できるか判断します。最終期日をアナウンスするのは、代替機能がクリティカルなワークフロー、エクスポート、信頼性、契約レビューをクリアし、依存度の高い顧客があらかじめ定義した移行ゲートを満たした後です。

直近で更新を迎える9社には個別プランを提供し、一時停止条件を設けたコホート単位で移行を進めます。重要なギャップを経済的に埋められない場合、あるいは想定解約額や移行コストが削減可能な保守・機会費用を上回る場合は、期日を強制するのではなく、機能を限定したバージョンの維持や再構築の再検討を行います。」

ステップごとの詳細解説

ステップ 1：「低利用率」を検証済みの依存関係マップに変換する。

単一の集計ダッシュボードに頼るのではなく、アカウントレベルの台帳を作成します。

機能を使っていないユーザーにもヒアリングを行います。ニーズ自体がないのか、機能を発見できないのか、設定でつまずいたのか、体験が不十分なのかを判断します。根底にあるニーズは広く存在するにもかかわらず、発見性や信頼性の問題（修正可能）によって導入が進んでいないのであれば、廃止よりも再投資の方が合理的な場合があります。

ステップ 2：選択肢を比較する前にハードゲート（必須関門）を定義する。

最終的なシャットダウンは、以下が満たされるまで進めてはなりません。

1. 利用データが意味のあるすべてのトリガーパスをカバーしており、既知の重大な欠落がないこと。
2. 契約、法的義務、コンプライアンス、データ保持要件がレビュー済みであること。
3. 依存するクリティカルなワークフローに、許容可能な代替手段または顧客承認済みの移行パスがあること。
4. 顧客が必要な過去データをエクスポートでき、チームがエクスポートとリカバリのリハーサルを完了していること。
5. 代替機能の信頼性、権限管理、アクセシビリティ、サポート体制が本番環境レベルにあること。
6. 影響を受けるすべてのエンタープライズアカウントに担当者、進捗ステータス、エスカレーション経路が設定されていること。

セキュリティ、重大な信頼性、またはデータ整合性の問題がある場合はスケジュールの短縮が可能ですが、その場合でも会社は理由を説明し、移行パスを提供する必要があります。一部のパブリックAPIポリシーでは正式な通知期間が規定されています。例えば、Atlassianのパブリックアクセス可能なクラウドREST APIに関する一般的なルールでは、重大なセキュリティ、信頼性、データ整合性の問題による例外を除き、元の形式を最低6か月間利用可能に保ちます。これは特定のポリシー例であり、すべてのプロダクト機能に適用される普遍的な期限ではありません。

ステップ 3：維持、再構築、メンテナンスモード、廃止を比較する。

ここでAWSが公開しているライフサイクルの定義が参考になります。「メンテナンス」は既存ユーザーをサポートしつつ新規オンボーディングや機能強化を停止すること、「サンセット」は既存ユーザーに移行を促し終了期日を設けること、「完全シャットダウン」はサービスとサポートを完全に終了することです。段階を踏むことで、面接の回答において非推奨化（デプリケーション）と即時削除を同一視してしまうミスを防ぐことができます。

現在の前提条件に基づくと、推奨策はメンテナンスモードへの移行と、その後の移行ゲートに基づくサンセットです。全体で3%という導入率と年間約12人月の保守コストは長期的投資を縮小する根拠となりますが、18%のARR、9社の直近更新、20%の機能ギャップがあるため、即時シャットダウンは受け入れられません。

ステップ 4：可逆的なアクションで推奨策を検証する。

最終期日を発表する前に以下を実行します。

1. 新規顧客への機能有効化を停止し、営業の提案項目から削除する。
2. エンタープライズ顧客14社すべてとワークフローをレビューし、ブランディング、添付ファイル、データ保持、権限のギャップを洗い出す。
3. 初期設定、過去データのエクスポート、配信、サポートを含め、依存度レベルが異なる顧客で移行パイロットを実施する。
4. 期日によって失敗のエビデンスが無視されないよう、実行前に移行ゲートと一時停止条件を文書化する。

パイロットでは、配信成功、受信者体験、添付ファイルとブランディングの正確性、権限、監査ログ、リトライ動作、サポート量、完了時間など、エンドツーエンドのジョブをテストする必要があります。単純なユースケースの顧客でのみ検証された代替機能では、80%をカバーしているという主張を証明したことにはなりません。

ステップ 5：セグメントごとに異なる移行パスを提供する。

アカウントを4つのグループに分類します。

• 現在の実質的な利用がない層：通知とエクスポートへのアクセスを維持しつつ、機能を非表示にする。
• 代替機能で完全にカバーできる低依存層：セルフサービス移行とリマインダーを提供する。
• ギャップを埋められる高依存層：プロダクトチームおよびカスタマーサクセスによる支援を提供する。
• 契約や重大なギャップでブロックされている層：ギャップ解消、更新、または解約の判断期日を定めた期限付き例外を付与する。

通知には、変更内容、理由、最終利用可能日、代替手段、移行手順、データアクセス方法、サポート窓口を明記します。高価値顧客に対しては一斉送信メールだけで済ませてはなりません。担当者が各顧客の影響理解を確認し、移行計画への合意を記録します。機能にAPIや自動化が含まれている場合は、レスポンス、変更履歴（チェンジログ）、開発者ドキュメントを通じても非推奨化やサンセットを検知できるようにします。

ステップ 6：ステージゲートと一時停止条件を活用する。

実行可能なステップ例は以下の通りです。

重要なワークフローが失敗した場合、エクスポートが不完全な場合、代替機能の信頼性が不十分な場合、サポート負荷が計画を大幅に超過した場合、解約意向があらかじめ定義したリスク上限を超えた場合、または法務・コンプライアンス上の問題が未解決の場合はプロセスを一時停止します。一時停止時には、ギャップの解消、特定コホートの期間延長、期限付き例外の付与、推奨策の変更の中から新たな選択を行います。なし崩し的に恒久的な機能維持へと戻してはなりません。

ステップ 7：経済性全体を比較する。

維持コストには、年間約12人月、レポート関連サポートチケットの22%、レガシーレンダラーによるインシデントおよびインフラリスク、エンジニアを新規レポート基盤に移行できない機会費用が含まれます。廃止コストには、代替機能の開発、移行ツール、カスタマーサクセスおよびサポート業務、一時的な並行運用、そして発生し得る値引き、解約、契約上の補償が含まれます。

18%のARRすべてを「廃止による損失」として計上してはなりません。未解決のギャップが原因で解約する顧客、移行する顧客、支援のみを必要とする顧客をそれぞれ見積もります。また、代替機能にも保守が必要なため、12人月のすべてを「廃止による削減額」として計上することも避けます。以下のシナリオ幅を比較します。

• クリティカルなギャップを妥当なコストで解消できるか。
• 関連する収益のうち、真にリスクにさらされているのはいくらか。
• 並行運用はどのくらいの期間続くか。
• 解放されたリソースはどのような高価値業務に充てられるか。
• 例外措置によってレガシーコストの削減が妨げられないか。

ステップ 8：シャットダウン期日ではなく、移行の成果を測定する。

主たる測定指標は、通知の送信完了ではなく、依存ワークフローの完了であるべきです。以下を追跡します。

• 真に依存しているアカウントおよびスケジュールジョブの移行完了率。
• 代替機能における配信成功率および重要タスクの完了率。
• 残存するレガシー利用および未確認アカウント数。
• レポート関連サポートチケット、移行リクエスト、エスカレーション数。
• 影響を受ける顧客の契約更新、解約意向、契約リスク。
• 過去データのエクスポート成功率およびデータ保持作業の完了状況。
• 実際に削減されたレガシーインシデント、保守工数、解放されたエンジニアリソース。

シャットダウン後は、バックグラウンドジョブ、エントリポイント、権限、フィーチャーフラグ、ドキュメント、営業時の約束事項、サポート用プレイブック、監視アラート、不要なデータコピーを削除します。過去データは合意された保持ポリシーに従って処理します。ボタンを非表示にしただけで運用上の責任をすべて残したままでは、機能廃止の本来の価値を得ることはできません。

高評価となる回答例

「まず、3%という数値を検証します。分母は権限があり関連するレポートニーズを持つワークスペースであるべきであり、UI外のスケジュールジョブやAPIトリガーが含まれているかを確認します。次に、ワークフローの重要度、切り替えの難易度、契約上のコミットメント、更新タイミングに基づいて14社のエンタープライズ顧客をセグメンテーションします。月1回しか使われないコンプライアンスレポートでも、頻度は低くても極めて重要な場合があります。

機能を即座に停止することはしません。四半期あたり3人月を消費し、レポート関連サポートチケットの22%を発生させているため、維持には長期的なコストがかかります。一方で、そのユーザーはARRの18%を占め、9社が間もなく更新を迎え、代替機能にはブランディングと添付ファイル配信が不足しています。私の推奨はメンテナンスモードへの移行です。新規の有効化や営業での提案を停止し、重大な問題のみを修正し、依存関係の監査と移行パイロットを開始します。

ブランディングと添付ファイルが契約上または重要ワークフロー上の必須要件であるかを特定し、依存度レベルの異なる顧客ごとに移行を進めます。パイロットでは、単なる機能チェックリストの比較ではなく、配信、権限、監査性、障害復旧、過去データのエクスポート、サポート運用を検証します。各エンタープライズアカウントに担当者を配置し、直近で更新を迎える顧客には個別プランを用意します。

最終期日をアナウンスするのは、代替機能がクリティカルなワークフローをクリアし、契約およびコンプライアンスのレビューが完了し、データのエクスポートが可能となり、高依存顧客があらかじめ定めた移行ゲートを満たした後です。まずは低リスクなコホートから移行し、重要タスクの失敗、エクスポートの不備、信頼性不足、許容できない解約リスクが発生した場合は次のコホートを一時停止します。

経済面では、年間12人月の保守、サポート、インシデント、ロードマップの機会費用と、代替機能のギャップ解消、移行作業、並行運用、想定される解約を比較します。18%のARRすべてが失われるわけではなく、12人月すべてが純削減になるわけでもないため、シナリオ幅と顧客からのエビデンスを用いて推奨策を更新します。

クリティカルなギャップを経済的に埋められる場合は、段階的なサンセットを完了させます。それらが代替不可能な契約要件である場合、あるいは想定される移行損失が解放される価値を上回り続ける場合は、機能を限定したバージョンの維持や再構築の再検討を行います。シャットダウン後は、ジョブ、コード、ドキュメント、営業資料、アラート、データ管理責任を削除し、チームがレガシースタックから完全に脱却できるようにします。」

よくある間違い

• 利用率3%を見て即座に削除する → 分母、頻度、ワークフローの重要度が誤っている可能性があります → まずデータを検証し、依存度でセグメンテーションする。
• 18%のARRを見て永久に維持する → 関連収益と直接起因する収益は異なり、技術的・機会費用は発生し続けます → 実際の解約リスクを検証し、経済性全体を比較する。
• 80%のカバレッジを移行準備完了と見なす → 不足している20%に契約上またはコンプライアンス上のブロッカーが含まれている可能性があります → 機能数ではなく個別のワークフローを検証する。
• 「維持」か「削除」の二者択一しか提示しない → メンテナンスモード、移行ブリッジ、期限付き例外の選択肢が失われます → 不可逆的な削除を段階的な意思決定プロセスに分解する。
• 代替機能の設計前に期日を発表する → 締め切りによって失敗のエビデンスが無視される恐れがあります → まずゲート、パイロット、一時停止条件を定義する。
• すべての顧客に同じメールを送る → 依存度の高いエンタープライズアカウントには、影響の確認、担当者のアサイン、エスカレーション経路が必要です → 依存度と商業的影響度に応じてコミュニケーションをセグメンテーションする。
• 通知の送信完了を成功と見なす → 顧客がメッセージを受け取っても移行を完了していない可能性があります → ワークフローの移行、タスクの成功、ガードレール指標を測定する。
• UIを隠しただけで完了とする → ジョブ、コード、データ、ドキュメント、営業の約束が運用責任として残ります → ライフサイクルのクリーンアップと振り返りを完了させる。

追加の質問と回答例

追加質問 1：最大の顧客が「この機能が削除されたら解約する」と言っています。どう対応しますか？

これが確定的な解約条件なのか、交渉上のポジションなのか、移行リスクへの懸念なのかを見極めます。代替不可能なワークフロー、契約条項、リスクにさらされる収益を特定し、ギャップの解消、移行支援の提供、期限付き例外の付与、限定バージョンの維持を比較検討します。大口顧客1社によってスケジュールが変更されることはあっても、無期限の例外が自動的に認められるべきではありません。いかなる例外にも、価格、サポート範囲、担当者、終了条件を設定する必要があります。

追加質問 2：レガシーレンダラーに重大なセキュリティ脆弱性が見つかりました。当初のスケジュールを維持できますか？

当初のタイムラインを機械的に維持してはなりません。セキュリティ責任者と協議し、リスクを隔離できるか、パッチを適用できるか、影響範囲を制限できるかを判断します。許容できないリスクである場合は、新規ジョブの停止、利用範囲の制限、またはシャットダウンの前倒しを行います。その場合でも、エクスポート手段、代替ワークフロー、および通知期間が短縮された明確な理由を提供します。緊急のリスクはスケジュールを変更させますが、顧客を移行させる責任を免除するものではありません。

追加質問 3：代替機能が80%を超えるカバー率を達成できない見込みです。サンセットを中止すべきですか？

そのギャップが真に依存しているワークフローと一致しているかをマッピングし、ブリッジを構築することで別のレガシーシステムが生まれないかを検討します。ブランディングや添付ファイルが限定的な移行レイヤーで処理できるなら、廃止を進めることができます。ギャップに代替不可能なコンプライアンス要件やコアな配信要件が含まれている場合は、限定的なレガシーバージョンの維持、クリティカルな機能の再構築、または別の代替手段へと方針を転換します。パーセンテージの数値だけで判断することはできません。

追加質問 4：利用データが信頼できないにもかかわらず、エンジニアチームが旧コードの削除を強く求めています。どう進めますか？

まず新規導入の拡大を停止し、ログ、スケジュール、APIコール、サポート履歴、カスタマーサクセスの知見、請求アカウントを照合します。低リスクのアカウントに対して可逆的な非表示化や移行パイロットを実行することは可能ですが、依存関係が不明な状態での完全削除は危険です。信頼できる台帳を迅速に作成できない場合は、「利用が確認されない」を「誰も使っていない」と解釈せず、データの不確実性をブロッカーとして扱います。

追加質問 5：2社の顧客が永久的なアクセスを要求しています。専用バージョンを作成すべきですか？

得られる収益と、セキュリティパッチ、インフラ、オンコール対応、テスト、担当者の知識維持を含む長期的なフォーク（個別ブランチ）の維持コストを比較します。標準の代替機能、有償移行、または期限付き例外の提供を優先します。長期的な専用バージョンの維持が合理的なのは、契約額と戦略的重要性が運用責任を持続的にカバーし、会社がそれを正式なプロダクトコミットメントとして承認する場合に限られます。一時的な例外措置が、なし崩し的に無期限のレガシーシステムになってはなりません。