shield_lock
JinDaGe
← Back to skills
extension
Category: AI Agent CapabilitiesNo API key required

req-workflow

Complete workflow from creating a requirements definition document from the context → review → approval

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

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

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

入力

$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命名規約 |