システム開発の工程一覧｜要件定義からリリースまで
「見積書に『基本設計』『詳細設計』『結合テスト』と並んでいるが、それぞれ何をする工程なのか」「会社によって工程の名前が違い、比較しにくい」。システム開発の工程は専門用語で表現されることが多く、発注者にとっては見積もりやスケジュールを読み解くうえでの壁になります。
この記事では、システム開発の工程を要件定義からリリースまで一覧で整理し、各工程の目的と成果物、設計とテストの対応関係を示すV字モデル、会社によって異なる工程名の読み替え方を解説します。発注者が各工程でどう動くかについては、開発の流れを解説した記事もあわせてご覧ください。
- システム開発の主な工程は要件定義・基本設計・詳細設計・製造・単体テスト・結合テスト・総合テスト・受入テスト・リリースです。
- 各工程には成果物（ドキュメントやプログラム）があり、見積もりや納品物の確認の基準になります。
- 設計の各工程とテストの各工程はV字モデルで対応しており、上流の決定が下流のテストの基準になります。
- 工程名は会社で異なるため、成果物と確認内容で読み替えるのが比較のコツです。
目次
システム開発の工程とは？
システム開発の工程とは、システムを作り上げるまでの作業を、目的と成果物ごとに段階的に区切ったものです。各工程には開始と終了の条件があり、成果物が承認されると次の工程に進みます。工程を区切ることで、作業の進み具合を管理しやすくなり、費用や期間の見積もりも工程単位で行えるようになります。
工程の区切り方は開発手法によって異なりますが、日本の受託開発で多く採用されているウォーターフォール型では、上流（要件定義・設計）から下流（製造・テスト）へ順に進めます。以下では、この一般的な工程を一覧で整理します。
システム開発の工程一覧
| 工程 | 目的 | 主な成果物 | 主な担当 |
|---|---|---|---|
| 要件定義 | システムで何を実現するかを決める | 要件定義書、業務フロー図、機能一覧 | 発注者＋開発会社 |
| 基本設計（外部設計） | 利用者から見える仕様を決める | 画面設計書、帳票設計書、データ設計書 | 開発会社（発注者が確認） |
| 詳細設計（内部設計） | プログラムの内部構造を決める | 詳細設計書、処理仕様書 | 開発会社 |
| 製造（実装） | プログラムを作る | ソースコード | 開発会社 |
| 単体テスト | 部品単位で正しく動くか確認 | テスト仕様書・結果報告書 | 開発会社 |
| 結合テスト | 部品同士の連携を確認 | テスト仕様書・結果報告書 | 開発会社 |
| 総合テスト（システムテスト） | システム全体が要件どおりか確認 | テスト仕様書・結果報告書 | 開発会社 |
| 受入テスト | 業務で使えるかを確認 | 受入テスト結果、検収書 | 発注者 |
| 移行・リリース | 本番環境で稼働させる | 移行計画書、操作マニュアル | 開発会社＋発注者 |
要件定義の前に「企画（構想）」、リリースの後に「運用・保守」を加えて全体の工程とすることもあります。
上流工程：要件定義・基本設計・詳細設計
要件定義では、業務の課題と求める機能・品質を整理し、発注者と合意します。基本設計では、要件をもとに画面のレイアウト、入力項目、帳票の形式、データの構造など、利用者や外部から見える部分を具体化します。詳細設計では、基本設計を実現するためのプログラムの構造や処理手順を決めます。上流工程の品質が、後のすべての工程に影響します。
製造と3段階のテスト
製造工程で作られたプログラムは、小さな単位から順にテストされます。単体テストで部品ごとの動作を、結合テストで部品同士や外部システムとの連携を、総合テストで性能やセキュリティを含むシステム全体を確認します。開発会社内のテストを段階的に行うことで、不具合の原因を特定しやすくなります。
受入テストとリリース
受入テストは発注者が主体となり、実際の業務シナリオでシステムを確認する工程です。合格すると検収となり、データ移行、利用者への研修を経て本番稼働します。
関連記事受入テスト（UAT）の進め方と検収のチェックポイント
V字モデルで見る設計とテストの対応
V字モデルとは、上流の設計工程と下流のテスト工程の対応関係をV字の形で表したものです。左側を上から下へ設計・製造が進み、右側を下から上へテストが進みます。それぞれの設計工程で決めた内容が、対になるテスト工程の確認基準になります。
V字モデルの対応関係
| 設計工程（左側） | 対応するテスト工程（右側） | テストで確認すること |
|---|---|---|
| 要件定義 | 受入テスト | 要件を満たし、業務で使えるか |
| 基本設計 | 総合テスト | 画面・帳票・性能などが設計どおりか |
| 詳細設計 | 結合テスト | 処理やデータの受け渡しが設計どおりか |
| 製造 | 単体テスト | 個々のプログラムが正しく動くか |
V字モデルから読み取れる発注者にとっての教訓は、要件定義で決めたことしか受入テストで確認できないという点です。要件定義書の内容が具体的であるほど、受入テストの判断もしやすくなります。
工程ごとの工数配分の目安
見積書では、工程ごとに工数や金額が示されることが一般的です。工程の配分は案件によって異なりますが、次のような傾向があります。
いずれも目安です。テストの比率が極端に少ない、設計の工程が見当たらないといった見積もりは、品質面の確認が必要です。
関連記事システム開発費用の内訳とは？人月単価・工程別の配分をわかりやすく解説
会社によって異なる工程名の読み替え
同じ内容の工程でも、会社によって呼び方が異なります。見積もりを比較するときは、名前ではなく成果物と作業内容で対応づけましょう。
| 一般的な呼び方 | ほかの呼び方の例 | 略称の例 |
|---|---|---|
| 要件定義 | 要求定義、システム化計画 | RD |
| 基本設計 | 外部設計、概要設計 | BD、ED |
| 詳細設計 | 内部設計、プログラム設計 | DD、ID |
| 製造 | 実装、開発、コーディング | PG、CD |
| 単体テスト | ユニットテスト | UT |
| 結合テスト | 統合テスト、連結テスト | IT |
| 総合テスト | システムテスト | ST |
| 受入テスト | ユーザー受入テスト、運用テスト | UAT |
関連記事ウォーターフォールとアジャイルの違い｜発注側の選び方
工程の区切りで確認したいこと
各工程の終わりには、次の工程に進んでよいかを判断する区切りがあります。発注者が特に確認すべきなのは、要件定義と基本設計の終了時、そして受入テストの終了時です。
- 要件定義の終了時：対象範囲と対象外の事項、機能一覧、非機能要件、概算費用とスケジュールに合意できているか。
- 基本設計の終了時：画面・帳票のイメージが業務に合っているか。ここを過ぎると見た目や項目の変更は手戻りが大きくなります。
- 総合テストの終了時：開発会社のテスト結果と、残っている不具合の一覧が報告されているか。
- 受入テストの終了時：業務シナリオが最後まで通り、納品物がそろっているか。
工程の区切りで承認した内容は、後から変更すると追加費用の対象になるのが一般的です。承認前にわからない点を残さないことが、結果として費用と期間を守ることにつながります。
関連記事発注者向けシステム開発用語集
よくある質問
- 基本設計と詳細設計の違いは何ですか？
- 基本設計は画面や帳票など利用者から見える部分の仕様を決める工程で、発注者も内容を確認します。詳細設計はそれを実現するプログラム内部の構造を決める工程で、主に開発会社が行います。
- 小規模な開発でもすべての工程が必要ですか？
- 工程の考え方は同じですが、小規模な開発では基本設計と詳細設計をまとめたり、成果物を簡略化したりすることがあります。ただし要件定義とテストは省略しない方が安全です。
- 工程ごとの成果物はすべて納品してもらえますか？
- どの成果物を納品対象とするかは契約によって異なります。将来の保守や開発会社の変更に備え、設計書やソースコードを納品物に含めるかを契約前に確認しておきましょう。
まとめ
システム開発の工程は、要件定義から基本設計・詳細設計、製造、3段階のテスト、受入テスト、リリースへと進み、各工程に成果物があります。V字モデルのとおり上流の決定が下流のテスト基準になるため、要件定義と設計の段階で内容を具体的にしておくことが品質の鍵です。発注者の役割については関連記事をご覧ください。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
