概要
3レイヤー判断
Build vs Buy は「戦略性 → 実現性 → 経済性」の順で判断する。コストから入らない。コア差別化機能は Build、コモディティ機能は Buy が原則。
機会損失を TCO に含める
内製でリリースが2ヶ月遅れると、その間のレコメンド経由売上（月450万円）を取りこぼす。時間価値を金額換算して TCO に加える。
重み付けスコアリング
定性評価を「加重合計 3.25 vs 2.30」という数値に変換。重みの置き方（スピード30%）に意思決定者の価値観が反映される。
BLUF（結論ファースト）
役員は最初の30秒で結論を知りたい。「結論 → 根拠3点 → リスク → お願い」の順で5分に収める。リアルオプション思考で段階戦略を採る。
問題
ECサイトのMOpsチームで「商品レコメンドエンジン」を導入することが決まった。経営層からは「内製（Build）すべきか、SaaS（Buy）を導入すべきか」の判断を求められている。あなたはMOpsエンジニア兼PM補佐として、Build vs Buy の意思決定フレームワークを設計し、5年TCO比較とともに推奨案を提示せよ。最終的に役員会で5分で説明できる「意思決定サマリ（BLUF形式）」も作成すること。
現状・前提条件
- 月間GMV: 約15億円、レコメンド経由売上は現状ゼロ（未導入）
- 目標: レコメンド経由でGMVを +3%（年間 5,400万円） 押し上げる
- エンジニア単価: 100万円/月（160時間）/ チームのML経験者は 1名のみ
- SaaS候補「RecoCloud」: 初期200万円 + 月額80万円（GMV連動なし）
- 内製候補: BigQuery ML + Vertex AI で構築、運用はMOpsチーム
- リリース要件: 4ヶ月以内（年末商戦に間に合わせたい）
期待する回答形式: (1) Build vs Buy 判断フレームワーク、(2) 5年TCO比較（数値計算を明示）、(3) 定性評価マトリクス（スコアリング）、(4) 推奨案と根拠、(5) 役員会向け BLUF サマリ（5分説明用）
2つの選択肢 — Build vs Buy（5年TCO 内訳）
どちらが「安い」か、ではなく 制約下でどちらが価値を出すか を見極めます。機会損失（時間価値）を忘れずに。
🔨 Build（内製）— 5年TCO ≈ 6,900万円
# 初期開発: ML1 + BE2 × 4ヶ月
12人月 × 100万 ............... 1,200万円
# インフラ (Vertex AI + BQ ML)
月30万 × 60ヶ月 .............. 1,800万円
# 保守運用 (再学習・改修)
月0.5人月 × 100万 × 60 ....... 3,000万円
# ⚠️ 機会損失 (リリース2ヶ月遅延)
月450万 × 2ヶ月 ............... 900万円
─────────────────────────────────
Build 5年TCO ............... 6,900万円
# 弱み
- ML人材1名 = 単一障害点（退職で頓挫）
- 4ヶ月で本番品質モデルは厳しい
- 機会損失2ヶ月分が乗る🛒 Buy（SaaS: RecoCloud）— 5年TCO ≈ 6,350万円
# 初期費用 (一括)
............................ 200万円
# 月額
80万 × 60ヶ月 ............... 4,800万円
# 連携開発 (API接続)
BE1 × 1.5ヶ月 = 1.5人月 ...... 150万円
# 連携保守
月0.2人月 × 100万 × 60 ....... 1,200万円
# ✅ 機会損失 (1ヶ月でリリース)
............................ 0円
─────────────────────────────────
Buy 5年TCO ................. 6,350万円
# 強み
- 1ヶ月でリリース → 年末商戦に間に合う
- ML人材リスクを回避
- 初年度から効果計上・撤退も容易
差額: Build が 550万円 高い（5年累計）。さらに Build は機会損失2ヶ月分（900万円）を含む。
ヒント（段階的開示）
ヒント1 — 方向性
Build vs Buy は「TCOだけ」で決めてはいけない。判断軸は最低でも 3レイヤー: (a) コスト（初期 + 運用 + 機会損失）、(b) スピード（Time to Market）、(c) 戦略性（コア機能か、差別化要因か）。特に「レコメンドが自社の競争優位の源泉になるか」が最重要。コモディティ機能なら Buy、差別化の核なら Build に傾く。今回は「リリース4ヶ月以内」「ML人材1名」という制約がスピードと実現性に強く効く。
ヒント2 — アプローチ（TCO内訳と機会損失）
TCO は「5年間の累積コスト」で比較する。
- Build: 初期開発（人月 × 単価）+ インフラ費（Vertex AI / BQ ML）+ 保守運用（年間の改修・モデル再学習工数）
- Buy: 初期費用 + 月額 × 60ヶ月 + 連携開発工数（API接続・データ送信）
ヒント3 — TCO計算の骨格と BLUF
【Build】
初期開発: 12人月 × 100万 ........ 1,200万
インフラ: 月30万 × 60 ........... 1,800万
保守: 月0.5人月 × 100万 × 60 .... 3,000万
機会損失: 450万 × 2ヶ月 .......... 900万
→ 6,900万円
【Buy】
初期: 200万 / 月額: 80万 × 60 ... 4,800万
連携開発: 1.5人月 × 100万 ....... 150万
連携保守: 月0.2人月 × 100万 × 60 1,200万
→ 6,350万円判断の落とし穴
| # | 落とし穴 | なぜ問題か | 正しいアプローチ |
|---|---|---|---|
| 1 | TCO（コスト）だけで判断する | 安い方を選んでも、リリースが遅れて競争優位を失えば本末転倒 | 戦略性 → 実現性 → 経済性 の3レイヤーで判断。経済性は最後 |
| 2 | 機会損失を計算に入れない | 内製の2ヶ月遅延 = 月450万円の取りこぼし。見えないが決定的なコスト | 遅延期間 × 月次効果額 を TCO に加算する |
| 3 | ML人材1名のリスクを軽視 | 単一障害点。退職・離脱でプロジェクトが頓挫、属人化が進む | 人材リスクを評価軸に入れ重み20%。採用後に内製を検討 |
| 4 | 最初から大きく賭ける（一発勝負） | 効果が不確実な段階で内製に全投資すると、失敗時の埋没コストが大きい | 段階戦略（まず Buy で小さく入り、効果を見て Build を検討） |
意思決定フロー図 — 3レイヤー判断
模範解答
1. 5年TCO 比較（数値計算）
前提単価: エンジニア 100万円/月、機会損失 = 目標年5,400万 ÷ 12 = 月450万円
| 項目 | Build（内製） | Buy（SaaS） |
|---|---|---|
| 初期開発 / 初期費用 | 12人月 × 100万 = 1,200万 | 一括 200万 |
| インフラ / 月額（×60ヶ月） | 月30万 × 60 = 1,800万 | 月80万 × 60 = 4,800万 |
| 連携開発（API接続） | — | 1.5人月 × 100万 = 150万 |
| 保守運用（×60ヶ月） | 月0.5人月 × 100万 × 60 = 3,000万 | 月0.2人月 × 100万 × 60 = 1,200万 |
| 機会損失（リリース遅延） | 月450万 × 2ヶ月 = 900万 | 0（1ヶ月でリリース） |
| 5年TCO | 6,900万円 | 6,350万円 |
ROI（目標 +5,400万/年 達成・粗利率30%前提）: 5年粗利 8,100万円。
Build ROI = (8,100 − 6,900) / 6,900 ≈ 17% / Buy ROI = (8,100 − 6,350) / 6,350 ≈ 28%。Buy は早期リリースで初年度から効果が立ち上がるため現在価値ベースでは差がさらに開く。
Build ROI = (8,100 − 6,900) / 6,900 ≈ 17% / Buy ROI = (8,100 − 6,350) / 6,350 ≈ 28%。Buy は早期リリースで初年度から効果が立ち上がるため現在価値ベースでは差がさらに開く。
2. 定性評価マトリクス（重み付けスコアリング）
| 評価軸 | 重み | Build | Buy | Build加重 | Buy加重 |
|---|---|---|---|---|---|
| コスト（5年TCO） | 25% | △(2) | ○(3) | 0.50 | 0.75 |
| スピード（TTM） | 30% | △(2) | ◎(4) | 0.60 | 1.20 |
| カスタマイズ性 | 15% | ◎(4) | △(2) | 0.60 | 0.30 |
| ML人材リスク | 20% | ×(1) | ◎(4) | 0.20 | 0.80 |
| ベンダーロックイン | 10% | ◎(4) | △(2) | 0.40 | 0.20 |
| 加重合計 | 100% | 2.30 | 3.25 |
Buy が 3.25 vs Build 2.30 で優位。 特にスピード（30%）とML人材リスク（20%）で大きく差がついた。
3. 推奨案 — 段階戦略（Buy → 将来 Build）
フェーズ1（0〜4ヶ月）: Buy で RecoCloud 導入
→ 年末商戦に間に合う・初年度から効果計上
→ レコメンド経由売上の "実データ" と効果規模を測定
フェーズ2（1〜2年後）: 効果が大きく差別化余地が見えたら Build 検討
→ SaaSで貯めた知見とデータで内製の勝算が立つ
→ ML人材を採用・育成してから着手（人材リスク解消後）根拠: (1) スピード（年末商戦・機会損失900万円回避）、(2) 実現性（ML人材1名の単一障害点リスク回避）、(3) 経済性（5年TCO 550万安・ROI 28% vs 17%）、(4) 戦略的撤退路（SaaSは後戻りしやすい）。
4. 役員会向け BLUF サマリ（5分説明用）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【結論】レコメンドエンジンは SaaS（RecoCloud）で導入を推奨。
内製は将来の選択肢として保留します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 根拠（3点）
1. スピード: 年末商戦に間に合う（SaaS=1ヶ月 vs 内製=4ヶ月+遅延）
→ 内製だと機会損失 約900万円
2. リスク: 社内ML人材は1名のみ。内製は属人化・頓挫リスクが高い
3. コスト: 5年TCOで SaaS が550万円安く、ROIも 28% vs 17%
■ 期待効果
- レコメンド経由でGMV +3%（年間 +5,400万円）を目標
- 初年度から効果計上（早期リリースのため）
■ リスクと対策
- ベンダーロックイン → 契約に "データ持ち出し条項" を入れる
- 月額固定（GMV連動なし）→ 売上拡大時は内製移行を再検討
■ 役員会へのお願い
- RecoCloud 初期200万 + 月額80万 の予算承認
- 効果測定（レコメンド経由GMV）を四半期でレビューする合意
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ポイント解説
1. 戦略性を最優先で判断する
Build vs Buy はコスト計算から入りがちだが、本質は「これは自社の競争優位の源泉か」。コア差別化機能は Build、コモディティ機能は Buy が原則。今回のレコメンドは "未導入＝まず立ち上げ速度が価値" なので Buy 寄りになる。
Build vs Buy はコスト計算から入りがちだが、本質は「これは自社の競争優位の源泉か」。コア差別化機能は Build、コモディティ機能は Buy が原則。今回のレコメンドは "未導入＝まず立ち上げ速度が価値" なので Buy 寄りになる。
2. 機会損失を TCO に含める
内製でリリースが2ヶ月遅れると、その間のレコメンド経由売上（月450万円）を取りこぼす。これは「見えないコスト」だが意思決定では決定的。時間価値を金額換算する習慣が重要。
内製でリリースが2ヶ月遅れると、その間のレコメンド経由売上（月450万円）を取りこぼす。これは「見えないコスト」だが意思決定では決定的。時間価値を金額換算する習慣が重要。
3. 重み付けスコアリングで定性を定量化する
「なんとなく Buy が良い」を「加重合計 3.25 vs 2.30」という数値に変換することで、役員に説明可能になる。重みの置き方（スピード30%）に意思決定者の価値観が反映される。
「なんとなく Buy が良い」を「加重合計 3.25 vs 2.30」という数値に変換することで、役員に説明可能になる。重みの置き方（スピード30%）に意思決定者の価値観が反映される。
4. 段階戦略（Buy → Build）で後戻り可能性を残す
「今はBuy、将来Build」とすることで、SaaSで貯めたデータと効果知見を使って内製の勝算を立てられる。最初から大きく賭けない（リアルオプション思考）。
「今はBuy、将来Build」とすることで、SaaSで貯めたデータと効果知見を使って内製の勝算を立てられる。最初から大きく賭けない（リアルオプション思考）。
5. BLUF は結論を最初の1行に
役員は最初の30秒で結論を知りたい。「結論 → 根拠3点 → リスク → お願い」の順で、5分で意思決定できる構造にする。詳細資料は別添にして、口頭は結論ファーストに徹する。
役員は最初の30秒で結論を知りたい。「結論 → 根拠3点 → リスク → お願い」の順で、5分で意思決定できる構造にする。詳細資料は別添にして、口頭は結論ファーストに徹する。
実務への応用
- MOps文脈: メール配信エンジン・CDP・MA ツールなど「Build or Buy」の判断は頻出。今回の3レイヤー（戦略性 → 実現性 → 経済性）はそのまま流用できる
- TCO テンプレート化: 初期開発 + インフラ + 保守 + 機会損失 の4項目をスプレッドシートのテンプレートにすると、提案のたびに数分で試算できる
- ベンダーロックイン対策: SaaS契約時は「データ持ち出し条項（エクスポートAPI保証）」「SLA」「解約条件」を必ず確認。後の内製移行の障壁を下げる
- 効果測定の自動化: 導入後は BigQuery で「レコメンド経由GMV」を日次集計し Looker Studio で可視化（過去の 2026-05-21 KPI ツリー設計 を流用）。四半期レビューで Build 移行の判断材料に
- 証券マン経験の活用: 段階戦略は金融の「リアルオプション」と同じ。不確実性が高いときは選択肢を残す投資が合理的。今はBuyで小さく入り、効果が確認できたらBuild（追加投資）に踏み込む
今日のまとめ
Build vs Buy の判断は「TCOが安い方」ではなく、「戦略性 → 実現性 → 経済性」の3レイヤーで行う。
特にスピード（時間価値）とML人材リスクが効く局面では、機会損失を金額換算して TCO に含めることが決定打になる。今回は段階戦略（まず Buy で速く立ち上げ、効果を見て将来 Build を検討）が最適解。役員説明は BLUF（結論ファースト）で5分に収める。
特にスピード（時間価値）とML人材リスクが効く局面では、機会損失を金額換算して TCO に含めることが決定打になる。今回は段階戦略（まず Buy で速く立ち上げ、効果を見て将来 Build を検討）が最適解。役員説明は BLUF（結論ファースト）で5分に収める。