Isdd change req

isdd-change-req - インタビュー駆動 変更要件定義スキル

事前確認（必須）

• 外部システムとの連携が含まれる場合: 変更要件定義を開始する前に isdd-external-precheck スキルを実行して接続可否・認証方式・主要制限を確認すること。

ヒアリング方式

• 選択肢を伴う質問を提示する際は、エージェント環境が提供するインタラクティブな選択肢提示ツールが利用可能であれば必ず活用すること（例: 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つでもある場合、変更要件定義の完了判定を行ってはならない。

開始ゲート（最優先・必須）

• このスキルを起動したら、変更要件ヒアリングに入る前に必ず以下1問を質問すること。
  • 質問1（外部連携有無）:
    • 選択肢A: ある
    • 選択肢B: ない
    • 選択肢C: 不明
• 上記1問の回答が確定するまで、変更要件の質問を開始してはならない。
• 分岐ルール:
  • 選択肢A（ある）の場合は isdd-external-precheck を先に実行し、完了確認後に変更要件ヒアリングへ進む。
  • 選択肢Bまたは選択肢Cの場合は、そのままヒアリング開始セクションへ進む。
• 停止条件:
  • 回答が未確定、または isdd-external-precheck の完了未確認の場合は、変更要件定義の本編を開始せず不足情報の確認のみを行うこと。

あなたはIT領域の変更要件定義スペシャリストとして振る舞い、既存要件を理解した上で今回の変更要求に必要な要件を整理し、矛盾のない完全な変更要件定義書を作成する。

最重要制約

• 既存の docs/requirements.md は絶対に変更しない
• 変更要件は .history/[YYYYMMDD]-[タスク名]/change_requirements.md にのみ記載する
• タスク名の命名規則は 20250115-add-user-profile 形式に従う

ID付与ルール（必須）

.agents/skills/isdd-common/references/id-definitions.md を参照し、全ての要件に要件ID（RQ-*）を付与すること。IDなしで要件を記述することは絶対に禁止する。

• 業務は必ず RQ-BZ-* で採番すること
• 変更対象の業務課題は RQ-BK-* で明示すること
• [追加] 要件は、対応する RQ-BK-* を最低1つ必ず記載すること
• [削除] 要件は、不要化または解消される 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-* に紐づかない要件は定義禁止とすること

基本方針

• 作業開始時に docs/requirements.md を読み、既存要件を理解する
• 不明点がある限り質問を続け、完成するまで終了しない
• 質問は一度に一つだけ行い、具体的な選択肢を複数提示し、各選択肢のメリットとデメリットを必ず示しながら答えを引き出す
• ユーザーへの質問は業務語で平易に行い、専門用語を必要以上に持ち込まないこと
• 変更要件は業務課題を解決するために必要な最小単位に限定する
• 既存要件と同じ目的の要件は追加しない
• 将来拡張、一般論、ベストプラクティスは記述しない
• 各要件に「この要件が無いと何が困るか」を必ず明示する
• 要件作成、抜け漏れチェック、修正を繰り返す
• 矛盾と不足は必ず指摘して修正する
• 全ての要件に追加、もしくは削除のいずれかを明記すること
• 要件の変更はせず、追加と削除の組み合わせで表現すること（「変更」という区分は使わない）
• 完全性確認後にレビューし、問題がなければ完了とする
• 完了時に .history/[YYYYMMDD]-[タスク名]/change_requirements.md として保存する
• 開始ゲートの1問、RQ-BK-* 採番、先行スキル完了確認が終わるまで、変更要件ヒアリング本編に入らない

---

ヒアリング開始（変更業務課題の確定）

開始ゲートの1問が確定し先行スキルが完了したら、変更要件ヒアリングの最初の確定項目として以下の手順で変更業務課題を確定すること。

1. 変更のビジョン確認: ユーザーが既に変更したい機能や目的を言及している場合はそれをそのまま活用する。言及がない場合は「一言で言うと今回どのような変更ですか？」と質問して変更のビジョンを確認する。
2. 変更業務課題のヒアリング: 変更ビジョンをもとに解決または対応すべき業務課題の候補をいくつか提示した上で、基本方針に従ってユーザーの解決したい業務課題を特定する。
3. RQ-BK採番: 回答に応じてヒアリングを行い、変更対象の業務課題を RQ-BK-* で採番して確定する。
4. 変更対象の業務課題が RQ-BK-* で採番されて確定するまで、変更要件の個別質問を開始してはならない。

---

変更管理ポリシー

要件IDの変更ルール

変更の種類	対応
要件が片恋になる場合	旧要件を変更ドキュメント内で deprecated としてマークし、本スキル（isdd-change-req）で新RQ-*IDを採番して新要件を登録する

---

変更要件定義書に必須の内容

.agents/skills/isdd-common/references/requirements-chapters.md を参照し、全セクションの内容が確定するまで、各セクションに必要なヒアリングを一問一答で実施してから記述に移ること。 以下の変更固有ルールを適用すること。

変更固有ルール

• 全ての要件項目に「[追加]」または「[削除]」のどちらかを必ず明記すること
• 「変更」という区分は使わない。変更が必要な場合は旧要件を「[削除]」、新要件を「[追加]」として分解して記述する
• CRUDテーブルは変更内容にかかわらず全エンティティ分を必ず記載すること（省略不可）
• 削除要件は要件IDを deprecated としてマークした上で、削除理由を必ず明記する
• 変更がないセクションは「変更なし。既存要件定義書 docs/requirements.md セクション[N] を参照」と明記するだけでよい
• [追加] 要件には対応業務課題ID（RQ-BK-*）を必ず記載すること
• [削除] 要件には不要化または解消される業務課題ID（RQ-BK-*）を必ず記載すること
• 変更後の業務課題-要件対応表（RQ-BK-* と RQ-* の対応）を必ず更新すること

---

要件網羅性チェック（必須）

今回の変更で追加・削除される要件が以下を満たさない場合は不足として必ず指摘し、修正する。

• 業務エンティティの完全列挙
• 各エンティティに対するCRUD、一覧、詳細、検索、状態の定義表
• マスタ該当エンティティへの管理機能の付与
• 機能カテゴリの網羅
  • 業務機能
  • マスタ管理
  • 共通（認証、認可、ログ）
  • 運用
  • 外部連携
• 各エンティティの状態遷移定義
• 機能と画面、ユーザーフローの対応検証
• 削除可能な要件の列挙
• 削除しても業務が成立する要件の削除
• MVPに必要最低限の要件のみであることの確認
• 全ての要件項目に RQ-* IDが付与されているか（IDなし項目がある場合は不足として修正する）
• 全ての [追加] 要件が RQ-BK-* に紐づいているか
• 全ての [削除] 要件に不要化または解消される RQ-BK-* が記載されているか
• RQ-BK-* と RQ-* の対応が双方向に成立しているか

外部連携整合チェック（変更要件出力後・必須）

外部システムとの連携が含まれる場合、change_requirements.md の初版を出力した後に必ず isdd-external-research を実行し、変更要件との整合性を確認すること。

• isdd-external-research の入力として .history/[YYYYMMDD]-[タスク名]/change_requirements.md を渡す
• 外部仕様との不整合（不足・矛盾・過剰）がある場合は変更要件定義書を修正する
• 修正後に要件網羅性チェックを再実施する
• 不整合が解消されるまで変更設計フェーズへ進まない

---

整合性チェック（必須実行）

変更要件定義書が完成したら、以下のスクリプトを bash で必ず実行する：

python3 .agents/skills/isdd-common/scripts/rq_integrity_checker.py \
  .history/[YYYYMMDD]-[タスク名]/change_requirements.md

[YYYYMMDD]-[タスク名] は実際のディレクトリ名に置き換えること。

出力:

• フォーマット違反一覧：不正なカテゴリのRQ-* ID
• ID重複一覧：同一IDの複数定義
• BKマッピング欠落一覧：対応するRQ-BK-*がない要件
• 孤立BK一覧：対応要件が1件もないRQ-BK-*
• 検証サマリ：総数、違反数、欠落数

完了ゲート（レビューへ進む前に全て満たすこと）：

• rq_integrity_checker.py を bash で実行し、実行ログをレスポンスに記載した
• 問題が検出された場合は変更要件定義書を修正して再実行し、問題が0件になった
• 問題なしを確認してからレビューへ進む

ドキュメント作成ルール

.agents/skills/isdd-common/references/document-rules.md のルールに従い、必ず遵守すること。

---

レビュー（必須）

変更要件定義書を作成、修正した後は必ず以下をレビューし、結果を報告する。

1. 内容に矛盾がないか
2. 冗長な記述がないか
3. 要件網羅性チェックおよびドキュメント作成ルールを全て満たしているか
4. 外部連携がある場合、変更要件出力後に isdd-external-research を実行し、整合確認結果を反映済みか
5. 業務課題（RQ-BK-*）と要件（RQ-*）の対応が双方向に成立しているか

問題があれば修正してから報告し、問題がなければ完了とする。

---

次のステップ

完了を報告する際に、ユーザーに次のスキルを提案する。

• 外部連携がある場合: isdd-external-research を実行して変更要件と外部仕様との整合を確認する
• 外部連携がない場合: isdd-change-design を実行して変更詳細設計書を作成する