はじめに
ウォーターフォール開発は、各工程が順次実行される「滝の流れ」のような開発手法です。各工程で作成される成果物は、プロジェクトの成功に不可欠です。
出典: ITトレンド - プロセス管理
この記事では、各工程の成果物について、目的・ツール・実務での実態を簡潔にまとめます。
各工程の成果物一覧
1. 要件定義フェーズ
| 成果物 | 目的 | 主なツール | 実務での実態 |
|---|---|---|---|
| 要件定義書 | 機能・性能要件の明確化 | Word, Confluence | 必須。小規模でも簡略化はするが作成 |
| システム概要書 | システム全体像の共有 | PowerPoint, Figma | 図解中心。技術詳細より全体像重視 |
| 業務フロー図 | 業務の流れの可視化 | Visio, Lucidchart | ステークホルダーとの認識合わせに重要 |
2. 基本設計（外部設計）フェーズ
| 成果物 | 目的 | 主なツール | 実務での実態 |
|---|---|---|---|
| 基本設計書 | ユーザー視点でのシステム設計 | Word, Excel | 画面設計と機能設計を分けないことも |
| 画面設計書 | UI/UX仕様の明確化 | Figma, Adobe XD | モックアップと併用が一般的 |
| 帳票設計書 | 出力帳票の仕様定義 | Excel, Crystal Reports | 印刷物がない場合は省略されることも |
| データモデル（ER図） | データベース構造の概念設計 | MySQL Workbench, draw.io | 正規化レベルを明記。DB設計者と連携 |
3. 詳細設計（内部設計）フェーズ
| 成果物 | 目的 | 主なツール | 実務での実態 |
|---|---|---|---|
| 詳細設計書 | プログラマーが実装できるレベルの設計 | Word, Excel | クラス図、シーケンス図を含む。小規模では省略されることも |
| データベース物理設計書 | テーブル・カラムの具体的な定義 | Excel, A5:SQL Mk-2 | インデックス設計も重要。パフォーマンス考慮 |
| API設計書 | 外部連携やマイクロサービス間の仕様 | Swagger/OpenAPI, Postman | 最近では必須。RESTful APIの設計原則に従う |
4. 実装（コーディング）フェーズ
| 成果物 | 目的 | 主なツール | 実務での実態 |
|---|---|---|---|
| ソースコード | システムの実体となるプログラム | Git/GitHub, GitLab | コーディング規約に従う。バージョン管理を徹底 |
| コーディング規約書 | コード品質の統一 | Word, Markdown | ESLint、Prettierで自動化。チーム全体で共有 |
5. テストフェーズ
| 成果物 | 目的 | 主なツール | 実務での実態 |
|---|---|---|---|
| 単体テスト仕様書・結果報告書 | 個別機能の動作確認 | Excel, TestRail | 自動化が進み、ドキュメントは簡略化傾向 |
| 結合テスト仕様書・結果報告書 | モジュール間の連携確認 | Excel, TestRail | 重要な統合ポイントに焦点。データの流れを追跡 |
| システムテスト仕様書・結果報告書 | システム全体の要件充足確認 | Excel, Zephyr | 非機能要件のテストも含む。ユーザーシナリオベース |
| 受け入れテスト仕様書・結果報告書 | 顧客視点での最終確認 | Excel, Word | ユーザー代表が実施。業務シナリオに基づく |
6. リリース・保守フェーズ
| 成果物 | 目的 | 主なツール | 実務での実態 |
|---|---|---|---|
| 運用マニュアル | 日常運用の手順書 | Word, Confluence | 図解と手順を明確に。スクリーンショット含む |
| 保守マニュアル | トラブル対応・障害切り分け | Word, Confluence | FAQ形式も有効。エラーメッセージと対処法の対応表 |
| 移行計画書 | 本番環境への切り替え手順 | Excel, Word | ロールバック手順も必須。移行タイムラインを明確化 |
| データ移行仕様書 | 既存システムからのデータ移行 | Excel, Word | データクレンジングも考慮。バックアップ手順も含む |
実務での実態
よく省略される成果物
- 帳票設計書（印刷物がない場合）
- 詳細設計書（コードがドキュメント代わり）
- 一部のテスト仕様書（自動化によりコードjsDocやPHPDocなどのコード上のコメントに記載）
- リリース・保守フェーズ（省略ではないが、開発チームからQAチームや運用チームに移管されることが多い）
重要視される成果物
- 要件定義書（プロジェクトの基礎）
- API設計書（マイクロサービス時代）
- テスト結果報告書（品質保証のエビデンス）
アジャイル開発との違い
最近ではアジャイルでの開発が用いられることが増えており、ドキュメントが少ない現場もあります。
| 項目 | ウォーターフォール | アジャイル |
|---|---|---|
| 重視するもの | ドキュメント | 動くソフトウェア |
| 開発スタイル | 各工程完結型 | 継続的な改善 |
| 柔軟性 | 低い（変更コスト高） | 高い（顧客との協調） |
- 要件定義はウォーターフォール、実装はアジャイルといったハイブリッド型の開発もあります。
筆者の体験談
私自身、要件定義書含むドキュメントが存在しない現場にアサインされた経験があります。「仕様はコードから読み取って！」と泣く泣くコードの意図を探り探り進めた開発でした。
誰かがわかっていればいいですが、長期のプロジェクトになると初めからいる人が抜けて行くこともあります。仕様は分かるうちにまとめておくのが吉だと感じました。
アジャイルでのゴリゴリ開発に憧れていましたが、実際に経験してみると先人のドキュメントが存在することのありがたさに気がつきました。個人的に開発記録を残してくれる先輩方にも感謝をお伝えしたいです。
まとめ
重要なポイント
- 目的を理解する: なぜその成果物が必要なのかを常に考える
- プロジェクトに応じた柔軟性: 規模や性質に応じて適切に調整
- ツールの活用: 効率的な作成・管理のためのツール選択