人員マップの使い方
図1: Webプロジェクト全フェーズの人員配置
以下の表はプロジェクト立ち上げ時のアサイン計画の起点として機能する。 ◎（フル稼働）の役割がそのフェーズのコアチームであり、最初にアサインが必要な人員だ。 ○（部分参加）はフェーズの一部で関与が必要な人員、△（レビュー）は定期的な確認・承認者として関与させる人員を示す。
特に注目してほしいのはDBA・共通チーム・セキュリティ担当の配置だ。 これらは「開発フェーズから呼ぶ」と認識されがちだが、実際には基本設計フェーズからフル稼働が必要になる。
フェーズ別 必要人員マップ
| 役割 | 企画 | 要件定義 | 基本設計 | 詳細設計 | 開発 | テスト | リリース | 運用 |
|---|---|---|---|---|---|---|---|---|
| PM | ◎ | ◎ | ○ | △ | ○ | ○ | ◎ | ○ |
| PMO | ○ | ◎ | ◎ | ○ | ◎ | ○ | ◎ | △ |
| アーキテクト/PL | ○ | ◎ | ◎ | ○ | △ | — | — | — |
| アプリ（FE） | — | ○ | ○ | ◎ | ◎ | ◎ | ○ | △ |
| アプリ（BE） | — | ○ | ○ | ◎ | ◎ | ◎ | ○ | △ |
| インフラ | △ | ○ | ◎ | ◎ | ◎ | ○ | ◎ | ◎ |
| DBA | — | ○ | ◎ | ◎ | ○ | ○ | ◎ | ◎ |
| 共通チーム | — | △ | ◎ | ◎ | ◎ | ○ | ○ | ○ |
| QA | — | △ | ○ | ○ | △ | ◎ | ◎ | △ |
| セキュリティ | △ | ◎ | ○ | ○ | — | ◎ | ◎ | ○ |
読み方のポイント
⚠️ DBA・共通チームは基本設計からフル稼働が必要
DBAが参加するのは「DBを実際に作る詳細設計フェーズから」と考えるプロジェクトが多い。しかしDB方式（RDB/NoSQL選定・DB構成）は基本設計フェーズで確定する。 DBAが不在のまま基本設計が固まると、後から「インデックス設計が成立しない」「テーブル構造を変えられない」という状況になる。
⚠️ セキュリティ担当は要件定義フェーズからフル稼働
認証方式・暗号化要件・監査ログの要件は要件定義フェーズで合意しなければならない。 これらを基本設計以降に持ち込むと、アーキテクチャの根本的な変更を迫られるケースがある。 セキュリティ担当を「テスト前の診断担当」として扱うのは、このマップで最も避けるべき配置だ。
💡 アーキテクト/PLは基本設計以降に稼働が落ちる
アーキテクト/PLは企画・要件定義・基本設計でフル稼働し、詳細設計からは部分参加に移行する。 これは「設計品質のレビュー役」に移るためで、詳細な実装はアプリ担当に委譲する。 ただし設計品質基準の定義と詳細設計レビューはこのフェーズでも必須だ。
アサインの失敗パターン
このマップを使う際によく起きる判断ミスを整理する。「工数を削れる」という誘惑から特定の役割を遅らせたり省いたりするケースが多いが、後工程での手戻りコストは往々にして節約分を超える。
| よくある失敗 | 結果 | 正しい対処 |
|---|---|---|
| DBAを開発フェーズからしか呼ばない | 基本設計で決まったDB構造にインデックスが張れず、全テーブル再設計が発生 | 基本設計フェーズ（◎）から参加させ、データモデルレビューに関与させる |
| セキュリティ担当をテスト前の「診断要員」として扱う | 認証設計の根本的な問題が後から発覚し、大規模な設計変更が必要になる | 要件定義フェーズ（◎）から認証・暗号化要件の確定に関与させる |
| 共通チームの成果物を後回しにする | FE/BEの詳細設計が共通コンポーネント仕様待ちでブロックされる | 基本設計フェーズで共通チームのタスクを最優先とし、他チームより先行させる |
| アーキテクト/PLを詳細設計以降も◎で確保しようとする | アーキテクトの稼働コストが増大し、プロジェクト全体のコスト超過につながる | 詳細設計からは△〜○に移行し、レビュー役として必要なときだけ関与させる |
✅ 次のPARTへ
PART 04から各フェーズの詳細に入る。各フェーズの冒頭には「座組み（誰がどのレベルで参加するか）」を示し、続けて成果物の詳細を整理する。