【2026年版】システム開発の外注｜相場と進め方、選び方を解説

社内にエンジニアがおらず、システム開発を外部に頼もうと考えている担当者なら、 「外注するとして、何から始めればよいのか」 「相場が分からないので、見積もりが妥当か判断できない」 「丸投げして失敗した話を聞く。自社は何をすればよいのか」 ——このような疑問をお持ちではないでしょうか。

システム開発の外注は、専門技術と開発リソースが社内にない企業にとって現実的な手段ですが、成否は開発会社の腕より、発注側が目的・要件・検収を握れるかで決まります。

相場と進め方を押さえ、内訳と範囲を同じ物差しで比較すれば、ベトナムのような海外の開発会社を使って国内の半分以下の費用で同等品質の開発を進める選択肢も現実的になります。

この記事では、システム開発の外注を検討している方に向けて、

• 外注と内製の違いと外注先の種類
• 外注のメリット・デメリットと丸投げの構造
• 規模別・工程別の費用相場と人月単価
• 発注前の準備から検収までの進め方
• 失敗しない外注先の選び方とオフショアの注意点

上記について、ベトナムで請負型・ラボ型の開発会社を運営し、グループで2,000名以上のIT人財データベースから直接アサインしている当社の実務経験を交えながら解説しています。

自社の案件をいくらで、どこに、どう頼むべきかを判断する材料が揃いますので、ぜひ参考にしてください。

システム開発を外注すべきか——内製との違いと向いているケース

「外注するしかないと思うが、本当にそれでよいのか」——社内にエンジニアがいない企業様から、当社が最初に受ける相談です。

結論から言えば、専門技術と開発リソースが社内になく、一定の期間内にシステムが必要なら、外注が現実的な手段です。

ただし、外注は「任せれば終わり」ではありません。

この章では内製との違い、向いているケース、外注先の種類を整理します。

外注と内製の違い

外注は外部の開発会社や個人に開発を委託する方法、内製は自社のエンジニアが開発する方法です。

違いは、費用の性質・立ち上がりの速さ・ノウハウの帰属にあります。

どちらが優れているかではなく、案件の性質と自社の体制で決まります。

外注が向くケース・内製が向くケース

外注が向くのは、次のような場合です。

• 社内に専門技術(モバイル・決済・AIなど)がない
• 決まった期限までにリリースする必要がある
• 社内のエンジニアが別の業務で手一杯
• 開発の固定費を増やしたくない

逆に、サービスの中核として継続的に改善し続けるもの、業務知識が複雑で外部に伝えにくいもの、中長期でエンジニア組織を育てたい場合は内製が向きます。

実務では「中核は内製、周辺と立ち上げは外注」という組み合わせが多く、内製化の前段階として外部の専属チーム(ラボ型)を使う企業も増えています。

外注先の種類——受託開発会社・フリーランス・オフショア

私自身、ベトナムのIT企業で受託側として案件を担当し、現在はマッチングアプリやAIチャットボットなどを請負型・ラボ型で提供しています。

その経験で言えば、外注先の種類より「その会社にPMがいて、要件から伴走できるか」で結果が分かれる、というのが実態です。受託開発会社に一貫して任せる形そのものを知りたい場合は、「受託開発とは」の記事で流れと費用相場を整理しています。

システム開発を外注するメリット・デメリット

「外注すれば楽になるのか」——メリットは確かにありますが、発注側の準備次第でデメリットが表面化します。

ここでは両方を整理し、最も多い失敗である丸投げの構造を示します。

外注のメリット

• 専門技術を採用せずに使える:モバイル・決済・AIなど、自社にない技術をすぐに調達できる
• 立ち上がりが早い:採用・育成を待たず、契約後に専門チームが動く
• 費用とスケジュールを確定しやすい:請負契約なら契約時に金額と納期が決まる
• 固定費を増やさない:案件単位で費用を調整できる
• 保守・追加開発まで相談できる:リリース後の運用も同じ会社に頼める

外注のデメリット

• ノウハウが社内に残りにくい:開発の中身が開発会社側に蓄積される
• 認識のずれが起こりやすい:業務知識を外部に伝える手間がかかる
• 仕様変更が追加費用になりやすい:請負では契約後の変更が見積もり対象になる
• 外注先への依存:ソースコードや設計資料を受け取らないと、乗り換えられない
• 会社による差が大きい:品質も進め方も会社次第

丸投げが失敗を招く理由

丸投げとは、目的・要件・検収を開発会社任せにすることです。

失敗の構造は決まっています。

目的が曖昧なまま発注する→開発会社が推測で要件を書く→現場の業務と合わない→検収で発覚する→改修は追加費用になる、という流れです。

前回の外注で予算の1.5倍かかった、という相談は珍しくありません。

防ぐには、発注側が「何のために」「誰が使うか」「何を必須とするか」を決め、検収基準を開発前に合意しておくことです。

当社が設計段階から日本人PMのレビューを入れているのも、認識のずれを上流で潰すほうが、検収で見つけるより安く済むためです。

削るべきは工数であって、要件の確認ではありません。

外注費用の相場——規模別・工程別の目安と人月単価

「結局、いくらかかるのか」——外注費用は「人月単価×工数(人月)+諸経費」で決まります。

多くの開発会社は単価を非公開にしており、相見積もりを取って初めて相場感がつかめる、というのが実情です。

この章では規模別の目安、工程別の内訳と人月単価、オフショアの単価と費用を抑えるコツを示します。

規模別の費用目安

※規模別の金額として流通している相場は、開発会社が自社の案件をもとに独自に集計したもので、公的統計のような一次資料が存在しません。金額の幅は機能数・外部連携の本数・非機能要件(性能・可用性・セキュリティ)で決まるため、自社の要件を上表の規模に当てはめたうえで、同じ作業範囲の見積もりを複数社から取って比べてください。

運用保守費は、開発費とは別に年額で見積もります。割合として流通している数値は開発会社が独自に集計したもので一次資料がないため示しませんが、機能追加まで含むのか、障害対応と軽微な修正だけなのかで金額は大きく変わります。契約書で範囲を切り分けたうえで年額を確認してください。

工程別の内訳と人月単価

(工程別の比率として流通している数値は開発会社の独自集計しかなく、公的統計のような一次資料が存在しないため、割合は示していません。上の重みの並びは、当社が受注時に工数を積むときの実感です)

人月単価は役割(プログラマー・SE・PM)によって差があり、どの役割を何人月使うかで総額が動きます。国内の単価は各社が非公開にしていて一次統計がないため、金額そのものではなく「どの役割が何人月入るか」を見積書で開示させて比べてください。

見積もりで要件定義の工数が極端に小さい場合は、要件の詰めが薄い可能性があり要注意です。

オフショア(ベトナム)の単価と費用を抑えるコツ

オフショアの人月単価は国内より大きく低く、当社の公開単価は実務3年目安で1,500USD(約22.5万円・1USD=150円換算の目安)、市場相場の約1/2(当社調べ)です。

当社の公開単価は次の通りです。

※市場相場は当社調べ。円表記は1USD=150円での換算目安で、体制やスキルにより変動します。日本人PMがフロントに立つ2〜3人月の最小構成で月額約80万円〜が目安です。

費用を抑えるコツは、主に次の3つです。

• 必須機能と将来機能を分ける:初回リリースの範囲を絞り、後から足す
• 内訳と範囲を同じ物差しで比較する:安い見積もりは、テストや保守が含まれていないことが多い
• 中間マージンのない体制を選ぶ:多重下請けに近い構造では、単価に中間コストが乗る

当社が相場の約1/2で提示できるのは、グループの人材紹介事業が持つ2,000名以上のIT人財データベースから直接アサインし、中間マージンが乗らないためです。

同じ仕様で見積もりが2倍違うとき、主な理由は技術力の差ではなく中間マージンの構造にあります。

外注の進め方——発注前の準備から検収までの7ステップ

「頼んだ後、自分たちは何をすればよいのか」——外注は、開発会社に任せる部分と発注側が握る部分に分かれます。

ここでは発注前の準備、依頼から検収までの流れ、開発中に発注側がすることを順に示します。

発注前に整理すること

相談の前に、次の4点を整理しておくと見積もりの精度が上がります。

• 目的と課題:誰のどの業務を、どう変えたいか
• 予算と時期:上限額と、いつまでに使い始めたいか
• 必須機能と将来機能:初回リリースに必要なものと、後回しにできるもの
• 現状の資料:業務フロー、既存システムの画面、扱うデータの一覧

逆に、ここが曖昧なまま相談すると、見積もりも曖昧になります。

依頼から検収までの流れ

1. 相談・見積もり依頼:2〜3社に目的・予算・時期を伝える
2. 要件定義:画面・機能・データを開発会社と一緒に固める
3. 見積もり比較・契約:工数の内訳と範囲を比較し、請負か準委任か、検収基準・変更管理・権利を決めて契約する
4. 設計・実装:開発会社が設計書を作り実装する。発注側は定例で進捗と設計を確認する
5. テスト・受け入れテスト:開発会社のテスト後、発注側が検収基準に沿って動作を確認する
6. 検収・リリース:合格で納品完了、公開
7. 保守・運用・改善:不具合対応と改善を保守契約または準委任で続ける

期間は、機能数、連携する外部システムの本数、そして発注側の意思決定の速さで大きく変わります。月数の一般的な目安として流通している数字は開発会社の独自集計しかなく、公的統計のような一次資料が存在しないため、ここでは示していません。相見積もりを取るときは、同じ作業範囲でスケジュールも出させて比べてください。

開発中に発注側がすること

• 定例で進捗と設計を確認し、判断を先延ばしにしない
• 仕様変更は変更管理(CR)の手続きで扱い、口頭の追加を作らない
• 検収基準に沿って受け入れテストを行い、不具合は再現手順を添えて戻す

2018年からベトナムで開発と採用の現場に立ってきましたが、揉める案件は例外なく「決める人が決めない」案件です。

発注側の判断者を1人決めておくことが肝心です。

失敗しない外注先の選び方——価格以外で見る項目

「どこに頼めば失敗しないのか」——見積もりが出そろった後に残る問いです。

外注先は価格ではなく、体制・実績・契約の透明性で選びます。評価軸をさらに細かく分解した「システム開発会社 選び方」の記事も、比較表を作るときの土台になります。

確認すべき項目

• 同種の開発実績:自社と近い業種・規模の案件を作った実績があるか
• 要件定義から伴走できるか:相談に乗れるPMがいるか、要件整理から手伝えるか
• 開発体制:PM・エンジニアの役割と人数、レビューの仕組みが明確か
• 見積もりの透明性:工数と単価の内訳、含まれる範囲が示されるか
• 仕様変更時のルール:変更管理の手続きと費用の扱いが決まっているか
• 納品後の保守体制:不具合対応と改善の窓口があるか
• コミュニケーション:日本語の窓口、定例の頻度、ドキュメントの言語

人材紹介の仕事で日系企業約100社と付き合ってきましたが、良い会社ほど「できないこと」を先に言います。

すべてを「できます」と言う会社は要注意です。

契約形態と成果物の権利

仕様と納期が明確なら請負契約、要件が動くなら準委任契約が基本です。責任範囲と報酬の決まり方の違いは、「準委任 請負 違い」の記事で整理しています。

どちらの契約でも、成果物とソースコードの権利帰属、設計書などのドキュメントの納品、契約不適合責任の期間を契約で確認します。

ここが曖昧だと、他社へ乗り換えられないベンダーロックの状態になります。

見積もりを比較するときは、金額の前に「工数の内訳」「単価の根拠」「含まれる範囲(テスト・ドキュメント・保守初期対応)」の3点をそろえて並べます。

同じ物差しで並べて初めて、価格差の理由が技術力なのか、範囲の狭さなのか、中間マージンなのかが見えてきます。

請負型とラボ型の使い分け

• 請負型が向く:仕様と納期が明確/プロジェクト単位で予算を確定したい/完成物の検収で管理したい
• ラボ型が向く:要件が固まりきらない/継続的な開発体制が必要/優先順位を柔軟に変えたい

当社では両方を提供しており、エンジニア1名からのラボ型は最短2週間で開始でき、ミスマッチ時は1か月単位のリプレイスメント保証で交代できます。

固める部分は請負、変える部分はラボ型、という組み合わせが基本の型です。

オフショア(ベトナム)に外注する場合の注意点

「オフショアは安いが、品質と意思疎通が不安」——3社で見積もりを比較すると、必ず出る論点です。

当社はベトナムで開発会社を運営していますが、この不安は正しく、対策は体制で打てます。

品質担保の体制

品質は国ではなく体制で決まります。

確認すべきは、次の3つの仕組みが標準化されているかです。

• 設計段階でのPMのレビュー(仕様の認識ずれを上流で防ぐ)
• Gitのプルリクエストによるコードレビュー
• リリース前のエンジニアとPMによるダブルチェック

当社はこの3点を全案件で標準化しており、体制のない会社に安さだけで頼むのは失敗のもとです。

コミュニケーションと時差

日本語N1〜N2レベルのブリッジSEまたは日本人PMが窓口に立てば、発注側に英語は不要です。

ベトナムとの時差は2時間で、日本の午前中にベトナム側の朝の定例を置くことができ、日中の稼働時間がほぼ重なります。

チャットでの日次のやり取り、週次の定例、稼働報告の3つで進捗を可視化すると、非常駐でも状況がつかめます。

契約と支払い

準拠法と管轄、契約通貨と為替、支払方法(海外送金の要否)、知的財産の帰属、データの取り扱いを契約前に確認します。

当社は日本法人(株式会社TALENTBASE JAPAN)との契約で海外送金が不要な形にしており、国内取引と同じ運用で進められます。

まずは現在の要件と予算をお聞かせください。

同等品質でどこまで下げられるか、体制を仮組みして概算でお答えします。

【FAQ】システム開発の外注に関するよくある質問

システム開発の外注について、当社がよくいただく質問に結論から回答します。

個別の状況により異なる点は、無料相談で具体的にお答えしています。

外注費用はいくらかかりますか?

人月単価×工数で決まります。

国内の規模別の金額は一次統計がないため、同じ作業範囲で複数社から見積もりを取って比べるのが確実です。当社の公開単価は実務3年目安で1,500USD(約22.5万円・1USD=150円換算の目安)、市場相場の約1/2(当社調べ)です。

外注と内製はどちらがよいですか?

専門技術がなく期限がある開発は外注、継続的に改善する主力サービスは内製が基本です。

内製の前段階として、外部の専属チーム(ラボ型)を使う方法もあります。

相談前に何を準備すればよいですか?

目的と課題、予算と時期、必須機能と将来機能の一覧、現状の資料の4点です。

この4点があれば、見積もりの精度が大きく上がります。

何社に見積もりを取ればよいですか?

2〜3社が目安です。

金額だけでなく、工数の内訳と含まれる範囲を同じ物差しで比較してください。

オフショアに外注しても品質は大丈夫ですか?

体制次第です。

設計レビュー・コードレビュー・リリース前のダブルチェックが標準化され、日本語で意思疎通できる窓口がある会社なら、国内と同等の品質が目安。

まとめ: システム開発の外注は「発注側が握る3点」で結果が決まる

システム開発の外注は、専門技術と開発リソースが社内にない企業にとって現実的な手段です。

この記事の要点は次の3つです。

• 外注すべきか:専門技術がなく期限があるなら外注、継続的に改善する主力サービスは内製。中核は内製、周辺と立ち上げは外注という組み合わせが実務の型
• 費用と進め方:費用は人月単価×工数。国内の規模別の金額は一次統計がないため同じ作業範囲で相見積もりを取って比べる。当社の公開単価は実務3年目安1,500USD(約22.5万円・1USD=150円換算の目安)で市場相場の約1/2(当社調べ)。発注前に目的・予算・必須機能・資料を整理し、要件定義と検収を自社で握る
• 選び方:価格ではなく実績・伴走・体制・見積もりの透明性・契約(権利・変更管理)で選ぶ。オフショアは品質担保の体制と日本語の窓口、契約・支払いの形を確認する

丸投げを避け、内訳と範囲を同じ物差しで比較すれば、失敗の多くは防げます。

自社の案件でいくらになるかは、必須機能を仮置きして概算するのが最も早く正確です。

現在の体制と要件をお聞かせください。同等品質でどこまで下げられるか、概算見積もりでお答えします。