『システム開発はどんな工程で進むの？』
『要件定義・基本設計・詳細設計って、それぞれ何が違う？』
『UT・IT・ST・UATって何の略？テスト工程がよくわからない』
ITエンジニアを目指すうえで、システム開発の工程を把握しておくことは非常に重要です。
工程ごとに担当する役割・成果物・必要なスキルが明確に異なるため、どの工程を経験するかによってキャリアの幅も大きく変わってきます。
この記事では、要件定義からリリース・保守運用まで7つの工程を順番に解説します。
また、開発とテストの対応関係を整理したV字モデル、テスト工程でよく使われる略語一覧もあわせて紹介します。
CIN GROUPでは、営業・事務・製造業など異業種から転職した100名以上のエンジニアデビューを支援してきました。ぜひ最後まで読み進めてみてください。
100名以上の
未経験エンジニアが活躍中！
システム開発の工程とは、ソフトウェアやWebシステムをゼロから完成させるまでの作業を段階的に分けたものです。
一般的には、要件定義・基本設計・詳細設計・実装・テスト・リリース・保守運用という流れで進みます。
それぞれの工程には専門的な知識が求められるため、担当するエンジニアやチームが分かれることも少なくありません。
工程を明確に分ける最大のメリットは、品質管理のしやすさにあるといえるでしょう。
各フェーズで成果物（ドキュメントやコードなど）を確認することで問題を早期発見しやすくなるため、大規模なシステム開発ほど工程管理が重視される傾向にあります。
この流れは『ウォーターフォール型』と呼ばれる開発手法に沿ったものです。
一方で、近年では繰り返し改善を重ねる『アジャイル型』も広く普及しています。それぞれの特徴については、この記事の後半で別途解説しています。
要件定義とは、システム開発を始める前に『何を作るのか』を明確にする工程です。
発注者（クライアント）からヒアリングを行い、業務上の課題やニーズを整理したうえで、システムが満たすべき機能・条件を定義します。
この段階で決める内容が、その後のすべての工程の土台となるため、最も重要な工程のひとつといえるでしょう。
要件定義での定義漏れや認識のズレは、開発後半になるほど修正コストが跳ね上がります。そのため、丁寧なヒアリングと正確な文書化が強く求められます。
要件定義の工程では、ヒアリングシートやインタビューをもとにクライアントの要望を整理し、システム要件書（要件定義書）にまとめます。
また、機能要件だけでなく、性能・セキュリティ・運用上の制約といった非機能要件も定義します。さらに、スコープ（開発範囲）を明確にすることで見積もり精度を高める役割も担います。
成果物としては、要件定義書・業務フロー図・ユースケース図などが挙げられます。
これらのドキュメントは後工程のエンジニアにも共有されるため、わかりやすく・もれなく仕上げることが重要です。
CIN GROUPの案件では、要件定義工程に参画するエンジニアはPMやPLクラスになることが多いといえます。
SEやエンジニアとして経験を積んだ先にある工程でもあるため、長期的なキャリア目標として目指す方も少なくありません。
現場によっては上流工程への参画機会を早期から設けているプロジェクトもあり、成長意欲のある方にとってやりがいのある環境といえるでしょう。
基本設計（外部設計とも呼ばれます）とは、要件定義で決めた内容をもとに、システムの全体像を設計する工程です。
『ユーザーから見てどう動くか』を定義する段階ともいえ、画面設計・機能設計・データベース設計の大枠などが含まれます。
実際にどんな画面があり、どのような操作フローになるかをこの工程で決めます。また、複数のシステムが連携する場合は、外部インターフェースの設計も行います。
基本設計の完成度が高いほど、後続の詳細設計・実装が円滑に進むため、精度の高い設計書の作成が求められるでしょう。
基本設計では、要件定義書をインプットとして、画面設計書・機能一覧・データフロー図などを作成します。
クライアントとの認識合わせを行いながらレビューと修正を繰り返すことも多く、コミュニケーション力が問われる工程でもあります。
また、非機能要件（パフォーマンス・セキュリティ・可用性）の設計方針も、この段階で定義することが一般的です。
開発チームが複数存在するプロジェクトでは、担当範囲の切り分けと整合性の確認も重要な作業のひとつといえます。
CIN GROUPでは、基本設計から参画するエンジニアはSE経験が2〜3年以上の方が多い傾向にあります。
プロジェクトによっては実装・テスト経験を積んだあとに設計工程へとステップアップするケースも多く、未経験スタートのエンジニアが数年以内に設計担当へ成長した事例もあります。
現場のPLや先輩エンジニアから設計ノウハウを学べる環境も整っているため、着実にキャリアを伸ばしていけるでしょう。
詳細設計（内部設計とも呼ばれます）とは、基本設計で決めたシステムの全体像を、エンジニアが実際に実装できるレベルまで細分化する工程です。
基本設計が『何を作るか』を定義するのに対し、詳細設計は『どのように作るか』を定義するといえるでしょう。
クラス図・シーケンス図・テーブル定義書など、実装の直接的な設計書を作成するのがこの工程の主な役割です。
詳細設計の完成度がそのままコーディングの品質に直結するため、実装担当者が迷わず進められるドキュメントを仕上げることが重要です。
詳細設計では、基本設計書をインプットとして、クラス設計・メソッド設計・テーブル定義・API仕様書などを作成します。
さらに、ロジックの分岐条件や例外処理の方針もこの段階で定めます。
設計書があいまいだと実装工程でバグが生まれやすくなるため、曖昧さを排除した精緻なドキュメントを仕上げることが求められます。
また、テーブル定義の変更は多くの機能に影響するため、修正前後の影響範囲の確認も欠かせません。
CIN GROUPの案件では、詳細設計は実装経験が1〜2年程度のSEが担当するケースが多いといえます。
実装を通じてシステムの動き方を理解したうえで、設計ドキュメントへとステップアップしていく段階です。
現場によっては実装と詳細設計を兼任するプロジェクトもあり、設計から実装まで一気通貫で経験できることは大きなスキルアップにつながるでしょう。
実装とは、詳細設計書をもとに実際にプログラムを書く工程です。
エンジニアが最も長い時間を費やすフェーズのひとつであり、使用するプログラミング言語やフレームワークへの習熟度が求められます。
書いたコードの可読性・保守性・パフォーマンスも重要なポイントです。チームで開発する場合はコーディング規約に沿って書くことが原則であり、設計書に忠実に実装しながら、不明点があれば積極的に確認していく姿勢が大切でしょう。
実装工程では、詳細設計書に記載されたロジックやAPI仕様に従ってプログラムを作成します。
フロントエンド（画面表示・UI）やバックエンド（業務ロジック・DB連携）など、担当領域によって使う技術が異なります。
また、実装しながら軽微なバグを発見・修正するセルフレビューも重要な作業のひとつです。
バージョン管理ツール（GitやGitHub）を使ったコードの管理・プルリクエストレビューも、現代の開発現場では欠かせないスキルといえるでしょう。
未経験から転職したエンジニアの多くが最初に担当するのがこの実装フェーズです。
PHPやTypeScript、Javaなど、プロジェクトによって使用言語は異なりますが、基本的なコーディング力を身につけながら現場経験を積んでいくという点はどの案件でも共通しています。
また、実装の品質は単体テストにも直結するため、テストを意識したコードの書き方も自然と身についていきます。
CIN GROUPでは先輩エンジニアがコードレビューを通じてサポートする体制が整っており、未経験でも安心してスキルアップできる環境があります。
もし、サポート内容を知りたかったり、教育環境を知りたい場合はぜひ下記よりエントリーしてください。
100名以上の
未経験エンジニアが活躍中！
単体テスト（UT：Unit Test）とは、実装した機能やモジュールを個別に検証するテスト工程です。
実装直後に行われることが多く、設計どおりの動きをするかを最小単位で確認します。V字モデルでは、詳細設計と対応するテスト工程にあたります。
単体テストの品質が高いほど、後続の結合テスト・総合テストでの手戻りが減るため、丁寧なテスト設計が求められるでしょう。
テスト項目に漏れが生じると後工程で大きな不具合として発覚することもあるため、正常系・異常系を網羅的に確認することが重要です。
単体テストでは、実装した関数やモジュールの入力と出力を確認するテストケースを作成し、実行します。
テスト仕様書（単体テスト仕様書）を事前に作成してから実施するのが一般的であり、テスト結果もドキュメントとして残します。
また、正常系（想定どおりの入力）だけでなく、異常系（想定外の入力・エラー）の確認も必要です。
CIツール（GitHub ActionsなどのCI/CD環境）を利用して自動テストを組み込んでいる現場も増えており、テスト自動化の知識も徐々に求められるようになってきています。
CIN GROUPのプロジェクトでは、実装担当のエンジニア自身が単体テストも担当するケースが多いです。
そのため、コーディングスキルと並行してテスト仕様書の作成方法や、エビデンス（証跡）の取り方も自然と身についていきます。
テストの視点を持ちながら実装することで、コードの品質そのものも向上するといえるでしょう。
未経験から入社したエンジニアが最初の半年〜1年で実装と単体テストを経験するケースは非常に多く、確実なスキルアップのステップとなっています。
単体テストが個々の機能を検証するのに対し、結合テスト（IT）・総合テスト（ST）・受入テスト（UAT）は、システム全体をより広い視点で検証する工程です。
それぞれの役割は異なり、ITは複数機能の連携確認、STはシステム全体が要件を満たすかの確認、UATは発注者側による最終承認という流れになります。
V字モデルでは、ITは詳細設計、STは基本設計、UATは要件定義にそれぞれ対応しているといえるでしょう。
結合テスト（IT）では、単体テストを通過したモジュール同士を組み合わせ、データの受け渡しや処理の連携が正しく動くかを確認します。
続く総合テスト（ST）では、実際のユーザー操作を想定したシナリオテストを実施し、システム全体の品質を担保します。
受入テスト（UAT）では、クライアントや業務担当者が参加し、業務フローに沿った最終確認を行います。テクニカルな観点だけでなく業務目線での確認がなければ、本番稼働後に使い勝手の問題が浮上するリスクがあるためです。
また、この工程では発見した不具合を管理・修正するバグトラッキングのスキルも必要になります。
CIN GROUPのエンジニアは、実装・単体テストを経験したのち、結合テストや総合テストの工程にも参画するケースが多いです。
特にIT・ST工程では、自分が実装した機能が他の機能と正しく連携するかを確認する機会となり、システム全体への理解が深まるでしょう。
UAT工程では発注者とのやりとりに立ち会うこともあり、コミュニケーション力やドキュメント管理のスキルも自然と磨かれていきます。
リリースとは、開発・テストを経て完成したシステムを本番環境に移行し、ユーザーが実際に使える状態にする工程です。
リリース後はシステムを安定して稼働させるための保守運用フェーズに入り、障害対応・機能改善・バージョンアップなど、継続的なサポートが必要となります。
つまり、システム開発はリリースで終わりではなく、その後の運用を含めて初めて完結するといえるでしょう。
開発全体を俯瞰する視点を持つためにも、保守運用フェーズまで理解しておくことは重要です。
リリース工程では、本番環境へのデプロイ・動作確認・リリース手順書の作成と実行を行います。そのため、インフラ知識（サーバー構成・デプロイ手順）が求められる場面もあります。
保守運用では、障害発生時の原因調査・修正・再発防止策の実施が主な作業となります。
また、ユーザーからの改善要望を収集し、次のバージョンアップへと反映していくサイクルを担当することも多いでしょう。
定期的なパフォーマンス確認やセキュリティパッチの適用なども、保守運用の重要な業務のひとつです。
CIN GROUPでは、保守・運用フェーズのプロジェクトに参画しながらシステムの全体像を学ぶエンジニアも多いです。
既存システムの保守を通じて、コードの読み方・障害対応・改修の影響範囲の見極めなど、実務直結のスキルが身につくといえるでしょう。
保守運用案件は比較的長期間にわたって担当できるため、業務知識を深めながら安定した経験を積みたい方に向いています。
異業種からの転職者でも保守運用から入って段階的にスキルアップしていくルートは実績のあるキャリアパスであり、CIN GROUPでも多くのエンジニアがこの流れで成長しています。
100名以上の
未経験エンジニアが活躍中！
システム開発の現場では、テスト工程をアルファベットの略語で呼ぶことが一般的です。
初めてIT業界に入ると『UTって何？』『ITとSTの違いは？』と戸惑う方も多いのではないでしょうか。まず一覧で確認しておきましょう。
| 略語 | 正式名称 | 内容 |
|---|---|---|
| UT | Unit Test（単体テスト） | 個々の機能・モジュール単位で動作確認 |
| IT | Integration Test（結合テスト） | 複数の機能を組み合わせて連携を確認 |
| ST | System Test（総合テスト） | システム全体を通して要件どおりに動くか確認 |
| UAT | User Acceptance Test（受入テスト） | 発注側（ユーザー）が要件を満たすか最終確認 |
現場によっては、UTとITをまとめて『開発工程』、ST・UATを『受け入れ工程』と呼び分けることもあります。
テスト範囲や定義はプロジェクトによって多少異なるため、入社後は現場の用語定義を最初に確認しておくとよいでしょう。
V字モデルとは、システム開発の流れをV字型に表したモデルです。
左側に要件定義〜実装の開発フェーズが並び、右側にテストフェーズが対応します。つまり、上流で決めた仕様をどの工程で検証するか、という対応関係を一目で把握できるのがV字モデルの特徴といえるでしょう。
上図のとおり、要件定義で定めた仕様は受入テスト（UAT）で検証され、基本設計は総合テスト（ST）、詳細設計は結合テスト（IT）、そして実装は単体テスト（UT）にそれぞれ対応します。
このように各工程が対となっているため、上流での設計漏れや定義のあいまいさは、後のテスト工程でそのまま問題として表面化してしまいます。
上流工程でいかに精度の高い設計を行うかが、開発全体の品質を大きく左右するといえるでしょう。
各工程で求められるスキルを一覧でまとめました。どの工程を担当するかによって必要な技術や知識が変わるため、自分のキャリアプランと照らし合わせながら確認してみてください。
| 工程 | 担当者 | 主なスキル |
|---|---|---|
| 要件定義 | PM・上流SE | ヒアリング力・業務知識・文書化 |
| 基本設計 | PL・上流SE | 設計書作成・要件読み取り |
| 詳細設計 | SE | ロジック設計・テーブル設計 |
| 実装 | SE・エンジニア | プログラミング・Git・フレームワーク |
| 単体テスト | 実装担当SE | テスト設計・エビデンス作成 |
| 結合〜受入テスト | SE・PM・発注者 | シナリオテスト・不具合管理 |
| リリース・保守運用 | SE・インフラ | デプロイ・障害対応・インフラ知識 |
工程が上流になるほどコミュニケーション力や業務知識が重視され、実装・テスト工程ではプログラミングスキルが核となります。
自分がどのキャリアを歩みたいかを考えながら、必要なスキルを逆算して身につけていくとよいでしょう。
この記事で解説した7工程の流れは、主にウォーターフォール型開発に沿ったものです。
現代のシステム開発ではアジャイル開発やスクラム開発も広く使われております。
それぞれの特徴や向き・不向きについては下記にて詳しく解説しておりますので、詳しく知りたい方は以下の記事もあわせてご覧ください。
この記事では、システム開発の7工程をV字モデル・略語一覧とあわせて解説しました。
要件定義から基本設計・詳細設計と上流工程で仕様を固め、実装・テストを経てリリース・保守運用へと進む一連の流れは、ただの作業手順ではなく品質を守るための仕組みです。
V字モデルが示すとおり、上流で決めた仕様を対応するテスト工程で検証するという考え方がシステム開発全体の品質を支えています。
エンジニアを目指す方にとって、この工程の流れを理解しておくことは面接対策にも入社後の実務にも役立つ知識なのでぜひ参考にしてください。
CIN GROUPでは、営業・事務・製造業など異業種から転職した100名以上のエンジニアデビューを支援してきた実績があります。まずは下記よりぜひお気軽にエントリーしてみてください。
100名以上の
未経験エンジニアが活躍中！
