ストーリー

3つの選択肢

判断フレームワーク：Core vs Context

最も重要な判断軸は「その機能はコアコンピタンスか、コンテキスト（サポート機能）か」です。

graph TD
    subgraph Matrix["Core vs Context 判断マトリクス"]
        BLD["Build 推奨
差別化要因 × カスタマイズ必要"]
        BOSS["Build or 深いOSSカスタマイズ
差別化要因 × 標準的で十分"]
        OSS["OSS 推奨
共通機能 × カスタマイズ必要"]
        BUY["Buy 推奨
共通機能 × 標準的で十分"]
    end

    style BLD fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style BOSS fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style OSS fill:#d1fae5,stroke:#059669,color:#065f46
    style BUY fill:#f3f4f6,stroke:#9ca3af,color:#374151

「コアには投資し、コンテキストには投資しない。これが鉄則だ。世界最高の認証基盤を作っても、それがビジネスの差別化にならないなら、それは無駄な投資だ」 — 佐藤CTO

TCO（Total Cost of Ownership）分析

Build の TCO

build_tco:
  initial_cost:
    design: "2人月 × 単価100万円 = 200万円"
    development: "6人月 × 単価100万円 = 600万円"
    testing: "2人月 × 単価100万円 = 200万円"
    subtotal: "1,000万円"

  annual_recurring:
    maintenance: "1人月/年 × 単価100万円 = 100万円"
    infrastructure: "月5万円 × 12 = 60万円"
    security_patches: "0.5人月/年 = 50万円"
    subtotal: "210万円/年"

  hidden_costs:
    opportunity_cost: "エンジニア10人月をコア機能開発に使えたはず"
    knowledge_risk: "開発者退職時のリスク"
    security_risk: "脆弱性対応の自社責任"

Buy の TCO

buy_tco:
  initial_cost:
    license: "年間300万円"
    integration: "2人月 × 単価100万円 = 200万円"
    migration: "1人月 × 単価100万円 = 100万円"
    subtotal: "600万円"

  annual_recurring:
    license: "300万円/年"
    support_plan: "50万円/年"
    integration_maintenance: "0.5人月/年 = 50万円"
    subtotal: "400万円/年"

  hidden_costs:
    vendor_lock_in: "将来の移行コスト"
    customization_limit: "必要な機能が実装されないリスク"
    price_increase: "値上げリスク"

OSS の TCO

oss_tco:
  initial_cost:
    evaluation: "1人月 × 単価100万円 = 100万円"
    customization: "3人月 × 単価100万円 = 300万円"
    deployment: "1人月 × 単価100万円 = 100万円"
    subtotal: "500万円"

  annual_recurring:
    maintenance: "1人月/年 = 100万円"
    infrastructure: "月10万円 × 12 = 120万円"
    upgrade_tracking: "0.5人月/年 = 50万円"
    subtotal: "270万円/年"

  hidden_costs:
    community_risk: "プロジェクトの停滞・終了リスク"
    security_response: "脆弱性対応は自己責任"
    deep_customization: "アップグレード困難化リスク"

5年間 TCO 比較

ベンダー評価チェックリスト

Buy を選択する場合のベンダー評価項目です。

## ベンダー評価シート

### 1. 企業の信頼性
- [ ] 財務状況は健全か（上場企業/資金調達状況）
- [ ] 業界での実績・市場シェアは十分か
- [ ] SLA（99.9%以上）を提供しているか

### 2. 技術的適合性
- [ ] 必要な機能の80%以上をカバーしているか
- [ ] REST API / Webhook など統合方法が充実しているか
- [ ] データのエクスポート機能があるか

### 3. セキュリティ・コンプライアンス
- [ ] SOC 2 Type II 認証を取得しているか
- [ ] GDPR / 個人情報保護法に対応しているか
- [ ] データの保存場所を選択できるか

### 4. 契約条件
- [ ] 解約条件は合理的か（ロックイン期間）
- [ ] 価格の値上げ上限はあるか
- [ ] データポータビリティ条項はあるか

### 5. サポート体制
- [ ] 日本語サポートがあるか
- [ ] 対応時間は十分か（24/7 or ビジネスアワー）
- [ ] エスカレーション経路は明確か

判断のデシジョンツリー

graph TD
    Q1{"Q1: それは
コアコンピタンスか？"}
    Q1 -->|はい| BUILD["Build
自社の差別化に直結"]
    Q1 -->|いいえ| Q2{"Q2: 標準的な
機能で十分か？"}
    Q2 -->|はい| Q3{"Q3: 予算に
余裕があるか？"}
    Q2 -->|いいえ| Q4{"Q4: OSSで十分な
ベースがあるか？"}
    Q3 -->|はい| BUY["Buy
運用負荷を外部化"]
    Q3 -->|いいえ| OSS["OSS
コスト効率重視"]
    Q4 -->|はい| OSSC["OSS + カスタマイズ"]
    Q4 -->|いいえ| BUILD2["Build"]

    style Q1 fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style Q2 fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style Q3 fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style Q4 fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style BUILD fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style BUILD2 fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style BUY fill:#d1fae5,stroke:#059669,color:#065f46
    style OSS fill:#d1fae5,stroke:#059669,color:#065f46
    style OSSC fill:#d1fae5,stroke:#059669,color:#065f46

まとめ

チェックリスト

• Core vs Context の判断基準を理解した
• TCO分析の方法を把握した
• ベンダー評価のチェックリストを理解した
• デシジョンツリーに基づく判断ができるようになった

次のステップへ

次は「PoC と技術評価」を学びます。Build / Buy / OSS の候補が絞られたあと、実際に検証する方法 — PoC の設計とタイムボクシングについて見ていきましょう。

推定読了時間: 30分