req-workflow

## 要件定義完全ワークフロー コンテキスト情報を入力として、要件定義書を作成し、レビュー・承認までを一貫して行うワークフロー。 ## 入力 $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. **ヒアリング質問リスト生成**: ```markdown ## 確認事項リスト ### 🔴 必須確認（これがないと要件定義の品質が担保できません） 1. [質問内容] - 背景: なぜこの情報が必要か - 例: 回答の具体例 ### 🟡 推奨確認（あると設計精度が大幅に向上します） 2. [質問内容] ### 🟢 任意確認（Phase 1で仮定を置くことも可能） 3. [質問内容] ``` 3. **質問テンプレート（カテゴリ別）**: | カテゴリ | 必須質問例 | |---------|-----------| | ビジネス | 「このプロジェクトの成功指標は何ですか？（例: MAU 1万達成 / 工数50%削減 / 売上10%増）」 | | ユーザー | 「メインターゲットユーザーは誰ですか？（例: 社内開発チーム / 一般消費者 / 企業の管理者）」 | | 技術 | 「既存システムとの連携は必要ですか？あれば連携方式の制約を教えてください」 | | スコープ | 「MVP（最小限の機能）として必須な機能は何ですか？」 | | 制約 | 「予算・リソース・納期に制約はありますか？」 | 4. **ユーザー選択**: ```markdown ⚠️ 要件定義に必要な情報が不足しています。 **検出された情報ギャップ:** | カテゴリ | 状態 | 不足情報 | |---------|------|---------| | ビジネス | ⚠️ 部分的 | 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. **影響分析レポート作成**: ```markdown ## 既存要件との整合性チェック結果 ### 関連する既存要件定義書 | ドキュメント | 関連度 | 影響 | |-------------|--------|------| | REQ-XXX-001_既存機能.md | 高 | 機能追加 | ### 整合性チェック結果 | 項目 | ステータス | 備考 | |------|----------|------| | 機能ID | ✅ OK | F-024から連番開始 | | 用語定義 | ✅ OK | 既存用語集と整合 | | 技術制約 | ⚠️ 要確認 | 依存バージョンの確認が必要 | ### 既存要件への影響 - REQ-XXX-001 の機能一覧に追記が必要 - または新規要件定義書 REQ-XXX-002 として独立作成 ``` 4. **ユーザー確認（影響がある場合）**: ```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 を参照 | 項目 | 値 | |------|-----| | ドキュメント種別 | 要件定義書 | | 合格基準 | 8点以上 | | 次のアクション | 成果物サマリー出力 → 基本設計へ | **重要**: ユーザーからの明示的な応答があるまで次のフェーズに進んではならない。 --- ### Phase 3: 成果物サマリー レビュー合格後、成果物をまとめて報告 **実行内容:** - 要件定義書の概要をまとめる - 機能一覧を抽出 - 次ステップ選択を提示 --- ### Phase 3.5: 次ステップ選択【必須】 > **共通仕様・出力形式**: `approval-gate` skill の「ワークフロー完了後の次ステップ選択」を参照 | 項目 | 値 | |------|-----| | ワークフロー名 | 要件定義 | | 次ワークフロー | `/basic-design-workflow` | --- ## 最終出力 ```markdown ## ワークフロー完了報告 ### 実行サマリー | フェーズ | ステータス | 詳細 | |---------|-----------|------| | コンテキスト収集 | 完了 | 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 "{成果物パス}" ``` ---