# Build Versus Buy ## 定義 Build Versus Buyは、ソフトウェア・インフラを内製(build)するか、商用ベンダーから購入(buy)するか、オープンソースを採用(adopt/OSS)するかを、単なる技術比較ではなくエンジニアリング資源(engineering cycles)の配分をめぐる経済的判断として扱う意思決定フレームワークである。二分法ではなく多次元のスペクトラムであり、ほとんどの組織はこの3つ全てを部分的に組み合わせることになる。中核となるのは、横軸をビジネス価値(none→differentiator)、縦軸を普遍性(commodity→bespoke)とする2×2マトリクスで、build(bespoke×高価値)・buy(commodity×低価値)・should not exist(bespoke×低価値)・decide(commodity×高価値)の4象限に技術投資を分類する。このマトリクスはRick Clarkが考案し、Peter Corlessがオープンソース・source-available・COTS・コミッション(委託開発)を組み込んだ拡張版(create/adopt/acquire/avoidの4象限)へ発展させた。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]]) ## 横断的知見 - 『SREの探求』5章は、Rick Clarkの2×2マトリクス(ビジネス価値×普遍性)より6年早く(原書2018年)、独立に「構築・購入・採用」の3択を提示していた。Mercereauは構築を「ニーズが特殊で革新的で自社以外では対応できない(LinkedInのKafka、FacebookのReact、LyftのEnvoyが最終的にOSS化された例)」、購入を「ニーズは一般的でそれを解く有料ソリューションが存在する」、採用を「ニーズは一般的でOSSソリューションが存在する」と定義する。この3分類は[[Reliability Map (r9y.dev)]]がSREcon22 APACで示した「採用・構築・購入」カードと同型であり、Rick Clark/Peter Corlessの2×2マトリクス系とは異なる系譜(3択の直接列挙)が、実務書とカンファレンストークの双方で独立に到達していたことを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] §5.1.3, [[Reliability Map (r9y.dev)]]) - Mercereauは3択それぞれに固有のコスト構造があることを、Rick Clark/Peter Corlessの2×2マトリクスにはない粒度で定式化する——CapEx(初期購入コスト)とOpEx(継続運用コスト)に加え、**PrOpEx(プロジェクト運用コスト。実装コストがCapExの単一明細項目として過小評価されがちな問題を補正する)**と**AbEx(廃棄コスト。あるソリューションから別のソリューションへ移行する際のコスト。ベンダーロックインが増大させる)**を導入する。Observability Engineering 2E第29章の2×2マトリクスは「ビジネス価値×普遍性」という判断時点の静的な軸を提供するのに対し、5章のCapEx/OpEx/PrOpEx/AbExはプロジェクトのライフサイクル全体(導入から廃棄まで)を通じた動的なコスト会計を提供しており、両者は「何を選ぶか」と「選んだ後に何が起きるか」という相補的な問いに答えている。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] §5.1.3-5.1.4.3, [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]]) ## 未解決の問い - Rick ClarkとPeter Corlessのそれぞれのフレームワークを同一の技術投資判断に適用した場合、判定は収束するか分岐するか。実際の企業事例で両方を試した比較はあるか。 - Reliability Mapの「採用・構築・購入」3択カードと、本conceptの2×2マトリクスを組み合わせて、SREケイパビリティのbuild-versus-buy判断を体系的に支援するツールは存在するか。 - 「decide」象限(commodity×高価値)の判断に必要な6つの問い(ジョブ・要件の独自性・最小解・プロダクトマネジメント体制・タイムライン・保守者)は、observability以外のドメイン(セキュリティツール、CI/CD基盤等)にどこまで一般化できるか。 - ハイパースケール企業(Meta・Google等)でbuild-versus-buyの経済性が逆転する具体的な閾値(エンジニア数・データ量・コスト規模)を定量的に示した一次資料はあるか。 - MercereauのPrOpEx/AbExという2つの追加コスト区分は、2×2マトリクスの4象限(build/buy/should not exist/decide)それぞれでどのように現れ方が異なるか。特に「decide」象限の判断にPrOpEx/AbExを組み込むとどう変わるか、統合した検討はまだない。 ## 関連 - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]] / [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] - 概念: [[トレードオフ意思決定]] / [[プラットフォームエンジニアリング]] / [[テレメトリパイプライン]] / [[Reliability Map (r9y.dev)]] / [[ベンダーエンジニアリング]] - エンティティ: [[Rick Clark]] / [[Peter Corless]] / [[Heidi Waterhouse]] / [[Retriever]](build象限の実例) / [[OpenTelemetry]](ベンダーロックイン回避の技術基盤) / [[Jonathan Mercereau]](構築・購入・採用の3択とCapEx/OpEx/PrOpEx/AbExの提唱者) ## 出典 - Charity Majors, Liz Fong-Jones, George Miranda, with Austin Parker, *Observability Engineering*, 2nd Edition, O'Reilly Media, 2026, Chapter 29. - Jonathan Mercereau, 「サードパーティとの協力を円滑に進める重要性」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 5章。