プロンプトと適用シナリオ
あなたはB2BコラボレーションSaaS製品の責任者です。次のイテレーションには6人週の開発リソースしかありませんが、3つの要望をすべて収めることはできません。
- セールスはSSOを提案しており、初期見積もりは5人週です。既存顧客1社がリリース後に契約を拡大すると述べており、セールスは同様の見込み顧客12社をリストアップしています。
- サポートは誤ってアーカイブされたプロジェクトの一括復元を提案しており、初期見積もりは3人週です。この問題は過去4週間のチケットの18%を占め、月間アクティブ管理者の約8%に影響を与えています。
- プラットフォームチームはストレージ移行を提案しており、初期見積もりは6人週です。現行バージョンは9か月後にサポートが終了しますが、移行、監視、ロールバックには少なくとも5か月かかります。
すべての数値は面接ケース用の前提条件であり、業界のベンチマークではありません。何を検証するか、異なる種類のタスクをどのように比較するか、どの要望を選択するか、そして選ばれなかったチームに何を伝えるかを説明してください。面接官はその後、ストレージのサポート終了日を前倒ししたり、SSOが1社のみを対象としていることを明かしたりするなど、制約を変更して、あなたが最初の結論に固執するかどうかを確認することがあります。
これは、ロードマップの意思決定に関わるプロダクトマネージャー、プロダクトオーナー、テクニカルリード向けのプロダクト判断力を問う質問です。2026年時点の公開面接資料でも、3つの競合する機能要望の優先順位付けは直接的なPM向けの質問として挙げられています。DoorDashの公開PM面接ガイドでも、プロダクトの優先順位付け（Product Prioritization）を独自の面接ラウンドとして設定し、データ、トレードオフ、困難な決断、そして冒頭での明確なノーススター（North Star）の提示を求めています。
面接官が評価しているポイント
第1のシグナルは、意思決定の目的を確立しているかどうかです。今サイクルがエンタープライズ拡大、リテンション、サポート効率化、あるいは必須のリスク軽減のどれを優先しているかをチームが把握するまで、収益、チケット数、プラットフォームリスク、開発コストから1つの結論を導き出すことはできません。優れた候補者は、目的があっても無視できないガードレールも特定します。
第2のシグナルは、ハードな制約を認識しているかどうかです。セキュリティ、コンプライアンス、契約上の合意、ベンダーのサポート終了、不可逆な依存関係などは、適格性の関門（ゲート）を形成します。最も遅い安全な着手時期（latest safe start date）に達した作業は、通常の機会をスコアリングする前にリソースを確保する価値があります。同時に、「サポートが9か月後に終了する」ことは、自動的に「今週開始する」ことを意味するわけではありません。最も遅い安全な着手時期を計算するには、移行、監視、ロールバック、予備期間を差し引く必要があります。
第3のシグナルは、エビデンスの質です。セールスパイプライン、サポートチケット比率、プラットフォームリスクは、本質的にそのまま比較できるものではありません。優れた回答では、顧客のコミットメントが契約上のものであるか、12社の見込み顧客が同等の商談ステージに達しているか、18%のチケットが1つの根本原因を共有しているか、8%のユーザーがクリティカルなジャーニーでブロックされているか、そして各見積もりにセキュリティレビュー、リリース作業、継続的なメンテナンスが含まれているかを検証します。
第4のシグナルは、意思決定そのものです。「RICE、MoSCoW、またはバリュー・エフォートマトリクスを使用します」と答えるだけでは不十分です。近年のプロダクト実務資料でも、1つのフレームワークですべての種類の作業を比較することはできないと警告されています。本来のRICEのガイダンスでも、依存関係や市場の必須要件（テーブルステークス）がスコア順を上書きすることを認めています。フレームワークは盲点を減らすためのものであり、推奨案、機会費用、決定を覆す条件に対する責任は候補者自身にあります。
最後に、面接官は実務的なコミュニケーションを求めています。ロードマップの決定には、エビデンス、前提条件、責任者、日程、見直しのトリガーが必要です。すべてのチームに「近いうちに」と約束することは、3つの隠れたコミットメントを生み出し、候補者が期待値を管理できる証拠にはなりません。
回答前の明確化のための質問
- このサイクルの単一の主要な成果は何ですか？ このケースでは、ストレージ移行の最も遅い安全な着手時期を条件としつつ、今四半期はエンタープライズ拡大を優先すると仮定します。
- 6人週とは何を意味しますか？ 1人のエンジニアによる6週間ですか、それとも複数人の間で代替可能な工数ですか？ レビュー、テスト、リリース作業、オンコール業務はすでに含まれていますか？ このケースでは、代替可能な総開発工数として扱います。
- 移行の最も遅い安全な着手時期はいつですか？ 9か月は確定した期限ですか、それとも早期警告ですか？ デュアルライト、検証、ロールバック、予備期間にはどのくらいかかりますか？ このケースでは、プラットフォームオーナーが今から4か月後までに着手すれば間に合うことを確認しているものの、次の計画サイクルでリソースを確保する必要があると仮定します。
- SSOに関する商業的エビデンスはどれほど確実ですか？ 契約条件として拡大が明記されていますか？ 12社の見込み顧客全員が同一の機能によってブロックされていますか？ 期待値と受注確度はどの程度ですか？ このケースでは、既存顧客の条件は確認済みであり、12社のうち4社が技術検証を完了していると仮定します。
- サポートの問題はプロダクトによる修正に値しますか？ 18%のチケットは重複排除されていますか？ そのタスクは8%の管理者にとって極めて重要ですか？ トレーニング、権限設定、ワークフロー設計が根本原因である可能性はありませんか？ このケースでは、一括復元が主な原因を解決し、データの損失は発生していないと仮定します。
- 3つの見積もりのスコープ定義は整合していますか？ SSOにはセキュリティレビューとエンタープライズ向け設定が含まれていますか？ 一括復元には監査ログが含まれていますか？ 移行にはデュアルライトとロールバック訓練が含まれていますか？ 境界条件が異なる見積もりを直接比較することはできません。
- 低コストのリスク検証で不確実性を減らせますか？ 小規模なテクニカルスパイク（調査）によって情報を得られますが、3つの要望すべてを細分化しても成果は生まれません。このケースでは、6人週の予算内で3営業日のSSOセキュリティスパイクを実施することを許容します。
- 最終決定権は誰にありますか？ PMはエビデンスに基づく推奨案を作成する必要があります。締結済み契約、規制上の義務、受け入れがたい技術的リスクがある場合は、明確な意思決定権者とエスカレーションパスが必要になることがあります。
30秒回答フレームワーク
「サイクルの目標とハードな制約、特にストレージ移行の最も遅い安全な着手時期を確認します。次に、成果、エビデンス、工数、遅延コスト、依存関係、可逆性を正規化し、同等に比較可能な機会のみをスコアリングします。本ケースでは、移行は1サイクル待つことができ、エンタープライズ拡大が最優先されるため、3営業日をかけてSSOを検証します。総工数が6人週以内に収まる場合はSSOを選択し、そうでない場合は一括復元に切り替えます。次サイクルの移行リソースを確保し、サポートには回避策と見直し時期を提示し、すべての前提条件と方針転換のトリガーを文書化します」
ステップごとの詳細解説
まず、3つの機能名を比較するのではなく、要望を成果として言い換えることから始めます。SSOはエンタープライズ拡大のブロッカーを取り除くことを目指します。一括復元は管理者の手戻りとサポートコストを削減することを目指します。ストレージ移行はベンダーの期限前に事業継続リスクを排除することを目指します。次に、サイクルの目標とガードレールを明記します。このケースでは、エンタープライズ拡大が目標であり、データの安全性、契約上の義務、移行の最も遅い安全な着手時期がガードレールとなります。
第2に、ハードな制約のゲートを構築します。すべての要望に対して4つの質問を投げかけます。遅延は法律、契約、安全基準に違反するか？ 外部の確定した期限はあるか？ 最も遅い安全な着手時期に達しているか？ 被害は後から回復可能か？ これらの回答により今サイクルでの作業が必須となる場合は、通常の機会を順位付けする前にそのリソースを確保します。ここでは、プラットフォームチームが今から4か月後までに開始すればよいと確認しているため、ゲートは発動しません。ただし、その結論にも責任者と期日が必要です。「後で」は計画ではありません。
第3に、エビデンスを正規化します。以下の表は、現在のケースのスナップショットにすぎません。
| 項目 | SSO | 一括復元 | ストレージ移行 |
|---|---|---|---|
| 想定される成果 | エンタープライズ拡大 | 手戻りとチケットの削減 | 事業継続リスクの低減 |
| 対象規模のエビデンス | 確認済みの契約拡大条件1件、技術検証済みの見込み顧客4件 | チケットの18%、月間アクティブ管理者の8% | 9か月後にサポート終了 |
| エビデンスの質 | 中 | 高 | 高 |
| 総工数 | 5人週 ＋ 3営業日のスコープ確認（合計最大6人週） | 3人週 | 6人週 |
| 遅延コスト | 今四半期の拡大が遅れる可能性 | チケットと手戻りが蓄積し続ける | 今なら1サイクル待てるが、その後急増する |
| 可逆性と依存関係 | セキュリティスコープが不利な場合は中止可能 | 段階的リリースが可能で、ロールバックも容易 | 依存関係が多く、ロールバックが高コスト |
「対象規模のエビデンス」は、単に要求元の数値を繰り返すだけではいけません。セールスのリストは、商談ステージ、契約条件、共通のニーズごとに重複を排除します。サポートデータは、根本原因、ユーザーグループ、深刻度ごとにセグメント化します。プラットフォームの期限から、実際の作業と予備期間を逆算します。情報が不足している場合は、優先度の確信度を下げる必要があります。いくら小数点以下まで精密な数値を並べても、根拠のない影響度見積もりの信頼性は高まりません。
第4に、作業内容に適した比較方法を選択します。候補が単一の目標に向かう機能の機会である場合、RICEによって対象規模（Reach）、影響度（Impact）、確信度（Confidence）、工数（Effort）を比較できます。タイミングが重要な場合は、遅延コストが役立ちます。スコープの絞り込みにはMoSCoWが役立ちます。商業的機会、体験の改善、基盤リスクが混在している場合は、まず分類して制約ゲートを適用し、残ったものに対して小さなスコアカードを使用します。スコアは議論の材料であり、「必須（must do）」の例外にはすべて文書化された理由が必要です。
第5に、1つの意思決定を下します。このケースの前提条件では、ストレージ移行は最も遅い安全な着手時期に達していません。SSOはエンタープライズ拡大に最も直接的に合致し、確認済みの拡大条件1件と技術検証済みの類似案件4件が存在します。3営業日のセキュリティおよびスコープ確認を実施します。作業全体が6人週以内に収まることが確認できれば、今サイクルをSSOに割り当てます。
明確な2つの切り替え条件を設定します。SSOの全スコープが6人週を超える場合、または拡大条件と共通の市場ニーズが検証できない場合は、作業を中止し、3人週の一括復元に切り替えます。残りのリソースは、3つ目の未完了の機能に着手するのではなく、ストレージ移行の検証に使用します。この切り替えルールにより、調査の期間を限定し、数日作業した後のサンクコスト効果による判断の歪みを防ぎます。
第6に、選ばれなかった作業を適切に扱います。次の計画サイクルにおいて、ストレージ移行のために6人週、責任者、開始日、リスクレビューを確保します。ベンダーの期限が前倒しになった場合、検証によって移行期間が延びることが判明した場合、または予備期間が合意されたバッファを下回った場合は、直ちに優先順位付けを再開します。サポートには、管理された手動の一括処理手順、チケットのタグ付け、次回の見直し期日を提供します。一時的な回避策が無期限の先送りにならないよう、深刻度と対応時間の測定を継続します。
最後に、成果の定義と振り返り（レトロスペクティブ）を行います。SSOのリリース後、ブロックされていた顧客が設定を完了したか、拡大条件が満たされたか、有望な商談が進展したか、認証エラーやサポート負荷が許容範囲内に収まっているかを確認します。合意された検証期間において、成果と当初の前提を比較します。期待した価値が現れない場合は、対象規模、影響度、確信度、工数のどこを見誤ったのかを特定します。優先順位付けのスキルとは、最初の判断を正当化することだけでなく、意思決定を修正することまで含みます。
質の高い模範回答
以下の推奨案は、プロンプトの架空のケースデータを使用しています。
「まず要望を成果に変換します。SSOはエンタープライズ拡大のブロッカーを解消し、一括復元は管理者の手戻りを削減し、ストレージ移行は事業継続リスクを抑制します。今四半期の主要な成果がエンタープライズ拡大であることを確認しつつ、セキュリティ、契約、移行の最も遅い安全な着手時期をガードレールとして維持します。
顧客1社、チケットの18%、9か月の期限を1つのスコアにまとめるのは時期尚早です。プラットフォームチームは、移行、監視、ロールバック、予備期間から逆算する必要があります。本ケースでは今から4か月後までに着手すれば安全であるとされているため、今サイクルではハードな制約ゲートは発動しません。それでも、次サイクルに向けて6人週と責任者を今すぐ確保します。セールスは契約拡大条件を検証し、12社の見込み顧客のうち何社が同一のSSO機能でブロックされているかを特定しなければなりません。現在のエビデンスは確認済み条件1件と技術検証済み見込み顧客4件です。サポートは、18%のチケットが一括復元の欠如によるものであることを示し、トレーニングや権限の問題を個別に除外する必要があります。
これらの前提に基づき、今サイクルはSSOを推奨します。エンタープライズ拡大に最も合致しており、5人週の見積もりは予算内に収まります。まず、6人週の予算に含まれる形で、最大3営業日のセキュリティおよびスコープ確認を実施します。総スコープが6人週に収まる場合はそのまま継続します。収まらない場合、または拡大条件や共通ニーズが確認できない場合は、作業を中止して3人週の一括復元に切り替えます。
選ばれなかった要望にも実行可能な対応が必要です。ストレージ移行は、次サイクルの開始予定、指名された責任者、前倒しにつながるリスクトリガーを設定してロードマップに記載します。サポートには管理された手動プロセスを提供し、次回の計画見直しまでに深刻度と対応時間のエビデンスを更新してもらいます。セールス、サポート、エンジニアリング、経営陣が同一の論理を共有できるよう、目標、エビデンス、前提条件、決定内容、切り替え条件を1ページの意思決定レコードにまとめます。
リリース後は、SSOの設定完了率、契約拡大条件の達成状況、商談の進捗、認証エラー、新規サポートチケットを確認します。合意された見直し期間において見積もり誤差を検証します。目標や確定した期限が変更された場合は再優先順位付けを行います。最初の決定は恒久的な約束ではありません」
よくある間違い
- 最初からRICEを適用する → 質の異なる作業が1つのスコアに押し込められ、確定した期限が平均値の中に埋もれてしまう → まず分類し、法務、セキュリティ、契約、依存関係、最も遅い着手時期の制約を確認した上で、機会を比較する。
- 最も声の大きいステークホルダーに従う → 組織内のパワーバランスがユーザーやビジネスのエビデンスに取って代わってしまう → エビデンスを正規化し、各要望の背後にある成果、対象規模、確信度を記録する。
- 「サポートが9か月後に終了する」ものを無条件で最優先にする → 移行とバッファを逆算しなければ、緊急性はわからない → 最も遅い安全な着手時期を計算し、責任者と見直しのトリガーを割り当てる。
- 12社の見込み顧客すべてを確実な収益として扱う → ステージ、受注確度、共通ニーズが検証されていない → 契約条件、パイプラインステージ、再利用可能な価値を確認し、不確実性に応じて確信度を下げる。
- チケット数だけで判断する → 重複、低深刻度の問題、少数の頻繁なユーザーが結果を歪める可能性がある → 根本原因、影響を受けるユーザー、タスクの深刻度、対応時間ごとにセグメント化する。
- チームを3つの要望すべてに分散させる → どれも完了させるための十分なリソースが得られず、3つの中途半端な作業とコンテキストスイッチのコストが増加する → 1つの成果を選択し、明確な終了ルールを設けた期間制限付きの検証のみを切り出す。
- すべての要望を次のリリースで対応すると約束する → 隠れたコミットメント同士が衝突し、次のサイクルに同じ問題が持ち越される → 選ばれなかったすべての項目に、ステータス、期日、責任者、再検討の条件を設定する。
- 推奨案を出さずにスコアだけを提示する → 面接官は候補者が機会費用に責任を持つ覚悟があるか判断できない → 選択内容、何を諦めるか、その理由、どのようなエビデンスがあれば覆すかを明言する。
- リリース時点で優先順位付けが正しかったと判断する → デプロイしたこと自体は、期待された価値が現れたことの証明にはならない → 当初の仮説を観察し、対象規模、影響度、確信度、工数の見積もりを振り返る。
フォローアップの質問と回答
フォローアップ1：CEOが特定の項目を最優先にするよう明示的に指示しました。それでも優先順位付けを行いますか？
それが新しい情報なのか、推奨なのか、それとも最終指示なのかを明確にし、チームが把握していない目標や制約をCEOが知っているかを確認します。決定権がCEOにある場合は、決定内容とリスクを記録して実行に移します。それでもPMは機会費用、先送りされるコミットメント、検証計画を提示すべきです。スコアカードで明確な権限を無効化することはできませんが、権限があるからといってリスクを隠蔽することは正当化されません。
フォローアップ2：3つの要望すべてのエビデンスが不完全です。終わりのない調査をどう回避しますか？
順位を変動させる可能性が最も高い未知数を特定し、調査期間を区切ります（タイムボックス）。このケースでは、SSOのセキュリティスコープと顧客の条件がSSOの適格性を決定し、ストレージの最も遅い着手時期が制約ゲートを発動させるかを決定します。これらの変数に3営業日を費やし、残りはレンジ（幅）で見積もり、分岐条件を事前に記述しておきます（結果AならXを選択、結果BならYを選択）。調査は網羅的な知識を得るためではなく、意思決定に必要な情報を購入するために行うべきです。
フォローアップ3：1社の大規模顧客の要望と、多数の一般ユーザーの問題をどのように比較しますか？
「大規模」と「多数」を、帰属可能な価値、対象規模、深刻度、戦略的適合性、確信度、工数、メンテナンス負担に変換します。大口顧客の要望が市場開拓につながる再利用可能な機能であるか、一般ユーザーの問題がコアタスクをブロックしているかをテストします。顧客数だけで優先順位が決まるわけではありません。重要業務を妨げる低頻度の問題は、頻繁に発生する軽微な不便さよりも優先されることがあります。
フォローアップ4：技術的負債が常にスコアリングで負けてしまいます。どう対応しますか？
技術的負債を、障害発生確率、デリバリーの遅延、コンプライアンスリスク、人件費、あるいはそれがブロックしている下流の作業として表現し、そのリスクが時間の経過とともにどう変化するかを示します。許容できない閾値または最も遅い安全な着手時期に達した時点で、ハードな制約としてリソースを確保します。それ以前は、期間を限定したリスク検証と将来の明確なリソース枠を設定します。短期的な収益モデルは、長期的な視野が必要な基盤作業の評価には適していません。
フォローアップ5：開発の途中で緊急の要望が入ってきました。直ちに再優先順位付けを行いますか？
同じゲートを適用します。セキュリティ、コンプライアンス、主要顧客の解約危機、または不可逆な期限であるかを確認します。ハードな制約が発動しない場合は、現在の作業を完了させる残存価値、切り替えコスト、新しい要望の遅延コストを比較します。優先順位を変更する場合は、作業の中断ポイント、作成済み成果物の扱い、変更されるコミットメントを文書化します。計画を維持する場合は、次回の見直し時期を設定します。頻繁な割り込みは、目標の不安定さや要求受け入れガバナンスの破綻を示している可能性があるため、別途トラッキングします。
フォローアップ6：SSOをリリースしましたが、契約拡大につながりませんでした。この決定をどのように振り返りますか？
意思決定レコードを階層ごとに検証します。商業的条件は本物だったか？ 見込み顧客は同一のニーズを持っていたか？ 顧客は設定を完了したか？ 実装はエンタープライズのセキュリティ要件を満たしていたか？ 観察期間は十分だったか？ その上で、判断ミスと実行ミスを区別します。対象規模や影響度が過大評価されていた場合は、今後のエビデンス基準を厳格化します。デリバリー品質が導入を妨げていた場合は、機会自体の良し悪しを判断する前に体験を改善します。振り返りは次の見積もりを変えるためのものであり、「市場が期待を下回った」で終わらせてはなりません。