業務システム開発の外注先はどう選ぶ？依頼手順と発注前準備・失敗回避を解説

業務システムの外注が難しいのは、発注する側が「何を作ってほしいか」を言語化しきれない状態から始まるためです。会計や販売管理とつなぐのか、現場のExcel帳票を何種類まで再現するのか、承認ルートの分岐はいくつあるのか。この手の与件は社内の業務そのものなので、開発会社側からは見えません。この記事では、外注する範囲の決め方、依頼先5タイプの向き不向き、発注前に固める4つの与件、RFP作成から契約までの手順、そして丸投げや仕様追加といった失敗パターンの回避策までを、発注側が手を動かせる粒度で並べました。開発手法そのものの違いや進め方の全体像は業務システム開発とは？4つの開発手法・費用相場・失敗しない進め方を解説で扱っているため、本記事は外注と発注実務に絞ります。

まとめ｜外注の可否を分ける3つの与件と、依頼先を決めるまでの順序

業務システムの外注で成否を分けるのは、開発会社の選定そのものよりも、選定に入る前に発注側が固めた与件の解像度です。固めるべき与件は3つ。①つなぐ既存システムの名前と連携本数、②再現する帳票の種類数と承認ルートの分岐数、③移行するデータの対象年数と件数。この3点を1枚の紙にして各社へ同時に渡せば、見積もりの前提が揃い、金額差が「前提の違い」ではなく「実力と単価の違い」として比べられるようになります。

順序は、外注範囲の決定 → 依頼先タイプの絞り込み → RFP作成 → 相見積もり（3社前後）→ 契約形態の決定 → 検収基準の合意、の6段階です。先に決めるべきは範囲であって会社ではありません。要件定義から任せるのか、設計以降だけを委ねるのかで、選ぶべき依頼先タイプも契約形態も変わるからです。

そして本記事の立場をひとつ先に述べます。要件が固まっていない段階で、開発から運用までを請負一括で発注してはいけません。要件定義を準委任で分離し、その成果物をもって開発フェーズの請負契約を結ぶ二段構えにしてください。一括発注は金額が確定して安心感がある反面、要件が動いた瞬間に追加費用の交渉が始まり、結果として二段構えより高くつくのが実務での通例です。

業務システム開発の外注範囲｜内製との線引きと委ねる工程の決め方

外注の話は「どこの会社に頼むか」から始めたくなりますが、先に決めるのは範囲です。範囲が決まらないまま複数社に声をかけると、各社が想定した範囲がばらばらのまま見積もりが返ってきて、比較が成立しません。

内製で回せる業務と、外注が必要になる業務を分ける4つの判断材料

内製と外注の線は、社内にエンジニアがいるかどうかだけでは引けません。実務で効く判断材料は4つあります。第一に、その業務が自社の競争力に直結するかどうか。受注から出荷までの独自オペレーションのように、他社と差がつく部分は要件が頻繁に変わるため、手を入れ続けられる体制が要ります。第二に、保守まで含めて人を張れるか。作る人より、5年後に直せる人がいるかで判断してください。第三に、要件の変更頻度。四半期ごとに業務が変わる領域を請負で外注すると、変更管理の交渉に工数が消えます。第四に、納期です。

判断の考え方そのものは内製化とは？外注との違い・メリットとデメリット・進め方を解説で整理しています。実務としては全部内製か全部外注かの二択にせず、コア業務の画面だけ内製、周辺の基幹連携やインフラは外注、という分割が現実的な着地になります。

要件定義から委ねる場合と、設計以降だけを外注する場合の分岐点

分岐点は単純で、自社でRFP（提案依頼書）を業務レベルまで書けるかどうかです。書けるなら設計以降の外注で足ります。書けないなら、要件定義そのものを準委任で発注してください。ここを曖昧にしたまま「よしなにお願いします」と伝えると、開発会社は自社の標準的な業務モデルを前提に見積もるため、現場の運用と合わない設計が出てきます。

要件定義を外注する場合、成果物は要件定義書だけでなく、業務フロー図・画面一覧・帳票一覧・データ移行対象一覧まで含めて指定します。この4点が揃っていれば、開発フェーズを別の会社に出すことも可能になり、1社に囲い込まれる状態を避けられます。対象範囲そのものの捉え方は業務システムとは？種類・基幹システムとの違いと開発・導入形態の選び方で確認してください。

外注先5タイプの比較｜SIer・受託開発会社・フリーランスの向き不向き

依頼先は大きく5タイプに分かれます。同じ「開発を外注する」でも、契約の相手が法人か個人か、指揮命令が誰にあるかで、発注側が負う手間とリスクが違います。

外注先5タイプの得意領域と費用感、向く案件規模と発注リスクの比較

個人（フリーランス）への依頼は、単一業務・数画面までで、かつ発注側に仕様を書ける人がいるなら成立します。オフショアを検討する場合の判断軸はオフショア開発とは？メリット・デメリットと国内受託開発との使い分けを発注者視点で解説にまとめました。SESは成果物ではなく労働時間に対する契約なので、完成責任を求めるなら選択肢から外してください。

業務システムの外注先を見極めるときに効く4つの実績確認と質問例

会社案内の実績一覧を眺めても差は見えません。次の4点を、具体名を挙げて質問してください。第一に、同業種の業務システムを何本手がけたか。業種が違えば商習慣が違い、帳票の作り直しが発生します。第二に、既存システムとの連携実績を製品名レベルで言えるか。「会計システムと連携できます」ではなく「勘定奉行のCSV連携とfreeeのAPI連携の両方で実績がある」と答えられるかを見ます。

第三に、保守運用を何年継続しているか。開発だけ受けて保守を持たない会社は、納品後の窓口が消えます。第四が体制で、専任のプロジェクトマネージャーが付くのか、営業担当が兼任するのかを確認してください。曖昧な回答が続く相手は、要件定義でも同じ密度になります。

発注前に固める4つの与件｜業務要件・予算枠・体制とスケジュール

準備の質がそのまま見積もりの精度になります。ここで手を抜くと、契約後の追加費用という形で必ず返ってきます。

現行業務の棚卸しで書き出す6項目と、曖昧なまま渡した場合の影響

業務システムの見積もりを揺らすのは、画面数ではなく業務の背景情報です。渡す前に次の6項目を書き出してください。

• 現行の業務フロー（誰が・いつ・何を入力するか）
• 扱う帳票の種類数と、そのうち外部提出が必要なもの
• 利用者数と、権限パターンの数（閲覧のみ・承認・管理者など）
• 連携する既存システムの製品名と連携本数
• 移行するデータの対象年数と件数
• 月末や期末など、ピーク時の同時利用者数と処理件数

このうち権限パターンと連携本数は、抜けると見積もりが2倍ぶれる代表格です。権限が3種類のつもりが実は部署ごとに9種類あった、という食い違いは業務システムで頻繁に起きます。数えきれない項目でも「未確定」と書いて渡すほうが精度は上がります。

予算枠の決め方と、社内決裁を発注前に通しておく段取りと期間の目安

予算は「いくらかかりますか」と聞いてから決めるものではありません。先に上限枠を決め、その枠内で実現できる範囲を各社に提案させると、比較が機能します。金額のレンジと内訳の読み方は業務システム開発の費用相場は？規模別の目安と内訳・見積書の読み方を発注者視点で解説で扱っているため、本記事では段取りだけ述べます。

段取りとして押さえるのは、稟議の所要期間です。数百万円規模でも役員決裁が必要な企業は多く、起案から承認まで1か月前後かかるケースは珍しくありません。提案を受けてから稟議を回すと、見積もりの有効期限が切れて再提示になります。相見積もりの前に予算枠だけ内示を取ってください。

発注側の担当者体制と、意思決定者を1人に決めておくべき理由と権限

発注側の体制で最も効くのは、人数ではなく意思決定者が1人に定まっているかどうかです。業務システムは複数部署にまたがるため、営業部と経理部で希望が衝突します。このとき「両方の意見を持ち帰って調整します」を繰り返すと、開発会社は決定待ちで手を止め、スケジュールだけが延びます。

置くべき役割は3つで足ります。決裁権を持つ責任者が1人、開発会社との窓口となる担当者が1人、現場の業務を説明できる実務者が部署ごとに1人。窓口担当は週に半日程度を確保できる人を選んでください。月に数時間しか動けない兼任担当を立てた案件は、要件定義の段階で遅延します。

依頼から契約までの手順｜RFP作成・相見積もり・契約形態の決め方

ここからが発注実務です。各社への声かけから契約締結まで、業務システムでは2〜3か月を見ておいてください。

RFPに書く8項目と、抜けると見積もりが大きくぶれる3つの情報

RFPは分厚く作る必要はありません。A4で5〜10枚に次の8項目が入っていれば、提案の土俵は揃います。

1. システム化の目的と、解決したい業務課題
2. 対象業務の範囲と、対象外とする業務
3. 現行業務フローと、扱う帳票・データの概要
4. 連携する既存システムと連携方式の希望
5. 利用者数・権限パターン・想定データ量
6. 予算枠と希望納期、稼働開始の目標時期
7. 提案してほしい内容（体制・開発手法・保守条件）
8. 提案書の提出期限と選定スケジュール

このうち抜けると金額が大きくぶれるのは、連携方式・データ移行の範囲・非機能要件（性能や稼働時間の条件）の3つです。逆に、画面のデザイン要望や細かな機能の一覧は、この段階で作り込まなくて構いません。RFPは仕様書ではなく、提案の前提を揃えるための文書だからです。

相見積もりを取る社数の目安と、金額以外で比べるべき5つの比較観点

社数は3社前後が目安です。5社を超えると、各社への説明と質問対応だけで発注側の工数が尽き、比較の質が落ちます。見積書の読み解き方はシステム開発の見積もりとは？見積書の見方・依頼方法・相見積もりの比較を発注者視点で解説に譲り、ここでは金額以外の比較観点を挙げます。

見るのは5点。①提案が自社の業務課題に触れているか（汎用テンプレートの流用でないか）、②工程別・職種別に工数が分解されているか、③連携とデータ移行が見積もりに含まれているか（別途扱いになっていないか）、④保守運用の条件と年額が提示されているか、⑤アサインされるメンバーの経歴が具体的か。総額だけが安い提案は、③と④が抜けていることが多く、契約後に追加見積もりとして戻ってきます。

請負と準委任の使い分け方と、契約不適合責任の通知期間の実務ルール

請負は仕事の完成に対して報酬を払う契約、準委任は業務の遂行に対して払う契約です。要件が固まっていない要件定義フェーズは準委任、仕様が確定した開発フェーズは請負、という分け方が実務の基本形になります。2020年4月1日施行の民法改正では準委任に「成果完成型」が明文化され（民法648条の2）、成果物に紐づけた準委任も選べるようになりました。契約の呼び名の違いは委託とは？委任・請負・受託との違いと発注者が押さえる契約の選び方で整理しています。

同じ民法改正で、従来の瑕疵担保責任は契約不適合責任へ置き換わりました。種類・品質の不適合については、不適合を知った時から1年以内に通知することが原則です（民法566条）。納品から1年ではありません。契約書に「検収completion後6か月」といった短縮条項が入っていることもあるため、期間を必ず確認してください。IPAが2020年12月22日に公開した「情報システム・モデル取引・契約書（第二版）」は、この改正を踏まえて条項を整理しており、自社の契約書案を点検する物差しに使えます。

2026年1月施行の取適法で、発注側の書面と支払い実務が変わる点

2026年1月1日、下請法は「中小受託取引適正化法（取適法）」へ名称を変え、規制内容が拡張されました。改正法は2025年5月16日に成立し、同月23日に公布されています。自社が委託側にあたる場合、発注実務で影響が出るのは主に支払いと価格協議の2点です。

支払手段としての手形払いは禁止されました。電子記録債権やファクタリングも、支払期日までに満額を得ることが難しい形なら同様に禁止対象となり、振込手数料は発注側の負担とされています。受託側から価格協議の求めがあったのに協議に応じない、必要な説明をしないといった一方的な代金決定も禁止。支払期日は給付を受領した日から60日以内という枠が引き続き効きます。従業員数を用いた適用基準の追加や運送委託の対象化も含まれ、紙の約束手形・小切手は2027年3月末までに廃止される方向です。自社の支払サイトを先に確認しておいてください。

外注で失敗する典型パターンと回避策｜丸投げ・仕様追加・保守不在

失敗の型はほぼ決まっています。以下の4つは、いずれも契約前の取り決めで回避できます。

丸投げで手戻りが起きる構造と、発注側が手放してはいけない決定権

丸投げが失敗する理由は、開発会社が業務を知らないからではありません。業務の「どちらでもよい部分」と「絶対に変えられない部分」の区別が、発注側にしか付かないからです。承認ルートを1段減らせるか、締め処理を月末から翌月5日にずらせるか。この判断を委ねると、現場が受け入れられない設計が出てきて、テスト段階で作り直しになります。

手放してはいけないのは3つの決定です。業務ルールを変えるかどうかの決定、優先順位を落とす機能の決定、そして検収を通すかどうかの決定。この3つを発注側が持ち続ければ、設計や実装の手段は委ねて構いません。

仕様追加が止まらない案件の変更管理と、追加費用の取り決めの手順

要件定義が終わった後の追加要望をゼロにはできません。止めるべきなのは追加そのものではなく、追加が記録されないまま進むことです。変更依頼書のフォーマットを契約時に決め、①依頼内容、②追加工数の見積もり、③スケジュールへの影響、④決裁者の承認、の4点を1枚に残す運用にしてください。

単価も先に決めておきます。追加開発が発生した場合の人月単価または人日単価を契約書に書いておけば、そのつど交渉する手間が消えます。決めずに進めた案件では、追加要望が出るたびに見積もり待ちが発生し、開発が止まる。

検収基準と受入テストの範囲を、契約前に決めておく理由と実務手順

検収でもめる原因の大半は、合格ラインが文書化されていないことにあります。契約前に、受入テストの実施主体・期間・合格条件を決めてください。合格条件が「不具合がないこと」では機能しません。障害を影響度で3段階に区分し、業務が止まる重度の障害はゼロ、軽微なものは残課題として期日を切って合意する形が着地点になります。

受入テストの期間は、開発期間の1〜2割を目安に確保します。3か月の開発なら2〜3週間。現場の実務者が参加できる日程を、業務の繁忙期とぶつからないように先に押さえてください。詰めずに納品日だけ決めると、検収が形骸化し、稼働後に業務が止まります。

納品後の保守体制と、ソースコード著作権の帰属で確認する契約条項

納品後に効いてくるのが保守と権利の2点です。保守は、対応時間帯・障害時の連絡経路・一次回答までの時間・年額費用を契約書に明記します。年額は初期開発費の15〜25%程度が市場で示されている目安ですが、監視やバージョン更新をどこまで含むかで金額が動くため、含まれる作業を一覧で確認してください。

著作権は、何も定めなければ制作した開発会社に帰属します。将来ほかの会社に保守を移す可能性があるなら、成果物の著作権を発注者へ譲渡する条項、または少なくとも改変と第三者への委託を認める利用許諾条項が要ります。ただし開発会社が持つ汎用ライブラリまで譲渡を求めると金額が上がるため、譲渡対象を「本件のために新規に作成したプログラム」に限定するのが現実的な線です。ソースコードの引き渡し形式と時期も、同じ条項で決めておいてください。

発注を見送るべき条件と、依頼先を1社に絞り込むときの最終判断軸

最後に判断です。ここでは玉虫色にせず、条件を示して言い切ります。

この3条件に当てはまるなら、いま外注しないという線引きとその理由

次の3つに当てはまる場合、いま発注しても失敗します。第一に、社内で窓口担当を週に半日も確保できないとき。要件定義は発注側の稼働が前提の工程であり、担当が動けない案件は開発会社の想像で埋められます。第二に、業務ルールそのものを変える意思決定がされていないとき。現行業務をそのまま電子化するだけの依頼は、紙の非効率をシステムに固定するだけで、投資に見合いません。

第三に、既存システムの仕様書もデータ構造も社内で誰も把握していないとき。この状態で連携を含む見積もりを取っても、各社は不確実性を金額に上乗せするか、後から追加見積もりを出すかのどちらかになります。いきなり開発を発注せず、現行調査だけを準委任で切り出して1〜2か月かけてください。順序を守るほうが総額は下がります。

最終1社に絞るときに見る条件と、契約前に済ませる最後の確認事項

最終選定で見る条件は3つに絞れます。①自社の業務課題を提案書の中で言い直せているか、②連携とデータ移行の工数が明示されているか、③保守まで含めた5年間の総額が示されているか。金額の安さは4番目です。初期費用が2割安くても、保守が年額で高ければ3年で逆転します。

契約書を交わす前の最後の確認は、担当するプロジェクトマネージャーとの面談です。営業担当が優秀でも、実際に動くのは開発チームです。想定される難所をその場で質問し、具体的に答えられるかを見てください。一創では業務システムの受託開発を基幹システム開発として提供しており、既存の会計・販売管理との連携やデータ移行を含む形での相談を受け付けています。要件が固まっていない段階での相談でも、現行調査から段階的に進める組み立てが可能です。

よくある質問

業務システムの外注を検討する担当者から実際に多い質問を、5つまとめました。

業務システム開発は個人（フリーランス）に依頼できますか？

単一業務・数画面規模であれば成立します。ただし条件が2つ。ひとつは、発注側に仕様を書ける人がいること。個人への依頼では要件定義を代行してもらえないケースが多く、仕様の曖昧さがそのまま手戻りになります。もうひとつは、保守の継続性を別途手当てすることです。個人は稼働状況で対応できなくなる可能性があり、業務が止まると経営に響く基幹寄りの領域では法人への依頼が無難。複数業務にまたがる場合や既存システムと連携する場合は、受託開発会社を選んでください。

業務システム開発を外注する場合の相場はどのくらいですか？

規模で幅があり、市場に出ている目安では小規模が100万〜300万円、中規模が300万〜800万円、大規模で800万〜1,500万円以上という区分で示されます（2026年7月時点の公開値）。ただし業務システムでは、既存システムとの連携本数、データ移行の対象年数、帳票の種類数、権限パターンの数で金額が上下するため、規模の区分だけで判断すると外れます。内訳と見積書の読み方は、業務システムの費用相場を扱った記事で整理しています。

開発を代行してもらう場合、要件定義書は自社で作る必要がありますか？

必須ではありません。要件定義そのものを準委任契約で外注する形が一般的です。ただし発注側が用意する情報はあります。現行の業務フロー、扱っている帳票の実物、利用者数と権限のパターン、連携したい既存システムの製品名。この4点は社内にしか存在せず、外注できません。委ねるときは、成果物に業務フロー図・画面一覧・帳票一覧・データ移行対象一覧まで含めて指定してください。

相見積もりは何社に依頼するのが適切ですか？

3社前後を目安にしてください。2社では比較の基準が作れず、5社を超えると説明会・質問対応・提案書の読み込みだけで発注側の工数が尽きます。声をかける前に、依頼先タイプ（大手SIerか受託開発会社かなど）を1つに絞っておくと、提案の前提が揃って比べやすくなる。タイプが混ざった相見積もりは、費用構造そのものが違うため金額の比較が成立しません。RFPは同時配布し、質問と回答は全社に共有する運用にしてください。

外注した業務システムのソースコードは自社のものになりますか？

契約で定めなければ、著作権は制作した開発会社に帰属します。自社へ移したいなら著作権譲渡の条項が要ります。ただし譲渡範囲を広げすぎると、開発会社が保有する汎用ライブラリまで対象に入り、金額が上がる要因になる。実務では譲渡対象を「本件のために新規に作成したプログラム」に限定し、汎用部分は改変と第三者委託を認める利用許諾で処理する形が多く見られます。引き渡し形式と時期も同じ条項で決めておいてください。

関連記事

• システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説：外注した後、どの工程で何が出てくるかを把握できます
• スクラッチ開発とは？パッケージ・ローコードとの違いと発注判断を解説：開発方式を選ぶ判断軸を確認できます
• システム開発の費用相場は？内訳・人月単価と見積もりの妥当性を発注者視点で解説：開発費全般の相場観をつかめます
• 金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方：規制業種で外注する場合の追加要件を確認できます
• システム保守とは？運用との違い・費用相場・契約形態を発注者視点で解説：納品後の保守条件を詰めるときの参考になります