影響調査（テスト）作成ルール
Impact Analysis (Test) Rulebook
本ドキュメントは、変更要求がテストへ与える影響を整理するための「影響調査（テスト）」の記述ルールを定義します。プロジェクト関係者が変更要否・影響度・対応方針・未解決事項を同じ粒度で判断できる状態を目標とします。
1. 全体方針
- 対象は「変更要求によるテスト影響の把握と判断」であり、個別テスト手順の詳細設計は扱わない。
- 記載粒度は「テスト責任者とプロジェクト管理者が合意形成できるレベル」とし、影響の有無だけでなく、判断根拠を簡潔に残す。
- 1 ドキュメントで複数のテストレベルを扱ってよいが、影響詳細はテスト対象単位で分割して管理する。
- 仕様変更、I/F 変更、運用変更への波及がある場合は、本書で概要と判断を記載し、詳細は各ドキュメントへ委譲する。
2. 位置づけと用語定義（必要に応じて）
| 用語 | 定義 |
|---|---|
| 変更要求 | プロダクトまたは運用に対する変更の要望。起票済みの要求や課題を含む |
| 影響対象テスト | 変更要求の影響を受けるテスト観点、テスト条件、テストケース、判定基準 |
| 変更要否 | 影響対象に対して変更が必要かどうかの判定 |
| 影響度 | 影響の強さ。品質リスク、検証網羅性、実行コスト、納期影響を踏まえて評価する |
| 対応方針 | 影響に対して採用する対処方針（実施、代替、見送りなど） |
| 未解決事項 | 判断や実施に必要な情報が不足している課題 |
3. ファイル命名・ID規則
- 対象ドキュメント ID は
imp-testとする。 - 対象ドキュメントの推奨ファイル名は
imp-test.mdとする。 idは id-and-file-naming-standard.md の規則に従い、英小文字・数字・ハイフンで構成する。- 関連する追補文書を分割する場合は
imp-test-<term>形式を用いる。
4. 推奨 Frontmatter 項目
影響調査（テスト）ドキュメントでは、document-metadata-standard.md に準拠し、以下を推奨する。
| 項目 | 説明 | 必須 |
|---|---|---|
| id | ドキュメント ID（例: imp-test） | ○ |
| type | project | ○ |
| status | draft / ready / deprecated | ○ |
| rulebook | specdojo:imp-test-rulebook 固定 | ○ |
| part_of | 一覧/親ドキュメントへの所属 ID 配列 | 任意 |
| based_on | 変更要求や根拠資料の ID 配列 | 任意 |
| supersedes | 置き換え対象ドキュメント ID 配列 | 任意 |
5. 本文構成（標準テンプレ）
影響調査（テスト）の本文は、以下の構成を標準とする。
| 章 | 見出し | 必須 | 目的 |
|---|---|---|---|
| 1 | 目的と適用範囲 | ○ | 対象と判断対象範囲を明確化する |
| 2 | 変更要求の概要 | ○ | 変更背景と要求内容を要約する |
| 3 | 影響分析サマリ | ○ | 影響の全体像と優先順位を俯瞰する |
| 4 | 影響詳細一覧 | ○ | 影響対象テストごとの変更要否・影響度を記録する |
| 5 | 対応方針 | ○ | 採用方針、実施条件、担当と期限を整理する |
| 6 | 未解決事項 | ○ | 意思決定待ちや調査不足を明示する |
6. 記述ガイド
6.1. 目的と適用範囲
- 対象変更要求の識別子、対象テスト範囲、対象期間を明記する。
- 「何を判断する文書か」を 2〜4 行で示す。
6.2. 変更要求の概要
- 変更の背景、狙い、成功条件を簡潔に記述する。
- 要求詳細は原文を転記せず、判断に必要な要点のみを要約する。
6.3. 影響分析サマリ
- 高・中・低の影響度で件数を整理し、優先対応対象を明記する。
- サマリで使用した評価観点（例: 欠陥流出リスク、回帰範囲、テスト工数、検証環境影響）を先に示す。
6.4. 影響詳細一覧
- 影響詳細は表形式で記載し、最低限次のカラムを含める。
| カラム | 内容 |
|---|---|
| 影響対象テスト | 影響を受けるテスト対象（レベル、観点、ケース） |
| 変更要否 | 要 / 否 |
| 影響度 | 高 / 中 / 低 |
| 対応方針 | 実施・代替・見送りなどの方針 |
| 判断根拠 | 判定理由の要点 |
| 備考 | 制約、前提、関連ドキュメント |
6.5. 対応方針
- 重要度が高い項目から順に、実施時期、担当、前提条件を記載する。
- 見送りの場合は、再評価条件と時期を必ず記載する。
6.6. 未解決事項
- 各項目に「論点」「不足情報」「決定期限」「担当」を記載する。
- 未解決事項は放置せず、次回レビューでの処理方針を記録する。
7. 禁止事項
実装詳細（SQL 全文、クラス名、API リクエスト構造）を記載しない。
「影響あり」「要対応」のみで根拠を記載しない。
影響度の尺度を定義せずに高・中・低を混在させない。
未解決事項に期限や担当を設定せずに放置しない。
他ドキュメントの本文を重複転記し、参照元との不整合を生む記述をしない。