## 機能要件
1. 商品の全文検索（キーワード、カテゴリ、価格範囲でのフィルタ）
2. 商品カタログのCRUD操作（管理画面から）
3. 既存Railsアプリとの API 連携（段階的移行のため）
4. 商品画像の管理・配信

## 非機能要件
- パフォーマンス: 検索レスポンス200ms以内（P95）
- スケーラビリティ: 月間200万ユーザーに対応可能
- 可用性: 99.9%（月間ダウンタイム43分以内）
- セキュリティ: 管理者認証、APIレート制限

## 制約条件
- 予算: OSS優先、クラウドコストは月10万円以内
- 期限: 3ヶ月で初期リリース
- チームスキル: Ruby/JS経験あり、GoやRustの経験なし
- 既存システム: Rails + PostgreSQLとの共存が必要

| 基準 | 重み | 根拠 |
|------|------|------|
| 学習コスト | 5 | チームのRuby/JS経験を活かしたい。3ヶ月の期限 |
| パフォーマンス | 4 | 検索API 200ms以内の要件 |
| TypeScript対応 | 4 | フロントエンドとの型共有で生産性向上 |
| エコシステム成熟度 | 4 | ORM、テストツール等が揃っているか |
| スケーラビリティ | 3 | 将来の200万ユーザー対応 |
| コミュニティサイズ | 3 | 困った時に情報が見つかるか |
| 既存システムとの統合 | 4 | Rails APIとの連携容易性 |
| 運用実績 | 3 | 本番環境での安定性 |
| ベンダーロックイン | 2 | OSSなのでリスクは低い |

| 基準（重み） | NestJS | Fastify | Go + Echo |
|-------------|:------:|:-------:|:---------:|
| 学習コスト (5) | 3 | 4 | 2 |
| パフォーマンス (4) | 3 | 4 | 5 |
| TypeScript対応 (4) | 5 | 5 | 1 |
| エコシステム成熟度 (4) | 5 | 3 | 4 |
| スケーラビリティ (3) | 4 | 4 | 5 |
| コミュニティサイズ (3) | 4 | 3 | 4 |
| 既存システム統合 (4) | 4 | 4 | 3 |
| 運用実績 (3) | 4 | 3 | 5 |
| ベンダーロックイン (2) | 5 | 5 | 5 |
| **加重合計** | **133** | **131** | **115** |

### NestJS の Pros/Cons
- Pros: DI、モジュール構造がRailsに近い。エコシステム充実
- Cons: 抽象度が高く、初期学習コストがやや高い

### Fastify の Pros/Cons
- Pros: 高速。シンプル。プラグイン機構が柔軟
- Cons: NestJSほど構造化されていない。大規模開発で規律が必要

### Go + Echo の Pros/Cons
- Pros: 圧倒的なパフォーマンス。バイナリデプロイが容易
- Cons: チームにGo経験者なし。3ヶ月の期限では学習コストが高い

## PoC計画: NestJS vs Fastify

### 仮説
NestJSのモジュール構造により、大規模化した際の保守性がFastifyより優れる。
一方、Fastifyの方がシンプルで、初期開発速度は高い。

### 成功基準
| 基準 | 閾値 | 計測方法 |
|------|------|---------|
| 商品検索APIの実装速度 | 両者の工数差が20%以内 | 実装時間を記録 |
| 検索APIのレスポンス時間 | 200ms以内（1000商品） | k6で負荷テスト |
| コードの可読性 | チーム評価で4/5以上 | アンケート |
| テストの書きやすさ | カバレッジ80%を1日で達成 | テストカバレッジ計測 |

### スコープ
- やること:
  - 商品検索API（GET /products?q=xxx）の実装
  - PostgreSQLとの接続（Prisma使用）
  - 基本的なバリデーション
  - ユニットテスト
- やらないこと:
  - 認証・認可
  - 管理画面
  - Dockerコンテナ化
  - CI/CD

### スケジュール
| 日程 | NestJS担当 | Fastify担当 |
|------|-----------|------------|
| Day 1-2 | プロジェクト初期設定 | プロジェクト初期設定 |
| Day 3-5 | 商品検索API実装 | 商品検索API実装 |
| Day 6-7 | テスト実装 | テスト実装 |
| Day 8-9 | パフォーマンス計測 | パフォーマンス計測 |
| Day 10 | レポート作成・比較 | レポート作成・比較 |

## プロダクト開発チーム Technology Radar（2025 Q2）

### Adopt（採用）
| 技術 | 象限 | 説明 |
|------|------|------|
| TypeScript | Languages & Frameworks | 全プロジェクトの標準言語 |
| PostgreSQL | Platforms | メインデータベース |
| Docker | Platforms | 開発・本番環境の標準 |
| GitHub Actions | Tools | CI/CDパイプライン |

### Trial（試用）
| 技術 | 象限 | 説明 |
|------|------|------|
| NestJS | Languages & Frameworks | マイクロサービス候補 |
| Prisma | Tools | 型安全ORM |
| Elasticsearch | Platforms | 全文検索エンジン |

### Assess（評価）
| 技術 | 象限 | 説明 |
|------|------|------|
| Hono | Languages & Frameworks | 軽量Webフレームワーク |
| Meilisearch | Platforms | Elasticsearchの代替 |
| OpenTelemetry | Tools | 分散トレーシング |

### Hold（保留）
| 技術 | 象限 | 説明 |
|------|------|------|
| jQuery | Languages & Frameworks | 新規採用禁止 |
| Heroku | Platforms | コスト面でAWSに移行 |

# 技術選定レポート: 商品検索マイクロサービス

## エグゼクティブサマリー
商品検索マイクロサービスのバックエンドフレームワークとして、
NestJS（TypeScript）を推奨する。

## 選定プロセス
1. 要件分析: 機能要件4項目、非機能要件4項目を定義
2. 候補評価: NestJS、Fastify、Go+Echo の3候補を9基準で評価
3. PoC実施: NestJS と Fastify の2週間PoCを計画

## 推奨: NestJS
### 理由
- 加重スコアで最高評価（133点）
- DI・モジュール構造がRailsに近く、チームの学習コストが低い
- TypeScript対応でフロントエンドとの型共有が可能
- エコシステムが成熟しており、Prisma等との統合が容易

### リスクと軽減策
| リスク | 軽減策 |
|--------|--------|
| パフォーマンスがFastifyに劣る | キャッシュ戦略で補完 |
| 抽象度の高さが学習障壁に | 社内勉強会で基本パターンを共有 |

## 次のアクション
1. 2週間のPoC実施（NestJS vs Fastify）
2. PoC結果を踏まえた最終判断
3. 本格開発開始