システム開発の依頼は何から？準備・費用・段階的な頼み方と選び方

システム開発を外部に依頼しようと決めても、社内に詳しい人がいなければ、最初の一歩でつまずきがちです。

何から始めて、誰に、どう頼めばよいのか、費用はいくらかかるのか。業務の手間を減らしたい場合も、今のシステムの置き換えを急ぐ場合も、高い費用をかけたのに現場で使われない、後から費用が膨らむ、作った会社にしか直せなくなる、といった失敗は避けたいところ。

この記事では、依頼の流れと発注側が決めること、初めてのシステム化か置き換えかで変わる準備、費用の決まり方と段階に分けた頼み方、依頼先の種類と見極め方、契約の確認点をまとめました。

運営するEPICsは、作らない選択肢も含めて中立に提案し、業務診断から開発、現場への定着までを支援する業務システムの受託開発会社です。
開発実績は250件以上あります（出典：EPICs DX・業務システム開発支援／EPICs アプリ・システム受託開発サービス）。

システム開発の依頼は何から始める？全体の流れと発注側が決めること

システム開発の依頼は、困っていることとシステムで変えたいことを整理し、開発会社に相談するところから始まります。

全体は、相談・ヒアリング、提案・見積もり、契約、要件定義（作る機能や条件を決める工程）、設計・開発・テスト、運用・保守の6つの段階に分かれるのが一般的です。
初めてシステム化する場合も、今のシステムを置き換える場合も、この流れは同じ。違うのは依頼の前に準備するもので、次の章で詳しく解説します。

各段階に共通するのは、開発会社に任せきりにせず、発注側が決めることがある点。ここが曖昧なままだと作るものの範囲が定まらず、費用や期間がぶれる原因になるのです。
IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」の紹介ページにも、システムの要件を定義する責任は、システムを利用して事業に役立てる側（ユーザ）にあると言われている、との記載があります。
システム開発の遅延の過半は要件定義の失敗にあると言われていることも、同じページで触れられている点です（出典：IPA「ユーザのための要件定義ガイド 第2版」）。

段階	この段階でやること	発注側が決めること
1．相談・ヒアリング	困りごとと目的を伝え、開発会社が業務を聞き取る	何に困り、何を変えたいか
2．提案・見積もり	進め方と費用の提案を受ける	どの会社を、どんな条件で比べるか
3．契約	頼む範囲と契約の形を決める	どこまでを頼むか
4．要件定義	必要な機能と条件を決める	機能の優先順位
5．設計・開発・テスト	画面や仕組みを作り、動きを確かめる	画面の確認と、受け入れてよいかの判断
6．運用・保守	使い始め、不具合や業務の変化に合わせて直す	保守の範囲と相談の窓口

表の右の列は、開発会社が代わりに決められない判断。どの段階で何を決めるのかを先に知っておけば、相談の前に何を準備すればよいかも見えてくるはずです。

要件定義で何を決め、発注側がどう関わるかは、要件定義とはの記事で詳しく紹介しています。

依頼の前に何を準備する？初めてのシステム化か置き換えかで変わる

依頼の前に準備するものは、初めてシステム化するのか、今のシステムを置き換えるのかで変わります。どちらの場合も、予算と時期の目安は添えて伝えるのが基本。準備するものは次の3つです。

• 初めてのシステム化：困っている作業と変えたいことの書き出し
• 置き換え：期限と、引き継ぎに要る資料
• どちらの場合も：予算と時期の目安

初めてのシステム化なら、困っている作業と変えたいことを書き出す

初めてシステム化する場合は、困っている作業と、システムで変えたいことを書き出しておけば十分です。書き出すのは、次の4点。

• 誰が（担当者・部署）
• どの作業を
• 何で行っているか（紙・Excel・FAXなど）
• どこで困っているか

変えたいことは、「ないと業務が回らない」ものと「あると助かる」ものに分けておきましょう。形式は自由で、手書きのメモでも構いません。
「注文書を見てExcelに入力し、転記ミスが出る」のように、作業と困りごとを1行ずつ書く程度で足ります。
この書き出しを、開発会社に提案を頼む書面に整えたものがRFP（提案依頼書）です。

開発会社は、今の業務の進め方をもとに提案を考えるもの。そのため、業務を知っている発注側の書き出しが出発点になるのです。
IPA（情報処理推進機構）の要件定義ガイドの紹介ページにも、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増している、と書かれています（出典：IPA「ユーザのための要件定義ガイド 第2版」）。

置き換えなら、まず期限を伝え、引き継ぎに要る資料を集める

今のシステムを置き換える場合は、まず期限を伝え、引き継ぎに要る資料を集めておきます。サポート終了日や契約の満了日が分かれば、開発会社はそこから逆算して進め方を考えられるからです。
期限が近いほど選べる進め方は限られるため、早めに相談しましょう。そろえておきたいのは、次の4つ。

• 今の開発会社と交わした契約書
• ソースコード（プログラムの中身）とデータがどこに保管されているか
• サーバーやドメイン（ホームページやメールのアドレスの元になる名前）、契約中のクラウドサービスのアカウント情報（どの会社と、誰の名義で契約しているか）
• 仕様書や操作マニュアルなど、システムの説明資料

新しく引き継ぐ開発会社は、中身を調べるところから始めます。手元にそろっているものが多いほど、引き継げるか作り直すかを早く判断できるでしょう。
全部そろわなくても、分かる範囲で伝えれば問題ありません。

契約書では、プログラムの権利やデータの扱いがどう取り決められているかを確かめておきましょう。
なお、システムの置き換え（再構築）は、IPAが公開する「情報システム・モデル取引・契約書（第二版）」でも、見直しのポイントの一つに挙げられているテーマです（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。

予算と時期は、幅と理由を添えて伝える

予算と時期は、決め切れていなくても、幅と理由を添えて伝えれば十分です。予算は、まだ金額を出せない段階でも相談できます。出せそうな幅があれば、その幅を伝えましょう。
時期は、使い始めたい時期と、その理由（決算期、繁忙期、サポート終了など）をセットで伝えるのが基本。

予算と時期の幅と理由が分かれば、開発会社はそれに合わせて作る範囲や進め方を提案できます。予算が固まらない場合は、業務診断など小さな範囲から頼み、段階ごとに次の予算を決める方法も。この方法は、後の章「まとまった予算を一度に出せないときは？」で詳しく紹介します。

決裁する人には、解決したい困りごとと使い始めたい時期だけでも、相談の前に伝えておくとよいでしょう。提案や見積もりが出たあとの社内の説明がスムーズになります。

システム開発の依頼にかかる費用は？金額を左右するのは作る範囲と頼む工程

システム開発の依頼にかかる費用に一律の相場はなく、何をどこまで作るかと、どの工程まで頼むかで決まります。具体的な金額の目安は、次の章で段階ごとに表にまとめました。

画面・機能・使う人数・つなぐ先が増えるほど、費用と期間は増える

システム開発の費用と期間は、画面や機能の数、使う人数、つなぐ先が増えるほど大きくなります。作る範囲を決める主な要素は、次の4つです。

• 画面や機能の数
• 使う人数
• 今のシステムや機器とつなぐか
• 今のデータを移すか

料金の目安を公開している受託開発会社のEPICsも、画面数と利用人数の組み合わせで「小規模」「中規模」といった区分を設けています（出典：EPICs DX・業務システム開発支援）。
たとえば、紙の日報をスマートフォンで入力できるようにするだけなら、画面は数枚で済むはず。一方、その日報のデータを基幹システム（受発注や会計など、会社の中心となる業務のシステム）に送り、全社員が使う形にすると、画面もつなぐ先も増え、費用も期間もふくらみます。

頼む工程の広さも、金額を左右する要素。要件定義から、テスト、データの移行、導入時の操作説明、公開後の保守まで、どこを任せるかで合計は変わるものです。

見積もりを比べるときは、抜けている工程がないかを先に見る

複数社の見積もり（相見積もり）を比べるときは、合計金額より先に、必要な工程が抜けていないかを確かめます。合計の安さだけで選ぶと、あとから要件定義やデータの移行を別料金で頼むことになりかねません。

確かめるときは、最初の章の表にある6つの段階と、見積書の行を照らし合わせます。特に、要件定義・テスト・データの移行・操作説明・保守のうち、入っていないものがないかを見ましょう。
「一式」とだけ書かれた行があれば、内訳を出してもらいます。仕様の変更や対象業務の追加で、どんなときに追加費用が出るのかが書かれているかも確認が必要です。

要件が固まる前の見積もりは、各社がそれぞれ前提を置いて出すため、金額に幅が出やすいもの。
IPAの「情報システム・モデル取引・契約書（第二版）」の紹介ページには、契約のタイミングへの期待が書かれています。
双方がシステムの仕様や検収（納品物を受け入れてよいか確かめること）の方法などについて、共通理解のもと対話を深めることです（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。
前提をそろえるには、依頼の前に書き出した同じ資料を各社に渡すとよいでしょう。

まとまった予算を一度に出せないときは？段階に分けて頼む進め方

まとまった予算を一度に出せないときは、業務診断、一部の業務での試行、本開発と、段階に分けて頼む方法があります。各段階の終わりに次へ進むかを決めるため、総額を一度に負担せずに済むのが利点。
段階ごとの結果は、社内で予算の承認を得るときの説明材料としても使えます。

業務診断、一部の業務での試行、本開発の順に頼む

段階に分けて頼む場合は、業務診断で変えるべき業務を見極め、一部の業務で試してから、本開発で全体へ広げます。業務診断は、今の業務を把握し、既製品（市販の業務ソフトやサービス）で足りるか、どこから作るかを選ぶ工程です。
一部の業務での試行はパイロット（一部の部署・業務で試すこと）とも呼ばれ、試した後に「拡げる・作り直す・止める」を決められます。

次の表の費用の目安は、受託開発会社のEPICsが2026年10月時点で公開している参考料金です。どれも「この金額から」という下限の目安として見てください（出典：EPICs DX・業務システム開発支援）。

段階	確かめること	次へ進むかの判断	費用の目安
1．業務診断	本当に変えるべき業務はどこか、既製品で足りるか	作るか、どの業務から試すか	30万円〜 （本開発を依頼する場合は全額充当）
2．一部の業務での試行（パイロット）	現場で使われ、効果が出るか	拡げる・作り直す・止める	50万円〜
3．本開発（全体へ広げる）	全体に広げても同じ効果が出るか	改善を続けるか	作る範囲による ・小規模（〜15画面・〜1,000人想定）：1ヶ月〜、80万円〜 ・中規模（31〜50画面・〜10,000人想定）：3ヶ月〜、200万円〜 ・大規模・基幹（50画面〜・10,000人〜）：4ヶ月〜、300万円〜

本開発の金額は、前の章で見た作る範囲によって変わります。業務診断の段階で、自社のシステムがどの規模に当たりそうかを聞いておくと、次の予算を組みやすくなるはずです。

段階に分けると打ち合わせが増え、最初に全体の設計も要る

段階に分けて頼む方法には、注意点もあります。打ち合わせが増えることと、最初に全体の設計が要ることです。主な注意点は次の3つ。

• 段階ごとに打ち合わせと確認が入るため、一度に頼むより発注側の手間が増える
• 業務診断の時点で最終的な全体像を描いておかないと、後の段階で作り直しが出やすい
• 段階に分けた発注を受けていない開発会社もある

作るものがすでに固まっている小さな改修や、画面を一つ足すだけの依頼なら、一度に頼むほうが早いこともあります。
段階に分けた発注を受けるかどうかは、相談の場で確かめるとよいでしょう。確かめ方は、後の章「依頼先はどう見極める？」で紹介します。

システム開発の外注先はどこを選ぶ？依頼先の種類と探し方

システム開発の外注先は、作るシステムの規模と、自社がどこまで業務の説明や管理を担えるかで選びます。主な依頼先は次の4種類です。

• 大手SIer（企業のシステム開発を取りまとめて請け負う大手の会社）
• 中堅・中小の開発会社
• フリーランス（個人で活動するエンジニア）
• オフショア開発（海外の開発会社への委託）

業務を説明して作るものを決める役割が発注側に残ることは、どの依頼先でも同じです。
IPAも、業務部門のユーザが要件定義に主体的に関わる必要性が増していると書いています（出典：IPA「ユーザのための要件定義ガイド 第2版」）。

依頼先	向いている場合	注意点
大手SIer	複数の拠点や全社の基幹システムを、大規模に作り替える場合	費用の規模が大きく、小さな案件は対応の範囲外のことがある
中堅・中小の開発会社	中小企業の業務システムを、業務の整理から一緒に作りたい場合	得意な業種や開発の範囲に差があるため、同業種の実績と保守の体制を確かめる必要がある
フリーランス	小さなツールや、今のシステムの部分的な改修	1人で担うため、長く保守を頼む場合や、担当が離れたときの引き継ぎに備えが要る
オフショア開発	仕様が固まっている、まとまった量の開発	要件の整理や仕様の調整は国内側で担う必要があり、発注側の管理の手間が増える

200万〜400万円くらいの予算で、業務の整理から一緒に進めたい中小企業なら、中堅・中小の開発会社が候補の中心になりやすいでしょう。

なお、外注のほかに、社内に開発の担当者を置いて自社で作る「内製」という選択肢もあります。外注先を探す方法は、知人からの紹介、展示会、発注したい会社と開発会社を引き合わせるマッチングサービスなど。
地域を絞って探したい場合は、大阪でシステム開発を頼める会社、名古屋のシステム開発会社、宮崎のシステム開発会社の記事も参考にしてください。

依頼先はどう見極める？相談の場で確かめること

比べる候補が2〜3社まで減ったら、どの会社にも次の4点を同じ聞き方で尋ねてみてください。答え方の違いから、自社に合う依頼先かどうかが見えてきます。

同業種の実績は、件数より進め方を聞いて比べる

同業種の実績は、件数の多さより、その案件をどう進めたかを聞いて比べます。同じ業界の仕事に慣れた会社なら、業務の前提を一から説明する手間は減るでしょう。

とはいえ、業界に詳しいことと、発注側と一緒に要件を固めてくれることは別の話。要件定義を発注側に任せきりにする会社だと、ITに詳しくない会社は決めきれないまま開発に進むおそれも。
IPAの紹介ページにも、要件を定義する責任はユーザ側にあると言われている、と書かれています（出典：IPA「ユーザのための要件定義ガイド 第2版」）。実績を聞くときは、要件をどう一緒に決めたかまで確かめておきたいところです。
事例が非公開でも、自社と似ている点を具体的に説明してもらえれば、判断の材料になります。

聞き方の例：「同じ業種の案件で、要件はどのように一緒に決めましたか」

「作らない」という提案が出てくるかで、中立かどうかが分かる

「作らない」提案まで出してくれる会社は、作ることを前提にせず中立に考えていると判断できます。ここでいう「作らない」提案とは、SaaS（インターネット経由で使う既製のソフト）やパッケージ（既製の業務ソフト）の活用、今のシステムの一部の改修で足りるかどうかの提案です。

すべてを一から作れば、作る必要のない部分にまで費用と期間がかかるでしょう。IPAの「情報システム・モデル取引・契約書」も、受託開発用とは別に、パッケージやSaaSを活用する場合の契約書を用意しています（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。
一方で、既製品に業務を無理に合わせると、現場で使われなくなることも。既製品が向く部分と作るべき部分を分けて説明してくれるかで判断しましょう。

聞き方の例：「今のシステムの手直しや市販のソフトで済む部分は、どこだと考えますか」

効果の測り方を作る前に決める会社なら、決裁者に説明しやすい

導入の効果を何で測るかを作る前に一緒に決めてくれる会社なら、費用対効果を決裁者に説明しやすくなります。測り方が決まっていないと、導入前後の違いを数字で示せません。
業務システムは現場で使われなければ効果が出ないため、たとえば利用率のように、使われているかを確かめる指標も入っていると安心です。

聞き方の例：「導入の効果は、何で測りますか」

段階に分けた発注を受けるかで、予算の組み方が変わる

業務診断や一部の業務での試行から段階に分けて頼めるかで、最初に用意する予算の大きさが変わります。段階に分けた発注を受けるかどうかは開発会社によって違い、受けない会社では最初に全体の見積もりと予算が必要になるのが一般的です。

段階に分けて頼めれば、最初は小さな予算で始め、結果を見て次の予算を決められます（進め方は前の章「まとまった予算を一度に出せないときは？」で紹介しています）。途中の段階で止めた場合の費用の扱いや、試した結果を次の段階にどう引き継ぐかも、あわせて聞いておくと安心でしょう。

聞き方の例：「最初は一部の業務だけを頼み、結果を見て続きを決めることはできますか」

発注の前に契約で何を確かめる？引き渡しと保守で困らないための確認点

発注の前の契約では、契約の形、成果物とソースコードの権利、検収の方法、保守の範囲の4つを確かめておくと、引き渡しの後で困りにくくなります。
発注側と開発会社のどちらにもメリットが偏らない契約書を目指して、IPAが公開しているひな形が「情報システム・モデル取引・契約書（第二版）」です。
請負契約で納品物に不具合があった場合の責任や、途中で契約を解除した場合の報酬の扱いなども、論点として整理されています（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。

確かめること	確かめる理由
契約の形（請負か準委任か）	請負は完成した成果物に対して、準委任は作業に対して支払う形。作るものが固まる前と後で、向く形が違うため
成果物の権利と、資料・ソースコードの受け取り	受け取れないと別の会社に引き継げず、作った会社に縛られる状態（ベンダーロックイン）になりやすいため
検収の方法と期間	何をもって完成とするかが曖昧だと、納品後の不具合の扱いでもめやすいため
保守の範囲と費用	不具合の対応、問い合わせ、小さな改修がどこまで含まれ、追加の開発をどう扱うかで、導入後にかかる費用が変わるため

作った会社と連絡が取れなくなっても次の会社へ移れるように、資料とソースコードを受け取れるかは契約の前に確かめておきましょう。
なお、この記事は法律の助言ではありません。契約書の内容は、必要に応じて弁護士に確認してください。

業務システムの開発を段階的に頼むならEPICs

業務システムの受託開発会社であるEPICsは、作る前の業務診断から、段階的な開発、引き渡し後の保守までを1社で受け持ちます。初めてのシステム化でも置き換えでも、まず現場の業務を把握するところから始めるのが基本です。
既製のSaaSで済むならSaaSの活用を、今のシステムの手直しで済むならその方法を勧めるなど、作らない道も含めて中立に提案。依頼は診断だけ、開発だけでも構いません。

EPICsの進め方は、まず一部の業務で試し、その結果を見て「拡げる・作り直す・止める」を選ぶ形。費用をまとめて先に負担する必要はありません。
開発手法も、業務領域ごとに、ノーコード（プログラムを書かずに作る方法）・AI駆動開発（AIを活用して作る方法）・スクラッチ開発（一からプログラムを書く方法）を使い分けるのが特徴です。

EPICsは、プログラムとデータの所有権をお客様に渡し、資料も整えるため、別の会社への移管もしやすい状態を保てます。
また、10年使う前提で保守しやすく作り、業務の変化や法改正に合わせた改善も続けるのが方針です。

EPICsの開発実績は250件以上。依頼は北海道から沖縄まで全国から受けており、打ち合わせから開発までオンラインで進めています。
業務診断の費用の目安は30万円〜（本開発を依頼する場合は全額充当）。

まずは困っている作業や今のシステムの資料を手元にそろえ、どこから手を付けるかを専門家と決めることから始めてみてください。

出典：EPICs DX・業務システム開発支援／EPICs アプリ・システム受託開発サービス

システム開発を依頼する費用はいくらですか？

一律の相場はなく、作る範囲と、どの工程まで頼むかで決まります。作る範囲を左右するのは、画面や機能の数、使う人数、今のシステムとつなぐかどうか。要件定義・テスト・データの移行・保守のどこまでを頼むかでも、金額は変わります。参考として、受託開発会社のEPICsが2026年10月時点で公開している目安は、業務診断が30万円〜、一部の業務で試すパイロット開発が50万円〜、小規模なシステム（〜15画面・〜1,000人想定）が1ヶ月〜・80万円〜で、いずれも下限の目安です。見積もりを比べるときは、合計金額より先に、抜けている工程がないかを確かめましょう。

システム開発を依頼すると、どのような流れで進みますか？

相談・ヒアリング、提案・見積もり、契約、要件定義、設計・開発・テスト、運用・保守の順に進むのが一般的です。どの段階にも、開発会社に任せず発注側が決めることがある点を押さえておきましょう。たとえば、作る機能や条件を決める要件定義では機能の優先順位を、テストでは納品物を受け入れてよいかを、発注側が判断します。初めてのシステム化でも今のシステムの置き換えでも流れは同じで、違うのは依頼の前に準備するもの。初めてなら困っている作業と変えたいことの書き出し、置き換えなら今のシステムの資料と契約書を用意しておくと、相談を進めやすくなります。

なぜ要件が固まっていなくても、システム開発の依頼を相談できるのですか？

作る機能や条件は、相談したあとの業務診断や要件定義の工程で、開発会社と一緒に洗い出せるためです。発注側が用意するのは、困っている作業と変えたいことの書き出しと、予算と時期の目安で足ります。予算や時期が決まっていなければ、幅と理由を伝えれば十分です。ただし、IPA（情報処理推進機構）の要件定義ガイドの紹介ページでは、システムの要件を定義する責任は利用する側にあると言われている、と書かれています。そのため、要件定義まで一緒に進めてくれる依頼先を選ぶことが大切です。

今のシステムを作った会社と連絡が取れない場合でも、置き換えを依頼できますか？

はい、置き換えや引き継ぎの相談はできます。まず、サポート終了日などの期限を伝えたうえで、仕様書などの資料、ソースコードとデータの保管場所、サーバーやサービスのアカウント情報、今の開発会社との契約書のうち、分かるものをそろえましょう。そろっているものが多いほど、引き継げるか作り直すかを早く判断できます。全部そろわなくても、分かる範囲で伝えれば問題ありません。次に同じ状況にならないよう、新しく頼むときは、資料とソースコードを受け取れるかを契約の前に確認しておくと安心です。