フェーズの定義
本シリーズでは以下の8フェーズを対象とする。フェーズの境界は明確に引けないケースも多いが、成果物の責任を明確にするために区切りとして定義する。
| フェーズ | 概要 | 主な意思決定 |
|---|---|---|
| 企画 | プロジェクトの目的・ゴール・スコープを定義する | 「何のために作るか」の合意 |
| 要件定義 | 「何を作るか」をビジネス側と合意する | 機能要件・非機能要件の確定 |
| 基本設計 | システムの骨格・方式・アーキテクチャを決める | 技術選定・システム構成の確定 |
| 詳細設計 | 実装できるレベルまで仕様を落とし込む | API仕様・DB物理設計・画面仕様の確定 |
| 開発 | 動くシステムを構築する | 実装方針・ブランチ戦略の運用 |
| テスト | 品質を多層的に検証・証明する | 受入基準の達成確認 |
| リリース/移行 | 安全に本番環境へ届ける | Go/No-Go判定・データ移行の承認 |
| 運用 | 安定稼働を維持し改善し続ける | SLAの継続管理・改善施策の優先度決定 |
役割の定義
本シリーズで登場する役割とその主な責務を定義する。プロジェクト規模によってはひとりが複数の役割を兼ねることもある。
| 区分 | 役割 | 主な責務 |
|---|---|---|
| 管理 | PM | ゴール・スコープ・スケジュール・コストの管理。ステークホルダーとの合意形成の責任者。 |
| 管理 | PMO | WBS・リスク・課題・変更管理のプロセス整備と運用。PM の活動を支えるプロセスオーナー。 |
| 技術統括 | アーキテクト / PL / TL | 技術方式の決定、設計品質のオーナー。全チームの設計の前提を作る。 |
| アプリ | アプリ(フロントエンド) | UI/UX設計・実装・コンポーネント管理。画面遷移・状態管理・API呼び出しの実装責任者。 |
| アプリ | アプリ(バックエンド) | API設計・業務ロジック実装・外部連携。DBとの接続・トランザクション管理の実装責任者。 |
| インフラ | インフラ担当 | ネットワーク・サーバー・クラウド・CI/CD・監視の設計・構築・運用。 |
| データ | DBA | DB設計・性能チューニング・移行・バックアップ。クエリ性能とデータ整合性の専門家。 |
| 横断 | 共通チーム | 認証・認可・APIゲートウェイ・共通ライブラリの整備。全アプリチームに横断的に影響する基盤を担当。 |
| 横断 | QA | テスト計画・テストケース設計・テスト実施・品質管理。受入基準の達成を証明する。 |
| 横断 | セキュリティ担当 | 脅威モデリング・セキュリティ設計・脆弱性診断。認証方式・暗号化・WAFの設計責任者。 |
「成果物」の定義
本シリーズにおける「成果物」は、文書(ドキュメント)だけを指さない。以下のすべてを成果物として扱う。
| 種類 | 例 |
|---|---|
| 文書・仕様書 | 要件定義書・設計書・テスト仕様書・Runbook |
| 意思決定の記録 | 技術選定ドキュメント・ADR(Architecture Decision Record)・Go/No-Go判定書 |
| 合意・承認 | スコープ確定書・受入合意書・リリース判定書 |
| コード・スクリプト | IaCコード・マイグレーションスクリプト・CI/CDパイプライン |
| 環境・インフラ | 構築済み開発環境・監視ダッシュボード・アラート設定 |
⚠️ 「文書を作った」は成果物ではない
成果物の本質は「次のフェーズへの入力として機能するか」だ。 誰も読まない設計書、署名のない合意書、本番と乖離した手順書は成果物として機能していない。 「誰が・何のために・いつまでに使うか」を意識して成果物を作ることが、後工程の手戻りを防ぐ。
✅ 次のPARTへ
PART 03では、全8フェーズ×全役割の稼働レベルを一覧で俯瞰できる「人員マップ」を示す。アサイン計画の起点として活用してほしい。