システム開発の工程を図付きで解説｜流れ・略語・費用比率も掲載

システム開発は、「要件定義が重要」「途中でトラブルが起きやすい」と言われる一方で、どの工程で、発注者が何を意識すべきかまで具体的に理解できているケースは多くありません。

システム開発の失敗の多くは、設計や開発そのものではなく、要件定義や設計段階での認識ズレ、関与不足によって引き起こされています。

本記事では、システム開発の全体工程（企画・構想〜要件定義、設計、開発、テスト、運用）を整理したうえで、各工程で発注者が注意すべきポイントや、よくある失敗とその対策をわかりやすく解説します。

「これからシステム開発を検討している方」
「過去にプロジェクトがうまくいかなかった経験がある方」
にとって、失敗を防ぐための実践的な指針となる内容です。

システム開発の工程｜各工程ごとの役割解説

システム開発は、上流工程と下流工程に分かれています。上流工程は主に発注者側と開発者側がすり合わせを実施しながら設計する段階で、下流工程は開発者側が主軸となり実装に向けたテストを進めていく段階です。

工程	内容
企画・構想	開発前に行う
要件定義	打ち合わせと要件定義書の作成
基本設計（外部設計）	UIの設計
詳細設計（内部設計）	プログラムの設計
プログラミング	実際にシステムを開発する
単体テスト	正しい動作かを確認する
結合テスト	プログラム同士を連携させてテストする
システムテスト	全体の総合的なテストをおこなう
運用テスト	実環境に近い状況でテストをおこなう
システム移行・リリース	システムを公開し、必要に応じて移行作業をおこなう
運用・保守	安定稼働させるために対応していく

それぞれの工程ごとに、何のために何をしていくのかを見ていきましょう。

①企画・構想フェーズ（開発前に行うこと）

企画・構想フェーズは、システム開発に着手する前段階で、「なぜシステムを作るのか」「何を解決したいのか」を明確にする工程です。このフェーズが曖昧なまま進むと、要件定義以降で方向性がぶれ、開発途中の手戻りや追加コストが発生しやすくなります。

発注者側で整理しておくべき主なポイントは以下の通りです。

• 背景・課題の整理：現在の業務で発生している問題点や非効率な部分を洗い出し、「システム化によって何を改善したいのか」を明確にします。
• 目的・ゴールの設定：業務効率化、コスト削減、売上向上など、システム導入によって達成したい目的を定義します。
• 対象業務・利用者の整理：どの業務を対象とし、誰がシステムを利用するのかを整理することで、後工程での要件ブレを防ぎます。
• 概算スケジュール・予算感の検討：実現したい時期や想定予算を大まかに決めておくことで、現実的な開発計画を立てやすくなります。
• 体制・役割：企画・構想フェーズを進めていく体制と、各メンバーの役割を決めます（意思決定者や窓口を明確にすることが重要です）

この段階では、仕様を細かく決める必要はありませんが、課題・目的・優先順位を関係者間で言語化・共有しておくことが重要です。企画・構想フェーズを丁寧に行うことで、要件定義以降の工程がスムーズになり、結果として開発全体の成功確率を高めることができます。

⇒システム開発を伴う事業計画書の書き方ガイド（無料DL）

②要件定義：打ち合わせと要件定義書の作成

システム開発を外注する場合、企画・構想でどのようなシステムを開発するのか固まったら、次は開発会社との打ち合わせをします。クライアントと契約書を取り交わした後、もしくは契約締結を前提として要件定義工程に入ります。

ここでは、打ち合わせでの注意点と、要件定義で決めるべきことをご紹介します。

打ち合わせ

本工程ではクライアントと開発会社間で打ち合わせを行い、双方のディスカッションの中で得られた情報を基に要件定義書と呼ばれるドキュメントを作成します。

要件定義が明確でない場合、開発を進める際に盛り込むべき内容が曖昧になってしまいます。また、「言った・言っていない」といった水掛け論も、プロジェクトでは非常に発生しやすくなります。開発会社側はクライアントの要望をしっかりと確認し、作り上げるシステムの概要を決めていく必要があります。

なお、打ち合わせの際に伝える要望はできるだけ現場目線の声をベースに進めていくべきです。現場の代表者や責任者が打ち合わせに参加せず、現場では使われないシステムをリクエストするケースがあります。このような状況はシステム開発の手間がかかるだけではなく、結果的に使われない可能性があるため、現場の責任者を交えるか、現場の声を把握したうえで打ち合わせに望みましょう。

要件定義書の作成

要件定義書とは、システム開発において、ユーザーが求める機能、性能、業務ルールなどを具体的にまとめた設計図となる書類です。 

要件定義書は以下の4つをおさえる必要があります。要件定義書の構成はプロジェクトによって異なりますが、一般的には以下の観点で整理されます。

機能名	特徴	具体例
機能要件	システムが実現すべき具体的な機能	・顧客の問い合わせを自動で分類し、担当部署に振り分ける ・ユーザーがマイページでお気に入りの商品を登録できる
非機能要件	システムの応答時間やデータ処理能力などの性能	・ウェブページの表示速度は3秒以内 ・月間アクセス数が100万件を超えても安定して稼働
品質要件	システムの品質を確保するための基準（セキュリティや可用性など）	・システムの年間ダウンタイムは24時間以内とする ・ユーザー認証は二段階認証を導入する
実行計画	システム開発に必要な工数やコスト、スケジュールを具体的に定める	・開発期間は6か月 ・各フェーズのマイルストーンを設定する

なお、要件定義工程についてより詳しい情報を知りたい方は、以下のURLをご確認いただけたらと思います。

関連記事：システム開発の要件定義とは？欠かせない要素と進め方を解説

要求定義と要件定義の違い

要求定義とは、システム開発などで「顧客がシステムに何を求めているか（目的、課題、期待する成果）」を明確にし、開発側に伝えるためのもので「要求定義書」としてまとめられます。要求定義でどうありたいかを決め、要件定義でどうやればそれを実現できるかを具体的に深ぼります。以下が具体例です。

• 要求定義：ユーザーインターフェースを重視し、初見でも使えるようにしてほしい
• 要件定義：左にメインメニューを置き、目的の画面まで2クリックで遷移する仕様とする

③基本設計（外部設計）

ここでは基本設計（外部設計）について解説します。

要件定義が完了した後、「基本設計」「外部設計」「インターフェース設計」などと呼ばれる工程に移ります。また、基本設計の工程では、開発期間や費用についてクライアント側と話し合います。

UI設計

要件定義で決めた内容をもとに、ハードウェアの設計やシステムの操作画面のレイアウトなど、搭載すべきものやシステムの特徴をより具体的に決定していきます。ここでユーザーインターフェース（UI）を設計するため、ユーザー側の視点に立って使い勝手のいいシステムになるよう検討することが重要です。見栄えの良さだけではなく、効率よく動き、操作性が高く、アクセスしやすいシステムになるように設計を進めます。

成果物の作成

要件定義で合意した内容をもとに、システムの仕様を具体化するための成果物を作成します。

これらの成果物は、開発会社だけでなく、発注者にとっても「認識が合っているか」「要件が正しく反映されているか」を確認する重要な判断材料となります。

基本設計では、基本設計書やシステム構成図、インターフェース設計書、外部設計書、方式設計書、テーブル定義書、ファイル定義書が成果物です。

成果物名	特徴
業務フロー図	どのような業務で利用するのか、業務の流れとシステムの関係性を記したもの
システム構成図	システム全体の構成を図で表したもの
画面一覧	システムの必要画面を一覧としてまとめたもの
実行計画	システム開発に必要な工数やコスト、スケジュールを具体的に定める
インターフェース図	要件定義やシステム構成図でまとめた資料をもとにどの情報をどのシステムに連携するかを決定したもの
帳票一覧	帳票を出力するにあたって必要な項目、レイアウトを示したもの ※帳票がないシステムでは不要
コード一覧	システム内で扱うデータ（区分や属性など）を識別するために割り当てる「符号（コード）」のルールや具体的な値を整理・定義したもの
CRUD図	データベースのテーブルに対して、各機能がどの操作（作成・参照・更新・削除）を行うかを整理したもの
バッチ一覧	通常業務とは別に、定期的・自動的に実行される処理の一覧
データベース設計書	業務プロセスなどをもとに保存するデータを一覧化したテーブル定義書やデータベースの関係性をまとめた設計図
非機能要件一覧	可用性、性能/拡張性、運用/保守性、セキュリティなどをまとめた要件一覧

なお、上記成果物についてのより詳細な解説は、以下の記事に掲載しています。

関連記事：基本設計における成果物とは？ 開発工程の流れや注意点を含めて解説

④詳細設計（内部設計）

「詳細設計」「内部設計」と呼ばれるのが、システムの中身である機能や動作の設計をおこなう工程です。

プログラムの設計

開発言語やAPIとの連携、サーバー・データベース、プログラミングのルールの策定など、主に技術的な要素を設計していきます。この工程で作成するのは、単体テスト仕様書や詳細設計書などです。

基本設計では人の目に見える部分を設計し、詳細設計は人の目に触れないものを動かすために必要な部分を設計します。詳細設計を行うことで、基本設計で設計した内容をシステムに正しく反映できるようになるのです。

成果物の作成

基本設計の成果物同様、詳細設計の成果物も「認識が合っているか」「要件が正しく反映されているか」を確認する重要な判断材料です。

成果物名	特徴
状態遷移図	システムの状態が遷移する様子を図に書いて図形や矢印などで表現したもの
シーケンス図	アクティブ図よりもシステムの内部処理に着目して、より詳細に表記したもの
画面遷移図	WEBアプリケーションやその他業務システムの開発において、どのように画面遷移が行われるかを表した図 ※基本設計段階で作成することもある
クラス図	プログラミングをする際の元データとなる、システムを構成するクラス関係を表すもの
アクティブ図	ユーザー操作とシステム処理の流れがわかるもの
モジュール構造図	構成するモジュールがどのように分割されて、各モジュールがどのような処理を行うのかを示した図
入出力設計書	各機能でどのような情報がインプットとして用いられ、どのような情報がアウトプットとして出てくるかを表したもの
バッチ処理設計書	定期的な処理や大量データの一括処理を行うプログラムの仕様を詳細に定義したもの
テスト設計書	単体テストや結合テストでベースとなるテストの指針や骨格を定めたもの
データベース物理設計書	論理設計で決めたデータ構造をデータベース管理システムに合わせて、具現化したもの
外部インターフェース設計図	社内外の他システムと連携するときの仕様を定義したもの
IPO（処理機能記述書）	システムの機能・ビジネスロジックの処理内容を入力（Input）、処理（Process）、出力（Output）の３形式で表現した図式

なお、上記成果物についてのより詳細な解説は、以下の記事に掲載しています。

関連記事：詳細設計の成果物は何が重視される？ 進め方や注意点を紹介

発注者は、すべての成果物を技術的な視点で理解する必要はありませんが、「要件定義で決めた内容が反映されているか」「業務上の使い勝手に問題がないか」といった観点で確認することが重要です。

設計工程での認識ズレを早期に発見できれば、開発フェーズ以降の手戻りや追加コストを大きく抑えることができます。

⑤プログラミング：実際にシステムを開発

プログラミングの工程では、実際にシステムを開発していきます。これは、コーディングや開発とも呼ばれる工程です。内部設計の際にプログラミングの型をある程度開発しますが、この工程では実際に作り上げていくフェーズです。

この工程ではプログラミング言語を用いますが、使用する言語の種類によって特徴が異なってきます。プログラミングの際はシステムごとに必要となるプログラミング言語が異なるため、さまざまな言語を使い分けながら進めていくことがあります。

関連記事：プログラミング言語の一覧・種類と特徴を徹底解説！

⑥単体テスト：正しい動作の確認

単体テストは、プログラムが正しく動作するかをチェックする工程です。詳細設計の際に作成しておいた単体テスト仕様書をもとに、動作確認をおこないます。

テストにはいくつか種類があり、はじめにおこなうテストは、個々のプログラムが要件定義で定めた内容どおりに動くかどうかのチェックです。もしも正常に反応しなかった場合には、どのように反応したのかを確認し、問題があった部分を修正します。

⑦結合テスト：プログラム同士の連携のテスト

結合テストは、プログラム同士を連携させて、正常に反応するかどうかをテストする工程です。単体ではうまくいっても、複数のプログラムが組み合わさると干渉によって正常に作動しないケースがあります。

たとえばデータの受け渡しをしてみるなどで、プログラム同士で連携がとれ、基本設計書で定めた機能が再現できているかどうかを検証するのです。

⑧システムテスト：全体の総合的なテスト

システムテストでは、全体の総合的なテストをおこないます。この工程でのテストとは、すべてのプログラムを合わせた状態で正常に作動するのかどうかをチェックしているものです。

システムテストでおこなうのは、動作確認だけではありません。アクセスへの耐久性や処理速度など、実際にユーザーが利用する際に問題がないかを確認していきます。

⑨受入テスト（UAT）・運用テスト

運用テストの工程で実施するのは、実際にシステムを利用する環境に近いものを用意し、そのなかで正常に反応してくれるかどうかという、実用性を重視したテストです。システム移行やリリース前の最終テストとなるため、ありとあらゆる状況を検証していきます。

テストできる環境を早めに整備しておけるように、外部設計が終わったあたりの段階から準備を進めていくといいでしょう。

⑩システム移行・リリース：新システムを公開

先述の各テストで徹底的に検証し、現場での運用に問題がない状態だと判断できれば、システム移行やリリースをおこないます。市場にリリース（公開）するときは、システムのすべての機能が一度に公開されるわけではなく、クライアント側のビジネス戦略に応じて順次リリースされていくという流れです。

開発したものが社内システムなどで、もしも既存のシステムを使っている場合には、旧システムから新システムへの移行作業をおこないます。この場合にも、一気に切り替えていく一斉移行の方法と、少しずつ切り替えていく順次移行の方法から選択可能です。

⑪運用・保守：安定稼働させるための対応

システムを実際に使い始めたら、安定稼働させるために運用・保守の工程として対応していきます。その後もしもバグがあれば正常に動くようにする、アップデートを実施したりなどの対応をとっていくのです。これによって、システムを使い続けられるようにしていけます。

ここまでシステム開発の工程全体を見てきましたが、AIエージェント時代が到来している現在では、この工程も自動化していくことが今後主流となっていくでしょう。システム開発の、AIによる自動化については以下の資料にて解説しています。
⇒システム開発はAIでどこまで自動化できるのか（無料DL）

システム開発の工程で発注側が注意すべきポイント

ここではシステム開発の工程を進めるうえで、よくある失敗事例と対策をチェックしやすいようリストでまとめています。

要件定義でよくある失敗と対策

要件定義は、システム開発全体の成否を左右する重要な工程ですが、発注者側の関与不足や認識のズレにより、さまざまな失敗が起こりやすい工程でもあります。ここでは、要件定義でよくある失敗と、その対策について解説します。

失敗例	起こる事象	対策
目的やゴールが曖昧なまま要件定義を進める	後の工程での仕様追加や変更が頻発	企画・構想フェーズで整理した課題や目的を要件定義書に明文化し、関係者間で合意を取る
現場の意見が反映されていない	実務に合わず使われないシステムとなる	現場担当者へのヒアリングを行い、業務フローや実際の運用を踏まえた要件整理をする
要望と要件が混在してしまう	「できたら嬉しいこと」と「必ず必要な機能」が整理されず、コストやスケジュールが膨らむ	要求事項に優先順位を付け、必須要件と追加要件を明確に分けて整理する
開発会社に任せきりにしてしまう	認識のズレに気づかないまま設計・開発が進む可能性がある	要件定義書の内容を発注者自身が確認し、業務視点で違和感がないかを必ずチェックする

＞＞【チェックリスト付き】失敗しない要件定義書の書き方ガイド（無料DL）

設計・開発工程でよくある失敗と対策

設計・開発工程では、要件定義で整理した内容をもとに、具体的な仕様・実装へと落とし込んでいきます。このフェーズでは、以下のような問題が起こりやすくなります。

失敗例	起こる事象	対策
設計内容と要件定義の乖離	「作りやすさ」や「技術的都合」を優先した設計となり、発注者の意図とずれてしまう	設計レビューの場で「要件との対応関係」を明示し、なぜこの設計になっているのかを確認する
設計の不備・不足（粒度の過不足）	設計が粗すぎると解釈が分かれ品質にばらつきが生じる。細すぎると変更への対応力が下がり開発スピードが落ちる	プロジェクトの規模や体制に応じて「どこまで設計で固めるか」を事前に合意しておく
仕様変更ルールが曖昧	追加要望や変更を場当たり的に受け入れ、スケジュール遅延やコスト超過につながる	変更管理のルール（影響範囲の確認・承認フロー・費用と納期への反映）を明確にしておく

テスト・運用フェーズでよくある失敗と対策

テスト・運用フェーズは、「作ったシステムが本当に使えるか」を検証し、実運用へとつなげる重要な工程です。このフェーズでも、発注者側で意識すべき注意点があります。

失敗例	起こる事象	対策
テスト観点の不足	実際の業務フローや例外ケースが考慮されず、仕様通りに動くかという観点だけに偏る	実業務を想定したシナリオテストや、現場担当者による受入テストを実施する
運用を見据えていない	操作性・画面遷移・エラーメッセージなどが見過ごされ、運用開始後の負担に直結する	「誰が・どの頻度で・どのように使うのか」という視点で運用時の使いやすさを確認する
運用・保守体制が不明確	障害発生時の連絡先・対応範囲・改修の進め方が曖昧なまま運用を開始し、トラブル時に混乱が生じる	運用開始前に保守契約の範囲・対応時間・役割分担を整理しておく

上流・下流工程の違いと重要性

システム開発は、大きく「上流工程」と「下流工程」に分けられます。上流工程か下流工程かによって、発注者の関与の注力度合いが変わってきます。

区分	主な工程	発注者の関与
上流工程	企画・構想、要件定義、設計	非常に高い（主体的な参加が必要）
下流工程	開発、テスト、運用	受入テストでの確認が中心

上流工程では目的・要件・仕様の方向性を固める

上流工程は、企画・要件定義・基本設計など、システムの目的や要件、仕様の方向性を定める工程です。

上流工程は、プロジェクト全体の方向性を決める非常に重要な工程であり、その出来がプロジェクトの成否を左右すると言っても過言ではありません。発注者が業務課題や目的を十分に整理しないまま開発を進めると、後工程での仕様変更や認識のズレが発生しやすく、追加コストや納期遅延につながるリスクが高まります。

そのため、要件定義や基本設計の段階では、ベンダー任せにせず、発注者自身が意思決定に関与することが重要です。

関連記事：システム開発の上流工程とは？発注者が知っておくべき工程の全体像と関わり方

下流工程では決定した内容を形にする

一方、下流工程は、開発・テスト・リリースといった、決定した内容を実際に形にする工程を指します。下流工程では、設計内容を正確に実装し、品質を確保することが主な役割となります。上流工程で合意形成ができていれば、下流工程はスムーズに進みます。

しかし、テストで想定外の不具合が発見されると、修正と再テストに追われ、納期遅延につながるリスクがあります。

システム開発手法ごとの工程比較

システム開発工程のモデルには複数の種類がありますが、ウォーターフォール開発とアジャイル開発は、システム開発工程の基本となる2モデルです。発注者側は最低でも、基本のウォーターフォール開発とアジャイル開発、そして開発工程に含まれるMVP開発（プロトタイピング開発）の3種類を抑えておきましょう。

開発手法	発注者が把握すべき	システム開発者が把握すべき
ウォーターフォール開発	◯	◯
アジャイル開発	◯	◯
MVP開発（プロトタイピング開発）	◯	◯
V字モデル	△	◯
スパイラル開発	△	◯
XP（ペアプログラミング）	△	◯
DevOps（呼び方：デブ・オプス）	△	◯
ハイブリッド開発	△	◯

それぞれのシステム開発工程モデルの種類について、特徴を解説します。

ウォーターフォール開発

ウォーターフォール開発とは、上流工程から下流工程に向かって、一定の流れで進めていく開発方法を表しています。決められた順に工程を進めていく方法で、1つの工程が完了しないうちには次の工程に入ることはありません。

進捗状況の把握が容易で、高い品質のシステムが作りやすいのがメリットです。ただし、素早いシステム開発は苦手で、仕様変更へ対応する難易度が高いというデメリットもあります。

アジャイル開発

アジャイル開発とは、後戻りすること（仕様変更）を前提としてプロジェクトを進行する開発方法です。ウォーターフォールとは違ってはじめに全体を綿密に設計せず、１つの工程をしっかりと完成させる前に進めていくため、各工程をスピーディに進行させられます。

また、工程の後戻りができるため、途中での仕様変更に対応しやすい開発方法です。ただし、工程の進捗状況の管理が難しいこと、対応できる開発会社が少ないという点がデメリットです。

どちらを選択すべきかは、以下の記事にてより詳細に掲載しています。

関連記事：アジャイル開発とウォーターフォール開発の違いとは？メリット・デメリットを解説！

MVP開発・プロトタイプ開発

プロトタイピング開発手法とは、早い段階で簡易版であるプロトタイプ（試作品）を開発し、クライアントからのフィードバックを確認してから完成させていく開発手法です。

仕様が固まっていない場合や発注に不慣れなクライアント、操作性が重視されるシステムの開発に特に適しています。認識のズレを早期に解消できる点や、技術的な問題を前倒しで発見できる点がメリットです。一方、プロトタイプ制作分のコスト増加や開発者の負担増というデメリットもあります。

関連記事：MVP開発とは？進め方・期間・コストから失敗しない仮説検証まで完全解説
関連記事：PoC・プロトタイプ・MVP開発の違いとは？3つの検証手法の目的・使い分けを徹底解説

V字モデル

V字モデルでは、プログラミングの工程までウォーターフォールと同じく上流から下流へ流れるように進め、テストの段階になってからは、テスト工程と開発工程をリンクさせて、効率的に検証作業を実施する方法です。

単体テストでは内部設計のチェック、結合テストでは外部設計のチェック、システムテストで要件定義の内容の実装をチェックします。このように、折り返して一つひとつ上流にのぼりながら工程を確認していくため、V字モデルといわれています。

テストする内容を明確にできるため作業進捗がわかりやすく、テスト工程で手戻りのリスクを軽減できるという点がメリットです。

スパイラル開発

スパイラル開発とは、機能ごとに開発工程を繰り返す手法です。同じく機能単位で進めるアジャイル開発と混同されやすいですが、リリースタイミングに大きな違いがあります。アジャイルは機能が完成するたびに順次リリースしますが、スパイラルは各機能をプロトタイプとして開発・レビューしながら改善を重ね、全機能が揃ってから一括リリースします。

そのため、スパイラル開発は品質を重視したい案件に向いていますが、コストが高くなりやすく、より計画的に進めやすいアジャイル開発のほうが普及しています。

DevOps

DevOpsとは、Development（開発チーム）とOperations（運用チーム）が連携しあう開発手法です。連携してシステム開発することによって、余分な工数を削減して素早く柔軟にかつ高い品質で対応できる仕組みを作れます。

情報共有の促進や、それぞれのチームが尊重しあえる組織文化を構築すること、テスト効率化のためのツール活用などが、DevOpsの重要なポイントです。

アジャイル開発の場合、開発チームが改善と修正を繰り返す動きと、運用チームのシステムを安定稼働させたい思いが反発しあいますが、DevOpsではそれがなくなります。

関連記事：DevOps / デブオプスとは何か？アジャイル開発との違いをわかりやすく解説

ハイブリッド開発

ハイブリッド開発とは、ウォーターフォール開発とアジャイル開発など、複数の開発手法を組み合わせたものです。

例えば、開発の進め方として、ハードウェア開発や外部連携はウォーターフォールで進め、ユーザーインターフェースなどソフトウェアの部分はアジャイルで進めるケースがあります。こうすることで、ウォーターフォール開発の長所である「計画性」とアジャイル開発の長所である「柔軟性」を両立させることが可能です。

一方で、二つの異なる手法を並行して管理することから、管理コストの増大、手法間でのギャップが生じやすいデメリットが挙げられます。

システム開発の工程別の工数比率

工程の理解を深めるために、システム開発工数全体に対してそれぞれの工程がどれほどの工数比率であるのかをチェックしていきましょう。日本情報システム・ユーザー協会（JUAS）が発表した「ソフトウェアメトリックス調査２０２５」によると、２０１８～２０２０年に集めたデータでの実績工数比率は、以下のとおりです。

実績工数比率

• 要件定義：２０％未満
• 設計から統合テスト（外部設計、内部設計、プログラミング、単体テスト、結合テスト、システムテスト）：６０％以上９０％未満
• 運用テスト：２０％未満

望ましいと感じている工数比率

実績データに対して、望ましいと感じている工数比率として集めたデータは、以下のとおりでした。

• 要件定義：４０％未満
• 設計から統合テスト：３０％以上８０％未満
• 運用テスト：２０％以上３０％未満

システム開発する際に、今よりも設計から統合テストの割合をおさえて、要件定義や運用テストの時間をとったほうがいいと感じる人が多いという結果です。しかし、実際には設計から統合テストの段階で工数が多くなっているのが実態なのです。

参照：ソフトウェアメトリックス調査２０２５

システム開発の工程で使う略語一覧

依頼する側にとっては専門用語を理解しやすいように、受注する開発会社側にとってはクライアントに話を説明しやすいように、以下の使用頻度の高い略語の意味を確認しておきましょう。

要件定義では、クライアントと開発会社がそれぞれの話を理解して、しっかりとコミュニケーションをとることが重要です。

• SP……企画
• SA……要求分析・システム方式設計要求分析
• RD-UI……要件定義（RDのみで要件定義を意図することもある）
• UI……基本設計
• BD……基本設計
• SS……構造設計
• FD……機能設計
• DD……詳細設計
• PD……詳細設計・プログラム設計
• PS……詳細設計
• M……製造
• UT……単体テスト
• CD……コーディング
• PG……プログラミング
• IT……結合テスト
• ST……システムテスト
• PT……総合テスト
• OTO……運用テスト

また本記事では代表的な用語を取り上げていますが、より詳細な情報を知りたい方はIPA（独立行政法人情報処理推進機構）が公表するガイドライン等を一読すると学びが多いはずです。

参考：IPAの詳細はこちら

まとめ：システム開発を成功させるために発注者が意識すべきこと

システム開発を外注する際は、開発会社の技術力だけでなく、発注者側の関わり方がプロジェクトの成否を大きく左右します。

特に、企画・構想から要件定義、設計・開発、テスト・運用に至るまで、各工程での判断や確認を怠ると、後工程での手戻りやコスト増加につながりやすくなります。

重要なのは、「何を作るか」だけでなく、「なぜ作るのか」「誰のために使うのか」を一貫して共有し続けることです。

企画・構想フェーズでは、課題や目的を言語化し、関係者間で認識を揃えること。
要件定義では、要望と要件を整理し、優先順位を明確にすること。
設計・開発工程では、要件とのズレがないかを確認し、変更ルールを明確にすること。

そして、テスト・運用フェーズでは、実業務を想定した検証と、運用・保守体制の整理が欠かせません。

これらを意識して進めることで、「作ったが使われないシステム」ではなく、現場で本当に活用され、事業や業務に貢献するシステムを実現しやすくなります。

システム開発は一度きりの作業ではなく、導入後も改善を続けていく取り組みです。発注者自身が各工程のポイントを理解し、開発会社と適切にコミュニケーションを取ることが、開発成功への近道と言えるでしょう。

⇒システム開発を伴う事業計画書の書き方ガイド（無料DL）

システム開発なら企画・構想から一貫してGeNEEにお任せ

本記事で解説したシステム開発の工程について、把握しきれていない場合でも、GeNEEなら企画・構想から一貫してシステム開発をお任せいただけます。「まずは相談から」という方でも問題ございませんので、下記フォームよりお気軽にお問い合わせください。

• 

  GeNEEの開発実績

  製造業、小売業、流通業、印刷・出版業など、業界別のベストプラクティスを保持しています。
  弊社の開発実績にご関心のある方はこちら

  一部公開可能な事例を掲載中

• 

  GeNEEの事業内容

  現在、6事業を展開しております。お客様の状況や目標に合わせて、FITするソリューションを提供いたします

  6事業の詳細はこちら

• 

  弊社主催セミナー

  最大月に1回のセミナーを開催しております。毎回30名以上の方にご出席いただいております。
  テック系のセミナーにご興味ある方はこちら

  月に1回テック系セミナー開催中

• 

  オウンドメディア

  GeNEE は技術に関する情報発信を積極的に行っています。 弊社のお客様だけでなく、業界全体に貢献のできる品質の高い情報提供を心掛けています。

  最先端テクノロジーの情報配信中

• 

  GeNEEの会社概要

  ビジネスxテクノロジーxデザインの三位一体で、お客様の課題を解決する独自のアプローチをご紹介

  創業から15年の実績

• 

  GeNEEの5つの特徴

  なぜGeNEEはコンサルティングやシステム開発のプロジェクト成功率が高いのか。
  競合他社との違いや優位性についてまとめております。

  GeNEEの5つの特徴

• 

  GeNEEへのお問い合わせ

  DX/ITコンサルティングのご依頼やシステム開発・スマホアプリ開発のご相談はこちらのフォームからお願いいたします

  お問い合わせフォームはこちら

• 

  GeNEEの資料をダウンロード

  ご希望の会社様にGeNEEのパンフレットをお送りしております。
  ITベンダーとの繋がりをお探しの方は是非お気軽にリクエストください。

  資料ダウンロードはこちら