システム開発工程の基礎知識【コンサル・PMO向け2026年版】

システム開発工程とは、要件定義から本番稼働までのシステム開発案件を、内容の異なる複数の段階に区切って進める標準的な区分のことです。PMOやコンサルタントとして開発案件に関わる際、各工程で何を確認し、何を管理すべきかを押さえていなければ、進捗報告や課題管理の精度は上がりません。

本記事では、ウォーターフォールモデルとV字モデルの基本構造、各工程のアウトプット、PMOが工程ごとに担う管理業務、アジャイルとの使い分け、そしてフリーランスPMOとして工程理解を武器にする方法までを、実務目線で解説します。

システム開発工程とは——全体像を押さえる

システム開発工程とは、要件定義から運用開始までのシステム開発プロジェクトを、内容の異なる複数の段階に区切って管理するための区分です。

工程の呼び方や区切り方は開発モデル・企業・プロジェクトによって多少異なりますが、多くの現場では「要件定義」「基本設計(外部設計)」「詳細設計(内部設計)」「開発(製造)」「テスト(結合・総合・受入)」という区分が広く使われています。ウォーターフォールモデルとV字モデルは、この工程区分を理解するための代表的な2つの整理の仕方です。以下、それぞれの基本構造を見ていきます。

ウォーターフォールモデルの基本工程

ウォーターフォールモデルとは、要件定義から運用まで各工程を完了させてから次の工程に進み、原則として後戻りしない前提で計画を立てる開発モデルです。工程名は滝の水が上流から下流へ一方向に流れ落ちる様子になぞらえて名づけられており、契約・予算・体制を工程単位で確定しやすいという特徴があります。

経済産業省の「情報システム・モデル取引・契約書」では、要件定義作成支援業務・外部設計書作成(支援)業務・ソフトウェア開発業務・ソフトウェア運用準備移行支援業務という4段階に分割した契約モデルが示されており(出典：IPA『共通フレーム2013』)、実務でもこの区分に沿って契約や体制が組まれることが一般的です。基本的な工程の並びは次のとおりです。

• 要件定義：発注者側の業務要件を整理する工程
• 基本設計(外部設計)：要件を画面・帳票などの仕様に翻訳する工程
• 詳細設計(内部設計)：仕様をプログラムの内部構造に落とし込む工程
• 開発(製造)：設計書に基づき実装する工程
• 結合テスト・総合テスト・受入テスト：段階的に品質を確認する工程
• 運用移行：本番環境への移行と運用体制への引き継ぎ

工程の名称や区切り方は、企業やプロジェクトによって多少異なる場合があります。同じ内容を指していても「基本設計」と「外部設計」、「内部設計」と「詳細設計」のように呼び方が揺れることが多いため、案件に入る際は最初にその現場での呼称を確認しておくと認識のずれを防げます。

V字モデルで理解する開発と検証の対応関係

V字モデルとは、要件定義から詳細設計までの開発工程と、単体テストから運用テストまでの検証工程を、内容が対応するもの同士で結び付けて示した図式です。IPAの資料では、品質保証の観点から見たモデルとして30年以上にわたり広く利用されてきたモデルと位置づけられています(出典：IPA『ソフトウェアテスト見積りガイドブック』第1部総論 p.7 図2.1)。

この対応関係を理解しておくと、「詳細設計で決めたモジュール分割の妥当性は結合テストで検証される」というように、設計時点でテスト観点を先取りして考えられるようになります。テスト工程の呼び方は「結合テスト」と「統合テスト」、「総合テスト」と「システムテスト」のように現場ごとに異なる略称が使われることが多いため、本記事では実務で広く使われる名称を併記しています。

各工程の内容とアウトプット

システム開発の各工程には、それぞれ確認すべき固有のアウトプット(成果物)があり、PMOはその成果物を通じて進捗と品質を把握します。工程の名前を知っているだけでは管理はできず、各工程で「何が出来上がっていれば次に進んでよいか」を成果物レベルで判断できることが実務では重要です。

要件定義・基本設計（外部設計）

要件定義は「何を実現したいか」を業務側の言葉で整理する工程で、基本設計(外部設計)はその要件を画面・帳票・外部インターフェースといった目に見える仕様に翻訳する工程です。

たとえば受注管理システムの刷新案件であれば、要件定義書には「取引先ごとに与信枠を設定し、超過時に警告を出したい」という業務要件が記載されます。これを受けて基本設計書では、その要件を「受注登録画面に与信超過フラグを表示し、登録ボタンを一時的に無効化する」という画面仕様に翻訳します。要件定義のアウトプットは要件定義書や業務フロー図が中心で、基本設計のアウトプットは画面レイアウト・帳票レイアウト・外部インターフェース仕様書などが中心になります。

詳細設計（内部設計）・開発（製造）

詳細設計(内部設計)は基本設計の仕様をプログラムの内部構造に落とし込む工程で、開発(製造)はその設計書に基づき実際にコードを書く工程です。共通フレーム2013では「ソフトウェア構築」とはいわゆるプログラミングのことを指すと定義されており(出典：IPA『共通フレーム2013』2.4.5.1項)、製造工程が指す作業範囲は業界内で概ね共通しています。

先ほどの与信チェックの例で言えば、詳細設計書には「与信チェック処理をCheckCreditLimitという関数として実装し、与信テーブルのcredit_limitカラムと突合する」といった、プログラマー向けの具体的な記述が入ります。開発(製造)工程では、この設計書どおりに実装されているかがコードレビューの基準になります。

結合テスト・総合テスト・受入テスト

結合テストは詳細設計に対応するモジュール間の連携確認、総合テストは基本設計に対応するシステム全体の機能・非機能確認、受入テストは要件定義に対応する発注者側の最終確認です。

結合テストでは、画面から入力されたデータが正しくデータベースへ反映されるか、外部システムとのインターフェースが仕様どおりに疎通するかといった、モジュールをまたぐ連携部分を確認します。総合テストでは機能面に加えて、応答時間やアクセス集中時の挙動といった非機能要件も含めてシステム全体を検証します。受入テストでは、実際の業務運用の流れに沿って発注者側がマニュアルどおりに操作できるかを確認し、ここで問題なければ運用移行に進みます。

PMOが各工程で担う管理業務

PMOは各工程で進捗管理・課題管理・レビュー設計を担い、前工程から後工程への情報の受け渡しが正しく行われているかを管理します。開発チームがつくる成果物そのものを作成する立場ではないため、成果物の中身を評価する視点と、工程をまたいだ整合性を見る視点の両方が求められます。

工程ごとの進捗管理・課題管理のポイント

進捗管理は工程ごとに見るべき指標が異なり、同じ「進捗率」という言葉でも工程によって中身が変わります。要件定義工程ではスコープの確定率や未決事項の件数、設計工程では設計書のレビュー完了率や指摘事項の解消率、テスト工程ではテストケースの消化件数や不具合検出件数・解消件数が主な指標になります。

工程を横断して発生する論点(仕様の解釈違い、他システムとの調整事項など)は、放置すると気づいた時には手戻りの規模が大きくなっているため、発生した時点で記録し、対応状況を可視化しておくことが欠かせません。課題の記録・優先度づけ・対応状況の可視化を仕組み化する方法は、課題管理表の作り方で具体的に解説しています。

工程間の『手戻り』を防ぐレビュー設計

手戻りの多くは、前工程での仕様の解釈違いがそのまま後工程に持ち込まれ、後になって発覚することで発生します。これを防ぐには、工程の切れ目ごとに関係者レビューのゲートを設け、次工程に進んでよいかを判断する場を明確に設計しておくことが有効です。

たとえば基本設計から詳細設計に進む前のレビューでは、発注者側の業務担当者にも同席してもらい、画面仕様が業務要件を正しく反映しているかを確認します。詳細設計から開発に進む前のレビューでは、逆に業務担当者よりも技術面のレビュアーを重視し、モジュール分割やデータベース設計の妥当性を確認します。工程ごとにレビューの参加者と観点を変えることで、同じレビューを形だけ繰り返す状態を避けられます。

ウォーターフォールとアジャイルの違いと使い分け

ウォーターフォールは工程を順番に完了させていく計画重視の進め方で、アジャイルは短い期間で開発とレビューを繰り返しながら要件を段階的に固めていく進め方です。どちらか一方が常に優れているわけではなく、案件の特性に応じて選ぶべきモデルが変わります。

アジャイル（スクラム）の工程・イベントの基礎

アジャイル開発の代表的な手法であるスクラムは、スプリントと呼ばれる短い期間を繰り返しながら、動くソフトウェアを段階的に完成させていく進め方です。IPAの資料では、1つのスプリントの中身は「スプリントプランニング」「デイリースクラム」「開発作業」「スプリントレビュー」「スプリントレトロスペクティブ」という一連の流れで構成されると説明されています(出典：IPA『アジャイル開発の進め方』2024年5月版 p.5)。

役割(ロール)は「プロダクトオーナー」「開発者」「スクラムマスター」の3種類に整理されます。プロダクトオーナーは何を開発するかの優先順位づけに責任を持ち、開発者は実際の開発作業に携わり、スクラムマスターはチームが自律的に協働できるよう支援する役割を担います(出典：同資料 p.12〜13)。ウォーターフォールにおけるPMOのような専任の進行管理役を置かず、チーム全体で自律的に進める点が大きな違いです。

プロジェクト特性に応じたモデル選定の判断軸

モデル選定の判断軸は、要件の確定度・契約形態・リリース頻度への要求という3点に整理できます。要件がすでに固まっており、請負契約で成果物の範囲を明確にしたい案件はウォーターフォールに向き、逆に要件そのものが利用者の反応を見ながら変わっていくプロダクト開発や、短いサイクルでのリリースが求められる案件はアジャイルに向きます。

IPAの調査によれば、アジャイルの原則とアプローチの取入状況は、日本は「全面的に取り入れている」がすべての部門で1割以下にとどまり、最も進んでいるIT部門でも「一部取り入れている」との合計で5割弱にとどまる一方、米国は各部門とも7割前後、ドイツも各部門とも6〜7割程度と、日本は米独に比べて大きく遅れています(出典：IPA『DX動向2025』p.24〜25 図表1-31)。国内の受託開発案件では準委任・請負を問わずウォーターフォールが引き続き選ばれる場面が多いため、PMOとしては両モデルの基礎を押さえたうえで、案件ごとに向き不向きを判断できることが求められます。

開発工程の理解がPMO・コンサルに必要な理由

開発工程の理解は、開発者・ベンダーと対等に会話するための共通言語であり、要件定義やスケジュール調整の精度を左右する実務スキルです。PMOやコンサルタントは自らコードを書くわけではありませんが、工程の中身を理解していなければ、進捗報告の裏側にある実態を読み取れません。

開発者・ベンダーとの対等な会話に必要な共通言語

工程の内容を理解していると、開発者やベンダーの説明を翻訳を介さずに理解でき、議論の解像度が上がります。「詳細設計がまだ終わっていない」という報告を受けたとき、それが単なる作業の遅れなのか、基本設計段階での仕様の曖昧さに起因するものなのかを見極められるかどうかで、PMOとして打てる手は大きく変わります。工程の内容を知らないままだと、ベンダー側の説明をそのまま受け取るしかなく、リスクの所在を自分で判断できません。

工程知識が要件定義・スケジュール調整に活きる場面

工程知識は、要件定義の段階でスケジュールの妥当性を見積もる場面で特に活きます。たとえば要件定義がずれ込んだ案件で、後続の設計・開発・テストの期間を機械的に圧縮しようとする計画を目にすることがありますが、各工程のアウトプットと工数の関係を理解していれば、「詳細設計を圧縮すればテスト工程で不具合が増える可能性が高い」といった、工程間のトレードオフを踏まえた指摘ができます。

フリーランスPMOとして工程理解を武器にする方法

フリーランスPMOにとって、工程理解の深さは案件面談での説得材料になり、単価水準にも関わってきます。同じ「PMO経験あり」でも、担当した工程の幅と、その工程で実際に何を管理していたかを具体的に語れるかどうかで、面談での評価は大きく変わります。

案件面談で工程理解をアピールするポイント

面談では、担当した工程の名称を並べるだけでなく、その工程で発生した具体的な課題と自分の対応を語ることがアピールになります。「要件定義から総合テストまで一通り経験しました」という説明よりも、「基本設計から詳細設計への引き継ぎで仕様の解釈違いが多発した案件で、レビューの参加者と観点を工程ごとに整理し直した」というような、工程間の橋渡しの経験を具体的に語る方が、採用側には実務能力として伝わります。

コンサルタントの歩み編集部が独立系PMO案件のヒアリングを行ったところ、工程ごとの管理ポイントを具体的に説明できた候補者ほど、初回契約の稼働条件交渉で好条件を引き出せている傾向が見られました。単価の面でも、同じ職種であっても上流(戦略策定・要件定義)は下流(運用・保守)より高単価になりやすいという傾向があり、IT戦略領域が150〜200万円である一方、運用・保守寄りの案件は下限50〜60万円台まで下がる例があります(出典：ドメイン知識ベース「上流工程と下流工程の単価差」)。工程をまたいで説明できることは、上流工程の案件を狙う際の材料にもなります。

工程を跨いだリスク管理ができる人材の希少性

特定の工程だけでなく、工程を跨いだリスクの連鎖を把握できる人材は、フリーランスPMOの中でも希少です。要件定義の甘さが詳細設計での手戻りを生み、それがテスト工程での不具合増加につながる、というように、リスクは工程をまたいで連鎖することが少なくありません。1つの工程の経験しかない人材は目の前の工程しか見えませんが、複数工程を横断した経験があると、上流の判断が下流にどう波及するかを見通せます。

PMOフリーランスの月額単価は80〜150万円が標準で平均は120万円程度、上限は250万円級とされ、役割別では戦略・リード級になると130〜200万円以上のレンジになります(出典：ドメイン知識ベース「PMOフリーランスの月額単価相場と役割別レンジ」)。工程を跨いだリスク管理ができるという専門性は、こうしたレンジの上位に位置づけられる役割で特に求められる能力です。案件獲得の具体的な進め方は、PMOフリーランスの案件獲得方法で詳しく解説しています。

システム開発工程理解でよくあるつまずき

システム開発工程の理解でつまずきやすいのは、用語・略語の混同と、工程の形式だけを覚えて実態を掴めていない状態の2つです。いずれも、実務経験が浅い段階のPMOやコンサルタントに共通して見られます。

用語・略語（RFP・RFI・UT/IT/STなど）の混同

RFP・RFIやUT/IT/STといった略語は、意味と使われる場面が異なるため、区別して覚えておく必要があります。RFI(情報提供依頼書)は発注前に開発会社の実績や技術情報を集めるための依頼書で、RFP(提案依頼書)はその後、具体的な要件や予算・スケジュールを示して提案を求める依頼書です。一般にRFIで候補を絞り込んだうえでRFPを送るという順序で使われます。UT(単体テスト)・IT(結合テスト)・ST(総合テスト)は、テスト工程の略称です。単体テストはプログラム単位、結合テストはモジュール間の連携、総合テストはシステム全体というように、それぞれ開発工程の異なる粒度に対応しています。これらの略語は企業によって使われ方に幅があるため、案件に入った際は初回の打ち合わせで用語の定義を揃えておくことをおすすめします。

工程の形式だけ知っていて実態を掴めていないケース

工程名とその順番を暗記しているだけで、各工程で実際に何が起きているかを掴めていないと、進捗報告を額面どおりに受け取ってしまうリスクがあります。「詳細設計が完了した」という報告があっても、レビューでどの程度の指摘が出て、それがどこまで解消されているかを確認しなければ、実態として次工程に進められる状態かどうかは判断できません。工程の名称と成果物の対応関係だけでなく、その工程で典型的に発生する論点(要件定義であれば業務部門間の要求の対立、詳細設計であれば非機能要件の考慮漏れなど)まで理解しておくことが、報告の裏側を読むために必要です。

出典・参考情報

1. IPA「共通フレーム2013」第3部 共通フレームとガイダンス（2026年8月参照）
2. IPA「ソフトウェアテスト見積りガイドブック」（SEC BOOKS）（2026年8月参照）
3. IPA「アジャイル領域へのスキル変革の指針 アジャイル開発の進め方」（2024年5月版）（2026年8月参照）
4. IPA「DX動向2025 日米独比較で探る成果創出の方向性」（2026年8月参照）

本記事の内容は2026年8月時点の情報に基づきます。工程名称・略語の定義や範囲は企業・プロジェクトにより異なる場合があるため、実際の案件では現場での呼称を確認してください。