システム開発とは何か？開発工程と進め方の基本を解説

システム開発とは、業務課題を解決するシステムを要件定義から保守まで一貫して構築する取り組みです。本記事では代表的な開発工程とウォーターフォール・アジャイルという進め方の違いを整理したうえで、発注者側に立つコンサルタントが工程ごとに担うべきチェック機能まで実務目線で解説します。読み終える頃には、開発ベンダーとの打ち合わせで使える共通言語が身につきます。

システム開発とは—定義と対象範囲を整理する

システム開発とは、要件定義から保守まで、システムを構築し維持する一連の活動全体を指します。

システム開発は、企業や組織が抱える業務課題をITで解決するために、要件の整理から設計・実装・テスト・リリース後の保守までを行う一連の活動です。情報処理推進機構(IPA)が公開する「共通フレーム2013」では、対象範囲を企画・要件定義・開発・運用・保守・廃棄までのライフサイクル全体と定義しており、ソフトウェアの実装作業だけを指す言葉ではありません(出典:IPA「共通フレーム2013」)。この対象範囲を「開発イコールプログラミング」と狭く捉えると、要件定義や保守フェーズでの関与を見落としかねません。

「開発」と「運用」の境界線

開発はシステムを新たに構築する工程を指し、運用は稼働後に維持・改善する工程を指します。

「開発」は要件定義から本番リリースまでの構築工程を指し、「運用」はリリース後のシステムを安定的に稼働させ、必要に応じて機能追加や不具合対応を行う工程を指します。共通フレーム2013でも開発プロセスと運用プロセス・保守プロセスは別の工程として区分されており、契約する相手や担当ベンダーが開発時と運用時で分かれるケースも珍しくありません(出典:IPA「共通フレーム2013」)。プロジェクト単位で参画するコンサルタントは、自分が関与しているのが開発フェーズなのか運用フェーズなのかを最初に確認すると、役割認識のズレを防げます。

コンサルタントが関わる場面の全体像

コンサルタントは要件定義・進捗管理・品質確認など複数の工程にまたがって関与します。

発注者側のコンサルタントは、開発の初期段階では要件定義の整理役として、中盤ではPMOやPMとして進捗とリスクの可視化を担い、終盤では受入テストや検収判定への関与を求められることが多くなります。IPAの「情報システム・モデル取引・契約書」では、ユーザ企業とITベンダの双方が各局面の役割を共通理解のもとで対話することの重要性が示されており、コンサルタントはこの対話を仲介・整理する立場になりやすいといえます(出典:IPA「情報システム・モデル取引・契約書(第二版)」)。関わるフェーズによって求められる視点が変わる点を押さえておくことが重要です。

システム開発の代表的な工程(要件定義〜保守)

代表的な工程は要件定義・設計・製造・テスト・リリース・保守という順序で進みます。

共通フレーム2013に沿って整理すると、システム開発は企画・要件定義・システム設計(基本設計・詳細設計)・製造(プログラミング)・テスト・リリース・運用/保守という工程で進みます(出典:IPA「共通フレーム2013」)。工程ごとに主な成果物と発注者側の関与ポイントが異なるため、次の表に整理しました。

要件定義・基本設計・詳細設計の役割分担

要件定義では業務要件を、基本設計では仕様を、詳細設計では実装方法をそれぞれ定めます。

要件定義では「何を実現したいか」という業務要件を整理し、基本設計ではその要件を画面・帳票・機能というシステム仕様に落とし込みます。詳細設計はさらに一段階具体化し、プログラム内部の処理方式やデータ構造といった実装方法を定める工程です。IPAの「情報システム・モデル取引・契約書」でも、ユーザ企業とITベンダが各設計工程で仕様や検収方法について共通理解を持つことが重要とされており、要件定義書と設計書の内容が食い違ったまま次工程に進むと、後工程での手戻りにつながりやすくなります(出典:IPA「情報システム・モデル取引・契約書(第二版)」)。要件定義の段階で業務エンティティ同士の関係を整理しておくと設計工程との橋渡しがしやすくなり、要件定義で使うER図の基礎を押さえておくことも実務では有効です。

テスト工程と受入時の確認ポイント

テストは単体・結合・総合・受入の順に進み、範囲と合格基準の事前合意が欠かせません。

テスト工程は一般的に、プログラム単位で確認する単体テスト、機能間の連携を確認する結合テスト、システム全体を確認する総合テスト、そして発注者側が業務観点で確認する受入テスト(検収)という順に進みます。受入テストでは、要件定義書に記載した業務要件が満たされているかを発注者側の視点で確認する必要があり、テストシナリオと合格基準を事前にベンダーと合意しておくことが欠かせません。合意が曖昧なまま検収に入ると、何をもって完成とするかで見解が割れるリスクがあります。

システム開発の主要な進め方(ウォーターフォールとアジャイル)

システム開発の代表的な進め方は、ウォーターフォールとアジャイルという2つの手法に大別されます。

ウォーターフォール開発は、開発対象全体の要件や仕様を確定してから設計・製造・テストへと順番に進める手法です。一方アジャイル開発は、プロセスの中で機能の追加・変更や優先順位の変更、先行リリース部分の改善などに柔軟に対応できる手法とされています(出典:IPA「情報システム・モデル取引・契約書(アジャイル開発版)」)。どちらか一方が常に優れているわけではなく、プロジェクトの特性に応じて選ばれるものです。

それぞれの向き・不向き

要件が固まった大規模案件はウォーターフォール、変化の多い案件はアジャイル向きです。

業務要件が事前に明確で、関係部署が多く仕様変更の影響範囲が大きい大規模案件は、工程ごとに検収を挟むウォーターフォールと相性が良い傾向があります。一方、市場環境の変化が速く、リリースしながら機能を磨き込みたい新規サービス開発などは、優先順位を柔軟に見直せるアジャイルと相性が良いとされています。IPAのアジャイル開発版モデル契約書でも、アジャイルではプロダクトオーナーの選任や開発チームへの迅速な意思決定が発注者側の役割として求められており、進め方によって発注者に求められる関与の質も変わる点に注意が必要です(出典:IPA「情報システム・モデル取引・契約書(アジャイル開発版)」)。

発注者が誤解しやすいポイント

アジャイルは仕様を決めなくてよい手法だという理解は、実務上は大きな誤解にあたります。

アジャイル開発は「仕様を決めずに開発を進められる手法」と誤解されがちですが、実際には反復のたびに優先順位や受け入れ条件を発注者側が判断する場面が増え、意思決定の頻度自体はむしろ高くなります。IPAのモデル契約書でも、ユーザ企業側にプロダクトの方向性・内容決定への主体的な関与が明記されており、丸投げを前提とした進め方ではありません(出典:IPA「情報システム・モデル取引・契約書(アジャイル開発版)」)。進め方を選ぶ際は、発注者側の意思決定負荷も合わせて確認しておくと安心です。

発注者側コンサルタントが工程ごとに果たすべきチェック機能

コンサルタントは各工程で発注者側の視点から抜け漏れと品質を確認する役割を担います。

コンサルタントの歩み編集部が発注者側コンサルタントへの取材を通じて確認したところ、各工程での関与の質がプロジェクトの成否を左右する場面が多いという声が共通していました(編集部独自調査)。開発ベンダーは契約範囲内の成果物を仕様通りに作ることに責任を持ちますが、業務要件そのものの網羅性や、現場で実際に使えるかどうかの判断は、発注者側の関与なしには担保しにくい領域です。工程ごとに次のようなチェック機能を意識しておくと、トラブルの予防につながります。

要件定義フェーズでの抜け漏れ防止

要件定義では、部署横断で現場の業務フロー全体を漏れなく洗い出せているか確認します。

要件定義フェーズでは、システム化の対象となる業務フローを部署横断で洗い出し、例外処理や繁忙期特有の業務まで拾えているかを確認することが重要です。現場担当者へのヒアリングだけに頼ると、日常的すぎて意識されない手順が要件から抜け落ちることがあります。発注者側コンサルタントは、業務部門と開発ベンダーの間に立ち、要件定義書の記載が実際の業務と一致しているかを両者の言葉で突き合わせる役割を担います。

テスト工程での品質担保への関与

受入テストでは、実際の業務シナリオに沿った確認観点をコンサルタントが設計します。

テスト工程、とくに受入テストの段階では、ベンダーが用意するテスト項目が技術的な動作確認に偏り、実際の業務シナリオに沿った確認観点が不足しているケースがあります。発注者側コンサルタントは、繁忙期の処理件数や例外的な入力パターンなど、実務で起こり得る状況を想定したテストシナリオを追加する形で品質確認に関与できます。IPAのモデル契約書でも検収方法について発注者・ベンダー双方の共通理解を持つことが重視されており、受入基準を事前に言語化しておくことが望ましいとされています(出典:IPA「情報システム・モデル取引・契約書(第二版)」)。

システム開発でよくあるトラブルとその予兆

システム開発におけるスケジュール遅延と仕様変更の多発は、代表的な2つの予兆にあたります。

システム開発におけるトラブルは、ある日突然発生するのではなく、多くの場合は事前に予兆が見られます。とくに「スケジュール遅延」と「仕様変更の多発」は、発注者側でも比較的気づきやすい2つの予兆です。リリース後にはシステム開発後に起こりうる障害対応まで見据えておくと、プロジェクト全体のリスク管理がしやすくなります。

スケジュール遅延の兆候

進捗会議において具体的な成果物の提示が徐々に曖昧になっていく様子は遅延の兆候といえます。

進捗会議で「順調です」という報告が続きながらも、具体的な成果物(設計書のドラフトやテスト結果など)の提示が徐々に曖昧になっていく状態は、遅延の初期兆候として注意が必要です。あわせて、特定の担当者への作業集中や、レビュー指摘の対応に時間がかかり始める様子も、スケジュールが後ろ倒しになりつつあるサインとして捉えられます。発注者側コンサルタントは、進捗率という数値だけでなく、成果物そのものの提示状況を定期的に確認することが有効です。

仕様変更が多発する原因

要件定義段階における合意形成の不足が、後工程での仕様変更が多発する主な原因になります。

仕様変更が繰り返される主な原因は、要件定義の段階で業務部門と開発ベンダーの間の合意形成が不十分なまま、詳細設計や製造工程に進んでしまうことにあります。要件定義書の記述が抽象的なまま次工程に進むと、担当者ごとの解釈の違いが後になって表面化し、都度の仕様変更につながります。IPAの共通フレーム2013でも、要件定義プロセスは開発全体の土台となる工程として位置づけられており、この段階での合意形成の丁寧さが、後工程での手戻りの少なさに直結すると考えられます(出典:IPA「共通フレーム2013」)。

システム開発に関わる主要な職種と役割分担

主な職種はプロジェクトマネージャー・PMO・システムエンジニアの3つに大別できます。

システム開発には、プロジェクト全体の意思決定を担うプロジェクトマネージャー(PM)、PMの意思決定を支える事務局機能としてのPMO(プロジェクトマネジメントオフィス)、そして設計・実装を担うシステムエンジニア(SE)など、複数の職種が関わります。役割の境界はプロジェクトによって幅がありますが、大まかな整理を押さえておくと、体制図を見たときに誰が何を担っているかを理解しやすくなります。

PM・PMO・SEの違い

PMは意思決定を、PMOは進捗管理の支援を、SEは設計・実装をそれぞれ担います。

PMはスケジュール・予算・品質に関する最終的な意思決定と責任を担う役割です。PMOはPMの意思決定を支えるため、進捗や課題の可視化、会議体の運営、資料の整備といった事務局機能を担います。SEはシステムの設計や実装を担う技術専門職で、要件を技術仕様に落とし込む役割を持ちます。プロジェクトマネジメントの知識体系としては、PMI(Project Management Institute)が策定するPMBOKが国際的に広く参照されており、PM/PMO人材が学習・資格取得の対象を選ぶ際にも、知名度の高さからPMP資格が第一候補に挙がりやすいとされています(出典:PMI日本支部・ドメイン知識ベース)。発注者側コンサルタントとして参画する場合は、自分がPM相当の意思決定者として振る舞うのか、PMOとして支援に回るのかを最初にすり合わせておくことが、工程ごとのチェック機能を発揮するうえでも重要です。システム開発を要件定義から保守までの一連の活動として捉え、工程ごとに発注者側が果たすべき役割を理解しておくことが、開発ベンダーとの共通言語を持つための土台になります。

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

出典・参考情報

1. 情報処理推進機構(IPA)「共通フレーム2013」（2026-09-08参照）
2. 情報処理推進機構(IPA)「情報システム・モデル取引・契約書(第二版)」（2026-09-08参照）
3. 情報処理推進機構(IPA)「情報システム・モデル取引・契約書(アジャイル開発版)」（2026-09-08参照）
4. PMI日本支部 公式サイト（2026-09-08参照）

本記事は2026年9月時点の情報に基づいています。制度・記法・契約書の詳細な内容は変更される場合があるため、最新情報は各公式サイトでご確認ください。最終更新日:2026年9月8日