システム開発の流れをわかりやすく解説【ウォーターフォール完全版】
システム開発やゲーム開発をしていると、
- 「要求定義と要件定義の違いが曖昧」
- 「設計ってどこまでやればいいの?」
- 「現場ごとにやり方が違ってよくわからない」
と感じることはありませんか?
実際、現場では工程が省略されたり、混ざったりすることも多く、
体系的に理解できている人は意外と少ないです。
そこで今回は、ウォーターフォール開発をベースに、
システム開発の流れを「担当・役割・成果物」まで含めて整理しました。
※本記事の前提を先に述べておくと、システム開発の目的や役割を理解することが本記事の目的であり、流れや関わる人は会社によって異なります。また、他にも手法があるため、今回の流れがすべてだとは思わないようにしてください。
■ この記事でわかること
- システム開発の全体の流れ
- 各工程の「担当・役割・成果物」
- 要求定義・要件定義・設計の違い
- 実務で使える整理された開発フロー
ウォーターフォール開発とは

ウォーターフォール開発とは、上流から下流へ順番に工程を進めていく開発手法です。
前の工程が完了してから次に進むため、
- 計画が立てやすい
- ドキュメントが整理される
- 大規模開発に向いている
といった特徴があります。
システム開発の全体像
まずは全体の流れを一覧で整理します。
| 工程 | 担当 | 役割 | 成果物 |
|---|---|---|---|
| 要求定義 | 顧客・設計者 | 顧客の要求や課題を整理する | 要求一覧 |
| 要件定義 | 設計者 | 開発に必要な要件を整理する | 要件定義書、要件一覧、業務フロー、概算見積もり |
| 基本設計 | 設計者 | 顧客が理解できる仕様を決める | 基本設計書、画面設計、機能一覧、構成図 |
| 詳細設計 | 設計者 | 開発者向けの内部仕様を決める | 詳細設計書、UML、各種定義書 |
| コーディング | 開発者 | システムを実装する | ソースコード、システム |
| 単体テスト | 開発者 | モジュール単位で確認する | 単体テスト結果 |
| 結合テスト | 開発者 | 機能同士の連携を確認する | 結合テスト結果 |
| 総合テスト | 開発者 | 実運用を想定して確認する | 総合テスト結果、受入記録 |
各工程の詳細
要求定義
要求定義は、「何を作るか」ではなく「なぜ作るか」を明確にする工程です。
| 項目 | 内容 |
|---|---|
| 担当 | 顧客・設計者 |
| 役割 | 顧客の「やりたいこと」「課題」を整理する |
| 成果物 | 要求一覧、課題整理、目的の明確化 |
この段階では、仕様を決めるのではなく、
- 現状の問題
- 解決したいこと
- ゴール
を整理することが重要です。
要件定義
要件定義では、要求をもとに「業務要件」、「機能要件」、「非機能要件」を整理し、
システムとして何が必要かを明確にします。
| 項目 | 内容 |
|---|---|
| 担当 | 設計者 |
| 役割 | システムとして必要な条件を整理する |
| 成果物 | 要件定義書、要件一覧(業務・機能・非機能)、業務フロー、見積もり |
また、この段階で「契約金」、「納期」といった見積もりも行われます。
基本設計
基本設計は、ユーザー視点の仕様を決める工程です。
| 項目 | 内容 |
|---|---|
| 担当 | 設計者 |
| 役割 | 顧客が理解できる仕様を決める |
| 成果物 | 基本設計書、画面設計、機能一覧、画面遷移図、構成図 |
主に以下を決めます。
- 画面構成
- 機能一覧
- 操作の流れ
- システム構成
顧客にレビューしてもらう重要なフェーズです。
詳細設計
詳細設計では、開発者がわかるように内部の動きやロジックを具体化します。
| 項目 | 内容 |
|---|---|
| 担当 | 設計者 |
| 役割 | 開発者が実装できるレベルまで仕様を落とす |
| 成果物 | 詳細設計書、処理フロー、テーブル定義、UML |
例えば、
- データ構造
- 処理の流れ
- エラー処理
などを定義します。
※小規模開発では省略されることも多い工程です。
コーディング
ここで実際にプログラムを作成します。
| 項目 | 内容 |
|---|---|
| 担当 | 開発者 |
| 役割 | 設計書に沿って実装する |
| 成果物 | ソースコード、システム |
設計がしっかりしているほど、手戻りが少ない・品質が安定するというメリットがあります。
単体テスト
機能単体で、正常に動くか・想定通りの結果になるかを確認します。
| 項目 | 内容 |
|---|---|
| 担当 | 開発者 |
| 役割 | モジュール単位で動作確認する |
| 成果物 | 単体テスト仕様書、テスト結果 |
結合テスト
複数の機能を組み合わせて、データの受け渡し・画面遷移・API連携などが正しく動くかを確認します。
| 項目 | 内容 |
|---|---|
| 担当 | 開発者 |
| 役割 | 機能同士の連携を確認する |
| 成果物 | 結合テスト仕様書、テスト結果 |
総合テスト
最後に、実際の業務に近い形でテストを行います。
| 項目 | 内容 |
|---|---|
| 担当 | 開発者・顧客 |
| 役割 | 実際の運用を想定して確認する |
| 成果物 | 総合テスト結果、受入確認 |
全体として問題ないか・業務として成立するかを確認し、問題がなければリリースとなります。
※詳細設計・単体テスト・総合テストは小プロジェクトでは確認程度に済ませておいて省略することもあります。
まとめ
今回のポイントを整理します。
ウォーターフォール開発は、「順番に整理して進めること」が最大の強みです。
| ポイント | 内容 |
|---|---|
| 要求定義 | 「なぜ作るか」を明確にする |
| 要件定義 | 「何が必要か」を決める |
| 基本設計 | 「ユーザー視点の仕様」を決める |
| 詳細設計 | 「内部の仕組み」を決める |
| テスト工程 | 段階的に品質を保証する |
サイトアイコン-2-150x150.png)