## 技術スタック

| レイヤー | 選択 | 理由 |
|---------|------|------|
| バックエンド | NestJS + TypeScript | 型安全、チームのJS経験、構造的 |
| フロントエンド | Next.js + TypeScript | SSR対応、React経験活用 |
| DB | PostgreSQL | RLS対応、マルチテナント実績 |
| ORM | Prisma | 型安全、マイグレーション自動化 |
| 認証 | Auth0 | マルチテナント対応、セキュリティ |
| インフラ | AWS (ECS + RDS) | マネージド中心で運用負荷軽減 |
| CI/CD | GitHub Actions | チーム全員が使い慣れている |
| モニタリング | Datadog | APM + ログ + メトリクスの統合 |

## 技術ロードマップ

### MVP（Month 1-4）
| 月 | テーマ | 成果物 |
|----|--------|--------|
| 1 | 基盤構築 | 認証、マルチテナント基盤、CI/CD |
| 2 | コア機能 | 健康データCRUD、基本API |
| 3 | ダッシュボード | 分析レポート、管理画面 |
| 4 | 品質・リリース | テスト強化、セキュリティ監査、MVP |

### 拡張（Month 5-10）
| 月 | テーマ |
|----|--------|
| 5-6 | モバイルアプリ対応、API拡張 |
| 7-8 | パフォーマンス最適化、スケーリング |
| 9-10 | AI分析機能、外部連携 |

## Technology Radar
### Adopt: TypeScript, Next.js, PostgreSQL, Docker, GitHub Actions
### Trial: Prisma, Auth0, Datadog
### Assess: GraphQL, Terraform, OpenTelemetry
### Hold: MongoDB（マルチテナントのRLS不可）

# ADR-001: マルチテナント方式にRow-Level Securityを採用

## ステータス
承認済み

## コンテキスト
企業向けSaaSのため、テナント（企業）ごとにデータを分離する必要がある。
候補:
1. DB分離（テナントごとに別DB）: セキュリティ最強だが運用コスト大
2. スキーマ分離（テナントごとに別スキーマ）: 中間的だが複雑
3. 行レベル分離（RLS）: 共有テーブル + PostgreSQL RLS

## 決定
PostgreSQL の Row-Level Security（RLS）を採用する。

## 結果
### ポジティブ
- インフラコストが最小（1つのDBインスタンス）
- Prismaとの統合が可能
- テナント追加の運用が簡単
### ネガティブ
- RLS の設定ミスで他テナントのデータが見えるリスク → E2Eテストで検証
- 大規模時のパフォーマンス懸念 → 初年度1万人なら問題なし

---

# RFC-001: 健康データの暗号化戦略（概要）

## サマリー
健康データ（個人情報 + 診断結果）の暗号化方式を定義する。

## 代替案
1. **アプリケーション層暗号化**: Prisma middleware で透過的に暗号化
2. **DB層暗号化**: PostgreSQL pgcrypto
3. **AWS KMS + Envelope暗号化**: KMSでデータキーを管理

推奨: AWS KMS + アプリケーション層暗号化の組み合わせ

## リスク
| リスク | 軽減策 |
|--------|--------|
| 鍵の漏洩 | AWS KMS + IAMで厳格にアクセス制御 |
| 暗号化によるパフォーマンス低下 | 検索対象フィールドのみ暗号化 |
| 鍵ローテーション | KMSの自動ローテーション機能を利用 |

## ジュニア（入社3ヶ月目）のオンボーディング計画

### 目標: 1ヶ月後に簡単なAPIエンドポイントを一人で実装できる

| 週 | テーマ | 方法 |
|----|--------|------|
| 1 | プロジェクト概要とアーキテクチャ理解 | ペアプロ + ドキュメント |
| 2 | NestJS + Prismaの基本操作 | ハンズオン + バグ修正タスク |
| 3 | テストの書き方、PR作成 | TDDペアプロ |
| 4 | 簡単なAPIを自力で実装 | サポート付きで自走 |

## スキルマップ

| スキル | シニア | ジュニア | FE-1 | FE-2 | インフラ |
|--------|:------:|:--------:|:----:|:----:|:--------:|
| TypeScript | A | B | A | B | C |
| NestJS | A | C | C | C | D |
| React/Next.js | B | D | A | A | D |
| PostgreSQL | A | C | B | B | B |
| AWS | B | D | D | D | A |
| テスト | A | C | B | B | B |
| セキュリティ | B | D | C | C | B |

（A=指導できる, B=自走できる, C=支援が必要, D=未経験）

## 心理的安全性の施策
1. 週次の「困っていること共有タイム」（5分 × 全員）
2. Blameless Postmortemの導入を宣言し、第1回を自分の失敗で実施
3. Slack #質問-何でも チャンネルを作り、リードが最初に質問を投稿

# HealthTrack 技術戦略報告書

## エグゼクティブサマリー
TypeScript統一スタック（NestJS + Next.js + PostgreSQL）を採用し、
AWS上にマルチテナントSaaSを構築します。MVPを4ヶ月でリリースします。

## 技術方針
- **型安全**: TypeScript統一で品質とDXを両立
- **セキュリティ最優先**: RLS + AWS KMS暗号化 + Auth0認証
- **運用効率**: マネージドサービス中心でインフラ負荷を最小化

## スケジュールとコスト
| 項目 | 内容 |
|------|------|
| MVPリリース | 4ヶ月後（Month 4末） |
| 月額インフラコスト | 推定15-20万円（予算30万円以内） |
| チーム | 6名（FTE換算5.5名） |

## リスクと対策
| リスク | 対策 |
|--------|------|
| ジュニアの立ち上がり | ペアプロ + 段階的なタスクアサイン |
| セキュリティ要件の不確実性 | 専門家レビューをMonth 3に実施 |
| インフラ担当の兼務 | IaCで自動化し、運用負荷を最小化 |

## 次のアクション
1. 来週: 開発環境の構築開始
2. 2週間後: 認証 + マルチテナント基盤のPoC完了
3. 1ヶ月後: コア機能の開発開始

## ナレッジ共有計画

### ドキュメント整備
| ドキュメント | 担当 | 期限 |
|-------------|------|------|
| オンボーディングガイド | テクニカルリード | Week 1 |
| ADR テンプレート + 初期ADR 3件 | テクニカルリード | Week 2 |
| API設計ガイドライン | シニアエンジニア | Week 3 |
| Runbook テンプレート | インフラ担当 | Week 4 |

### 定期的な共有活動
| 活動 | 頻度 | 内容 |
|------|------|------|
| デイリースタンドアップ | 毎日15分 | 進捗とブロッカーの共有 |
| 設計レビュー | 週1回60分 | RFC/設計ドキュメントのレビュー |
| テックトーク | 隔週30分 | 学んだことの共有（LT形式） |
| 振り返り（レトロ） | 隔週60分 | プロセスの改善 |

### ツール
- ドキュメント: GitHub リポジトリ内 docs/
- コミュニケーション: Slack + Notion
- 設計議論: Miro + RFC
- API ドキュメント: OpenAPI + Swagger UI（自動生成）

### 効果測定（3ヶ月後に評価）
- オンボーディング時間: 目標1日以内
- ADR作成件数: 月2件以上
- テックトーク登壇率: チーム全員が1回以上