プロンプトと適用シナリオ
あるB2B SaaSプロダクトにおいて、ARR（年間経常収益）の12%を占める大口顧客が10週間後に契約更新を迎えます。顧客は6週間以内に独自仕様の承認監査エクスポート機能を提供することを求めており、対応されない場合は解約すると通告しています。顧客の仕様をそのまま開発する場合、エンジニア3名で8週間（計24人週）かかり、その後も毎年約6人週の保守工数が発生すると初期見積もりされています。チームが来四半期に新規プロダクト開発へ充てられる工数は30人週のみです。
エンタープライズ顧客40社にヒアリングを実施したところ、6社が「監査やコンプライアンスのチームに承認記録を提出しなければならない」という根本的な課題を共有していることが判明しました。ただし、この独自ファイル形式を要求しているのは解約を示唆している該当顧客のみです。なお、顧客シェア、タイムライン、エンジニアリング見積もりは面接ケース用の架空の前提条件であり、業界ベンチマークではありません。
候補者は、直接的な個別カスタマイズ、再利用可能なプロダクト機能の開発、アカウント固有部分の有償提供、開発の見送りのいずれかを提案しなければなりません。2026年の公開プロダクトマネージャー問題集には、大口顧客がカスタム機能なしでは解約すると迫った場合にどう対応すべきかを直接問う設問が含まれています。中国の公開面接資料でも、大口顧客のカスタマイズ要求とプロダクトの方向性、保守負担、機会費用のバランスをどう取るかが問われています。このプロダクト判断に関する質問は、B2B SaaSのプロダクトマネージャー、プロダクトリード、および大口顧客との合意形成に関わるビジネス・技術リーダーに適しています。
面接官が評価しているポイント
第1に、候補者が「顧客が解約する」という主張を検証すべき因果関係の仮説として扱えているかです。顧客は実際の監査要件で困っている可能性もあれば、単に値引き、納期の確約、あるいは交渉での優位性を求めているだけの場合もあります。優れた回答では、更新の最終意思決定者や、購買・監査・コンプライアンスの担当者に直接アプローチします。その機能がない場合に何が起きるか、代替案で更新を維持できるか、合意した成果物が提供された場合に書面で更新を確約するかを検証します。
第2に、顧客が指定した解決策から「片付けるべき用事（Job to be Done）」へ立ち戻れるかです。GitLabの公開プロダクトプロセスでは、顧客の課題と望む成果について対話を深めることが求められています。Atlassianのプロダクトマネジメント指針でも、何を開発するかを決める際に顧客ニーズを戦略、価値、労力、適合性と結びつけるよう定めています。ここでの本質的な課題は「承認の監査可能な証拠を提供すること」です。独自のファイル形式は、提供手段の1つに過ぎません。
第3に、価値とコストが比較可能な基準で算出されているかです。ARRの12%という数字は収益の集中度を示しているに過ぎません。要求を断ったからといって12%全額を失うとは限らず、また売上のすべてが利益というわけでもありません。候補者は、回避可能な顧客粗利益の損失、再利用可能なプロダクト価値、ライフサイクル全体での開発・保守コスト、そしてロードマップから押し出される成果物の機会費用を比較すべきです。不確実な各インプットには幅（レンジ）と信頼度を設定する必要があります。
第4に、プロダクトと個別プロジェクト納品との間に持続可能な境界線を引けるかです。共通の認証・認可、エクスポートモデル、監査ログの挙動はプロダクト本体に属する可能性があります。特定アカウントのみが使用するフィールドマッピング、ファイルテンプレート、ワークフローコネクタは、有償のプロフェッショナルサービス、パートナーによる導入支援、または顧客側でのデータ変換に任せるべきです。この境界線は契約書にも明記する必要があります。スコープ、価格、検収条件、知的財産、サポートレベル、変更プロセス、撤退条件を口頭の約束のままにしてはいけません。
最後に、面接官は明確な意思決定を求めています。「状況によります」や「RICEスコアで評価します」といった回答はケースの回避とみなされます。優れた回答では、選択した方針、却下した選択肢、投資を打ち切る基準、そして判断を覆す新たな証拠を具体的に提示します。
回答前の確認質問（Clarifying Questions）
- 解約の脅威には因果関係としての信憑性があるか？ 更新の意思決定者は誰か？ 監査機能の欠如は書面の更新条件になっているか？ 許容可能な代替案があれば契約を継続できるか？ 営業が伝えてきた一言は、確実な解約を意味するわけではない。
- どのような成果物であれば顧客は満足するか？ 生データ、検証可能な署名、特定のフィールド、固定のファイル形式、あるいは社内システムへの自動連携のどれが必要か？ 回答によって、プロダクト機能、設定変更、インターフェース提供、サービス納品、顧客側での変換などの選択肢が変わる。
- 納品に対してどのような商業的コミットメントが得られるか？ 顧客は条件付き更新契約の締結、契約期間の延長、導入・保守費用の支払いに同意し、明確な検収基準を受け入れるか？ 商業的コミットメントがなければ、ベンダー側が全投資リスクを負う一方で、顧客は別の理由で解約できてしまう。
- そのARR 12%の質はどうなっているか？ 粗利益率、支払い履歴、サポートコスト、アップセル余地、契約期間を精査する。売上が大きくてもサービスコストが膨大であったり、回収リスクがあったり、ターゲット市場との適合度が低ければ判断は変わる。
- ニーズはどの程度共通しているか？ 6社の顧客は同一の課題と権限モデルを共有しているのか、それとも単に要望の中に「エクスポート」という単語が含まれているだけか？ 単なるラベルの一致はプラットフォーム開発の根拠にはならない。
- 24人週の見積もりには何が含まれているか？ 調査、設計、セキュリティおよびコンプライアンスレビュー、開発、移行、テスト、リリース、運用、顧客検収、将来の保守までカバーされているか？ 初期開発の工数だけを数えると、カスタム納品コストを構造的に過小評価することになる。
- 機会費用は何か？ 本来30人週を割り当てる予定だった成果物は何か？ 影響を受ける顧客数、売上コミットメント、規制対応の期限、信頼性目標はどれか？ 「ロードマップに影響が出る」と抽象的に言うのではなく、犠牲になる具体的な成果物を特定しなければならない。
- それぞれのコミットメントを決定できる権限者は誰か？ プロダクト境界はプロダクト部門、実現可能性と見積もりはエンジニアリング部門、商業条件は営業または経営幹部、データ要件の承認はセキュリティ・法務・コンプライアンス部門が担う。プロダクトマネージャーが単独ですべてを約束することはできない。
30秒回答フレームワーク
「アカウントがARRの12%を占めるという理由だけで要求を承認することはしませんし、逆にカスタマイズを全面的に拒否する画一的なルールも適用しません。まず更新の意思決定者に対し、不足している本質的な成果物、その欠如が本当に解約につながるのか、そして開発によって条件付き更新契約が結べるのかを確認します。その上で、独自形式の要求を『再利用可能な監査エクスポートのコア機能』と『アカウント固有のアダプター』に分離し、回避可能な粗利益、共通需要のエビデンス、ライフサイクルコスト、犠牲になるロードマップの価値を比較します。本前提条件のもとでは、24人週の直接開発を却下し、再利用可能なコア機能＋有償アダプターの組み合わせを選択します。更新、検収、セキュリティ、保守の境界が期限までに契約で合意された場合にのみ開発に着手し、合意できなければロードマップを維持して限定的な代替案を提供します。」
ステップ別の詳細解説
まずは「機能開発 → 解約抑止 → 更新」の因果チェーンの検証から始めます。顧客の業務責任者、更新の意思決定者、監査・コンプライアンス担当者に個別にヒアリングを行います。現在の運用を観察し、どこで業務が破綻しているかの証拠を収集し、期限の最終リミットを特定します。その上で2つの反実仮想的な問いを立てます。「新たな手段を提供しない場合、解約の確率はどれくらいか」「選んだ選択肢によってその確率はどれだけ下がるか」。営業パイプライン上のステータスや顧客の声のトーンを、これらの条件付き確率の代用にしてはなりません。
議論を整理するために以下の計算式を用います。
期待保護価値 = 顧客の年間粗利益 ×（選択肢なしでの解約確率 − 選択肢ありでの解約確率）
目的は単に数値を飾ることではありません。各確率に幅を持たせ、裏付けとなる証拠と責任者を設定します。「明確な検収基準を満たせば更新する」という覚書（アデンダム）に署名する顧客は、口頭の警告よりもはるかに強い証拠となります。もしその機能が複数ある解約要因の1つに過ぎない場合、保護される価値を顧客のARR 12%全額と同等に見積もることはできません。
次に、課題（Job）、共通機能、アカウント固有のアダプターを分離します。本ケースでは、6社の顧客が監査可能な承認記録を必要としています。したがって、権限管理、一貫したイベントモデル、エクスポート履歴、検証可能な完全性はプロダクトのコア機能になり得ます。一方で、独自仕様のフィールド名、ファイルの並び順、社内システム固有のルールは1社のみに属するため、範囲を限定したアダプターとして扱います。ただし、この分離を行えば自動的にプラットフォーム化が正当化されるわけではありません。共通コアは、ワークフロー、データ、権限の制約が複数顧客間で実際に共通している場合にのみ成り立ちます。
実行可能な3つの選択肢を比較します。以下の工数数値はケースの前提条件に基づきます。
| 選択肢 | 初期工数 | 継続工数 | 顧客への成果 | プロダクト価値 | 主なリスク |
|---|---|---|---|---|---|
| 完全なカスタム仕様の開発 | 24人週 | 年間約6人週 | 要件に完全一致するが、6週間での納品は非現実的 | 低い。独自構造がメインプロダクトに混入する | 来四半期のキャパシティの80%を消費し、悪しき前例を作る |
| 再利用可能なコア機能＋有償アダプター | コア8人週、アダプター2人週 | アダプターに対して年間約2人週 | 6週間で合意した成果物を提供可能 | 6社に共通する課題を再利用 | 共通需要の判断が誤っていた場合の過剰プロダクト化 |
| 開発を見送り、限定的なワークアラウンドを提示 | 最大2人週 | 期間限定のマニュアルまたはサービスコスト | 今回の監査は凌げる可能性があるが、更新を確保できないリスク | ロードマップを保護 | ワークアラウンドが拒否された場合にアカウントを失う |
直接開発を選択すると、30人週中24人週（四半期キャパシティの80%）を消費します。現在の3名体制では依然として8週間を要するため、顧客が求める6週間の期限には間に合いません。再利用可能な選択肢では、エンジニア2名が4週間かけて8人週のコア機能を開発し、続いて1名が2週間でアダプターを開発します。これにより合計10人週、四半期キャパシティの約3分の1を消費して6週間での納品が可能となります。ただし、これによって押し出される計画を明示しなければなりません。プロフェッショナルサービスも無償のリソースではなく、導入、運用、サポートのコストが含まれます。社内にサービス提供体制がない場合、「サービス部門に任せる」という回答は単にリスクを他チームへ丸投げしたに過ぎません。
提示された前提条件のもとでは、直接の個別カスタマイズを却下し、「再利用可能な監査エクスポートコア＋有償のアカウント固有アダプター」を推奨します。そして5営業日目の終業時をデッドラインとする厳格な着手ゲート（条件）を設定します。具体的には、明確な検収基準を前提とした更新契約または覚書への署名、エンジニアリングによる10人週のスコープ確認、セキュリティおよびコンプライアンスによるデータ境界の承認、商業責任者によるロードマップ延期の受け入れです。いずれかの条件が満たされない場合は、限定的なワークアラウンドを選択し、プロダクト開発キャパシティは消費しません。
この判断により、6社に共通する課題のエビデンスを活用しつつ、独自形式がプロダクトのコアを汚染するのを防ぎます。プロダクトチームは共通機能を所有します。フィールドマッピングと独自テンプレートは、個別の見積もり、サポートレベル、変更管理プロセスの対象とします。契約書には、データの責任分界点、検収用サンプル、納期、費用、保守期間、重大な変更時の再見積もり条件、アダプターの廃止または標準形式への移行条件を明記する必要があります。将来のあらゆるカスタマイズへの対応を約束してはならず、導入可能性のある残り5社を確定売上としてカウントしてはいけません。
最後に、意思決定の妥当性を検証します。リリース前には、共通コアが顧客固有の分岐を持たずに共通課題を表現できているかを確認します。匿名化されたサンプルデータを用いて、認可、フィールドの網羅性、再現性のある再生成、監査人の検収基準を満たしているかをテストします。リリース後は、契約が更新されたか、顧客が実際にその機能を利用しているか、残り5社が導入または対価を支払うか、どれだけのサポート工数を消費しているか、どのロードマップ成果物が遅延したかを測定します。顧客が契約を更新したものの機能を使用しなかった場合、開発のおかげで更新できたと安易に結論付けてはなりません。アダプターの保守工数が増加し続ける場合は、価格の引き上げ、サポート範囲の縮小、または契約上の撤退条項を行使します。
再利用可能な原則は次の通りです。「解約リスクのうち変えることができる部分のみを価値として評価し、複数顧客で反復される課題のみをプロダクト化し、アカウント固有の差異と長期保守のコストは契約によって適切に配分する」。
質の高い模範回答
「ARRの12%という数字はリスクのエクスポージャーの上限値であり、開発によって確実に得られる価値とは見なしません。初日に営業と同行し、顧客の業務責任者、更新の意思決定者、監査責任者と面談します。監査可能な記録そのものが必要なのか、それとも指定のファイル形式でなければならないのか、そして機能がない場合、一時的な代替案がある場合、合意通りの納品ができた場合で更新の判断がどう変わるかを確認します。最も確実な証拠は、『解約するかもしれない』という口頭の脅しではなく、検収条件と紐付いた書面での更新条件です。
価値とコストを同一のモデルで評価します。価値側は、顧客の年間粗利益と、その選択肢によって低減される解約確率から算出します。コスト側には、初期リリース工数、年間の保守・サポート工数、そして延期されるロードマップ成果物の機会費用を含めます。顧客の仕様をそのまま開発すると24人週かかり、来四半期の開発工数30人週の80%を占有する上、6週間の納期にも現実的には間に合いません。したがって、この選択肢は明確に却下します。
調査の結果、エンタープライズ顧客40社中6社が『承認記録を監査可能にする』という共通の課題を抱えており、独自形式を必要としているのは該当顧客のみであることがわかっています。そこで、8人週を再利用可能な監査エクスポートのコア機能に、2人週を有償のアダプター開発に割り当てます。コア機能はプロダクト本体に取り込み、独自フィールドやテンプレートは明確な保守境界を持つアダプター側に閉じ込めます。この10人週の選択肢であれば6週間の納期に収まりますが、四半期キャパシティの約3分の1を消費するため、商業責任者に対してどのロードマップ項目が延期されるかを提示します。
5営業日目の終了時点を着手ゲートとして設定します。検収条件を含む更新契約または覚書の締結、10人週に収まるスコープのエンジニアリング確認、セキュリティおよびコンプライアンスの承認、そして費用・サポート・変更管理・契約終了条件の契約締結を必須とします。ゲートを1つでも通過できなければ、脅しを暗黙のロードマップコミットメントには変えさせません。その場合は、マニュアル変換を組み合わせた期間限定の標準エクスポートを代替案として提供します。
リリース後は、更新契約の締結状況、実際の機能利用状況、残り5社の導入・購買意欲、サポート時間、ロードマップの遅延を追跡します。仮に顧客が更新した場合でも、機能のおかげでARR 12%が守られたと短絡的に結論付けることはしません。事前の条件付きコミットメントと、その後の利用実績というエビデンスに基づいて、その貢献度を厳密に評価します。」
よくある間違い
- ARR 12%という数字を聞いて即座に承諾する → 収益の集中度を因果関係のある価値と混同し、解約をちらつかせれば優先度を割り込めると学習させてしまう → 解約の反実仮想、粗利益、契約コミットメント、意思決定権限を検証する。
- 「プロダクトは絶対に個別カスタマイズしない」と突っぱねる → その要望がターゲット市場における共通の課題を浮き彫りにしている可能性がある → プロダクトコアとアダプターの境界線を引く前に、反復されるワークフローや制約のエビデンスを探す。
- 顧客独自の要求全体を無理にプラットフォーム化する → 1社のアカウントの存在は、汎用アーキテクチャへの投資を正当化する根拠にはならない → 反復される顧客課題のエビデンスに裏付けられた、最小限のコアのみをプロダクト化する。
- 初版の開発工数しか計算に入れない → サポート、バージョンアップ、データ変更対応、検収作業は何年にもわたってチームのリソースを奪う → ライフサイクル全体を見積もり、価格設定や契約条件に保守コストを反映させる。
- プロフェッショナルサービスを「無料の工数」として扱う → リスクがプロダクトから導入支援やサポート部門へ移動したに過ぎない → サービスの担当責任者、キャパシティ、価格、サポートレベル、撤退条件を定義する。
- 回答として精密なRICEスコアだけを提示する → 解約確率、戦略適合性、契約上の証拠があいまいなままの推測に過ぎない可能性がある → 重要なインプットには幅と信頼度を設定し、判断を覆すトリガーを明記する。
- 更新交渉を行う前に開発を始めてしまう → ベンダー側が全リスクを負い、顧客は価格や購買方針など別の理由で解約できてしまう → 開発着手前に、明確な商業的コミットメントと検収基準を合意する。
- 提案なしで選択肢だけを並べる → 候補者がトレードオフを引き受けて意思決定できるか面接官が評価できない → 選択した方針、却下した選択肢、着手ゲート、代替案を明確に述べる。
追加質問と回答例
追加質問1：顧客がARRの30%を占めており、失注すればキャッシュフローが危機に瀕します。回答は変わりますか？
会社の許容リスク度が変化するため、検証と経営判断のスピードを大幅に上げる必要がありますが、30%であっても任意の仕様を無条件で承認してよい理由にはなりません。短期的なランウェイ（資金維持期間）と顧客の粗利益を精査し、マニュアル対応、限定的なブランチ運用、共通コア開発、完全なカスタマイズを比較します。売上集中度を下げる計画を開始しつつ、時間を稼ぐために一時的なサービスコストをより多く受け入れることは合理的な経営判断となり得ます。全社レベルの売上リスクを背負う権限を持つ責任者が例外を承認し、撤退期限を設定すべきです。
追加質問2：他の顧客はこの機能を全く必要としていません。それでも再利用可能なコアを開発しますか？
1社の独自ワークフローをプラットフォーム価値の証明として扱ってはなりません。単一アカウントのビジネスケースとして捉えます。すなわち、回避可能な粗利益が開発・継続保守・サポート・機会費用をカバーできるか、会社として意図的に受託プロジェクトを販売しているか、契約上すべての個別差異に価格を設定できているかを検討します。リターンと戦略的境界の両方が維持されるなら、隔離されたアダプターの提供は合理的かもしれませんが、ロードマップ上の再利用可能な投資であるかのように偽ってはなりません。それができなければ代替案を提示するか、要求を断ります。
追加質問3：営業がすでに「6週間で納品する」と約束してしまっていました。どう対応しますか？
最初のミスに新たな約束を重ねる前に、顧客へ伝えた正確な文言、発言の権限、顧客の認識を確認します。エンジニアリング部門は実現可能なスコープを提示し、商業責任者は納期、スコープ、価格、または補償の再交渉を行うかを判断し、法務部門は契約上のリスクを確認します。6週間で共通コアと限定的なアダプターしか作れない場合は、検収サンプルと対象外事項を書面で定義します。プリセールスのコミットメントプロセスは事後的に改善しますが、そのガバナンス対応を顧客との緊急の対話より優先させてはなりません。
追加質問4：顧客が条件付き更新を拒否し、「まず作ってくれ。話はそれからだ」と言っています。着手しますか？
その態度は、開発が解約を防ぐという仮説の信憑性を著しく低下させます。少なくとも購買プロセスの具体的な進捗、意思決定者による確認、または有償のディスカバリーフェーズの合意を取り付け、後戻りできない投資は制限します。顧客があらゆる対価の提示を拒否する場合、原則としてロードマップを保護し、既存機能と期間限定のサービス代替案を提示します。全社レベルの意思決定責任者が不確実性を明示的に引き受けない限り、口頭の脅しを10人週の投資コミットメントに変えてはなりません。
追加質問5：独自形式が機密性の高い承認データにアクセスするため、セキュリティレビューが6週間以内に完了しません。どうしますか？
セキュリティ承認は着手ゲート（必須条件）であり、売上の大きさで妥協できるスコアではありません。顧客自身の環境内で標準エクスポートを変換してもらう、あるいは匿名化された最小限のフィールドパッケージを提供するなど、データ境界を拡大しない代替案を模索します。それらの選択肢が要件を満たさない場合は、納期の再交渉を行うか開発を断ります。プロダクトマネージャーは商業的な損失を説明することはできますが、セキュリティ責任者に代わってリスクを引き受けることはできません。
追加質問6：期日通りに納品したものの、顧客が結局解約してしまいました。この決定をどう振り返りますか？
事前の因果チェーンを再構築します。誰が何をコミットしたか、検収は通過したか、機能は実際に使用されたか、価格や購買プロセスの問題が本当の原因ではなかったかを検証します。判断ミス、実行の失敗、顧客側の状況変化を切り分けます。その上で、解約確率の見積もり手法、プリセールスでのエビデンス基準、契約条件をアップデートし、開発した共通コアが残り5社の顧客に価値を提供できるかを再評価します。「顧客が悪質だった」で終わらせてはならず、また1回の失敗を理由に戦略アカウントからの要望をすべて拒否するような極端な対応も避けるべきです。