成果物の本質的な意味
図1: 成果物を活かすプロジェクト運営の全体像
本シリーズを通じて最も伝えたかったことは、成果物は「提出するドキュメント」ではなく「次のフェーズへの入力」だという点だ。
誰も読まない設計書、署名のない合意書、本番と乖離した手順書は成果物として機能していない。 成果物の価値は「誰がいつ・何のために・どのように使うか」によって決まる。 後工程の担当者が「これがあれば迷わず進める」と感じられる成果物を作ることが、手戻りゼロプロジェクトの核心だ。
💡 「いつ誰を呼ぶか」の判断が品質を決める
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 | リリース確認 |
| セキュリティ | 脅威モデリング・要件 | アーキレビュー | 脆弱性診断 | 定期診断 |
成果物を見直すタイミング
成果物は一度作ったら終わりではない。以下のタイミングでは関連する成果物を必ず見直す必要がある。
| 見直しトリガー | 見直すべき成果物 | 見直しの目的 |
|---|---|---|
| スコープの変更要求が発生 | プロジェクト憲章・WBS・スケジュール・リスク管理表 | 変更の影響範囲をすべての成果物に反映し、全員の再合意を得る |
| 技術的な実現不可能が判明 | ADR（技術選定）・システム方式設計書・非機能要件定義書 | 代替案の選定と、影響を受ける下流の設計書への展開 |
| テストで重大な不具合が連続して発見 | 詳細設計書・テスト仕様書・不具合管理票 | 設計レベルの問題かを判断し、詳細設計への手戻りを決定する |
| Go/No-Go判定でNo-Goになった | リリース判定書・ロールバック手順書・データ移行手順書 | No-Goの根拠を記録し、再リリースに向けた課題対応計画を立てる |