企画フェーズの成果物と役割

このフェーズの座組み

図1: 企画フェーズの役割・成果物・タスク

フル稼働PM

部分参加PMOアーキテクト

レビュー参加インフラセキュリティ

⚠️ インフラとセキュリティを企画フェーズに巻き込む理由

クラウド vs オンプレの方針、適用すべき法令・規制（GDPR・個人情報保護法等）は企画フェーズで判断しなければならない制約条件だ。これらを後回しにすると、基本設計で「クラウド前提で進めたが、規制上オンプレが必要だった」という根本的な覆しが起きる。

役割	成果物	ポイント
管理PM	プロジェクト憲章、目的・ゴール定義、ステークホルダー一覧・RACI表	ステークホルダー全員の合意署名が必須。特にゴールとスコープの境界を明文化する。
管理PMO	プロジェクト体制図、初期マスタスケジュール（マイルストーン単位）	役割・責任の明文化。誰が意思決定者かを全員に周知する。
技術統括アーキテクト	技術的フィジビリティメモ、概算見積根拠	「作れるか・作れないか」の初期判断を文書化。不確実性の高い技術要素はここで洗い出す。
インフラインフラ	概算インフラコスト試算、クラウド/オンプレ方針メモ	後の基本設計の前提条件になる。コスト感覚の合意も重要。
横断セキュリティ	適用法令・規制の洗い出しメモ（GDPR・個人情報保護法・業界規制等）	コンプライアンス要件は後から変えられない。業界特有の規制は必ず確認する。

💡 プロジェクト憲章はゴールの凍結ではなく合意の記録

プロジェクト憲章は「変えてはいけないもの」ではなく「全員が合意した時点の認識の記録」だ。状況が変わったら更新すればよい。重要なのは「最後に全員が合意した状態」を常に参照できることだ。

💡 「スコープ外」を明記する

プロジェクト憲章には「スコープ内」だけでなく「スコープ外」も明記することを強く推奨する。後から「あの機能も含まれると思っていた」という認識ズレを防ぐ。

企画フェーズは後工程のすべての前提を作るフェーズだ。ここでの合意不足・定義漏れが、基本設計・詳細設計・開発フェーズに入ってから「実はそういう意味ではなかった」という根本的な覆しを引き起こす。代表的な失敗パターンを整理しておく。

失敗パターン	何が起きるか	予防策
ゴールが「売上向上」のような定性表現のみ	進捗の判断ができず、「まだ終わっていない」が永続する	KPIを数値で定義する（例：DAU 1万人・CVR 3%）
スコープ外を明記しない	「あの機能も含まれると思っていた」が多発し追加要求が積み重なる	「スコープ外」セクションを憲章に明示する
ステークホルダーの承認を省略する	後から「聞いてない」「合意した覚えがない」が出てくる	憲章に署名欄を設け、全員の署名を記録する
インフラ・セキュリティを企画フェーズに巻き込まない	設計フェーズで「クラウド前提で進めたが規制上オンプレが必要だった」など根本的な覆しが起きる	企画フェーズにレビュー参加者として招集する
技術的フィジビリティを確認しない	「作れると思っていたが、実は不可能または工数が10倍かかる」が開発中に発覚する	アーキテクトに概算見積・フィジビリティ確認を依頼する

企画フェーズの成果物は「美しいドキュメント」である必要はない。Notion・Confluence・Googleドキュメントの1ページであっても、全員が確認・署名できていれば目的を果たせる。形式よりも「全員が同じ認識を持っている状態」を作ることが重要だ。

✅ 次のPARTへ

プロジェクト憲章を実際に使えるものにするには

プロジェクト憲章が「提出するだけで誰も参照しない」文書になるケースは多い。それを防ぐには、憲章の構成要素を「後工程で参照される場面」から逆算して設計する必要がある。

たとえば「スコープ外の明記」は、要件定義フェーズで新しい要求が上がってきたときに「これは憲章のスコープ外です」と言える根拠として機能する。数値のないゴール定義は、開発フェーズの進捗判断で「どこまでやれば完了か」がわからなくなる原因になる。

RACI表を実務で機能させるコツ

RACI表の最大の落とし穴は「Aが複数いる状態」だ。最終承認者（Accountable）が複数のメンバーに分散していると、フェーズ移行のたびに「誰のOKをもらえばいいか」が不明確になり意思決定が止まる。

実際のプロジェクトでは「承認は合議制で」という運用になりがちだが、合議制には「誰も最終責任を持たない」という構造的な欠陥がある。各成果物のAccountableは必ず一人に絞ることを原則とし、どうしても二人が必要な場合は「最終判断はAだが承認にはBのサインも必要」という形で役割を分離する。