人員マップの使い方
以下の表はプロジェクト立ち上げ時のアサイン計画の起点として機能する。 ◎（フル稼働）の役割がそのフェーズのコアチームであり、最初にアサインが必要な人員だ。 ○（部分参加）はフェーズの一部で関与が必要な人員、△（レビュー）は定期的な確認・承認者として関与させる人員を示す。
特に注目してほしいのはDBA・共通チーム・セキュリティ担当の配置だ。 これらは「開発フェーズから呼ぶ」と認識されがちだが、実際には基本設計フェーズからフル稼働が必要になる。
フェーズ別 必要人員マップ
| 役割 | 企画 | 要件定義 | 基本設計 | 詳細設計 | 開発 | テスト | リリース | 運用 |
|---|---|---|---|---|---|---|---|---|
| PM | ◎ | ◎ | ○ | △ | ○ | ○ | ◎ | ○ |
| PMO | ○ | ◎ | ◎ | ○ | ◎ | ○ | ◎ | △ |
| アーキテクト/PL | ○ | ◎ | ◎ | ○ | △ | — | — | — |
| アプリ（FE） | — | ○ | ○ | ◎ | ◎ | ◎ | ○ | △ |
| アプリ（BE） | — | ○ | ○ | ◎ | ◎ | ◎ | ○ | △ |
| インフラ | △ | ○ | ◎ | ◎ | ◎ | ○ | ◎ | ◎ |
| DBA | — | ○ | ◎ | ◎ | ○ | ○ | ◎ | ◎ |
| 共通チーム | — | △ | ◎ | ◎ | ◎ | ○ | ○ | ○ |
| QA | — | △ | ○ | ○ | △ | ◎ | ◎ | △ |
| セキュリティ | △ | ◎ | ○ | ○ | — | ◎ | ◎ | ○ |
読み方のポイント
⚠️ DBA・共通チームは基本設計からフル稼働が必要
DBAが参加するのは「DBを実際に作る詳細設計フェーズから」と考えるプロジェクトが多い。しかしDB方式（RDB/NoSQL選定・DB構成）は基本設計フェーズで確定する。 DBAが不在のまま基本設計が固まると、後から「インデックス設計が成立しない」「テーブル構造を変えられない」という状況になる。
⚠️ セキュリティ担当は要件定義フェーズからフル稼働
認証方式・暗号化要件・監査ログの要件は要件定義フェーズで合意しなければならない。 これらを基本設計以降に持ち込むと、アーキテクチャの根本的な変更を迫られるケースがある。 セキュリティ担当を「テスト前の診断担当」として扱うのは、このマップで最も避けるべき配置だ。
💡 アーキテクト/PLは基本設計以降に稼働が落ちる
アーキテクト/PLは企画・要件定義・基本設計でフル稼働し、詳細設計からは部分参加に移行する。 これは「設計品質のレビュー役」に移るためで、詳細な実装はアプリ担当に委譲する。 ただし設計品質基準の定義と詳細設計レビューはこのフェーズでも必須だ。
✅ 次のPARTへ
PART 04から各フェーズの詳細に入る。各フェーズの冒頭には「座組み（誰がどのレベルで参加するか）」を示し、続けて成果物の詳細を整理する。