システム開発を外部の会社に依頼しようとしたとき、「そもそもどんな工程を経て完成するのか分からない」と感じる方は少なくありません。
工程を理解しないまま発注すると、開発会社ごとに提案範囲がずれて見積もりを比較できなかったり、要件定義段階の合意不足が原因で後から追加費用が発生したりします。
本記事では、システム開発工程の全体的な流れ、各工程の成果物、V字モデルの考え方、ウォーターフォールとアジャイルの違い、工数比率の目安、失敗を避けるポイントまでわかりやすく解説します。
システム開発工程とは?プロジェクト全体の流れをわかりやすく解説
システム開発工程とは、企画・要件定義から設計・開発・テスト・リリース・運用保守に至るまで、システムを完成させるために踏む一連のプロセスのことです。
システム開発は、いきなりプログラムを書き始めるわけではありません。まず依頼主(発注者)の要望を整理し、実現する機能を設計図に落とし込み、その設計に沿ってプログラムを組み立て、最後に正しく動作するかを検証してから本番環境へ移行するという順序を踏みます。
この一連の流れを工程ごとに区切って管理することで、進捗や品質を可視化し、関係者全員が同じゴールに向かって作業を進められるようになります。
一般的に、要件定義・基本設計・詳細設計までを「上流工程」、プログラミング・テスト・リリース・運用保守を「下流工程」と呼びます。
上流工程で決めた内容が下流工程の作業範囲や工数を左右するため、上流工程の精度がプロジェクト全体の成否を大きく左右する点は覚えておく必要があります。
実際、日経コンピュータの調査では、システム開発プロジェクトが品質・コスト・納期(QCD)をすべて満たして成功する割合は15年前の26.7%から近年は52.8%まで改善したものの、失敗理由の筆頭には今なお「要件定義が不十分だったこと」が挙げられています。
システム開発工程一覧｜要件定義から運用保守までの6フェーズと成果物
システム開発工程は、大きく分けて「要件定義」「基本設計」「詳細設計」「開発(プログラミング)」「テスト」「リリース・運用保守」の6フェーズで構成されます。
各工程では担当者が変わったり、次工程に進むための承認が必要になったりするため、それぞれの成果物を把握しておくと発注者としての理解が深まります。
要件定義・基本設計・詳細設計は「上流工程」
最初の「要件定義」では、発注者の業務課題や実現したいことをヒアリングし、必要な機能・操作の流れ・予算・スケジュール・体制まで具体的に整理します。
成果物は「要件定義書」で、以降の工程はすべてこの文書を土台に進みます。
ここで曖昧な点を残したまま次工程へ進むと、後述するとおり後工程での手戻りにつながりやすいため、発注者自身も内容を丁寧に確認することが欠かせません。
次の「基本設計(外部設計)」では、要件定義で固まった要望を実現するために、システムに実装する機能や画面構成を明確化・具体化します。成果物は機能ごとに作成される「基本設計書」です。
続く「詳細設計(内部設計)」では、基本設計の内容をプログラムとして実現する方法まで落とし込みます。
成果物は「詳細設計書」や「機能仕様書」で、これがプログラマーへの実質的な指示書となります。
開発・テスト・リリースは「下流工程」
「開発(プログラミング)」工程では、詳細設計で決まった仕様に沿って実際にプログラムを組み立てます。
設計内容を正確に実装し、品質を確保することが主な役割です。
「テスト」工程では、プログラムが仕様どおりに動作するかを単体テスト→結合テスト→システムテスト→受入テスト(UAT)の順に検証していきます。
1つの工程で問題が見つかった場合、原因となった設計や実装まで遡って修正するため、テストを複数段階に分けることで不具合の混入箇所を特定しやすくしています。
最後の「リリース(システム移行)・運用保守」工程で本番環境へシステムを移行し、稼働開始後は不具合対応や機能改善などの保守運用へと移ります。
システム開発工程における「V字モデル」の考え方
システム開発工程を理解するうえでよく登場するのが「V字モデル」という考え方です。
これは、要件定義から実装までの「開発フェーズ」と、単体テストから受入テストまでの「テストフェーズ」を対応づけ、V字の形で図式化したものです。
具体的には、要件定義の内容は最終段階の受入テスト(UAT)で、基本設計の内容はシステムテストで、詳細設計の内容は結合テストで、プログラミングの内容は単体テストで、それぞれ検証されるという対応関係になります。
V字モデルを意識することで、「この設計書に書いた内容は、どのテストで確認されるのか」があらかじめ明確になり、テスト漏れや仕様の認識違いを防ぎやすくなります。
ウォーターフォール型の開発と組み合わせて使われることが多い考え方ですが、発注者にとっても各工程のつながりを理解する助けになります。
システム開発工程の2大手法｜ウォーターフォールとアジャイルの違い
同じ6フェーズの工程でも、どの順序・サイクルで進めるかによって「ウォーターフォール型」と「アジャイル型」という2つの代表的な手法に分かれます。
自社のプロジェクトにどちらが向いているかを知っておくことは、発注前の重要な判断材料になります。
ウォーターフォール型の特徴とメリット・デメリット
ウォーターフォール型は、要件定義から運用保守までの工程を上流から下流へ順番に進め、原則として前の工程には戻らない手法です。
計画をすべて決めてから着手するため完成度が高く、進捗やコストの見通しを立てやすい点がメリットです。
一方で、前の工程が完了しないと次の工程に着手できないため開発期間が長期化しやすく、途中での仕様変更に弱いというデメリットがあります。
要件が明確で、正確性・安全性が強く求められる業務システムなどに向いた手法です。
アジャイル型の特徴とメリット・デメリット
アジャイル型は、機能単位で「設計→開発→テスト」の小さなサイクルを繰り返しながら開発を進める手法です。
一定の区切りごとに発注者の要望を確認できるため、途中の仕様変更や優先順位の入れ替えに柔軟に対応できる点がメリットです。
反面、全体の完成イメージや進捗管理が難しくなりやすく、当初の想定より工数が膨らむこともあります。
市場の変化が速く、要件が変化しやすいプロジェクトに向いています。なお実務では、両者の長所を組み合わせた「ハイブリッド型」で進めるケースも珍しくありません。
システム開発工程ごとの工数比率・期間比率の目安
各工程にどれだけの工数(人員×時間)を配分するかを示す「工程比率」は、見積もりの妥当性を判断するうえで重要な指標です。
一般的な目安として、要件定義に全体の10〜15%、基本設計・詳細設計に20〜30%、開発(プログラミング)に30〜40%、テストに15〜25%程度を配分するケースが多いとされています。
プロジェクトの規模や新規開発か改修かといった特性によって最適な比率は変わりますが、独立行政法人情報処理推進機構(IPA)が公表する「ソフトウェア開発データ白書」でも、工程別の工数比率・期間比率が統計データとして示されており、多くの開発会社が見積もりの妥当性を検証する際の参考値として活用しています。
例えば開発期間が6ヶ月のプロジェクトであれば、要件定義に3〜4週間、設計に6〜8週間、開発に9〜10週間、テストに4〜6週間程度を配分するのが1つの目安になります。
見積書を受け取った際に、この目安から極端に外れた配分になっていないかを確認するだけでも、発注者として提案内容の妥当性をある程度チェックできます。
特に要件定義の工数が極端に少ない見積もりは、後工程での仕様変更や追加費用につながりやすいため注意が必要です。
システム開発工程と契約形態(請負契約・準委任契約)の関係
システム開発工程を理解するうえで、あわせて押さえておきたいのが契約形態です。
工程によって、発注者と開発会社の間で結ぶ契約の性質が変わることがあります。
「請負契約」は、成果物の完成に対して報酬を支払う契約形態です。
基本設計・詳細設計・開発(プログラミング)のように、仕様が固まっていて成果物を明確に定義できる工程でよく使われます。
開発会社には成果物を完成させる義務(契約不適合責任)が生じるため、発注者は仕様どおりの納品を期待できます。
一方「準委任契約」は、成果物の完成そのものではなく、稼働した工数(業務の遂行)に対して報酬を支払う契約形態です。
要件定義のように仕様がまだ固まっていない工程や、リリース後の運用保守のように継続的な対応が求められる工程で使われることが多くあります。
準委任契約では成果物の完成は保証されないため、発注者側もある程度プロジェクトに関与し、進捗を確認しながら進める姿勢が求められます。
どちらの契約形態が使われているかによって、発注者が負うべき役割や責任の範囲も変わります。
契約前に、どの工程がどちらの契約形態にあたるのかを開発会社に確認しておくと、後のトラブルを避けやすくなります。
システム開発工程でよく使われる略語一覧
システム開発の現場では、工程名がアルファベットの略語で呼ばれることが多く、見積書や提案書にもそのまま使われるケースがあります。
代表的な略語を知っておくと、開発会社とのやり取りがスムーズになります。
– 要件定義: RD(Requirement Definition)
– 基本設計(外部設計): SA(System Architectural design)
– 詳細設計(内部設計): SS(System Structure design)、PS(Program Structure design)と呼ばれることもある
– プログラミング(開発): PG(Programming)
– 単体テスト: UT(Unit Test)
– 結合テスト: IT(Integration Test)
– システムテスト: ST(System Test)
– 運用テスト・受入テスト: OT(Operation Test)、UAT(User Acceptance Test)
これらの略語は開発会社や案件によって多少の違いがあるため、見積書や進捗報告で見慣れない略語が出てきた場合は、遠慮せずに確認することをおすすめします。
システム開発工程を理解せずに発注すると起こりやすい失敗と成功のポイント
システム開発工程の流れを理解しないまま発注すると、いくつかの典型的な失敗につながります。
1つ目は、開発会社ごとに提案範囲や前提条件が異なるため、金額だけで見積もりを比較してしまい、実際には作業範囲の異なるものを比べていたというケースです。
2つ目は、要件定義の段階で社内の合意形成が不十分なまま設計・開発フェーズに進み、後から「やはりこの機能も必要だった」という追加要望が発生し、納期遅延や追加費用につながるケースです。
前述のとおり、日経コンピュータの調査でもシステム開発失敗の理由として最も多く挙がるのが「要件定義の不十分さ」であり、特に開発期間が3年を超えるような大規模プロジェクトでは成功率がわずか16%まで落ち込むというデータもあります。
こうした失敗の多くは、発注者自身が工程の全体像と各工程で何を決めるべきかを事前に把握しておくことで、未然に防げるものです。
最後に、中小企業がシステム開発を発注する際に押さえておきたいポイントを3つ紹介します。
1つ目は、発注前に自社の業務課題と開発目的を明確にしておくことです。
「何のためにシステムを導入するのか」が曖昧なままでは、要件定義工程で開発会社と十分な議論ができません。
2つ目は、見積もりを比較する際に、工程ごとの作業範囲と工数比率まで確認することです。
金額の総額だけでなく、どの工程にどれだけの工数が配分されているかを見ることで、提案内容の妥当性を判断しやすくなります。
3つ目は、自社のプロジェクト特性(要件が固まっているか、途中で変化しやすいか)に応じて、ウォーターフォール型・アジャイル型のどちらが適しているかを開発会社と相談しながら決めることです。
システム開発工程の全体像を理解しておくことは、専門知識がない発注担当者にとっても、開発会社との認識のズレを防ぎ、プロジェクトを成功に導くための第一歩になります。
システム開発工程に関するよくある質問
Q. システム開発工程全体でどのくらいの期間がかかりますか?
A. システムの規模によって大きく異なりますが、目安として中小規模のシステムで3ヶ月〜半年程度、大規模なシステムでは1年以上かかることも珍しくありません。
前述の工数比率のとおり、要件定義だけでも全体期間の1〜2割程度を占めることが多いため、発注前にはこの期間も見込んでスケジュールを組む必要があります。
Q. 開発の途中で仕様を変更したくなった場合はどうすればいいですか?
A. ウォーターフォール型では、後工程で仕様変更が発生すると前の工程までさかのぼって修正が必要になるため、追加費用や契約変更の交渉が必要になりやすい傾向があります。
アジャイル型であれば比較的柔軟に対応できますが、いずれの手法でも、契約前に仕様変更が発生した場合のルール(変更管理プロセスや費用負担の考え方)を開発会社とすり合わせておくことが、後のトラブルを避けるポイントです。
システム開発の進め方や自社に合った手法の選び方について、AI活用も含めて相談したい場合は、Dimebizまで気軽にお問い合わせください。
