ASR分析
ブリーフは仕様ではありません。願望、仮定、中途半端に述べられた制約の山であり、その中にはシステムの形状とコストを実際に決定する、ごく少数の要件が埋もれています。このスキルはそれらの要件を見つけ出し、正確にし、誰かが見積もりや設計にコミットする前に相互にチェックします。
アーキテクチャ上重要な要件（ASR） とは、アーキテクチャに測定可能な影響を与える要件のことです。それを満たすことで構造上の選択を強いられ、技術を制約し、達成が難しい品質基準を設定し、または他の要件と相互作用して選択肢を制限します。ブリーフ内のほとんどの要件はアーキテクチャ上重要 ではありません。仕事は、重要なものとそうでないものを分け、それぞれがなぜ重要であるかを示すことです。
この作業の品質属性面は、国際標準の製品品質モデルである ISO/IEC 25010 に基づいています。標準化された品質特性を使用することで、分析が完全になり（毎回同じ側面をチェックする）、全員が共有の用語を使用できます。references/quality-model.md を参照してください。
パイプライン
ブリーフを6つのステップで実行します。各ステップは、次のステップで使用される成果物を生成します。
-
抽出、書き写しではない。 生の入力を読み、実際の要件を引き出します。これには、機能、苦情、何気ない発言として述べられたものも含まれます。「当社のブラックフライデーのトラフィックは通常の40倍です」という文は機能要求ではありません。それは、パフォーマンスとスケーラビリティの要件が偽装されたものです。解釈してください。何がアーキテクチャ上重要かを認識する方法については、
references/asr-framework.mdを参照してください。 -
分類。 抽出された各要件を3つのバケットのいずれかに分類します。
- 機能 — システムが 行う こと
- 品質属性 — どの程度うまく実行するか（パフォーマンス、信頼性、セキュリティ、保守性…）。毎回同じ範囲をカバーするためにISO/IEC 25010特性を使用します —
references/quality-model.md - 制約 — 固定され、交渉の余地のない境界（義務付けられた技術、規制、期限、既存システム）。制約は設計の対象ではなく、他のすべてを形成します。
-
シャープ化。 各重要な要件を、曖昧さがなくテスト可能になるように書き直し、その アーキテクチャ上の含意 — それを真剣に受け止めた場合の構造上の結果 — を述べます。作成者がこっそり入れた解決策を剥ぎ取ります（「Kafkaを使う」は提案されたメカニズムであり、要件ではありません。要件はその背後にあるスループットまたは疎結合です）。テストできない要件は見積もることができません。
-
2軸で優先順位付け。 すべてのASRが等しく注目に値するわけではありません。各ASRを以下の基準でランク付けします。
- ビジネス価値 — 結果がクライアントにとってどの程度重要か。
- アーキテクチャへの影響 — 設計をどの程度制約し、元に戻すのにどの程度のコストがかかるか。（高い影響は 不可逆性と影響範囲 に関するものであり、労力ではありません。）
両方で高い要件こそが、アーキテクチャが実際に決定される場所です。そこに分析の時間を費やしてください。
references/scenarios-and-priorities.mdを参照してください。
-
実現可能性をチェック。 何かを設計する前に、優先度の高い要件が 共存できる ことを確認します。最も危険なブリーフは内部に矛盾を含んでいます。レイテンシ目標、一貫性目標、コスト上限のすべてが同時に真になり得ないものです。数値要件の算術計算を含む具体的な方法については、
references/feasibility-check.mdを参照してください。 -
シナリオを指定し、戦略を選択。 優先度の高い品質属性について、測定可能な品質シナリオ（トリガー、条件、測定可能なレスポンス）を作成し、次にそれぞれを満たす 設計戦略 をコストとともに選択します。
references/scenarios-and-priorities.mdおよびreferences/design-strategies.mdを参照してください。
分析を信頼できるものにする規律
- 臭いを見つけろ。 ブリーフには繰り返し現れる失敗パターンがあります。漠然とした最上級表現、隠された仮定、単位や出典のない数字、矛盾する要件などです。
references/brief-smells.mdはそれらのカタログであり、それを見つけたときに何を問いかけるべきかを示しています。 - すべての仮定に印を付ける。 ブリーフに情報がなく、あなたがギャップを埋めた場合、それにラベルを付けます。それは 埋められたギャップ（情報が不足しており、デフォルト値を提供した）ですか、解釈（曖昧で、ある読み方を選択した）ですか、それとも スコープの狭小化（意図的に何かを除外した）ですか？ラベルのない仮定に基づいた見積もりは、スーツを着た推測にすぎません。
- 形状を変える質問で締めくくる。 優れた分析の出力には、その答えがアーキテクチャを最も変えるであろう2〜3の質問が含まれます。それが次のクライアントとの会話の内容であるべきです。
- 見積もりは、その下にある分析と同じだけ防御可能である。 これが分析が最初に行われる理由です。つまり、クライアントに提示する数字を、あなたが自信を持って支えられるものにするのです。
このスキルの使い方
- ブリーフを最初から最後まで分析する → 上記の6ステップパイプラインを実行します。
- 何がアーキテクチャ上重要かを判断する →
references/asr-framework.md - 品質属性を選択しカバーする →
references/quality-model.md（ISO/IEC 25010） - テスト可能な品質シナリオを作成し優先順位付けする →
references/scenarios-and-priorities.md - 品質属性ごとに設計アプローチを選択する →
references/design-strategies.md - 矛盾や不可能な組み合わせを見つける →
references/feasibility-check.md - ブリーフを批判的に読む →
references/brief-smells.md - 成果物の文書を整形する →
references/output-template.md