概要
前倒し投資 vs 後払い運用費は NPV で揃える
内製（Build）は初期に大きく払い、SaaS（Buy）は運用費を後年に分散する。名目単純合計では後払いの SaaS が有利に見えるが、割引率（WACC 8%）で現在価値に割り引くと評価が変わる。証券実務の DCF / NPV そのもので、投資案件の公平な比較には時間価値の調整が必須。
TCO に隠れコストを含める
移行・学習・ベンダーロックイン・解約時の再移行は見落としがち。SaaS の「初期 40 万」は連携開発だけで、実際にはデータ移行・運用学習で膨らむ。隠れコストを無視した TCO 比較は経営に誤った意思決定をさせる。
感度分析で損益分岐点を示す
SaaS の従量課金は配信量に線形比例、内製は固定費で吸収するため 損益分岐点（breakeven 配信量） が存在する。「今いくら安いか」ではなく「配信量がどう伸びるとどちらが有利になるか」を示すことで、将来の意思決定を誤らない。
定量と定性を意思決定マトリクスで統合
コスト（NPV）だけでは可搬性・データ主権・スピードが抜ける。加重スコアリングで軸ごとに重みを付けて総合評価し、最後に 撤退基準（trigger） を添えることで、不可逆でない意思決定として経営が承認しやすくなる。
問題
ECサイト MOps チームのシニアエンジニア兼テックリードとして、レガシー内製メール配信基盤（Python 2.7 相当 + 手動 SQL 実行）のリプレイスを「内製で作り直す（Build）か、配信 SaaS を導入する（Buy）か」で経営会議に諮ることになった。後輩が作成した Bad 提案書ドラフト をレビューし、7つの意思決定・財務上の問題 を洗い出して Good 提案書へ再設計せよ。
前提数値（正）
- エンジニア単価: 80 万円/月（160 時間）
- 現在の配信量: 240 万通/月。SaaS 従量単価: 0.05 円/通
- 割引率（WACC）: 8%
- 内製案の変動費（配信量比例）はほぼゼロ（固定インフラで吸収）、SaaS 案は配信量に従量課金が比例
- 事業計画では 12〜18ヶ月で配信量が倍増（480 万通/月）する可能性が高い
期待する回答形式: 問題点の列挙（番号付き）+ 6W3H 整理 + NPV 比較（計算過程）+ 感度分析（損益分岐点）+ 意思決定マトリクス + 推奨と撤退基準
悪い提案書 (Before)
この提案書には 7つの意思決定・財務上の問題 が隠れています。見つけてみてください。
Bad 提案書ドラフト — 名目単純合計・観点欠落
タイトル: メール配信基盤リプレイス提案
現状: 内製基盤が古くて辛いので刷新したい。
← 問題①: Who/Why/損失額が不明（定性のみ）
比較:
■ 内製リプレイス案
- 開発: 6人月 → 480万円
- 年間保守: 2人月=160万 + GCP 96万/年
- 5年総額: 480 + (160+96)×5 = 1,760万円
← 問題②: 名目単純合計（NPV なし）
← 問題④: 年次CF・回収期間なし
■ SaaS 導入案
- 初期導入: 40万円
← 問題③: 移行/学習/解約コスト欠落
- 月額: 固定15万 + 従量12万 = 27万/月
= 324万/年
- 5年総額: 40 + 324×5 = 1,660万円
← 問題⑤: 配信量倍増（従量増）を無視
結論: SaaS の方が5年で100万円安いので
SaaS を導入すべき。
← 問題⑥: 定性リスク（ロックイン等）未評価
← 問題⑦: 撤退基準・条件分岐なし問題点サマリー（7点）
1現状の課題が定性的 — 「古くて辛い」では Who/Why/損失額 が不明。誰のどの業務がいくらの損失かを数値化
2名目単純合計で NPV なし — 前倒し投資（内製）と後払い運用（SaaS）を割引率 8% で現在価値に揃える
3隠れコスト欠落 — 移行・学習・ロックイン・解約を TCO に含める
4単年・静的比較 — 年次キャッシュフロー・回収期間（Payback）を示す
5配信量増加を無視 — 従量課金は配信量に比例。損益分岐点を出す
6定性リスク未評価 — 可搬性・データ主権・スピードを意思決定マトリクスで加重評価
7撤退基準なし — どの条件で内製へ切り替えるかの trigger を提案に含める
ヒント（段階的開示）
ヒント1 — 方向性
Bad 提案書の罠は 3 系統。(1) 財務評価の誤り — 初期投資が重い案（内製）と運用費が重い案（SaaS）を名目単純合計で比べると、お金の時間価値を無視する。前倒しで払う内製が不当に高く見える。NPV/DCF で現在価値に割り引くべき。(2) スコープ・コストの欠落 — 移行・学習・ロックイン・解約などの隠れコストが TCO に入っていない。(3) 意思決定の観点不足 — 現在の配信量だけで判断し将来の倍増（SaaS 従量が効く）を見ていない。定量だけで定性リスク（可搬性・データ主権）も評価していない。
ヒント2 — アプローチ
- 問題①: 「古くて辛い」→ 誰の・どの業務が・なぜ今・いくらの損失かを数値化（工数 + 機会損失）
- 問題②: 内製は初期 480 万を前倒し、SaaS は運用費を後年。割引率 8% で NPV に揃える
- 問題③: SaaS 側の移行・連携・運用学習・ロックイン・解約時再移行を TCO に計上
- 問題④: 5年一括でなく年次 CF + 回収期間（Payback）で見る
- 問題⑤: 配信量倍増で SaaS 従量が線形増。内製は固定費吸収 → 損益分岐点を解く
- 問題⑥: コスト・スピード・拡張性・ロックイン・運用負荷・データ主権を加重スコア化
- 問題⑦: 「SaaS 一択」でなく、どの条件で内製へ切り替えるかの再評価 trigger を添える
ヒント3 — 計算骨格
【NPV 計算骨格（割引率 8%）】
割引係数: Y0=1.000 Y1=0.926 Y2=0.857 Y3=0.794 Y4=0.735 Y5=0.681
Y1-5 割引係数合計 = 3.993
内製 NPV(コスト) = 初期480 + 年256 × 3.993 = ?
SaaS NPV(コスト) = 初期80(移行含む) + 年324 × 3.993 = ?
【損益分岐点（breakeven 配信量）】
SaaS 年次 = 180万(固定) + 月量 × 0.05円 × 12
内製 年次 = 256万（固定）
→ SaaS年次 = 内製年次 になる月量 X を解く
【意思決定マトリクス骨格】
評価軸 | 重み | 内製 | SaaS
コスト(NPV) | 30% | ? | ?
市場投入スピード | 20% | ? | ?
拡張性/スケール | 15% | ? | ?
可搬性/ロックイン| 15% | ? | ?
保守運用負荷 | 10% | ? | ?
データ主権 | 10% | ? | ?問題点分析（7点）
| # | 問題点 | 分類 | 改善方法 |
|---|---|---|---|
| 1 | 現状の課題が定性的（Who/Why/損失額なし） | 企画 | 6W3H で誰の課題・機会損失を数値化 |
| 2 | 名目単純合計で NPV なし | 財務 | 割引率 8% で現在価値に割り引く（DCF） |
| 3 | 隠れコスト欠落（移行/学習/ロックイン/解約） | TCO | SaaS 初期 40→80 万に補正、退出コスト計上 |
| 4 | 単年・静的な 5年一括比較 | 財務 | 年次 CF + 回収期間（Payback） |
| 5 | 将来の配信量増加を無視 | 感度分析 | 損益分岐点（breakeven 配信量）を算出 |
| 6 | 定性リスク未評価 | 意思決定 | 意思決定マトリクスで加重スコアリング |
| 7 | 撤退基準・条件分岐なし | 戦略 | 内製へ切り替える再評価 trigger を明記 |
NPV 比較 & 損益分岐点 — Bad vs Good の変換
模範解答
| 項目 | 内容 |
|---|---|
| Who | 配信オペレーター3名（手動作業）・MOps エンジニア2名（障害対応）・マーケ（施策リードタイム待ち） |
| What | レガシー配信基盤（Python 2.7 相当）のリプレイス。Build（内製）か Buy（SaaS）か |
| When | Python 2.7 系ライブラリ EOL、セキュリティパッチ停止済み。今期中の意思決定が必要 |
| Where | GCP（Cloud Run / Pub/Sub / BigQuery）上の MOps 配信基盤。全配信の 61% を占有 |
| Why | 手動 SQL の運用負荷・障害リスク・施策リードタイム 38 日の主因。EOL のセキュリティ懸念 |
| Which | 案A: 内製 / 案B: SaaS /（案C: 現状維持＝EOL リスクで却下、ベースライン） |
| How | 案B は既存 Pub/Sub からの連携アダプタ + データ移行。案A は Cloud Run v2 + Argo で再構築 |
| How many | 現在 240万通/月 → 12〜18ヶ月で 480万通/月へ倍増見込み |
| How much | NPV・損益分岐点・意思決定マトリクスで定量評価（各タブ参照） |
割引係数（8%）: Y0=1.000 Y1=0.926 Y2=0.857 Y3=0.794 Y4=0.735 Y5=0.681
Y1-5 割引係数合計 = 3.993
■ 内製案（隠れコスト補正後）
初期(Y0): 開発 480万
年次(Y1-5): 保守160万 + インフラ96万 = 256万/年
NPV = 480 + 256 × 3.993 = 480 + 1,022 = 約 1,502万円
■ SaaS 案（隠れコスト補正後）
初期(Y0): 連携開発40万 + データ移行/学習40万 = 80万 ← 問題③補正
年次(Y1-5): 固定15万 + 従量12万 = 27万/月 = 324万/年
NPV = 80 + 324 × 3.993 = 80 + 1,294 = 約 1,374万円| 案 | 名目5年総額 | NPV(PV 8%) | 初期偏り | 判定(現配信量) |
|---|---|---|---|---|
| 内製 | 1,760万 | 1,502万 | 大（前倒し） | コスト劣位 |
| SaaS | 1,700万※ | 1,374万 | 小（分散） | コスト優位 |
ポイント: 隠れコスト補正で SaaS 初期を 40→80 万に修正（Bad の名目 1,660 万から増加）。それでも現配信量では SaaS が NPV 優位。前倒し投資の内製は割引の恩恵を受けにくい。
| 配信量/月 | SaaS 年次（固定180万＋従量） | 内製 年次（固定256万） | 優劣 |
|---|---|---|---|
| 240万通 | 180 + 144 = 324万 | 256万 | 拮抗〜内製寄り |
| 480万通 | 180 + 288 = 468万 | 256万 + α | 内製優位 |
【損益分岐点】SaaS 年次 = 内製 年次(256万) となる配信量
180万(固定) + 月量 × 0.05円 × 12 = 256万
月量 × 0.6 = 76万
月量 ≒ 127万通 ← 年次運用費が並ぶ点
※ 内製の初期480万を NPV 込みで回収するには
より高い配信量・長期利用が必要。現配信量240万通でも
「年次運用費」だけなら内製が安いが、初期投資を含む
NPV では現時点は SaaS 優位。配信量倍増(480万通)で
内製の NPV 優位が明確になる。
結論: 意思決定は「静的なコスト差」ではなく「配信量の成長シナリオ」に依存する。現配信量では SaaS 優位、倍増すると内製優位に転じる。
| 評価軸 | 重み | 内製 | SaaS | 内製×重み | SaaS×重み |
|---|---|---|---|---|---|
| コスト（NPV・現配信量） | 30% | 3 | 5 | 0.90 | 1.50 |
| 市場投入スピード | 20% | 2 | 5 | 0.40 | 1.00 |
| 拡張性/将来スケール | 15% | 5 | 3 | 0.75 | 0.45 |
| 可搬性/ベンダーロックイン | 15% | 5 | 2 | 0.75 | 0.30 |
| 保守運用負荷 | 10% | 2 | 5 | 0.20 | 0.50 |
| データ主権/セキュリティ | 10% | 5 | 3 | 0.50 | 0.30 |
| 加重スコア合計 | 100% | 3.50 | 4.05 |
現時点の総合評価は SaaS（4.05）> 内製（3.50）。ただし拡張性・可搬性・データ主権は内製が優位。重みは経営と合意した優先基準であり、絶対値ではない。
推奨: まず SaaS を導入する（Buy first）。ただし無条件ではなく再評価トリガーを設ける。
✓推奨理由 — 現配信量では NPV 優位（1,374 < 1,502）、市場投入が数週間（内製は 4〜6ヶ月）、EOL リスクを即解消。初期投資が小さくキャッシュフロー負担が軽い（CFO 目線）。
1trigger 1 — 配信量が損益分岐点（月 480 万通レベル）を継続的に超えた → 従量課金が固定内製費を上回る
2trigger 2 — SaaS ベンダーが値上げ（例: 従量単価 +30%）または要件のカスタマイズ限界に達した
3trigger 3 — データ主権・コンプライアンス要件（個人情報の国内保持等）が強化された
🛡リスクヘッジ — 連携アダプタを「SaaS 依存を薄く保つ」抽象レイヤ（Protocol）として設計し、将来の内製移行コストを下げておく（ロックイン緩和＝オプション価値）。
ポイント解説
1前倒し投資 vs 後払い運用費は NPV で揃える — 内製は初期に大きく払い、SaaS は運用費を後年に分散する。名目単純合計では後払いが有利に見えるが、割引率 8% で現在価値に割り引くと評価が変わる。証券実務の DCF/NPV そのもので、投資案件の公平な比較には時間価値の調整が必須。
2TCO には隠れコストを必ず含める — 移行・学習・ベンダーロックイン・解約時再移行は見落としがち。SaaS の「初期 40 万」は連携開発だけで、実際はデータ移行・運用学習で膨らむ。隠れコストを無視した比較は経営に誤った意思決定をさせる。
3静的比較ではなく成長シナリオで感度分析する — SaaS の従量課金は配信量に線形比例、内製は固定費で吸収するため損益分岐点が存在する。「今いくら安いか」ではなく「配信量がどう伸びるとどちらが有利か」を示すことで将来の意思決定を誤らない。
4定量と定性を意思決定マトリクスで統合する — コスト（NPV）だけでは可搬性・データ主権・スピードが抜ける。加重スコアリングで軸ごとに重みを付けて総合評価すると、コスト僅差の案でも「なぜこの選択か」を経営に説明できる。
5意思決定に撤退基準（trigger）を組み込む — 「SaaS 一択」でなく「どの条件で内製へ切り替えるか」を提案に含めると、不可逆でない意思決定として経営が承認しやすい。ロックインを薄く保つ抽象レイヤ設計は、将来の選択肢を残すリアルオプションそのもの。
実務への応用
ECサイト MOps の配信基盤・分析基盤・認証基盤など「作るか買うか」の判断は頻出。NPV・損益分岐点・意思決定マトリクス の 3 点セットで提案すると、CFO/経営が数値で意思決定できる。
SaaS 導入の稟議では「月額いくら」だけでなく 5年 NPV・隠れコスト・撤退基準 を添えることで、後年の値上げやロックインのリスクを事前に経営と合意できる。
損益分岐点（月 480 万通）を BigQuery のダッシュボードで監視し、超過が継続したら内製移行の PoC を起票する運用 trigger に接続する。
設計判断がオプション価値になる: SaaS 連携アダプタを抽象レイヤ（Protocol / インターフェース）として実装し、将来の内製差し替えコストを下げる。エンジニアの設計判断がそのままビジネスのオプション価値（将来の選択肢を残す）になる。
今日のまとめ
Build vs Buy の意思決定は「名目 5年総額の比較」では誤る。① 前倒し投資（内製）と後払い運用費（SaaS）を NPV（割引率で現在価値に揃える）で公平に比べ、② 隠れコスト（移行・学習・ロックイン・解約）を TCO に含め、③ 感度分析（損益分岐点）で配信量成長シナリオを織り込み、④ 意思決定マトリクス（加重スコア）で定性リスクも統合し、⑤ 撤退基準（trigger）を添える。 この 5 点セットで、エンジニアが CFO・経営に「なぜこの選択か」を数値で語れる。
次のステップ
- 発展問題: SaaS 案を採用した場合の連携アダプタを、将来の内製移行コストを最小化する抽象レイヤ（Protocol）として設計せよ。ロックインを薄く保つインターフェース境界と、移行時に差し替える実装範囲を図示すること。
- 参考: NPV/DCF（正味現在価値・割引キャッシュフロー）/ TCO（総所有コスト）/ 意思決定マトリクス（加重スコアリング）/ Real Options（リアルオプション）/ Payback Period / 6W3H フレームワーク