ストーリー

ATAM（Architecture Tradeoff Analysis Method）

ATAMの概要

// ATAMの9ステップ
const ATAM_STEPS = [
  // Phase 1: プレゼンテーション
  { step: 1, name: "ATAMの説明", who: "評価リーダー" },
  { step: 2, name: "ビジネスドライバーの説明", who: "プロジェクトマネージャー" },
  { step: 3, name: "アーキテクチャの説明", who: "アーキテクト" },

  // Phase 2: 調査と分析
  { step: 4, name: "アーキテクチャアプローチの特定", who: "全員" },
  { step: 5, name: "品質属性ユーティリティツリーの作成", who: "全員" },
  { step: 6, name: "アーキテクチャアプローチの分析", who: "全員" },

  // Phase 3: テスト
  { step: 7, name: "シナリオのブレインストーミングと優先順位付け", who: "ステークホルダー" },
  { step: 8, name: "アーキテクチャアプローチの再分析", who: "全員" },

  // Phase 4: レポート
  { step: 9, name: "結果の報告", who: "評価リーダー" },
];

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

// ユーティリティツリー: 品質属性を具体的なシナリオに分解
interface QualityAttributeTree {
  root: "ユーティリティ（システムの有用性）";
  attributes: QualityAttribute[];
}

interface QualityAttribute {
  name: string;
  refinements: Refinement[];
}

interface Refinement {
  scenario: string;
  priority: { business: 'H' | 'M' | 'L'; technical: 'H' | 'M' | 'L' };
}

const UTILITY_TREE_EXAMPLE: QualityAttribute[] = [
  {
    name: "パフォーマンス",
    refinements: [
      {
        scenario: "ピーク時（通常の3倍）でもAPI応答がp99 < 200ms",
        priority: { business: 'H', technical: 'H' },
      },
      {
        scenario: "フィード生成が1秒以内に完了する",
        priority: { business: 'H', technical: 'M' },
      },
    ],
  },
  {
    name: "可用性",
    refinements: [
      {
        scenario: "1つのAZが障害でも99.99%の可用性を維持",
        priority: { business: 'H', technical: 'H' },
      },
      {
        scenario: "データベース障害時に読み取り専用モードで継続",
        priority: { business: 'M', technical: 'H' },
      },
    ],
  },
  {
    name: "セキュリティ",
    refinements: [
      {
        scenario: "SQLインジェクション攻撃を100%防御",
        priority: { business: 'H', technical: 'M' },
      },
    ],
  },
  {
    name: "変更容易性",
    refinements: [
      {
        scenario: "新しい決済プロバイダの追加が2週間以内",
        priority: { business: 'M', technical: 'M' },
      },
    ],
  },
];

リスクとトレードオフの特定

// ATAMの分析結果カテゴリ
interface ATAMFindings {
  // リスク: アーキテクチャ上の問題で品質属性に悪影響を与える可能性
  risks: Risk[];

  // 非リスク: 分析の結果、問題がないと判断された設計判断
  nonRisks: string[];

  // 感度点: 小さな変更が品質属性に大きな影響を与えるポイント
  sensitivityPoints: SensitivityPoint[];

  // トレードオフ: ある品質属性の改善が別の品質属性を悪化させるポイント
  tradeoffs: Tradeoff[];
}

interface Risk {
  id: string;
  description: string;
  affectedAttribute: string;
  likelihood: 'high' | 'medium' | 'low';
  impact: 'high' | 'medium' | 'low';
  mitigation: string;
}

interface Tradeoff {
  id: string;
  description: string;
  improves: string;   // 改善される品質属性
  degrades: string;   // 悪化する品質属性
  decision: string;   // 最終的な判断
}

// 例
const EXAMPLE_FINDINGS = {
  risks: [
    {
      id: "R-001",
      description: "単一のメッセージブローカーがSPOFになっている",
      affectedAttribute: "可用性",
      likelihood: "medium",
      impact: "high",
      mitigation: "Kafkaクラスターの冗長化とマルチAZ配置",
    },
  ],
  tradeoffs: [
    {
      id: "T-001",
      description: "キャッシュの積極的活用",
      improves: "パフォーマンス（レイテンシ低減）",
      degrades: "一貫性（キャッシュとDBの不整合リスク）",
      decision: "TTL 60秒のキャッシュを採用。一貫性はイベント駆動の無効化で補完",
    },
  ],
};

その他のレビュー手法

const REVIEW_METHODS = {
  atam: {
    name: "ATAM",
    focus: "トレードオフ分析",
    scale: "大規模プロジェクト",
    duration: "2-3日",
  },
  adr: {
    name: "ADRレビュー",
    focus: "個別の設計判断の妥当性",
    scale: "日常的な判断",
    duration: "30分-1時間",
  },
  threatModeling: {
    name: "脅威モデリング (STRIDE)",
    focus: "セキュリティリスク",
    scale: "セキュリティ要件が高いシステム",
    duration: "半日-1日",
  },
  failureAnalysis: {
    name: "障害モード分析 (FMEA)",
    focus: "障害パターンの網羅的分析",
    scale: "ミッションクリティカルシステム",
    duration: "1日",
  },
};

まとめ

チェックリスト

• ATAMの9ステップの流れを理解した
• ユーティリティツリーの作成方法を把握した
• リスクとトレードオフの特定方法を理解した
• レビュー手法の使い分けを把握した

次のステップへ

次は「技術戦略の策定」を学びます。組織全体の技術方針をどう定め、実行するかを掘り下げます。

推定読了時間: 30分