成果物の本質的な意味
本シリーズを通じて最も伝えたかったことは、成果物は「提出するドキュメント」ではなく「次のフェーズへの入力」だという点だ。
誰も読まない設計書、署名のない合意書、本番と乖離した手順書は成果物として機能していない。 成果物の価値は「誰がいつ・何のために・どのように使うか」によって決まる。 後工程の担当者が「これがあれば迷わず進める」と感じられる成果物を作ることが、手戻りゼロプロジェクトの核心だ。
💡 「いつ誰を呼ぶか」の判断が品質を決める
DBA・セキュリティ・共通チームの参加タイミングが適切かどうかが、プロジェクトの後半の品質を決定的に左右する。これらの専門家を「必要になってから呼ぶ」のではなく「設計の前提を作るフェーズから巻き込む」ことが、手戻りを防ぐ最短経路だ。
シリーズ全体のキーポイント
| フェーズ | 最重要の気づき |
|---|---|
| 企画 | スコープ外を明記する。インフラ・セキュリティを企画段階から巻き込む。 |
| 要件定義 | 非機能要件定義書が後工程の設計制約の根拠。全員の合意署名を取る。変更管理プロセスをここで設置する。 |
| 基本設計 | 変更コストが最も高い決定が集中する。DBA・共通チームの成果物は他チームの詳細設計に先行して確定させる。 |
| 詳細設計 | 設計品質基準を明文化しないとレビューがブレる。QAがテストケースを先行作成することで仕様の矛盾を早期発見できる。 |
| 開発 | PMOのスコープクリープ管理とログ設計の実装は後回し厳禁。インフラ環境の遅延は全体のボトルネックになる。 |
| テスト | 性能テストはインフラ・DBA・QAの3者協働。UATはPM主導でビジネス側の署名入り受入合意書を取る。 |
| リリース | データ移行リハーサルは必須。Go/No-Go基準は当日ではなく事前に全員で合意する。 |
| 運用 | Runbookが「作った人しか直せない」問題を解消する。アプリチームからの正式な引き継ぎ文書が必要。 |
フェーズ別 早見表
アサイン計画時の参考として、各フェーズの最重要成果物をロール別に簡潔にまとめる。
| 役割 | 企画〜要件定義 | 基本設計〜詳細設計 | 開発〜テスト | リリース〜運用 |
|---|---|---|---|---|
| PM | 憲章・ゴール・要件 | スコープ確定 | 進捗管理 | Go/No-Go・KPI |
| PMO | 体制・WBS・変更管理 | リスク管理 | スコープクリープ防止 | 移管完了報告 |
| アーキテクト/PL | 非機能要件・フィジビリティ | 方式設計・技術選定 | 設計レビュー | — |
| アプリ（FE/BE） | 画面要件・機能要件 | 詳細設計・API仕様 | 実装・単体テスト | デプロイ手順 |
| インフラ | コスト試算 | 構成図・IaC設計 | 環境構築・CI/CD | 監視・Runbook |
| DBA | データ要件 | 論理/物理モデル・DDL | マイグレーション | 移行・容量管理 |
| 共通チーム | — | 認証設計・ライブラリ | ライブラリ提供 | CVE管理 |
| QA | テスト方針 | テスト計画・テストケース | テスト実施・UAT | リリース確認 |
| セキュリティ | 脅威モデリング・要件 | アーキレビュー | 脆弱性診断 | 定期診断 |