フレームワーク活用ガイドひとことで言うと#
ある機能やシステムを「自前で開発する（Build）」か「既存の製品・サービスを買う（Buy）」かを、コスト・戦略・リスクの観点から判断するフレームワーク。「作れるから作る」という罠を避けるための思考法。
押さえておきたい用語#
- Build（ビルド）
- 必要な機能やシステムを自社で開発する選択肢。カスタマイズ性は高いが、開発・保守コストを自社で負担する。
- Buy（バイ）
- 既存のSaaS・パッケージ・OSSを購入・導入する選択肢。初期コストは低いが、カスタマイズに制約がある。
- TCO（Total Cost of Ownership）
- 初期費用だけでなく、運用・保守・移行・廃棄まで含めた総保有コストを指す。Build vs Buyの比較では5年間で算出するのが一般的。
- Core Domain（コアドメイン）
- 自社の競争優位の源泉となる領域のこと。ここは自前で作るべきという判断基準になる。
- Commodity（コモディティ）
- 差別化要因にならない汎用的な機能。認証・決済・メール送信などが典型例で、Buy寄りの判断になりやすい。
ビルド vs バイ判断の全体像#
こんな悩みに効く#
- 「エンジニアがいるから何でも自前で作る」文化が染みついていて、SaaS導入を検討できない
- 逆にSaaSを入れすぎて、ツール間の連携コストが膨大になっている
- 内製か外注かの判断が属人的で、毎回議論が紛糾する
基本の使い方#
「この機能は自社の競争優位に直結するか？」を問う。Yesなら Build寄り、Noなら Buy寄り。
- 検索アルゴリズムが売りのメディア → 検索エンジンは Core（Build）
- 同じ会社の請求管理 → Commodity（Buy: Stripe等）
- ベンダーロックイン: 乗り換えコストはどの程度か
- セキュリティ・コンプライアンス: 規制要件を満たせるか
- 市場投入速度: Buyならいつから使えるか、Buildだと何ヶ月かかるか
- チームスキル: 自前開発できるスキルセットがあるか
具体例#
従業員30名のBtoB SaaS。セキュリティ意識の高いCTOが認証基盤を内製していたが、2名のエンジニアが保守に専念しており、MFA対応やSSO連携の要望に追いつけなくなっていた。
TCO比較（5年間）
| 項目 | Build（現状の内製） | Buy（Auth0） |
|---|---|---|
| 開発・保守の人件費 | 約7,500万円 | 0円 |
| ライセンス料 | 0円 | 約2,400万円 |
| 連携・移行コスト | 0円 | 約500万円 |
| 5年間TCO | 約7,500万円 | 約2,900万円 |
認証はCore Domainではなく、Auth0に移行。浮いた2名のエンジニアをコアプロダクトの開発に回した結果、新機能のリリース速度が 月1回 → 月3回 に改善。
従業員500名の精密部品メーカー。市販のMESを3つ検討したが、自社の特殊な品質管理工程（検査項目200以上、工程間フィードバック）に対応できるものがなかった。
判断のポイント
- 品質管理プロセスは同社の Core Domain（この精度が競争優位）
- 市販MESのカスタマイズ見積もりが新規開発並みのコスト
- 社内にPLC制御と業務システム開発ができるチームが既にいる
5年間TCOはBuild 8,000万円 vs Buy+カスタマイズ 1.2億円 で、Buildに決定。開発した自社MESは工程間フィードバックの自動化により不良率を 2.3% → 0.8% に低減させた。
シリーズBの決済フィンテック。決済処理エンジンは当然Buildだが、不正検知もBuildすべきかで議論が分かれた。
スコアリングで判断。
| 評価軸 | 決済エンジン | 不正検知 |
|---|---|---|
| Core Domain? | 最重要 | 重要だが本業ではない |
| 市場に代替あるか? | なし | Sift, Stripe Radar等 |
| 社内スキル | ある | 機械学習人材が不足 |
| 市場投入速度 | 既に稼働中 | Buyなら2週間、Buildなら6ヶ月 |
決済エンジンはBuild維持、不正検知はStripe RadarをBuyし、判定ルールのチューニングだけを自前で行うHybrid方式に。不正検知のリリースが 6ヶ月前倒し になり、不正損失率は初月から 0.3% → 0.08% に改善した。
やりがちな失敗パターン#
- 「作れるから作る」で判断してしまう — エンジニアリングチームの能力ではなく、ビジネス上の価値で判断する。Commodityを内製するのは競争優位を生まないリソースの浪費
- TCOの隠れコストを見逃す — Buildの場合は「退職リスク」「採用コスト」「技術負債の蓄積」、Buyの場合は「データ移行」「API連携の保守」「値上げリスク」を含めて計算する
- 一度決めたら見直さない — 事業フェーズやチーム規模が変われば最適解も変わる。年に1回はBuild/Buyの妥当性を再評価する
- Build or Buyの二択で考える — Hybridという第三の選択肢がある。コア部分だけBuildして周辺をBuyするのが多くの場合で最適解になる
まとめ#
Build vs Buy判断は「Core DomainかCommodityか」を最初に問い、TCOと追加リスク要素を加味して結論を出すフレームワーク。Core Domainは自前で作り、Commodityは買う。判断に迷ったらHybridという選択肢も検討する。重要なのは 「作れるかどうか」 ではなく 「作るべきかどうか」 で判断すること。事業フェーズの変化に応じて定期的に見直す習慣も欠かせない。