システム開発の工程とは？流れ・V字モデル・略語一覧を解説

システム開発の工程とは？10段階の流れ

次の10段階は、ウォーターフォール型の開発を例に、発注してからシステムが動き続けるまでの仕事を分けたものです。

1. プロジェクト計画

2. 要件定義

3. 基本設計（外部設計）

4. 詳細設計（内部設計）

5. 実装（プログラミング）

6. 単体テスト・結合テスト

7. システムテスト（総合テスト）

8. 運用テスト（受入テスト）

9. リリース（本番移行）

10. 保守・運用

上流工程と下流工程の違い

この10段階を3つのまとまりに分けると、次のようになります。前半の2つは、一般に上流工程・下流工程と呼ばれる範囲です。

• 上流工程（1〜3）：プロジェクト計画から基本設計まで。何を作るかを決める

• 下流工程（4〜8）：詳細設計から運用テストまで。作って検証する

• リリース、保守・運用（9〜10）：完成したシステムを動かし続ける

発注側が特に深く関わるのは、上流工程です。ここで決め漏れたことは下流で手戻りになり、期間や費用に跳ね返りかねません。下流工程でも、運用テストは発注側が自ら行います。上流と下流の境目は会社によって前後し、リリースや保守・運用まで下流工程に含める説明もあります。見積もりや体制の説明で「上流」「下流」という言葉が出てきたら、どの工程までを指すのかを担当者に尋ねておくと安心です。

担当者の説明と自社の理解が食い違うときは、IPAの「共通フレーム2013」を物差しにしましょう。共通フレーム2013は、発注側と開発側が同じ言葉で話せるように、システムの構想から開発、運用、保守までに必要な作業の項目と役割をまとめた枠組みです。双方が各工程をこの枠組みのどのプロセスに当てはめているかを比べれば、認識の違いがどこにあるかがはっきりします。

参考：IPA「SEC BOOKS：共通フレーム2013」

1.プロジェクト計画

プロジェクト計画で発注側が最初に決めるのは、何のためにシステムを作るのか、そして予算の上限です。この2つを軸に、対象の範囲、体制、スケジュールを具体化し、プロジェクト計画書にまとめます。

2.要件定義

システムに何を求めるかが曖昧なままだと、後の工程で判断がぶれます。そこで要件定義では、業務の流れと、システムに求める機能や性能、セキュリティなどの要件を洗い出し、要件定義書にまとめます。この工程で要件を決めるのは発注側で、開発会社はそれを支援する立場です。IPAは「超上流から攻めるIT化の原理原則17ヶ条」で、「要件定義は発注者の責任である」を原則の1つに挙げています。

IPAの「情報システム・モデル取引・契約書（第二版）」（以下、モデル契約）では、要件定義書は双方の責任者が記名押印して確定すると定めています（17条）。

参考：IPA「超上流から攻めるIT化の原理原則17ヶ条」

3.基本設計（外部設計）

画面や帳票、ほかのシステムとのデータのやり取りなど、システムの外部と接する部分の仕様を決め、基本設計書（外部設計書）にまとめます。モデル契約では、発注側と開発会社が要件定義書どおりになっているかを点検し、双方の責任者が記名押印して設計書を確定させると定めています（22条）。

参考：IPA「情報システム・モデル取引・契約書（第二版）」

4.詳細設計（内部設計）

プログラムの構造やデータの持ち方など、システム内部の仕組みを決める工程です。主に開発会社が担い、成果物は詳細設計書になります。

5.実装（プログラミング）

設計書に沿ってプログラムを作ります。主に開発会社の作業で、発注側は進み具合の報告を受け、仕様の問い合わせに答える役割です。問い合わせへの返答が遅れると、回答を待つ作業が止まり、開発の遅れにつながりかねません。社内で回答する担当者を決めておきましょう。

6.単体テスト・結合テスト

単体テストではプログラムの部品ごとに、結合テストでは部品をつないだ状態で、正しく動くかを検証します。いずれも主に開発会社が行い、発注側はテストの結果報告を受け取ります。

7.システムテスト（総合テスト）

システム全体が設計どおりに動くか、想定した利用者数やデータ量に耐えられるかを試す工程です。発注側は、テストの範囲と結果の報告をもとに、運用テストへ進んでよいかを判断します。

8.運用テスト（受入テスト）

発注側が実際の業務の流れに沿ってシステムを使い、求めた要件どおりに動くかを確かめます。モデル契約では、検収（28条）は納入されたソフトウェアの検査です。検査の項目やテストデータを定めた検査仕様書を発注側が開発会社と協議して作り（27条）、この検査に合格した時点で検収完了と定めています。運用テストは、その後の工程として別に置かれています。ただし、実際の契約では受入テストを検収とする場合もあります。運用テストと検収の順序や範囲は、契約で確認しておきましょう。

9.リリース（本番移行）

完成したシステムを本番の環境に切り替え、使い始める工程です。既存のシステムを置き換える場合は、あわせてデータの移行を計画します。切り替えで業務が混乱しないよう、発注側は切り替えの日時を決め、利用者への案内や操作の教育を前もって済ませておきます。

あわせて決めておきたいのが、切り替えた後に問題が起きたときに元のシステムへ戻す手順（切り戻し）です。この手順を開発会社と取り決めておけば、当日の判断で慌てずに済みます。

10.保守・運用

稼働後の不具合の修正、機能の追加、システムの監視を続ける工程です。発注側は、保守の範囲と費用を決め、開発会社などと保守契約を結びます。

開発を外部の会社に任せても、要件定義や運用テストのように発注側が判断する工程は手元に残ります。そのため、依頼先を探す前に、自社で担う工程と任せる工程の線引きを決めておきましょう。線引きが決まったら、BIZNAVIのシステム開発のサービス一覧から、任せたい工程に合う依頼先を探せます。

依頼先の選び方や費用の相場は、システム開発会社の比較記事で紹介しています。

システム開発の設計とテストの対応（V字モデル）

V字モデルは、設計の工程とテストの工程を1対1で対応づける考え方です。設計で決めた内容が実現できているかを、対になるテストで検証します。テストの計画や設計は、作り終える前の、対応する設計の段階から始めるのが基本です。左側に設計を上から、右側にテストを下から並べるとV字の形になることから、この名前で呼ばれます。

表は、設計とテストを対応させる一般的な例です。要件定義で決める要件のうち、業務の流れに関わるものは運用テストで、システムに求める機能や性能に関わるものはシステムテストで確かめます。

なお、モデル契約の解説にも設計とテストを対応させた図がありますが、「V字モデル」という言葉は出てきません。解説の図では外部設計をシステムテストと対にしているなど、設計とテストの対応のさせ方は資料や会社によって異なるため、テスト計画の段階で開発会社に尋ねておきましょう。

参考：IPA「情報システム・モデル取引・契約書（第二版）」

システム開発の主な手法（ウォーターフォール・アジャイル・スパイラル）

どの工程をどの順番で進めるかは、開発手法によって変わります。代表的な手法は、ウォーターフォール、アジャイル、スパイラルの3つです。要件が固まっているならウォーターフォール、進めながら決めたいならアジャイル、リスクの評価と試作を重ねて固めたいならスパイラルが適しています。

ウォーターフォール開発

工程を上から順番に進め、原則として前の工程に戻らない手法です。作る範囲を先に決め、工程ごとに成果物を確定させてから次へ進むので、予算や納期の目安を立てやすくなります。その反面、後の工程で仕様を変えると手戻りが大きくなるため、作るものを最初に決めきれる開発に向いています。

【向いている開発の例】

• 会計や人事給与、販売管理などの基幹システム

• 法令や社内規程で処理の手順が決まっている業務のシステム

• 今ある機能を変えずに、古いシステムを新しい基盤へ移す刷新

本記事の10段階とV字モデルは、この手法を前提にした説明です。

アジャイル開発

市場や利用者の反応に合わせて、作るものを途中で変えたい場面で選ばれるのがアジャイル開発です。短い期間で計画・開発・確認を繰り返して動くソフトウェアを少しずつ増やすため、作りながら正解を探る開発に向いています。アジャイル開発の考え方は、2001年に公開された「アジャイルソフトウェア開発宣言」にまとめられており、「計画に従うことよりも変化への対応を」などの価値を掲げています。

【向いている開発の例】

• 新しく立ち上げるWebサービスやスマートフォンアプリ

• 公開した後に、利用者の声に合わせて改善を続けるサービス

• 小さく始めて、効果を確認しながら機能を広げたい社内ツール

IPAのアジャイル開発版のモデル契約は準委任契約を前提とし、発注側がプロダクトオーナー（プロダクトの方向性と内容に責任を持つ人）を選任する形をとっています。開発の期間を通して判断を下せる担当者を社内から出せるかどうかが、アジャイル開発を選べるかのポイントです。

参考：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」

参考：アジャイルソフトウェア開発宣言

スパイラル開発

スパイラル開発では、繰り返しのたびに失敗の原因になりそうな点（リスク）を洗い出して評価し、その結果に応じて設計・試作・検証などを選びながら開発を進めます。バリー・ベームが1988年の論文で解説したモデルで、試作は、リスクを減らすために必要に応じて使う手段の1つです。実物を触らないと良し悪しを判断しにくい要素が多い開発ほど、この進め方の強みが生きます。

【向いている開発の例】

• 操作画面の使い勝手が成果を左右する、利用者の多いシステム

• 前例の少ない技術を使い、作ってみないと実現できるか分からない開発

• 規模が大きく、途中の失敗が大きな損失につながるプロジェクト

試作を繰り返すたびに費用と期間は積み上がっていきます。そのため、繰り返しごとの評価の基準と、予算・期間の目安、次の繰り返しへ進むかの判断の仕方を、開発会社と事前に取り決めておきましょう。

参考：Barry W. Boehm「A Spiral Model of Software Development and Enhancement」（Computer、1988年）

システム開発の工程を分けて進めるメリット

工程を分けて進めると、問題を早い段階で見つけ、計画どおりに完成させやすくなります。システム開発では、問題が見つかるのが遅いほど、直すための手間と費用が大きくなるためです。

具体的には、次の3つのメリットがあります。

• 品質を工程ごとに確保できる：各工程の終わりに成果物を確定させるため、不具合や決め漏れを早い段階で見つけやすい

• 進み具合を管理しやすい：工程と成果物が区切られているので、どこまで進んだかを把握しやすい

• 追加の費用を抑えやすい：手戻りが減るぶん、予定外の作業にかかる費用がふくらみにくい

これらのメリットを得るには、工程ごとに必要な成果物と確認・承認する担当を決め、発注側と開発側で合意しておくことが前提です。たとえば主要な要件を合意しないまま設計に進むと、後から要件が変わるたびに設計のやり直しや追加の作業が生じ、品質や納期、費用に響くおそれがあります。

システム開発の工程で使われる略語一覧

開発の現場では、工程を2〜3文字の英語の略語で呼ぶのが一般的です。会社によって呼び方が違うため、最初の打ち合わせ（キックオフ）で意味をそろえておくと、誤解を防げます。

略語や対応する工程は、会社やプロジェクトによって異なります。表は、開発会社などが公表している呼び方の例です。とくに次の点で、会社によって意味が分かれます。

• PTは、総合テスト（Product Test）の略として使う例と、性能テスト（Performance Test）の略として使う例がある

• PTとSTはどちらも「総合テスト」の意味で使われることがあり、同じ工程を指すのか、対象や役割が異なるのかは会社によって違う

• 基本設計（BD）と外部設計（ED）、詳細設計（DD）と内部設計（ID）を同じものとして扱う会社もある

• 運用テストは、受入テスト（UAT：User Acceptance Test）と呼ばれることもある

担当者が交代すると、略語の受け取り方が人によってずれることがあります。プロジェクトの用語集に略語の意味をまとめ、関係者で共有しておきましょう。

システム開発の工程に関するよくある質問

ここでは、工程の進め方のうち、スケジュール、要件定義と基本設計の違い、工数の配分、検収、要件の変更の扱いについてお答えします。

工程表（スケジュール）はどう作る？

工程表には、本記事の10段階のように工程を分け、工程ごとに期間と成果物、発注側が承認するタイミングを書き出します。要件定義書や基本設計書の確定、運用テストは発注側の作業になるため、社内の担当者の予定も書き込んでおきましょう。

要件定義と基本設計の違いは？

要件定義はシステムに何を求めるかを決める工程で、基本設計はその要件を画面や帳票などの具体的な仕様に落とし込む工程です。要件定義では、業務の流れと、システムに求める機能や性能、セキュリティなどの要件を洗い出し、要件定義書にまとめます。基本設計では、画面や帳票、ほかのシステムとのデータのやり取りなど、システムの外部と接する部分の仕様を決め、基本設計書（外部設計書）にまとめます。要件を決めるのは発注側で、開発会社はそれを支援する立場です。モデル契約では、どちらの書類も双方の責任者が記名押印して確定すると定めています（17条、22条）。

参考：IPA「情報システム・モデル取引・契約書（第二版）」

工程ごとの工数の比率はどれくらい？

要件定義：設計〜結合テスト：総合テストの比率は、工数で15：60：25、工期で20：50：30が目安です（資料では5刻みに丸めた値）。ここでの総合テストは、本記事のシステムテストとは範囲が異なります。開発会社が行うシステムテストは「設計〜結合テスト」に含まれます。総合テストには、ユーザーが行う総合テスト（本記事の運用テストに近い工程）や、稼働後の初期フォローなどが含まれます。一般社団法人日本情報システム・ユーザー協会（JUAS）の「ソフトウェア・メトリクス調査2025」に載っている目安です。主にウォーターフォール型の開発を対象にした過去の集計にもとづくため、規模や開発手法に合わせて読み替えてください。

参考：一般社団法人日本情報システム・ユーザー協会「ソフトウェア・メトリクス調査2025【ガイドブック】」（2025年4月）

受入テストと検収は同じ？

同じとは限りません。受入テスト（運用テスト）は、発注側が業務の流れに沿ってシステムを試す作業です。一方の検収は、納入された成果物が契約どおりかを確かめる手続きです。モデル契約では、納入されたソフトウェアを検査し、合格したときに発注側が検査合格書を交付すること、検査期間内に書面で具体的な理由を挙げて異議を述べなければ合格とみなすことを定めています（28条）。運用テストは、モデル契約では検収の後の工程です。実際の契約では受入テストを検収とする場合もあるため、検収の範囲と期限は契約で確認しておきましょう。

工程の途中で要件を変えたくなったら？

変更したい内容と、費用や期間への影響を開発会社と文書で取り決めてから進めるのが原則です。モデル契約は、変更管理書の交付と、連絡協議会での協議という手続きを定めています（37条）。

参考：IPA「情報システム・モデル取引・契約書（第二版）」

まとめ

本記事では、システム開発の工程を、プロジェクト計画から保守・運用までの10段階に分けて解説しました。上流工程で何を作るかを決め、下流工程で作って検証し、リリース後は保守・運用でシステムを動かし続けます。このうち要件定義書と基本設計書の確定、運用テスト、検収は、開発を外部に任せても発注側が自ら判断する場面です。設計とテストを対にするV字モデルを押さえておけば、各テストで何を確かめるかを判断しやすくなります。手法は、要件が固まっていればウォーターフォール、進めながら決めたいならアジャイル、リスクの評価と試作を重ねて固めたいならスパイラルが目安です。

工程ごとに自社が担う役割が見えたら、次は開発を任せる会社選びに進みましょう。依頼先の選び方や費用の相場はシステム開発会社の比較記事で、具体的な候補はBIZNAVIのシステム開発のサービス一覧で見つけられます。ぜひ一度ご覧ください。