---
title: "システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説"
url: "https://www.issoh.co.jp/column/details/13132/"
published: 2026-07-06
updated: 2026-09-25
categories: ["Webシステム"]
publisher: "株式会社一創"
---

# システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説

システム開発の工程は、要件定義から運用保守まで大きく7つのフェーズに分かれます。この記事では、各工程で何を作り（成果物）、誰が担当し（体制）、全体のどれくらいの工数を占めるか（比率）を、発注する側の視点でまとめました。現場で飛び交うRDやUT、ITといった略語、ウォーターフォールとV字モデルの対応関係、上流工程と下流工程の境界、そして工程の進め方を誤ると案件が炎上する条件まで、順に確認していきます。開発会社に丸投げせず、要所で正しく口を出すための地図として使ってください。

## まとめ｜システム開発の工程で発注者が確認すべき7フェーズと成果物

システム開発の工程は、①要件定義 ②基本設計（外部設計）③詳細設計（内部設計）④開発（製造）⑤テスト ⑥リリース ⑦運用・保守、の7フェーズで捉えると全体像が掴めます。テストは単体・結合・総合・運用の各段階に細分でき、分け方によって工程数は5〜10と幅があります。この7フェーズを実装者の視点でライフサイクル（SDLC）として捉え直す整理は[SDLCとは？ソフトウェア開発ライフサイクルの工程とモデル](https://www.issoh.co.jp/tech/details/13386/)で解説しています。

発注側がまず押さえるべきは、各工程の「成果物」です。要件定義書・基本設計書・詳細設計書・[テスト仕様書](https://www.issoh.co.jp/column/details/13200/)といった文書を工程の節目でレビューし、承認できて初めて次工程へ進みます。ここを開発会社任せにすると、後工程での手戻りが工数を押し上げます。工程別の工数は、要件定義に約1割、設計に2〜3割、製造に3〜4割、テストに2〜3割を充てる配分が経験則の目安です。

失敗の多くは上流、とくに要件定義への発注側の関与不足から起きます。誰が何をいつ作るのかを工程表で可視化し、上流に自社の業務担当が入る体制を組めるかどうかが、システム開発の成否を分けます。工程全体の設計や体制づくりに不安があれば、発注者側に立って要件定義と工程管理を支える[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)への相談を検討してください。

## システム開発の工程の全体像と上流から下流まで7フェーズの呼び方

システム開発は、業務の要求を文書に落とすところから、動くシステムを本番で運用し続けるところまでを一連の工程でつなぎます。工程の「順番」そのものを通しで追いたい場合は、[システム開発の流れとは？工程の全体像と各フェーズのポイント](https://www.issoh.co.jp/column/details/12851/)で全体の流れを1本にまとめました。本記事は、その各工程の中身、つまり成果物・体制・工数・失敗条件を掘り下げます。

### 上流工程と下流工程の違いと境界、どこまでが上流かの実務的な判断基準

上流工程とは、要件定義・基本設計といった「何を作るか」を決めるフェーズを指します。この「何を作るか」を利用者の視点で機能として図に落とし込む手法が[ユースケース図](https://www.issoh.co.jp/tech/details/13469/)で、要件定義の抜けを早期に炙り出す道具になります。下流工程は、詳細設計以降の「どう作るか・作ったものを確かめる」フェーズです。境界を詳細設計のどちら側に置くかは会社によって揺れますが、実務では「発注側の業務判断が必要な範囲＝上流」と考えると迷いません。

画面に出す項目や承認の流れ、扱う金額の丸め方といった業務ルールは、発注側にしか決められません。この判断が残っている工程は上流です。逆に、内部のクラス構成やテーブルの持ち方は開発会社の領分で、下流に属します。上流をどこまで発注側が握るかで、後工程の手戻り量が変わります。

### システム開発の各工程で作成する成果物と発注者が承認すべき文書の一覧

工程の節目には、次工程の入力になる成果物が必ず生まれます。発注側は、この成果物をレビューして承認する立場です。何が出てくるはずかを知らないと、レビューの抜けがそのまま品質の穴になります。基本設計フェーズで作られる[システム構成図](https://www.issoh.co.jp/column/details/13136/)も成果物の一つで、サーバーやデータの流れを1枚で確認できます。

| 工程     | 主な成果物          | 発注側の関与    |
| ------ | -------------- | --------- |
| 要件定義   | 要件定義書・業務フロー    | 内容を主導・承認  |
| 基本設計   | 画面設計書・帳票設計・ER図 | 画面と業務を確認  |
| 詳細設計   | 詳細設計書・テーブル定義書  | 原則は開発会社主体 |
| 開発（製造） | ソースコード・単体試験項目  | 進捗を確認     |
| テスト    | テスト仕様書・不具合報告書  | 運用テストを主導  |
| リリース   | 移行計画書・手順書      | 本番移行を承認   |
| 運用・保守  | 運用手順書・保守契約     | 運用体制を決定   |

とくに要件定義書は、後続の設計・テストすべての基準になる文書です。書き方の型やサンプルを知っておくと、承認の精度が上がります。要件定義そのものの進め方は[要件定義とは](https://www.issoh.co.jp/column/details/12848/)で詳しく整理しています。

### システム開発の現場で使う工程の略語一覧とRDやUT、ITなどの読み方

開発現場では、工程名を英語の略語で呼ぶ場面が珍しくありません。会社ごとに割り当てが異なるため、打ち合わせの冒頭で定義をすり合わせておくと認識のずれを防げます。代表的な略語を並べます。

| 略語 | 英語                      | 対応する工程      |
| -- | ----------------------- | ----------- |
| RD | Requirements Definition | 要件定義        |
| UI | User Interface          | 基本設計（外部設計）  |
| SS | System Structure        | 構造設計        |
| DD | Detail Design           | 詳細設計（内部設計）  |
| PG | Programming             | 製造（プログラミング） |
| UT | Unit Test               | 単体テスト       |
| IT | Integration Test        | 結合テスト       |
| ST | System Test             | 総合テスト       |

同じ「UI」でも、外部設計を指す会社とユーザーインターフェース設計だけを指す会社があります。略語は共通言語ではなく方言に近いものです。契約書や工程表では、略語の隣に日本語の工程名を併記してもらうと安全です。

## システム開発の工程ごとの体制と工数比率｜誰がどれだけ関わるのか

工程は、担当する人と割く時間の配分で見ると実態が見えます。全工程を開発会社に等分で任せるわけではありません。上流ほど発注側の関与が濃く、下流ほど開発会社の専門作業が主になります。

### 各工程の担当と発注側の関与度の濃淡と、上流丸投げが破綻する理由

要件定義は、発注側の業務担当が主役です。業務の実態を知らない開発会社だけで要件は固まりません。基本設計では画面や帳票を発注側が確認し、詳細設計から製造にかけては開発会社が主体になります。基本設計（外部設計）のフェーズで発注側が何を承認すべきかは[外部設計とは](https://www.issoh.co.jp/column/details/13134/)で詳しく整理しています。テストの最終段階である運用テストでは、再び発注側が実際の業務で使えるかを判定します。

丸投げが破綻するのは、この関与の濃淡を無視して上流まで開発会社任せにするからです。要件定義書のレビューに発注側の業務担当が一度も出てこない案件は、後工程で「思っていたものと違う」が噴出します。上流だけは人を出す、この一点を守るだけで手戻りは大きく減ります。

### 工程別の工数比率の目安と、設計・製造・テストの工数配分バランス

工数の配分は案件規模や品質要件で動きますが、目安のレンジはあります。要件定義に全体の約1割、設計（基本＋詳細）に2〜3割、製造に3〜4割、テストに2〜3割、という配分が経験則の出発点です。IPAが公開するソフトウェア開発のデータ集でも、工程別の工数実績が規模帯ごとに整理されています。

ここで注意したいのは、テストの比率です。品質要件が高い金融・公共系では、テストが設計や製造と同等かそれ以上に膨らみます。見積書でテスト工数が全体の1割を切っている場合、テスト設計が甘いか、後から追加請求が来る前触れです。工程別の費用感は[システム開発の費用](https://www.issoh.co.jp/column/details/13121/)とあわせて確認してください。

### システム開発の工程表（ガントチャート）の作り方と進捗確認の見方

工程表は、どの工程をいつ始めていつ終えるかを1枚で示す計画表です。ガントチャート形式で工程を横棒に並べ、成果物の完成日をマイルストーンとして置きます。発注側は、細かな作業ではなく成果物の承認日に注目すると進捗を掴みやすくなります。

1. 工程を要件定義から運用保守まで縦に並べる
2. 各工程の成果物と承認日をマイルストーンにする
3. 工程の重なり（並行作業）と依存関係を線で結ぶ
4. 要件定義の遅れが全体を押す前提で余裕日を置く

進捗確認では「何％終わったか」より「予定の成果物が承認まで到達したか」を見ます。コードが8割書けていても、単体テストで作り直しになれば工程は進んでいません。承認済みの成果物の数で進捗を測るのが、発注側の見方です。

## 開発手法で変わる工程の進め方とウォーターフォールとV字モデル

工程の並べ方は、採用する開発手法で変わります。一方向に流すウォーターフォール、小さな工程を繰り返すアジャイル。どちらが向くかは、要件の固まり具合で決まります。

### ウォーターフォール開発の工程とV字モデルにおけるテストの対応関係

ウォーターフォールは、要件定義から順に工程を下へ流し、原則として前工程には戻らない進め方です。手法そのものの工程やV字モデル、向くプロジェクトの見極めは[ウォーターフォール開発とは](https://www.issoh.co.jp/column/details/13140/)で詳しく解説しています。この手法を品質保証の視点で描き直したのがV字モデルです。左側の設計工程と右側のテスト工程が、同じ高さで対応します。

- 要件定義 ↔ 運用テスト（要求どおり使えるか）
- 基本設計 ↔ 総合テスト（システム全体の動き）
- 詳細設計 ↔ 結合テスト（機能間の連携）
- 製造 ↔ 単体テスト（部品単位の動作）

V字モデルの利点は、設計の段階で対応するテストの観点を先に決められることです。要件定義を書いた時点で運用テストの合格条件を握っておけば、テスト工程で「何をもって完了とするか」の揉め事が減ります。設計とテストをペアで考える、これがV字モデルの実務的な使いどころです。テスト工程そのものの種類と進め方は、[システム開発のテスト工程を種類・流れ・発注観点で解説した記事](https://www.issoh.co.jp/column/details/13445/)で詳しく整理しています。

### アジャイル開発で工程の考え方と進め方がどのように変わるのか整理

アジャイルは、要件定義から製造・テストまでの工程を数週間の単位で繰り返す進め方です。全工程を1回で通すのではなく、優先度の高い機能から小さく作って確かめます。要件が固まりきらない新規事業や、仕様変更が前提のサービス開発で採られます。

アジャイルでも工程そのものが消えるわけではありません。要件定義も設計もテストも各周回に凝縮されて存在します。手法の向き不向きの判断は[アジャイル開発とは](https://www.issoh.co.jp/column/details/12850/)で整理しています。要件が動く前提ならアジャイル、要件が確定していて品質と検収が厳格ならウォーターフォールが基本線です。

## 上流工程の失敗で炎上するシステム開発の典型パターンと回避条件

工程の知識は、失敗を避けるために使ってこそ意味があります。炎上する典型は2つ。どういう条件なら避けられるかを言い切り、採用しない場面まで玉虫色にせず明示します。

### 上流工程を軽視したシステム開発案件が炎上する条件と着工を見送る兆候

最も多い炎上は、要件定義を軽く済ませた案件で起きます。要件定義書のレビューに発注側の業務担当が出席せず、情報システム部門だけで承認してしまうと、現場の業務ルールが抜け落ちがちです。抜けは製造やテストの段階で発覚し、そのたびに設計へ戻る手戻りが工数を倍近くまで膨らませます。

次の兆候が2つ以上そろう案件は、着工を見送るか要件定義をやり直すべきです。第一に、要件定義に業務部門が関与しない。第二に、要件定義書がA4数枚しかない。第三に、工程表でテスト期間が全体の1割未満に圧縮されている。この状態で進めるくらいなら、上流を仕切り直せる開発会社に相談する方が結果的に安く済みます。上流を発注者側から点検する[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)を挟めば、要件定義の抜けを着工前に潰せます。

### 工程を飛ばしても良い場面と、省略がシステム開発の致命傷になる場面

すべての工程を毎回フルセットで踏む必要はありません。既存システムの軽微な文言修正なら、詳細設計書を省いて改修と単体テストだけで回すのは合理的です。工程は、リスクの大きさに応じて厚み付けを変えるものです。

一方で、省略が致命傷になる工程もはっきりしています。外部システムとの連携、課金・決済、個人情報の取り扱いが絡む機能で結合テストや総合テストを削るのは避けるべきです。ここでの不具合は本番で金銭事故や情報漏えいに直結し、修正費用は開発費を上回ります。テスト工程を削って納期を詰める提案が来たら、削る対象がこの3領域に触れていないかを必ず確認してください。

## よくある質問

システム開発の工程について、検索で多く見られる疑問に簡潔に答えます。

### システム開発の工程はいくつに分けるのが一般的ですか？

大きくは、要件定義・基本設計・詳細設計・開発（製造）・テスト・リリース・運用保守の7フェーズで捉えるのが一般的です。ただしテストを単体・結合・総合・運用に細分したり、要件定義の前に企画工程を置いたりするため、数え方によって5〜10工程と幅が出ます。工程数そのものより、各工程の成果物を押さえる方が実務では役立ちます。

### 上流工程と下流工程の違いは何ですか？

上流工程は要件定義や基本設計など「何を作るか」を決めるフェーズ、下流工程は詳細設計以降の「どう作り、確かめるか」のフェーズです。境界は会社によって揺れますが、発注側の業務判断が必要な範囲を上流と考えると整理しやすくなります。上流の精度が、下流の手戻り量をほぼ決めます。

### システム開発の工程で使う略語にはどんなものがありますか？

要件定義をRD、基本設計をUI、詳細設計をDD、製造をPG、単体テストをUT、結合テストをIT、総合テストをSTと呼ぶ例があります。ただし割り当ては会社ごとに異なり、同じUIでも外部設計全体を指す場合と画面設計だけを指す場合があります。打ち合わせの冒頭で定義を合わせておくのが安全です。

### 各工程の工数比率の目安はどれくらいですか？

経験則では、要件定義に全体の約1割、設計に2〜3割、製造に3〜4割、テストに2〜3割という配分が出発点です。IPAが公開する開発データ集でも工程別の実績が整理されています。品質要件の高い金融・公共系ではテストの比率が上がるため、見積でテストが極端に薄い場合は内容を確認してください。

### 発注者は各工程でどこまで関わる必要がありますか？

要件定義と運用テストは発注側が主導し、基本設計は画面と業務を確認します。詳細設計から製造は開発会社が主体で、発注側は進捗の確認が中心です。関与の濃淡を無視して上流まで丸投げすると手戻りが増えます。上流だけは業務担当が人を出す、という線を守るのが実務の勘所です。

## 関連記事

- [システム開発とは](https://www.issoh.co.jp/column/details/12847/)：工程の前提となるシステム開発全体の定義や進め方を俯瞰できます。
- [要件定義書の書き方（サンプル）](https://www.issoh.co.jp/column/details/12849/)：最上流の成果物である要件定義書を、型とサンプルから作れます。
- [システム開発の費用](https://www.issoh.co.jp/column/details/13121/)：工程別の工数配分が費用にどう反映されるかを確認できます。

---

出典: [システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説](<https://www.issoh.co.jp/column/details/13132/>)（株式会社一創）