requirements-reviewer

name	requirements-reviewer
description	要求定義書のレビューを行うスキル。品質チェック・矛盾検出・抜け漏れ検出・曖昧性分析を実施し、 構造化レポートを出力する。以下の場合に使用: (1) 要求定義書・要件定義書をレビューしたい時、 (2) 要求の品質や完全性を確認したい時、 (3) 矛盾・抜け漏れ・曖昧な表現を検出したい時
disable-model-invocation	true

要求定義書レビュースキル

このスキルは、形式を問わず要求定義書を受け取り、8つの品質観点で体系的にレビューして構造化レポートを出力します。実装や設計の判断は行いません。

このスキルのスコープ

含まれるもの

• ✅ 要求定義書の品質レビュー（8観点）
• ✅ 曖昧な表現・矛盾・抜け漏れの検出
• ✅ 構造化レポートの生成（問題一覧・重大度・改善提案）
• ✅ spec 進行可否の判断材料の提示

含まれないもの

• ❌ 要求定義書の新規作成（上流スキル rdd が担当）
• ❌ 仕様書の作成（下流スキル spec が担当）
• ❌ 実装の判断・設計
• ❌ 要求の自動修正（改善提案のみ）

パイプライン上の位置: rdd（要件定義）→ requirements-reviewer（レビュー）→ spec（仕様作成）

---

対応入力形式

このスキルは以下の任意の形式の入力を受け付けます:

形式	対応方法
EARS記法	各パターン（WHEN/WHILE/WHERE/IF...THEN/Ubiquitous）に対してパターン固有のチェックも実施
自然言語	文章から要求を抽出し、曖昧性・検証可能性を重点チェック
箇条書き	各項目を個別要求として扱い、粒度・一貫性を確認
表形式	列の意味を解釈し、抜け漏れカラムを指摘
混在形式	形式ごとに適切な手法を適用し、形式間の一貫性も確認

入力形式が不明確な場合は、Phase 1 でユーザーに確認します。

---

レビュー観点（概要）

8つの観点で体系的にレビューします。詳細チェックリストは references/review-checklist.md を参照してください。

#	観点	概要	優先度
1	曖昧性の検出	解釈が複数生じる表現・暗黙の仮定を特定	高
2	一貫性	要求間の矛盾・用語の不統一を検出	高
3	完全性	異常系・エッジケース・前提条件の抜け漏れを確認	高
4	テスト可能性	各要求が検証・テスト可能かを確認	高
5	トレーサビリティ	要求が目的・価値に結びついているかを確認	中
6	粒度	1要求1責務の原則、粗すぎ・細かすぎを検出	中
7	過剰仕様回避	実装詳細・不要な制約の混入を検出	中
8	非機能要求の分離	機能要求と非機能要求の混在を検出	低

---

実行フロー

Phase 1: 入力理解・スコープ確認

ユーザーへの確認（必要に応じて質問する）:

1. レビュー対象の確認

   • 「レビュー対象のシステム・機能の概要を教えてください（把握していない場合）」
   • 「特に重点的にチェックしてほしい観点はありますか？（なければ全8観点を均等にチェック）」

2. スコープの確認

   • 「これは完成版の要求定義書ですか、それともドラフトですか？」
   • 「前提として存在する制約（技術スタック・法規制・既存システムとの連携等）があれば教えてください」

3. 優先度の確認

   • 「このドキュメントは spec スキルへ渡す直前の状態ですか？（Critical 問題のみ修正すべきか全問題か）」

注意: 質問は必要最小限に絞る。入力から自明なことは質問しない。

---

Phase 2: 体系的レビュー（2並列サブエージェント）

2つのサブエージェントを並列実行して効率化する:

サブエージェント A: 個別要求品質チェック

各要求を独立してレビュー:

• 観点 1: 曖昧性の検出 — 曖昧語辞書 (references/ambiguity-dictionary.md) を参照
• 観点 4: テスト可能性 — 「どのようにテストするか」を考えながら各要求を評価
• 観点 6: 粒度 — 1要求1責務の原則に照らして評価
• 観点 7: 過剰仕様回避 — 実装詳細・不要な制約の有無

サブエージェント B: 要求間・構造品質チェック

要求全体の構造と相互関係をレビュー:

• 観点 2: 一貫性 — 要求間の矛盾・同一概念の異なる表現
• 観点 3: 完全性 — 異常系・前提条件・アクター・環境の網羅性
• 観点 5: トレーサビリティ — 目的・価値との対応付け
• 観点 8: 非機能要求の分離 — 機能・非機能の混在

---

Phase 3: 結果統合・重大度判定・改善提案生成

両サブエージェントの結果を統合し:

1. 重複の排除: 同一問題の統合（パターンが同じ問題は代表例1つ＋件数で表示）
2. 重大度の判定: 以下の基準に従い Critical / Major / Minor を判定
3. 改善提案の生成: 各問題に具体的な改善案を添付
4. 良い点の抽出: 建設的なレビューのために肯定的な評価も記録

---

重大度判定基準

重大度	定義	例
Critical	spec 進行不可。このままでは仕様書が作れない、または致命的な矛盾がある	「ログインしている場合はログアウトする」と「ログイン中は常にセッションを維持する」が共存 / 主要機能の正常系が一切未定義
Major	spec 進行は可能だが、品質リスクが高い。修正推奨	テスト不可能な要求（「適切に処理する」）/ 重要な異常系が未定義 / 同一用語が異なる意味で使われている
Minor	品質改善のための指摘。対応は任意	軽微な曖昧表現 / 非機能要求が機能要求セクションに混在 / 不要な実装詳細の記述

---

レポート出力フォーマット

# 要求定義書レビューレポート

## サマリー

| 観点 | Critical | Major | Minor | 評価 |
|------|----------|-------|-------|------|
| 1. 曖昧性の検出     | X | X | X | ⭐⭐⭐⭐⭐ |
| 2. 一貫性           | X | X | X | ⭐⭐⭐⭐⭐ |
| 3. 完全性           | X | X | X | ⭐⭐⭐⭐⭐ |
| 4. テスト可能性     | X | X | X | ⭐⭐⭐⭐⭐ |
| 5. トレーサビリティ | X | X | X | ⭐⭐⭐⭐⭐ |
| 6. 粒度             | X | X | X | ⭐⭐⭐⭐⭐ |
| 7. 過剰仕様回避     | X | X | X | ⭐⭐⭐⭐⭐ |
| 8. 非機能要求の分離 | X | X | X | ⭐⭐⭐⭐⭐ |
| **合計**           | **X** | **X** | **X** | |

## スコアカード

| 項目 | スコア |
|------|--------|
| 総合品質スコア | ⭐⭐⭐☆☆ (3/5) |
| **spec 進行可否** | ✅ 進行可能 / ⚠️ 要修正後に進行 / ❌ 進行不可 |
| Critical 問題数 | X 件 |
| Major 問題数 | X 件 |

> **判定根拠**: [Critical が 0 件のため進行可能 / Critical X 件が解消されるまで進行不可 等]

---

## 問題詳細

### Critical

#### [C-01] <問題タイトル>
- **観点**: [観点名]
- **該当要求**: `[要求ID または引用]`
- **問題**: [問題の説明]
- **改善案**: [具体的な改善提案]

---

### Major

#### [M-01] <問題タイトル>
- **観点**: [観点名]
- **該当要求**: `[要求ID または引用]`
- **問題**: [問題の説明]
- **改善案**: [具体的な改善提案]

---

### Minor

#### [m-01] <問題タイトル>
- **観点**: [観点名]
- **該当要求**: `[要求ID または引用]`（他 X 件同様）
- **問題**: [問題の説明]
- **改善案**: [具体的な改善提案]

---

## 良い点

- [具体的に優れている要求・記述を挙げる]
- [良い記述のパターンを指摘する]

---

## 推奨アクション（優先度順）

1. 🔴 **[Critical 問題の修正]** — [具体的なアクション]
2. 🟡 **[Major 問題の修正]** — [具体的なアクション]
3. 🟢 **[Minor 問題の対応]** — [具体的なアクション（任意）]

スコアカードの評価基準

スコア	基準
⭐⭐⭐⭐⭐	問題なし
⭐⭐⭐⭐	Minor のみ
⭐⭐⭐	Major 1〜2件
⭐⭐	Major 3件以上、または Critical 1件
⭐	Critical 2件以上

spec 進行可否の判断

判定	条件
✅ 進行可能	Critical = 0
⚠️ 要修正後に進行	Critical = 0 かつ Major ≥ 3（または主要機能の Major）
❌ 進行不可	Critical ≥ 1

---

注意事項

1. 改善案は提案のみ: 要求定義書を自動修正しない。ユーザーが判断・修正する
2. 同パターン問題はまとめる: 同じ問題が多数ある場合は「代表例 + 他 X 件同様」でまとめる
3. 文脈を尊重する: 省略されている情報が暗黙の前提として妥当な場合は問題視しない
4. 批判的になりすぎない: Minor を大量に列挙するよりも、重要な問題に集中する
5. ドメイン知識の限界: ドメイン固有の正しさは判断できないため、論理的な問題に集中する

---

使用例

例 1: EARS記法の要求定義書

ユーザー: 以下の要求定義書をレビューしてください。

REQ-001: WHEN ユーザーがログインボタンを押した時、
         システムはユーザーを認証しなければならない。
REQ-002: WHILE ユーザーが管理者権限を持っている場合、
         システムはユーザー管理画面を表示しなければならない。
REQ-003: システムは適切にエラーを処理しなければならない。

Claude: [Phase 1: スコープ確認後、Phase 2 で 2並列レビュー実行]
出力: レビューレポート
  - REQ-001: Major [テスト不可能] 「認証」の成功/失敗条件が未定義
  - REQ-003: Critical [曖昧性] 「適切に」は測定不能

例 2: 自然言語の要求定義書

ユーザー: このドキュメントをレビューしてください。
「ユーザーはファイルをアップロードできる。
 大きすぎるファイルはアップロードできない。
 アップロードしたファイルはすぐに表示される。」

Claude: [Phase 2 で各文を要求として解析しレビュー]
出力: レビューレポート
  - 「大きすぎる」: Critical [曖昧性] サイズ上限が数値未定義
  - 「すぐに」: Major [テスト不可能] 許容レイテンシが未定義
  - 正常系と異常系が混在: Minor [粒度]

---

リファレンス

ファイル	内容
references/review-checklist.md	8観点の詳細チェックリスト・良い例/悪い例・典型的な問題パターン
references/ambiguity-dictionary.md	曖昧語辞書と改善例（4カテゴリ）