ドキュメント定義マトリクス
| ドキュメント | 何を定義するか | 誰が使うか | 変更コスト | 最重要度 |
|---|---|---|---|---|
| 受入合意書（UAT） | ビジネス側がシステムを「受け入れる」という署名付きの正式合意 | PM・リリース判定会議・監査 | 高 | ◎ 最重要 |
| 脆弱性診断報告書・対応記録 | 発見された脆弱性の一覧・重大度・対応方針・対応後の再確認結果 | PM・セキュリティ・リリース判定・監査 | 高 | ◎ 最重要 |
| 負荷テスト計画書・結果・ボトルネック分析 | テストシナリオ・実施結果・ボトルネック箇所・対応内容 | インフラ・DBA・PM・リリース判定 | 中 | ○ 重要 |
| システムテスト仕様書・実施記録 | テストケースと実施結果・要件との照合証拠 | QA・PM・ビジネス側 | 中 | ○ 重要 |
| 結合テスト仕様書・実施記録 | API境界・外部システム連携の検証証拠 | QA・アプリ担当 | 低 | △ 記録 |
| 単体テスト結果・カバレッジレポート | 実装品質の計測記録 | 開発者・QA | 低 | △ 記録 |
| 不具合管理票 | 発見された不具合・重大度・対応状況・クローズ根拠 | QA・開発者・PM | 低 | △ 記録 |
◎最重要ドキュメントの詳細
受入合意書（UAT）
何を定義するか：「ビジネス側がこのシステムの受け入れに同意する」という正式な合意の記録。テストした機能の範囲・確認した受入基準・合意した日付・ビジネス側責任者の署名が含まれる。
なぜ変更コストが高いか：受入合意書のないリリースは「ビジネス側が承認していない状態でのリリース」を意味する。後から「そのシステムは受け入れていない」と言われた場合に対抗する根拠がない。また、署名なしの受入合意書は法的・監査的な証拠として機能しない。
⚠️ 受入合意書はQAではなくPMが主導して取得する
UATはビジネス側がシステムを受け入れるかどうかの判断プロセスだ。技術的なテスト合否ではなく「業務に使えるか」の確認なので、PMが主導してビジネス側責任者を巻き込み、署名付きの受入合意書を取得する。QAに任せると「技術テストは合格した」という報告で終わり、ビジネス側の合意が形式化されないリスクがある。
脆弱性診断報告書・対応記録
何を定義するか：セキュリティ診断で発見された脆弱性の一覧（CVE/OWASP分類）・重大度評価（Critical/High/Medium/Low）・各脆弱性の対応方針・対応後の再診断結果・残存リスクの受け入れ判断記録。
形骸化した場合の影響：重大度Highの脆弱性が「対応中」のまま本番にリリースされるケースがある。対応記録がないと「どの脆弱性に対応済みか」が追跡できず、次回の診断で同じ指摘を繰り返す。
テスト結果エビデンスと◎の違い
| 種類 | 目的 | 使われ方 | 最重要度 |
|---|---|---|---|
| 受入合意書 | ビジネス側の正式合意の証明 | リリース判定の法的・組織的根拠 | ◎ |
| 脆弱性診断報告書 | セキュリティリスクの把握と対応の証明 | リリース可否の判断根拠・監査証跡 | ◎ |
| 負荷テスト結果 | 性能要件達成の証明 | 非機能要件定義書との照合・リリース判断材料 | ○ |
| システムテスト記録 | 機能要件充足の証明 | 要件定義書との照合証拠 | ○ |
| 単体テスト結果 | 実装品質の計測記録 | 内部品質の参考指標 | △ |
💡 ◎は「なければリリースを止める」根拠になるドキュメント
受入合意書と脆弱性診断報告書は、これがなければリリースを止めることが正当化できる文書だ。単体テスト結果が揃っていなくてもリリースは止まらないが、受入合意書がなければリリースのGo判定を出すべきではない。この違いが◎と△の本質的な差だ。
✅ 次のPARTへ