ストーリー

品質特性（Quality Attributes）とは

アーキテクチャの品質を評価するための非機能要件の観点です。機能要件（何ができるか）に対して、品質特性は「どのように動作するか」を定義します。

主要な品質特性

アーキテクチャパターンと品質特性の関係

// ヘキサゴナルアーキテクチャが得意な品質特性
const hexagonalStrengths = {
  '変更容易性': '高い -- Adapterの差し替えが容易',
  'テスト容易性': '高い -- InMemoryで独立テスト可能',
  'パフォーマンス': '中程度 -- 変換層のオーバーヘッド',
  'シンプルさ': '低い -- 学習コストがかかる',
};

品質特性の測定

変更容易性の測定

// 変更容易性を測る指標
interface ChangeabilityMetrics {
  // 変更影響範囲: 1つの機能変更で触るファイル数
  averageFilesPerChange: number; // 目標: 5ファイル以下

  // 依存の方向: 内側→外側の依存がないか
  inwardDependencyViolations: number; // 目標: 0

  // 循環依存: モジュール間の循環参照
  circularDependencies: number; // 目標: 0
}

テスト容易性の測定

// テスト容易性を測る指標
interface TestabilityMetrics {
  // DB接続なしで実行可能なテストの割合
  unitTestRatio: number; // 目標: 80%以上

  // テスト実行時間
  unitTestDuration: number; // 目標: 30秒以内

  // ビジネスロジックのカバレッジ
  domainCoverage: number; // 目標: 90%以上
}

品質特性シナリオ

品質特性を具体的に定義するために「シナリオ」を使います。

シナリオテンプレート:
「[刺激元]が[刺激]を発生させたとき、
 [環境]において、[アーティファクト]は
 [応答]を[応答測定]以内に行う」

例1: 変更容易性
「開発者が新しい決済手段を追加するとき、
 通常運用中に、決済Adapterを
 2日以内に実装・テスト完了できる」

例2: パフォーマンス
「1000人の同時ユーザーが注文を作成するとき、
 通常負荷時に、注文APIは
 200ms以内にレスポンスを返す」

例3: 可用性
「データベースサーバーが障害を起こしたとき、
 通常運用中に、システムは
 5分以内にフェイルオーバーして復旧する」

品質特性の優先順位付け

全ての品質特性を最大化することはできません。プロジェクトの性質に応じて優先順位を付けます。

ECサイトの場合:
1. 可用性（ダウンタイム = 売上損失）
2. パフォーマンス（遅いとカート離脱率が上がる）
3. セキュリティ（決済情報の保護）
4. 変更容易性（新機能の迅速な追加）
5. テスト容易性（品質の担保）

社内管理ツールの場合:
1. 変更容易性（頻繁な要件変更）
2. テスト容易性（正確性の担保）
3. デプロイ容易性（素早いリリース）
4. パフォーマンス（そこまで重要でない）
5. 可用性（業務時間内のみ）

まとめ

チェックリスト

• 8つの品質特性を説明できる
• パターンと品質特性の関係を理解した
• 品質特性シナリオを書ける
• プロジェクトに応じた優先順位付けができる

次のステップへ

次は「アーキテクチャフィットネス関数」を学びます。品質特性を自動的に監視・検証する仕組みを身につけましょう。

推定読了時間: 30分