システム開発を外部ベンダーに依頼しようと考えている企業の担当者にとって、「工程の全体像がつかめていない」という状態は大きなリスクです。
どの工程で何が決まり、発注側は何をすべきなのかを把握していないと、完成したシステムが業務実態と合わなかったり、後から多額の追加費用が発生したりする事態を招きかねません。
本記事では、システム開発の工程を要件定義からリリースまで順を追って解説し、各工程で発注側が押さえておくべき注意点も合わせてご紹介します。
AI・DX支援
AI活用・業務効率化、
専門家に相談してみませんか？
DimeBizを運営するFrom Downtown合同会社では、中小企業のAI導入・DX推進をご支援しています。
記事の内容に関するご質問もお気軽にどうぞ。
システム開発の工程とは
システム開発の工程とは、あるシステムを企画・構想の段階からリリースして実際に稼働させるまでの一連の作業手順を指します。
工程を段階的に区切ることで、「現在どこまで進んでいるか」「次に何をすべきか」が明確になり、品質管理やスケジュール管理が行いやすくなります。
システム開発の工程は大きく「上流工程」と「下流工程」の2種類に分類されます。
上流工程は要件定義・基本設計・詳細設計を指し、システムの方向性や仕様を決める段階です。
下流工程は製造（プログラミング）・テスト・リリース・運用保守を指し、実際にシステムを作り込み、安定稼働させる段階です。
発注側にとって特に重要なのは上流工程です。要件定義や設計の段階での認識のズレが後工程に影響するため、上流工程への積極的な関与が開発成功の鍵となります。
独立行政法人情報処理推進機構（IPA）の統計データでも、プロジェクト失敗原因の約半数が要件定義に起因すると複数の分析で示されており、上流工程の重要性を裏付けています。
システム開発の工程と流れ（7つのステップ）
標準的なシステム開発は、以下の7つの工程で進みます。
要件定義
要件定義は、システムで何を実現するのかを明文化する工程です。
具体的には、現状の業務課題の整理、解決すべき問題の特定、必要な機能の洗い出し（機能要件）、処理速度やセキュリティなどの性能基準の設定（非機能要件）を行い、要件定義書としてまとめます。
この工程の成果物である要件定義書は、その後の設計・製造・テストすべての基準になります。
曖昧なまま進めると後工程で修正が膨らみ、コスト増と納期遅延に直結します。
発注側は自社の業務プロセスを整理し、「何を課題と感じていて、システムで何を解決したいのか」を具体的に言語化することが求められます。
要件定義の具体的な進め方については、下記記事で詳しく紹介しています。
基本設計（外部設計）
基本設計は、要件定義で決まった内容をシステムの仕様として具体化する工程です。
ユーザーが実際に触れる部分、すなわち画面の構成・入出力の操作・帳票のフォーマット・データの流れなどを定義します。
「外部設計」とも呼ばれるのは、システムの外側（ユーザーインターフェース側）の設計を行うためです。
成果物には基本設計書、システム構成図、インターフェース設計書などが含まれます。
発注側もこの段階で設計書の内容を確認し、業務の実態と合致しているかを検証することが重要です。
詳細設計（内部設計）
詳細設計は、基本設計で定めた仕様をエンジニアが実装できるレベルまで詳細化する工程です。
どのような処理ロジックで機能を実現するか、データベースのテーブル構造はどうするか、といった「システムの内側」の仕様を設計します。
「内部設計」とも呼ばれます。
成果物は詳細設計書（内部設計書）で、エンジニアはこの設計書をもとに実際のプログラムを書きます。
詳細設計の品質がそのまま製造工程の効率と最終的なシステムの品質に影響するため、設計工程への工数投資は惜しむべきではありません。
製造（プログラミング）
製造工程は、詳細設計書に基づいてエンジニアが実際にプログラムを書く工程です。
IPAの「ソフトウェア開発分析データ集2022」（5,546プロジェクト分析）によると、新規開発における製造工程の工数比率の中央値は約31%と最も高く、全工程の中で最も人的リソースを要する工程です。
この工程では、開発言語やフレームワークの選定が品質・保守性・将来的な拡張コストに大きく影響します。
発注側がプログラムの中身を直接確認する場面は少ないものの、進捗報告の頻度や確認方法をあらかじめベンダーと取り決めておくことで、手戻りのリスクを低減できます。
テスト（単体・結合・システム・運用）
テスト工程は、製造したシステムが要件定義・設計の仕様通りに動作するかを段階的に検証する工程です。
一般的に以下の4段階で実施します。
単体テスト（UT：Unit Test）は、個々のプログラムモジュールを単独でテストします。
結合テスト（IT：Integration Test）は、複数のモジュールを組み合わせた際の連携動作を確認します。
システムテスト（ST：System Test）は、システム全体を対象に機能・性能・セキュリティを総合的に検証します。
運用テスト（UAT：User Acceptance Test）は、発注者側が実際の業務環境に近い条件でシステムを操作し、「業務で使えるか」を確認します。
テスト工程とその対応する設計工程の関係は「V字モデル」として整理されています。
要件定義はシステムテスト（受入テスト）に、基本設計は結合テストに、詳細設計は単体テストにそれぞれ対応しており、設計工程で決めた仕様をテスト工程で検証する構造になっています。
IPAデータ集2022の新規開発データでは、結合テストの工数比率の中央値が約20%、総合テストが約13%となっており、テスト工程全体でも相当な工数が必要です。
発注側にとってはUATが直接関わる工程であり、ここでの確認漏れが運用後の障害につながるため、現場の担当者を巻き込んだ十分なテスト時間を確保することが求められます。
リリース・移行
リリース工程は、テストで合格したシステムを本番環境に展開し、実際の業務運用を開始する工程です。
既存システムからの移行が伴う場合は、旧データの移行作業や移行後の整合性確認も必要になります。
移行方式には、旧システムを止めて一斉に切り替える方法と、一定期間は旧システムと新システムを並行稼働させてから完全移行する方法があります。
リスクが高い大規模システムでは並行稼働方式が選ばれることが多く、それだけ期間もコストも増加します。
発注側はリリース日程と移行方式を事前に決め、社内周知と業務調整を進めておく必要があります。
運用・保守
リリース後は安定した稼働を維持するための運用・保守フェーズに移行します。
運用とは日常的なシステムの監視・バックアップ・アカウント管理などを指し、保守とはバグ修正・法改正への対応・機能追加などを指します。
注意すべき点として、運用・保守にかかるコストは初期開発費とは別に毎年継続的に発生します。
予算計画に保守費用を含めていないと、翌年度の予算承認で想定外の出費となり、経営層と現場担当者の間で認識のズレが生じる原因になります。
契約前にベンダーから保守体制とコスト感を確認しておくことを強くお勧めします。
工程で使われる代表的な略語
システム開発の現場では各工程を英語の略称で呼ぶことが多く、ベンダーとのやり取りで頻繁に出てきます。主要な略語を以下に整理します。
SP（システム企画）は、開発着手前のシステム化計画立案フェーズを指します。
SA（要求分析・System Analysis）は要件定義の前段階で現状分析を行う工程、RD（要件定義・Requirements Definition）は機能・非機能要件を文書化する工程です。
BD（基本設計・Basic Design）が外部設計、DD（詳細設計・Detail Design）が内部設計にそれぞれ対応します。
テスト工程の略語は前述のUT（単体テスト）・IT（結合テスト）・ST（システムテスト）・OT/UAT（運用テスト・受入テスト）が代表的です。
ベンダーから「IT完了後にSTを実施します」などの報告があった場合、これらの意味を押さえておくとスムーズにコミュニケーションが取れます。
工程別の工数比率と期間の目安
IPAの「ソフトウェア開発分析データ集2022」をもとにした新規開発の工程別工数比率（中央値）は、製造（製作）31%・結合テスト20%・詳細設計18%・総合テスト13%の順に高くなっています。
また、同機構の「ソフトウェア開発データ白書2018-2019」では要件定義が全工数の約10%を占めるとされています。
これらの数値から分かるのは、テスト工程全体（結合テスト＋総合テスト＋運用テスト）で全工数の3分の1以上を占めるという事実です。
テストは「作った後にサクッと確認する」という軽い作業ではなく、品質を担保するための主要な工程です。
見積もり段階でテスト工数を軽視すると、後から工数不足が発覚してスケジュール遅延や品質低下につながります。
開発期間の目安は規模によって大きく異なります。
小規模システム（機能が限定的な社内ツールや単機能のWebアプリなど）は1〜3ヶ月、中規模システム（業務管理システムや顧客管理システムなど）は3〜6ヶ月、大規模システム（基幹系や複数システムの統合など）は6ヶ月以上が一般的な目安です。
中規模の場合の工程別の期間配分としては、要件定義1〜2ヶ月、設計・実装2〜4ヶ月、テスト1〜2ヶ月が参考値となります。
スケジュールを見積もる際には、テスト工程での不具合修正や運用テストでの仕様変更対応のための余裕時間を必ず組み込むことが重要です。
開発手法による工程の違い（ウォーターフォールとアジャイル）
システム開発の代表的な手法として、ウォーターフォールとアジャイルがあります。
手法によって工程の進め方が異なるため、発注前に違いを理解しておくことが重要です。
ウォーターフォール型の特徴
ウォーターフォールとは、要件定義から運用保守まで各工程を順番に一方向へ進める開発手法です。
前工程が完了してから次工程に進み、基本的に前工程に戻ることを前提としません。
メリットは、各工程の成果物と進捗が明確に管理できるため、スケジュールと予算の予測精度が高い点です。
要件が確定している大規模プロジェクトや、官公庁・金融機関などコンプライアンス上の文書管理が重要な案件に適しています。
一方、要件が途中で変化しやすいプロジェクトでは、前工程への大きな手戻りが発生するリスクがあります。
アジャイル型の特徴
アジャイルとは、機能単位で「設計→開発→テスト→リリース」の小さなサイクルを繰り返す開発手法です。
各サイクル（スプリント）は1〜4週間程度の短期間で設定され、リリースごとにユーザーのフィードバックを得ながら機能を追加・改善していきます。
メリットは、変化する要件への対応力の高さと、早期に動く機能を確認できる点です。
一方で、プロジェクト全体のスコープと費用が流動的になりやすく、発注側も継続的に開発に関与する必要があります。
スタートアップや新規サービス開発など、市場の反応を見ながら方向性を調整していきたい案件に向いています。
中小企業が手法を選ぶ際の判断基準
手法の選び方に正解はありませんが、中小企業が発注する場合の判断基準として、「要件が明確かどうか」が最初の分岐点になります。
現行の業務フローをシステム化する場合や、法的要件への対応が目的の場合は、要件が比較的固まっているためウォーターフォールが適しています。
一方、新しい業務モデルを実験的に試したい場合や、ユーザーの反応を見ながら機能を調整したい場合はアジャイルが有効です。
また、発注側のリソースも考慮が必要です。
アジャイルは開発チームとの頻繁なコミュニケーションが不可欠なため、自社側にも担当者の時間的コミットメントが求められます。
発注側が各工程で果たすべき役割
システム開発を外部に依頼する場合でも、発注側が完全に任せきりにすることは開発失敗のリスクを高めます。各工程で発注側が担うべき主な役割を整理します。
要件定義フェーズでは、自社の業務課題を整理し、「何を解決したいのか」を文書化して開発会社に伝えることが最重要です。
社内で決裁権を持つ責任者と現場の担当者を決め、要件定義の場に参加することが求められます。
設計フェーズでは、開発会社から提出された設計書に目を通し、業務の実態と合致しているかを確認します。
専門的な技術用語が並ぶ設計書であっても、画面構成や操作の流れなど発注側が判断できる部分は確認し、不明点は質問することが重要です。
テストフェーズ（特にUAT）では、実際にシステムを操作して業務が回るかどうかを発注側が主体的に確認します。
「動く」だけでなく「使える」かどうかを見るのがこの工程の目的であり、現場の実務担当者が参加することで認識のズレを早期に発見できます。
リリース後の運用フェーズでは、障害発生時の連絡体制・対応SLAをあらかじめ取り決め、保守体制を確立しておくことが安定稼働の前提となります。
工程ごとに発生しやすい失敗パターンと対策
日経コンピュータの「ITプロジェクト実態調査2018」では、システム開発プロジェクトの成功率は52.8%であることが示されています。
つまり残りの約半数では、スケジュール遅延・コスト超過・品質問題のいずれかが発生していることになります。
失敗の多くはいくつかの典型的なパターンに集約されます。
要件定義での失敗は「終わらない・漏れる・膨らむ」の3パターンが代表的です。
「終わらない」は発注側の意思決定が遅く要件が固まらないケース、「漏れる」は現場の業務フローを十分にヒアリングしないまま要件定義書を作成するケース、「膨らむ」は開発開始後に追加要件が次々と出てくるケースです。
対策は、要件定義を始める前に「この段階で何を決めるのか」のスコープを明確にし、社内の決裁フローをあらかじめ整理しておくことです。
設計工程での典型的な失敗は、設計書を確認せずに次工程に進んでしまうことです。
「専門的で分からない」と発注側が確認を怠った結果、製造工程の終盤や完成後に仕様の齟齬が発覚し、大幅な手戻りが生じるケースがあります。
分からない点は遠慮せずに質問し、業務の観点から確認できる箇所は必ずチェックすることが重要です。
テスト工程では、テスト期間の不足と担当者のリソース確保が課題になりやすいです。
システムテストの結果として多数の不具合が検出された場合、修正と再テストのサイクルが繰り返され、当初の期間では収まらなくなります。
テスト計画を工程の初期段階から立案し、UAT担当者の時間を事前に確保しておくことが重要です。
リリース後の失敗パターンとして多いのは、保守体制を契約前に確認していなかったことによるトラブルです。
障害発生時の対応時間や連絡先、追加開発の単価感をリリース前に取り決めていないと、問題が起きた際の対応が後手に回ります。
まとめ
システム開発の工程は、要件定義・基本設計・詳細設計・製造・テスト・リリース・運用保守の7段階で構成されます。
工程を正しく理解することは、発注側にとってベンダーとの認識合わせやプロジェクト全体のマネジメントに直接つながります。
特に上流工程の要件定義は、プロジェクト失敗原因の約半数を占める最重要工程です。
自社の業務課題を整理し、開発会社に正確に伝える準備を整えることが、システム開発成功の第一歩となります。
また、IPAの統計データが示すように、テスト工程には全工数の3割以上が費やされており、スケジュールや予算の見積もりでは軽視できない工程です。
開発手法はウォーターフォールとアジャイルの特徴を理解した上で、自社の要件の明確さと内部リソースに合わせて選択することが重要です。
発注側が各工程で適切に関与し、ベンダーとの対話を継続することで、想定通りのシステムをスムーズにリリースできる可能性が高まります。
システム開発の工程や進め方について疑問がある場合、または自社に合った開発方針の検討が必要な場合は、Dimebizにお気軽にご相談ください。
