品質属性シナリオの策定 - L0 カリキュラム

ストーリー

佐

佐藤CTO

ステークホルダー分析で品質属性の優先順位が見えた。次はそれを検証可能なシナリオに変換するフェーズだ

佐

佐藤CTO

99.99% 可用性

佐

佐藤CTO

“可用性99.99%“だけでは、何を測るのか、いつの話なのか、どの部分の話なのかが曖昧だ。決済APIの可用性なのか、管理画面の可用性なのか。通常時なのか、障害時なのか。これを6つの要素で構造化するのが品質属性シナリオだ

あなた

NexPayの場合、特にどの品質属性が難しいですか？

あ

佐

佐藤CTO

すべてが同時に求められることが難しい。暗号化すればレイテンシが増える。冗長化すればコストが増える。サービスを分割すればトランザクション整合性が複雑になる。個別の品質属性は学んできたはずだ。ここでは複数の品質属性を同時に満たすシナリオ設計を学ぶ

品質属性シナリオの構造

6要素の復習

品質属性シナリオは以下の6要素で構成されます。

要素	説明	例
刺激源（Source）	刺激を発生させる主体	エンドユーザー、外部システム、攻撃者
刺激（Stimulus）	品質属性に影響する事象	リクエスト、障害、攻撃、負荷急増
環境（Environment）	シナリオが発生する状況	通常運用時、ピーク時、障害復旧中
成果物（Artifact）	影響を受けるシステム要素	決済API、投資サービス、DB
応答（Response）	システムの反応	処理継続、フェイルオーバー、エラー通知
測定値（Measure）	応答の定量的基準	レスポンス < 500ms、可用性 > 99.99%

可用性シナリオ

QA-AV-001: 決済基盤の高可用性

シナリオID: QA-AV-001
品質属性: 可用性
優先度: MUST

刺激源: AWSアベイラビリティゾーン
刺激: 1つのAZが完全に利用不可になる
環境: 通常運用時（平日日中のピーク帯）
成果物: 決済処理システム全体
応答: 残存AZで決済処理を継続。処理中のトランザクションはリトライされる
測定値:
  - フェイルオーバー完了: 30秒以内
  - 処理中トランザクションの損失: 0件
  - 年間可用性: 99.99%以上

QA-AV-002: データベース障害時の継続性

シナリオID: QA-AV-002
品質属性: 可用性
優先度: MUST

刺激源: データベースサーバー
刺激: プライマリDBがハードウェア障害でダウンする
環境: 決済ピーク時（昼12時台、20,000 TPS）
成果物: 決済データベースクラスタ
応答: 自動フェイルオーバーでスタンバイDBにwriteが切り替わる
測定値:
  - フェイルオーバー時間: 15秒以内
  - データ損失: 0（同期レプリケーション）
  - フェイルオーバー中の決済エラー率: 0.1%未満

QA-AV-003: 投資サービスの部分障害

シナリオID: QA-AV-003
品質属性: 可用性
優先度: SHOULD

刺激源: 外部証券API
刺激: 証券会社のAPIが5分間応答しなくなる
環境: マーケット開場直後（9:00-9:30）
成果物: 投資サービス
応答: サーキットブレーカーが発動し、投資機能をグレースフルデグラデーション。
      決済・送金機能は影響を受けない。
測定値:
  - 障害検知: 10秒以内
  - 決済・送金への影響: 0%
  - 投資サービス復旧: 外部API復旧後30秒以内

「可用性で重要なのは障害分離だ。投資サービスが落ちても決済は止まらない。これはサービス分割の最大の動機の1つだ」 — 佐藤CTO

セキュリティシナリオ

QA-SE-001: カード情報の保護

シナリオID: QA-SE-001
品質属性: セキュリティ
優先度: MUST

刺激源: 攻撃者（外部）
刺激: SQLインジェクション攻撃で決済データベースへのアクセスを試みる
環境: 通常運用時
成果物: 決済API、カードデータストア
応答: WAFとアプリケーション層のバリデーションで攻撃を遮断。
      カード番号はトークン化されており、DBに平文では保存されていない。
測定値:
  - 攻撃検知: リアルタイム
  - カード番号の漏洩: 0件（トークン化により平文が存在しない）
  - 攻撃元IPの自動ブロック: 30秒以内

QA-SE-002: 内部者による不正アクセス

シナリオID: QA-SE-002
品質属性: セキュリティ
優先度: MUST

刺激源: 社内開発者（内部脅威）
刺激: 本番環境のユーザーデータに権限外のアクセスを試みる
環境: 開発作業中
成果物: 本番データベース、管理API
応答: IAMポリシーによりアクセス拒否。試行は監査ログに記録され、
      セキュリティチームにアラート通知。
測定値:
  - 不正アクセスのブロック: 100%
  - 監査ログの記録: リアルタイム
  - アラート通知: 1分以内
  - ログの改ざん不可能性: 保証（WORM storage）

QA-SE-003: AML（マネーロンダリング対策）

シナリオID: QA-SE-003
品質属性: セキュリティ
優先度: MUST

刺激源: 不正利用者
刺激: 短時間に多数の少額送金を行い、マネーロンダリングを試みる
環境: 通常運用時
成果物: 送金サービス、AMLモニタリングシステム
応答: 不正検知エンジンが異常パターンを検出し、送金を保留。
      コンプライアンス担当者に審査を依頼。
測定値:
  - パターン検知: リアルタイム（ストリーム処理）
  - 疑わしい取引の自動保留: 500ms以内
  - 誤検知率（False Positive）: 5%未満

パフォーマンスシナリオ

QA-PE-001: 決済処理のレイテンシ

シナリオID: QA-PE-001
品質属性: パフォーマンス
優先度: MUST

刺激源: エンドユーザー（店舗でQR決済）
刺激: QRコード読み取りによる決済リクエスト
環境: 通常運用時（5,000 TPS）
成果物: 決済API（認証→与信→売上確定）
応答: 決済処理を完了し、成功/失敗を返す
測定値:
  - p50: 200ms以下
  - p95: 400ms以下
  - p99: 800ms以下
  - エラー率: 0.01%未満

QA-PE-002: ピーク時のスループット

シナリオID: QA-PE-002
品質属性: パフォーマンス + スケーラビリティ
優先度: MUST

刺激源: 大規模キャンペーン
刺激: 通常の3倍のトラフィックが突発的に発生
環境: キャンペーン開始直後
成果物: 決済API、残高照会API
応答: オートスケーリングにより処理能力を拡張し、
      レイテンシSLAを維持しながら全リクエストを処理
測定値:
  - スケールアウト開始: トラフィック増加検知後60秒以内
  - スケールアウト完了: 5分以内
  - SLA違反率: 0.1%未満
  - ピーク時TPS: 10,000以上

QA-PE-003: 残高照会の高速応答

シナリオID: QA-PE-003
品質属性: パフォーマンス
優先度: MUST

刺激源: エンドユーザー（アプリ起動）
刺激: アプリ起動時の残高・取引履歴の表示リクエスト
環境: 通常運用時（50,000 RPS）
成果物: アカウントサービス（残高照会API）
応答: キャッシュ層から残高と直近10件の取引履歴を返す
測定値:
  - p50: 50ms以下
  - p95: 150ms以下
  - p99: 300ms以下
  - キャッシュヒット率: 95%以上

スケーラビリティシナリオ

QA-SC-001: ユーザー数の成長

シナリオID: QA-SC-001
品質属性: スケーラビリティ
優先度: MUST

刺激源: 事業成長
刺激: ユーザー数が300万から1,000万に増加（2年間）
環境: 段階的な成長
成果物: システム全体
応答: インフラの水平スケーリングにより、
      パフォーマンスSLAを維持しながら処理能力を拡張
測定値:
  - レイテンシ劣化: 10%未満
  - インフラコスト増加: ユーザー数増加比の70%以下（スケール効率）
  - アーキテクチャ変更: 不要（設定変更のみ）

QA-SC-002: データ量の増大

シナリオID: QA-SC-002
品質属性: スケーラビリティ
優先度: SHOULD

刺激源: 取引量の増加
刺激: 取引データが月間10億件に達する
環境: 2年目以降の通常運用
成果物: 取引データストア、分析基盤
応答: パーティショニングとアーカイブ戦略により、
      クエリ性能を維持しながらデータを管理
測定値:
  - 取引照会レスポンス: p95 < 200ms維持
  - ストレージコスト: ホットデータ比率30%以下
  - データ保持期間: 7年（法定保存期間）

シナリオ間のトレードオフマップ

品質属性シナリオ間には、トレードオフの関係があります。

graph TD
    SEC["セキュリティ
QA-SE-001
暗号化・トークン化"]
    PERF["パフォーマンス
QA-PE-001
低レイテンシ"]
    AVAIL["可用性
QA-AV-001
マルチAZ冗長化"]
    COST["コスト効率
CON-005
予算3億円"]
    SCALE["スケーラビリティ
QA-SC-001
サービス分割"]
    MAINT["保守性
QA-MT-001
独立開発・デプロイ"]
    SEC -- "競合" --- PERF
    SEC -- "補強" --- AVAIL
    PERF -- "競合" --- COST
    AVAIL -- "競合" --- COST
    AVAIL -- "補強" --- SCALE
    COST -- "補強" --- MAINT
    SCALE -- "補強" --- MAINT
    style SEC fill:#fee2e2,stroke:#dc2626,color:#991b1b
    style PERF fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
    style AVAIL fill:#d1fae5,stroke:#059669,color:#065f46
    style COST fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#92400e
    style SCALE fill:#f3e8ff,stroke:#7c3aed,color:#5b21b6
    style MAINT fill:#f3f4f6,stroke:#9ca3af,color:#374151

トレードオフの解決方針

トレードオフ	解決方針
セキュリティ vs パフォーマンス	カード情報のトークン化で暗号化/復号の頻度を最小化。HSM（Hardware Security Module）で暗号化処理を高速化
可用性 vs コスト	ティアード可用性: 決済は99.99%、管理画面は99.9%。全機能を同等に冗長化しない
一貫性 vs 可用性	決済は強整合性（同期）、履歴照会は結果整合性（非同期）。ユースケースごとに使い分け
スケーラビリティ vs 複雑性	サービス分割は事業ドメイン単位に限定（過度な分割を避ける）。データの結合ポイントを最小化

「すべてのシナリオを満たす”銀の弾丸”はない。大事なのは、どこで妥協するかを意識的に選ぶことだ。フィンテックでは”セキュリティでの妥協は許されない”が、パフォーマンスの目標は交渉可能だ。p99を800msから1000msに緩和することで、セキュリティ強化の余地が生まれることもある」 — 佐藤CTO

まとめ

ポイント	内容
品質属性シナリオ	6要素で構造化し、定量的に検証可能にする
可用性	決済基盤99.99%、障害分離でサービスごとに独立
セキュリティ	トークン化、ゼロトラスト、AMLリアルタイム検知
パフォーマンス	決済p99 < 800ms、残高照会p99 < 300ms
トレードオフ	セキュリティvsパフォーマンス、可用性vsコストの解決方針を明示

チェックリスト

品質属性シナリオの6要素を使って定量的に記述できた
可用性・セキュリティ・パフォーマンス・スケーラビリティの主要シナリオを理解した
シナリオ間のトレードオフ関係を把握した
トレードオフの解決方針を理解した

次のステップへ

次は「規制制約と技術制約」に進みます。NexPayプロジェクト特有のPCI DSS、資金決済法などの規制制約と、既存システムやチーム構成から生じる技術制約を詳しく分析しましょう。

推定読了時間: 30分