システム開発を外注するとき、開発が「どんな工程を、どんな順番で」進むのかを知らないままだと、進捗報告を見ても状況が分からず、気づいたときには手遅れ——ということが起こりがちです。さらに現場では「SS」「UT」「IT」といった略語が当たり前のように飛び交い、話についていけない場面も少なくありません。
システム開発の工程とは、要件定義から設計・製造・テスト・運用までの一連の作業の段階を指します。発注者がすべての工程を細かく理解する必要はありませんが、全体の流れと、各工程で何が起きるかを押さえておくと、開発会社とのやりとりが格段にスムーズになります。
この記事では、システム開発の工程の全体の流れと、SS・SA・UT・ITといった各工程の略称・略語を一覧で解説し、発注者が特に関わるべき工程までを発注側の目線で整理します。
この記事のポイント
- システム開発の工程は要件定義→設計→製造→テスト→運用の流れで進む
- SS・SA・UT・ITなどの略語は設計とテストが対応するV字で覚えると分かりやすい
- 開発手法（ウォーターフォール／アジャイル）で工程の進み方が変わる
- 発注者は全工程ではなく要件定義・テスト・検収の3工程に関わればよい
目次
システム開発の工程と全体の流れ
システム開発の工程を知っておくべき理由
発注者がシステム開発の工程を理解しておくべき理由は、進捗を正しく把握し、適切なタイミングで関与するためです。工程を知らないと、開発会社からの報告が「いま順調なのか、遅れているのか」を判断できず、問題に気づくのが遅れます。
また、各工程には発注者が確認・判断すべきポイントがあります。たとえば要件定義では「作るものの中身」を、テストや検収では「期待どおりに動くか」を確認します。工程の流れを知っていれば、こうした節目を逃さずに関われます。
逆に言えば、発注者が技術的な作業内容まで理解する必要はありません。全体の地図を持っておき、自分が関わるべき場所を把握しておけば十分です。
たとえば「設計工程に入りました」という報告を受けたとき、工程を知っていれば「では基本設計の内容を見せてほしい」と次の一手を打てます。工程を知らないと、報告をただ受け流し、後になって「思っていたものと違う」と気づくことになります。工程の理解は、受け身の発注から主体的な発注へ切り替えるための土台になります。
要件定義から運用までの工程の流れ
システム開発の工程は、おおむね次の順番で進みます。上流（要件定義・設計）から下流（製造・テスト・運用）へ流れていくイメージで、川の流れにたとえて「上流工程」「下流工程」と呼ばれることもあります。上流での決定が下流すべてに影響するため、序盤ほど発注者の関与が効いてきます。
| 工程 | 内容 | 発注者の関わり |
|---|---|---|
| 要件定義 | 何を作るか、必要な機能を決める | 主体的に関わる（最重要） |
| 設計 | 要件を実現する仕組みを設計する | 基本設計の内容を確認 |
| 製造（実装） | 設計をもとにプログラムを作る | 進捗を定期的に確認 |
| テスト | 意図どおり動くかを段階的に検証する | 受け入れテストに参加 |
| 検収・運用 | 納品物を確認し、本番運用・保守へ | 検収基準で合否を判断 |
要件定義は、解決したい課題と必要な機能を言葉と図で固める工程です。ここが曖昧なまま先へ進むと、後工程のすべてがずれていきます。続く設計は、要件をどう実現するかを決める工程で、画面や帳票など利用者から見える部分を決める「基本設計」と、内部のデータ構造や処理を決める「詳細設計」に分かれます。
製造（実装）は、設計をもとに実際にプログラムを書く工程です。発注者が直接関わる場面は少ないものの、定期的な進捗報告で遅れの兆候を見ておきます。テストは、作ったものが意図どおり動くかを段階的に確認する工程で、小さな部品単位から全体へと検証範囲を広げていきます。最後の検収・運用では、納品物が要件を満たすかを発注者が確認し、合格すれば本番運用と保守に移ります。
この中で発注者が最も深く関わるべきは、最初の要件定義です。ここで決めた内容が、その後のすべての工程の土台になります。要件定義の具体的な進め方は要件定義の進め方の解説で詳しく扱っています。
開発手法によって工程の進み方は変わる
同じ工程でも、採用する開発手法によって進み方が変わります。代表的なのがウォーターフォール型とアジャイル型です。
ウォーターフォール型は、要件定義→設計→製造→テストを上流から順番に進める方法で、工程の区切りが明確で進捗を管理しやすい一方、後からの仕様変更には弱い特徴があります。アジャイル型は、小さな単位で設計から実装・テストまでを繰り返す方法で、変化に強い反面、全体の進捗が見えにくくなりがちです。手法ごとの違いはMVP・アジャイル・スクラムの違いの解説もあわせて確認すると、自社のプロジェクトに合う進め方を判断しやすくなります。
発注者にとって重要なのは、どちらの手法でも「自分が確認すべき工程は変わらない」という点です。ウォーターフォールなら各工程の区切りで、アジャイルなら繰り返しの節目ごとに、要件と成果物を確認します。手法の名前に惑わされず、要所で関与する姿勢さえ持っていれば、進め方が違っても対応できます。逆に、手法を理由に「アジャイルなので途中は見えなくて当然」と関与をやめてしまうと、丸投げと同じ結果を招きます。
システム開発の工程でよく使う略称・略語
工程の略称・略語の一覧
システム開発の現場では、各工程をアルファベットの略称で呼ぶことが多くあります。打ち合わせや進捗表で頻出するので、意味を押さえておくとコミュニケーションがスムーズになります。
| 略称 | 英語 | 意味（工程） |
|---|---|---|
| SP | System Planning | 企画 |
| SA | System Analysis | 要求分析 |
| RD | Requirements Definition | 要件定義 |
| BD・UI | Basic Design | 基本設計（外部設計） |
| SS | System Structure Design | 構造設計 |
| FD | Function Design | 機能設計 |
| DD・PS | Detail Design | 詳細設計（内部設計） |
| M | Manufacture | 製造 |
| PG・CD | Programming / Coding | プログラミング・コーディング |
| UT | Unit Test | 単体テスト |
| IT | Integration Test | 結合テスト |
| ST・PT | System Test | システムテスト（総合テスト） |
| OT | Operation Test | 運用テスト |
紛らわしいのが、同じ工程に複数の呼び方があることです。たとえば基本設計は「外部設計」、詳細設計は「内部設計」と呼ばれることがあり、略称もBD・UI・EDなど会社によって揺れます。呼び方が違っても「利用者から見える部分を決めるのが基本設計、内部の作りを決めるのが詳細設計」という役割を押さえておけば、表記の違いに振り回されずに済みます。
なぜこれほど略語が多いのかというと、システム開発が多くの専門工程に細かく分かれているからです。特に設計とテストはそれぞれ複数の段階に分かれており、現場では口頭やチャットでのやりとりを効率化するために略称が定着しています。発注者がすべてを使いこなす必要はありませんが、意味を知っておくだけで、専門用語に気後れせず会話に参加できます。
これらの略語は会社によって表記が少し異なることもありますが、意味はほぼ共通です。すべてを暗記する必要はなく、打ち合わせで出てきたときに「それはどの工程の話か」が分かれば十分です。分からない略語が出てきたら、その場で「それはどの工程ですか」と聞けば、相手も丁寧に説明してくれます。略語を理解しようとする姿勢自体が、開発会社との信頼関係にもつながります。
設計とテストが対応するV字モデルで覚える
略語を効率よく覚えるコツは、設計とテストが対になっている「V字モデル」を意識することです。上流で決めた内容を、対応する下流のテストで検証する、という対応関係になっています。
具体的には、要件定義（RD）はシステムテスト（ST）で、基本設計（BD）は結合テスト（IT）で、詳細設計（DD）は単体テスト（UT）で検証されます。「決めたこと」と「確かめること」がペアになっていると分かると、ばらばらの略語が一本の線でつながり、各工程の役割も理解しやすくなります。
このV字の対応を知っておくと、テスト工程の報告を受けたときに「それは何を確かめているのか」が分かります。たとえば結合テスト（IT）でつまずいているなら、基本設計（BD）の段階に立ち返って原因を探る、という見当がつきます。工程同士のつながりが見えると、トラブルが起きたときに開発会社と交わす会話の解像度が上がり、的確な質問ができるようになります。
発注者が関わるべき工程を押さえる
工程と略語を理解したら、発注者として特に力を入れるべき工程を押さえましょう。全工程に均等に関わる必要はなく、要件定義・受け入れテスト・検収の3つが要所です。
要件定義は作るものを決める最重要工程であり、受け入れテストと検収は「期待どおりに動くか」を発注者自身の目で確認する最後の砦です。この3つの工程さえ外さなければ、大きな失敗はほぼ防げます。要件定義工程の成果物を自分でも整理しておきたい場合は、要件定義書テンプレート（Word形式）を使うと、何を決めるべきかの抜けを防げます。なお、発注そのものの流れ（相談・見積もり・契約まで）を知りたい場合はシステム開発の発注工程と流れを参照してください。
この3工程に絞って関わると決めておけば、本業が忙しくても無理なくプロジェクトに関与できます。逆に、すべての工程を細かく見ようとすると負担が大きく、結局どこも中途半端になりがちです。力を入れる工程を絞ることが、限られた時間でシステム開発を成功させるコツです。特に受け入れテストは、現場の担当者に実際に触ってもらい、業務で使えるかを確かめる場として重視してください。
システム開発の工程に関するよくある質問
- Q. SS工程とは何ですか？
- SS（System Structure Design）は構造設計を指す工程で、システムの内部構造やデータの持ち方、機能間の関係を設計する段階です。基本設計と詳細設計の間に位置づけられることが多く、会社によって呼び方や区切りは多少異なります。
- Q. 発注者は工程をどこまで理解すればよいですか？
- 技術的な作業内容まで理解する必要はありません。全体の流れを地図として把握し、要件定義・受け入れテスト・検収の3工程で何を確認すべきかを知っておけば十分です。
- Q. V字モデルとは何ですか？
- 上流の設計工程と下流のテスト工程を対応させて表したモデルです。要件定義はシステムテスト、基本設計は結合テスト、詳細設計は単体テストで検証される、という対応関係を示し、各工程の目的を理解しやすくします。
