システム開発の流れを工程別にわかりやすく解説

システム開発の流れは、企画・要件定義・基本設計・詳細設計・開発・テスト・リリース(保守運用を含む)という7つの工程で進むのが基本です。本記事では、発注者側の立場でプロジェクトに関わる独立コンサルタントに向けて、各工程で行うこと、ウォーターフォールとアジャイルでの違い、PMO/PMが果たす役割、非エンジニアの発注者が押さえておきたい点を整理して解説します。

システム開発の全体像

システム開発の流れは、企画・要件定義・基本設計・詳細設計・開発・テスト・リリース(保守運用を含む)という7つの工程に整理できます。

各工程は独立して行われるものではなく、前の工程の成果物が次の工程の入力になる連鎖の関係にあります。情報処理推進機構(IPA)が公開する要件定義の解説でも、要件定義は「プロジェクトの初期に実施される工程」とされており、この段階での抜け・漏れは、後続の設計や開発工程での手戻りコストの増加につながるとされています(出典:IPA「DX SQUARE」)。全体像を先に押さえておくことで、いま自分が関わっている作業が、どの工程の、何のための作業なのかを見失わずに判断しやすくなります。

要件定義から保守運用までの7工程

7つの工程は、企画→要件定義→基本設計→詳細設計→開発→テスト→リリース・保守運用の順に進みます。

それぞれの工程を、代表的な成果物と合わせて整理すると次のとおりです。

企画から詳細設計までを「上流工程」、開発以降を「下流工程」と呼ぶのが一般的です。上流工程での合意が曖昧なまま下流工程に進んでしまうと、後になって仕様の解釈違いが表面化しやすくなります。

各工程で行うこと

各工程では、上流の3工程(要件定義・基本設計・詳細設計)で仕様を固め、下流の3工程(開発・テスト・リリース)で実装と検証を行います。

上流と下流では求められる視点が異なり、発注者が関与すべき度合いも変わってきます。次の項目で、それぞれの工程で具体的に何が行われるかを見ていきます。

要件定義・基本設計・詳細設計

要件定義では業務要件を、基本設計では機能仕様を、詳細設計では実装方法をそれぞれ固めます。

要件定義は、発注者側の業務部門が抱える課題や実現したいことをヒアリングし、システムに求める要件として言語化する工程です。基本設計(外部設計)は、要件定義の内容を画面・帳票・機能一覧といった仕様に具体化する工程で、利用者が実際に触れる部分の仕様を固めます。詳細設計(内部設計)は、基本設計で定めた仕様を、プログラムの内部処理やデータ構造といった実装方法にまで落とし込む工程です。この3工程でどこまで仕様を具体化できているかは、そのまま見積もりの精度にも影響します。別記事「システム開発費用の相場と見積もりの考え方」では、工程ごとの費用感を見ることができますので、あわせて確認しておくと判断がしやすくなります。

開発・テスト・リリース

開発工程ではプログラムを実装し、テスト工程では段階的に品質を検証し、リリース工程で本番環境へ移行します。

開発(製造)工程は、詳細設計書に基づいてプログラムを実装する工程で、実装したモジュール単位での単体テストまでを含むのが一般的です。続くテスト工程は、機能間の連携を確認する結合テスト、システム全体を通しで確認する総合テスト、発注者側が業務観点で確認する受入テスト(検収)という順に段階を踏みます。テストの範囲や合格基準を工程の早い段階で合意しておかないと、検収の場面で「何をもって完成とするか」の認識にずれが生じやすくなります。リリース工程では、本番環境への移行(既存システムがある場合は並行稼働を含む)と保守運用担当への引き継ぎを行い、以降は保守運用工程として安定稼働を維持していきます。

ウォーターフォールとアジャイルでの流れの違い

ウォーターフォール開発は工程を順番に進める方式、アジャイル開発は短い期間で計画・設計・開発・テストを繰り返す方式です。

ウォーターフォール開発は、開発対象全体の要件や仕様を確定してから、設計・製造・テストへと順番に進める手法です。一方アジャイル開発は、機能の追加・変更や優先順位の変更、先行リリース部分の改善などに柔軟に対応できる手法とされています(出典:IPA「情報システム・モデル取引・契約書(アジャイル開発版)」)。この進め方の違いは契約形態にも表れており、ウォーターフォールでは成果物の完成に対価を支払う請負契約が、アジャイルでは業務の遂行自体に対価を支払う準委任契約が採用されやすい傾向にあります。

どちらが優れているというものではなく、要件の確定度合いやプロジェクトの性質に応じて選ぶものと考えられます。アジャイルは「仕様を決めずに進められる手法」と誤解されることがありますが、実際には反復のたびに優先順位や受け入れ条件を発注者側が判断する場面が増えるため、意思決定の頻度はむしろ高くなる点に注意が必要です。

PMO/PMが各工程で果たす役割

PMOは各工程の進捗・課題を可視化する役割を、PMはその情報をもとに意思決定を行う役割をそれぞれ担います。

PM(プロジェクトマネージャー)は、スケジュール・予算・品質に関する最終的な意思決定と責任を担う役割です。PMO(プロジェクトマネジメントオフィス)は、PMの意思決定を支えるため、進捗状況や課題の可視化、会議体の運営、各種資料の整備といった事務局機能を担います。とくに要件定義から基本設計にかけては、部署をまたいだ関係者が多く決めるべき事項が集中する局面のため、PMO/PMによる進捗管理と合意形成の支援が重要になります。

戦略・DX・IT・データといった高度人材は構造的に不足しており、IT人材は2030年に最大で約79万人不足すると見込まれています(出典:経済産業省調査を引用したコンサルGO記事)。こうした人材不足を背景に、発注者企業がプロジェクト単位で外部のPM/PMO人材を活用する動きが広がっており、独立コンサルタントが担う役割は今後も増えていくと考えられます。

編集部が独立系のPM/PMOへのヒアリングを重ねてきた中では、要件定義の工程で合意形成に十分な時間を割けたプロジェクトほど、後工程での手戻りが少ない傾向がある、という声が多く聞かれます(編集部独自調査)。PMOは、各工程で行うべきタスクを洗い出し、担当者と期限を割り振ってスケジュールに落とし込む役割も担います。「WBSの作り方 完全ガイド」では、工程をスケジュールに落とし込む具体的な手順を確認できます。

非エンジニアの発注者が押さえておくべき点

非エンジニアの発注者が押さえておくべき点は、要件定義の内容を自分の言葉で確認すること、検収基準を工程の早い段階で合意しておくことです。

システム開発の流れを理解したうえで、非エンジニアの発注者がとくに押さえておきたいポイントは次の4点です。

• 要件定義書の内容を業務観点で確認する：専門用語のまま読み流さず、自部門の業務でどう使われるかに置き換えて理解する
• 検収基準を早い段階で合意する：何を満たせば「完成」とするかを、テスト工程が始まる前に言語化しておく
• 仕様変更が発生した場合のルールを決めておく：スケジュールや費用への影響をどう扱うかを事前に取り決めておく
• PMO/PMの役割分担を確認する：進捗管理と意思決定のどちらを誰が担うのかをプロジェクト開始時にすり合わせる

各工程の呼び方や定義に不安がある場合は、「システム開発とは?開発工程の基本をわかりやすく解説」で工程の定義を再確認するのも有効です。システム開発の流れを工程ごとに理解しておくことは、開発ベンダーやPMO/PMと対等に対話するための土台になります。

本記事は2026年9月時点の情報に基づいています。

出典・参考情報

1. 独立行政法人情報処理推進機構(IPA)「DX SQUARE - 要件定義とは？」（2026-09-09参照）
2. 独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書(アジャイル開発版)」（2026-09-09参照）
3. コンサルGO「PMO業務の基礎」（経済産業省のIT人材不足調査を引用）（2026-09-09参照）

本記事は2026年9月時点の情報に基づいています。制度・ガイドラインの詳細な内容は変更される場合があるため、最新情報は各公式サイトでご確認ください。最終更新日:2026年9月9日