## 品質チェック：なぜこのルールで「十分に」検査できるのか

`/vspec:qc` の検査ルールは `quality_standard.md` に基づきます。特定業界のテンプレートではなく、「高品質な要件が必ず答えるべき問い」を実行可能なチェックリストとして固定化したものです。

### 0）品質基準と落とし込み方（9 つの次元）

品質チェックは主観評価ではなく、品質を“検査できる次元”に分解し、各次元ごとに「欠陥分類 → チェック観点 → 特定方法 → 修正方針 → 受入方法」を定義します。

- 完全性：必要な対象と分岐を漏れなく覆えているか
  - 典型的な欠陥分類：ロール漏れ、シナリオ漏れ、状態漏れ、例外/補償漏れ、制約漏れ、成果物漏れ（フィールド/ログ/監査/レポート）
  - チェック方法：先にカバレッジ清単（ロール×操作×データ範囲×シナリオ分岐×状態変化）を作り、仕様が各項目を明確に定義しているかを突合する
  - 修正：漏れ項目を追加し、シナリオと受入ケースに紐付ける（検証できない散文追加で終わらせない）
- 正しさ：事実/規則に沿い、論理が自己矛盾しないか
  - 欠陥：規則の矛盾、到達不能/終了不能の状態機械、契約/現行ルールとの衝突
  - チェック：反例の推論、正の根拠（決裁者/根拠）との突合、境界条件の演算
  - 修正：権威口径（誰が決めるか）を明確化し、規則と例で一貫させる
- 精密さ：口径が測定可能で実装に落ちるか
  - 欠陥：時間口径（TZ/営業日）が不明、上下限がない、丸め/精度がない、デフォルトが不明
  - チェック：主要フィールド/指標に「定義 + 単位 + 精度 + 範囲 + デフォルト + 例」を要求
  - 修正：フィールド表/規則表に固定し、境界値を受入で検証する
- 柔軟性：変更に追従できるか（スコープ/ルール/ポリシーの変更）
  - 欠陥：変更境界と方針が不明、フローにルールが埋め込まれている、バージョン化口径がない、安全なロールアウト/ロールバックがない
  - チェック：可変点/不変点（何が設定で変えられるか、何がリリース必須か）、影響面（状態/データ/権限/依存）、検証とロールバック戦略を明示する
  - 修正：可変点を規則表/設定/ポリシーへ抽出し、移行・互換案を追加し、変更シナリオを受入と演習に入れる
- 再利用性：一回限りの文章ではなく、モデルとして再利用できるか
  - 欠陥：ルールが散在、用語ゆれ、再利用モデル不足（RBAC/データ権限/リソースカレンダー/イベント）
  - チェック：用語表、規則表、権限点、イベント schema を抽出し、シナリオから参照できる状態にする
  - 修正：共通部分を定義へ集約し、シナリオは差分のみを書く
- 読みやすさ：読者が素早く理解・検索できるか
  - 欠陥：構造が悪い、図表がない、重要定義が段落に埋もれる
  - チェック：結論先出し、主要対象は表、モジュールごとに入口図と成果物リスト
  - 修正：構成を整理し、要点と表を補う
- 一貫性：同じ概念/フィールド/フローが文書全体で整合しているか
  - 欠陥：同名異義、同義異名、図・本文・API・テストの不一致
  - チェック：用語表/フィールド表を単一の真実として維持し、各成果物を突合
  - 修正：命名と定義を統一し、変更は用語/フィールド/状態のレベルで管理する
- 実装可能性：工学的に実現でき、合理的なコストで作れるか
  - 欠陥：依存境界が不明、失敗戦略がない、冪等/並行の口径がない、運用/可観測がない
  - チェック：重要経路は依存清単 + 失敗マトリクス + 状態機械 + データフローで検査し、降格/ロールバック/補償を必須化
  - 修正：境界と戦略を補い、必要ならスコープ調整やマイルストーン分割で最小閉ループを作る
- テスト可能性：「それっぽい」ではなく受入/自動化で検証できるか
  - 欠陥：観測可能な出力がない、シナリオが列挙できない、受入基準が主観的
  - チェック：主要ルールは必ず実行可能な受入ケースに対応させ、例外経路は観測証跡を要求
  - 修正：Given/When/Then の用例と断言に落とし、テストデータと権限/データ範囲の前提条件を補う

補足：完全性は正面から「全てを網羅した」と証明しづらい一方で、上記の欠陥分類（ロール/シナリオ/状態/例外/制約/成果物）に分解してカバレッジ清単で突合すれば、実行可能で効果的な品質検査計画にできます。

### 1）業界に依存しない：見るのは“構造”と“検証可能性”

チェックは業務用語そのものではなく、要件が実装・テスト可能な構造を持つかを確認します。たとえば：

- 目的と範囲：目的/非目的、意思決定すべき境界が明確か
- 役割と権限：誰が何をできるか、誰が何を見られるか（アクセス権限とデータ権限）
- 状態と制約：状態遷移、前提条件、制約、例外と補償が閉ループになっているか
- 口径の整合性：時間口径、上下限、精度、フィールド定義が一貫し追跡可能か
- 受入とテスト可能性：シナリオが列挙でき、主要分岐と主要制約を受入で検証できるか
- リスクと依存：失敗戦略、リトライ、冪等、ロールバック、監査、アラートが明示されているか

これらは業界に関係なく、ソフトウェア要件で必ず必要になります。

### 2）なぜ「十分」なのか：典型的な失敗モードを潰す

「十分」とは全ての業務詳細を網羅することではありません。手戻り・事故・受入争いを生みやすい高頻度の欠落を、要件段階で体系的に露出させることです。例：

- 主経路だけで取消/却下/撤回/補償がなく、運用できない
- 権限が一文だけで、権限点やデータ範囲がなく越権や口径揺れが起きる
- 時間/精度/上下限の口径がなく、実装がバラつき受入で揉める
- 外部依存の失敗戦略がなく、復旧不能・追責不能になる

### 3）千锤百炼：反復改善で磨かれたチェックリスト

このルールは一度で完成したものではなく、要件レビュー、実装の齟齬、受入争い、障害の振り返りから反復的に改善されています。各ルールは実際に起きた欠陥クラスに対応し、「チェックできる／位置を特定できる／修正提案が出せる」形に落とし込まれています。

### 4）方法論が先、プロンプトは後

重要なのは「先に方法論で次元を固定し、後からプロンプトで出力を整える」ことです。抽象化や thinking modes（境界、対称、制約、多様性）で問題空間を固定した上でプロンプトを設計すると、出力の網羅性と再現性が安定します。方法論の支えがない場当たり的な分析では、同等の効果を安定して得にくくなります。
