システム開発の流れは7工程｜作る前と作った後まで発注者目線で解説

業務のシステム化に向けて開発会社を探し始めたものの、開発がどんな順番で進み、自社がいつ何をすればよいのかが見えずに困っている担当者の方も多いでしょう。
提案書の略語や期間の妥当性が分からないまま、社長に進め方を説明しなければならない場面もあります。

この記事では、要件定義（何を作るかを決める工程）から運用・保守までのシステム開発の流れと、業務システムで加わる「作る前」「作った後」の段階を解説。
各工程で発注者がやること、期間の目安、進め方の選び方、略語の意味まで分かり、社内の体制と開発会社に確かめることを決められるようになります。

当社EPICsは、業務システムの受託開発会社です。SaaS（インターネット経由で使う既製のソフト）で足りる場合は作らない選択肢も含めて中立に提案し、一部の業務で試してから全体へ広げる段階的な進め方で、導入を支援しています。

システム開発の流れは？要件定義から運用・保守までの7工程

システム開発は、要件定義・基本設計・詳細設計・実装・テスト・リリース・運用保守の7つの工程を、この順番で進めるのが基本です。
IPA（情報処理推進機構）の調達管理ガイドの概要でも、工程は計画の策定から要件定義、設計・開発、テスト、移行を経て運用・保守へと並んでいます（出典：IPA 調達管理ガイド試作版の概要）。
工程の呼び方や区切り方は、開発会社によって多少の違いがある点に注意しましょう。

工程	その工程でやること	できあがるもの
①要件定義	作るものの範囲・機能・性能を決める	要件定義書
②基本設計（外部設計）	画面・帳票・他のシステムとの連携など、使う人から見える部分を決める	基本設計書
③詳細設計（内部設計）	プログラムの内部の作りを決める	詳細設計書
④実装（プログラミング）	設計書をもとにシステムを作る	プログラム
⑤テスト	単体・結合・総合・受け入れの順に動作を確かめる	テストの結果報告
⑥リリース（移行）	本番の環境に切り替え、今のデータを移す	稼働するシステム
⑦運用・保守	不具合への対応や改修を続ける	保守の記録

業務システムでは、要件定義の前の業務の見直しと、リリース後の試験導入・効果測定も流れに含めて考えます（次の章で解説）。

要件定義と設計で「何を作るか」を決める（上流工程）

要件定義と設計は、どんなシステムを作るかを言葉と図で決める工程で、まとめて上流工程と呼ばれます。内訳は次の3つです。

• 要件定義：作る範囲と機能、速さ・安全性などの機能以外の条件（非機能要件）を決める
• 基本設計：画面・帳票など、使う人から見える部分を決める
• 詳細設計：開発会社がプログラムの内部の作りを決める（発注者が細かく確かめる必要は少ない）

上流で決めたことは後の工程すべての前提になるため、後から変えるほど、前の工程に戻ってやり直す「手戻り」が大きくなりがちです。発注者が深く関わるのも、主にこの段階になります。

実装・テスト・リリースで、決めたものを形にして切り替える（下流工程）

実装・テスト・リリースは、設計書のとおりにシステムを作り、小さな単位から確かめて本番に切り替える工程で、まとめて下流工程と呼ばれます。中身は次の3つです。

• 実装：開発会社が設計書をもとにプログラムを作る（プログラミングは工程の一部）
• テスト：単体テスト（部品ごと）、結合テスト（部品をつないで）、総合テスト（全体。システムテストとも呼ぶ）、受け入れテスト（発注者が業務で確かめる）の順に進める
• リリース（移行）：本番の環境に切り替え、今のExcelなどのデータを移す。全社一斉か部署ごとかも選ぶ

設計で決めたことは、対応するテストで確かめるのが基本。細かい設計ほど小さな単位のテストで確かめるこの対応関係は、V字モデルと呼ばれます。
最後の受け入れテストは発注側が主役で、IPAの調達管理ガイドでも、ここでの開発会社の役割は「支援」という位置づけです（出典：IPA 調達管理ガイド試作版）。

運用・保守で、使い続けられる状態を保つ

リリース後は、運用・保守として不具合や問い合わせへの対応、業務の変化や法改正に合わせた改修を続けます。業務システムは、作る期間より使う期間のほうが長くなるのが一般的です。

保守の範囲（対応する時間帯や、追加費用になる改修の範囲など）は、開発の契約とは別に決めることが多いもの。着手前に、どこまでが保守に含まれるかを確かめておきましょう。

業務システムは「作る前」と「作った後」まで流れに入る

業務システムの開発は、7つの工程の前に「作るかどうかを判断する段階」、後に「一部の業務で試して全体へ広げる段階」を入れて考えると、作ったのに現場で使われない失敗を防ぎやすくなります。
業務は動きながら変わり、現場が使うかどうかも導入してみないと分からない面があるためです。
ただし、業務が小さくやり方も固まっているなら、一度に作るほうが早いこともあるでしょう。

当社では、現状把握・方針策定・パイロット（一部で試すこと）・横展開（全体へ広げること）・継続改善の5段階で進めています（出典：EPICs DX・業務システム開発支援）。

作る前に、業務を見直して「作るかどうか」を判断する

要件定義に入る前に、どの業務に手間がかかっているかを洗い出し、そもそも新しく作る必要があるのかを判断します。進め方は次の2段階です。

• 現状把握：今の業務の流れと、手間や転記ミスが集中しているところを見える形にする
• 方針策定：既製のSaaSやパッケージ（業種向けの既製ソフト）で足りるか、一部の改修で済むか、作るならどの業務からかを決める

ここで作らない判断ができれば、不要な開発費をかけずに済みます。発注側が用意するのは、困っている業務と今のやり方、変えたい期限、おおよその予算です。

当社では、業務診断で現場の実態や仕様の抜け漏れを洗い出し、SaaSや一部の改修で足りる場合は、作らない選択肢も含めて提案しています（出典：EPICs DX・業務システム開発支援）。

当社が開発を担当した株式会社ワカシ様（訪問入浴サービス）は、Excelで管理していた予約から勤怠、介護保険の請求までを一気通貫で扱おうと、訪問介護向けの管理ツールも検討しました。
しかし、利用者1人に職員3人を配置する勤怠管理や、車両・訪問コースの管理で融通が利かず、独自に開発することを選んだそうです（出典：ワカシ様のインタビュー・開発事例）。

開発会社への相談から契約までも、作る前に進める

開発会社への依頼（外注）は、相談、提案と見積もり、契約の順に進み、契約を結んでから要件定義が始まるのが一般的です。各段階の中身は、次のとおり。

• 相談（ヒアリング）：困っている業務と今のやり方を伝える
• 提案・見積もり：要件が固まる前は幅のある概算になり、要件定義を経て精度が上がる
• 契約：成果物の完成に責任を持つ請負契約と、作業の遂行に対して支払う準委任契約を、工程ごとに使い分けることもある

作った後は、一部の業務で試してから全体へ広げる

作った後は、一部の業務や部署で試してから全体へ広げ、導入前後の効果を数字で確かめます。流れは次の3つです。

• パイロット：一部で試して効果と使い勝手を確かめ、「拡げる・作り直す・止める」を判断する。総額を一度に負担せずに済む
• 横展開：ほかの業務や部署へ広げ、操作の教育やマニュアルの整備も行う
• 効果測定：着手前に効果を測る指標（KPI：処理時間や利用率など）を決め、導入前後を数字で比べる。社長への説明材料になる

全体へ広げた後も、業務の変化や法改正に合わせて改善を続けます。試す段階を挟む分だけ、全体の期間は延びることもある点は知っておきましょう。

各工程で、発注者は何を決めて何を用意する？

システム開発で発注者が担うのは、作るものを決めること、業務の実物と現場の声を出すこと、できあがったものを確かめて承認することの3つです。
関わるのは発注の窓口になる担当者1人ではなく、業務を知る現場の担当者と、予算や範囲を決める社長（決裁者）も含まれます。

IPAの調達管理ガイドでも、発注側に含まれるのは、局面に応じた業務企画・業務実施・システム部門などの関係者です（出典：IPA 調達管理ガイド試作版）。

工程	発注の担当者（窓口）	現場の担当者	社長
作る前	困りごとと今の業務の流れをまとめる	手間がかかっている作業を挙げる	目的・予算・期限を決める
要件定義	要望を取りまとめて優先順位を付ける	業務の実物と例外的な処理を説明する	作る範囲と予算を承認する
設計	画面や帳票を確認する	画面の流れが業務に合うか確かめる	大きな変更があるときに判断する
実装	定例で進捗を確認し、質問に答える	必要に応じて質問に答える	報告を受ける
受け入れテスト・検収 （検収＝納品されたものを確かめて受け取ること）	テストの段取りを組む	実際の業務の手順とデータで操作して確かめる	検収を承認する
リリース・作った後	切り替えの段取りと効果の取りまとめ	新しいやり方に切り替え、意見を出す	全体へ広げるかを判断する

規模の小さい会社では、発注の担当者と社長が兼ねることもあります。

要件定義では、困りごとと優先順位を発注者が決める

要件定義で発注者が決めるのは、何を解決したいかという目的と、欠かせない機能とあれば良い機能の優先順位です。月末だけの集計や取引先ごとの特別な扱いといった、例外的な処理も洗い出します。

IPAの要件定義ガイドは、要件を定義する責任は使う側にあり、システム開発の遅延の過半は要件定義の失敗にあると言われていることを紹介しています（出典：IPA ユーザのための要件定義ガイド 第2版）。

発注者ができる工夫は、次の3つです。

• 業務を知る現場の担当者を打ち合わせに入れる
• 要望に優先順位を付けて、範囲を絞る
• 要件をまとめきれない場合は、要件定義の支援を頼めるかを開発会社に確かめる

要件定義で何を決めるか、依頼前にどこまで準備すればよいかは、要件定義とはの記事で詳しく紹介しています。

設計と開発中は、画面を確かめ、変更のルールを決めておく

設計の段階では、画面や帳票が業務に合うかを現場の担当者と一緒に確かめ、開発中は仕様を変えるときのルールを先に決めておきます。
画面の流れ（画面遷移）を見て、いつもの作業がその順番でできるかを確認するのが基本。
IPAの「共通フレーム2013」のガイダンスも、画面の原案や遷移は使う部門が確かめ、予算の追加や機能の削減など変更への対応は前もってルールにしておくことを勧めています（出典：IPA 共通フレーム2013 ガイダンス）。

開発中は定例で進捗を確認し、仕様の変更は費用と期間への影響を確かめてから承認しましょう。
変更は品質にも響きます。
JUAS（日本情報システム・ユーザー協会）が会員企業を中心に行った調査では、要求仕様に大きな変更があった案件は、不具合の多さを表す指標（換算欠陥率）の平均が、変更のない案件の約2.5倍でした（出典：JUAS ソフトウェア・メトリクス調査2025）。

受け入れテストと検収は、現場の担当者が実際の業務で確かめる

受け入れテストは、実際に使う現場の担当者が、いつもの業務の手順とデータに近い条件でシステムを動かし、業務が回るかを確かめる工程です。開発会社のテストのやり直しではありません。用意するのは次の3つです。

• いつもの業務と例外的な業務のテストの手順（シナリオ）
• テストに使うデータ
• 合格の基準（検収の基準）

IPAの「共通フレーム2013」のガイダンスは、受入れの基準を稼働後の使い方まで想定して具体的かつ定量的に決め、計画書にまとめることが望ましいとしています（出典：IPA 共通フレーム2013 ガイダンス）。

受け入れテストで見つかる不具合が多いほど、開発期間は延びやすい傾向があります。
JUASの調査では、利用者側の総合テストで見つかった不具合の平均は、期間が標準内に収まった案件で20.92件、標準を超えた案件で39.55件でした（出典：JUAS ソフトウェア・メトリクス調査2025）。
不具合を早めに見つけて減らせるよう、テストの手順と合格の基準は前もって用意しておきましょう。

テストの結果が検収の基準を満たしたら、検収を承認して納品・支払いへ。満たさない点は、修正を依頼します。

システム開発の期間はどれくらい？規模別の目安

業務システムの開発期間は、規模によって大きく変わります。
当社が公開している目安では、小規模なシステムで1ヶ月〜、中規模で3ヶ月〜、大規模・基幹システムで4ヶ月〜です（出典：EPICs DX・業務システム開発支援）。

規模	目安となる画面数・利用者数	期間の目安
小規模なシステム	〜15画面 〜1,000人想定	1ヶ月〜
中規模なシステム	31〜50画面 〜10,000人想定	3ヶ月〜
大規模・基幹システム	50画面〜 10,000人〜	4ヶ月〜

どれも「〜」の付いた下限の目安で、作る範囲や連携するシステムの数によって変わります。
作る前の業務の見直しや、一部の業務での試験導入を入れる場合は、その期間も見込んでおきましょう。

期間の配分は、要件定義2割・設計から結合テスト5割・総合テスト3割が目安

工程ごとの期間の配分は、要件定義が約2割、設計から結合テストまでが約5割、総合テストが約3割というのが一つの目安です。
JUASの「ソフトウェア・メトリクス調査2025」が示す工期の比率（20：50：30）で、総合テストには利用者側の総合テストと稼働直後のフォローが含まれます（出典：JUAS ソフトウェア・メトリクス調査2025）。

要件定義と総合テストは合わせて期間の半分を占め、どちらも発注側の確認が欠かせない工程です。工程表にその期間が入っているかを確かめましょう。
ただし、この調査はJUAS会員企業を中心としたもので規模の大きな案件も含まれ、中小企業の小規模な案件にそのまま当てはまるとは限りません。

期間が延びるのは、要件があいまいなまま進め、社内の決定が遅れるとき

開発期間が延びやすいのは、要件があいまいなまま進めて途中で仕様変更が重なるときと、発注側の確認や決定が遅れるときです。
同じ調査では、実際の期間は標準的な期間の約1.08倍で、1割程度の余裕を持った計画が安全だとしています。
調査の中では比較的小さな、50人月（1人が1ヶ月で行う作業量の50倍）未満の案件では、56%が標準的な期間を上回っていました（出典：JUAS ソフトウェア・メトリクス調査2025）。

発注側でできるのは、次の3つです。

• 要件定義の段階で、機能の優先順位を決めておく
• 確認・決定する人と、回答の期限を決めておく
• 工程表にある発注側の確認の期間を、社内の予定に押さえておく

ウォーターフォールとアジャイル、どちらで進めるべき？

ウォーターフォールとアジャイルは、どちらが優れているかではなく、要件がどこまで固まっているか、途中の変更を前提にするかで選びます。
ウォーターフォールは7つの工程を上から順に1回で進める方法、アジャイルは小さな範囲で設計・実装・テストを短い間隔で繰り返す方法です。

デジタル庁の資料も、アジャイル開発は要件や技術の不確実性を伴うプロジェクトで有用で、不確実性を伴わない案件にはウォーターフォール型開発が適するとしています（出典：デジタル庁 情報システム調達改革検討会 資料1別紙）。

比べる点	ウォーターフォール	アジャイル
進め方	工程を順番に1回で進める	小さな範囲で作って確かめるを繰り返す
仕様の変更	変更すると手戻りが大きい	変更を前提に進める
期間と費用の見通し	最初に立てやすい	範囲を決めながら進むため変わりやすい
発注側の関わり方	工程の区切りごとに確認・承認する	短い間隔で確認と判断を続ける
向いている業務	やり方が固まっている業務	使いながら決めたい業務

やり方が固まっている業務なら、ウォーターフォールで進めやすい

業務のやり方や帳票の形が決まっていて、作る範囲をはっきり書き出せるなら、ウォーターフォールで進めやすくなります。
工程の区切りごとに成果物を確認・承認するため、期間と費用の見通しを最初に立てやすく、社内の稟議にも乗せやすいのが利点です。

向いているのは、法改正や制度に合わせて決まった帳票を出す業務や、今のシステムと同じ機能を新しい仕組みに置き換える業務。
途中で仕様を変えると手戻りが大きいため、要件定義と基本設計の確認には時間をかけておきましょう。

使いながら決めたい業務は、小さく作って確かめながら進める

現場で使ってみないと細かい要望が決まらない業務は、アジャイルのように小さな範囲で作って確かめながら進めるほうが合いやすくなります。
プロトタイプ（試作品）を先に作って画面を触ってもらい、認識のずれを早めに直すのも一つの方法です。

ただし、発注側が短い間隔で確認と判断を続けることが前提です。
IPAのアジャイル開発版のモデル契約も、発注側が選ぶプロダクトオーナー（作るものに責任を持つ人）が、必要な情報や意思決定を適時に出すことを成否の要の一つとしています（出典：IPA 情報システム・モデル取引・契約書 アジャイル開発版）。
担当者が忙しく、決定に時間がかかる会社では進みにくいでしょう。

1つのシステムの中で、固まっている範囲は順番に、決めきれない範囲は小さく試しながら進める組み合わせ方もあります。

工程表に出てくる略語の意味は？RD・BD・UTなどの早見表

提案書や工程表に出てくる略語は工程の英語名の頭文字で、要件定義はRD、基本設計はBD、単体テストはUTのように表します。よく使われる例は次のとおりです。

工程	よく使われる略語	元の英語
企画	SP	System Planning
要求分析・システム方式設計	SA	資料によって指す工程が異なる
要件定義	RD	Requirements Definition
基本設計（外部設計）	BD ED UI	Basic Design External Design User Interface
詳細設計（内部設計）	DD ID	Detail Design Internal Design
システム構造設計	SS	System Structure Design
プログラム構造設計	PS	Program Structure Design
実装	PG CD	Programming Coding
単体テスト	UT	Unit Test
結合テスト	IT	Integration Test
総合テスト	ST	System Test
運用テスト	OT	Operation Test

注意したいのは、同じ略語でも、会社や資料によって指す工程が違うことがある点です。
たとえばSAは、要求分析を指す資料もあれば、システム方式設計を指す資料もあります。表の略語は、特定の会社の定義ではなく、よく使われる例として参考にしてください。

提案書で分からない略語が出てきたら、開発会社に「どの工程のことか」を確かめれば十分です。
大切なのは、略語を覚えることより、その工程で自社が何を決め、何を確かめるのかを押さえておくこと。

業務システムの開発ならEPICs

流れが分かっても、どの業務から手を付けるかの判断は簡単ではありません。
当社EPICsは、業務の見直しから開発、現場への定着、導入後の改善まで、この記事の流れを1社で支援する業務システムの受託開発会社です。

段階ごとに確かめながら進め、パイロット後に「拡げる・作り直す・止める」を判断できるため、総額を一度に負担する必要はありません。
SaaSで足りるかも含めて中立に提案し、診断だけ・開発だけのご依頼にも対応。
着手前には効果を測る指標（KPI）を設計し、導入前後を数字で示せるようにしています。

開発手法は、ノーコード（プログラムを書かずに画面の操作で作る方法）・AI駆動開発（AIを活用した開発）・スクラッチ（一から作る開発）を業務領域ごとに使い分け、10年使う前提で保守しやすく作ります。

費用の目安は、業務診断が30万円〜（本開発を依頼する場合は全額充当）、小規模なシステムが1ヶ月〜・80万円〜。開発実績は250件以上です。

まずは困っている業務と今のやり方を整理し、どこから手を付けるかを専門家と決めることから始めてみてください。

出典：EPICs DX・業務システム開発支援／EPICs アプリ・システム受託開発サービス

システム開発はなぜ失敗するのですか？

多くは、要件定義の段階で目的や優先順位があいまいなまま進み、途中の仕様変更や認識のずれが重なるためです。IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」は、システム開発の遅延の過半は要件定義の失敗にあると言われていることを紹介しています。JUAS（日本情報システム・ユーザー協会）が会員企業を中心に行った調査でも、要求仕様に大きな変更があった案件は、不具合の多さを表す指標の平均が変更のない案件の約2.5倍でした。防ぐには、現場の担当者を要件定義に入れて優先順位を決め、仕様変更のルールを先に決め、受け入れテストで実際の業務が回るかを確かめることが大切です。

システム開発で、発注者がいちばん時間を使うのはどの工程ですか？

要件定義と、受け入れテストを含む総合テストの2つです。JUAS（日本情報システム・ユーザー協会）が会員企業を中心に行った「ソフトウェア・メトリクス調査2025」では、工程ごとの期間の配分は要件定義が約2割、総合テストが約3割で、どちらも発注側の確認が欠かせない工程にあたります。ただし、この調査には規模の大きな案件も含まれるため、小規模な案件にそのまま当てはまるとは限りません。開発会社から工程表を受け取ったら、この2つの工程に発注側が確認する期間が入っているかを確かめておくと安心です。

システム開発の工程を省いて、開発期間を短くすることはできますか？

工程そのものを省くより、作る範囲を絞るほうが安全です。要件定義やテストを削ると、後から手戻りが起きたり、稼働後に不具合が見つかったりして、結果的に期間が延びやすいためです。期間を短くしたい場合は、一部の業務から作って試し、効果を確かめてから広げる方法があります。最初に作る範囲が小さい分、最初の開発の期間を短くできるでしょう。EPICsが公開している目安では、小規模なシステム（〜15画面・〜1,000人想定）の開発期間は1ヶ月〜です。

システムの要件が固まっていなくても、開発を依頼できますか？

はい、依頼できます。要件定義の前の業務の見直しから相談でき、発注側だけで要件をまとめきれない場合は、要件定義の支援を頼めるかを開発会社に確かめるとよいでしょう。現場で使ってみないと決まらない業務は、小さな範囲で作って確かめながら進める方法もあります。相談の前に用意しておきたいのは、困っている業務と今のやり方、変えたい期限、おおよその予算です。これらがあれば、作る必要があるかどうかも含めて話を進められます。