要件定義フェーズのドキュメント定義

ドキュメント定義マトリクス

ドキュメント	何を定義するか	誰が使うか	変更コスト	最重要度
非機能要件定義書	性能（RPS・レスポンスタイム）・可用性（SLA・RTO/RPO）・スケーラビリティ・セキュリティ要件・保守性	全設計チーム（アーキテクト・インフラ・DBA・セキュリティ）・QA	高	◎ 最重要
業務要件定義書	ビジネス側が期待する機能・業務フロー・ユーザーシナリオ・優先度（MoSCoW）	全開発チーム・QA・ビジネス側	高	◎ 最重要
変更管理プロセス定義	要件変更の申請フロー・影響評価プロセス・承認者・記録方法	PM・PMO・全チーム	高	◎ 最重要
ユースケース一覧	アクター（ユーザー種別）と機能の対応関係	FE・BE・QA	中	○ 重要
セキュリティ要件定義	認証方式・暗号化要件・監査ログ保持期間・脅威モデリング結果	セキュリティ・アーキテクト・FE・BE	高	○ 重要
データ要件定義	主要エンティティ・データ量・更新頻度・保持期間	DBA・BE・インフラ	中	○ 重要
テスト方針書（初版）	テスト種別・範囲・受入基準の大枠・テスト環境要件	QA・PM・ビジネス側	中	○ 重要
課題管理台帳	未解決課題の記録と対応状況	PMO・PM	低	△ 記録

何を定義するか：機能要件と並んで、システムの「品質特性」を数値で確定させる。性能要件（ピーク時の同時接続数・95パーセンタイルのレスポンスタイム）、可用性要件（稼働率・RTO・RPO）、スケーラビリティ（将来のユーザー数・データ量の上限想定）。

形骸化した場合の影響：設計者が自分の判断で性能・可用性の水準を設定してしまう。後から「その水準では足りない」が発覚しアーキテクチャの再設計が必要になる。

⚠️ 「できるだけ速く・できるだけ止まらない」は要件ではない

数値のない非機能要件定義書は無効だ。「レスポンス1秒以内（95パーセンタイル・ピーク500RPS時）」「月次稼働率99.9%・RTO4時間・RPO1時間」のように具体的な数値と条件を明記する。数値がないと設計者・テスターが判断できない。

何を定義するか：ビジネス側が期待する「システムが実現すべき価値」。機能一覧ではなく、誰が・何のために・どのように使うかというユーザー視点で記述する。優先度（Must/Should/Could/Won't）も明記する。

形骸化した場合の影響：開発チームが「技術的に実装しやすいもの」を作り、ビジネス側が「使いたかったもの」と乖離する。UATで初めて乖離が発覚し、全機能の見直しが必要になる。

何を定義するか：要件変更が発生した際の「申請→影響評価→承認→実施→記録」の全フロー。誰が申請でき、誰がレビューし、誰が最終承認するかを明文化する。

⚠️ 変更管理プロセスを持たないプロジェクトはスコープクリープで必ず苦しむ

「ちょっとした変更のつもり」が積み重なり、開発フェーズ中盤で工数が跳ね上がるパターンは定番の失敗だ。変更管理プロセスは要件定義フェーズで設置しないと、開発フェーズに入ってからでは機能しない。「プロセスを後で作る」は機能しない。

項目	定義すべき内容	後工程での使われ方
性能要件	ピーク時RPS・95%ile レスポンスタイム・スループット	基本設計でのスケール設計・テストフェーズの負荷テスト基準
可用性要件	月次稼働率（SLA）・RTO・RPO	インフラの冗長化方針・DR設計・バックアップ設計
スケーラビリティ	現在・1年後・3年後のユーザー数・データ量上限	DB設計・インフラ設計・コスト試算
セキュリティ	認証方式・暗号化要件・監査ログ保持期間・データ分類	基本設計の認証設計・セキュリティテストの基準
保守性	デプロイ頻度・ダウンタイム許容値・監視要件	CI/CD設計・監視設計・Runbook設計
法令・コンプライアンス	個人情報保護・GDPR・業界規制への対応要件	認証設計・ログ設計・データ保持ポリシー

✅ 次のPARTへ