req-workflow

name	req-workflow
description	コンテキストから要件定義書作成→レビュー→承認までの完全ワークフロー

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

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

入力

$ARGUMENTS

入力形式

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

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

入力例:

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

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

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

---

全体フロー

Phase	名称	内容
0	コンテキスト収集	入力解析、メモ読み込み、既存ドキュメント確認
0.3	ヒアリング提案	情報不足時の確認事項リスト生成【条件付き】
0.5	既存要件整合性確認	既存要件定義書との整合性チェック（追加仕様時）
1	要件定義書作成	``req-writer skill による作成
2	レビューループ	``req-reviewer skill によるレビュー（8点以上、最大5回）
2.5	ユーザー承認	approval-gate skill
3	成果物サマリー	完了報告、次ステップ提示

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

---

サーキットブレーカー

条件	アクション
メモ不在	入力情報のみで続行
入力不足	Phase 0.3 ヒアリング提案を実行
5回ループ後も8点未満	現状の問題点をまとめて報告、手動修正を推奨

---

Phase 0: コンテキスト収集

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

実行内容:

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

収集する情報:

カテゴリ	収集内容
ビジネス	目的、ゴール、KPI、予算、スケジュール
ユーザー	ペルソナ、課題、ニーズ、利用シーン
技術	技術スタック、制約、既存システム
競合	競合サービス、差別化ポイント
法規制	コンプライアンス要件

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

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

レイヤー	必須/推奨	未定義時のアクション
フロントエンド	必須	未解決課題に追加（例: I-XXX フロントエンド技術選定）
バックエンド	必須	未解決課題に追加
データベース	必須	未解決課題に追加
認証方式	必須	未解決課題に追加
インフラ/クラウド	推奨	備考として記載
CI/CD	推奨	備考として記載

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

完了条件:

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

---

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

トリガー: コンテキスト収集後、以下のいずれかに該当する場合

• 必須情報（ビジネス目標/ユーザー/技術制約）が欠落
• 曖昧な表現が多い（「など」「適宜」「必要に応じて」）
• 矛盾する要件が存在
• スコープが広すぎる/不明確

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

実行内容:

1. 情報ギャップ分析:

   カテゴリ	評価	チェック項目
   ビジネス	✅/⚠️/❌	目的明確か、KPI具体的か、予算/スケジュールあるか
   ユーザー	✅/⚠️/❌	ペルソナ特定可能か、課題明確か、利用シーン想定できるか
   技術	✅/⚠️/❌	技術スタック指定あるか、既存システム連携明確か
   スコープ	✅/⚠️/❌	境界明確か、優先順位あるか、フェーズ分けあるか

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

   ## 確認事項リスト
   
   ### 🔴 必須確認（これがないと要件定義の品質が担保できません）
   1. [質問内容]
      - 背景: なぜこの情報が必要か
      - 例: 回答の具体例
   
   ### 🟡 推奨確認（あると設計精度が大幅に向上します）
   2. [質問内容]
   
   ### 🟢 任意確認（Phase 1で仮定を置くことも可能）
   3. [質問内容]
   

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

   カテゴリ	必須質問例
   ビジネス	「このプロジェクトの成功指標は何ですか？（例: MAU 1万達成 / 工数50%削減 / 売上10%増）」
   ユーザー	「メインターゲットユーザーは誰ですか？（例: 社内開発チーム / 一般消費者 / 企業の管理者）」
   技術	「既存システムとの連携は必要ですか？あれば連携方式の制約を教えてください」
   スコープ	「MVP（最小限の機能）として必須な機能は何ですか？」
   制約	「予算・リソース・納期に制約はありますか？」

4. ユーザー選択:

   ⚠️ 要件定義に必要な情報が不足しています。
   
   **検出された情報ギャップ:**
   | カテゴリ | 状態 | 不足情報 |
   |---------|------|---------|
   | ビジネス | ⚠️ 部分的 | KPI具体値 |
   | ユーザー | ❌ 不足 | ペルソナ詳細 |
   
   **対応を選択してください**:
   
   1. ヒアリング実施 → 上記質問への回答を入力
   2. 仮定で続行 → 不明点は「未解決課題（I-XXX）」として記録し続行
   3. 中断 → 情報収集後に再開
   
   > 番号を選択してください（1-3）:
   

ユーザー回答と対応:

回答	アクション
1	ユーザーの回答を待ち、回答内容をコンテキストに追加して Phase 0.5 へ
2	不足情報を「未解決課題」として記録し、仮定を明記して Phase 0.5 へ
3	ワークフロー中断。再開時は収集した情報を入力として再実行

スキップ条件:

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

完了条件:

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

---

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

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

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

実行内容:

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

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

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

   チェック項目	確認内容	矛盾時のアクション
   機能ID重複	新規F-XXXが既存と重複しないか	連番を調整
   用語定義	同一用語が異なる意味で使われていないか	用語集を統一
   技術制約	既存の技術制約と矛盾しないか	制約の優先順位を明記
   非機能要件	パフォーマンス/セキュリティ要件が矛盾しないか	厳しい方を採用
   スコープ境界	既存のスコープ外項目と重複しないか	スコープ変更を明記

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

   ## 既存要件との整合性チェック結果
   
   ### 関連する既存要件定義書
   | ドキュメント | 関連度 | 影響 |
   |-------------|--------|------|
   | REQ-XXX-001_既存機能.md | 高 | 機能追加 |
   
   ### 整合性チェック結果
   | 項目 | ステータス | 備考 |
   |------|----------|------|
   | 機能ID | ✅ OK | F-024から連番開始 |
   | 用語定義 | ✅ OK | 既存用語集と整合 |
   | 技術制約 | ⚠️ 要確認 | 依存バージョンの確認が必要 |
   
   ### 既存要件への影響
   - REQ-XXX-001 の機能一覧に追記が必要
   - または新規要件定義書 REQ-XXX-002 として独立作成
   

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

   ⚠️ 既存要件への影響が検出されました。
   
   **対応方針を選択してください**:
   
   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 を参照

項目	値
ドキュメント種別	要件定義書
合格基準	8点以上
次のアクション	成果物サマリー出力 → 基本設計へ

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

---

Phase 3: 成果物サマリー

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

実行内容:

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

---

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

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

項目	値
ワークフロー名	要件定義
次ワークフロー	/basic-design-workflow

---

最終出力

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

### 実行サマリー
| フェーズ | ステータス | 詳細 |
|---------|-----------|------|
| コンテキスト収集 | 完了 | 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命名規約 |