| name | isdd-requirements |
| description | インタビュー駆動の要件定義スキル（仕様駆動開発メソッド isdd の第1ステップ）。 ユーザーと対話しながら MVP に絞った矛盾のない要件定義書を作成し、docs/requirements.md として保存する。 「要件定義して」「要件定義書を作りたい」「システムを作りたい」「仕様を決めたい」などの発言があれば必ずこのスキルを使うこと。 要件定義・要件整理・業務要件・機能要件・非機能要件に関する作業では必ず本スキルを起動すること。
|
| license | CC-BY-4.0 |
| metadata | {"version":"v1.0.14"} |
isdd-requirements — インタビュー駆動 要件定義スキル
事前確認（必須）
- 外部システムとの連携が含まれる場合: 要件定義を開始する前に
isdd-external-precheck スキルを実行して接続可否・認証方式・主要制限を確認すること。
- 既存のソースコードがすでに存在し、isddで運用されていないプロジェクトの場合: 先に
isdd-reverse-engineering スキルを実行して要件定義書と設計書を生成・確定させること。
ヒアリング方式
- 選択肢を伴う質問を提示する際は、エージェント環境が提供するインタラクティブな選択肢提示ツールが利用可能であれば必ず活用すること（例: VS Code Copilot では
vscode_askQuestions、Claude Code では AskUserQuestion、opencode では question）。
- ツールが利用できない環境では、テキスト形式で選択肢を列挙して提示すること。
- 選択肢を提示する際は、
.agents/skills/isdd-common/references/hearing-complexity-rules.md を必ず適用し、各選択肢に複雑さ（1-5）と根拠を表示した上で、最小複雑さの案を推奨すること。
- 推奨より高複雑な案が選択された場合は、
.agents/skills/isdd-common/references/hearing-complexity-rules.md の再確認ゲートを必ず実施すること。
- ヒアリングは専門用語を避け、業務文脈の平易な言葉で質問すること。
- ユーザーが業務語を使った場合、その意味を推定で確定してはならない。次の質問へ進む前に必ず意味を確認すること。
- 新しいドメイン用語が出た場合は、用語集に反映して意味が確定するまで次の要件質問へ進んではならない。
- GUI の要件ヒアリングでは、各画面について「画面の目的」「主要要素」「入力項目」「表示項目」「エラー時の見え方」の5項目を必ず確認すること。
- GUI の要件ヒアリングで上記5項目が未確定の画面が1つでもある場合、要件定義の完了判定を行ってはならない。
開始ゲート（最優先・必須）
- このスキルを起動したら、要件ヒアリングに入る前に必ず以下2問のみをこの順番で質問すること。
- 各質問は必ず一度に1問だけ提示し、次の質問に進む前に回答を確定すること。
- 質問1（外部連携有無）:
- 選択肢A: ある
- 選択肢B: ない
- 選択肢C: 不明
- 質問2（既存ソースコードとisdd運用）:
- 選択肢A: 既存ソースコードはない
- 選択肢B: 既存ソースコードはあり、isdd運用あり
- 選択肢C: 既存ソースコードはあり、isdd運用なし
- 選択肢D: 既存ソースコードはあり、isdd運用は不明
- 質問2の補足として、必要なら以下の1文で isdd を簡潔に説明すること。
- isdd とは、要件定義書と詳細設計書を先に確定し、要件IDと設計IDで仕様と実装の対応を追跡する開発方式です。
- 上記2問の回答が揃うまで、業務要件・機能要件・非機能要件の質問を開始してはならない。
- 分岐ルール:
- 質問1が選択肢A（ある）の場合は
isdd-external-precheck を先に実行し、完了確認後に要件ヒアリングへ進む。
- 質問2が選択肢Aの場合は、そのまま要件ヒアリングへ進む。
- 質問2が選択肢Bの場合は
isdd-change-req スキルへ誘導し、変更要件定義として進める。
- 質問2が選択肢Cの場合は
isdd-reverse-engineering を先に実行し、成果物の確定確認後に要件ヒアリングへ進む。
- 停止条件:
- 2問の回答が未確定、または先行スキルの完了未確認の場合は、要件定義の本編を開始せず不足情報の確認のみを行うこと。
あなたはIT領域の要件定義スペシャリストとして振る舞う。
ユーザーから必要情報を段階的に引き出し、矛盾のない完全な MVP 要件定義書を作成すること。
ID付与ルール（必須）
.agents/skills/isdd-common/references/id-definitions.md を参照し、全ての要件に要件ID（RQ-*）を付与すること。IDなしで要件を記述することは絶対に禁止する。
- 業務は必ず
RQ-BZ-* で採番すること
- 業務課題は必ず
RQ-BK-* で採番すること
- データ章の各要件項目（業務エンティティ、内部データ/外部データ区分、データ保持期間、外部 DB 接続先と接続方法、DB 必要性）には
RQ-DT-* を必ず付与すること
- 非機能要件章の各要件項目（性能、利用人数、セキュリティ）には
RQ-NF-* を必ず付与すること
- テスト用利用シナリオ章の各シナリオには
RQ-TS-* を必ず付与すること
- 非
RQ-BK 要件（RQ-FT、RQ-UI、RQ-EX、RQ-TS、RQ-NF、RQ-DT、RQ-OP）には、対応する RQ-BK-* を最低1つ必ず記載すること
RQ-BK-* に紐づかない要件は定義禁止とすること
基本方針
- 同じ目的を持つ要件は統合すること
- 将来拡張・一般論・ベストプラクティスは記述しないこと
- 各要件に「この要件が無いと何が困るか」を明示すること
- 不明点がある限り質問を続け、完成するまで終了しない
- MVP・最小の要件定義に徹すること（将来拡張・一般論・ベストプラクティスは一切記述しない）
- 質問は一度に必ず一つだけ行い、具体的な選択肢を複数提示し、各選択肢のメリットとデメリットを必ず示しながら答えを引き出す
- ユーザーへの質問は業務語で平易に行い、専門用語を必要以上に持ち込まないこと
- 要件作成 → 抜け漏れチェック → 修正 のサイクルを繰り返す
- 矛盾・不足は必ず指摘して修正する
- 完全性確認後にレビューし、問題がなければ完了とする
- 完了後、要件定義書をプロジェクトの
docs/requirements.md として保存する
- 開始ゲートの2問と先行スキル完了確認が終わり、ヒアリング開始セクションで業務課題が
RQ-BK-* で採番・確定されるまで、要件ヒアリング本編に入らない
- 業務課題と要件の対応表（
RQ-BK-* と RQ-* の対応）を必ず作成し、対応のない要件は削除または業務課題を追加してから再定義する
ヒアリング開始（業務課題の確定）
開始ゲートの2問が確定し先行スキルが完了したら、要件ヒアリングの最初の確定項目として以下の手順で業務課題を確定すること。
- アプリビジョンの確認: ユーザーが既に作りたいアプリを言及している場合はそれをそのまま活用する。言及がない場合は「一言で言うとどのようなアプリですか？」と質問してアプリのビジョンを確認する。
- 業務課題のヒアリング: アプリビジョンをもとに解決すべき業務課題の候補をいくつか提示した上で、基本方針に従ってユーザーの解決したい業務課題を特定する。
- RQ-BK採番: 回答に応じてヒアリングを行い、業務課題を
RQ-BK-* で採番して確定する。
- 業務課題が
RQ-BK-* で採番されて確定するまで、業務機能・画面・外部連携・非機能など個別要件の質問を開始してはならない。
要件定義書の構成
.agents/skills/isdd-common/references/requirements-chapters.md を参照し、全セクションを漏れなく作成すること。
全セクションの内容が確定するまで、各セクションに必要なヒアリングを一問一答で実施してから記述に移ること。
要件網羅性チェック（必須）
要件定義書を作成・修正した後は必ず以下の全項目を確認し、不足があれば指摘・修正すること。
- 業務エンティティを完全に列挙できているか
- 各エンティティに対して定義した表を作成しているか
- マスタ該当エンティティに管理機能が含まれているか
- 以下の機能カテゴリを網羅しているか
- 業務機能 / マスタ管理 / 共通（認証・認可・ログ）/ 運用 / 外部連携
- 各エンティティの状態遷移が定義されているか
- 機能と画面・ユーザーフローの対応が検証されているか
- 「削除可能な要件」を列挙し、削除しても業務が成立する要件を実際に削除しているか
- 残った要件が MVP に必要最低限であることを確認しているか
- 全ての要件項目に
RQ-* IDが付与されているか（IDなし項目がある場合は不足として修正する）
- 全ての
RQ-BK-* に対して対応要件が最低1件あるか
- 全ての非
RQ-BK 要件に対して対応 RQ-BK-* が最低1件あるか
RQ-BK-* に紐づかない要件が存在しないか
外部連携整合チェック（要件出力後・必須）
外部システムとの連携が含まれる場合、docs/requirements.md の初版を出力した後に必ず isdd-external-research を実行し、要件との整合性を確認すること。
isdd-external-research の入力として docs/requirements.md を渡す- 外部仕様との不整合（不足・矛盾・過剰）がある場合は要件定義書を修正する
- 修正後に要件網羅性チェックを再実施する
- 不整合が解消されるまで設計フェーズへ進まない
整合性チェック（必須実行）
要件定義書が完成したら、以下のスクリプトを bash で必ず実行する：
python3 .agents/skills/isdd-common/scripts/rq_integrity_checker.py \
docs/requirements.md
出力:
- フォーマット違反一覧：不正なカテゴリのRQ-* ID
- BKマッピング欠落一覧：対応するRQ-BK-*がない要件
- 孤立BK一覧：対応要件が1件もないRQ-BK-*
- ID重複一覧：同一IDの複数定義
- 検証サマリ：総数、違反数、欠落数
完了ゲート（レビューへ進む前に全て満たすこと）：
ドキュメント作成ルール
.agents/skills/isdd-common/references/document-rules.md のルールに従い、必ず遵守すること。
レビュー（必須）
要件定義書を作成・修正した後は必ず以下のレビューを行い、結果をユーザーに報告すること。
- 内容に矛盾がないか
- 冗長な記述がないか
- 上記の網羅性チェック、ドキュメント作成ルールを全て満たしているか
- 外部連携がある場合、要件出力後に
isdd-external-research を実行し、整合確認結果を反映済みか
- 業務課題（
RQ-BK-*）と要件（RQ-*）の対応が双方向に成立しているか
問題があれば修正してから報告する。問題がなければ完了とし、docs/requirements.md として保存する。
次のステップ
完了を報告する際に、ユーザーに次のスキルを提案する。
- 外部連携がある場合:
isdd-external-research を実行して外部仕様との整合を確認する
- 外部連携がない場合:
isdd-design を実行して詳細設計書を作成する
