このフェーズの座組み
図1: 要件定義フェーズの役割・成果物・タスク
要件定義フェーズ — 座組み
フル稼働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が要件定義フェーズで設置する
要件変更の承認フロー（誰が申請し・誰がレビューし・誰が承認するか）を要件定義フェーズで確立しなければならない。開発フェーズに入ってから「ちょっとした変更」が積み重なるスコープクリープは、変更管理プロセスの不在から生まれる。
| 変更管理の要素 | 定義すべき内容 |
|---|---|
| 変更要求の提出方法 | Issueトラッカー・専用フォーム・会議体での口頭申請など、チャネルを一本化する |
| 影響評価の基準 | 工数・スケジュール・スコープ・コストへの影響度をどう評価するか |
| 承認権限 | どのクラスの変更をPMが承認し、どのクラスをステアリングコミッティに上げるか |
| 緊急変更のルール | 本番障害対応などの緊急時でも事後記録は必須とする、など例外ルールも明文化する |
要件定義フェーズでよくある失敗パターン
要件定義は後工程すべての土台になる。ここでの抜け漏れは後フェーズで複利的にコストが膨らむ。
| 失敗パターン | 何が起きるか | 防止策 |
|---|---|---|
| 非機能要件を後回しにする | 「マルチAZ必須」が基本設計完了後に判明し、アーキテクチャを再設計する羽目になる | 要件定義フェーズ開始時にインフラを参加させ、性能・可用性・DR要件を同時に定義する |
| ユーザーストーリーが主語不在で書かれる | 「〜できること」という書き方で誰向けの機能か不明確になり、実装後に「想定ユーザーが違う」と判明する | 「〇〇ユーザーが〜できる」形式を徹底し、ユーザー種別を先に列挙してから要件を書く |
| 承認を口頭だけで済ませる | フェーズ後半で「そんな要件は合意していない」という認識ズレが発生し、スコープ交渉が再燃する | 各要件定義書に承認欄を設け、書面（またはIssueのClose記録）で合意証跡を残す |
| 変更管理プロセスを定義しない | 開発中盤で要件変更が口頭で発生し、設計書と実装が乖離したまま進む | 要件定義フェーズ中に変更管理プロセス（申請方法・影響評価・承認権限）を文書化する |
✅ 次のPARTへ