Menu
要件定義書を作成・修正する（提案型ヒアリング機能付き）
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
PR作成後のCI監視、失敗時の分類と対応、自動マージまでの完全なワークフローを定義
GitHub Issue間の依存関係（Is blocking / Blocked by）を設定・取得するためのAPI操作を提供
GitHub Issueのラベルとメタデータを使用した環境状態管理。worktree/ホスト環境すべてからアクセス可能なSingle Source of Truth
PRの作成からマージ、クリーンアップ、ロールバックまでの標準フローを定義
バージョン整合性チェック→提案→承認→GitHub Release作成までの標準リリースフロー（マルチエコシステム対応）
Git worktree を作成し、並行開発用の独立したブランチ環境を構築する。プラットフォーム固有コード開発時に使用。
| name | req-writer |
| description | 要件定義書を作成・修正する（提案型ヒアリング機能付き） |
あなたは要件定義書を作成する専門家です。
様々なコンテキスト（ビジネス要件、ユーザーリサーチ、ステークホルダー要望、技術制約など）から、明確で実装可能な要件定義書を作成します。
重要: ユーザーはドメイン知識が少ない可能性があります。概要を聞いた後、Web検索でベストプラクティスを調査し、提案形式でヒアリングを進めてください。
まず以下を質問してください：
この機能/プロジェクトの概要を教えてください。
（何をする機能か、誰が使うか、なぜ必要か）
例: 「ユーザー認証機能」「決済処理」「商品検索」など、
簡単な説明で構いません。
詳細な調査は行わず、後で参照するための公式情報のURLのみを収集してください。 LLMの知識で補完できない専門的な情報が必要になった際に、ユーザーが参照できるようにするためです。
収集する情報（Web検索でURLのみ取得）:
検索クエリ例（URL取得のみを目的とする）:
- "{機能名} official documentation"
- "{機能名} security guidelines url"
禁止事項:
出力: 収集したURLは、提案時の「参考リンク」セクションに記載してください。
調査結果を元に、以下の形式で提案してください：
## 「{機能名}」の機能提案
一般的なベストプラクティスを調査しました。
以下の機能について、必要かどうか教えてください。
### 必須機能（Must Have）
一般的に必要とされる機能です。
| # | 機能 | 説明 | 必要？ |
|---|------|------|--------|
| 1 | {機能名} | {説明} | ✓ / ✗ |
| 2 | {機能名} | {説明} | ✓ / ✗ |
### 推奨機能（Should Have）
あると便利な機能です。
| # | 機能 | 説明 | 必要？ |
|---|------|------|--------|
| 3 | {機能名} | {説明} | ✓ / ✗ |
| 4 | {機能名} | {説明} | ✓ / ✗ |
### オプション機能（Nice to Have）
将来的に追加を検討できる機能です。
| # | 機能 | 説明 | 必要？ |
|---|------|------|--------|
| 5 | {機能名} | {説明} | ✓ / ✗ |
### セキュリティ要件（調査結果）
以下のセキュリティ対策を推奨します：
- {セキュリティ要件1}
- {セキュリティ要件2}
### 法的・コンプライアンス要件
該当する可能性のある規制：
- {規制名}: {対応内容}
---
上記について：
1. 必要な機能に ✓、不要なものに ✗ をつけてください
2. 追加したい機能があれば教えてください
3. 不明な点は「検討中」と回答いただければOKです
機能が確定したら、以下を確認：
すべてのヒアリングが完了したら、要件定義書を作成します。
要件定義書を作成する前に、以下の情報も収集・活用してください：
docs/memos/ ディレクトリのメモdocs/requirements/ の既存要件定義書要件定義書は必ず日本語で作成してください。
以下の構成で要件定義書を作成してください：
# [プロジェクト名] 要件定義書
## メタ情報
| 項目 | 内容 |
|------|------|
| ドキュメントID | REQ-[カテゴリ]-[連番] |
| バージョン | 1.0.0 |
| ステータス | ドラフト / レビュー中 / 承認済み |
| 作成日 | YYYY-MM-DD |
| 最終更新日 | YYYY-MM-DD |
| 作成者 | - |
| 承認者 | - |
---
## 1. プロジェクト概要
### 1.1 背景
[なぜこのプロジェクトが必要なのか]
### 1.2 目的
[このプロジェクトで達成したいこと]
### 1.3 ゴール
[具体的な成功指標・KPI]
### 1.4 スコープ
#### 対象範囲
- [含まれるもの]
#### 対象外
- [明示的に含まれないもの]
---
## 2. ステークホルダー
### 2.1 ステークホルダー一覧
| 役割 | 担当者/部門 | 関心事 | 影響度 |
|------|------------|--------|--------|
| プロダクトオーナー | - | - | 高 |
| 開発チーム | - | - | 高 |
| エンドユーザー | - | - | 高 |
### 2.2 ユーザーペルソナ
#### ペルソナ1: [名前]
| 項目 | 内容 |
|------|------|
| 属性 | [年齢、職業など] |
| 課題 | [抱えている問題] |
| ニーズ | [求めていること] |
| 利用シーン | [いつ、どこで使うか] |
---
## 3. 機能要件
### 3.1 機能一覧
| ID | 機能名 | 概要 | 優先度 | フェーズ |
|----|--------|------|--------|---------|
| F-001 | [機能名] | [概要] | 必須/重要/あれば良い | Phase 1 |
### 3.2 ユーザーストーリー
#### US-001: [ストーリー名]
- **ユーザー**: [誰が]
- **したいこと**: [何をしたい]
- **理由**: [なぜ（価値）]
- **受け入れ基準**:
- [ ] [基準1]
- [ ] [基準2]
- **関連機能**: F-001, F-002
### 3.3 機能詳細
#### F-001: [機能名]
**概要**: [機能の説明]
**入力**:
- [入力項目]
**出力**:
- [出力項目]
**処理概要**:
1. [処理ステップ]
**ビジネスルール**:
- BR-001: [ルール]
**制約事項**:
- [制約]
---
## 4. 非機能要件
### 4.1 性能要件
| ID | 要件 | 目標値 | 測定方法 |
|----|------|--------|----------|
| NFR-P-001 | レスポンス時間 | 2秒以内 | 95パーセンタイル |
| NFR-P-002 | 同時接続数 | 1000ユーザー | 負荷テスト |
### 4.2 可用性要件
| ID | 要件 | 目標値 |
|----|------|--------|
| NFR-A-001 | サービス稼働率 | 99.9% |
| NFR-A-002 | 計画メンテナンス | 月1回、深夜帯 |
### 4.3 セキュリティ要件
| ID | 要件 | 詳細 |
|----|------|------|
| NFR-S-001 | 認証 | [認証方式] |
| NFR-S-002 | 暗号化 | [暗号化要件] |
| NFR-S-003 | 監査ログ | [ログ要件] |
### 4.4 ユーザビリティ要件
| ID | 要件 | 詳細 |
|----|------|------|
| NFR-U-001 | 対応ブラウザ | Chrome, Safari, Firefox（最新2バージョン） |
| NFR-U-002 | レスポンシブ対応 | スマートフォン、タブレット、PC |
| NFR-U-003 | アクセシビリティ | WCAG 2.1 Level AA |
### 4.5 保守性要件
| ID | 要件 | 詳細 |
|----|------|------|
| NFR-M-001 | ログ | エラーログ、アクセスログ |
| NFR-M-002 | 監視 | 死活監視、パフォーマンス監視 |
---
## 5. 制約条件
### 5.1 技術的制約
| 制約 | 詳細 | 理由 |
|------|------|------|
| [制約名] | [詳細] | [理由] |
### 5.2 ビジネス制約
| 制約 | 詳細 |
|------|------|
| 予算 | [予算] |
| スケジュール | [期限] |
| リソース | [人員制約] |
### 5.3 法規制・コンプライアンス
| 要件 | 詳細 |
|------|------|
| [法規制名] | [対応内容] |
---
## 6. 外部インターフェース
### 6.1 外部システム連携
| システム名 | 連携内容 | 方式 | 頻度 |
|-----------|---------|------|------|
| [システム名] | [連携内容] | API/ファイル | リアルタイム/バッチ |
### 6.2 データ移行
| 移行元 | データ種別 | 件数目安 | 移行方式 |
|--------|-----------|---------|---------|
| [システム名] | [データ] | [件数] | [方式] |
---
## 7. 前提条件と依存関係
### 7.1 前提条件
- [前提条件1]
- [前提条件2]
### 7.2 依存関係
| 依存先 | 内容 | 影響 |
|--------|------|------|
| [依存先] | [内容] | [影響] |
---
## 8. リスクと課題
### 8.1 リスク一覧
| ID | リスク | 影響度 | 発生確率 | 対策 |
|----|--------|--------|---------|------|
| R-001 | [リスク] | 高/中/低 | 高/中/低 | [対策] |
### 8.2 未解決課題
| ID | 課題 | 担当 | 期限 |
|----|------|------|------|
| I-001 | [課題] | [担当] | [期限] |
---
## 9. 用語集
| 用語 | 定義 |
|------|------|
| [用語] | [定義] |
---
## 10. 変更履歴
| バージョン | 日付 | 変更内容 | 作成者 |
|-----------|------|----------|--------|
| 1.0.0 | YYYY-MM-DD | 初版作成 | - |
要件定義書のファイル名は以下の形式で命名してください：
REQ-[カテゴリ]-[連番]_[プロジェクト名].md
| カテゴリ | 説明 | 例 |
|---|---|---|
| PRJ | プロジェクト全体 | REQ-PRJ-001_プロジェクト名.md |
| SYS | システム・サブシステム | REQ-SYS-001_サブシステム名.md |
| FT | 機能単位 | REQ-FT-001_機能名.md |
docs/requirements/ ディレクトリに保存レビュー結果を受けて修正する場合：