adr-writer

ADR ライター

明確な背景、代替案、影響を含めて、アーキテクチャ上の意思決定を文書化します。

ADR テンプレート

# ADR-001: [Title of Decision]

**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-XXX
**Date:** 2024-01-15
**Deciders:** Alice (Tech Lead), Bob (Principal Engineer)
**Owner:** Alice

## Context

What is the issue we're facing? What factors are driving this decision?

We need to choose a database for our new analytics service. Current
requirements:

- 10M+ events per day
- Complex aggregation queries
- Real-time dashboards
- Budget: $5k/month
- Team familiar with SQL

## Decision

We will use PostgreSQL with TimescaleDB extension.

## Alternatives Considered

### Option 1: PostgreSQL + TimescaleDB (CHOSEN)

**Pros:**

- Team already knows PostgreSQL
- Time-series optimization for analytics
- Reliable and proven
- Good query performance
- Reasonable cost (~$3k/month)

**Cons:**

- Requires manual scaling effort
- Not purpose-built for analytics

### Option 2: ClickHouse

**Pros:**

- Excellent query performance for analytics
- Built for analytics workloads
- Column-oriented storage

**Cons:**

- Team unfamiliar with ClickHouse
- Steeper learning curve
- Different query syntax

### Option 3: BigQuery

**Pros:**

- Fully managed
- Excellent for analytics
- Scales automatically

**Cons:**

- Higher cost (~$8k/month for our volume)
- Vendor lock-in to GCP
- Less control over optimization

## Tradeoffs

**What we're optimizing for:**

- Team velocity (familiar tech)
- Cost efficiency
- Good enough performance

**What we're sacrificing:**

- Peak analytical performance (vs ClickHouse)
- Fully managed experience (vs BigQuery)

## Consequences

### Positive

- Development can start immediately (no learning curve)
- Lower operational costs
- Can reuse existing PostgreSQL expertise
- Easy integration with current stack

### Negative

- Will need to manually optimize queries
- May need to revisit if we scale 10x
- Requires more operational work than BigQuery

### Risks

- Performance may degrade at 100M+ events/day
- **Mitigation:** Monitor query performance, plan migration at 50M events/day

## Implementation Notes

- Use TimescaleDB hypertables for event storage
- Implement continuous aggregates for common queries
- Set up read replicas for dashboard queries
- Document scaling runbook at 50M events/day

## Follow-up Actions

- [ ] Provision PostgreSQL + TimescaleDB cluster (Alice, by 2024-01-20)
- [ ] Create migration script from MySQL (Bob, by 2024-01-22)
- [ ] Set up monitoring dashboards (Alice, by 2024-01-25)
- [ ] Document scaling thresholds (Alice, by 2024-01-30)

## References

- [TimescaleDB Benchmarks](https://example.com)
- [Cost Analysis Spreadsheet](https://docs.google.com/...)
- [Team Survey Results](https://example.com)

## Revision History

- 2024-01-15: Initial draft (Alice)
- 2024-01-16: Added cost analysis (Bob)
- 2024-01-17: Accepted by architecture review board

ADR の番号付け

ADR-001: Initial System Architecture
ADR-002: Database Selection for Analytics
ADR-003: Authentication Strategy
...

ステータスのワークフロー

Proposed → Accepted → Implemented
    ↓
Rejected

Accepted → Deprecated → Superseded by ADR-XXX

よくある意思決定の種類

テクノロジーの選定：

• データベースの選択
• フレームワークの選定
• クラウドプロバイダー
• プログラミング言語

アーキテクチャパターン：

• マイクロサービスとモノリス
• イベント駆動とリクエスト／レスポンス
• 同期と非同期の通信

インフラストラクチャ：

• デプロイ戦略
• モニタリングの方法
• スケーリング戦略

セキュリティ：

• 認証方式
• データの暗号化方式
• アクセス制御モデル

クイックスタートガイド

# 1. Create new ADR
cp templates/adr-template.md docs/adr/ADR-042-title.md

# 2. Fill in sections
# - Context: Why are we making this decision?
# - Decision: What did we decide?
# - Alternatives: What else did we consider?
# - Consequences: What are the impacts?

# 3. Review with team
# - Share in architecture channel
# - Get feedback from stakeholders
# - Iterate on alternatives

# 4. Update status to "Accepted"
# 5. Link from main architecture docs

ベストプラクティス

1. 重要な意思決定について ADR を作成する：すべての選択に ADR が必要なわけではありません
2. 代替案を文書化する：選択肢を検討したことを示します
3. トレードオフを正直に記載する：どの意思決定にもデメリットがあります
4. 簡潔にまとめる：最大 1～2 ページにします
5. ステータスを更新する：非推奨／後継 ADR に置き換えられた ADR に印を付けます
6. 関連する ADR をリンクする：意思決定の経緯をたどれるようにします
7. フォローアップを含める：担当者を明記したアクション項目を記載します

アンチパターン

❌ 詳細すぎる：誰も読まない 10 ページの ADR ❌ 代替案がない：意思決定があらかじめ決まっていたように見えます ❌ 影響の記載がない：デメリットを無視しています ❌ 担当者がいない：責任を負う人がいません ❌ ステータスが古い：古い ADR が「提案済み」のままになっています

レビューチェックリスト

• 背景に問題が明確に記載されている
• 意思決定が明示されている
• 2 つ以上の代替案を検討している
• トレードオフが正直に評価されている
• 影響（良い点と悪い点）が文書化されている
• リスクとその軽減策が特定されている
• 意思決定の担当者が割り当てられている
• 期限付きのフォローアップアクションがある
• ステータスが最新である

成果物チェックリスト

• ADR ドキュメントが作成されている
• 背景で問題が説明されている
• 意思決定が明確に記載されている
• 2～3 個の代替案が文書化されている
• トレードオフのセクションが記入されている
• 影響（良い点と悪い点）が列挙されている
• リスクとその軽減策が特定されている
• 意思決定日と担当者が記載されている
• フォローアップアクションが割り当てられている
• ステータスが設定されている