まとめ — 最重要ドキュメント早見表

◎最重要ドキュメント横断早見表

全8フェーズを通じて◎ 最重要と判定されたドキュメントの一覧だ。変更コストが高かつ後工程依存度が広いものがここに並ぶ。

フェーズ	◎最重要ドキュメント	定義の核心	主な後工程参照者
企画	プロジェクト憲章	ゴール・スコープ内外・制約・成功基準	全フェーズ・全チーム
企画	ステークホルダー一覧・RACI表	意思決定者・承認者・責任分担	PM・PMO・全フェーズ
要件定義	非機能要件定義書	性能・可用性・RTO/RPO・セキュリティ要件（数値で）	全設計チーム・QA
	業務要件定義書	機能・業務フロー・優先度（MoSCoW）	全開発チーム・QA・ビジネス側
	変更管理プロセス定義	変更要求の申請〜承認フロー全体	PM・PMO・全チーム
基本設計	システム方式設計書	技術スタック・アーキテクチャパターン・通信方式	全チーム
	認証・認可設計	認証方式・権限モデル・セッション管理	FE・BE・インフラ・セキュリティ
	論理データモデル（ER図）	エンティティ・関係・DB選定根拠	DBA・BE・共通チーム
	APIゲートウェイ設計方針	ルーティング・共通認証・統一レスポンスフォーマット	FE・BE全員
詳細設計	詳細API仕様書（OpenAPI）	エンドポイント・スキーマ・エラーコード・認証要件	FE・BE・QA
	物理データモデル・DDL	テーブル定義・型・制約・デフォルト値	BE・DBA
	インデックス設計書	インデックス一覧と対応クエリパターン根拠	DBA・BE
	共通コンポーネント仕様書	共通ライブラリのIF・制約・バージョン	FE・BE全員
開発	変更管理記録	全変更要求の内容・影響評価・承認証跡	PM・PMO・監査
テスト	受入合意書（UAT）	ビジネス側の正式受け入れ合意と署名	PM・リリース判定・監査
テスト	脆弱性診断報告書・対応記録	脆弱性一覧・重大度・対応状況・再診断結果	PM・セキュリティ・リリース判定
リリース	リリース判定書（Go/No-Go）	判定基準・達成状況・承認者署名	PM・全チーム・監査
	データ移行手順書・整合性確認手順	移行ステップ・確認SQL・リハーサル結果	DBA・PMO・作業者
	ロールバック手順書	判断基準・切り戻し手順・タイムアウト設定	PM・インフラ・DBA・アプリ
運用	Runbook（障害対応手順書）	アラート別対応手順・エスカレーション・復旧手順	運用チーム（アプリチーム不在でも）
運用	運用移管完了報告	引き継ぎ内容一覧・未解決課題・双方署名	PM・PMO・運用チーム・監査

フェーズをまたぐ依存関係

◎最重要ドキュメントは独立して存在するのではなく、後続フェーズのドキュメントへの入力として連鎖する。

起点ドキュメント		依存する後続ドキュメント
非機能要件定義書	→	システム方式設計書・インフラ構成図・負荷テスト計画書・リリース判定基準
認証・認可設計	→	詳細API仕様書（認証フィールド）・セキュリティ診断基準・Runbook（認証障害対応）
論理データモデル	→	物理データモデル・DDL・インデックス設計・データ移行手順書
詳細API仕様書	→	FE実装コード・BE実装コード・結合テストケース
受入合意書	→	リリース判定書（前提ドキュメントとして参照）
Runbook	→	運用移管完了報告（引き継ぎドキュメントの一つ）

形骸化防止チェックリスト

合意・署名の確認

プロジェクト憲章にステークホルダー全員の署名があるか

非機能要件定義書に全設計チームの合意署名があるか

受入合意書にビジネス側責任者の署名があるか

リリース判定書に最終承認者の署名があるか

運用移管完了報告に双方の署名があるか

版管理の確認

API仕様書（OpenAPI）はGit管理されており最新版が一か所か

DDLとアプリコードのDB定義が一致しているか

Runbookは最後の障害後に更新されているか

変更管理記録は最新の変更まで記録されているか

数値の確認

非機能要件に具体的な数値が記載されているか（「できるだけ速く」はNG）

インデックス設計書に対応クエリパターンの根拠があるか

リリース判定のGo/No-Go基準が数値で定義されているか

SLA要件が稼働率・RTO・RPOの数値で定義されているか

実態との一致

認証設計の内容がFE・BE実装と一致しているか

データ移行手順書のリハーサルを実施済みか

ロールバック手順書のドライランを実施済みか

Runbookの手順を運用チームが実際に追えるか

プロジェクト立ち上げ時の確認項目

⚠️ ◎ドキュメントのオーナーが全員決まっているか

プロジェクト開始時に「この◎ドキュメントを誰が作り・誰がレビューし・誰が承認するか」をRACIで確定させる。フェーズが始まってから「これ誰が作るんですか」という状況になるのは、アサイン計画の失敗だ。

確認項目	確認タイミング
全◎ドキュメントのオーナー（Responsible）が決まっているか	プロジェクト憲章合意時
全◎ドキュメントの最終承認者（Accountable）が決まっているか	RACI表作成時
各フェーズの◎ドキュメント完成がフェーズゲートの条件になっているか	WBS作成時
基本設計の◎4本（方式設計・認証・ER図・ゲートウェイ）が詳細設計開始前に完成する計画か	マスタスケジュール作成時
リリース判定書にRunbook完成を前提条件として含めているか	リリース計画作成時

シリーズ全記事一覧

成果物の定義すべき事項 — 全10回

✅ 姉妹シリーズ

「各フェーズで誰が・何を作るか」の役割分担を知りたい場合は「各フェーズでの成果物と役割」シリーズ（全13回）を参照してほしい。本シリーズと組み合わせることで、ドキュメントの「作り手」と「定義すべき内容」を両面から把握できる。

◎最重要ドキュメント 横断早見表