概要
「既存メンバーだから無料」は機会費用の無視
エンジニアの人件費が固定費でも、その工数を他の優先施策に使えたはずという機会費用は、build vs buy比較で必ず金額換算する。
「作って終わり」はMLの継続コストを見落とす
モデルの再学習・ドリフト監視・アラート対応という継続的な運用負荷を無視すると、内製コストは恒常的に過小評価される。
SaaS従量費は事業の成長率を反映する
「現状の月額×60ヶ月」は成長中の事業では過小評価になりやすい。年ごとの呼び出し数増加を織り込んで積算する。
コスト差が僅差なら戦略軸で決める
機会費用・運用保守・成長率・統合コストを正しく積算すると差は縮まる。差が小さいほど「コアかコモディティか」の判断が主役になる。
問題
ECサイト MOps 販促システムチームでは、商品詳細ページ・カート内の「よく一緒に購入されている商品」枠を、単純な購入履歴の共起集計によるルールベースで表示しているが、CVR改善が頭打ちになっており、機械学習ベースのパーソナライズドレコメンドエンジンへの刷新を検討している。
選択肢は2つ。(a) 内製構築（Vertex AIを使った協調フィルタリングモデルを自社で開発）と、(b) SaaS導入（外部レコメンドAPIサービスを契約）。後輩PdM見習いが「レコメンドエンジン刷新 build vs buy 意思決定提案書」のドラフトを作成し、来週の技術投資会議（役員承認）に提出しようとしている。
あなたはMOpsチームのシニアエンジニアとして、この Bad 意思決定提案書をレビューし、実際に役員会の投資判断に使えるレベルへ再設計することになった。以下のドラフトには 7つの問題点が潜んでいる。問題点を全て洗い出し、Good 意思決定提案書へ再設計してください。
制約・前提条件（正）
- エンジニア単価: 80万円/月（160時間=20人日 → 1人日=4万円）
- 内製構築の開発工数: 90人日（MLエンジニア1名+バックエンドエンジニア1名の混成チーム、想定開発期間3ヶ月）
- 過去実績: 直近3件の類似GCP ML案件は、いずれも当初見積もりに対し平均+35%の工数超過が発生している
- 内製の運用保守: リリース後もモデルの定期再学習・データドリフト監視・アラート対応が必要で、月20人日相当のオンコール工数（データサイエンティスト0.25FTE相当）が継続的に発生する
- MLインフラ費用: Vertex AI Training/Prediction・BigQuery ML等の月額利用料 15万円
- SaaS基本料: 月額30万円（固定）
- SaaS従量課金: 1万回あたり500円、現状の月間呼び出し数800万回（=800単位）→現状40万円/月
- EC事業の成長率: 過去3年間の実績で、検索・レコメンド系APIの月間呼び出し数は年率平均20%で増加している
- SaaS未対応の必須要件: 在庫連動のクーポン即時反映ロジック（在庫切れ商品を即座にレコメンド対象から除外する仕組み）はSaaS標準機能に無く、自社側での統合実装が必要。初期構築20人日 + 継続保守5人日/月
- スイッチングコスト（参考情報）: 導入後に他SaaSまたは内製へ乗り換える場合、データ移行・再統合コストとして40人日相当が別途発生する
- 後輩ドラフトは、内製の人件費・運用保守コスト、SaaSのトラフィック成長、統合コスト、見積もり超過リスク、乗り換えリスク、戦略的なbuild-or-buy判断軸のいずれも検討していない
期待する回答形式: 問題点の列挙（番号付き） + 5年TCO比較表（Build/Buy、内訳付き） + リスク調整後レンジ表（見積もり超過・成長率シナリオ） + build-or-buy戦略判断軸（コア/コモディティ） + 段階的な推奨案
悪い意思決定提案書 (Before)
このドラフトには 7つの問題 が隠れています。見つけてみてください。
Bad ドラフト — 機会費用ゼロ扱い・トラフィック固定・戦略軸なし
件名: パーソナライズドレコメンドエンジン刷新 build vs buy 提案
【比較対象】
(a) 内製構築: Vertex AIを使った協調フィルタリングモデルを自社で開発
(b) SaaS導入: 外部レコメンドAPI「〇〇Recommend」を導入
【コスト比較（5年間）】
(a) 内製構築
- 開発工数: 90人日
- エンジニアは既存チームメンバーのため追加人件費は発生しない
← 問題①: 機会費用の無視、追加人件費ゼロ扱い
- リリース後の運用コストはほぼゼロ（一度作れば動き続ける）
← 問題②: モデル再学習・ドリフト監視等の継続コストを無視
→ 5年間の総コスト: 0円
(b) SaaS導入
- 月額基本料: 30万円
- 従量課金: 現在の月間呼び出し数800万回 × 500円/1万回 = 40万円/月
← 問題③: 事業成長によるトラフィック増加を反映せず現状固定
- 月額合計: 70万円
← 問題④: SaaS未対応の統合コスト（クーポン連動）が未計上
→ 5年間の総コスト: 70万円 × 60ヶ月 = 4,200万円
← 問題⑤: ベンダーロックイン・スイッチングコストへの言及なし
【結論】
内製の方が5年間で4,200万円安く済むため、内製構築で進めるべきである。
← 問題⑥: 内製の見積もり超過リスク(過去実績+35%)が未調整
← 問題⑦: コスト比較のみで戦略的なbuild-or-buy判断軸が無い問題点サマリー（7点）
1機会費用の無視 — 内製90人日を「既存メンバーだから無料」として計上していない
2運用保守コストの過小評価 — モデル再学習・ドリフト監視の継続工数をほぼゼロとしている
3SaaS従量費の静的評価 — 現状トラフィックのまま5年間固定して計算している
4統合コストの欠如 — SaaS未対応の必須要件（クーポン連動）への実装コストが未計上
5ロックインリスクの不在 — スイッチングコストへの言及が一切ない
6見積もり超過リスク未調整 — 過去実績+35%が単一点推定に反映されていない
7戦略軸の欠如 — コスト比較のみで「コアかコモディティか」の判断枠組みが無い
ヒント（段階的開示）
ヒント1 — 方向性
Bad版の罠は3系統。(1) 内製コストの過小評価——「既存メンバーだから追加人件費ゼロ」「運用コストはほぼゼロ」という2つの記述は、いずれも実際に発生するコスト（機会費用・継続的な保守工数）を無視してゼロ円扱いにしている。(2) SaaSコストの静的評価——現状のトラフィック（800万回/月）だけで5年間の従量課金を単純に60倍しており、EC事業自体の成長によって呼び出し数が増え続けることも、SaaS標準機能で足りない部分の統合コストも反映していない。(3) 意思決定プロセスの欠如——単一のコスト比較だけで「内製一択」と結論づけており、見積もり超過やベンダーロックインといったリスク、そして「このレコメンド精度は自社の競争優位の中核なのか、それとも他社と同じでよいコモディティ機能なのか」という戦略的な判断軸が一切ない。
ヒント2 — アプローチ
- 問題①: 内製の開発工数90人日を「既存メンバーだから追加人件費ゼロ」としている → その工数は本来他の優先施策に充てられたはずであり、機会費用として人件費単価で計上する
- 問題②: 内製のリリース後運用コストを「ほぼゼロ」としている → モデル再学習・ドリフト監視・アラート対応の継続工数(月20人日)とMLインフラ費用を計上する
- 問題③: SaaS従量課金を現状トラフィックのみで計算している → EC事業の実績成長率（年率20%）を反映し、年ごとに従量費が増える前提で5年間を積算する
- 問題④: SaaS未対応の必須要件（在庫連動クーポン即時反映）への統合コストが計上されていない → 初期構築+継続保守のコストをSaaS側の総コストに加算する
- 問題⑤: ベンダーロックイン・スイッチングコストがリスクとして触れられていない → 将来乗り換える場合の移行コストを参考情報として明記し、意思決定の柔軟性の違いとして扱う
- 問題⑥: 内製開発の見積もり超過リスク（過去実績+35%）が単一点推定にしか反映されていない → 見積もり通り/リスク調整後の2シナリオでレンジを持たせる
- 問題⑦: コスト比較のみで戦略軸が無い → レコメンド精度が自社の競争優位の中核かコモディティかを判断軸として明示し、コストが僅差の場合はこの軸で決める
ヒント3 — 誘導
【Build（内製）5年TCOの骨格】
初期開発費 = 90人日 × 4万円 = 360万円
リスク調整後初期開発費 = 360万円 × (1 + 0.35) = 486万円
運用保守費(5年) = 20人日/月 × 4万円 × 60ヶ月 = 4,800万円
MLインフラ費(5年) = 15万円 × 60ヶ月 = 900万円
Build総額(見積もり通り) = 360 + 4,800 + 900 = 6,060万円
Build総額(リスク調整後) = 486 + 4,800 + 900 = 6,186万円
【Buy（SaaS）5年TCOの骨格（成長率20%/年を反映）】
Year N の従量費 = 40万円 × (1.2)^(N-1)
Year N の月額 = 30万円 + Year Nの従量費
5年間の基本料+従量費 合計 ≒ 5,372万円
統合コスト = 初期80万円 + 5人日×4万円×60ヶ月(=1,200万円) = 1,280万円
Buy総額 = 5,372 + 1,280 = 6,652万円
【判断軸の骨格】
差額 = Buy総額 - Build総額(リスク調整後) = 6,652 - 6,186 = 466万円（僅差）
→ コストだけでは決め手にならない
→ 「レコメンド精度は自社の競争優位の中核か」で最終判断
→ コストが僅差なら段階的（ステージゲート）導入を検討問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | 内製90人日を機会費用ゼロで計上 | 内製コスト | 機会費用として人件費単価で計上 |
| 2 | 運用保守コストをほぼゼロとしている | 内製コスト | 月20人日の継続工数+MLインフラ費を計上 |
| 3 | SaaS従量費を現状トラフィックで固定 | SaaSコスト | 成長率20%/年を反映して年次積算 |
| 4 | SaaS未対応要件の統合コストが未計上 | SaaSコスト | 初期+継続の統合コストを加算 |
| 5 | ベンダーロックインへの言及が無い | リスク | スイッチングコストを参考情報として明記 |
| 6 | 見積もり超過リスクが未調整 | リスク | 見積もり通り/リスク調整後の2シナリオ化 |
| 7 | 戦略的な判断軸が無くコストのみで即断 | 意思決定 | コア/コモディティ軸+ステージゲート案 |
5年TCO比較図 — Bad vs Good（同一スケール）
模範解答
修正①②③④⑥: 5年TCO比較表（Build/Buy、内訳付き）
Build（内製）
| 項目 | 内容 | 金額 |
|---|---|---|
| 初期開発費 | 90人日 × 4万円 | 360万円 |
| 運用保守費（5年） | 20人日/月 × 4万円 × 60ヶ月 | 4,800万円 |
| MLインフラ費（5年） | 15万円/月 × 60ヶ月 | 900万円 |
| Build総額（見積もり通り） | 6,060万円 | |
| リスク調整後初期開発費 | 360万円 × 1.35（過去実績+35%） | 486万円 |
| Build総額（リスク調整後） | 6,186万円 |
Buy（SaaS、成長率20%/年を反映）
| Year | 従量費（40万円×1.2^(N-1)） | 月額（基本料30万円込） | 年間額 |
|---|---|---|---|
| 1 | 40.0万円 | 70.0万円 | 840.0万円 |
| 2 | 48.0万円 | 78.0万円 | 936.0万円 |
| 3 | 57.6万円 | 87.6万円 | 1,051.2万円 |
| 4 | 69.1万円 | 99.1万円 | 1,189.4万円 |
| 5 | 82.9万円 | 112.9万円 | 1,355.3万円 |
| 基本料+従量費 5年合計 | 5,372.0万円 | ||
| 統合コスト（初期80万円+5人日×4万円×60ヶ月） | 1,280万円 | ||
| Buy総額 | 6,652万円 | ||
Bad版は「0円 vs 4,200万円」という4,200万円の差で内製一択と結論づけていたが、機会費用・運用保守・MLインフラ・トラフィック成長・統合コスト・見積もり超過リスクを正しく積算すると、Build 6,186万円 vs Buy 6,652万円で差はわずか466万円（約7%）まで縮まる。方向性としては依然Buildがやや有利だが、「圧倒的な差」から「僅差」への変化そのものが、コストだけで即断してはいけないという最大のシグナルである。
修正⑦: build-or-buy戦略判断軸（コア/コモディティ）
| 判断軸 | 内製が有利になる条件 | SaaSが有利になる条件 |
|---|---|---|
| 差別化への寄与 | レコメンド精度が競合との差別化要因であり、自社データに特化したモデルでないと競争優位を作れない | 業界標準的なロジックで十分であり、精度自体は競争優位の源泉ではない |
| 実行リスク | 社内にML運用の実績・人材が十分にあり、+35%の超過を吸収できる余裕がある | ML人材が不足しており、SaaSで早期に立ち上げてリスクを下げたい |
| 柔軟性・拡張性 | 在庫連動クーポン即時反映のような自社独自要件が今後も増える見込みがある | 標準機能で足りる範囲が大きく、統合コストが今後も大きくならない見込み |
| 投資回収の確実性 | コスト差が明確に大きく、投資回収期間が短い | コスト差が僅差で、SaaSの方が意思決定を先送りできる |
今回のようにコスト差が466万円（総額の約7%）まで縮まった場合、コストの大小だけで意思決定するのは危険である。「レコメンド精度が自社の競争優位の中核かどうか」という戦略軸を明示し、コストがどちらに転んでも意思決定の根拠が残るようにする。
修正⑤⑥⑦: 段階的な推奨案（ステージゲート型）
| フェーズ | 内容 | 判断 |
|---|---|---|
| Phase 1（0〜6ヶ月） | SaaS導入でMVPを先行立ち上げ。統合コスト（在庫連動クーポン即時反映）を含めて実装し、CVRへの効果を実測する | — |
| 判定ゲート（6ヶ月後） | SaaS導入によるCVR改善効果と、呼び出し数の実際の成長率を測定する | 効果が小さければSaaS継続、効果が大きく差別化要因と判明すれば内製検討へ |
| Phase 2（Go時、1〜2年目） | レコメンド精度が競争優位の中核と判明した場合、内製構築（90人日、リスクバッファ35%込みで予算化）に着手 | 見積もり超過リスクを織り込んだ予算で承認する |
| Phase 2（No-Go時） | SaaS継続。ただしスイッチングコスト（40人日相当）を認識した上で、契約更新のたびにTCOを再計算する | 3〜5年で累計コストがBuild優位に転じていないか定期確認する |
Bad版は「5年間の総コストを一度に比較して即決」という一括の意思決定だったが、コスト差が僅差でありSaaS側は統合作業も必要な以上、まずSaaSで早期に立ち上げてCVR効果とトラフィック成長の実測値を得てから、内製への投資判断を行う段階的なロードマップの方が、90人日・見積もり超過リスクのある投資を裏付けなく承認するより合理的である。
ポイント解説
1「既存メンバーだから追加人件費ゼロ」は機会費用の無視である — その工数を他の優先施策に使えたはずという機会費用は、build vs buy比較において必ず金額換算して計上する。
2内製の「作って終わり」という発想は運用保守コストを見落とす典型例である — 特にMLモデルは再学習・ドリフト監視という継続的な運用負荷が発生し、これを無視すると内製コストは恒常的に過小評価される。
3SaaSの従量課金は現状のトラフィックで固定せず、事業の成長率を反映して積算する — 単純に「現状の月額×60ヶ月」とするのは、成長中の事業では過小評価になりやすい典型的な誤りである。
4SaaS導入でも「標準機能で足りない部分」の統合コストは必ずBuy側の総コストに含める — SaaS導入は「0から作らなくていい」だけであり、自社固有の要件が残る限り統合コストはゼロにならない。
5過去の類似案件の見積もり超過実績があるなら、単一点推定ではなくリスク調整後のレンジで比較する — 「見積もり通りなら安い」という前提だけで意思決定すると、実行段階で想定外のコスト超過に直面する。
6コスト差が僅差になった場合こそ、戦略的な判断軸（コア機能かコモディティ機能か）が意思決定の主役になる — コストだけで押し切れない局面で「何を差別化要因とするか」を明示できないと、役員会で説得力のある結論が出せない。
実務への応用
MOpsチームでは、レコメンドエンジンに限らず、CDP（顧客データ基盤）・不正検知・チャットボットのような「内製もSaaS導入もどちらも技術的に可能」な機能領域で、今後も同種のbuild-or-buy判断が繰り返し発生する。本問題の型（機会費用と継続保守コストを内製側に正しく積算する → 成長率と統合コストをSaaS側に正しく積算する → コスト差が僅差なら戦略軸で判断する → 段階的に立ち上げて実測してから大きな投資判断をする）は、この種の意思決定全般に再利用できる。
証券会社経験との接続: 投資判断の場では「初期コストだけを比較して意思決定する」ことは避け、必ず保有期間中のランニングコスト・撤退コスト（スイッチングコスト相当）まで含めたトータルの経済性で比較する訓練を受けており、その視点がそのままエンジニアリングの内製/SaaS判断にも応用できる。
今日のまとめ
build vs buyのコスト比較は「初期費用だけ」「現状トラフィックだけ」を比べても成立しない。内製側には機会費用と継続的な運用保守コストを、SaaS側には事業成長を反映した従量費と自社固有要件の統合コストを正しく積算し、過去実績に基づく見積もり超過リスクをレンジとして持たせる、という一連の設計を行って初めて、Bad版の「0円 vs 4,200万円」という極端な差が「6,186万円 vs 6,652万円、差はわずか466万円」という現実的な僅差に修正される。そしてコスト差が僅差になった局面こそ、戦略的判断軸とステージゲート型の意思決定プロセスが、役員会での意思決定の質を左右する。
次のステップ
- 発展問題: Phase 1のSaaS導入から6ヶ月後、実際にはCVRが2.10%→2.15%（相対+2.4%）しか改善せず、当初期待していたほどの差別化効果は見られなかったとする。このとき、(1) 残り4.5年間のSaaS継続 vs 内製切替のどちらを推奨するか、(2) その判断に必要な追加の実測データは何か、(3) スイッチングコスト（40人日相当）を踏まえた損益分岐のタイミングをどう計算するか、の3点を踏まえた振り返りレポートを作成せよ。
- 参考: TCO（Total Cost of Ownership）分析、機会費用（Opportunity Cost）、ベンダーロックイン、ステージゲート法による段階的投資判断、コア・コンピタンス論（build vs buyの戦略的判断軸）