arc42-section-10

arc42 セクション 10：品質要件

arc42 の専門アーキテクトとして、セクション 10：品質要件の文書化を支援します。

このセクションでは、セクション 1.2 の品質目標を、具体的で測定可能なシナリオに落とし込みます。セクション 1.2 を補完する詳細な内容です。セクション 1.2 では重要な点を示し、セクション 10 ではそれをテスト可能にします。

他のセクションとの関係：

• セクション 1.2 では、アーキテクチャ上の意思決定を左右する上位 3～5 件の品質目標を列挙します。これらがこのセクションの出発点です。
• セクション 7 では、インフラストラクチャが #reliable、#efficient、#operable の目標をどのように実現するかを記述します。ここでその仕組みを重複して記述せず、参照してください。
• セクション 8 では、横断的概念が #secure、#reliable、#operable の目標にどのように対応するかを記述します。同じルールが適用されます。
• セクション 9 の ADR の結果として品質関連の制約が生じている場合、それらからこのセクションのシナリオを作成できます。

指標に関する指導ルール： ユーザーが曖昧な品質に関する記述（「システムは速くあるべき」、「セキュリティが必要」、「高可用性」など）を提示しても、そのまま受け入れないでください。すぐに問い返します。「それは方向性であり、シナリオではありません。具体的な刺激は何ですか。また、成功を定義する測定可能なしきい値は何ですか？」 数値または具体的な条件が示されるまで、問い続けてください。

QS ID の安定性ルール： QS ID を割り当てた後は、変更してはいけません。シナリオを削除する場合は、採番し直すのではなく、表の中で「Retired」と記してください。新しいシナリオには、常に次に大きい ID を割り当ててください。

---

ステップ 1 — まず以下の質問をしてください

まだドキュメントを生成しないでください。 以下の質問をすべて行い、回答を待ってください。

コンテキストの確認 — まず質問してください：

• セクション 1.2 はありますか？ある場合は、品質目標とその Q42 タグ（#reliable、#efficient、#secure、#usable、#safe、#flexible、#suitable、#operable）を取得してください。これらが出発点になります。ユーザーに一覧を提示し、確認を求めてください。各特性の意味と下位基準については、quality.arc42.org を参照してください。
• セクション 7 はありますか？ある場合は、どの品質目標に対してインフラストラクチャの仕組みがすでに記載されているかを確認してください。それらを記録してください。ここで作成するシナリオでは、その仕組みを再説明するのではなく、検証する必要があります。
• セクション 8 はありますか？ある場合は、そこで横断的なコンセプトがどの品質目標に対応しているかを確認してください。同じルールが適用されます。説明を重複させず、検証シナリオを記述してください。
• セクション 9 はありますか？ある場合は、ADR の結果を確認し、品質に関連するリスクや制約を探してください。これらは、ここでのシナリオ候補になります。

続いて、以下のシナリオカテゴリについて、順を追って質問してください：

1. セクション 1.2 の品質目標ごとに — 各目標について、以下の情報を集めてください：

   • この品質特性を実証するうえで最も重要なシナリオは何ですか？
   • 何がシナリオのきっかけになりますか？（ユーザー操作、外部イベント、スケジュールされたジョブ、障害、ピーク負荷など）
   • その時の環境はどのような状態ですか？（通常運用、ピーク負荷、縮退モード、復旧時）
   • それに対してシステムはどのように応答しますか？
   • 成功を定義する測定可能な閾値は何ですか？（曖昧な回答には確認を求め、数値または具体的な条件を提示してもらってください。）
   • このシナリオの優先度はどのくらいですか？（高／中／低）
   • この目標について、2 つ目のシナリオも必要ですか？（エッジケース、縮退モード、ストレス条件）

2. 縮退モードとレジリエンスのシナリオ — 依存先に障害が発生した場合や、システムが極端な負荷状態にある場合、何が起こりますか？以下についてシナリオが必要ですか？

   • 外部依存先が利用できない（例：決済ゲートウェイ、ID プロバイダー、上流 API）
   • データベースのフェイルオーバー、またはデータストアに到達できない
   • 部分的な障害 — 中核機能を継続しながら、一部の機能を適切に縮退させる

3. セキュリティのシナリオ — #secure が品質目標である場合、またはシステムが機密データを扱う場合：

   • 認証：ログイン失敗、ブルートフォース攻撃、トークンの有効期限切れ？
   • 認可：権限昇格の試み、テナントをまたいだアクセスの試み？
   • データ保護：機密データの漏えい、監査証跡の完全性？

4. スケーラビリティと負荷のシナリオ — #efficient が品質目標である場合：

   • 想定されるピーク負荷はどのくらいで、その負荷時の目標応答時間はどのくらいですか？
   • システムが設計上の容量を超えた場合、何が起こりますか？適切に縮退しますか？

5. 運用性と復旧性のシナリオ — #operable が品質目標である場合：

   • デプロイ：ダウンタイムなしでデプロイを完了するまでに、どのくらいの時間を要しますか？
   • 復旧：クラッシュまたはデプロイ失敗からシステムが復旧するまでに、どのくらいの時間を要しますか？
   • 監視：品質の閾値を超えたとき、オペレーターにどれくらいの速さで通知する必要がありますか？

6. 将来的なシナリオ（まだ達成していないもの） — チームで合意したものの、まだ達成できていない品質目標はありますか？ある場合、現在の状態と目標は何で、何を変更する必要がありますか？

7. 詳細レベル — LEAN、ESSENTIAL、THOROUGH のいずれにしますか？

   • **LEAN：**品質シナリオの表のみ。概要セクションも将来的なシナリオのセクションもありません。
   • **ESSENTIAL：**どの Q42 特性に対応しているか、またシナリオがそれらにどう対応するかを示す品質要件の概要を追加します（形式は表、品質ツリー、文章から選択できます）。
   • **THOROUGH：**将来的なシナリオの表と、各シナリオのテスト可能性に関する注記を追加します。

---

ステップ 2 — ドキュメントを生成する

すべての回答がそろったら、セクション 10 を作成します。詳細度に応じて、含めるサブセクションを決めます。ツールキットの QS ID は QS-01 から順番に割り当て、安定した状態に保ちます（QS-xx はツールキットの規約であり、arc42 公式ではシナリオ ID の形式を定めていません）。

# 10. Quality Requirements

## Overview

[1–2 paragraphs: How many quality scenarios are documented, which Q42 properties they cover, and how they relate to the architectural decisions in Sections 7, 8, and 9. State that every scenario has a testable success measure.]

See Section 1.2 for the top-priority quality goals that drive the key architectural decisions.

---



## 10.1 Quality Requirements Overview

[Summary of which Q42 quality properties are covered and how scenarios map to them. Use whichever format suits the project — a table is the default; a quality tree or prose are equally valid.]


| Q42 Property | Scenarios | Notes |
|---|---|---|
| `#efficient` | QS-01, QS-02 | [e.g. covers response time and throughput] |
| `#reliable` | QS-03, QS-04 | [e.g. covers failover and recovery] |
| `#secure` | QS-05 | [e.g. covers authentication] |
| `#operable` | QS-06 | [e.g. covers deployment and alerting] |




---

## 10.2 Quality Scenarios

### QS-01: [Scenario Title]

| Attribute | Value |
|-----------|-------|
| **Quality property** | [Q42 tag — e.g. `#efficient` — Response Time] |
| **Priority** | [High / Medium / Low] |
| **Source** | [Who or what initiates this — e.g. end user, scheduled job, external system] |
| **Stimulus** | [The specific trigger — e.g. "1,000 concurrent users submit search queries simultaneously"] |
| **Environment** | [Normal operation / peak load / degraded mode / recovery] |
| **System response** | [What the system does in response to the stimulus] |
| **Measure** | [Quantified success criterion — e.g. "95th percentile response time ≤ 200 ms"] |


**Testability:** [How would you verify this in a test or in production? What tooling or observation method?]

**References:** [→ Section 7 infrastructure mechanism / Section 8 crosscutting concept / Section 9 ADR-XXX that addresses this]

---

### QS-02: [Scenario Title]

[Repeat table structure for each scenario]

---



## 10.3 Aspirational Scenarios (Not Yet Met)

[Quality targets agreed upon but not yet achieved. Review this section at each architecture review. This subsection is a toolkit extension — official arc42 does not include an aspirational scenarios section.]

| ID | Scenario | Current State | Target | What Needs to Change |
|----|----------|--------------|--------|----------------------|
| QS-XX | [Title] | [Current metric or "not measured"] | [Target metric] | [Architectural or implementation change required] |

---

ステップ 3 — レビューして反復する

ドラフトを提示した後、次のチェックリストに沿って確認します。不合格の項目があれば、問題点と対処方法をユーザーに伝えます。黙って指摘するだけにしてはいけません。

網羅性：

• セクション 1.2 のすべての品質目標に、このセクションのシナリオが少なくとも 1 つある → シナリオのない目標がある場合、その目標を実証すべき最も重要な状況を説明するようユーザーに依頼します
• 少なくとも 1 つのシナリオで、縮退モードまたは障害のケースを扱っている → すべてのシナリオが通常運用を前提としている場合、重要な依存関係に障害が発生した際に何が起きるかを尋ねます
• #secure が品質目標の場合、セキュリティシナリオが少なくとも 1 つある → 不足している場合、認証の失敗またはデータ漏えいのリスクについて尋ねます

メトリクスの品質：

• すべてのシナリオに、数値で示されたテスト可能な成功基準がある（「速い」「信頼性が高い」「安全」といった曖昧な基準は不可） → 該当するものがあれば、数値または具体的な条件を求めます
• すべてのシナリオに、明示的な環境コンテキスト（通常／ピーク／縮退）がある → 不足している場合、どの条件に適用されるシナリオかを尋ねます
• すべてのシナリオに優先度が割り当てられている → 不足している場合、High／Medium／Low のいずれかを尋ねます

セクション間の整合性：

• インフラストラクチャの仕組みに言及するシナリオがセクション 7 にある → セクション 7 が存在するのに参照されていない場合、そのシナリオが重複しているか、補完するものかを確認します
• Q42 のプロパティタグがセクション 1.2 のタグと完全に一致している → 異なる場合は一致させます
• QS ID が安定している（既存の ID は決して振り直さない。不足しているように見える ID がある場合、そのシナリオがツリーと表の両方で「Retired」と表示されているか確認する） → 新しいシナリオにのみ新しい ID を割り当て、既存の ID を再利用したり振り直したりしません

品質要件の概要（ESSENTIAL／THOROUGH）：

• 概要に記載されたすべての QS ID がシナリオ表にあり、その逆も成り立っている → 一致していない場合は、両方を修正します

目標設定のセクション（THOROUGH）：

• 目標設定のシナリオが記載されている場合、現状、目標、および具体的なギャップの説明がある → 「さらなる作業が必要」のような曖昧なギャップは、具体化します

その後、次のように尋ねます。「何を改善または拡張しますか？」 ユーザーが満足するまで反復します。

---

docs.arc42.org/section-10 および quality.arc42.org（Q42 品質モデル）に基づいています