システム開発の全工程を徹底解説！ ウォーターフォール・アジャイルの違いや最新トレンドまで分かる
複数の企業がプロジェクトに参画し、分業しながら進めていくことが多いシステム開発。すでにエンジニアとして活躍している人でも、「自分が担当する工程以外はあまり知らない」「システム開発の全体像が分からない」という人は少なくないのでは？
この記事では、基本的なシステム開発の工程や、代表的な開発手法であるウォーターフォールモデルやアジャイルモデルなどについて紹介します。その他、システム開発の現場で頻出する略語についても合わせて解説。
プロジェクト開発についての理解を深め、これからのキャリアについて考えるきっかけにしてみましょう。
※この記事は2024年1月5日に公開し、2025年3月31日に内容を更新しております
目次
システム開発工程とは？
まずはシステム開発における各工程でどのようなことが行われているのかを詳しく解説します。一般的には、要件定義に近いほど上流工程と呼ばれ、保守や運用に近いほど下流工程と呼ばれます。
ただし、一口に「システム開発の工程」といっても、プロジェクトの規模や開発手法などによっては明確に分かれていなかったり、省略されたりすることもあります。現在自分が担当している工程はどのあたりなのか、将来的にどのような工程に携わりたいのかなどを考えながら読んでみてくださいね。
要件定義
要件定義の工程ではクライアントと共に、これからどのようなシステムをどんな開発手法で作るのか、導入や運用方法、予算、開発期間など、システム開発に必要な要件を決めていきます。この話し合いの場にはベンダーが参加するのが一般的ですが、プロジェクトの規模によっては開発会社のPMやPL、SEなども参加することがあります。
システム開発は、要件定義で決めた内容に基づいて進んでいくため、最終的にトラブルが発生しないように、クライアント側と開発側の双方が認識を合わせておくことが必要です。要件定義は開発工程における設計図を作る“最上流工程”であり、もっとも重要なフェーズといえます。
基本設計、詳細設計
基本設計は、要件定義の工程で決めた内容を基に、主にインターフェース（ユーザーから見える部分）を決定する工程です。プロジェクトの規模にもよりますが、基本設計書は一般的にシステムの機能ごとに作成されます。
各システムを担当するシステム会社のエンジニアが基本設計書を作成し、それぞれの基本設計書を相互にフィードバック・改善しながら完成させていきます。完成した基本設計書はクライアントが確認する資料なので、専門用語や複雑なデータが記載されることは少ないです。
基本設計書の内容が決定したら、その内容を基に詳細設計書を作成します。基本設計書がクライアント向けの資料だったのに対し、詳細設計は各開発会社のエンジニア向けの資料です。搭載予定の機能をモジュールごとに分割し、具体的な実装を想定した「機能仕様書」「データフロー図」「データベース物理設計書」など、より専門的な資料を作成しながら、プログラミング工程に進むための設計書を確定していきます。
プログラミング
詳細設計が終わったらいよいよ製造工程です。各開発会社のSEやプログラマーが詳細設計書の内容に基づき、プログラミングを行っていきます。
テスト工程
プログラミング工程が終わったら、作成したプログラムが要件定義で決めた通りの動きをするかを確認するため、テスト工程に移ります。
テストには開発の進捗段階や検証する内容によって、さまざまな種類や手法が存在します。それぞれ詳しく解説します。
●製造・単体テスト
まずはモジュール単位でテストを行い、不具合が見つかったら修正したり、テスト結果のフィードバックを行ったりしながらプログラムを完成させていきます。企業によってはテスターというポジションがテスト工程を担当することもあります。
●結合テスト
単体テストで各モジュールに不具合がないことを確認したら、次は複数のモジュールを組み合わせたサブシステムに不具合が起きないか、各サブシステムのインターフェースにズレがないか、各サブシステムの連携がうまくいっているかなどの確認をしていきます。
規模の大きいプロジェクトの場合は結合テストを２段階に分け、サブシステム内の連携をチェックする内部結合テストとサブシステム外の連携をチェックする外部結合テストを行うこともあります。
●システムテスト（総合テスト）
結合テストで各サブシステムの不具合がないことを確認したら、いよいよシステム全体に不具合がないかの確認をするシステムテストです。すべてのプログラムが要件定義で決めた通りの動きをするかを確認するのはもちろん、アクセス過多時の耐久性や処理速度の速さなどあらゆる角度からテストを行います。
●運用テスト
運用テストとは、システムを納品・リリースする前の最終工程です。クライアントの要望を満たした上で、その機能が正常に稼働するかはもちろん、誤操作しにくい仕様になっているか、もっと操作性が上がらないかなど、実際にユーザーが使う時に起こりうるトラブルや不具合などを想像しながら細かくチェックしていきます。
クライアント側のテスト担当者が実際の業務を想定しながら運用テストを実施することもあります。先ほども述べた通り、運用テストはリリース前の最終テストとなるため、システムのクオリティーに直結する重要な工程といえます。
システム移行（リリース）
一般的に、開発したシステムをリリースする時は、旧システムから新システムに移行する工程が必要となります。
このシステム移行の工程は、エンジニアにとって最も緊張感を味わう工程と言っても過言ではありません。その理由は、旧システムの仕様によってあらゆるトラブルが予想されるからです。また、サービスを停止できる時間には限りがあるため、時間制限がある中でシステム移行を行わなければなりません。
新システムにデータを移行しても想定通りの動作をするよう、さまざまな懸念点を考慮しながら移行手順書を作成し、システム移行がスムーズに進むようにしておくことが求められます。
システム移行をする方法としては、旧システムから新システムに一気に切り替える一斉移行という方法と、機能ごとに徐々に切り替えていく順次移行があります。
運用、保守
リリースしたシステムを問題なく稼働し続けるには保守・運用業務が必要になります。
運用とは、システムの改修やアップデートなど、システムに変更を加えることを指します。それに対し保守は、システムが滞りなく稼働するようにデータを入力したり、サーバダウンなどのトラブルが発生したときに対応手順書に沿って処理をしたりすることを指します。
運用・保守工程はどちらもシステムの安定稼働がミッションとなるので、それぞれの担当者が連携することが大切です。また運用、保守の工程は、社内の情報システム部門が担当することもあれば、外部のシステム会社が担当することもあります。
なぜ工程を分けて開発するのか？
ここまでシステム開発はいくつかの工程に分けて行うことを説明してきましたが、そもそもなぜ分業してシステム開発をするのかというと「効率よく、品質の高いシステムを作るため」です。具体的に説明します。
タスク管理をしやすくするため
プロジェクトの規模にもよりますが、システム開発には半年～数年を要するような長期プロジェクトが多くあります。そのため、開発工程をフェーズごとに細分化し、細かくゴールを設定することでメンバー全員がシステム開発の完成図をイメージしやすいという利点があるのです。フェーズごとに管理者を設定すればタスク管理もしやすくなります。
トラブル発生を防ぐため
フェーズごとに細かくテストしていくことで、システム完成後に「気付いたら不具合だらけだった」というトラブルを防ぐことにつながります。これは、システムの品質を上げるうえで重要な意味を持ちます。
人員配置を最適化するため
フェーズごとに必要な技術や作業量も異なるため、そのフェーズに特化したメンバーを投入したり、状況に応じて人員を追加・変更したりすることも可能になります。工程を分けることで、複雑化しやすいシステム開発がより簡潔になり、その結果システム開発の効率化・クオリティー向上につながっているのです。
開発工程モデルとは？
開発工程モデルとは、開発プロセスのことを指します。開発工程モデルは、先ほどご紹介した開発フェーズをどのように進めていくかによって分類されます。
今回は代表的な開発工程モデルであるウォーターフォールモデルとアジャイルモデルの二つを詳しく説明します。
ウォーターフォールモデル
「ウォーターフォール」は、日本語で「滝」という意味です。つまりウォーターフォールモデルとは、滝のように上流から下流に向かって進んでいき、戻ることのない一方通行の開発プロセスのことを表しています。
ウォーターフォールモデルの最大のメリットは、一つのフェーズが完了してから次のフェーズに着手するため、進捗の把握が比較的簡単な点です。進捗の把握が管理しやすい分、品質がある程度担保しやすいのもメリットの一つといえます。
一方、ウォーターフォールモデルのデメリットは、ミスや不具合があった場合、それをリカバリーするのに時間やコストが掛かること。特に要件定義や基本設計などの上流工程にミスがあった場合は、多大なコストが掛かります。
ミスや不具合を改善し、前のフェーズが完了するまで次のフェーズには進めないため、スピードが求められるプロジェクトにはあまりふさわしくないと言われています。
アジャイルモデル
「アジャイル」は日本語で「俊敏な」という意味で、その名の通りスピードが求められるプロジェクトと相性がいい開発工程モデルです。ウォーターフォールモデルとは逆に、後戻り前提で工程を進めていくため、設計段階ではあえて詳細まで決めず、全体を作りながら随時修正を行っていきます。
アジャイルモデルのメリットは先ほども述べたように、開発スピードが速いこと。新規事業などで工程や成果物のイメージがつきにくい場合でも、とりあえず開発をスタートできる柔軟さもあります。
一方で、アジャイルモデルは工程の進捗や状況を把握するのが難しいため、管理しづらい点がデメリットです。また、アジャイルモデルは比較的新しい開発工程モデルなので、対応できる開発会社が少ない点もデメリットの一つ。アジャイルモデルでの開発実績が少ない分、開発会社はクライアントにメリットを理解してもらうのが難しいというデメリットもあります。
その他
●プロトタイプモデル
「プロトタイプ」とは日本語で「試作品」という意味です。まず開発初期に試作品を作成し、クライアントや関係者に確認してもらった上で開発を進められるため、認識のずれを最小限に防げる点が最大のメリットです。
一方で大規模なシステム開発の場合、プロトタイプを作るだけで膨大な時間やコストが必要になってしまうため、プロトタイプモデルは小規模なシステム開発に向いているといわれています。また、開発からプロトタイプ確認のプロセスを何度も繰り返すことになるため、開発会社側の負担が大きい点もプロトタイプモデルのデメリットの一つです。
プロトタイプを作成し、クライアントと認識のすり合わせが終わった後は、ウォーターフォールモデルと同じ流れとなります。
●スパイラルモデル
スパイラルモデルは、サブシステムごとに開発を進め、プロトタイプをクライアントに確認してもらいながら進めていくモデルです。
一つ一つのサブシステムはウォーターフォールモデルで開発を進めていきます。スパイラルモデルは要件定義で詳細を細かく決めず、サブシステムごとに計画を立てていくため、途中で計画変更があっても柔軟に対応しやすい点が大きなメリットです。
またプロトタイプモデルと同様に、試作品をクライアントにチェックしてもらいながら進められるため、クライアントと完成図を共有しながら開発を進められる点もメリットの一つです。
スパイラルモデルは柔軟さがある一方で、プロトタイプに不具合や修正が多いほど何度も開発の工程を踏まなければならないため、プロジェクトの進捗を把握しづらい点がデメリットの一つ。またサブシステムが多いほど開発コストも増えていきます。
スパイラルモデルのように各フェーズを一つの作業計画とし、プロトタイプを作成しながら進めていく開発工程モデルの総称を「反復型開発プロセス」と呼びます。反復型開発プロセスに分類される開発工程モデルは、スパイラルモデルのほかにインクリメンタルモデル、インテレーティブモデルなどが有名です。インクリメンタルモデルについては、次で説明します。
●インクリメンタルモデル
インクリメンタルモデルは、システム開発を小さな機能単位（インクリメント）に分割し、段階的に開発を進める手法です。各インクリメントは独立した機能として設計・開発・テストされ、完成した段階でシステムに組み込まれていきます。
システム全体を一度に開発するのではなく、段階的に機能を追加していくため、開発リスクを分散できます。また、各インクリメントが完成するごとにシステムを利用できるため、ユーザーは早期にシステムの恩恵を受けられます。開発途中での要件変更にも柔軟に対応しやすく、変化の激しいビジネス環境に適しているといえるでしょう。各インクリメントのリリースごとにユーザーからのフィードバックを得ることで、システムの改善を継続的に行えます。
インクリメンタルモデルは、アジャイル開発とウォーターフォール開発の中間的な性質を持ち、両方の利点を組み合わせた開発手法といえます。小規模なプロジェクトから大規模なプロジェクトまで、幅広いプロジェクトに適用可能です。
システム開発工程で覚えておきたい略語
システム開発の現場では略語や英語が使用されることが多くあり、「なんとなく使っているけど、何の略？」「あれってどういう意味？」と感じることも少なくないのではないでしょうか。そこで今回は、システム開発の現場でよく使われる略語を紹介します。
システムに関わる言葉を知っておくと、打ち合わせなどの場でも便利ですよ。
・SP（System Planning）：企画
・SA（System Architectural design、Service Analysis、System Analyze）：要求分析
・RD（Requirements Definition）：要件定義
・BD（Basic Design）：基本設計
・SS（System Structure Design）：構造設計
・FD（Function Design）：機能設計
・DD（Detail Design）：詳細設計
・PS（Program Structure Design）：詳細設計
・M（Manufacture）：製造
・UT（Unit Test）：単体テスト
・CD（Cording）：コーディング
・PG（Programing）：プログラミング
・IT（Integration Test）：結合テスト
・ST（System Test）：システムテスト
・OT（Operation Test）：運用テスト
最新のシステム開発動向
近年、システム開発の現場は、技術革新の波に乗り、かつてないほどのスピードで変化しています。
ここでは、システム開発の各工程に変化をもたらすであろう最新の動向を紹介します。
クラウドネイティブ開発
クラウドネイティブ開発は、クラウド環境の特性を最大限に活用し、コンテナ、マイクロサービス、APIなどの技術を用いて、スケーラブルで柔軟性の高いアプリケーションを開発する手法です。これにより、開発者はインフラの管理から解放され、より迅速にアプリケーションを開発・デプロイできるようになります。
ローコード／ノーコード開発
ローコード／ノーコード開発は、プログラミングの知識が少ない人でも、GUIベースの開発ツールを用いてアプリケーションを開発できる手法です。これにより、開発者はコードを書く量を大幅に削減し、開発期間を短縮できます。ビジネス部門の担当者が自らアプリケーションを開発できるため、ビジネスニーズへの迅速な対応が可能になります。
DevOps／DevSecOps
DevOpsは、開発（Development）と運用（Operations）の連携を強化し、開発サイクルを高速化する手法です。DevSecOpsは、DevOpsにセキュリティ（Security）を組み込み、開発の初期段階からセキュリティを考慮した開発を行う手法です。これにより、開発者はより安全で高品質なシステムを迅速に提供できます。
サーバーレスアーキテクチャ
サーバーレスアーキテクチャは、サーバーの管理をクラウドプロバイダーに任せ、関数単位でコードを実行する開発手法です。これにより、開発者はインフラの管理から解放され、アプリケーションの規模に応じて自動的にリソースを調整できます。
生成AIの活用
近年、生成AIはシステム開発の現場でも活用され始めています。例えば、コード生成、テストケース生成、ドキュメント生成などに生成AIを活用することで、開発者は開発効率を大幅に向上させることができます。
これらの最新動向を踏まえ、システム開発者は常に新しい技術や手法を学び、柔軟に対応することが重要です。変化の激しい時代において、最新の情報をキャッチアップし、最適な技術を選択することで、より高品質なシステムを効率的に開発できるでしょう。
まとめ
基本的なシステム開発の工程や、代表的な開発手法、システム開発の現場で使用される略語についてご紹介しました。今自身が担当している工程や、これからチャレンジしてみたい工程を理解することで、今後のキャリアについて考えるきっかけにしてみてくださいね。
また上流工程になればなるほど、開発手法について考えたり略語を使用する機会が増えたりすることもあると思います。「今後上流工程を目指したい！」と思っている人は、ぜひ参考にしてみてくださいね。
文／赤池沙希 編集／エンジニアtype編集部
RELATED関連記事
システム開発に欠かせない要件定義、重要性や進め方のコツは？ 失敗事例も解説！
システム開発におけるプログラミングの進め方や注意点は？ スキルアップ方法や人気の言語も解説
システム開発のテスト工程は重要なの？ テストの種類や進め方を詳しく解説
駆け出しエンジニアが覚えておきたい「IT用語」の意味を解説
システム運用・保守とは？ それぞれの違いや業務内容、仕事のやりがいや注意点を解説！
JOB BOARD編集部オススメ求人特集
RANKING人気記事ランキング
日本の技術者は万博を楽しむ知力が残っているか？ 落合陽一に聞く、逆風ムードでも「万博に行くべき理由」
AWS認定資格10種類を一覧で解説！ 難易度や費用、おすすめの学習方法も
「エンジニアの実力は肩書きでは測れない」LayerX AI・LLM事業部 CPO 小林 篤に見る“疑念駆動”のキャリアメーク
「三流でもいいは甘えだった」牛尾 剛が米マイクロソフトで痛感した、妥協を捨てる覚悟
【稼げるIT職種2025】「年収800万円以上欲しいエンジニア」が知っておきたい、今狙い目の職種TOP4
タグ
そのほかのタグを見る
