システム開発の外注はどう進める？費用相場と発注の流れ、失敗しない会社の選び方
業務システムを新しく作りたい、既存のシステムを刷新したい。社内に開発できる人材がいない場合、外部の会社に委託することになります。
ただ、見積もりを取っても金額が妥当なのか判断できない、何を伝えればよいのかわからないという声は多く聞きます。外注費用が読めない原因の多くは、開発会社の価格設定ではなく、発注前に論点が整理されていないことにあります。
この記事では、外注と内製の使い分け、外注先の種類、費用の相場と内訳、発注から納品までの流れ、要件定義の勘所、よくある失敗と対策、契約時の確認事項までを順に整理します。
| 確認したいポイント | 結論 | 詳細 |
|---|---|---|
| 費用相場はいくら？ | 規模により100万〜数千万円 | 費用の大半は人件費。人月単価に工数を掛けた額が土台で、開発方法と連携数で大きく変わる。 |
| 外注先はどう選ぶ？ | 同業種の実績と内訳の粒度 | 価格だけで選ばない。見積書の内訳が細かく、前提と除外事項が書かれているかを見る。 |
| 失敗の原因は？ | 要件が曖昧なまま発注 | 開発の遅延の多くは要件定義に原因がある。決めるべきことを発注側が決められるかが分かれ目。 |
| 費用を抑えるには？ | 最低限の機能から始める | 必要最小限で作り、使いながら広げる。既製品で足りる部分は開発しない判断も有効。 |
この記事でわかること
- 外注と内製の使い分けと、外注先4種類の選び分け
- 費用の内訳と人月単価、開発方法別・規模別の相場
- 社内の要件整理から検収までの発注の流れ
- 要件定義でつまずかないために発注側が担うこと
- よくある失敗の型と、費用を抑える具体的な方法
作りたいシステムの要件整理から相談したい方へ。
→ 無料相談フォームから、現在の業務と実現したいことをそのままお送りください。
外注と内製の使い分け
システム開発は、工程の全部または一部を外部に委託する外注と、自社の要員で開発する内製に分かれます。
どちらか一方を選ぶ必要はありません。工程ごとに担当を決めれば、両者は自然に混ざります。
それぞれの特徴から整理します。
外注のメリット
必要なスキルを持つ体制をすぐに確保でき、開発の期間を短縮できます。エンジニアの採用や育成を待つ必要がありません。
開発会社は過去の案件で蓄積した手法や部品を持っているため、ゼロから組み立てるより早く形になります。品質面でも一定の水準が期待できます。
費用も契約の時点で見通せます。社内で人を抱えるのと違い、案件が終われば支出も終わります。
外注のデメリット
最大の問題は、システムの中身が社内に残りにくいことです。改修が必要になるたびに委託先へ依頼することになり、費用も期間も相手の状況に左右されます。
ドキュメントが不十分だと他社への切り替えも難しくなり、結果として価格交渉の余地も失われます。
また、業務を最もよく知っているのは自社の担当者です。丸投げすると、実態と合わないシステムができあがります。
内製が向いているケース
対象が一つの部署に閉じていて、規模も小さく、社内に開発できる人がいる場合は、自社で作ったほうが早く安く済みます。
また、頻繁に仕様を変えたい業務や、自社の競争力に直結する領域は、内製に寄せる価値があります。改善を自分たちのペースで回せるためです。
ただし、人材の確保と育成には時間がかかります。今すぐ必要なものを内製で作ろうとすると、間に合いません。
一部だけを外注する形
要件定義は自社で行い実装だけ委託する、設計まで依頼して実装は社内で行う、といった分け方ができます。
人手が足りないだけであれば、準委任契約でエンジニアに参画してもらい、自社の体制の中で進める方法もあります。この場合、管理と判断は自社が担う前提になります。
自社に何が足りないのかを整理してから、補う部分だけを外部に求めるほうが費用は抑えられます。
人員の確保という観点から検討する場合は、SES会社の仕組みと選び方を解説した記事もあわせてご覧ください。
関連記事：システム開発の外注は丸投げでいい？起きるトラブルと発注側が最低限やるべきこと
外注先の種類と選び分け
委託できる相手にはいくつかの種類があり、それぞれ得意な規模と領域が違います。
代表的な四つを整理します。
大手システムインテグレーター
大規模なシステムの企画から設計、開発、運用までを一括で請け負う会社です。プロジェクト全体の管理体制が整っており、複数部署にまたがる案件にも対応できます。
品質管理の仕組みや、障害時の体制が確立している点が利点です。基幹システムの刷新など、止められないシステムを扱う場合に選択肢になります。
一方で単価は高く、小規模な案件では費用に見合わないことがあります。実際の開発が下請けに回る構造も一般的です。
中小の受託開発会社
数十名規模で開発を請け負う会社です。単価が比較的抑えられ、担当者との距離が近いため、細かい調整がしやすくなります。
特定の業種や技術領域に強みを持つ会社も多く、自社の課題に近い実績があれば要件定義の時間も短くなります。
ただし、体制の規模には限りがあります。大規模な案件や、24時間の保守が必要な案件では対応範囲を確認してください。
オフショア・ニアショア開発
海外や国内の地方拠点を活用する方法です。単価を抑えられる点が最大の利点になります。
その一方で、仕様の伝達と品質管理に工数がかかります。要件が固まっている工程に限定して使うと効果が出やすくなります。
ブリッジ役となる担当者がいるかどうかで、進めやすさが大きく変わります。
フリーランス
小規模な開発や、特定の技術に絞った作業であれば、個人に依頼する選択肢もあります。費用を抑えられ、着手も早くなります。
ただし一人体制のため、途中で離脱したときのリスクがあります。長期の保守が必要なシステムには向きません。
秘密保持と成果物の権利の扱いは、個人相手でも必ず書面にしてください。
どの種類の依頼先が合うか、比較の観点を資料で確認したい方へ。
→ 資料請求フォームから、開発体制づくりの進め方をまとめた資料をお受け取りいただけます。
関連記事：AIエージェントの進化形！マルチエージェントシステムとは？仕組み・事例・開発の全て
費用の相場と内訳
金額そのものより、何にいくらかかるのかという構造を把握しておくことが大切です。構造がわかれば、見積もりの妥当性を自分で判断できます。
順に整理します。
費用を構成する4つの要素
システム開発の費用は、人件費、プロジェクト管理費、設備費、保守運用費に分かれます。
人件費は、エンジニア、プロジェクトマネージャー、デザイナーなどの費用です。必要な技術が高度になるほど高くなります。管理費は進捗や課題の管理にかかる費用で、大規模になるほど比率が上がります。
設備費はサーバーやネットワーク機器、ソフトウェアのライセンス費用です。クラウドを使う場合は月額の利用料になります。
人月単価の考え方
人件費は、人月単価に工数を掛けて算出されます。人月単価は担当者の職位や技術領域によって幅があり、上流工程を担う層ほど高くなります。
見積書を受け取ったら、金額を単価で割り戻してみてください。想定されている工数が見えてきます。金額に納得できない場合、工数が過剰なのか単価が高いのかを切り分けられます。
誰がどの割合で稼働するのかを明記してもらうと、この確認がしやすくなります。
開発方法による違い
既存のパッケージやクラウドサービスを導入する場合、初期費用は抑えられますが月額の利用料が発生します。汎用的な機能が最初から備わっているため、導入までの期間も短くなります。
完全に一から作るスクラッチ開発は高額になりますが、自社独自の業務フローに合わせた仕組みを構築できます。
両者の中間として、パッケージを土台に必要な部分だけ作り込む方法もあります。まずは既製品で足りるかを確認してから判断してください。
規模別の目安
小規模な業務システムであれば100万円台から、部署をまたぐ規模で数百万円から1,000万円台、基幹システムの刷新など全社規模になると数千万円以上が一つの目安になります。
費用を押し上げる主な要因は、連携する既存システムの数、利用ユーザー数、求められるセキュリティ水準です。ユーザー数が増えるほど構成も複雑になります。
まずは必要最低限の機能で作り、運用しながら追加していく段階的な進め方が推奨されます。
保守運用にかかる費用
稼働後は、障害対応、問い合わせ対応、小規模な改修、サーバーの利用料が継続的に発生します。年額で初期費用の15%前後を見込む考え方が広く使われています。
見積もりを比較する際は、初期費用だけでなく、3年程度の総額で並べてください。初期が安くても保守が高ければ逆転します。
保守の範囲に何が含まれるのかも、契約前に必ず確認してください。
サーバーやネットワークの整備もあわせて検討する場合は、インフラ構築の手順と設計のポイントをまとめた記事が参考になります。
関連記事：AI在庫管理で利益を最大化｜中小企業向け導入ガイドとシステム選定の要点
発注から納品までの流れ
進め方を把握しておくと、社内の調整もしやすくなります。一般的な流れを五つの段階に分けて説明します。
順に見ていきます。
社内で要件を整理する
開発会社に相談する前に、解決したい課題、対象業務、現在の手順、想定する利用者数、予算の上限、稼働させたい時期を整理します。
この段階で完璧な仕様書は必要ありません。ただし、何を解決したいのかが曖昧なままだと、提案も見積もりも精度が上がりません。
現行業務のフローを図にしておくだけでも、初回の打ち合わせの質が変わります。
提案依頼書を作り、相見積もりを取る
自社の状況、依頼したい範囲、予算感、スケジュールを一つの文書にまとめます。これを複数社に同じ内容で渡すことで、同じ前提での提案を受けられます。
口頭で説明するだけでは、会社ごとに理解がずれて比較になりません。A4で数枚あれば十分に機能します。
比較は2社から3社に絞るのが現実的です。数を増やしすぎると、比較そのものに時間を取られます。
契約を結ぶ
システム開発では、成果物の完成に責任を負う請負契約と、作業時間に対して支払う準委任契約があります。
要件が固まっている工程は請負、仕様を探りながら進める工程は準委任というように、工程ごとに使い分けるのが一般的です。すべてを一括で請負にすると、開発側はリスクを織り込んだ見積もりを出すことになります。
契約前に、成果物の定義と検収の基準を明確にしておいてください。
開発とレビューを進める
設計、実装、テストと進みます。この間、定期的に進捗と成果物を確認する場を設けてください。完成間際に初めて見て、想定と違うと気づくのが最も避けたい状況です。
画面の設計や動く試作を早い段階で確認できると、認識のずれを減らせます。
仕様変更が発生した場合は、費用と期間への影響をその都度確認し、記録に残してください。
検収して運用へ引き渡す
納品されたシステムが、契約で定めた要件を満たしているかを確認します。この検収の基準が曖昧だと、後で揉める原因になります。
実際の業務データを使って、現場の担当者にも確認してもらってください。開発側のテストだけでは、業務上の不都合は見つかりません。
あわせて、設計書、操作手順書、運用手順書の受け取りも確認します。
要件の整理や依頼先の比較について、具体的に相談したい方へ。
→ 無料相談フォームから、検討中の内容をお聞かせください。
要件定義でつまずかないために
外注が失敗する原因の多くは、技術力ではなく要件定義にあります。ここに時間をかけるかどうかで、結果が大きく変わります。
押さえておきたい四つの点を挙げます。
要件を決める責任は発注側にある
システムの要件を定義する責任は、そのシステムを使ってビジネスに貢献する発注側にあると考えられています。開発会社は技術的な実現方法を提案できますが、何を実現したいかは決められません。
システム開発の遅延は、その過半が要件定義の失敗に起因するとも言われています。要件定義で発生しやすい問題と解決の勘どころを整理した資料が公開されており、発注側の担当者にとって参考になります(IPA『ユーザのための要件定義ガイド 第2版』)。
この工程を開発会社に丸投げすると、できあがったものが業務に合わないという結果になります。
現場の担当者を巻き込む
情報システム部門や管理職だけで要件を決めると、実際の業務との差が出ます。日々その業務を担当している人に参加してもらってください。
例外的な処理や、担当者が独自に行っている作業は、ヒアリングしないと表に出てきません。こうした部分が後から仕様漏れとして問題になります。
使う人が関わったシステムは使われます。この差は非常に大きくなります。
非機能の要件を忘れない
画面や帳票といった機能面だけでなく、応答速度、同時利用者数、稼働時間、バックアップ、セキュリティといった条件も要件です。
これらを決めずに進めると、動くけれども遅い、障害時に復旧できないといった問題が稼働後に表面化します。
運用や移行、総合テストの進め方についても、要件として定義しておいてください。
決められないことを明示する
すべてを最初に決められるとは限りません。決まっていない項目を隠すのではなく、いつまでに誰が決めるのかを明示して合意してください。
曖昧なまま進めるのは、揉め事を避けるための配慮に見えて、実際には後工程のコストと摩擦を先送りしているだけです。
未決事項を一覧にして管理する仕組みを、開発会社と共有しておくと進めやすくなります。
社内の推進体制づくりについては、情報システム部門の体制づくりを解説した記事をご覧ください。
よくある失敗と対策
外注でつまずく型は、ある程度決まっています。事前に知っておくだけで、かなり避けられます。
五つ挙げます。
価格だけで選んでしまう
最も多い失敗です。安すぎる見積もりは、テストや保守、運用といった後で効いてくる費用が抜けているだけということがあります。
判断は総額の大小ではなく、内訳の粒度と、前提や除外事項が明記されているかで行ってください。何が含まれていないのかを確認することが重要です。
見積もりの内訳を出すことを渋る会社は、その時点で候補から外して構いません。
要件が曖昧なまま発注する
完成したものが現場で使えなかった、という失敗はここから生まれます。曖昧な部分は、開発側が都合よく解釈するか、リスクとして金額に上乗せされます。
要件が固まっていない段階では、まず調査と要件定義だけを分けて依頼し、内容が見えてから実装の契約を結ぶ順番にしてください。
急ぐ気持ちから一括契約に踏み切ると、結果的に手戻りで時間を失います。
追加要望が積み上がる
開発の途中で、あれもこれもと要望が増えるのはよくあることです。ただし、追加のたびに費用と期間は増えます。
最初のリリースに含める範囲を決め、それ以外は次回に回すという判断基準を、社内で先に合意しておいてください。
変更管理の手順を開発会社と決めておくと、費用の見通しも立てやすくなります。
保守と運用を考えていない
納品後に誰が運用するのかを決めないまま進めると、障害が起きても対応できません。保守契約の有無、対応時間、連絡経路を発注の段階で決めておいてください。
運用にかかる費用も、初期費用と合わせて予算化しておく必要があります。
社内の担当者を開発中から関わらせておくと、引き継ぎがスムーズになります。
ドキュメントが残らない
設計書や仕様書が納品されず、何がどう作られているかを誰も説明できない状態は、将来の改修を著しく難しくします。
納品物としてドキュメントを契約に明記してください。他社への切り替えが可能な形で残してもらうことが、長期的な費用と自由度を守ります。
あわせて、開発中に決めた仕様変更の記録も残しておいてください。
失敗を避ける進め方や比較の観点をまとめた資料をご用意しています。
→ 資料請求フォームからご覧いただけます。
費用を抑える方法
費用を抑えるとは、安い会社を探すことではありません。同じ効果をより少ない工数で得られるように、範囲と進め方を設計することです。
効果の大きい四つを挙げます。
必要最低限の機能から始める
最初から作り込みすぎないことが、結果的に総額を最も大きく左右します。必要最小限の機能で作り、使いながら段階的に広げてください。
この進め方であれば、実際の反応を見ながらフェーズごとに投資判断ができ、使われない機能への過剰な投資を防げます。
あったら便利という機能は、最初のリリースには入れないでください。
既製品で足りる部分は開発しない
同じことができるパッケージやクラウドサービスがないかを、必ず先に確認してください。月額数万円のサービスで足りる業務に、数百万円をかけて開発する例は少なくありません。
既製品で8割満たせるなら、残りを業務側の運用で吸収する判断も現実的です。業務をシステムに合わせるほうが安く済む場面は多くあります。
既製品を土台に、足りない部分だけを作る構成も有効です。
工程を分けて契約する
要件定義、設計、実装と工程ごとに契約を分けると、各段階の終わりに継続するかどうかを判断できます。途中で方向を変えても損失が限定されます。
契約の手続きは増えますが、要件が固まらないまま実装に進んでしまうリスクを避けられます。
段階契約に応じるかどうかは、依頼先を選ぶ判断材料にもなります。
発注側の準備で工数を減らす
現行業務の資料、扱うデータの一覧、帳票の様式などを事前に用意しておけば、開発会社が調査に費やす時間が減ります。その分が費用に反映されます。
窓口を一本化し、質問への回答を早く返すことも、期間の短縮に直結します。回答待ちで止まる時間は、そのまま費用になります。
社内の意思決定者を明確にしておくことも、進行を早めるうえで効果があります。
AIを組み込んだ開発を検討している場合は、AI受託開発の範囲と進め方をまとめた記事もご覧ください。
契約と取引のルール
金額に合意しても、条件が曖昧なままだと後で認識のずれが生じます。契約前に確認すべき点を整理します。
三つの観点で見ていきます。
契約書で確認する項目
成果物の定義、検収の基準と期間、瑕疵や不具合への対応、支払いの条件、契約期間と解約の取り決め。この五つは必ず確認してください。
特に検収の基準は、何をもって完成とするのかを具体的に書いておく必要があります。曖昧なまま進めると、支払いの段階で揉めます。
仕様変更が発生した場合の手続きと費用の扱いも、あらかじめ決めておいてください。
委託取引に関するルール
システム開発の委託は、発注側と受注側の規模によって、代金の支払いや発注時の書面交付についてのルールが適用される場合があります。
2026年1月から、従来の下請法は中小受託取引適正化法として施行され、対象となる取引や事業者の範囲が広がりました。委託する側の義務や禁止行為も整理されています(中小企業庁『2026年1月施行 下請法は取適法へ 改正ポイント説明会』資料)。
自社が委託事業者に該当するかどうかは規模の要件で決まります。該当する場合は書面の交付や支払期日に定めがあるため、法務部門や専門家に確認してください。
成果物の権利の帰属
開発したプログラムやドキュメントの権利が、発注側と開発側のどちらに帰属するのかを確認します。ここが曖昧だと、後から自社で改修したいときや、他社に引き継ぎたいときに支障が出ます。
開発会社が既に持っていた部品を流用する場合、その部分の権利は開発会社に残るのが一般的です。どこまでが自社の権利になるのかを明確にしておいてください。
ソースコードの受け取りについても、契約時に取り決めておく必要があります。
内製化を並行して進めたい場合は、DX人材の育成と内製化の進め方をまとめた記事が参考になります。
まとめ
システム開発の外注費用は、規模により100万円台から数千万円以上まで幅があります。費用の大半は人件費で、人月単価に工数を掛けた金額が土台になります。既製品の活用かスクラッチ開発かでも大きく変わります。
外注が失敗する原因の多くは、技術力ではなく要件定義にあります。システムの要件を決める責任は発注側にあるという前提を理解し、現場を巻き込んで要件を固めてください。
依頼先を比較する際は、総額の大小ではなく、見積もりの内訳の粒度と、前提や除外事項が明記されているかで判断します。安い見積もりは、範囲が狭いだけということが少なくありません。
費用を抑える王道は、必要最低限の機能で小さく始め、段階的に広げることです。あわせて、成果物の定義と検収の基準、ドキュメントの納品、権利の帰属を契約段階で明確にしておけば、大きなトラブルはかなり避けられます。
システム開発の外注について、自社の要件に合わせて相談したい方へ。
→ 無料相談フォームから、実現したい内容と現在の状況をお送りください。担当者がご案内します。
