ITエンジニアや社員のスキル管理ツールfapi（ファピー）を提供する株式会社エフ・ディー・シーのDXサービス事業推進部 佐々木舞美が、200名以上のITエンジニアのスキル管理・アサイン管理を25年以上行ってきた実務経験をもとに、システム開発工程の基本と各フェーズの役割を解説します。
システム開発工程とは、システムを完成させるまでに踏むべき作業手順のことです。社内外のエンジニアが分担しながら作業を進める現代のシステム開発では、工程への理解度がプロジェクトの成否を大きく左右します。本記事では18のフェーズを略号付きで整理し、開発モデルの選び方や工程管理を成功させるコツまで、現場目線でわかりやすく解説します。「自分の担当工程しかわからない」「全体の流れを把握したい」という方はぜひ参考にしてください。
システム開発工程とは？工程に沿って進めるメリット
システム開発工程とは、システム開発を進めるうえで定められた一連の手順を指します。要件定義やシステム設計などを「上流工程」、プログラミングや単体テストなどを「下流工程」に分類するのが一般的です。
工程に沿って作業を進めることで、計画通りにプロジェクトを進行できるだけでなく、進捗や品質の把握、責任範囲の明確化、トラブル時の原因追及がしやすくなります。上流工程ほどビジネス理解や設計力が、下流工程ほど実装スキルやテスト力が求められるため、どの工程にどんなスキルを持つエンジニアを配置するかがプロジェクト全体の成功を左右します。
システム開発工程の18フェーズ一覧【略号付き】
システム開発の現場では、各工程を略号で呼ぶことが多くあります。コミュニケーションをスムーズに進めるためにも、略号と意味をセットで押さえておきましょう。
| 区分 | 略号 | 工程名 | 概要 |
|---|---|---|---|
| 上流工程 | SP | システム企画 | システム導入の目的と概要を策定 |
| SA | 要件分析 | クライアントの要望を整理・定義 | |
| RD | 要件定義 | 開発モデル・予算・期間を確定（最重要） | |
| 設計工程 | UI | UI基本設計 | ユーザー画面・操作性の設計 |
| ED | 外部設計 | ユーザー視点での仕様設計 | |
| DD | 詳細設計 | 内部構成の詳細仕様化 | |
| ID | 内部設計 | システム内部の動作・データ定義 | |
| SS | 構造設計 | プログラム構造の分解と詳細化 | |
| FD | 機能設計 | 機能ごとの仕様定義 | |
| PD/PS | プログラム設計 | 実装直前のプログラム動作定義 | |
| 実装工程 | PG | プログラミング | 実際のプログラム作成 |
| CD | コーディング | プログラム言語の記述・装飾 | |
| 下流工程 | UT | 単体テスト | 機能単位での動作確認 |
| IT | 結合テスト | 複数機能の連携確認 | |
| PT | 総合テスト | システム全体の動作・性能確認 | |
| ST | システムテスト | 本番環境を想定した最終確認 | |
| OT | 運用テスト | 実運用フローでの最終確認 |
4つの区分でわかるシステム開発工程の流れ
18のフェーズはそれぞれ独立したものではなく、「上流→設計→実装→下流」という大きな流れの中に位置づけられます。各区分の役割を押さえると、自分の担当工程が全体のどこにあたるかが見えてきます。
上流工程（SP・SA・RD）：何を作るかを決める
システム開発の方向性を決定する最重要フェーズです。とくに要件定義（RD）で決めた内容がプロジェクト全体の品質を左右するため、ここで時間をかけて関係者と合意を取ることが重要です。上流工程の精度が低いと、設計・実装・テストすべての段階で手戻りが発生します。
設計工程（UI・ED・DD・ID・SS・FD・PD/PS）：どう作るかを決める
上流で決まった要件を、開発者が実装できる粒度まで落とし込むフェーズです。ユーザーから見える「外部設計」と、システム内部の動きを定義する「内部設計」に大きく分かれます。設計の段階で機能の抜け漏れや矛盾を発見できれば、後工程の手戻りを大幅に減らせます。
実装工程（PG・CD）：設計をプログラムにする
設計書に基づいて実際にプログラムを作成する段階です。エンジニアのコーディングスキルや使用言語の習熟度が成果物の品質に直結します。プログラミングとコーディングは厳密には区別される場合がありますが、現場では同義で使われるケースも多くあります。
下流工程（UT・IT・PT・ST・OT）：品質を担保する
作成したシステムが要件どおりに動くかを検証するフェーズです。単体テストから始まり、徐々にテスト範囲を広げ、最終的に運用テストで本番運用を想定した検証を行います。テスト工程を軽視すると、リリース後の重大なトラブルにつながるため、納期が押している現場ほど注意が必要です。
V字モデルで開発工程とテスト工程を対応づける
V字モデルとは、開発工程とテスト工程を対応関係で整理したモデルです。アルファベットの「V」のように、左側に開発工程、右側にテスト工程を配置することからこの名前で呼ばれます。
| 開発工程 | 対応するテスト工程 |
|---|---|
| 要求定義 | 運用テスト |
| 要件定義 | 総合テスト |
| 基本設計 | 結合テスト |
| 詳細設計 | 単体テスト |
V字モデルを活用すると、「詳細設計を単体テストで確認する」「要件定義を総合テストで確認する」といった対応関係が明確になります。テスト工程で何を確認すべきかを事前に整理できるため、品質の担保と効率的な進行を両立できます。
代表的な開発モデル4つの違いと選び方
システム開発工程の進め方は、選択する開発モデルによって変わります。代表的な4モデルの違いを押さえておきましょう。
| モデル | 特徴 | 向いているケース |
|---|---|---|
| アジャイル | 短いサイクルで開発・テストを繰り返す。現代の主流 | 仕様変更が多い／スピード重視 |
| ウォーターフォール | 上流→下流に一方向で進める。進捗管理しやすい | 要件が明確／大規模・長期 |
| スパイラル | サブシステム単位でウォーターフォール型に進める | 段階的に機能を増やす中規模開発 |
| プロトタイプ | 試作品を作りクライアントの反応を反映する | イメージ共有が難しい小〜中規模 |
近年は、要件が明確な部分はウォーターフォール、変更が多い部分はアジャイルを使い分ける「ハイブリッド型」を採用する現場も増えています。プロジェクトの規模、要件の確度、納期、チーム体制などを総合的に判断してモデルを選びましょう。
工程管理を成功させる実務的なコツ
18のフェーズや開発モデルを理解しても、運用が伴わなければプロジェクトは成功しません。長年現場を見てきた経験から、押さえておきたいコツを3つに整理しました。
1. 上流工程に時間をかける
システム開発の手戻りコストは、フェーズが進むほど大きくなります。要件定義の段階で関係者の合意を取ることに時間を惜しまないこと——これがプロジェクト全体の品質を高める最短ルートです。「早く実装に入りたい」気持ちを抑えて、上流工程を丁寧に進めましょう。
2. メンバーのスキルに合った工程配置を行う
各工程に必要なスキルは異なります。要件定義には業務分析力、設計には抽象化能力、コーディングには実装スキル、テストには品質意識——エンジニアの保有スキルと工程の要件をマッチングさせることで、生産性は大きく変わります。適材適所のアサインができていないと、優秀なメンバーがいてもプロジェクトはうまく回りません。
3. 進捗とアサイン状況を可視化する
「どの工程が今どこまで進んでいるか」「誰がどの案件で稼働しているか」をリアルタイムで把握できる体制を整えましょう。可視化することで、ボトルネックの早期発見やリソースの再配分がスムーズになります。Excelでの管理に限界を感じている現場では、専用ツールの導入が効果的です。
システム開発を進める上でスキル管理ツール導入のメリットをご存知ですか？
システム開発工程を効率良く進めるには、各フェーズに最適なスキルを持つエンジニアを配置することが欠かせません。要件定義に強いエンジニア、設計が得意なエンジニア、テスト工程で力を発揮するエンジニア——それぞれの強みを正確に把握できていなければ、工程ごとの生産性は最大化できません。
Excelやスプレッドシートでのスキル管理には限界があります。情報の更新が追いつかない、横断検索ができない、最新のアサイン状況と連動しない——こうした課題は、スキル管理ツールの導入で解決できます。エンジニアの保有スキルや経験を一元管理し、各工程に最適なメンバーを即座に検索できる体制こそ、システム開発工程の質を一段引き上げる鍵です。
