設問の意図と対象範囲
2026年向けの公開プロダクトマネージャー面接ガイドには、「機能やプロジェクトを終了・廃止した経験について教えてください」という質問が挙げられています。ここでは、意思決定を変えるきっかけとなったデータ、埋没費用、ステークホルダーへの影響、そして得られた教訓を説明することが求められます。目的は機能の失敗を証明することではなく、価値の低い取り組みから、より重要なユーザー成果へとリソース（開発余力）を再配分できる能力を示すことです。本記事では、単一の指標に基づく機械的な終了ルールではなく、意思決定とストーリーの構成方法について解説します。
面接官が見極めているポイント
面接官は、指標を選定する前にユーザーの成果が定義されているか、そして「誰も発見しなかった」「発見されたが価値につながらなかった」「利用されたがコア体験を損なった」という状況が区別できているかを確認しようとしています。GoogleのHEARTフレームワーク研究では、目標（Goals）をシグナル（Signals）と指標（Metrics）に対応づけ、行動データと態度データを組み合わせて多角的に検証することを提唱しています。優れた回答では、追加投資に伴う機会費用、採用した可逆的なテスト手法、および終了条件が明確に述べられます。
自問すべき明確化のための問い
- 探索フェーズを終了するのか、リリースを一時停止するのか、それともすでに利用されている機能を削除するのか？ ライフサイクルによって移行やコミュニケーションのリスクは異なります。
- その機能はどのようなユーザー成果に寄与するものですか？ 目標がタスク完了時間である場合、クリック数だけを見て判断すると誤解を招く可能性があります。
- どのユーザー層を別々のコホートとして分ける必要がありますか？ 新規ユーザー、有料ユーザー、高頻度利用ユーザーでは、定着率や継続率が異なる場合があります。
- 法的、契約的、または移行に関する約束事項は存在しますか？ 閲覧専用アクセスの提供や、より長い事前通知期間が必要になる場合があります。
- その根拠は相関関係ですか、それとも因果関係ですか？ 実験、対照群、定性インタビュー、サポートチケットなどによって、得られる確信度は異なります。
30秒で答える要約例
「私は前提条件Zに基づき、ユーザー成果Yの達成を目指す機能Xを担当していました。リリース後、セグメント別の導入率、タスク成功率、カウンターメトリクスを分析したところ、データはその前提を支持しておらず、これ以上の追加投資はプロジェクトQのリソースを圧迫することが判明しました。そこで可逆的な一時停止または段階的リリーステストを実施し、移行方針についてエンジニアリング、サポート、影響を受ける顧客との合意形成を行いました。その後、機能を停止して開発リソースをQへ再配分しました。（※結果部分はご自身の実際の指標に置き換えてください。）私の得た教訓は、ディスカバリー段階で終了基準をあらかじめ定義しておくことの重要性です。」
ステップ別の回答手順
1. 継続することがなぜ価値を生み出し得るのかを定義する
目標を「初回セットアップが1セッション内で完了する」といったユーザー視点の成果として記述し、完了率、価値実感までの時間（Time to Value）、リピート利用、サポートへの問い合わせなどの観測可能なシグナルを洗い出します。GoogleのGoals-Signals-Metricsプロセスでも、収集が容易なページビュー数を成功の代用指標として安易に用いることへの注意が促されています。
2. コホートとカウンターメトリクスを用いて問題を特定する
新規ユーザーと既存ユーザー、プラン階層、プラットフォーム、利用頻度などを比較します。導入率が低い原因は、発見しにくさ（見つけやすさの欠如）にある場合もあれば、機能自体の重要度が低い場合もあります。逆に導入率が高くても、エラーや返金、サポート負荷の増大を伴っている可能性があります。ファネル分析、継続率、定性フィードバックを活用して「使われていない」のか「悪影響を及ぼしている」のかを識別し、データの網羅性やサンプル数の限界も明記します。
3. 3つの選択肢とそれぞれの機会費用を比較する
継続的な改善（イテレーション）、学習のための一時停止、そして移行を伴う終了（シャットダウン）を1つの意思決定マトリクスにまとめます。改善はアップサイドの可能性を残しますがエンジニアリングリソースを消費します。一時停止は主要な前提を低コストで検証できます。終了はリソースを解放しますが、移行、契約、信頼面でのコストが発生します。過度な精度を偽る必要はありませんが、優先順位の評価基準と不可逆的な影響を明確に示す必要があります。
4. 撤退と移行のプロセスを設計する
終了とは、単に削除ボタンを押すことではありません。新規ユーザー向けの導線を凍結し、既存ユーザー向けには閲覧やエクスポートの権限を維持し、代替手段を告知した上で、バックグラウンドジョブ、指標の集計、サポートドキュメントを順次削除します。各ステップに担当者、期限、ロールバック条件を設定します。根拠が一時停止のみを支持している場合は、それを完全な削除と呼ぶべきではありません。
模範回答
「私は小規模チーム向けのレポートエクスポート機能を担当していました。サポートを介したエクスポート作業を削減できると見込んでいましたが、リリース後にチーム規模とプランでセグメント分析を行ったところ、大規模アカウントには導入されたものの、小規模チームでは初回エクスポートの完了に至るケースがほとんどなく、失敗によるサポートチケットの増加を招いていました。簡易的なガイドを追加する小規模な実験を行った結果、主な課題はフォーマット不足ではなく権限設定の説明不足にあることが確認されました。しかし文言を修正した後も完了率は事前合意した基準値に届かず、エンジニアリングチームは並行して新しい権限モデルの開発を進めていました。そこで私は、新規受付を凍結し、既存レポートのダウンロードとデータ移行を維持しつつ、影響を受ける顧客に通知を行い、開発リソースを高頻度で利用される別レポートへ移行することを提案しました。（※成果は実際の指標に置き換えてください。）この経験からの教訓は、ディスカバリーの段階でセグメント別導入率とサポートコストを撤退基準に組み込んでおくべきだということです。」
よくある間違い
- 「利用率が低かったので削除した」で終わる → ユーザーゴールやコホートの視点が欠落 → 目標、シグナル、サンプルサイズ、カウンターメトリクスを提示する。
- 全体の平均値しか見ない → 特定層に集中したリスクが見落とされる → ライフサイクル、プラン、プラットフォームごとにセグメント化し、カバレッジを報告する。
- 一時停止をシャットダウンと呼ぶ → 移行責任が考慮されていない → 実験、凍結、読み取り専用モード、完全削除を明確に区別する。
- サンクコストを継続の正当化に使う → 過去の投資額は将来の価値を証明しない → 残りの追加コストと代替案件の機会を比較する。
- 都合のよい数値を捏造する → 深掘りの質問で破綻する → 実績値を用いるか、プレースホルダーであることを明示する。
- カウンターメトリクスを無視する → クリック数が増えていても信頼が低下している可能性がある → エラー、返金、クレーム、継続率をモニタリングする。
フォローアップ質問と発展シナリオ
高単価な顧客が依然としてその機能に依存している場合はどうしますか？
まず契約内容、移行期限、代替手段を確認し、顧客コホートごとに維持コストを算出します。閲覧専用またはエクスポートのアクセスを維持し、通知期間を延長して例外事項を文書化します。集中したリスクを全体の平均値の中に埋もれさせてはいけません。
終了を正当化するのに十分なデータが揃っていない場合はどうしますか？
最大の不確実性を、事前に設定したサンプルサイズ、観察期間、停止ルールを持つ最小限の検証可能な実験（MVE）に落とし込みます。検証中は不要不急の追加投資を凍結し、確証がないまま賭けを拡大させないようにします。
多大なリソースを投じたエンジニアリングチームが終了に強く抵抗した場合はどう対応しますか？
これまでの成果を認め、再利用可能なコンポーネントと回収不能なコストを切り分けます。その上で今後の追加投資、ユーザー成果、代替プロジェクトを比較して提示します。決定が彼らの仕事を否定するものと受け取られないよう、移行作業や再利用の検討にチームを巻き込みます。
終了後に指標が反発（悪化など）した場合はどうしますか？
復元を判断する前に、季節変動、移行の失敗、計測方法の変更がなかったかを検証します。ユーザーの成果が真に悪化している場合は、可逆的で小規模な段階的再リリースを用いながら当初の終了条件を再検証します。指標の反発があっても、安易に以前のロードマップへ戻るべきではありません。