はじめて業務システムを外に頼むとき、開発会社から「要件定義」「基本設計」「結合テスト」といった言葉が次々に出てきて、いま自分たちが何をすればよいのか分からなくなることがあります。工程の名前は開発会社ごとに少しずつ違いますが、流れそのものは大きく変わりません。この記事では、システム開発の流れを7つの工程に分け、発注する側（中小企業の経営者や担当者）が各工程で何を決め、何を確かめるのかを整理します。まず7つの工程の全体を表で示し、そのあと工程ごとに発注する側がすることを説明します。あわせて、設計とテストの対応を示す「V字モデル」を表で説明し、ウォーターフォールとアジャイルの違いにも短く触れます。
この記事の結論
- システム開発は、企画・要件定義・設計・開発・テスト・導入・運用保守の7つの工程で進みます。工程の名前は会社ごとに違うので、名前より「その工程で何ができあがるか」を確かめます。
- 発注する側の出番が多いのは、最初の企画と要件定義、それに最後の受入テストです。要件定義は発注者の責任とされています。
- V字モデルでは、要件定義で決めたことを受入テストで確かめます。要件を決めるときに確かめ方も一緒に書いておくと、作り終えてからの手戻りを減らせます。
- 工程ごとに契約を分け、進むごとに見積もりを出し直す多段階の進め方は、発注する側と開発会社の双方のリスクを下げます。
システム開発の流れ：7つの工程の全体像
経済産業省が公開し、のちにIPAが改訂した「情報システム・モデル取引・契約書」では、システム化の方向性と計画づくりから始まり、要件定義、外部設計、内部設計、プログラミング、各種のテスト、運用テスト、導入・受入支援を経て、運用と保守に至るまでの工程が並べられています[3][4]。この記事では、発注する側から見て分かりやすいように、次の7つにまとめます。
| 工程 | 何をするか | 発注者が主にすること |
|---|---|---|
| 1. 企画 | なぜシステムが要るのか、何を良くしたいのかを決める | 目的・予算・時期を決め、社内で合意を取る |
| 2. 要件定義 | システムで何ができるようにするかを文書にする | 業務の流れと必要な機能を説明し、要件定義書を確認して承認する |
| 3. 設計 | 画面・帳票・データの形や、内部の仕組みを決める | 画面や帳票の案を見て、使う人の目で確かめる |
| 4. 開発 | 設計に沿ってプログラムを作る | 進み具合の報告を受け、仕様の質問にすぐ答える |
| 5. テスト | 作ったものが設計や要件どおりに動くかを確かめる | 受入テストで、実際の業務に使えるかを確かめる |
| 6. 導入 | 本番の環境に移し、データを移して使い始める | 使う人への説明、旧システムからの切り替え日を決める |
| 7. 運用・保守 | システムを止めずに使い続けられるようにし、不具合の修正や機能の追加を行う | 問い合わせの窓口と、直す・足すの判断をする人を決める |
工程の名前は会社によって違い、「基本設計」を「外部設計」、「詳細設計」を「内部設計」、「総合テスト」を「システムテスト」と呼ぶこともあります。見積書や提案書を読むときは、名前よりも「その工程で何ができあがるのか」を確かめると混乱しにくくなります。
🛠 この記事のような業務システムの課題は、ご相談ください。今の業務の流れを伺い、どこをシステムにするかから一緒に決めます（相談は無料）。
Why
開発の遅れは、最初の工程に原因があることが多い
システム開発でつまずく原因は、プログラムを書く段階よりも前にあることが少なくありません。IPA（情報処理推進機構）の講演資料では、日本情報システム・ユーザー協会（JUAS）の「ソフトウェアメトリックス調査2016」をもとに、システム開発の遅れの原因の過半は要件定義の失敗だと示しています。回答のあった479件のプロジェクトで最も多かった遅れの理由は「要求仕様の決定漏れ」でした[1]。
要件定義とは、新しいシステムで「何ができるようにするか」を決めて文書にする工程です。ここで決め漏れがあると、作り終えてから「この機能が足りない」と分かり、作り直しになります。IPAがまとめた『実務に活かすIT化の原理原則17ヶ条』でも、その9番目に「要件定義は発注者の責任である」と書かれています[2]。開発会社に任せきりにできる工程と、発注する側が中心になって決めなければならない工程がある、ということです。
流れの全体を知っておくと、どの時点で自分たちの判断が求められるのかが前もって分かります。打ち合わせの準備もしやすくなり、社内の担当者の時間も確保しやすくなります。
Process
工程ごとに発注者がすること
1. 企画：目的と予算を社内でそろえる
最初に決めるのは、「どの業務の、何を良くしたいのか」です。たとえば「受注の入力に毎日2時間かかっている」のように、今の困りごとを具体的に書き出します。17ヶ条では、システム化の方針や狙いを関係者に行き渡らせることが成功の鍵になる、と書かれています[2]。経営者と現場の担当者で目的がずれたまま進むと、要件定義の段階で意見がまとまらなくなります。
予算を考えるときは、開発費だけで見ないことが大切です。17ヶ条は、システム化の費用はソフトウェア開発だけではないとして、社員への教育や旧システムからの移行にかかる費用を見落とさないよう注意しています[2]。
こうして決めた目的や今の困りごと、予算を開発会社に渡すときは、書面にまとめておくと提案や見積もりを比べやすくなります。その書き方は提案依頼書（RFP）の書き方の記事で紹介しています。
2. 要件定義：業務を説明し、決めたことを文書で残す
発注する側の出番がいちばん多い工程です。開発会社は業務の中身を知らないので、今の業務の流れ、例外の扱い、使う人の人数、扱うデータの量などを説明します。「今と同じでよい」という伝え方は避けます。17ヶ条にも「『今と同じ』という要件定義はありえない」とあり、今の使われ方まで調べて要件にするよう求めています[2]。
「速く動くこと」のような言い方も、人によって受け取り方が違います。「画面の表示は3秒以内」のように、数字にできるものは数字にします。要求が言葉の受け渡しの中で変わってしまう仕組みは、システム開発の『伝言ゲーム』の記事でくわしく取り上げています。
3. 設計：画面と帳票を、使う人の目で見る
設計には、画面や帳票など利用者から見える部分を決める段階（基本設計・外部設計）と、内部の仕組みを決める段階（詳細設計・内部設計）があります。発注する側が見るべきなのは主に前者です。実際に使う担当者に画面の案を見てもらい、入力の順番や項目の並びが仕事のやり方に合っているかを確かめます。後者は開発会社が中心になって進めます。
4. 開発：質問にすぐ答える
プログラムを作る段階では、発注する側が手を動かすことはほとんどありません。ただ、開発中には「この場合はどう扱いますか」という質問が必ず出ます。返事が遅れるとその分だけ作業が止まるので、答える担当者と返事の期限を決めておきます。
5. テスト：受入テストは発注者が行う
テストは、部品ごとの動きを見る段階から、全体を通して見る段階へと順に進みます。最後の受入テストは、発注する側が「この内容なら受け取ってよい」と判断するためのテストです。IPAが公開しているモデル契約書には「検査仕様書の作成及び承認」「本件ソフトウェアの検収」という条項があり、何をもって合格とするかを書面で決めておく作りになっています[4]。検収（納品物を確かめて受け取ること）の基準は、テストが始まる前に決めておきます。
6. 導入：切り替えの日と、使う人への説明
本番の環境にシステムを移し、今までのデータを移して使い始めます。旧システムや紙の運用をいつやめるか、問題が出たときにいつ元に戻すかを決めておきます。使う人への説明会や手順書の用意も、この段階で必要になります。
7. 運用・保守：動かし続ける体制を決める
システムは使い始めてからのほうが長く付き合うことになります。17ヶ条では、開発コストと運用・保守コストのバランスを考え、システムの一生にかかる費用（ライフサイクルコスト）を意識するよう求めています。あわせて、発注者は要件定義の段階から運用・保守を見据えた計画と体制を作るよう書かれています[2]。だれが問い合わせを受け、だれが「直す・足す」を決めるのかを、導入前に決めておきます。
V-Model
V字モデルとは：設計とテストの対応を表で見る
V字モデルは、設計の工程とテストの工程を組にして考える見方です。経済産業省の研究部会がまとめた「非機能要求記述ガイド」では、分析から設計・開発までを品質を作り込む工程、開発からシステムテストまでを品質を確かめる工程と考え、対応する工程どうしで確かめ合うものだと説明されています[5]。図にすると左側を下りて右側を上るV字の形になるため、この名前で呼ばれます。
ここでは図の代わりに、一般的な対応を表にします。左の列で決めたことが、右の列のテストで確かめられる、という関係です。
| 設計の工程（決める） | 対応するテスト（確かめる） | テストで見ること | 主に確かめる人 |
|---|---|---|---|
| 要件定義 | 受入テスト（運用テスト） | 実際の業務に使えるか | 発注者 |
| 基本設計（外部設計） | 総合テスト（システムテスト） | システム全体が設計どおりに動くか | 開発会社 |
| 詳細設計（内部設計） | 結合テスト | 部品どうしをつないだときに正しく動くか | 開発会社 |
| プログラミング | 単体テスト | 部品1つずつが正しく動くか | 開発会社 |
この表から分かるのは、要件定義で決め漏れたことは、いちばん最後の受入テストまで見つからない可能性がある、ということです。同じガイドでも、V字モデルではシステムテストの段階になって要求の食い違いや漏れに気づき、大きな手戻りやコストの増加につながることがあったと指摘しています。そのうえで、要求をまとめた時点ですぐに、どう確かめるかまで考えておく進め方を勧めています[5]。
発注する側がこの考え方を取り入れるなら、要件定義を承認するときに「この要件は、受入テストでどう確かめるか」を一緒に書いておく方法があります。確かめ方を書けない要件は、まだ中身があいまいだと分かるからです。
Contract
工程によって契約の形が変わる
工程の流れは、契約の結び方にも関わります。IPAの講演資料によると、モデル契約書では要件定義の支援を準委任型、ソフトウェアの開発を請負型とし、外部設計やシステムテストはどちらの型もありうる、という整理になっています。そのうえで、工程ごとに契約を分ける「多段階契約」と、工程が進むごとに見積もりを出し直す考え方を採っています[4]。準委任は作業そのものに対価を払う形、請負は完成した成果物に対価を払う形です。
要件が固まる前に全体の金額を確定させると、発注する側も開発会社も無理な前提を抱えることになります。17ヶ条でも、多段階の見積りは双方のリスクを下げるとしています[2]。契約の型の違いは請負と準委任の違いの記事で、見積もりを頼む前に確かめておくことは見積もり依頼前のチェックポイントの記事で整理しています。
Methods
ウォーターフォールとアジャイルの違い
ここまでの7つの工程を、上から順に1回ずつ進める作り方をウォーターフォール開発と呼びます。前の工程を終えてから次に進むので、全体の予定と費用を前もって立てやすい反面、途中で要件を変えると手戻りが大きくなります。
アジャイル開発は、短い期間ごとに一部の機能を作って使う人に見てもらい、意見をもとに直していく作り方です。「アジャイルソフトウェア開発宣言」では、計画に従うことよりも変化への対応に価値を置く、と書かれています[6]。IPAのアジャイル開発向けのモデル契約は、準委任契約を前提にしています[4]。
大まかには、業務が決まっていて作るものがはっきりしている、会計や受発注のような会社の中心になる業務（基幹業務）のシステムはウォーターフォール、使ってもらいながら中身を決めていく新しいサービスはアジャイルが合いやすい、と考えると判断しやすくなります。アジャイルについてはMVPとアジャイルの違いの記事で取り上げています。
Sources
参考にした資料
- IPA（情報処理推進機構）「ユーザが自ら実践！最新事例で学ぶ要件定義の勘どころ 第一部 全体概要」講演資料（2020年）※日本情報システム・ユーザー協会「ソフトウェアメトリックス調査2016」をもとにした図を掲載
- IPA ソフトウェア・エンジニアリング・センター『実務に活かすIT化の原理原則17ヶ条』（2010年10月）
- IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年12月公開）
- IPA（情報処理推進機構）「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」講演資料（2025年4月）
- 経済産業省 ソフトウェア開発力強化推進タスクフォース 要求工学・設計開発技術研究部会「非機能要求記述ガイド」（2008年7月）
- 「アジャイルソフトウェア開発宣言」（2001年）
FAQ
システム開発の流れについてよくある質問
システム開発の工程は、いくつに分けるのが正しいですか？
決まった数はありません。テストを単体・結合・総合・受入に分けて数えると10前後になり、まとめて数えると5〜7つになります。大事なのは数よりも、それぞれの工程で何ができあがり、だれが確かめるのかを開発会社と合わせておくことです。
V字モデルとウォーターフォールは同じものですか？
同じではありません。ウォーターフォールは工程を順番に進める作り方のことで、V字モデルはその流れの中で、どの設計をどのテストで確かめるかという対応を示す見方です。ウォーターフォールで進める開発の計画を立てるときに、V字モデルの考え方がよく使われます。
社内にITに詳しい人がいなくても、要件定義はできますか？
できます。要件定義で発注する側に求められるのは、ITの知識よりも、自社の業務を正しく説明することです。今の業務の流れ、例外の扱い、困っている点を書き出しておけば、開発会社がそれをシステムの言葉に置き換えます。決めた内容を自分たちの言葉で説明できるかどうかを、承認する前に確かめてください。
小さなシステムでも、すべての工程が必要ですか？
工程の重さは規模に合わせて変えられますが、要件定義と受入テストは省かないほうが安全です。小さなシステムでも、何を作るかを決めずに始めると手戻りが起き、受け取る前に確かめなければ不具合をそのまま抱えることになります。設計書の細かさなどは、開発会社と相談して調整します。
システム開発は、企画・要件定義・設計・開発・テスト・導入・運用保守の順に進みます。発注する側の出番が多いのは、最初の企画と要件定義、それに最後の受入テストです。V字モデルで見ると、要件定義で決めたことは受入テストで確かめる組になっているので、要件を決めるときに確かめ方も一緒に書いておくと、作り終えてからの手戻りを減らせます。当社では、業務の整理と要件定義から、開発、導入後の運用保守まで、続けてご相談いただけます。
