システム開発の流れを工程別に解説！発注側が知るべき全ステップ

システム開発を外注しようと検討している場合、「どんな工程で進むのか」「自社はどこで何をすればいいのか」が分からないまま進めてしまうと、手戻りや追加コストが発生するリスクが高まります。

工程の全体像を把握しておくだけで、開発会社との認識のずれを防ぎ、プロジェクトの成功確率を高めることができます。

本記事では、要件定義からリリース・運用保守まで全工程の内容と発注側が各工程で確認すべきポイントを工程別に解説します。

開発手法の違いや費用の目安、開発現場でよく使われる略語の意味もあわせて整理しています。

システム開発の流れで押さえるべき全工程の概要と役割分担

システム開発は、企画・要件定義から始まり、設計・実装・テスト・リリース・運用保守という一連の工程で進みます。

それぞれの工程には明確な目的と成果物があり、前工程の完成度が後工程の品質と工数を左右します。

全体の流れを把握せずに発注すると、「追加費用が発生した」「完成物が想定と違った」といったトラブルにつながりやすくなります。

開発工程の全体像と各フェーズの位置づけ

一般的なシステム開発の工程は以下の順序で進みます。

1. 要件定義: システムで実現したいことを具体的に決める
2. 基本設計(外部設計): ユーザー視点での画面・操作・データ構造を設計する
3. 詳細設計(内部設計): プログラムの内部ロジックを詳細に設計する
4. プログラミング: 設計書に基づいてコードを書く
5. 単体テスト: 各機能・モジュール単体の動作確認
6. 結合テスト: 複数のモジュールを連携させた動作確認
7. システムテスト: システム全体が要件定義書どおりに動作するかの総合確認
8. リリース: 本番環境への移行・公開
9. 運用・保守: 稼働後のバグ対応・セキュリティ管理・機能改善

工程1〜3を「上流工程」、工程4〜9を「下流工程」と呼ぶことがあります。

上流工程での決定がシステム全体の品質を決めるため、上流工程での認識合わせと品質確保がプロジェクト成功の鍵になります。

発注側と開発会社の役割分担

上流工程(要件定義〜設計)では、発注側が積極的に関与することが求められます。

自社業務の課題や必要な機能を開発会社に正確に伝えられるかどうかが、成果物の品質に直接影響します。

担当者だけでなく、実際にシステムを使う現場スタッフも要件定義に参加することが重要です。

下流工程(コーディング〜システムテスト)は主に開発会社が進め、発注側はテスト結果の確認・中間レビューへの参加が主な役割となります。

リリース後は、運用課題を継続的にフィードバックし、追加開発や機能改善の優先順位を判断する役割を担います。発注側の関与度が高い工程ほど、最終的な品質への影響度も高くなります。

システム開発の流れ 各工程の内容と発注側が確認すべきポイント

要件定義 システムに必要な機能と要件を決める最重要工程

要件定義は、システムで「何を実現するか」を具体的に決める工程です。

機能要件(どんな画面を作るか、何を計算・処理するか)と非機能要件(処理速度・セキュリティ水準・同時接続数・可用性など)の両方を定義します。

この工程が持つ重要性は数値にも表れています。情報処理推進機構(IPA)の調査によると、工期遅延の原因の55%が要件定義の問題に起因しています。

要件の定義が曖昧なまま設計・開発を進めると、後工程での修正コストが飛躍的に増加します。

設計完了後に要件を変更した場合のコストは、要件定義段階での変更コストの数倍〜十数倍に膨らむことが知られています。

発注側の主な役割は、業務フローの整理と優先順位の明確化です。「必ず実現すべき機能」と「あったら便利な機能」を明確に区別しておくことが、予算と品質のバランスをとるうえで重要です。

主な成果物は要件定義書です。

基本設計と詳細設計 システムの外側と内側を設計する2つの工程

基本設計(外部設計)では、ユーザーが実際に触れる画面や操作の仕様を決めます。

画面レイアウト・入力項目・画面遷移・データベースの構造などを定義し、発注側にもレビューを依頼する工程です。

ここで定義した内容が最終的なシステムの使い勝手を決めるため、開発会社との密なコミュニケーションが求められます。

詳細設計(内部設計)では、基本設計をもとにプログラムの内部ロジックを詳細に設計します。

開発者向けの技術的な内容が多いため、発注側はこの工程での詳細なレビューよりも、基本設計段階での認識合わせを優先することが現実的です。

情報処理推進機構のデータでは、基本設計と詳細設計を合わせた工数は全体の約35〜40%を占めます。

設計工程に十分な時間をかけることが、後工程の品質向上とコスト削減につながります。

プログラミング 設計書をもとに実際のシステムを構築する工程

プログラミングは、設計書に基づいてソースコードを書く工程です。

一般的に「開発」と聞いてイメージしやすい工程ですが、工数全体に占める比率は約30〜33%(情報処理推進機構 ソフトウェア開発分析データ集 2022)であり、設計やテストと同等かそれ以下になることも珍しくありません。

発注側がこの工程で主に行うことは、仕様変更の依頼が生じた場合の影響範囲の確認と意思決定です。

プログラミング工程に入ってからの仕様変更は修正コストが大きくなるため、設計完了時点で仕様を固めることが望ましい姿です。

テスト 品質を段階的に確認する3段階の検証プロセス

テストは、単体テスト・結合テスト・システムテストの3段階で品質を段階的に確認します。

単体テスト(UT)は、各機能・モジュール単体が正しく動作するかをプログラマー自身が確認するテストです。

結合テスト(IT)は、複数のモジュールを連携させたときに正常に動作するかを確認します。

インターフェース間のデータの受け渡しやエラー処理が想定どおりに機能するかを検証します。

システムテスト(ST・総合テスト)は、システム全体が要件定義書の要件どおりに動作するかを確認する最終テストです。性能テストや負荷テストもこのタイミングで行われます。

受入テスト(UAT)は発注側が自ら操作して動作を確認する検収フェーズです。

ここで問題がなければ正式な検収として受け入れます。テスト工程全体の工数は、情報処理推進機構のデータによると全体の約28〜33%を占め、プログラミング工程と同程度以上の工数が割かれます。

リリースと運用保守 公開後も続く安定稼働と改善の工程

リリースは、完成したシステムを本番環境に移行・公開する工程です。

既存システムからのデータ移行やユーザーへの操作説明(トレーニング)が伴う場合もあります。

移行手順を事前に確認し、本番移行に失敗した場合の切り戻し計画を準備しておくことが大切です。

運用・保守は、システムが稼働を開始した後も続く工程です。

バグの発見と修正、セキュリティパッチの適用、法改正への対応、利用状況の分析と機能改善などが含まれます。

保守費用の目安は月額で開発費の数%〜10%程度が多く見られます。発注時点でどこまでが保守の範囲に含まれるかを契約書で確認しておくと、後からのトラブルを防げます。

工程別工数比率と費用相場の目安

情報処理推進機構のデータが示す工程別の工数比率

情報処理推進機構(IPA)が公表している「ソフトウェア開発分析データ集 2022」では、工程別の標準的な工数比率として以下のような目安が示されています。

– 要件定義: 10〜20%
– 基本設計: 約17%
– 詳細設計: 約18〜20%
– プログラミング(製造): 約30〜33%
– テスト(単体・結合・システム合計): 約28〜33%

「システム開発=プログラミング」というイメージを持ちやすいですが、設計工程とテスト工程を合わせると全工数の約60〜70%を占めます。

発注側が「プログラミングはすぐ終わるはず」という認識でスケジュールを詰めると、品質低下や手戻りの原因になります。

見積書を受け取った際は、工程ごとの工数と単価が明示されているかを確認することを推奨します。

規模別の開発費用相場と人月単価の目安

システム開発の費用は、システムの規模・機能数・開発会社のスキルや所在地によって大きく異なります。2026年時点での一般的な目安は以下のとおりです。

– 小規模(社内業務改善ツール・在庫管理等): 100〜300万円
– 中規模(部門間連携システム・ECサイト等): 500〜1,000万円
– 大規模(基幹システム・SaaS等): 1,000万円以上

人月単価の目安は60〜200万円で、若手エンジニアや地方拠点の場合は60万円前後、大手SIerのプロジェクトマネージャークラスでは200万円を超えるケースもあります。

設計工程の比重が著しく少ない見積もりや、テスト工程の工数が極端に短い見積もりは、後工程での追加費用が発生しやすい場合があります。

相見積もりをとる場合も、金額だけでなく工程ごとの工数の妥当性を比較することが重要です。

代表的な開発手法と流れの違い

ウォーターフォール型 計画を重視して工程を順番に進める手法

ウォーターフォール型は、要件定義→設計→実装→テスト→リリースという工程を一方向に順番に進める手法です。

各工程が完了してから次の工程に移るため、進捗状況が把握しやすく、スケジュールと予算の管理がしやすいというメリットがあります。

一方で、開発途中での仕様変更や追加要件への対応が難しく、設計段階での見落としが後工程で大きな手戻りを招くリスクがあります。

要件が最初から明確に定まっている大規模案件や、官公庁・金融系のシステムに向いている手法です。

アジャイル型 短いサイクルで仕様変更に柔軟に対応する手法

アジャイル型は、「スプリント」と呼ばれる2〜4週間の短い開発サイクルを繰り返しながらシステムを構築する手法です。

各スプリントで「設計→実装→テスト→レビュー」を小さな単位で行い、フィードバックを次のサイクルに反映させます。

仕様変更や追加要件に柔軟に対応できるため、要件が開発中に変化しやすいWebサービスやSaaS、スタートアップのプロダクト開発に適しています。

一方で、発注側が頻繁にレビューや意思決定に参加する必要があるため、担当者が継続的に関与できる体制が求められます。

中小企業が開発手法を選ぶ際の判断ポイント

中小企業がシステム開発を外注する際の手法選定は、以下の視点で判断することをおすすめします。

要件が最初からほぼ固まっている場合はウォーターフォール型が向いています。

予算・納期が明確であることが前提となります。

要件が変化しやすい場合や段階的にシステムを育てていきたい場合はアジャイル型が向いています。

ただし、担当者が週次〜隔週で開発チームとコミュニケーションをとれる体制が必要です。

中小企業で担当者のリソースが限られている場合は、ウォーターフォール型で要件定義を丁寧に行い、基幹部分を確実に作り上げるアプローチが現実的なケースも多くあります。

まずはスモールスタートでコアな機能のみを開発し、実際に運用しながら追加開発を行う方法も選択肢のひとつです。

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

開発会社からの提案書や打ち合わせでは、以下の略語が頻繁に使われます。

これらの意味を事前に把握しておくと、開発会社との認識合わせがスムーズになります。

略語	正式名称	意味
RD	Requirement Definition	要件定義
BD	Basic Design	基本設計(外部設計)
ED	External Design	外部設計(BDと同義)
DD	Detailed Design	詳細設計(内部設計)
ID	Internal Design	内部設計(DDと同義)
PG	Programming	プログラミング・コーディング
UT	Unit Test	単体テスト
IT	Integration Test	結合テスト
ST	System Test	システムテスト(総合テスト)
OT / UAT	Operation Test / User Acceptance Test	運用テスト・受入テスト

見積書や工程表(ガントチャート)に記載されている略語を正確に理解しておくと、「どの工程に何日かかるか」を自社で確認しやすくなります。

要件定義を正しく進めるための準備と注意点

工期遅延を招く要件定義の失敗パターン

情報処理推進機構(IPA)の調査では、工期遅延の原因の55%が要件定義の問題に起因することが明らかになっています。具体的な失敗パターンとして多いのは次の3つです。

一つ目は要件の決定漏れです。

「〇〇の機能も後で追加できますよね?」という認識のまま開発に入ってしまい、後工程で追加費用とスケジュール延長が発生するケースです。

初期の要件定義で範囲を明確にしておくことが対策になります。

二つ目は現場ユーザーの意見が反映されていないことです。

経営層や情報システム部門が要件をまとめても、実際にシステムを使う現場担当者の業務フローが考慮されていないと、完成後に「使いにくい」という問題が生じます。

要件定義の打ち合わせには現場担当者を参加させることが重要です。

三つ目は非機能要件の未定義です。画面や機能の要件は決めたが、応答速度・同時接続数・バックアップ頻度・セキュリティ基準などの非機能要件を決めないまま進めてしまうケースです。

非機能要件はシステムの品質に直結するため、要件定義の段階で明記しておく必要があります。

発注前に準備すべき3つのこと

システム開発を発注する前に準備しておくと、要件定義がスムーズに進む3つの事項があります。

1つ目は業務フローの文書化です。現在の業務をどのような手順で進めているか、どこに課題があるかを文書や図で整理しておきます。

開発会社への説明がしやすくなり、要件の決定漏れを防ぐことができます。

2つ目は「必須機能」と「あると便利な機能」の峻別です。予算には限りがあるため、フェーズ1で実現すべき機能と後回しにする機能を事前に決めておきます。

開発会社との見積もり交渉でも、優先順位が明確になっているとコスト調整がしやすくなります。

3つ目はRFP(提案依頼書)の準備です。RFPには開発の背景・目的・要件の概要・スケジュール・予算の目安を記載します。

複数社への相見積もりを取る場合、RFPがあることで各社からの提案内容を同一の基準で比較できます。

AI活用によってシステム開発の流れはどう変わるか

2026年現在、AIツールの活用がシステム開発の各工程に影響を与え始めています。

プログラミング工程では、GitHub CopilotなどのAIコーディング支援ツールが普及しており、ボイラープレートコードや単純な処理の自動生成が可能になっています。

開発会社によっては、コーディング工数を2〜3割削減できたという事例が報告されており、見積もりに反映される形でコスト削減につながるケースも出てきています。

テスト工程でも、AIを活用したテストコードの自動生成や、バグ検出の支援ツールが登場しています。

単体テストの一部を自動化することで、品質を保ちながらテスト工数を抑えるアプローチが広がりつつあります。

要件定義工程でも、自然言語で要件を入力するとユーザーストーリーや機能一覧を生成するAIツールが使われ始めています。

ただし、AIが生成した要件をそのまま採用するのは危険で、業務の実情に合わせた確認・修正が不可欠です。

中小企業基盤整備機構の「中小企業のDX推進に関する調査(2025年)」によると、中小企業でAIを活用している企業は28.4%で、前回調査から14.1ポイント増加しています。

AI活用の広がりを受け、開発会社への発注時にはAIツールの活用有無や、それによる工数・費用の変化についても確認することが今後重要になります。

一方で、AIがシステム開発の全工程を自動化するわけではありません。

要件定義・設計・テスト設計・プロジェクト管理における人間の判断と関与は引き続き不可欠です。

AI活用によって開発の一部が効率化しても、工程の全体像と各フェーズの目的を理解しておくことの重要性は変わりません。

発注側としてAIの活用状況を確認しながら、見積もりや工程表の妥当性を判断できる知識を持っておくことが、今後のシステム発注に役立ちます。

システム開発の流れは、どの工程をどのような順序で進めるかを正しく理解するだけで、開発会社との認識ずれを防ぎ、プロジェクトの成功確率を高めることができます。

要件定義から運用保守まで、各工程で発注側が何をすべきかを把握したうえで依頼することが、期待どおりのシステムを納期と予算内で手に入れるための第一歩です。

システム開発の進め方や発注の流れについて詳しく相談したい場合は、Dimebiz にお気軽にお問い合わせください。