システム開発工程とは？10ステップの流れと巻き取り範囲、発注前に押さえるポイント【2026年最新】

はじめに

システム開発の「巻き取り」とは、外部に任せていた作業や他社が手がけていたシステムを、自社や別の開発会社が引き取って担うことを指す場合が多いです。巻き取りを判断する前に、工程ごとに自社で担う範囲と外注する範囲を整理しておくことが大切です。引き継ぐ際は、設計書、ソースコード、各種アカウント、データの所在と権利を確認します。移行やリリース後の運用まで含めて役割と契約内容を決めておくと、引き継ぎ時の認識のずれを抑えられます。

「システム開発を外部に発注したいが、工程の全体像が分からないまま見積もりを受け取ってしまった」——そんな不安を抱えていませんか。システム開発には要件定義から保守まで多くの工程があり、それぞれで発注者が確認すべきことが変わります。工程を理解しないまま任せきりにすると、「思っていたものと違う」「追加費用が膨らんだ」といった失敗につながりかねません。

この記事は、初めてシステム開発を発注する非IT系の担当者に向けて、システム開発工程の流れを「発注者目線」で整理したものです。10のステップと上流・下流の区分、移行・引き継ぎで自社が巻き取る範囲、開発手法による進み方の違い、現場で飛び交う略語、工程ごとの工数（コスト）、そして工程と契約形態の関係までを、一気に把握できる構成にしました。専門用語をできるだけかみ砕き、各工程で「発注者として何を確認すればよいか」をひとつずつ添えています。読み終えたとき、見積書や工程表に並ぶ言葉の意味が分かり、「どこを開発会社に任せ、どこを自社で担うか」を判断できる状態になることを目指します。

システム開発工程とは？全体の流れと「上流・下流」の区分

システム開発工程とは、要件定義から設計・実装・テストを経てリリースし、その後の運用・保守まで含めた一連の作業のまとまりを指します。これらは大きく「上流工程」と「下流工程」に分けられます。上流は何を作るかを決める段階、下流は実際に作って動かす段階です。発注者にとって特に重要なのは上流で、ここでの認識ずれが後工程すべてに波及します。

区分	含まれる工程	主な担い手	発注者の関与度
上流工程	要件定義・基本設計	発注者＋開発会社	高い（仕様を決める）
下流工程	詳細設計・実装・各種テスト	開発会社	中〜低（確認が中心）
運用・保守	リリース後の改修・障害対応	開発会社	中（要望を出す）

「工程」「流れ」「開発プロセス」はほぼ同じ意味で使われます。呼び方の違いに惑わされず、全体像をひとつのつながりとして捉えることが第一歩です。

恋活アプリの作成を例に、企画・機能設計から公開後の運用までを具体的に確認できます。

システム開発の10工程を「発注者目線」で解説

代表的なシステム開発は、次の10ステップで進みます。各工程の技術的な詳細よりも、発注者が「ここで何を確認すべきか」を押さえてください。

プロジェクト計画：目的・予算・スケジュール・体制を決めます。ゴールが曖昧なまま進めないことが最重要です。
要件定義：必要な機能を文章で確定します。最も認識ずれが起きやすく、発注者の言語化が試される工程です。
基本設計：画面や機能など、利用者から見える部分を設計します。発注者が内容を理解できる形かを確認します。
詳細設計：内部の処理やデータ構造を設計します。ここは開発会社に委ねて問題ありません。
実装（プログラミング）：設計をもとにコードを書きます。進捗の報告頻度を取り決めておきます。
単体テスト：機能を最小単位で検証します。
結合テスト：複数機能を組み合わせて連携を検証します。
システムテスト：全体が要件どおり動くかを総合的に確認します。
運用テスト（受入テスト）：発注者自身が実環境に近い形で確認する、合否を分ける工程です。
リリース・保守：公開して終わりではなく、改修と障害対応が続きます。

上流工程の進め方は受発注の成否を大きく左右します。要件定義・基本設計の詳しい進め方は「システム開発の上流工程」、品質を左右するテストの考え方は「システム開発のテスト工程」の記事で個別に解説します。要件定義の具体的な進め方は「動くもの」から始める要件定義の考え方もあわせてご覧ください。

工程ごとの役割と作業の流れを確認する際は、【図解あり】システム開発ワークフロー完全ガイド｜工程ごとの役割と注意点を徹底解説をご覧ください。

移行・引き継ぎ工程と、自社で巻き取る範囲の決め方

10工程のうち、発注者が見落としやすいのがリリース前後の移行と、その後の運用・保守の引き継ぎです。工程表では「リリース」の一行にまとめられがちですが、ここで役割があいまいだと、公開後にだれも対応できない作業が残ります。システム開発の巻き取りを考えるときは、工程ごとに「自社で担う作業」と「外注に任せる作業」を分けて整理することから始めます。

工程	自社で巻き取りやすい作業	外注に任せる作業	契約・成果物で確認すること
プロジェクト計画	目的・予算・体制の決定	計画書の作成支援	体制と役割分担の合意
要件定義	業務フローと要望の整理	要件の文書化と実現性の確認	要件定義書の範囲と承認者
基本設計	画面・機能のレビュー	画面・機能の設計	基本設計書の確認方法
詳細設計・実装	進捗と課題の確認	内部設計とプログラミング	ソースコードの引き渡しと権利
結合・システムテスト	テスト結果の確認	テストの計画と実施	テスト結果報告の提出
運用テスト（受入）	実業務に沿った操作確認	不具合の修正	検収の基準と期限
移行・リリース	移行データの確認と社内周知	データ移行と本番切り替え	移行手順書と切り替えの判断者
保守	問い合わせ受付と軽微な設定変更	障害対応と改修	保守契約の範囲と対応時間帯

リリース前のデータ移行と本番切り替えの役割分担

旧システムやExcelから新システムへデータを移す作業は、変換や取り込みの作業を開発会社が、移したデータが正しいかの確認を発注者が担う、と分けて考えると整理しやすくなります。どのデータを移すか、移行後の件数や内容をだれが確認するか、本番切り替えの可否をだれが判断するかを、移行手順書として事前に決めておきます。切り替え後に問題が見つかった場合に旧環境へ戻す手順も、あわせて確認しておくと安心です。

運用・保守を社内で巻き取るための準備

リリース後の運用を社内で巻き取る場合は、次の3つを先にそろえます。

運用手順書：日常の操作、定期作業、よくある問い合わせへの対応方法をまとめたもの
管理者権限：サーバー、ドメイン、外部サービス、管理画面のアカウントと権限
問い合わせ窓口：利用者からの問い合わせと障害時の連絡先、開発会社への連絡経路

社内で担う範囲を広げるほど、手順書と権限の整備が欠かせません。どこまでを社内で対応し、どこからを保守契約で開発会社に任せるかを、移行前に開発会社と決めておきましょう。

他社が開発したシステムを引き継ぐときに確認する資産

開発途中の案件や他社が開発したシステムを巻き取る場合は、次の資産の所在と権利を確かめる現状調査から始めます。

設計書：要件定義書・設計書と、仕様変更の履歴
ソースコード：最新版の保管場所と、利用・改変できる権利
各種アカウント：サーバー・ドメイン・外部サービス・開発ツールの管理者権限
データ：保存場所、バックアップ、個人情報の取り扱い

資料がそろっているか、前の開発会社の協力が得られるかによって、引き継げる範囲や進め方は変わります。引き継ぎの可否は、現状調査の結果を見て個別に判断します。

知っておきたいシステム開発工程の略語一覧

打ち合わせや見積書では、工程が略語で書かれることが少なくありません。意味が分からないまま頷いてしまうと認識ずれの原因になります。最低限おさえたい略語をまとめました。

略語	正式名称	工程
RD	Requirement Definition	要件定義
BD	Basic Design	基本設計
DD	Detail Design	詳細設計
PG	Programming	実装
UT	Unit Test	単体テスト
IT	Integration Test	結合テスト
ST	System Test	システムテスト
OT	Operation Test	運用テスト

スケジュールを略語と日程で示した「工程表（ガントチャート）」を提示されることもあります。工程表の読み方と作り方は、別記事「システム開発の工程表」で具体的に解説します。

開発手法で工程の進み方は変わる（ウォーターフォール／アジャイル）

同じ10工程でも、進め方の手法によってスケジュールやリスクが変わります。発注前に、自社の案件にどちらが合うかを擦り合わせておくと安心です。

比較軸	ウォーターフォール	アジャイル
進め方	工程を順番に一気通貫	機能単位で設計〜テストを反復
仕様変更	後からの変更が苦手	変更に強い
向く案件	仕様が固まった大規模開発	要件が動く新規事業・小規模
発注者の関与	上流に集中	全期間にわたり継続的

仕様が固まりきらない新規システムでは、小さく作って確かめながら進めるアジャイル的な進め方のほうが、手戻りを抑えやすい傾向があります。

工程ごとの工数配分と「手戻り」のコスト

工程理解で見落とされがちなのが、「どの工程にコストが偏るか」という視点です。一般的なウォーターフォール開発では、工数はおおむね次のように分散します。

工程グループ	工数の目安	特徴
要件定義・設計（上流）	約30〜40%	ここの精度が全体を決める
実装	約30%	設計どおりに作る
テスト（下流）	約30〜40%	品質を担保する

注目すべきは、上流での決定ミスが下流で発覚すると、修正コストが何倍にも跳ね上がる点です。要件定義で見落とした仕様をテスト段階で直すと、設計・実装・テストをやり直すことになります。工数が全工程に分散しているからこそ、「どこか一工程だけを効率化」しても全体最適にはなりにくい、という構造的な課題があります。

工程と契約形態（請負・準委任）の関係

工程を理解すると、見積書や契約書で「どの工程を、どの契約で発注しているか」も読めるようになります。システム開発では、工程の性質に合わせて契約の分け方や契約形態を使い分けることがあります。

多段階契約と一括契約の違い

比較軸	多段階契約	一括契約
契約の単位	要件定義・設計・実装などの工程ごと	全工程をまとめて1つ
見積もりの考え方	前の工程の成果をもとに次の工程を見積もる	契約時に全体を見積もる
発注者が確認する場面	工程の区切りごと	主に最終の検収
検討されやすい案件	要件が固まっていない段階から始める案件	要件と範囲が明確な案件

要件定義だけを先に発注し、その成果をもとに設計以降の見積もりと契約を決める進め方は、多段階契約の考え方にもとづくものです。

請負と準委任の違い

比較軸	請負	準委任
約束する内容	成果物の完成	作業の遂行
使われることが多い工程	詳細設計・実装など、作るものが決まった工程	要件定義や保守など、成果物を事前に確定しにくい工程
発注者が決めておくこと	成果物の範囲と検収の基準	作業の範囲と報告の方法

請負は成果物の完成を約束する契約、準委任は作業の遂行を約束する契約です。どちらが常に有利ということはなく、工程の性質と、成果物をどこまで事前に決められるかで選び方が変わります。

検収の基準と仕様変更の手続きを契約前に決める

契約形態にかかわらず、何をもって完了とみなすかという検収の基準と、途中で仕様を変えたいときの手続き（変更の申し出方、影響の見積もり、合意の方法）は、契約前に開発会社とすり合わせておきます。ここが曖昧だと、巻き取りや引き継ぎの場面で「どこまでが前の契約の範囲か」が分からなくなります。契約形態の選び方や契約書の条項は案件ごとに判断が分かれるため、具体的な契約判断は弁護士などの専門家に確認してください。

事例紹介：工程を分断せず一気通貫で開発したケース

ある中小企業の業務システム開発では、当初ウォーターフォール型で要件定義書を固めてから実装する計画でした。しかし要件定義の文章だけでは現場担当者が完成像をイメージできず、運用テストの段階で「実際の業務に合わない」という指摘が続出しました。

そこで、要件定義の段階から実際に動く画面（プロトタイプ）を見せながら仕様を固め、設計・実装・改修を同じチームが一気通貫で担当する進め方に切り替えました。結果として、文章だけで詰めていた頃に比べて手戻りが大幅に減り、リリースまでのリードタイムを短縮できました。工程を細かく分業して引き継ぐほど、引き継ぎロスと認識ずれが積み上がる——これは多くの発注現場で起きている課題です。動くものから始める進め方の詳細はノーコードで実現する業務システム開発の成功法則で紹介しています。

工程理解の落とし穴と、ノーコード開発という選択肢

工程を学ぶと「すべてを自分が管理しなければ」と気負いがちですが、非IT系の担当者が全工程を細かく統制するのは現実的ではありません。むしろ大切なのは、上流（要件定義・受入テスト）に集中し、下流は信頼できる相手に任せる切り分けです。

そのうえで、工程が分断されることによる手戻りそのものを減らす選択肢が、ノーコード開発です。Bubbleのようなノーコードプラットフォームでは、設計・実装・改修の境界がなだらかになり、動く画面を見せながら要件を固められます。工程ごとに人と成果物を引き継ぐ従来型の分業で生じるロスを抑えられるため、仕様が動きやすい中小企業のシステム開発と相性が良い方法です。

💡 ポイント：工程を「全部やる」のではなく、「上流に集中し、分断のロスを減らす作り方を選ぶ」。これが発注を成功させる近道です。費用面の考え方は業務システム開発の費用目安も参考になります。

よくある質問（FAQ）

Q. システム開発の工程はいくつですか？

A. 分け方により6〜10工程とされますが、要件定義・設計・実装・テスト・リリース・保守という大きな流れは共通です。

Q. 発注者はどの工程に一番関わるべきですか？

A. 上流の要件定義と、最後の運用テスト（受入）です。この2つの精度が満足度を大きく左右します。

Q. どこから外部に発注すべきですか？

A. 要件定義の壁打ちから一緒に進められる相手が理想です。発注先選びの考え方は「業務システム開発」を誰に頼むべきかで解説しています。

Q. 他社が開発したシステムを途中から引き継ぐことはできますか？

A. まずは設計書・ソースコード・各種アカウント・データの所在と権利を確かめる現状調査から始めます。資料の状態や前の開発会社の協力の有無によって進め方が変わるため、引き継ぎの可否や範囲は調査の結果をもとに個別に判断します。

Q. 要件定義だけを先に発注することはできますか？

A. 工程ごとに契約を分ける多段階契約の考え方で、要件定義を先に発注する進め方があります。その場合は、要件定義書などの成果物と、何をもって完了とするかの条件を契約時に明確にしておきます。

Q. リリース後の運用を社内で巻き取るには何を準備すればよいですか？

A. 運用手順書、管理者権限とアカウント、問い合わせ・障害時の連絡先、保守契約の範囲を整えます。これらは移行前に開発会社と引き継ぎ内容として決めておくと、リリース後の対応で迷いにくくなります。

まとめ

システム開発工程は、要件定義から保守まで続く一連の流れであり、上流・下流に分けて捉えると全体像がつかめます。10のステップそれぞれで発注者が確認すべきポイントは異なり、特に「何を作るか」を決める要件定義と、「思ったものになっているか」を見極める受入テストは、開発会社に任せきりにできない発注者の責任範囲です。略語や開発手法、工程ごとの工数配分まで把握しておけば、提示された見積もりや進捗報告の内容を自分の言葉で読み解けるようになり、認識ずれによる手戻りや追加費用のリスクを減らせます。

工程を把握したら、移行・リリースと保守まで含めて、どこまでを自社で巻き取り、どこからを外注するかを工程ごとに決めておきましょう。他社のシステムを引き継ぐ場合は、設計書・ソースコード・アカウント・データの所在と権利を確かめることが出発点になります。あわせて、工程ごとの契約形態と検収の基準、仕様変更の手続きを契約前にすり合わせておくと、引き継ぎの場面で範囲があいまいになりにくくなります。

一方で、これらすべての工程を発注者が細かく統制するのは現実的ではありません。大切なのは、上流に集中して下流は信頼できる相手に委ね、さらに工程の分断によって生じる手戻りそのものを減らす作り方を選ぶことです。動く画面を見せながら設計・実装・改修を一気通貫で進められるノーコード開発は、工程の引き継ぎロスを抑えたい中小企業のシステム開発と相性の良い選択肢です。

開発途中の案件を引き継ぐ場合は、要件を整理し直し、どこまで実装を担うかを最初に決めることが大切です。当社の開発事例では、他社が作成に取り掛かっていた高校向けのポータルサービスを引き継いで要件定義と実装を担当し、部活や生徒の課外活動への寄付を募る機能と、課外活動の指導者を募集・応募できる機能を開発しました。当社では、開発途中のシステムの引き継ぎや、自社で巻き取る範囲の整理の段階からご相談いただけます。

関連する事例：高校のポータルサービスの事例を見る

会社概要を見る・開発実績を見る

受託開発の相談・具体的な相談を送る