影響分析:

• God Object（order.rb）: 変更のたびに予期しない副作用が発生。8チーム中6チームがこのファイルを日常的に変更し、マージコンフリクトが週平均12件発生。
• 循環依存: テストの独立実行が不可能。order_serviceのテストにpayment_serviceのモックが必須で、テスト実行時間の30%を占める。
• Shared DB: スキーマ変更が全チームに影響。カラム追加でも全チームの承認が必要で、リードタイム平均2週間。

技術的負債スコア = 変更頻度 × バグ率 × 複雑度係数

ヒートマップの解釈:

graph TD
    subgraph HH["高バグ率 × 高変更頻度\n最優先で分割"]
        A1["order.rb\norder_svc"]
    end
    subgraph HL["高バグ率 × 低変更頻度"]
        A2["payment.rb\npayment_svc"]
    end
    subgraph LH["低バグ率 × 高変更頻度\n次フェーズで対応"]
        A3["orders_controller"]
    end
    subgraph LL["低バグ率 × 低変更頻度\n現状維持可"]
        A4["product.rb"]
        A5["user.rb"]
    end

    style HH fill:#fee2e2,stroke:#dc2626,stroke-width:3px,color:#991b1b
    style HL fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style LH fill:#fef3c7,stroke:#d97706,color:#92400e
    style LL fill:#d1fae5,stroke:#059669,color:#065f46
    style A1 fill:#fee2e2,stroke:#dc2626,color:#991b1b
    style A2 fill:#fef3c7,stroke:#d97706,color:#92400e
    style A3 fill:#fef3c7,stroke:#d97706,color:#92400e
    style A4 fill:#d1fae5,stroke:#059669,color:#065f46
    style A5 fill:#d1fae5,stroke:#059669,color:#065f46

推奨アクション: order.rb と order_service.rb を最優先で分割。この2ファイルだけでバグの47%、マージコンフリクトの60%を占めている。

依存グラフ:

graph TD
    OM["Order<br/>Model"] --> OS["OrderService"]
    OS --> PS["PaymentSvc<br/>（循環依存!）"]
    PS --> OS
    OM --> NS["NotificationService<br/>（全サービスから直接依存）"]
    OS --> IS["InventorySvc"]
    OS --> NS
    IS --> NS
    PS --> NS
    OM --> DB["PostgreSQL（単一DB）<br/>300テーブル、全モジュールが共有"]
    OS --> DB
    IS --> DB
    PS --> DB
    NS --> DB

    classDef danger fill:#fee,stroke:#c33,color:#333
    classDef warning fill:#fff3cd,stroke:#f0ad4e,color:#333
    classDef db fill:#e8f4fd,stroke:#2196f3,color:#333
    class PS danger
    class NS warning
    class DB db

結合度メトリクス:

凝集度評価:

# ShopMaster マイクロサービス移行アセスメントレポート

## 1. エグゼクティブサマリー

ShopMasterは5年間の成長により、モノリスの限界に達している。
デプロイ頻度（月2回）がビジネス要求（週次リリース）に追いつかず、
障害復旧時間（4時間）がSLO（30分）を大幅に超過している。

移行推奨度: ★★★★☆（強く推奨）

## 2. 現状の問題（定量データ）

| 指標 | 現状 | 目標 | ギャップ |
|------|------|------|---------|
| デプロイ頻度 | 月2回 | 週1回以上 | 2倍以上 |
| ビルド時間 | 45分 | 10分以内 | 4.5倍 |
| テスト時間 | 2時間 | 20分以内 | 6倍 |
| MTTR | 4時間 | 30分 | 8倍 |
| マージコンフリクト | 週12件 | 週2件以下 | 6倍 |

## 3. 移行の推奨フェーズ

### Phase 1（3ヶ月）: Strangler Fig開始
- NotificationServiceをイベント駆動に分離
- APIゲートウェイの導入
- CI/CDパイプラインの分離準備

### Phase 2（6ヶ月）: コアサービス分離
- Order/Payment の循環依存解消
- Orderサービスの独立（DB分離含む）
- Paymentサービスの独立

### Phase 3（6ヶ月）: 完全移行
- 残りモジュールの段階的分離
- 共有DBの完全分離
- モノリスの廃止

## 4. リスク評価

| リスク | 影響度 | 発生確率 | 対策 |
|--------|--------|---------|------|
| データ整合性の喪失 | 高 | 中 | Sagaパターン導入 |
| 運用複雑度の増大 | 中 | 高 | SREチーム組成 |
| チームスキル不足 | 中 | 中 | 段階的研修 |

## 5. 必要リソース

- 専任移行チーム: 5名 × 15ヶ月
- インフラ追加コスト: 月額約50万円増
- 研修コスト: 約200万円