システム開発の全工程・流れを解説！失敗しない手順とプロセス・フロー

システム開発の工程とは、企画・要件定義から設計・開発・テスト・リリース・保守運用までの一連のプロセスを指します。

本記事は、開発会社への発注に不安を感じる、大手企業の経営企画・DX推進室の責任者の方に向けて、各工程の概要と発注者として押さえるべき勘所を解説します。

読了後には、各工程で発注者として何を準備し、どこで意思決定すべきかが整理できます。

システム開発の工程・プロセスとは？

工程理解の土台となる「V字モデル」と代表的な2つの開発手法(ウォーターフォール／アジャイル)を整理します。

開発をスムーズに進めるためには、まずこうした基本的な枠組みや手法の特徴を理解しておくことが大切です。 

システム開発の工程は、独立行政法人情報処理推進機構（IPA）の「共通フレーム2013」で定義され、企画・要件定義から保守・運用までの7工程で整理するのが一般的です。

システム開発における「V字モデル」の重要性

V字モデルは、開発の各設計工程と対応するテスト工程を「V字」で対応づけるフレームワークです。要件定義は受入テスト（UAT）と、基本設計は結合テストと、詳細設計は単体テストと対になります。

上流の要件定義の品質はプロジェクト全体のコストを左右します。Barry BoehmとVictor Basili「Software Defect Reduction Top 10 List」（IEEE Computer, 2001）では、欠陥を上流で除去することは下流での修正に比べて10〜100倍効率的とされています。

代表的な2つの開発手法

システム開発の工程は、選択する開発手法によって順序や粒度が変わります。代表的な手法はウォーターフォールとアジャイルの2つで、要件の安定度に応じて使い分けます。

ウォーターフォール

ウォーターフォールは、要件定義→設計→開発→テスト→リリースの順に上流から下流へ一方向に進める手法です。各工程の成果物を確定させてから次工程に進むため、要件が安定した大規模刷新に向いています。

アジャイル

アジャイルは、1〜4週間程度のスプリントで「設計・開発・テスト・リリース」を反復し、動くシステムを早期に提供する手法です。要件の変化に強く、新規事業やプロダクト開発に向きます。

【全7工程】システム開発の流れ・手順

ウォーターフォール型を前提とした以下7工程について、発注者が各段階で確認・準備すべき内容を整理します。

• 工程1. 企画・要件定義
• 工程2. 基本設計（外部設計）
• 工程3. 詳細設計（内部設計）
• 工程4. 開発（プログラミング）
• 工程5. テスト（単体・結合・総合）
• 工程6. リリース・導入
• 工程7. 保守・運用

ここからは、それぞれの工程で具体的にどのような作業が行われ、発注者として何に気をつけるべきかを詳しく見ていきましょう。 

工程1. 企画・要件定義

プロジェクトの目的・業務課題を整理し、機能要件と非機能要件を定義する工程です。この要件定義書の品質が、プロジェクト全体の成否を決めると言っても過言ではありません。 

発注者がこの段階で確認・準備すべきこと

発注者の役割は、ビジネス課題の言語化と意思決定者の巻き込みです。手戻り防止のため、以下を発注者主導で進めます。

• プロジェクトのKPI・業務課題の言語化
• 現行業務フロー(As-Is)と将来像(To-Be)の整理
• 意思決定者・現場ユーザーの巻き込み
• 予算・納期の上限の合意

これらの土台をしっかり固めておくことが、後々の手戻りを防ぐ最大の防御策になります。 

工程2. 基本設計（外部設計）

要件定義書をもとに画面・帳票・操作の流れを設計する工程です。画面遷移図・画面項目定義・外部連携仕様が主な成果物となります。

発注者がこの段階で確認・準備すべきこと

画面・外部連携の仕様が業務に合うかを検証する工程です。設計段階の見落としは追加コストに直結しかねません。 

• 画面モックアップが現場の動線と合っているか
• 外部システムとの連携仕様に齟齬がないか
• 帳票・出力データが業務で使える粒度か
• 現場ユーザーを入れた画面レビュー実施

この段階で現場のリアルな意見をしっかり取り入れておくことで、リリース後に使い勝手の良いシステムに近づきます。 

工程3. 詳細設計（内部設計）

基本設計を実装可能な粒度まで分解し、データ構造・処理ロジック・モジュール分割を設計する工程です。データ項目の定義漏れの早期発見が必要となります。

発注者がこの段階で確認・準備すべきこと

技術作業が中心の工程ですが、データ項目の定義漏れは後工程で重大な手戻りを招きます。以下を確認しましょう。

• データモデル(ER図)に必要項目が網羅されているか
• 既存システムからのデータ移行範囲が明確か
• 業務部門代表者の設計レビュー参加体制

専門的な内容が増えますが、業務部門側からも積極的にレビューに参加できる体制を作っておくことがプロジェクト成功の鍵です。 

工程4. 開発（プログラミング）

詳細設計に基づきソースコードを実装する工程です。発注者は進捗の可視化と仕様変更時のルール運用に関与します。

発注者がこの段階で確認・準備すべきこと

開発会社の作業が主体ですが、進捗の透明性と変更管理は発注者の責任です。能動的に体制を整えていきましょう。

• WBSに基づく週次の進捗確認
• 変更管理プロセスの運用
• モジュール単位の中間レビュー参加

開発会社に任せきりにするのではなく、定期的に状況を把握して一緒にプロジェクトを進める意識を持つことが大切です。 

工程5. テスト（単体・結合・総合）

単体テスト→結合テスト→総合テスト→受入テスト(UAT)の順に実施する工程です。受入テストは発注者の責任となります。

発注者がこの段階で確認・準備すべきこと

受入テストの準備が発注者の主担当です。事前準備の質がリリース可否の判断を左右します。

• UATシナリオを業務部門と合意済みか
• バグ優先度判断基準を事前合意
• 本番想定の規模でのテスト環境確保

本番さながらの環境とシナリオで徹底的にテストを行うことが、リリース直後のトラブルを未然に防ぐ要となります。 

工程6. リリース・導入

システムを本番環境に展開し、利用者へ提供する工程です。データ移行と運用切替が最大のリスクポイントとなります。

発注者がこの段階で確認・準備すべきこと

データ移行と運用切替が最大のリスクです。切戻し判断ルールを事前に固めることで現場混乱を最小化できます。

• データ移行の事前リハーサル(最低2回)
• 旧システムとの並行稼働期間と切替判断基準
• 現場ユーザー向け操作研修・マニュアル整備
• 障害時の連絡体制と切戻し判断ルール

万が一のトラブルに備えて、素早く元の状態に戻せる「切戻し」のルールをあらかじめ決めておくと安心です。 

工程7. 保守・運用

システム稼働後、不具合対応・利用者サポート・機能改修を継続的に実施する工程です。長期では開発費の数倍を占めるため計画段階での見積りが重要となります。

発注者がこの段階で確認・準備すべきこと

予算化が後手になりやすい工程です。改善要望の優先順位付けの仕組みを早期設計することで投資効果を維持できます。

• 保守・運用の責任範囲(一次対応・二次対応)
• 月次運用レポートと改善要望の起票プロセス
• 中長期での機能拡張の優先順位付けの仕組み

リリースして終わりではなく、システムを育てていくための予算と運用体制をあらかじめ計画しておくことが重要です。 

アジャイル開発の場合の工程の違い

ウォーターフォール型との違いを以下3点で整理します。

• スプリント単位のサイクル・各工程の粒度の違い
• ウォーターフォールとの違い
• アジャイルで発注者が特に注意すべき点

柔軟性が高い手法である分、発注者側にもウォーターフォールとは違った形での積極的な関与が求められます。 

スプリント単位のサイクル・各工程の粒度の違い

アジャイル型では要件定義から開発・テスト・リリースまでを1〜4週間の「スプリント」で反復します。各スプリント末に発注者へ動作デモを行い、優先順位を協議します。

ウォーターフォールとの違い

両者の主要な違いを以下の比較表で整理してみましょう。

観点	ウォーターフォール	アジャイル
計画の確定タイミング	プロジェクト開始時に全体確定	スプリントごとに更新
仕様変更への対応	変更管理プロセスで都度判断	次スプリント以降で柔軟に反映
主要な成果物	工程ごとの確定ドキュメント	動くシステム(インクリメント)
向いている案件	要件が安定した大規模刷新	要件が流動的な新規開発
発注者の関与頻度	工程の節目(中〜低頻度)	スプリントレビューで継続的

アジャイルで発注者が特に注意すべき点

アジャイルは「丸投げ」と相性が悪い手法です。優先順位を判断するプロダクトオーナーを発注者側で確保できるかが成否を分けます。社内に該当人材がいない場合は、外部パートナーに代行や育成を依頼する選択肢が現実的です。

システム開発のフローでよくある失敗パターンと対処法

現場で頻出する以下3つの失敗パターンと対処法を解説します。

• 失敗1. 要件定義の甘さによるトラブル
• 失敗2. 度重なる仕様変更によるスケジュール遅延・コスト超過
• 失敗3. 現場の意見を無視した設計

失敗から学び、同じ轍を踏まないように事前に対策を打っておくことが成功への近道です。 

失敗1. 要件定義の甘さによる「言った・言わない」のトラブル

要件定義書に記載されない曖昧な合意が後工程でトラブル化し、追加費用と納期遅延を招くパターンです。

対処法は、合意事項を要件定義書・議事録に明記し、双方承認の版数管理を行うことです。あわせて、契約書には契約不適合責任の範囲と期間を明記しておきましょう。 

失敗2. 開発途中の度重なる仕様変更によるスケジュール遅延・コスト超過

当初の要件定義から外れる変更が変更管理プロセスを経ずに開発投入され、納期遅延と費用超過を招くパターンです。

対処法は変更管理ルールを契約段階で合意することです。変更内容・影響範囲・追加工数・追加費用を「変更管理票」で承認する運用を定型化し、一定金額（例：50万円）以上は経営層承認を必須とするなどの工夫が効果的です。 

失敗3. 現場の意見を無視した設計による「リリース後に使われない」システム

経営層と情報システム部門だけで要件を固め、現場の声を取り入れず開発した結果、「投資効果ゼロ」のシステムが生まれるパターンです。

対処法は、企画段階から現場のキーマンをメンバーに組み込み、画面モックアップで早期フィードバックを得ることです。

システム開発で知っておくべき略語・専門用語

開発会社との打ち合わせで頻出する略語を3カテゴリに整理します。

• プロジェクト管理・マネジメント用語
• 開発手法・フレームワーク用語
• 設計・技術要素用語

これらの言葉を理解しておくだけで、ベンダーが作成した資料やミーティングの内容が格段に理解しやすくなります。 

プロジェクト管理・マネジメント用語

プロジェクトの進行・契約・体制に関わる用語です。発注者が頻繁に使用します。

RFP（提案依頼書）

RFP(Request For Proposal)は、発注者が課題・要件・予算・納期を示し開発会社に提案書を依頼する文書です。

RFI（情報提供依頼書）

RFI(Request For Information)は、RFPの前段階で開発会社の対応技術領域や実績を確認する文書です。

PM / PMO（プロジェクトマネージャー / 支援事務局）

PM(Project Manager)はプロジェクト責任者、PMO(Project Management Office)はその支援組織を指します。

WBS（作業分解構成図）

WBS(Work Breakdown Structure)は、プロジェクト作業を階層的に分解した図表で、進捗・工数管理の基本となります。

SLA（サービスレベル合意書）

SLA(Service Level Agreement)は、稼働率や障害対応時間などのサービス水準を文書化した合意書です。

ROI（投資対効果）

ROI(Return On Investment)は、投資額に対する効果を百分率で示す指標で、稟議資料で必須となります。

開発手法・フレームワーク用語

開発の進め方や設計思想に関する用語です。提案書・設計書で頻出します。

MVP（実用最小限の製品）

MVP(Minimum Viable Product)は、顧客課題の検証に必要な最小限の機能だけを実装した製品で、新規事業の検証に用います。

PoC（概念実証）

PoC(Proof of Concept)は、新技術やビジネスモデルの実現可能性を小規模に検証する取り組みで、本格開発の前段階に実施します。

Agile（アジャイル）

Agileは短いサイクルで反復開発を進める手法の総称で、スクラム・カンバン・XPなどのフレームワークがあります。

DevOps（デブオプス）

DevOpsは開発(Development)と運用(Operations)の連携を強化する文化・手法で、リリース頻度と安定性を両立します。

CI/CD（継続的インテグレーション / デリバリー）

CI/CD(Continuous Integration / Continuous Delivery)は、コード統合・テスト・デプロイを自動化し頻繁なリリースを可能にする仕組みです。

設計・技術要素用語

システムの設計や技術構成に関する用語です。発注者の理解がベンダー任せ回避につながります。

UI / UX（ユーザーインターフェース / ユーザーエクスペリエンス）

UI(User Interface)は画面・操作の見た目を、UX(User Experience)は利用者が得る体験全体を指します。

API（アプリケーション・プログラミング・インターフェース）

API(Application Programming Interface)は、システム同士が機能を呼び出すための仕様で、SaaS連携・基幹系連携の前提です。

SaaS / PaaS / IaaS

SaaSはソフト、PaaSは開発基盤、IaaSはサーバ・ストレージを月額利用する形態で、それぞれSoftware／Platform／Infrastructure as a Serviceの略です。

QA（品質保証）

QA(Quality Assurance)は、開発プロセス全体で品質を担保する活動の総称で、要件定義・設計レビューから関与します。

UAT（受入テスト）

UAT(User Acceptance Test)は、発注者が業務観点で実施する最終テストで、本番想定シナリオで業務遂行可否を検証します。

Legacy System（レガシーシステム）

Legacy Systemは、長期運用で技術的負債が蓄積し保守・拡張が困難になった既存システムで、経済産業省「DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～」で論点となった刷新対象です。

Microservices（マイクロサービス）

Microservicesは、システムを独立デプロイ可能な小さなサービス群に分割する手法で、スケーラビリティと保守性の両立を狙います。

開発工程で外注先に確認すべきチェックリスト

各工程フェーズで発注者が外注先に確認しておくべき項目を整理します。 契約前にこれらを書面で合意しておくことで、後工程でのトラブルを未然に防げます。

企画・要件定義フェーズで確認すべきこと

• 要件定義書の成果物範囲（業務フロー図・画面遷移図・データモデルのどこまで含むか）
• 要件定義の進め方（ヒアリング回数・議事録の作成責任・合意プロセス）
• プロジェクト体制（PM・エンジニアの経歴、途中交代時の引継ぎルール）
• 変更管理のルール（追加要件が発生した場合の費用・納期への影響の取り決め）

開発・テストフェーズで確認すべきこと

• 進捗報告の頻度と形式（週次報告書・プロジェクト管理ツールの共有範囲）
• 課題発生時の初動ルール（起票から一次回答までの対応時間の目安）
• テスト計画の範囲（単体・結合・総合テストの実施責任と、受入テスト（UAT）の支援範囲）
• 中間成果物のレビュー機会（モジュール単位のデモや中間レビューの有無）

リリース・保守フェーズで確認すべきこと

• 納品物の一覧（ソースコード・設計書・テスト報告書・運用マニュアルのどこまで含むか）
• リリース後の不具合対応期間と範囲（無償対応の期限・対応範囲の定義）
• 保守・運用の体制と費用（一次対応・二次対応の責任分担、月額費用の目安）
• 将来の改修・拡張に備えた引継ぎ（ドキュメント整備義務の有無）

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

発注者の方からよくいただく以下3つの質問にお答えします。

• 大手企業のDX推進において、どの工程が最も重要ですか？
• 開発会社との適切なコミュニケーション頻度はどのくらいですか？
• 開発工程の途中で仕様変更が必要になった場合、どう対処すべきですか？

多くの方が疑問に感じるポイントですので、ぜひプロジェクトを進める際の参考にしてみてください。 

大手企業のDX推進において、どの工程が最も重要ですか？

最も重要なのは要件定義です。

Boehm & Basili(IEEE Computer, 2001)では上流での欠陥除去は下流の10〜100倍効率的とされ、要件定義の品質がプロジェクト全体のコストと納期を決めます。業務部門キーマンを巻き込み業務フローを言語化することが投資効果を左右します。

開発会社との適切なコミュニケーション頻度はどのくらいですか？

ウォーターフォール型では工程の節目ごとの定例(月1〜2回)が基本ですが、要件定義・基本設計・受入テスト準備の3局面では週1回以上を推奨します。

アジャイル型ではスプリントレビュー(1〜2週間に1回)への参加が前提です。課題発生時の初動応答は24時間以内の一次回答をSLAで合意しておくと安心です。

開発工程の途中で仕様変更が必要になった場合、どう対処すべきですか？

変更管理プロセスを経由させることが原則です。

変更内容・影響範囲・追加工数・追加費用・変更後納期を「変更管理票」に整理し、発注者の決裁印で承認後に開発投入します。一定金額(例:50万円)以上は経営層承認を必須とするルールを契約段階で合意しておくべきです。

まとめ：システム開発の工程を理解し、失敗しないプロジェクト推進を

システム開発の工程は7工程に整理され、ウォーターフォール型かアジャイル型の選択で進め方が変わります。発注者として最も重要なのは、要件定義の段階で業務部門のキーマンを巻き込み、要件を文書化することです。

Incubation Baseは、新規事業開発・システム開発・DX支援の3軸で、シニアコンサルタントが要件定義から実装まで伴走型で支援しています。要件定義の壁打ちや体制構築のご相談は、無料の個別相談からお問い合わせください。