ストーリー

ATAMとは

ATAM（Architecture Tradeoff Analysis Method）は、アーキテクチャの品質属性に関するトレードオフを体系的に分析する手法です。

ATAMの目的

graph TD
    A["<b>ATAMの3つの目的</b><br/><br/>1. アーキテクチャのリスクを早期に発見する<br/>2. 品質属性間のトレードオフを明確にする<br/>3. ステークホルダー間の合意を形成する"]
    style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

ATAMの特徴

ATAMの9ステップ

フェーズ1: プレゼンテーション（ステップ1-3）

graph TD
    S1["Step 1: ATAMの紹介<br/>評価チームがATAMプロセスを参加者に説明"]
    S2["Step 2: ビジネスドライバーの提示<br/>プロジェクトマネージャーがビジネス目標を共有"]
    S3["Step 3: アーキテクチャの提示<br/>アーキテクトが現在の設計を説明"]

    S1 --> S2 --> S3

フェーズ2: 調査と分析（ステップ4-6）

graph TD
    S4["Step 4: アーキテクチャアプローチの特定<br/>使用しているパターン・戦術を列挙"]
    S5["Step 5: 品質属性ユーティリティツリーの生成<br/>品質属性をシナリオとして具体化"]
    S6["Step 6: アーキテクチャアプローチの分析<br/>シナリオに対する設計判断を分析"]

    S4 --> S5 --> S6

フェーズ3: テストと報告（ステップ7-9）

graph TD
    S7["Step 7: ブレインストーミングとシナリオの優先付け<br/>ステークホルダー全員でシナリオを追加"]
    S8["Step 8: アーキテクチャアプローチの再分析<br/>新シナリオに対する分析"]
    S9["Step 9: 結果の報告<br/>リスク、非リスク、感度点、トレードオフ点を報告"]

    S7 --> S8 --> S9

Step 5: 品質属性ユーティリティツリー

ATAMの核心となるのがユーティリティツリーです。品質属性を具体的なシナリオに落とし込み、優先度を付けます。

ユーティリティツリーの構造

ユーティリティ（全体目標）
├── パフォーマンス
│   ├── レイテンシ
│   │   ├── (H,H) API応答時間が95パーセンタイルで200ms以内
│   │   └── (M,L) バッチ処理が1時間以内に完了
│   └── スループット
│       └── (H,M) 同時1000リクエスト/秒を処理
├── 可用性
│   ├── 障害回復
│   │   ├── (H,H) 単一ノード障害時に30秒以内にフェイルオーバー
│   │   └── (M,M) データセンター障害時に5分以内に復旧
│   └── データ保全
│       └── (H,H) 障害時にデータ損失ゼロ
├── セキュリティ
│   ├── 認証
│   │   └── (H,M) 不正ログイン試行を検知しブロック
│   └── データ保護
│       └── (H,H) 個人情報が暗号化されて保存
└── 変更容易性
    ├── 機能追加
    │   └── (M,H) 新しい決済手段を2週間以内に追加
    └── 技術更新
        └── (L,M) フレームワークのメジャーバージョンアップを1ヶ月以内に実施

優先度の表記

(重要度, 達成難易度) — H: High, M: Medium, L: Low

interface QualityScenario {
  attribute: string;       // 品質属性
  subAttribute: string;    // サブ属性
  scenario: string;        // 具体的なシナリオ
  importance: "H" | "M" | "L";  // ビジネス上の重要度
  difficulty: "H" | "M" | "L";  // 技術的な達成難易度
}

// 優先順位の判断
// (H,H) → 最優先で分析すべき（重要かつ難しい）
// (H,M) → 優先的に分析
// (H,L) → 重要だが比較的容易（リスクは低い）
// (M,H) → 難しいがビジネス的には中程度

Step 4: アーキテクチャアプローチの特定

各品質属性を実現するために使用している（または検討している）アーキテクチャ戦術を特定します。

パフォーマンス戦術の例

// アーキテクチャ戦術の分類
const performanceTactics = {
  resourceDemand: [
    "計算量の削減（キャッシュ）",
    "データ転送量の削減（ページネーション）",
    "リクエストの間引き（レートリミット）",
  ],
  resourceManagement: [
    "並行処理（マルチスレッド、非同期I/O）",
    "リソースプーリング（コネクションプール）",
    "負荷分散（ロードバランサー）",
  ],
  resourceArbitration: [
    "スケジューリング戦略（FIFO、優先度ベース）",
    "オートスケーリング",
  ],
};

const availabilityTactics = {
  faultDetection: [
    "ヘルスチェック",
    "ハートビート",
    "例外検出",
  ],
  faultRecovery: [
    "アクティブ冗長化",
    "パッシブ冗長化",
    "リトライ",
    "サーキットブレーカー",
  ],
  faultPrevention: [
    "入力バリデーション",
    "トランザクション管理",
    "プロセス分離",
  ],
};

Step 6: 感度点とトレードオフ点

感度点（Sensitivity Point）

特定のアーキテクチャ決定が、ある品質属性に大きな影響を与えるポイントです。

graph LR
    D["決定:<br/>キャッシュのTTLを5分に設定"]
    P["パフォーマンス<br/>← TTLを短くすると低下"]
    F["データ鮮度<br/>← TTLを短くすると向上"]
    R["TTLの値はパフォーマンスに対する<b>感度点</b>"]

    D --> P
    D --> F
    P --> R
    F --> R

    style D fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style R fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

トレードオフ点（Tradeoff Point）

複数の品質属性に影響し、一方を改善すると他方が悪化するポイントです。

graph LR
    D["決定:<br/>書き込み時の同期レプリケーション"]
    C["一貫性 ↑ 向上<br/>（すべてのレプリカが同期）"]
    A["可用性 ↓ 低下<br/>（レプリカ障害で書込失敗）"]
    L["レイテンシ ↓ 低下<br/>（同期待ちが発生）"]
    R["同期方式はC-A-Lの<b>トレードオフ点</b>"]

    D --> C
    D --> A
    D --> L
    C --> R
    A --> R
    L --> R

    style D fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style C fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style A fill:#ffebee,stroke:#c62828,stroke-width:2px
    style L fill:#ffebee,stroke:#c62828,stroke-width:2px
    style R fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

リスクと非リスク

interface ATAMFinding {
  type: "RISK" | "NON_RISK" | "SENSITIVITY" | "TRADEOFF";
  description: string;
  relatedScenarios: string[];
  architecturalDecision: string;
}

// リスクの例
const risk: ATAMFinding = {
  type: "RISK",
  description: "単一のRDBMSに全データを集約しているため、" +
               "データ量増加時にスケーラビリティのボトルネックになる",
  relatedScenarios: [
    "同時1000リクエスト/秒を処理",
    "データ量が10倍に増加しても応答時間を維持"
  ],
  architecturalDecision: "全サービスが共有する単一PostgreSQLインスタンス",
};

// 非リスクの例
const nonRisk: ATAMFinding = {
  type: "NON_RISK",
  description: "ステートレスなAPIサーバー設計により、" +
               "水平スケーリングが容易に実現可能",
  relatedScenarios: ["同時1000リクエスト/秒を処理"],
  architecturalDecision: "セッション情報をRedisに外部化",
};

実践的ATAMワークショップの例

シナリオ: ECプラットフォームのアーキテクチャ評価

1. ビジネスドライバー

・年間売上100億円規模のECサイト
・セール時に通常の10倍のトラフィック
・グローバル展開を2年以内に計画
・決済の信頼性が最重要

2. ユーティリティツリー（抜粋）

3. アーキテクチャアプローチと分析

// 検討中のアプローチ
const approaches = {
  approach1: {
    name: "モジュラーモノリス + CDN",
    tactics: [
      "CloudFront + S3 で静的コンテンツ配信",
      "リードレプリカによるDB負荷分散",
      "Redisキャッシュレイヤー",
    ],
    sensitivity: "キャッシュTTL設定がセール時のパフォーマンスに直結",
    tradeoff: "モノリス内の決済モジュール障害が全体に波及するリスク",
    risk: "セール時のDB書き込み集中がボトルネックになる可能性",
  },
  approach2: {
    name: "マイクロサービス + イベント駆動",
    tactics: [
      "決済サービスを独立デプロイ",
      "Kafkaによる非同期処理",
      "サービスごとの独立DB",
    ],
    sensitivity: "イベントの順序保証がデータ整合性に影響",
    tradeoff: "運用の複雑性とチームの学習コスト",
    risk: "分散トランザクションの一貫性担保が困難",
  },
};

4. 結果のまとめ

graph TD
    subgraph リスク
        R1["R1: モノリスのDB書き込み集中（アプローチ1）"]
        R2["R2: 分散トランザクションの整合性（アプローチ2）"]
    end
    subgraph 感度点
        S1["S1: キャッシュTTL → パフォーマンス"]
        S2["S2: イベント順序保証 → データ整合性"]
    end
    subgraph トレードオフ点
        T1["T1: 決済の独立性 vs 運用複雑性"]
        T2["T2: 同期処理（一貫性）vs 非同期処理（性能）"]
    end
    subgraph 推奨
        REC["モジュラーモノリスから始め、<br/>決済モジュールを最初に分離する段階的アプローチ"]
    end

    リスク --> 感度点 --> トレードオフ点 --> 推奨

    style R1 fill:#ffebee,stroke:#c62828
    style R2 fill:#ffebee,stroke:#c62828
    style S1 fill:#fff3e0,stroke:#e65100
    style S2 fill:#fff3e0,stroke:#e65100
    style T1 fill:#e3f2fd,stroke:#1565c0
    style T2 fill:#e3f2fd,stroke:#1565c0
    style REC fill:#e8f5e9,stroke:#2e7d32

日常の設計判断へのATAM応用

「フルATAMは大規模プロジェクト向けだ。だが、そのエッセンスは日常の設計判断にも使える」と佐藤CTOはアドバイスします。

ライトウェイトATAM（30分版）

graph TD
    S1["1. 品質属性の列挙（5分）<br/>この決定に関わる品質属性を3つ以内で挙げる"]
    S2["2. シナリオの具体化（5分）<br/>各品質属性について具体的なシナリオを1つずつ書く"]
    S3["3. 選択肢の分析（10分）<br/>各選択肢が各シナリオにどう影響するか分析"]
    S4["4. 感度点・トレードオフ点の特定（5分）<br/>決定のどの部分がどの品質に影響するか明確化"]
    S5["5. リスクの判断と決定（5分）<br/>許容できるリスクを判断し、決定を下す"]

    S1 --> S2 --> S3 --> S4 --> S5

まとめ

チェックリスト

• ATAMの9ステップの流れを説明できる
• ユーティリティツリーを作成できる
• 感度点とトレードオフ点の違いを説明できる
• リスクと非リスクを区別できる
• ライトウェイトATAMを日常の判断に適用できる

次のステップへ

次はコスト・リスク分析を学びます。トレードオフを金銭的な観点からも評価する手法を身につけましょう。

推定読了時間: 40分