ストーリー

ATAM（Architecture Tradeoff Analysis Method）

概要

ATAMのプロセス

Phase 1: プレゼンテーション
├── 1. ATAM手法の説明
├── 2. ビジネスドライバーの提示
└── 3. アーキテクチャの提示

Phase 2: 調査と分析
├── 4. アーキテクチャアプローチの特定
├── 5. 品質属性ユーティリティツリーの生成
└── 6. アーキテクチャアプローチの分析

Phase 3: テストと報告
├── 7. ブレインストーミングとシナリオの優先順位付け
├── 8. アーキテクチャアプローチの分析（再）
└── 9. 結果の報告

品質属性ユーティリティツリー

utility_tree:
  performance:
    - scenario: "ピーク時に1秒以内でAPIレスポンスを返す"
      importance: High
      difficulty: Medium
    - scenario: "1,000同時接続を処理する"
      importance: High
      difficulty: High

  availability:
    - scenario: "月間99.9%の可用性を維持する"
      importance: High
      difficulty: Medium

  security:
    - scenario: "患者データを暗号化して保存する"
      importance: High
      difficulty: Low

  modifiability:
    - scenario: "新しい決済プロバイダーを2週間以内に追加できる"
      importance: Medium
      difficulty: Medium

  scalability:
    - scenario: "トラフィックが10倍になっても水平スケールで対応できる"
      importance: Medium
      difficulty: High

「ATAMのフル実施は数日かかる。現実には軽量版ATAMとして、ユーティリティツリーとトレードオフ分析だけを2-3時間で実施するのが実用的だ」 — 佐藤CTO

アーキテクチャレビューボード

構成

レビューの分類

review_tiers:
  tier1_lightweight:
    trigger: "単一サービス内の設計変更"
    process: "PRベースのレビュー（ADR + 設計図）"
    participants: "チーム内 + テックリード"
    duration: "非同期、1-3日"
    approval: "テックリードの承認"

  tier2_standard:
    trigger: "サービス間の連携変更、新技術採用"
    process: "30分のレビューミーティング + ADR"
    participants: "レビューボードから2-3名"
    duration: "1週間以内"
    approval: "レビューボード2名の承認"

  tier3_full:
    trigger: "アーキテクチャの根本的変更、新システム設計"
    process: "軽量ATAM（2-3時間のワークショップ）"
    participants: "レビューボード全員 + ステークホルダー"
    duration: "2週間以内"
    approval: "チーフアーキテクトの承認"

設計レビューチェックリスト

汎用チェックリスト

design_review_checklist:
  business_alignment:
    - "ビジネス要件を満たしているか？"
    - "将来のビジネス目標との整合性はあるか？"

  quality_attributes:
    - "パフォーマンス要件を満たせるか？"
    - "可用性要件を満たせるか？"
    - "セキュリティ要件を満たせるか？"
    - "スケーラビリティは考慮されているか？"

  architecture_principles:
    - "組織のアーキテクチャ原則に準拠しているか？"
    - "既存システムとの整合性はあるか？"
    - "不必要な複雑さを導入していないか？"

  operational_readiness:
    - "監視・アラートの設計はあるか？"
    - "障害時のリカバリー方法は明確か？"
    - "デプロイ・ロールバック手順は定義されているか？"

  team_capability:
    - "チームがこの技術を運用できるか？"
    - "必要なスキルアップの計画はあるか？"

  cost:
    - "インフラコストの見積もりはあるか？"
    - "TCO（Total Cost of Ownership）は検討されているか？"

RFCプロセス

RFC（Request for Comments）とは

RFCテンプレート

# RFC-NNN: [タイトル]

## メタ情報
- 作成者: [名前]
- 作成日: [日付]
- レビュー期限: [日付]（作成日から2週間）
- ステータス: [Draft | In Review | Accepted | Rejected | Withdrawn]

## サマリー
[1-2文で変更の概要を説明]

## 動機
[なぜこの変更が必要か]

## 詳細設計
[技術的な詳細、図表を含む]

## トレードオフと代替案
[検討した代替案とその比較]

## 移行計画
[段階的な移行ステップ]

## 未解決の問題
[まだ決まっていない点]

## フィードバック
### [レビュアー名] - [日付]
[コメント]

### [レビュアー名] - [日付]
[コメント]

RFCプロセスのフロー

1. RFC作成（Draft）
   └── 作成者が RFC を書いて GitHub に PR を出す

2. レビュー期間（2週間）
   ├── 全エンジニアが PR にコメント可能
   ├── 週1回の同期ミーティング（オプション）
   └── 作成者がフィードバックを反映

3. 決定
   ├── レビューボードが Accept / Reject を判断
   └── Accept の場合 → ADR として確定

4. 実装
   └── 決定に基づいて実装を開始

「RFCプロセスの本質は透明性と包括性だ。全員に意見を言う機会を与え、その上で合理的に決定する。反対意見があっても、プロセスを経た決定には全員がコミットする — これが”Disagree and Commit”だ」 — 佐藤CTO

レビュープロセスのアンチパターン

まとめ

チェックリスト

• ATAMの概要と品質属性ユーティリティツリーを理解した
• レビューボードの構成とTier分類を把握した
• 設計レビューチェックリストの項目を理解した
• RFCプロセスのフローとADRとの関係を理解した

次のステップへ

次は「テクニカルスタンダードと原則」を学びます。レビュープロセスの基盤となる技術標準をどのように策定・維持するかを見ていきましょう。

推定読了時間: 40分