システム開発工程とは？7つの流れと発注側の役割を解説

システム開発工程とは、システムを企画してから運用に至るまでの作業を、目的ごとに区切って順序立てたものです。一般的には企画・要件定義・設計・開発・テスト・リリース・運用保守の7つの工程で構成され、開発手法によって工程の進め方が変わります。そこで本記事では、手法ごとの工程の流れと、各工程で発注側と開発会社が担う役割を解説します。あわせて、打ち合わせで頻出する略語と、開発会社の工程管理を見極めるポイントも紹介します。

システム開発工程とは？

システム開発工程とは、「何を作るか決める」「どう作るか決める」「作る」「確かめる」「使い続ける」という流れを、成果物と責任範囲が明確になるよう区切ったものです。このように工程を区切ると、各段階の完了基準と承認のタイミングがはっきりします。その結果、発注側と開発会社の認識のずれを早い段階で見つけられます。

システム開発の7つの工程

代表的なシステム開発工程は次の7つです。なお、名称や区切り方は開発会社によって多少異なりますが、全体の流れは共通しています。

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

上流工程と下流工程の違いは、「何を作るかを決める工程」か「決まった仕様を形にする工程」かにあります。具体的には、それぞれの範囲と特徴は次のとおりです。

このため、発注側の関与がもっとも求められるのは上流工程です。反対に、下流工程に入ってからの仕様変更ほど、スケジュールと費用への影響が大きくなります。

発注側がシステム開発工程を理解すべき理由

発注側がシステム開発工程を理解すべき理由は、外部に依頼しても要件の決定と成果物の承認の責任が発注側に残るためです。したがって、工程の全体像を知らないまま進めると、次の3つのリスクが生じます。

• 判断が遅れる：どの時点で何を決めるべきかが分からず、承認待ちでスケジュールが止まる
• 認識がずれる：要件定義で業務の前提を伝えきれず、テスト段階で「想定と違う」と気づく
• 見積もりを比較できない：開発会社ごとに含まれる工程が異なり、費用の妥当性を判断できない

つまり、工程ごとに「誰が何を決め、何を受け取るのか」を把握することが、発注前のリスクを減らす第一歩です。

システム開発工程の4つの開発手法

開発手法は、システム開発工程の並べ方と繰り返し方を決める枠組みです。たとえば同じ7つの工程でも、順番どおり一度に進めるか、小さな単位で繰り返すかによって、発注側の関わり方と契約形態が変わります。まずは、代表的な4つの手法の違いを確認しましょう。各手法の特徴は次のとおりです。

手法	工程の進め方	向いているケース	相性のよい契約形態
ウォーターフォール	工程を上流から順に1回ずつ進める	要件が開発前に固まる基幹システム、法規制対応	請負契約
アジャイル	計画〜テストを1〜4週間の短い周期で繰り返す	要件が変わりやすい新規サービス、Webアプリ	準委任契約（ラボ型）
スパイラル	機能単位で設計〜テスト〜評価を繰り返し、完成度を高める	大規模で、リスクを段階的に確認したいシステム	準委任契約、または工程ごとの請負
プロトタイプ	試作品で画面や操作性を確認してから本開発に入る	UIの比重が大きいシステム、要件が言語化しにくいケース	試作は準委任、本開発は請負など

表1: 主な開発手法と工程の進め方の違い

特に、要件を事前に固めやすい基幹システムの開発では、ウォーターフォール型が広く採用されています。一方で、上流と下流をウォーターフォールで固め、実装部分をアジャイルで進めるハイブリッド型を採用するプロジェクトも増えています。なお、2つの代表的な手法の違いは、ウォーターフォールとアジャイルの違いで詳しく比較しています。

ウォーターフォール型のシステム開発工程

ウォーターフォール型は、7つの工程を上流から順に一度ずつ進め、前の工程の成果物を承認してから次へ進む手法です。また、全体の費用と納期を事前に見通しやすく、成果物が文書として残ります。そのため、基幹システムや品質要求の高いシステムで多く採用されています。

企画

企画工程では、発注側がシステム化の目的と範囲を決め、投資判断の材料をそろえます。具体的には、解決したい業務課題、期待する効果、予算の上限、希望時期を整理します。一方、開発会社は提案依頼書（RFP）をもとに、実現方式の提案と概算見積もりを提示します。

ただし、目的があいまいなまま進むと、後の工程で機能の優先順位を判断できなくなります。そのため、「何を実現すれば成功か」を、企画の段階で言語化しておきましょう。

要件定義

要件定義工程では、システムが満たすべき機能・性能・セキュリティの条件を確定し、要件定義書として合意します。まず、発注側は現行の業務フロー、例外処理、利用者数、連携する既存システムの情報を提供し、要件の優先順位を決めます。次に、開発会社はヒアリングで要件を整理・文書化し、実現性と費用への影響を説明します。

要件定義は「何を作るか」が決まる最も重要な工程です。特に、業務の暗黙知を伝えきれないと、テスト段階で認識のずれが見つかり、大きな手戻りにつながります。

設計（基本設計・詳細設計）

設計工程では、要件をシステムの仕様に変換します。具体的には、設計は利用者から見える部分を決める基本設計と、内部の処理を決める詳細設計に分かれます。まず基本設計では画面レイアウト、帳票、データ項目、外部システムとの連携方式を決め、発注側が業務で使える内容かを確認して承認します。

次に、詳細設計では、プログラムの構造や処理手順を決めます。詳細設計は技術的な工程で、主に開発会社が担います。つまり、設計書の承認は、開発に入る前に仕様を確定させる最後の機会です。

開発（実装）

開発工程では、開発会社が詳細設計書にもとづいてプログラムを作成します。その際、開発会社はコーディング規約とコードレビューで品質を保ち、発注側は定例会議で進捗報告を受けて仕様の質問に回答します。ただし、この段階での仕様変更は、設計書の修正と再見積もりを伴うため、変更管理の手順に沿って判断します。

テスト

テスト工程では、単体テスト・結合テスト・システムテスト・受け入れテストの順に範囲を広げ、要件と設計どおりに動くかを確認します。このうち、単体テストからシステムテストまでは開発会社が実施し、結果をテスト報告書として提出します。そして最後の受け入れテスト（UAT）は発注側が主体となり、実際の業務シナリオでシステムを操作して合否を判断します。

また、ウォーターフォール型では、設計工程とテスト工程を対応づけた「V字モデル」の考え方を使います。つまり、要件定義はシステムテストと受け入れテストで、基本設計は結合テストで、詳細設計は単体テストで確認します。

リリース（移行）

リリース工程では、完成したシステムを本番環境に展開し、利用を開始します。まず開発会社は本番環境の構築、データ移行、切り替え手順書の作成を担当します。一方、発注側は切り替え日の決定、利用者への周知と操作研修、問題発生時に旧システムへ戻すかどうかの判断基準を準備します。さらに、業務への影響を抑えるため、一部の部門から段階的に展開する方法もあります。

運用・保守

運用・保守工程では、稼働中のシステムを監視し、障害対応・不具合修正・機能改善を続けます。具体的には、発注側は改善要望を集約して優先順位をつけ、開発会社は監視、障害の一次対応、OSやミドルウェアの更新を担います。なお、保守契約の範囲と、障害発生時の初動対応までの時間は、リリース前に取り決めておきましょう。

工程別に見る発注側と開発会社の役割

ウォーターフォール型の役割分担を工程別にまとめると、次のとおりです。また、この表は発注側の担当者がどの時期に工数を割くべきかの目安になります。

工程	発注側の主な役割	開発会社の主な役割	主な成果物
企画	目的・予算・時期の決定、RFPの作成	提案、概算見積もり	企画書、提案書
要件定義	業務情報の提供、要件の優先順位づけ、承認	ヒアリング、要件の整理・文書化	要件定義書
設計	業務視点での設計書レビューと承認	基本設計・詳細設計の作成	設計書（基本・詳細）
開発	進捗確認、仕様に関する質問への回答	実装、コードレビュー	ソースコード
テスト	受け入れテストの実施と合否判断	単体〜システムテストの実施	テスト仕様書、テスト報告書
リリース	切り替え判断、利用者への周知・研修	本番環境構築、データ移行	移行計画書、操作マニュアル
運用・保守	改善要望の集約、優先順位づけ	監視、障害対応、改修	運用手順書、障害報告書

表2: ウォーターフォール型の工程別役割分担

ウォーターフォール型は請負契約と組み合わせることが多く、開発会社が仕様書どおりの完成に責任を負います。たとえばカオピーズの請負型では、納品後6ヶ月間の品質保証を付けています。

アジャイル型のシステム開発工程

アジャイル型は、優先度の高い機能から順に、計画・設計・実装・テストを1〜4週間の短い周期（スプリント）で繰り返す手法です。たとえば代表的なフレームワークであるスクラムでは、スプリントを1か月以内の固定された期間と定めています（Schwaber and Sutherland, 2020）。そのため、スプリントごとに動くソフトウェアを確認でき、要件が変わりやすい新規サービスに適しています。

↻ 計画から振り返りまでを1〜4週間ごとに繰り返し、必要な機能がそろった段階でリリース

プロダクトビジョンとバックログの作成

アジャイル型の最初の工程では、システムで実現したい価値（プロダクトビジョン）と、必要な機能の一覧（プロダクトバックログ）を作成します。このとき、発注側はプロダクトオーナー（PO）として、機能の優先順位を決めます。一方、開発会社は機能の見積もりと技術的リスクの洗い出しを担います。なお、ウォーターフォール型の要件定義と異なり、この時点ですべての仕様を確定させる必要はありません。

スプリント計画

スプリント計画では、開発チームとPOが次のスプリントで開発する機能と、その完了条件を決めます。次に、開発チームは作業量を見積もり、POと合意してからスプリントを開始します。特に、完了条件（Definition of Done）があいまいだと「できた」の認識が合わず、レビューで差し戻しが続きます。

設計・実装・テスト（スプリントの実行）

スプリント期間中、開発チームは設計・実装・テストを並行して進めます。また、チームは毎日短いミーティング（デイリースクラム）で進捗と課題を共有します。一方、発注側には仕様の質問への迅速な回答が求められ、回答の遅れはそのままスプリントの遅れにつながります。

スプリントレビューと振り返り

スプリントレビューでは、発注側が完成した機能を実際に操作して確認し、次に作る機能の優先順位を見直します。あわせて、開発チームは振り返り（レトロスペクティブ）で進め方の改善点を洗い出し、次のスプリントに反映します。つまり、発注側にとって、スプリントレビューは要望と実装のずれを早期に見つけられる最も重要な場です。

リリースと継続的な改善

アジャイル型では、必要最小限の機能でリリースし、利用状況を見ながら改善を続けるのが一般的です。ただし、リリース後も同じチームが開発を続けることが多く、運用・保守と機能追加の境界があいまいになりやすい点に注意が必要です。

アジャイル型は仕様変更を前提とするため、準委任契約やラボ型開発と相性のよい手法です。なお、準委任契約は成果物の完成ではなく、作業の遂行に対して対価を支払う契約です。専任チームで継続的に開発する体制については、ラボ型開発のページで紹介しています。

スパイラル型のシステム開発工程

スパイラル型は、システムを機能単位に分け、「計画→リスク分析→開発・テスト→評価」のサイクルを繰り返して完成度を高める手法です。具体的には、1周ごとにリスクを確認し、次の周で何を作るかを判断します。そのため、規模が大きく技術的な不確実性が高いシステムに向いています。また、1周の流れは、次の4つの段階で構成されます。

このようにスパイラル型はリスクを段階的に減らせる一方、サイクルの回数が増えると期間と費用が膨らみやすくなります。そのため、発注側と開発会社は、周回ごとに「どこまで完成すれば次に進むか」の判断基準を合意しておくことが大切です。

プロトタイプ型のシステム開発工程

プロトタイプ型は、本開発の前に画面や主要機能の試作品（プロトタイプ）を作り、発注側が実際に触って確認してから仕様を確定する手法です。特に、文章だけでは要件を伝えにくいシステムや、操作性が業務効率を左右するシステムで効果を発揮します。

まず、試作の段階で、発注側はすべての要件を固める必要はありません。たとえば「現場が迷わず操作できるか」「必要な情報が一画面で見られるか」など、試作で答えを出したい問いを明確にします。また、開発会社はデータベースや外部連携を実装せず、見た目と操作の流れの確認に絞って試作品を作るのが一般的です。

さらに、評価の段階に現場の担当者が参加するかどうかで、本開発後の手戻りの量は大きく変わります。なお、本開発はウォーターフォール型で進めることが多く、プロトタイプで合意した画面が基本設計の土台になります。

ただし、プロトタイプ型で注意したいのは、完成度の高い試作品が「ほぼ完成している」と誤解されやすい点です。つまり、試作品は確認用であり、本番で使うにはセキュリティや性能を含めた本開発が必要です。そのため、この前提を、社内の関係者にも共有しておきましょう。

システム開発工程で知っておきたい略語一覧

開発会社との打ち合わせでは、システム開発工程やテストを2〜3文字の略語で呼ぶのが一般的です。そのため、略語の意味を押さえておくと、スケジュール表や見積書の内容を正確に読み取れます。ただし、同じ工程でも会社によって呼び方が異なるため、初回の打ち合わせで用語の定義をそろえておくと確実です。

工程を表す略語

工程を表す略語には、RD・BD・UT・STなどがあります。これらは特に、スケジュール表やWBS（作業分解構成図）の工程名として頻繁に登場します。

略語	正式名称	意味
SP	System Planning	システム企画。目的・範囲・予算の大枠を決める
RD	Requirements Definition	要件定義。必要な機能・性能などの条件を確定する
BD	Basic Design	基本設計。画面・帳票・データなど利用者から見える仕様を決める。外部設計（ED）とほぼ同義
DD	Detailed Design	詳細設計。プログラムの構造や処理を決める。内部設計（ID）とほぼ同義
PG / CD	Programming / Coding	製造。設計書にもとづいてプログラムを作成する
UT	Unit Test	単体テスト。機能・部品ごとに動作を確認する
IT	Integration Test	結合テスト。複数の機能をつなげて連携を確認する
ST	System Test	システムテスト（総合テスト）。システム全体が要件どおりか確認する
UAT / OT	User Acceptance Test / Operation Test	受け入れテスト・運用テスト。発注側が実業務に近い形で確認する

表3: 工程を表す主な略語

プロジェクト運営で使われる略語

一方、プロジェクト運営で使われる略語には、RFP・WBS・PM・POなどがあり、提案書や進捗管理の資料で体制や進め方を説明する際に使われます。

略語	正式名称	意味
RFP	Request for Proposal	提案依頼書。発注側が開発会社に提案と見積もりを求める文書
WBS	Work Breakdown Structure	作業を細かく分解し、担当と期限を割り当てた計画表
PM	Project Manager	プロジェクト全体の進捗・品質・費用に責任を持つ管理者
PO	Product Owner	アジャイル型で、機能の優先順位を決める責任者。発注側が担うことが多い
PoC	Proof of Concept	概念実証。本開発の前に技術や効果を小規模に検証すること
SLA	Service Level Agreement	運用・保守での対応時間や稼働率などの品質保証の取り決め
BrSE	Bridge System Engineer	ブリッジSE。オフショア開発で、日本側と海外の開発チームをつなぐエンジニア

表4: プロジェクト運営で使われる主な略語

発注前にシステム開発会社の工程管理を見極める5つのポイント

開発会社の実力は、技術力や実績だけでなく、システム開発工程をどう管理しているかに表れます。そのため、発注側は提案や見積もりの段階で次の5つを確認すると、発注後に進め方の違いで揉めるリスクを減らせます。

工程ごとの成果物と完了基準が示されているか

発注側は、提案書や見積書に工程ごとの成果物と完了基準が明記されているかを確認します。たとえば「設計一式」「テスト一式」とだけ書かれている見積書では、どの文書が納品され、発注側がいつ承認するのかが分かりません。反対に、要件定義書や基本設計書、テスト報告書まで具体的に示す会社ほど、工程管理が標準化されています。

要件定義への関与の仕方が具体的か

発注側は、開発会社が要件定義の進め方を具体的に説明できるかを確認します。具体的には、ヒアリングの回数や参加者、業務フローの整理方法までが判断材料です。一方、要件定義を発注側に任せきりにする会社や、ヒアリングを省いて見積もりを出す会社では、後工程の手戻りが起きやすくなります。

仕様変更の手順と費用の扱いが明確か

発注側は、開発途中の仕様変更について、影響の評価者と見積もり・承認の手順が決まっているかを確認します。特に、変更管理のルールがないと、口頭での依頼が積み重なり、最後に想定外の追加費用が発生します。そのため、契約形態（請負か準委任か）と変更時の扱いは、セットで説明を受けましょう。

品質を確認する仕組みがあるか

発注側は、コードレビュー、テストの範囲、不具合の管理方法、納品後の保証期間を確認します。また、ISO 9001などの品質マネジメント認証の有無や、テスト報告書のサンプルも判断材料になります。さらに、サンプルを見ると、品質管理の仕組みが実際に運用されているかを判断しやすくなります。

報告と意思疎通の体制が整っているか

発注側は、定例会議の頻度、進捗報告の形式、窓口の担当者、問い合わせへの回答時間を確認します。特にオフショア開発では、日本語で要件の背景まで理解して伝えられるブリッジSE（BrSE）の有無が、認識のずれを防ぐ鍵になります。

最後に、5つの観点を開発会社への質問の形にまとめると、次のとおりです。また、複数社を比較する際のチェックリストとして活用できます。

開発会社の工程管理を見極めるチェックリスト（カオピーズ作成）

なお、開発会社の候補を比較する観点については、システム開発会社おすすめ25選と失敗しない選び方もあわせて参考にしてください。

システム開発工程でよくある5つの問題と対策

システム開発工程のトラブルの多くは、技術的な問題よりも、工程の進め方や発注側との合意の不足から生じます。代表的な5つの問題について、原因と対策を整理します。

まとめ

システム開発工程は、企画・要件定義・設計・開発・テスト・リリース・運用保守の7つで構成され、開発手法によって進め方が変わります。また、プロジェクトの成否は、発注側が各工程で何を決め、何を確認するかに大きく左右されます。したがって、工程管理を具体的に説明できる開発会社を選ぶことが、手戻りや追加費用を防ぐ最も確実な方法です。

自社に合う開発手法や工程の進め方に迷っている方は、ぜひカオピーズにご相談ください。日本市場での12年以上の開発実績をもとに、プロジェクトの状況に合った進め方をご提案します。なお、お問い合わせはお問い合わせフォーム、メール（[email protected]）、お電話（03-5809-2633／受付 10:00〜18:00、土日祝休み）で承っています。

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

Q1. システム開発工程の全体には、どのくらいの期間がかかりますか？

システム開発工程の全体期間は、システムの規模・機能数・開発手法によって大きく異なり、要件定義で開発範囲が固まった段階の見積もりで確定するのが一般的です。そのため、企画段階では概算の期間として捉えておきましょう。ただし、上流工程の期間を削ると後工程の手戻りが増えやすいため、要件定義と設計には十分な期間を確保することが重要です。

Q2. 要件定義書は発注側が作成するものですか？

要件定義書を誰が作成するかは、契約で定める業務範囲によって異なります。要件定義工程を開発会社に委託する場合は、開発会社がヒアリングをもとに作成するのが一般的です。ただし、どちらが作成する場合でも、業務上の要件を決めて承認する責任は発注側にあります。そのため、発注前に業務の課題と目的を整理しておくと、要件定義を円滑に進められます。

Q3. 上流工程だけ、または開発工程だけを外部に依頼できますか？

工程を分けて外部に依頼することは可能です。たとえば要件定義と設計を自社で行い、開発以降を外部に依頼する形も、その逆の形もあります。ただし、依頼先が工程ごとに変わる場合は、前工程の意図を引き継ぐため、設計書の粒度と引き継ぎ方法を事前に取り決めましょう。

Q4. 開発途中で開発手法を変更できますか？

開発途中で手法を変更することは可能ですが、スケジュールや契約条件の見直しが必要になる場合があります。たとえばウォーターフォール型からアジャイル型に切り替えると、成果物の定義や仕様変更の扱いが変わるため、契約形態を見直すケースもあります。そのため、現在の工程の進み具合と契約条件を整理したうえで、開発会社と協議しましょう。

参考文献

1. Schwaber, K. and Sutherland, J.（2020）.
   「スクラムガイド：スクラム公式ガイド ゲームのルール」（日本語版）.
   https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf（2026年10月19日閲覧）