ドキュメント定義マトリクス
図1: 企画フェーズの成果物・担当・更新タイミング
| ドキュメント | 何を定義するか | 誰が使うか | 変更コスト | 最重要度 |
|---|---|---|---|---|
| プロジェクト憲章 | ゴール・スコープ（内外）・制約・前提条件・成功基準 | 全フェーズ・全チーム・ステークホルダー | 高 | ◎ 最重要 |
| ステークホルダー一覧・RACI表 | 誰が意思決定者か・誰に何の責任があるか | PM・PMO・全フェーズ | 高 | ◎ 最重要 |
| プロジェクト体制図 | チーム構成・報告ライン・役割割り当て | PMO・全チームリード | 中 | ○ 重要 |
| 概算インフラコスト試算 | 予算上限の根拠・クラウド/オンプレ方針の財務的根拠 | PM・インフラ・経営層 | 中 | ○ 重要 |
| 適用法令・規制メモ | どの法律・規制・業界標準がこのシステムに適用されるか | セキュリティ・アーキテクト・PM | 高 | ○ 重要 |
| 技術的フィジビリティメモ | 技術的に実現可能かどうかの根拠・不確実要素の洗い出し | アーキテクト・PM | 低 | △ 記録 |
| 初期マスタスケジュール | マイルストーンと期限の大枠 | PM・PMO | 低 | △ 記録 |
◎最重要ドキュメントの詳細
プロジェクト憲章
何を定義するか：ゴール（何を達成するか）・スコープ内（何を作るか）・スコープ外（何を作らないか）・制約（予算・期間・技術）・前提条件・成功基準。
なぜ変更コストが高いか：すべての後工程はこの文書を前提として進む。スコープが変わると要件定義からやり直しになる。特に「スコープ外」の明記がないと「含まれると思っていた」が後工程で発生する。
⚠️ 「スコープ外」を明記しないプロジェクト憲章は半分しか機能しない
多くのプロジェクト憲章は「スコープ内」しか書かない。後工程で「あの機能も含まれると思っていた」という認識ズレを防ぐには、スコープ外の明示が不可欠だ。「既存システムとのデータ移行は含まない」「モバイルアプリは含まない」といった記載が後のスコープクリープを防ぐ。
ステークホルダー一覧・RACI表
何を定義するか：誰が最終意思決定者か（Accountable）・誰が実行責任者か（Responsible）・誰に相談するか（Consulted）・誰に通知するか（Informed）。
なぜ変更コストが高いか：意思決定者が曖昧なプロジェクトは、フェーズ移行のたびに承認待ちが発生し進行が止まる。また「その決定は自分が関与すべきだった」という後からの介入を招く。
💡 RACI表で特に重要なのは「A（最終承認者）」の明確化
各主要成果物（要件定義書・基本設計書・リリース判定書等）について「誰がAccountableか（最終的にOKを出す人）」を企画フェーズで明確にしておく。これがないと意思決定が遅延しプロジェクト全体が止まる。
注意ポイント
適用法令・規制メモは変更コストが高いが記録として△にしていない理由：法令の見落としはアーキテクチャレベルの設計変更を引き起こすため○に分類する。「あとで確認」は禁物で、企画フェーズで確定させる必要がある。
| 失敗パターン | 具体的な影響 | 防止策 |
|---|---|---|
| プロジェクト憲章のスコープ外を書かない | 「あの機能も含まれると思っていた」が後工程で頻発し、スコープクリープが止まらなくなる | 「含まない」リストを憲章内に明記し、全ステークホルダーの署名を得る |
| RACI表の「A（最終承認者）」が複数いる | 最終意思決定が遅延し、フェーズ移行のたびに承認待ちが発生する | 各成果物のAccountableは必ず一人に絞る |
| 概算コスト試算を後回しにする | 基本設計完了後に「予算超過」が発覚し、アーキテクチャを再検討するコストが発生 | 企画フェーズでざっくりとした規模感を出し、予算の上限と照合する |
| 適用法令の確認を後回しにする | 開発後半でGDPRや個人情報保護法の対応が発覚し、認証・暗号化・ログ設計を大幅変更することになる | 企画フェーズでセキュリティ担当が法令メモを作成し、アーキテクトが設計に反映する |
✅ 次のPARTへ