システム開発の流れを工程別に整理する、PM/PMOが押さえるべき視点

システム開発は、要件定義から保守運用まで複数の工程を経て進みます。本記事では各工程の役割と、ウォーターフォール型・アジャイル型による流れの違いを整理したうえで、PM/PMOとして独立コンサルタントが工程ごとにどう関わるかという参画目線の視点を加えて解説します。開発工程の全体像を体系的に押さえ直したい方の一助になれば幸いです。

システム開発の流れを工程別に整理する(要件定義〜保守運用)

システム開発の流れは、要件定義・基本設計・詳細設計・実装・テスト・保守運用という工程を順に経て進みます。

これらの工程区分は、IPA(独立行政法人情報処理推進機構)がソフトウェアのライフサイクル全体を通じて必要な作業項目・役割を包括的に規定した「共通フレーム2013」が土台になっています。共通フレームでは、構想から開発、運用、保守に至るまでの流れが体系立てて整理されており、多くの開発現場で工程の呼び方や区切り方の共通言語として参照されています。

現場では、要件定義(RD)・基本設計(SA)・詳細設計(DD)・実装(PG)・テスト(UT/IT/ST)・保守運用という略称もあわせて使われますが、呼び方は企業やプロジェクトによって多少異なります。重要なのは名称そのものより、どの工程で何を確定させ、次の工程に何を引き渡すかという役割分担です。

上流工程(要件定義・基本設計)の役割

上流工程では、発注者の要求を要件として言語化し、システム全体の設計方針を固めます。

要件定義は、業務上の課題や要望を「システムに何をさせるか」という要求として整理する工程です。ここで固めた要件は以降のすべての工程の前提になるため、後工程で覆すほど手戻りの影響が大きくなります。基本設計(外部設計)では、要件定義で固めた要求をもとに、画面・帳票・外部インターフェースといった、利用者から見える部分の仕様を決めます。

上流工程は、システムの方向性そのものを左右する意思決定が集中する工程です。技術的な実装方法よりも、業務要件を漏れなく引き出し、優先順位をつける力が問われます。

下流工程(詳細設計・実装・テスト)の役割

下流工程は、上流で固めた設計を詳細な仕様に落とし込み、プログラムとして実装・検証する工程です。

詳細設計(内部設計)は、基本設計の内容をプログラムとして組み立てられる粒度まで分解する工程です。実装(プログラミング)では、詳細設計に基づいてコードを書き、単体テスト(UT)で個々のプログラムの動作を確認します。その後、結合テスト(IT)で機能同士の連携を、総合テスト(ST)でシステム全体が要件定義どおりに動くかを検証します。

下流工程は、上流で決めた仕様を正確に作り込み、品質を担保する工程です。仕様どおりに動くかという検証の精度が、システムの信頼性を直接左右します。

開発手法によって変わるシステム開発の流れの違い

同じ工程区分でも、開発手法がウォーターフォール型かアジャイル型かで流れの組み立て方は大きく変わります。

ウォーターフォール型の流れ

ウォーターフォール型は、要件定義から保守運用までの各工程を、後戻りしない前提で直線的に進める進め方です。

前の工程が完了し関係者の承認を得てから次の工程に着手するため、途中の工程で仕様が変わることを想定していません。要件や仕様を最初にすべて確定できる、大規模で関係者が多いシステムや、官公庁・金融機関のように仕様変更の手続きが重い案件で採用されやすい進め方です。工程ごとの成果物と承認のタイミングが明確なため進捗管理はしやすい一方、後工程で判明した課題を前工程に戻して直す調整コストは大きくなります。

アジャイル型の流れ

アジャイル型は、要件を分割し短い期間(スプリント)で設計・実装・テストを繰り返しながら進める流れです。

IPA・経済産業省が公表している「情報システム・モデル取引・契約書(アジャイル開発版)」でも、アジャイル開発はそのプロセスの中で機能の追加・変更や優先順位の変更、先行リリース部分の改善などに柔軟に対応できる手法と整理されています。1つのスプリントの中で小さな単位の設計・実装・テストを一通り終え、動くものを都度確認しながら次のスプリントの優先順位を見直していきます。要求が変化しやすいWebサービスや、利用者の反応を見ながら機能を磨き込みたいプロダクトで選ばれやすい進め方です。

システム開発の流れの中でPM/PMOが担う役割

PM/PMOは、各工程の節目でスコープ・品質・進捗を管理し、開発チームと発注者の橋渡し役を担います。

各工程でのプロジェクトマネジメントの重点

上流工程では要件の合意形成、下流工程では品質と進捗の可視化が、それぞれの重点になります。

上流工程のPM/PMOは、発注者側の複数部署の要望を整理し、優先順位や実現可否についての合意を形成する役割が中心です。下流工程に入ると、テスト工程の進捗・不具合の件数や傾向・スケジュールへの影響を可視化し、開発チームと発注者の双方に状況を説明する役割の比重が増していきます。

こうした役割の違いは、独立コンサルタントの単価水準にも表れています。上流工程にあたる戦略策定・要件定義は月150万円台から200万円程度になりやすい一方、運用・保守寄りの下流工程は月50万円台から60万円台まで下がるケースがあるとされ、担う役割の重さによって水準が変わる傾向があります。PMOの月額単価で見ても、サポート中心の役割は60〜90万円程度、マネジメント寄りは90〜130万円程度、戦略・リード級は130〜200万円以上とされ、どの工程でどの役割を担うかによってレンジが大きく異なります。

独立コンサルタントとして参画する際の関わり方

独立コンサルタントがPM/PMOとして参画する際は、どの工程から関わるかで求められる役割と評価軸が変わります。

要件定義や基本設計といった上流フェーズから参画する場合は、業務要件を引き出す力や複数部署の調整力、優先順位づけの仮説を提示する力が重視されます。一方、詳細設計以降やテスト工程から参画する場合は、決められたスコープの中で進捗と品質をどれだけ正確に可視化できるかが評価の中心になります。

コンサルタントの歩み編集部が独立コンサルタント数名に行った聞き取りでは、上流フェーズからPMO/PMとして参画したケースのほうが、下流フェーズのみからの参画に比べて提案の裁量が広いと感じる声が多く聞かれました。どの工程から参画するかは、案件の探し方だけでなく、参画後にどこまで裁量を持てるかにも関わってくる論点だといえます。フリーランスPMの単価相場を工程・役割別に整理した記事もあわせて参考にしてみてください。

システム開発の流れでつまずきやすいポイントとその対処

つまずきの多くは、要件定義段階の認識齟齬とテスト工程での仕様変更対応に集中します。

要件定義フェーズでの認識齟齬

要件定義フェーズでは、発注者と開発チームの間で言葉の定義や優先順位の認識がずれやすくなります。

発注者は業務用語で要望を語り、開発チームはシステム用語で仕様に落とし込むため、同じ単語でも指している範囲が微妙に異なることがあります。例えば「承認」という言葉ひとつでも、誰の承認を指すか、どの段階の承認かが部署によって違う場合があります。要件定義書のフォーマットと記載粒度をあらかじめ揃えておくと、こうした認識のずれを後工程に持ち越しにくくなります。

テスト工程での仕様変更対応

テスト工程での仕様変更は手戻りの影響が大きいため、変更の受け入れ基準をあらかじめ決めておくことが重要です。

テスト工程で「やはりこの画面はこう動いてほしい」といった要望が出てくることは珍しくありません。ここで場当たり的に対応を決めてしまうと、他の機能への影響範囲を見落としたまま実装を変更し、新たな不具合を生むリスクが高まります。変更要求が出た際は、影響範囲の分析と優先度の判断を経てから着手するという変更管理の手順を、プロジェクトの早い段階で関係者と合意しておくことが有効です。

開発の流れを可視化するためのドキュメント・ツール

開発の流れを可視化するには、WBSやガントチャートで工程とタスクの関係を整理することが有効です。

WBS・ガントチャートの活用

WBSは作業を工程ごとに分解し、ガントチャートはその作業を時系列で示す使い分けが基本です。

WBS(作業分解構成)は、システム開発全体を工程・機能単位のタスクに分解し、担当と工数を割り当てる書類です。以下は、架空のシステム開発案件を題材にしたWBSの記載例です。

このようにWBSでタスクと先行関係を整理したうえで、ガントチャートに落とし込むと、どのタスクがどの期間に重なり、どこが全体の期日に影響するかが視覚的にわかるようになります。WBSの作り方・作成手順をより詳しく知りたい場合は、そちらの記事も参考になります。ガントチャートの作成のポイントと活用法もあわせて確認しておくと、工程表への落とし込みがスムーズになります。

進捗管理・品質管理の指標

進捗管理では消化率や遅延日数、品質管理ではテスト密度やバグ収束率といった指標がよく使われます。

進捗管理では、計画に対する消化率やタスクの遅延日数を週次で確認し、遅延が出ている工程を早期に特定します。品質管理では、テストの実施件数に対する不具合の検出割合や、テスト終盤にかけて不具合の検出件数が落ち着いていくバグ収束の傾向を確認し、テストが十分に行われているかを判断する材料にします。数値そのものより、前工程・前フェーズとの比較で傾向を見ることが実務では重視されます。

システム開発の流れを理解した上でのキャリア・案件の広がり

開発工程への理解は、PM/PMO案件で提案の質と単価の両面に影響します。

PM/PMO案件で問われる開発工程理解

PM/PMO案件の選考では、工程ごとのリスクと成果物を具体的に語れるかどうかが評価されます。

面談では「どの工程で何を管理していたか」を具体的に問われる場面が多く、抽象的な「進捗管理をしていました」という説明よりも、要件定義で何を確定させ、テスト工程でどのような基準で品質を判断していたかを語れることが評価につながります。資格の面では、PMP(Project Management Professional)が知名度・案件要件への通りやすさの両面で第一候補になりやすいとされていますが、単価を決める主な要素は資格の有無よりも実務経験です。

開発の流れを踏まえた提案力の高め方

提案力を高めるには、各工程で起こりうる問題を具体例とともに説明できることが重要です。

発注者に提案する際、「要件定義フェーズでこういう認識齟齬が起こりやすいので、この形式で合意を取ります」といった具体的な対処法を提示できると、単なる進行管理役ではなく工程を先読みできるPM/PMOとして評価されやすくなります。開発手法や工程の呼び方はプロジェクトごとに異なることも多いため、案件ごとに使われている用語を早い段階で確認し、共通言語をすり合わせる姿勢も評価される要素の1つです。

出典・参考情報

1. IPA(独立行政法人情報処理推進機構)「共通フレーム2013」(2026-09-10参照)
2. IPA・経済産業省「情報システム・モデル取引・契約書(アジャイル開発版)」(2026-09-10参照)

本記事は2026年9月時点の情報に基づいています。