このフェーズの座組み
要件定義フェーズ — 座組み
フル稼働PMPMOアーキテクトセキュリティ
部分参加アプリ（FE）アプリ（BE）インフラDBA
レビュー参加QA
⚠️ 非機能要件の合意はこのフェーズで完結させる
性能（RPS・レスポンスタイム）・可用性（SLA・RTO/RPO）・スケーラビリティ・セキュリティ要件は、アーキテクト・インフラ・DBA・セキュリティ全員の合意が必要だ。このフェーズで合意できなかった非機能要件は後のフェーズで根本的なアーキテクチャの見直しを引き起こす。
成果物マトリクス
| 役割 | 成果物 | ポイント |
|---|---|---|
| 管理PM | 業務要件定義書、ユースケース一覧、業務フロー図 | ビジネス側との合意が核心。要件の優先度（MoSCoW等）も明記する。 |
| 管理PMO | 課題管理台帳、要件変更管理プロセス定義 | 変更管理の仕組みはここで作らないと後で機能しない。要件変更の承認フローを明文化する。 |
| 技術統括アーキテクト | 非機能要件定義書（性能・可用性・拡張性・RTO/RPO・データ保持期間） | 後工程の設計制約になる最重要文書。全員の合意署名を取る。 |
| アプリFE | 画面要件一覧、ラフワイヤーフレーム | ユーザー動線の整理。デザイナーがいれば協働する。UXの観点も含める。 |
| アプリBE | 機能要件一覧、外部インターフェース要件 | 連携先システムの洗い出しを早めに。インターフェース仕様の合意が遅れると設計が止まる。 |
| インフラインフラ | 非機能要件へのインフラ観点コメント、SLA要件確認記録 | 可用性要件（マルチAZ・DR等）は構成コストに直結する。コストとのトレードオフを明示する。 |
| データDBA | データ要件定義（主要エンティティ洗い出し）、データ量・更新頻度の見積もり | 業務データの棚卸し。データ量の見積もりはDB選定とインフラ設計に影響する。 |
| 横断QA | テスト方針書（初版）、受入基準の大枠 | テスト種別・範囲・受入基準はここで合意しておく。後から追加すると工数が跳ね上がる。 |
| 横断セキュリティ | 脅威モデリング結果、セキュリティ要件定義（認証方式・暗号化・監査ログ要件） | 認証方式の決定（OAuth2/SAML等）はアーキテクチャに深く関わる。早期合意が必須。 |
非機能要件定義書の重要性
非機能要件定義書は、後工程の設計制約の根拠文書だ。以下の項目を必ず含めること。
| 項目 | 記載すべき内容 | 使われるフェーズ |
|---|---|---|
| 性能要件 | 最大同時接続数、ピークRPS、許容レスポンスタイム（95%ile） | 基本設計・性能テスト |
| 可用性要件 | SLA（99.9%等）、RTO（目標復旧時間）、RPO（目標復旧時点） | 基本設計（DR構成） |
| スケーラビリティ | 将来のユーザー数・データ量の上限想定 | 基本設計（スケール設計） |
| セキュリティ | 認証方式・暗号化要件・監査ログ保持期間 | 基本設計・セキュリティ診断 |
| 保守性 | デプロイ頻度・ダウンタイム許容値 | インフラ設計・CI/CD設計 |
変更管理プロセスの設置
💡 変更管理プロセスはPMOが要件定義フェーズで設置する
要件変更の承認フロー（誰が申請し・誰がレビューし・誰が承認するか）を要件定義フェーズで確立しなければならない。開発フェーズに入ってから「ちょっとした変更」が積み重なるスコープクリープは、変更管理プロセスの不在から生まれる。
✅ 次のPARTへ