プロダクトマネージャー面接：自社開発か外部購入か（Build vs. Buy）をどう判断するか？

プロンプトと適用可能なコンテキスト

あなたはエンタープライズ向け電子署名機能を必要とするB2BワークフローSaaSプロダクトを担当しています。2社の戦略的顧客が4か月以内の提供を求めています。あるベンダーは8週間でローンチ可能であり、必須ワークフローの80%をカバーし、費用は年間250,000ドルに従量課金が加算されると提示しています。データエクスポートAPIと90日前の解約通知オプションを提供していますが、ホワイトラベル対応、オフライン署名、およびカスタム承認ルーティングのサポートは限定的です。社内での見積もりはエンジニア5名で9か月を要し、その後もセキュリティ、コンプライアンス、運用の継続的な対応が必要です。自社開発、外部購入、またはハイブリッドアプローチのいずれを採用するかを決定し、その推奨の根拠となるエビデンス、パイロット検証、経済性、リスク、および再検討条件を説明してください。

これは、プロダクトマネージャー（PM）、プラットフォームPM、テクニカルPM向けのプロダクト判断力を問う質問です。実際の面接では、社内製ツールとサードパーティ製ツールのどちらを選択するかをどのように決定するかが候補者に直接問われます。公式な技術ガイダンスでも、開発（Build）、購入（Buy）、再利用、および組み合わせアプローチは、ユーザーニーズ、機能要件、総コスト、統合、カスタマイズ、運用、契約、およびリプレイス/廃止を含むライフサイクル全体に関わる意思決定として扱われます。

このプロンプトに含まれるすべての数値やプロダクトの詳細は面接用の前提条件であり、業界のベンチマークではありません。エンジニア5名で9か月という見積もりは45人月に相当し、プロダクトマネジメント、デザイン、セキュリティ、法務、インフラ、継続的な運用の工数はまだ含まれていません。優れた回答とは、いずれかの選択肢が無条件に安価であると決めつけることではなく、どの前提条件が意思決定を左右し、チームがそれらをどのように検証するかを示すものです。

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

第1のシグナルは、候補者がユーザーの課題とビジネス目標から思考を始めているかどうかです。「自社のスタックを自前で保持したい」や「ベンダーのデモが良さそうだった」といった理由は、どちらも判断基準として不十分です。回答では、達成すべき顧客成果、4か月の期限、リスクにさらされている収益や維持率、およびどの機能がプロダクトの真の差別化につながるかを明確に定義する必要があります。

第2のシグナルは、譲れない要件（Non-negotiable requirements）が重み付けされた選好（Preferences）と明確に分離されているかどうかです。データレジデンシー、セキュリティ、コンプライアンス、アクセシビリティ、信頼性、法的条件、ローンチ期限などは、選択肢を即座に無効化する要因になり得ます。重み付けスコアによって、魅力的な価格設定がコンプライアンス要件の不適合を埋め合わせるような事態は許されません。

第3のシグナルは、経済的な網羅性です。自社開発のコストには、ディスカバリー、実装、インフラ、テスト、メンテナンス、インシデント対応、セキュリティレビュー、アップグレード、および45人月の機会費用が含まれます。外部購入のコストには、サブスクリプションおよび従量課金、統合費用、ベンダー管理、カスタム対応、サポートプラン、価格改定リスク、移行、および撤退コストが含まれます。1年間のライセンス料と初期の実装期間のみを比較することは、総所有コスト（TCO）の評価とは言えません。

第4のシグナルは、実践的な検証と可逆性です。優れた候補者は、規模は小さいながらも複雑な実際のワークフローを用いたパイロット検証を提案し、データエクスポートや障害時の挙動をテストし、明確なシステム境界によってベンダーロックインを制限します。また、意思決定には責任者、測定可能な前提条件、および再検討を行うための明確なトリガーが必要です。

回答前に明確にすべき質問

• 4か月以内に達成すべき顧客およびビジネス上の成果は何か？ 影響を受ける収益、解約リスク、契約上のコミットメント、および限定公開版（Limited release）で顧客が満足するかどうかを確認します。
• 真の必須ゲート（Hard gates）となる要件はどれか？ 本人確認、監査証跡、データレジデンシー、暗号化、アクセシビリティ、可用性、オフライン利用、ホワイトラベル、ルーティング、法的義務を明確にします。
• この機能のどこが差別化要素となるのか？ 署名エンジン自体はコモディティなインフラである一方、業界特化のルーティング、ポリシー、テンプレート、監査ワークフローがプロダクトの優位性を生み出している可能性があります。
• 「80%のカバー率」とは具体的に何を意味するのか？ 不足している20%を、ローンチのブロッカー、設定で対応可能なギャップ、将来のニーズ、およびベンダーの周辺で自社構築できる固有ワークフローに分類します。
• 社内見積もりの信頼性はどの程度か？ エンジニア5名で9か月という見積もりに、ディスカバリー、各種認証取得、セキュリティ、インフラ、移行、サポートツール、本番運用の責任が含まれているかを確認します。
• 予想される利用量と成長率はどの程度か？ 利用量はベンダーの経済性、キャパシティプランニング、レート制限、および自社開発が財務的に有利になる損益分岐点に影響します。
• ベンダーの運用上および商業上のリスクは何か？ サービスレベル（SLA）、セキュリティエビデンス、インシデント対応、再委託先（サブプロセッサー）、ロードマップ、価格体系、データ所有権、エクスポート品質、解約条件、ベンダー自体の存続可能性を確認します。
• 自社開発を選択した場合、どの代替プロジェクトのリソースが失われるか？ 機会費用はプロダクトの意思決定そのものであるため、遅延するロードマップ施策の期待価値と、電子署名を自社保有する価値を比較します。

30秒の回答フレームワーク

「まず顧客成果を定義し、コンプライアンス、セキュリティ、信頼性、データ管理権、および4か月の期限を必須ゲート（Hard gates）として設定します。次に、機能をコモディティな署名インフラと差別化を生むワークフローに分解し、共通の3年間という時間軸で自社開発、外部購入、ハイブリッドを比較し、機会費用と撤退コストを含めて評価します。本ケースの前提では、純粋な自社開発は期限に間に合いませんが、ベンダーを活用すれば8週間で大半のニーズを満たせます。したがって、現時点での推奨はハイブリッドアプローチです。署名エンジンは購入し、独自のルーティング、ポリシー、ユーザー体験レイヤーは自社開発します。本契約の前に、小さくとも負荷の高いパイロット検証を実施し、セキュリティ、統合、障害復旧、データエクスポート、実際の利用コストを検証した上で、再交渉、ベンダー切り替え、または内製化の拡大を判断するための前提条件とトリガーを文書化します」

この導入により、情報が完全であると見せかけることなく明確な判断を示せます。回答の残りの部分では、この推奨が必須ゲート、現実的な経済性、および撤退テストをクリアできることを証明していきます。

ステップ・バイ・ステップの詳細な回答

まず、1ページのディシジョン・コントラクト（意思決定合意書）の作成から始めます。顧客成果、決定期日、説明責任者、選択可能なオプション、必須ゲート、評価期間、前提条件、必要なエビデンス、および遅延コストを明記します。本ケースでは、2社の戦略的顧客向けに4か月以内に本番稼働可能な限定リリースを提供することを目標と仮定します。面接の前提として3年間の経済期間を設定します。これは、予測不可能な長期予測に頼ることなく、継続コストや移行コストを十分に評価できる長さです。

次に、機能を分解します。暗号署名、本人確認、証明書管理、証跡生成、ベースラインの可用性は、共通化されたコモディティインフラである可能性が高いです。一方、業界特化のルーティング、権限設定、テンプレート、例外処理、ブランディング、監査体験はプロダクトの差別化要素になり得ます。このように分解することで、チームが「電子署名」を単一の分割不可能な機能として扱うのを防ぎ、現実的なハイブリッドの選択肢を導き出せます。

スコアリングを行う前に必須ゲートを適用します：

これらのゲートを通過した選択肢のみを比較マトリクスで評価します。重み付けは設定した目標を反映させるべきであり、チームはわずかな重みの変更で結果が逆転しないかを検証する必要があります：

同じ3年間の時間軸で総所有コスト（TCO）を再構築します。自社開発の場合、45人月の見積もり、プロダクトおよびデザイン工数、セキュリティ・法務レビュー、インフラ、テスト、運用ツール、オンコール体制、サポート、メンテナンス、アップグレード、およびエンジニアが他のロードマップを後回しにすることによる機会費用を含めます。外部購入の場合、年間250,000ドルのライセンス料、予想利用量、導入費用、プレミアムサポート、セキュリティ・調達レビュー、社内での統合維持工数、カスタマイズ、価格改定シナリオ、移行および撤退費用を含めます。ハイブリッドの場合、ベンダー費用と自社が意図的に保有する薄いレイヤーの開発・運用コストを合算します。

あらゆる不確実性を無理に正確な金額へ換算しようとしないでください。エンジニア人件費、利用量の伸び、サポート負荷、移行工数には幅（レンジ）を持たせ、感度分析を実施します。例えば、「年間利用量、価格上昇率、または社内の運用負荷がどの水準に達すると推奨の選択肢が逆転するか？」を検証します。楽観的な見積もり1点のみで優位に立つ推奨案は脆弱です。

機会費用についての議論は明確に行う必要があります。5名のエンジニアが9か月間で他に何をデリバリーできたか、それらのプロジェクトがどれだけの顧客価値や事業価値を生み出したか、そして社内に希少なセキュリティやコンプライアンスの専門知識があるかを問いかけます。エンジニアの給与が既に予算化されているからといって、45人月が「無料」になるわけではありません。それは希少なリソースの配分決定です。

長期契約を締結する前に、小さくとも難度の高い1つのワークフローを対象に期限を定めたパイロット検証を実施します。実際の代表的な文書、ローンチに不可欠な最も複雑なルーティング、現実的なID・権限ロール、および本番相当のデータ量を使用します。テスト項目は以下の通りです：

1. 統合にかかる時間と最初の価値提供（Time-to-First-Value）までの期間
2. エンドユーザーおよび管理者の体験
3. セキュリティ、プライバシー、アクセシビリティ、監査証跡の適合性
4. レイテンシ、レート制限、部分障害、リトライ、重複コールバック、および障害復旧
5. 可観測性（オブザーバビリティ）とサポートのエスカレーション体制
6. データエクスポート、削除、およびベンダー撤退のシミュレーション
7. 不足している20%の機能を埋めるために必要な実際の工数

結果を見る前にパイロットの合否基準（しきい値）を定めておきます。ハッピーパス（正常系）の洗練されたデモだけでは不十分です。不足しているワークフローの1つが規制上または契約上のブロッカーである場合、「80%のカバー率」であってもローンチの観点からは実質0%と同義になることがあります。もしそのギャップが、ベンダーコアの外部で綺麗に実装可能なプロダクト固有のルーティングやブランディングであれば、ハイブリッドアプローチの優位性が高まります。

可逆性（Reversibility）は、将来の移行プロジェクトとしてではなく、プロダクト設計の一部として組み込みます。自社の標準ドキュメント、署名者、同意、ステータス、監査モデルをベンダー固有のIDから独立させて保持します。ベンダー固有のAPI呼び出しは既存の統合境界の背後に隠蔽し、状態を再構築するために必要なイベントを永続化し、エクスポートをテストし、プロバイダー停止時の縮退運転動作を定義します。契約条件には、データ所有権、エクスポート形式、データ削除、重要な仕様変更の事前通知、可能な限りの価格保護、サービスレベル（SLA）、解約条件、および移行支援を含める必要があります。

本ケースの前提条件に基づき、ハイブリッドアプローチを推奨します。4か月のコミットメントを達成するためにコモディティな署名エンジンを購入し、差別化要素となるルーティング、ポリシー、テンプレート、プロダクト体験をその周辺に自社構築します。パイロット結果によって選択を覆せるよう、最初の契約期間とスコープは限定的なものにとどめます。なお、ベンダーが必須ゲートで不適合となった場合、不足する20%にコストの高いコアブロッカーが含まれる場合、利用コストが著しく悪化する場合、あるいは独自の署名技術そのものが防御可能な競争優位性となる場合には、この推奨内容は変更されます。

ローンチ後は、ディシジョン・コントラクトと現実の実績を比較します。最初の署名完了までの時間、ワークフロー完了率、署名エラー率、サポート工数、エンジニアリング保守工数、SLAの達成状況、ワークフロー完了あたりの利用コスト、顧客の導入率、維持・拡大した収益、および新しいワークフローの追加に必要な工数を追跡します。契約更新時、または「度重なるサービス障害」「大幅な値上げ」「エクスポートの失敗」「戦略的ロードマップの衝突」「急激な利用量の増加」「コンプライアンス要件の変更」「ラッパーが第2の署名プラットフォーム化するほどの過度なカスタム開発の発生」といったトリガーが引かれた場合には、前倒しで決定を再評価します。

質の高い回答例

「私であれば、まず達成すべき成果と必須ゲートの定義から始めます。今回のケースにおける成果は、2社の戦略的顧客向けに4か月以内に本番稼働可能なリリースを提供することです。セキュリティ、コンプライアンス、データの所有権とエクスポート、信頼性、クリティカルワークフローの網羅性、および納期を譲れない条件として扱います。また、リスクにさらされている収益や顧客維持率、限定的な機能提供で顧客のコミットメントを満たせるかどうかも確認します。

選択肢を比較する前に機能を分解します。署名エンジン、本人確認、証明書、標準的な証跡はコモディティなインフラと言えます。一方で、業界特化のルーティング、ポリシー、テンプレート、権限管理、監査体験こそが当社の差別化要素になり得ます。これにより、すべて自社開発するか、ベンダーの機能をすべて購入するか、あるいはエンジンを購入してプロダクトレイヤーを自社構築するかという、3つの現実的な選択肢が生まれます。

純粋な自社開発の見積もりはエンジニア5名で9か月、すなわちプロダクト、デザイン、セキュリティ、法務、インフラ、継続的な運用工数を除いても45人月を要します。提示された前提では4か月の期限に間に合いません。ベンダーは8週間のローンチと80%のカバー率を謳っていますが、パイロット検証なしにこれらの数値を鵜呑みにしたり、スコア評価でコンプライアンスの不備を妥協したりはしません。

まず、セキュリティ、法務、データ、信頼性、およびローンチ阻害要因となるワークフローのレビューを実施します。その後、ゲートを通過した選択肢を共通の3年間という時間軸で比較します。自社開発のTCOには、実装、本番運用、メンテナンス、アップグレード、インシデント対応、および5名のエンジニアが後回しにするロードマップの機会費用を含めます。外部購入のTCOには、年間250,000ドルの費用、従量課金、統合、サポート、社内の維持管理、価格改定、カスタマイズ、撤退コストを含めます。これらに幅を持たせ、どの利用量やベンダー価格で結果が逆転するかを検証します。

現時点での私の推奨はハイブリッドです。顧客の期日に確実に間に合わせるためにコモディティな署名エンジンを購入し、独自のルーティングや体験はベンダーコアの外部に自社構築します。契約前に、現実的な権限とデータ量を用いて、小さくとも難度の高いワークフローでパイロット検証を行います。最も複雑なルーティング要件、セキュリティ証跡、アクセシビリティ、部分障害、リトライ、サポートエスカレーション、データエクスポート、削除、および撤退シミュレーションをテストします。不足している20%は、ブロッカー、設定対応、プロダクト固有の拡張機能に分類する必要があります。

自社の標準データモデルをベンダー固有のIDから独立させ、ベンダー固有のAPI呼び出しを隔離し、状態の再構築に必要なイベントを永続化し、データ所有権、エクスポート、削除、SLA、価格および仕様変更の保護、解約、移行サポートを交渉することで可逆性を担保します。初期のスコープと契約は、パイロットで問題が発覚した場合に決定を撤回できるよう、最小限にとどめるべきです。

ローンチ後は、実際の利用状況、ワークフロー完了率、エラー率、サポート工数、エンジニアリング保守工数、利用コスト、収益への影響を当初の前提と比較します。契約更新時、またはサービス障害、大幅な値上げ、コンプライアンス変更、エクスポートの不具合、急激な利用量の増加、度重なるカスタム開発が発生した際には速やかに再検討します。もしベンダーが必須ゲートを満たせなければ購入はしません。パイロットを通過し、ギャップが自社の差別化レイヤー内に収まるのであれば、ハイブリッドを採用することで、自社で保有すべきプロダクト価値を損なうことなくスピードを手に入れることができます」

よくある間違い

• 思想的な好みを前提にする → 「当社は常に自社開発する」「コモディティなソフトウェアは購入すべき」といった決めつけは、実際のユーザーニーズや制約を無視しています → 成果、必須ゲート、および差別化機能を最初に定義してください。
• 必須ゲートを加重平均スコアに含める → 価格の安さによって、セキュリティや法務要件の不適合が計算上隠れてしまうリスクがあります → 好みのスコアリングを行う前に、要件を満たさない選択肢を排除してください。
• ライセンス費用と実装工数だけを比較する → 運用、メンテナンス、機会費用、統合、カスタマイズ、撤退コストが見落とされます → すべての選択肢に対して同じ期間と完全なTCOモデルを適用してください。
• 「80%の機能カバー率」を十分な根拠とみなす → ローンチに不可欠なワークフローが1つでも欠けていれば、プロダクト全体が無効化される可能性があります → すべてのギャップをブロッカー、設定対応、拡張機能、後回し可能のいずれかに分類してください。
• ベンダーのデモを鵜呑みにする → 正常系の挙動だけでは、統合、障害復旧、監査、エクスポートの課題は見抜けません → 事前定義した基準に基づき、小さくとも難度の高い実際のワークフローでパイロット検証を実施してください。
• 社内エンジニアのリソースを無料とみなす → 既に予算化されている給与であっても、貴重なロードマップの開発リソースを消費することに変わりはありません → 45人月によって遅延するプロジェクト、価値、学習機会を具体的に挙げてください。
• 撤退設計なしに外部購入を選択する → ベンダーID、プロプライエタリな状態管理、未テストのエクスポートはベンダーロックインを引き起こします → 標準データモデルを自社保有し、統合部分を隔離し、エクスポートをテストし、移行条件を交渉してください。
• 一時的な事実に基づいて恒久的な決定を下す → 利用量、価格体系、コンプライアンス、機能、戦略は変化します → 前提条件を記録し、測定可能な再検討トリガーを設定してください。

フォローアップ質問と回答例

フォローアップ1：ベンダーが必須のコンプライアンス要件を1つ満たしていませんが、半年後には対応すると約束しています。どう対応しますか？

ロードマップ上の口頭約束を現時点のエビデンスとして扱ってはなりません。その要件が初期顧客にとって法的に、または契約上必須であるかを確認します。必須である場合、そのベンダーはゲート不通過となります。選択肢としては、別のプロバイダーを探すか、影響を受けるデータを処理しない縮小版でローンチするか、顧客とのコミットメントを再調整することが挙げられます。一時的な社内統制で代替することは、セキュリティおよび法務の責任者が承認し、残余リスクが明確に許容されている場合にのみ認められます。

フォローアップ2：財務部門から「エンジニアには既に給与を払っているのだから、外部ベンダーは高すぎる」と言われました。どう反論しますか？

給与の会計処理を議論するのではなく、リソース配分のトレードオフを示します。今回の見積もりでは自社開発に少なくとも45人月を消費し、他のロードマップ施策の価値提供を遅らせることになります。さらにインフラ、セキュリティ、コンプライアンス、サポート、オンコール、メンテナンス、アップグレードの工数も加算されます。その上で、3年間の総コストレンジと、ベンダーのライセンス料、利用料、統合費用、撤退コストを比較します。結果として自社開発が正しい判断になることもありますが、「既に雇っている」からといってリソースが無料になるわけではありません。

フォローアップ3：利用量が予想を大幅に上回るペースで増加し、ベンダー費用が見合わなくなってきました。直ちに自社開発へ切り替えますか？

まずはユニットエコノミクス、契約ティア、ボリュームディスカウント、および切り替えコストを検証します。実績ボリュームをもとにベンダーと再交渉し、競合ベンダーを比較し、本番運用で得た知見をもとに自社開発の見積もりを更新します。コスト増加が文書化されたトリガーを繰り返し超え、社内で安全に運用できる機能であると判断された場合は、自社で保有するシステム境界の背後で段階的な移行を開始します。場当たり的な緊急の再開発は、一時的に高いベンダー費用を支払うよりも高くつく可能性があります。

フォローアップ4：エンジニアから「不足している20%にこそ、最も価値ある顧客体験が含まれている」と主張されました。判断は変わりますか？

それらのギャップが自社のルーティング、ポリシー、インターフェースレイヤー内で綺麗に実装できるのであれば、ハイブリッドアプローチの妥当性を強めることになります。一方で、その拡張のために署名エンジン内部への非サポートの改変が必要だったり、クリティカルな状態管理が重複したり、将来のアップグレードを阻害する脆弱なワークアラウンドを生み出す場合は、ベンダー採用の妥当性が弱まります。パイロット検証を通じて実際の拡張工数とメンテナンス境界を測定し、その上で推奨案をアップデートします。

フォローアップ5：ハイブリッドアーキテクチャが長期的に見て誤った選択になりつつあると、どのように判断しますか？

ベンダーの度重なるインシデント、ワークフロー完了あたりの単価悪化、エクスポートの失敗、ロードマップの不一致、コンプライアンスのギャップ、そしてカスタム開発が肥大化して並行する巨大プラットフォームになりつつないかを注視します。また、社内のサポートやエンジニアリング工数が当初の前提と乖離していないかも比較します。複数のトリガーが継続して発生し、再評価した自社開発案または別ベンダー案が同じ必須ゲートをクリアできる場合は、計画的な移行スケジュールを組みます。可逆性とは、エビデンスに基づいて軌道修正できることを意味するのであり、切り替えがノーコストでできるという意味ではありません。