日本語

中規模市場のCEOのためのBuild vs. Buy vs. Partnerフレームワーク

Key Facts: Build vs. Buy vs. Partnerの意思決定

  • 内部のbuild見積もりは、メンテナンス、統合、機会費用を考慮すると実際のコストを40〜60%過小評価します（Deloitteのtotal cost of ownership調査）。
  • M&Aディールの70〜90%は期待された価値を提供できず、統合コストは常にディールサイズの20〜30%を超えます（McKinseyのpost-merger integration調査）。
  • 戦略的パートナーシップの約半数が3〜5年以内に解消または期待を下回り、その主な原因はロードマップの不一致と責任の曖昧さです（PwCの戦略的アライアンス調査）。
  • Buildパスはエンジニアの見積もりの2〜3倍の時間がかかります（コアではないケイパビリティに対し、スコープクリープと競合する優先事項が積み重なることで）。
  • Partner優先の戦略は、差別化につながらないケイパビリティに対してbuildより6〜10倍速く市場投入を実現します。これは中規模市場の価値が失われるか獲得されるかの分岐点です。

100〜300人規模の企業のCEOなら誰もが、ある時点で同じような会話に直面します。競合他社が顧客から問い合わせが来ているケイパビリティをリリースしました。CTOはbuildしたいと言います。CFOはまさにこれをやっているスタートアップがあると言及します。パートナーシップ担当の責任者は60日で統合できるベンダーがいると思っています。そして取締役会は次の会議までに計画を知りたいと思っています。

これがbuild vs. buy vs. partnerの意思決定です。これはCEOとして行う最も高リスクの判断の一つです。答えが複雑だからではなく、誤った答えが18ヶ月のコストになるからです。また、現在の組織構造で選んだパスを実際に実行できるかどうかという並行した問いとともに浮上することが多いです。

失敗パターンは誤った選択をすることではありません。どの選択が実際に正しいかを明らかにする分析を行う前に選択することです。HBRのmake-or-buy意思決定の調査は、どのパスが持続的な価値を生み出すかを決定する3つの構造的な力を特定しています。

なぜこの意思決定は見た目より難しいのか

各部門のリーダーはそれぞれのバイアスをこの会話に持ち込みます。エンジニアはbuildを好みます。創造的で、恒久的で、ケイパビリティを示します。CFOはアクイジションに反射的な懐疑心を持ちます。アクイジションプレミアム、統合リスク、earn-outの問題は経験済みです。ビジネスデベロップメントのリーダーはパートナーシップを好みます。コミットメントが少なく、協調的に感じられ、人員承認が不要です。

これらのバイアスのどれも間違ってはいません。しかし、それらは戦略的分析ではありません。

本当の複雑さは、3つのパスすべてに意思決定の18ヶ月後にしか見えない隠れた移行コストがあることです。Buildは内部のベロシティが予想より遅く、ケイパビリティを維持するための組織的負債が積み重なるために失敗します。Buyは文化的統合コストが過小評価され、買収されたチームが離脱するために失敗します。Partnerはサードパーティのロードマップへの依存が最終的にプロダクト戦略から乖離するために失敗します。

フレーミングの問題もあります。ほとんどのエグゼクティブはこれをバイナリとして扱います。build対buyです。パートナーシップパスはほぼ後付けとして加えられます。しかし中規模市場企業では、特に重要だが差別化につながらないケイパビリティに対して、パートナーパスがしばしば最も活用されていない選択肢です。

このフレームワークが答えるように設計された問いは「今最も安いオプションはどれか?」ではありません。それは: 3年後に組織のケイパビリティの重心をどこに置きたいか?

Core・Context・Commodityの判断テスト

4ステップフレームワークを実行する前に、10秒のフィルターを使ってケイパビリティを分類します。Core（顧客が対価を払う競争上の差別化の源泉）、Context（運営に重要だが顧客には見えない）、またはCommodity（誰でも提供できる基盤的なもの）のどれか。Coreのケイパビリティはbuildする権利を得ます。Contextのケイパビリティは通常buyを正当化します。そしてCommodityのケイパビリティはほぼ常にパートナーシップまたはサブスクリプションに属します。そうしないことが、中規模市場企業が静かにエンジニアリングキャパシティを消耗する原因です。

4ステップの意思決定フレームワーク

ステップ1: 戦略的重要性と差別化ポテンシャル

まず、ケイパビリティを2×2のマトリクスに配置します。

軸1: 戦略的重要性（低〜高）: このケイパビリティはコアのバリュープロポジションにとってどれほど中心的か? 顧客体験はそれに依存しているか? 失うと売上がリスクにさらされるか?

軸2: 差別化ポテンシャル（低〜高）: このケイパビリティをベンダーが提供するものより意味のある形で優れたものとしてbuildできるか? これが競争上の参入障壁になるバージョンはあるか?

象限が方向性を示します。

差別化ポテンシャル低 差別化ポテンシャル高
戦略的重要性高 Buy or Partner Build
戦略的重要性低 Partner or 廃止 Buy（必要な場合）

ケイパビリティが戦略的に重要だが差別化できない場合、buyまたはpartnerはほぼ常に正しい選択です。エンジニアの時間は最も希少なリソースです。汎用的なインフラのbuildに使わないでください。

ケイパビリティで本当に差別化できるなら、buildが参入障壁を作る方法です。しかし、本当に差別化できるかどうか、それともbuildを正当化するために自分に言い聞かせているだけかについて、正直でなければなりません。

ステップ2: 能力習得までの期間の分析

差別化マトリクスが方向性を示します。しかし能力習得までの期間が、その方向性を負担できるかどうかを示します。

各オプションについて見積もります。

  • Build: 顧客が対価を払うか依拠するバージョンができるまでどのくらいかかるか?（正直に: 内部見積もりは通常2倍楽観的です）
  • Buy: 買収されたケイパビリティがプロダクトとチームに完全に統合されるまでどのくらいかかるか?（統合作業、文化の定着、チームの残留不確実性を考慮してください）
  • Partner: 統合がライブになり顧客がアクセスできるまでどのくらいかかるか?（法務、技術統合、パートナーへの依存を考慮してください）

最速のオプションとbuildオプションの時間差が12ヶ月以上あり、そのケイパビリティが戦略的に重要であれば、buildはほとんどの場合正しい選択ではありません。単に遅延しているだけでなく、リスクにさらされています。

120人のSaaS企業は分析モジュールを評価する際にこれを発見しました。Build見積もり: 堅固なv1まで14ヶ月。サードパーティのSDK統合: 8週間。タイムラインが紙に書き出されると、意思決定はより明確になりました。

ステップ3: 3年間のtotal cost of ownership

ここでほとんどのエグゼクティブチームが表面的な計算に欺かれます。

Buildは最初のcapexが既に支払っている給与であるため安く見えます。しかし実際のTCOには、エンジニアリングのメンテナンス、buildしなかった他の機能の機会費用、専門スキルが必要な場合の採用、そして市場が進化するにつれてケイパビリティを最新の状態に保つコストが含まれます。

Buyはアクイジションプレミアムが見えるため高く見えます。しかしこれには統合コスト（ディール価値の20〜30%が多く、McKinseyのM&A統合調査が一貫して検証する数字）、統合中のマネジメントの時間、潜在的な報酬パッケージ、そして買収した組織から引き継ぐ組織的負債のコストが含まれます。

Partnerは他社のインフラに対価を払うため最も安く見えます。しかしこれには、成長に伴いスケールするライセンスコスト、パートナーがシステムをアップグレードしたときの統合メンテナンス、パートナーが買収または方向転換した場合の戦略的依存リスク、そして内部ケイパビリティの漸進的な侵食が含まれます。

各オプションの3年間のTCO比較表を作成します。直接コスト、間接コスト（マネジメントの時間）、そして各パスの失敗モードについての誠実なアセスメントに基づいたリスク調整済みコストを含めます。特にソフトウェアケイパビリティについては、SaaSのための厳密なTCOモデルがここで適応できる財務構造を提供します。

300人の専門サービス会社がコンプライアンスケイパビリティを評価する際にこのエクササイズを行いました。Buildの表面的なコストは$800Kでした。現実的な失敗モード調整を含む3年間のTCOは$240万でした。コンプライアンスSaaSとのパートナーは既知の依存リスクで$38万でした。意思決定は異なる会話になりました。

ステップ4: 各パスに対する組織の準備状況

最後のステップが最も不快です。なぜならCEOが各オプションを実行するための組織の現在のキャパシティについて正直でなければならないからです。これは人員の構造と密接に関連しています。大きなケイパビリティ投資はしばしば、並行して人員の意思決定が必要です。

Buildについて: このbuildに必要な人材はいるか、それとも採用が必要か? 現在のエンジニアリングチームにキャパシティはあるか、それともこれが他の優先事項を排除するか? これを担当できるプロダクトマネジメントのケイパビリティはあるか?

Buyについて: アクイジションを統合したことがあるか? 2つの企業を同時にマネジメントできるリーダーはいるか? 現在のマネジメントチームにビジネスを運営しながら統合トラックを担当するキャパシティはあるか?

Partnerについて: パートナーシップを組成・管理できるBD機能はあるか? 以前に戦略的ベンダー関係をうまく管理したことがあるか? 統合を維持するための内部技術ケイパビリティはあるか?

ほとんどのエグゼクティブチームは3つのパス全てに対して組織の準備状況を過大評価します。自身の楽観論に懐疑的でいてください。

実践例: 2つのケース

ケース1: 120人規模のSaaS企業における分析機能

120人のB2B SaaS企業は、エンタープライズの見込み顧客からembedded analyticsの要求に直面していました。プロダクト内で利用データとトレンドを確認する機能です。CTOの最初の直感はbuildでした。「私たちのデータモデルは誰よりも理解している。サードパーティのツールはスキーマにきれいにマッピングされることはない。」

フレームワークを実行すると異なる状況が明らかになりました。

  • 差別化ポテンシャル: 中程度。分析機能は戦略的に重要でしたが、コアのバリュープロポジションではありませんでした。顧客は革新的な分析ではなく、機能する分析を求めていました。
  • 能力習得までの期間: BuildはエンタープライズレディなものまでTCO 14ヶ月。サードパーティのSDK統合は完全に機能する分析スイートを埋め込むまで6〜8週間。
  • 3年間のTCO: Build は現実的に$180万。SDKライセンスは$24万/年（顧客数に応じてスケール）。Partnerで3年: $72万（既知のベンダー依存つき）。
  • 組織の準備状況: Build に対して低い（2人のシニアエンジニアはすでにキャパシティ一杯）。Partnerに対して中程度（以前に1つのベンダー関係を管理した経験あり）。

意思決定: Partner。8週間でembedded analytics SDKを統合し、分析機能の要件でブロックされていた3件のエンタープライズ契約を獲得し、エンジニアリングをコアプロダクトの差別化に再配分しました。

ケース2: 300人規模の専門サービス会社におけるコンプライアンス機能

専門サービス会社は異なる問題に直面していました。規制業界のクライアントが、同社が持っていないコンプライアンスコンサルティングのケイパビリティを求めていました。コンプライアンスチームを採用する（build）、小規模なコンプライアンス専門会社を買収する（buy）、またはコンプライアンスSaaSベンダーと提携する（partner）の選択肢がありました。

フレームワークから明らかになったこと。

  • 差別化ポテンシャル: 高い。既存の顧客関係と業界知識から、汎用SaaSにはできない方法でコンプライアンス業務を差別化できました。
  • 能力習得までの期間: Buildは信頼性のあるコンプライアンスチームを採用してオンボーディングするまで9〜12ヶ月。10人のブティックのアクイジション: 統合を含めて4〜6ヶ月。Partner: 60日でライブだが差別化は限定的。
  • 3年間のTCO: Build は$210万。アクイジションはプレミアムと統合を含めて$340万。Partner は戦略的依存リスクを含めて$38万。
  • 組織の準備状況: Build に対して高い（以前にプラクティスをbuildした経験あり）。アクイジションに対して低い（M&A経験なし）。

意思決定: Build。8ヶ月かけて4人のコンプライアンス専門家を採用し、2件の既存顧客関係で新しいプラクティスを立ち上げ、14ヶ月以内に収益性の高いコンプライアンス部門を持つようになりました。

エグゼクティブが犯す失敗

Build対buyとして扱う。 ほとんどのエグゼクティブの会話はパートナーシップパスを真剣に評価することなく終わります。差別化につながらないケイパビリティに対して、うまく構造化されたパートナー関係はほぼ常に最もROIの高い選択肢です。

パートナーシップを管理するコストを過小評価する。 パートナーシップは自然に管理されません。リレーションシップオーナー、統合のメンテナンス、12〜24ヶ月ごとの再交渉が必要です。そのキャパシティがなければ、パートナーシップのコストは見た目より高くなります。

内部のbuildベロシティを過大評価する。 複雑なケイパビリティに対するエンジニアの見積もりは設計上楽観的です。予想外の複雑さ、競合する優先事項、または顧客が最初のバージョンを見て生じるスコープ変更ではなく、buildを見積もっています。Deloitteのtotal cost of ownership調査は、内部のbuild見積もりがメンテナンスと統合コストを40〜60%過小評価することを一貫して示しています。

buildの機会費用を考慮しない。 エンジニアリングチームが差別化につながらないケイパビリティに費やすすべての時間は、実際に案件を獲得するケイパビリティに使われない時間です。これはTCO分析にほとんど現れない隠れたコストです。AIはこの緊張を鋭くしています: AIケイパビリティはbuild-vs-buyの計算を変えつつあります。これは24ヶ月前には当てはまらなかったことです。

意思決定メモのテンプレート

取締役会にこれを持ち込む前に、1ページの意思決定メモを作成します。

ケイパビリティのギャップ: [このギャップを解消しない場合の戦略的影響を含む具体的なケイパビリティの説明]

評価したオプション: Build / Buy / Partner

推奨: [オプション] と [具体的な実装アプローチ]

3年間のTCO比較:

  • Build: $ / 前提条件: [3つの主要な前提条件のリスト]
  • Buy: $ / 前提条件: [3つの主要な前提条件のリスト]
  • Partner: $ / 前提条件: [3つの主要な前提条件のリスト]

主要なリスク:

  • Build リスク: [具体的なリスクと軽減策]
  • Buy リスク: [具体的なリスクと軽減策]
  • Partner リスク: [具体的なリスクと軽減策]

ゴー・ノーゴーの判断基準: [特定の条件]が発生した場合、[期間]以内にこの意思決定を見直します

ケイパビリティまでのタイムライン: [ケイパビリティが顧客向けに稼働する予定日]

ゴー・ノーゴーの判断基準は、ほとんどのメモが省略する部分です。すべての戦略的意思決定には見直しが必要な条件があります。トリガーが最初に明確であれば、もはや意味をなさないパスに縛られることなく、推奨事項に基づいて迅速に行動できます。

このフレームワークが答える問い

Build vs. buy vs. partnerはコストの意思決定ではありません。ケイパビリティ戦略の意思決定です。MIT Sloan Management Reviewの論文が主張するように、最も持続的な競争優位は、所有するケイパビリティとアクセスするケイパビリティを意図的に選択することから生まれます。問いは「今最も安いオプションはどれか?」ではありません。「3年後に組織のケイパビリティの重心をどこに置きたいか、そして最も少ない実行リスクでそこに到達するパスはどれか?」です。

これを正しく行う企業は、差別化できる場所にmoatをbuildし、それ以外はpartnerとし、buildより速くケイパビリティが必要なときはbuyします。誤った企業はすべてのケイパビリティのギャップをbuildの問題として扱い、差別化につながらない業務でエンジニアリングキャパシティを使い果たし、最高の人材が内部インフラに時間の半分を費やしている理由を不思議に思います。

上記のフレームワークは意思決定を代わりにしてくれません。しかし、コミットする前に正しい問いを明らかにします。それが通常、時間の経過とともに良くなる意思決定と、2年後もまだ取締役会に説明し続けている意思決定の違いです。

Reworkでクロスチームプロセスとしてフレームワークを実行する

Build vs. buy vs. partnerの意思決定は、分析がCEOの頭の中や単一のスライドデッキに存在するときに失敗します。TCOの数字は財務から、能力習得までの期間はエンジニアリングから、組織の準備状況はHRから、パートナーシップの実現可能性はBDから来ます。各部門が異なるタイミングで異なる断片を見ています。

Rework Work Ops（月額$6/ユーザーから）はフレームワークを共有の意思決定ワークスペースに変えます。ケイパビリティの意思決定ごとにプロジェクトを作成し、4つのフレームワークのステップを並行したワークストリームとして割り当て、同じ構造に対して各部門のインプットを収集できます。差別化マトリクス、TCOテーブル、準備状況アセスメント、いつものバージョン管理ドキュメントの混乱なしで。各オプション（build、buy、partner）は同じフィールドを持つ比較可能なレコードになるため、取締役会メモはデータから自然に書き上がります。

この意思決定のCRM関連バージョン（セールスツール、Pipelineインフラ）については、Rework CRM/Sales Ops（月額$12/ユーザーから）と組み合わせることで、意思決定プロセスとそれに続く運営上のオーナーシップが同じシステムに存在するようになります。Reworkでこのプロセスを実行するチームは通常、意思決定サイクルを6〜8週間から2〜3週間に短縮します。主に、古いバージョンの分析で作業する部門間のやり取りをなくすことで。

よくある質問

Q: 中規模市場企業にとってbuildが意味をなすのはどんな場合ですか? A: Buildが意味をなすのは3つの条件が同時に成立する場合のみです。そのケイパビリティが差別化のコアである（顧客が対価を払う）、ベンダーが提供するものより本当に優れたものをbuildできる、そして他の優先事項を犠牲にせず3年以上メンテナンスするためのエンジニアリングキャパシティがある。いずれかが不確かな場合、buildパスは通常誤りです。ほとんどの中規模市場企業は必要以上に2〜3倍buildしています。

Q: Buyすべきでbuildすべきでないことを示す最大のシグナルは何ですか? A: そのケイパビリティが、あなたのセグメントで3社以上の信頼できるベンダーが参入している成熟したカテゴリとしてすでに存在している場合です。本物の市場が形成されているということは、問題がよく理解され、解決策が標準化されており、独自バージョンをbuildすることがすでにコモディティ化されているものの再発明であることを意味します。分析機能、課金、CRM、コンプライアンスツール、メールインフラはすべてこのパターンに当てはまります。

Q: Partnerが正しいパスかどうかを知るには? A: Partnerが正しいパスなのは、ケイパビリティが戦略的に重要だが差別化につながらない場合、buildとpartnerの時間差が6ヶ月以上ある場合、そして少なくとも3年間ロードマップがあなたと一致する信頼できるパートナーが存在する場合です。パートナーパスにはリレーションシップを管理する内部キャパシティも必要です。パートナーシップは自然に管理されません。

Q: チームがbuyすべきものをbuildしたがっている場合は? A: エンジニアの熱意は本物のシグナルですが、意思決定のインプットとしては不十分です。問いはチームがbuild「できるか」や「したいか」ではありません。buildの機会費用が次の何かをbuildしない機会費用を上回るかどうかです。会話を再フレームしてください。「これをbuildすると、次の12ヶ月でbuildしない3つのことは何か?」そのリストは通常、問われているケイパビリティより価値があります。

Q: 表面的なbuildコストと真のbuildコストをどう見積もりますか? A: エンジニアリングチームの初期見積もりに3つの掛け算を適用します。顧客がv1を見た後のスコープクリープに1.5倍、配信を遅らせる競合する優先事項に1.3倍、そして合計の20〜30%を年間メンテナンスコストとして加えます。表面的な$50万のbuildは通常、初年度コスト$100万、メンテナンス$15〜20万/年です。DeloitteのTCO調査は、内部見積もりが40〜60%過小評価することを一貫して示しています。

Q: Build vs. buyの最も一般的な失敗はどんなものですか? A: 4つの繰り返されるもの: (1) バイナリとして扱い、パートナーシップを真剣に評価しない。(2) サンクコストのロジックを使う（「すでにbuildを始めているから今さら切り替えられない」）。(3) 「自分たちのデータモデルを知っている」を「カテゴリリーダーよりうまくbuildできる」と混同する。(4) 継続的なメンテナンスを過小評価する。これがbuildの経済性が18ヶ月後に実際に崩壊するところです。

Q: この意思決定にどのくらいかけるべきですか? A: TCOが$50万以下のケイパビリティには2〜3週間が適切です。TCOが$100万以上または戦略的な影響があるケイパビリティには4〜6週間が妥当です。フレームワークを厳密に実行するのに十分な長さで、市場があなたを追い越すほど長くない。8週間を超える意思決定はたいてい、分析不足ではなく未解決の戦略的な意見の不一致を反映しています。

関連記事