req-workflow

要件定義完全ワークフロー

コンテキスト情報を入力として、要件定義書を作成し、レビュー・承認までを一貫して行うワークフロー。

入力

$ARGUMENTS

入力形式

以下の形式で入力を受け付けます：

プロジェクト: [プロジェクト名・概要]
ビジネス: [ビジネス目標・KPI]
ユーザー: [ターゲットユーザー・課題]
技術: [技術制約・既存システム]
メモ: [参照するメモのパス（任意）]

入力例:

プロジェクト: タスク管理システムの新規開発
ビジネス: チーム生産性向上、進捗可視化
ユーザー: 開発チーム、プロジェクトマネージャー
技術: Next.js、既存の認証基盤と連携必須
メモ: docs/memos/task-management-idea.md

簡易入力（プロジェクト概要のみ）:

ユーザー管理機能を持つWebアプリケーションを作りたい

全体フロー

Phase規約: workflow-phase-convention skill を参照

サーキットブレーカー

Phase 0: コンテキスト収集

入力から参照先を解析し、必要な情報を収集

実行内容:

1. 入力から要件の種類・規模を判断
2. 指定されたメモファイルを読み込み
3. docs/memos/ ディレクトリを自動チェック
4. docs/requirements/ の既存要件定義書を確認
5. プロジェクト構成（package.json等）を把握
6. 収集した情報を整理

収集する情報:

【重要】技術スタック完全性チェック:

以下の技術スタックが定義されているか確認し、未定義の場合は未解決課題として記録する：

注意: 技術スタックが未定義の場合、仮定で埋めずに「要選定（I-XXX）」と明記すること。

完了条件:

• コンテキスト情報が整理されている
• 技術スタック完全性チェックが実施されている

Phase 0.3: ヒアリング提案【入力不足時】

トリガー: コンテキスト収集後、以下のいずれかに該当する場合
- 必須情報（ビジネス目標/ユーザー/技術制約）が欠落
- 曖昧な表現が多い（「など」「適宜」「必要に応じて」）
- 矛盾する要件が存在
- スコープが広すぎる/不明確

目的: 要件定義の品質を左右する重要情報を事前に収集し、後工程での手戻りを防止する。

実行内容:

1. 情報ギャップ分析:

1. ヒアリング質問リスト生成:

```markdown ## 確認事項リスト

### 🔴 必須確認（これがないと要件定義の品質が担保できません） 1. [質問内容] - 背景: なぜこの情報が必要か - 例: 回答の具体例

### 🟡 推奨確認（あると設計精度が大幅に向上します） 2. [質問内容]

### 🟢 任意確認（Phase 1で仮定を置くことも可能） 3. [質問内容] ```

1. 質問テンプレート（カテゴリ別）:

1. ユーザー選択:

```markdown ⚠️ 要件定義に必要な情報が不足しています。

検出された情報ギャップ:

対応を選択してください:

1. ヒアリング実施 → 上記質問への回答を入力 2. 仮定で続行 → 不明点は「未解決課題（I-XXX）」として記録し続行 3. 中断 → 情報収集後に再開

> 番号を選択してください（1-3）: ```

ユーザー回答と対応:

スキップ条件:

• 全カテゴリが ✅ 評価（情報が十分）
• ユーザーから「仮定で続行」と明示的に指示された場合

完了条件:

• 情報ギャップ分析が完了
• ユーザーが対応方針を選択済み
• 選択に応じた処理が完了（回答追加 or 未解決課題記録 or 中断）

Phase 0.5: 既存要件との整合性確認【追加仕様時】

トリガー: docs/requirements/ に既存の要件定義書が存在する場合

目的: 追加仕様が既存要件と矛盾しないことを確認し、影響範囲を特定する。

実行内容:

1. 既存要件定義書の特定:

- docs/requirements/REQ-*.md を検索 - 関連する要件定義書を特定（同一プロジェクト/機能領域）

1. 整合性チェック項目:

1. 影響分析レポート作成:

```markdown ## 既存要件との整合性チェック結果

### 関連する既存要件定義書

### 整合性チェック結果

### 既存要件への影響 - REQ-XXX-001 の機能一覧に追記が必要 - または新規要件定義書 REQ-XXX-002 として独立作成 ```

1. ユーザー確認（影響がある場合）:

```markdown ⚠️ 既存要件への影響が検出されました。

対応方針を選択してください:

1. 追記 → 既存要件定義書に追記 2. 新規 → 新規要件定義書として作成 3. 中断 → 確認後に再開

> 番号を選択してください（1-3）: ```

スキップ条件:

• docs/requirements/ に既存要件定義書が存在しない（新規プロジェクト）
• ユーザーから「新規要件として作成」と明示的に指示された場合

完了条件:

• 既存要件との整合性チェックが完了
• 影響がある場合はユーザー確認済み
• 作成方針（追記 or 新規）が決定

Phase 1: 要件定義書作成

req-writer skill を使用して要件定義書を作成

実行内容:

• 収集したコンテキストを活用
• 入力情報を分析
• テンプレートに従って要件定義書を作成（日本語）
• docs/requirements/REQ-[カテゴリ]-[連番]_[プロジェクト名].md に保存

コンテキストの活用:

• ビジネス要件を「目的・ゴール」に反映
• ユーザー情報を「ペルソナ」「ユーザーストーリー」に反映
• 技術制約を「制約条件」「非機能要件」に反映
• 不明点は「未解決課題」に記載

完了条件:

• 要件定義書ファイルが作成されている
• 必須セクションがすべて記載されている

Phase 2: レビュー・修正ループ

req-reviewer skill と req-writer skill を使用してレビューと修正を繰り返す

実行内容:

loop (最大5回):
    1. req-reviewerでレビュー実行
    2. スコアが8点以上なら終了
    3. req-writerで問題点を修正
    4. ループ継続

完了条件:

• スコアが8点以上
• または5回ループ完了

Note: 要件定義は最大5回リトライ（設計/実装の3回より多い）

理由: 要件定義は後工程の土台となるため、ここでの品質確保が最重要。
ステークホルダーとの認識齟齬を解消するために、より多くの修正機会を確保。
また、要件の曖昧さは設計・実装フェーズで増幅されるため、
初期段階での徹底的な精査が全体コストを削減する。

Phase 2.5: ユーザー承認ゲート【必須】

共通仕様・出力形式: approval-gate skill を参照

重要: ユーザーからの明示的な応答があるまで次のフェーズに進んではならない。

Phase 3: 成果物サマリー

レビュー合格後、成果物をまとめて報告

実行内容:

• 要件定義書の概要をまとめる
• 機能一覧を抽出
• 次ステップ選択を提示

Phase 3.5: 次ステップ選択【必須】

共通仕様・出力形式: approval-gate skill の「ワークフロー完了後の次ステップ選択」を参照

最終出力

## ワークフロー完了報告

### 実行サマリー
| フェーズ | ステータス | 詳細 |
|---------|-----------|------|
| コンテキスト収集 | 完了 | X件の情報源を参照 |
| 要件定義書作成 | 完了 | [ファイルパス] |
| レビューループ | 完了 | X回実行, 最終スコア: X/10 |

### 収集したコンテキスト
| 種類 | ソース | 主な内容 |
|------|--------|---------|
| ビジネス | 入力情報 | [概要] |
| ユーザー | 入力情報 | [概要] |
| メモ | docs/memos/xxx.md | [概要] |

### 成果物
#### 要件定義書
- パス: docs/requirements/REQ-XXX-001_xxx.md
- 最終スコア: X/10点

#### 機能一覧
| ID | 機能名 | 優先度 | フェーズ |
|----|--------|--------|---------|
| F-001 | [機能名] | 必須 | Phase 1 |
| F-002 | [機能名] | 重要 | Phase 1 |

### レビュースコア推移
| 回 | スコア | 主な改善点 |
|----|--------|-----------|
| 1  | X/10   | ... |
| 2  | X/10   | ... |

### 未解決課題
| ID | 課題 | 対応方針 |
|----|------|---------|
| I-001 | [課題] | [方針] |

---

## エラーハンドリング

- **フェーズ0失敗**: メモが見つからない場合は入力情報のみで続行
- **フェーズ1失敗**: 入力情報の不足を報告し、追加情報を要求
- **フェーズ2で5回ループ後も8点未満**: 現状の問題点をまとめて報告、手動修正を推奨

## 全体フロー図

[入力] コンテキスト情報 ↓ [Phase 0] コンテキスト収集 ├── メモ読み込み ├── 既存ドキュメント確認 └── プロジェクト構成把握 ↓ [Phase 0.3] ヒアリング提案 ★入力不足時 ├── 情報ギャップ分析 ├── 確認事項リスト生成 └── ⏸️ ヒアリング/仮定で続行/中断 を選択 ↓ (情報十分 or ヒアリング完了) [Phase 0.5] 既存要件との整合性確認 ★追加仕様時 ├── 関連要件定義書の特定 ├── 整合性チェック（機能ID/用語/技術制約） ├── 影響分析レポート作成 └── ⏸️ 追記/新規/中断 を選択 ↓ [Phase 1] 要件定義書作成 └── req-writer skill ↓ [Phase 2] レビュー・修正ループ ├── req-reviewer skill → スコア判定 └── req-writer skill → 修正 ↓ (8点以上) [Phase 2.5] ユーザー承認ゲート └── ⏸️ 続行/修正/中断 を待機 ↓ (続行) [Phase 3] 成果物サマリー ↓ [Phase 3.5] 次ステップ選択 ★NEW └── ⏸️ 1.基本設計へ / 2.修正 / 3.終了 を選択 ↓ (1を選択) [自動実行] /basic-design-workflow "{成果物パス}"

---

## 参考スキル

| スキル | 用途 |
|--------|------|
| `approval-gate` skill | ユーザー承認ゲート |
| `workflow-phase-convention` skill | Phase命名規約 |