システム開発を外注する前に｜費用相場・多段階契約・発注者側の準備と会社の選び方

同じ要件を伝えたのに、見積もりが3社で倍近く違う。着手後に「それは要件に入っていません」と言われて追加費用が出る。完成したが現場で使われない。システム開発の外注で起きるトラブルは、驚くほど型が決まっています。

原因の多くは、開発会社の技術力ではありません。発注前に論点が整理されていないことです。曖昧さを残したまま進めるのは、揉め事を避ける優しさではなく、後工程のコストと摩擦を先送りしているだけです。

本記事では、外注と内製の判断から、外注先の種類、費用の内訳と相場、工程ごとに契約を分ける考え方、発注側が準備すべきこと、会社の選び方、そしてよくあるトラブルまでを整理します。発注担当者が社内で説明できる状態を目指しています。

確認したいポイント	結論	詳細
システム開発は外注と内製どちらが良い？	短期間で形にするなら外注が現実的	自社でエンジニアを育成せずに開発できます。一方でノウハウは社内に残りにくく、変更のたびに費用と時間が発生します。
外注費用はどう決まる？	人月単価×工数。人件費が全体の約8割	ほかにプロジェクト管理費、設備費、保守運用費が乗ります。同じ要件でも会社によって数十%の価格差が生じます。
契約は1本でまとめるべき？	工程ごとに分ける多段階契約が基本	要件定義は準委任、設計から開発・テストは請負が目安です。要件定義が終わった時点で開発費を見積もり直します。
トラブルを防ぐ鍵は？	発注側が協力義務を果たすこと	目的、現行業務、意思決定者を発注側が示さないとプロジェクトは進みません。ベンダの管理義務と両輪で機能します。

この記事でわかること

• 外注と内製を分ける判断軸と、外注先4タイプの向き不向き
• 費用の内訳と人月単価の考え方、相見積もりで条件を揃える方法
• 工程ごとに契約を分ける多段階契約と、請負・準委任の使い分け
• 発注側が事前に用意すべき材料と、協力義務という考え方
• 開発会社を選ぶ5つの観点と、よくあるトラブル5つの回避策

外注すべきか、どこまでを外に出すか。事業相談の初回は無料で対応しています。

システム開発は外注すべきか、内製すべきか

外注先を探し始める前に、そもそも外に出すべき仕事なのかを確認します。この判断を飛ばすと、外注しても社内に何も残らないか、無理な内製で人が疲弊するかのどちらかになります。

外注のメリット

最大の利点は立ち上がりの速さです。自社でエンジニアを採用・育成しなくても、専門知識を持つ体制をすぐに確保できます。採用に半年から1年かかることを考えると、時間そのものを買っているという見方が正確です。

他社の類似案件で得た知見が入る点も価値になります。よくある落とし穴を先回りして避けられるため、自社だけで進めるより手戻りが減ります。

外注のデメリット

ノウハウが社内に蓄積しにくいのが最大の弱点です。仕様変更や機能追加のたびに費用と時間が発生し、依存が強まる構造になります。誰も中身を説明できないシステムが残ると、将来の乗り換えも難しくなります。

加えて、発注側の稼働はゼロにはなりません。要件の確認、意思決定、テストへの参加は必ず発生します。ここを見込まずに計画すると、確認待ちでプロジェクトが止まります。

判断軸は時間軸と、その業務が競争力の源泉かどうか

半年以内に成果が必要なら外注が現実解です。逆に、その業務が自社の競争力そのもので、継続的に改善し続ける前提なら、内製に寄せる意味が出てきます。

現実的な着地点は、外部が主導して立ち上げ、運用フェーズで社内に移していく段階的な移管です。契約時点で移管を前提にしておくことが条件で、後から言い出しても対応してもらえないことがあります。

関連記事：外注ゼロでAIを回す会社がやっている、内製化5段階のステップ

外注先の種類と向き不向き

「システム開発会社」とひとくくりにされますが、契約の形も責任範囲も違います。何を外に出したいのかで、選ぶべき相手が変わります。

受託開発会社（請負）

要件を渡し、完成した成果物を受け取る形です。完成責任を負ってもらえるため、発注側の管理負荷は比較的軽くなります。仕様が固まっている案件に向きます。

一方で、開発途中の仕様変更には追加見積もりが必要になり、柔軟性は下がります。作りながら決めたい案件とは相性が良くありません。

技術者の常駐・準委任型

エンジニアに参画してもらい、時間と体制に対して費用を払う形です。仕様が固まっていない段階や、社内メンバーと一緒に進めたい場合に向きます。

注意点は、成果物の完成責任は負わないという点です。進行管理を発注側が担う前提になるため、社内にプロジェクトを見られる人が必要になります。

ラボ型・オフショア開発

一定期間、専任チームを確保する形です。人月単価を抑えられる場合があり、継続的に開発量がある企業に向きます。仕様が明確な実装工程では効果が出ます。

反面、仕様が固まらない上流工程ではコミュニケーションコストが単価差を上回ることがあります。要件定義と受け入れは国内で持ち、実装の一部を切り出す形が現実的です。

フリーランス

小規模な開発や、特定技術のスポット対応であれば有効です。費用を抑えられ、着手も速くなります。一方で体制が個人に依存するため、長期運用や機密性の高い案件には向きません。

選び分けの基準は「仕様の確定度」

整理すると、仕様が固まっているなら請負型、固まっていないなら準委任型という基準に集約されます。分からないものを請負で発注すると、追加見積もりの連続になります。

外注と内製の切り分け、依頼先の選定基準づくりからご相談いただけます。事業相談の初回は無料です。

システム開発の外注費用と相場の見方

見積書の金額そのものより、内訳の粒度と、前提・除外事項が書かれているかを見てください。ここが判断の基準になります。

費用の内訳は大きく4つ

1つ目は人件費で、エンジニア、プロジェクトマネージャー、デザイナーなどの費用です。システム開発費用のおよそ8割を占めます。必要な技術や専門知識が高度になるほど単価が上がります。

2つ目はプロジェクト管理費で、進捗管理、課題管理、関係者調整にかかる費用です。規模が大きいほど比率も金額も増えます。3つ目は設備費、4つ目が保守・運用費です。

人月単価×工数という計算構造

費用は基本的に、人月単価に必要な工数を掛けて算出します。関わる人数が多く、期間が長いほど金額は素直に増えます。したがって、費用を下げる方向性は工数を減らすか、単価の高い人が必要な範囲を減らすかの2つしかありません。

機能を削る、既存のパッケージやSaaSで代替する、段階的に開発する。この3つが現実的な打ち手です。まず必要最低限の機能で作り、運用しながら追加していく進め方が推奨されるのはこのためです。

利用者数と非機能要件が金額を動かす

見落とされやすいのが非機能要件です。利用ユーザー数が増えるほどサーバー構成やセキュリティ対策が複雑になり、開発コストが上がります。可用性、応答速度、監査ログの要件も同様です。

画面数や機能数だけで見積もりを比較すると、この部分の差が見えません。同じ機能でも、想定利用者数が10人と1万人では別の設計になります。

相見積もりは条件を揃えてから取る

同じ要件でも、開発会社によって数十%以上の価格差が生じることがあります。だからこそ複数社から見積もりを取る価値がありますが、できるだけ同じ要件書を各社に提示し、比較条件を揃えることが前提になります。

比較するのは価格だけではありません。開発範囲、保守範囲、納品物、サポート内容、将来の拡張性まで含めて評価してください。安すぎる見積もりは、テストや保守運用といった後で効いてくる費用が抜けているだけということがあります。

関連記事：そのAI、何ヶ月で元が取れますか。投資回収を3分で見える化する計算式

契約の型。多段階契約と請負・準委任の使い分け

システム開発のトラブルは、契約の設計で相当程度防げます。情報処理推進機構（IPA）が公開しているモデル契約は、その考え方を整理した公的な参照点になります。

工程ごとに契約を分ける「多段階契約」

IPAの「情報システム・モデル取引・契約書」は、開発工程を1本の契約にまとめず、工程ごとに分ける多段階契約を軸としています。基本契約書と個別契約書の二層構造で運用する形です。

多段階契約は、要件定義が終わった時点で開発部分をあらためて見積もり直すことを前提にします。発注側から見ると総額が最初に確定しない不安はありますが、根拠のない金額で全体を確定させるより、結果的にトラブルも無駄なコストも少なくなるという立場です。

出典：IPA 独立行政法人情報処理推進機構「情報システム・モデル取引・契約書」

要件定義は準委任、設計・開発・テストは請負

何を作るかが未確定な要件定義には準委任契約が推奨されます。準委任は善管注意義務を前提とし、成果物の完成責任は負いません。決まっていないものに完成責任を求める契約は、そもそも成立しにくいという考え方です。

一方、内部設計から開発・テストのように作るものが決まっている工程には、完成責任と契約不適合責任を伴う請負契約が向きます。運用・保守は継続的な業務のため、準委任が基本になります。

契約不適合責任の期間を確認する

納品後に見つかった不具合を無償で修正する期間は、民法改正により従来の最長1年から最長10年へと変わりました。開発側の体制計画にも影響するため、契約時に慎重な検討が必要です。

発注側としては、検収の方法と基準、不具合の定義、対応期間をセットで確認しておいてください。ここが曖昧だと、リリース後の対応でもめます。

仕様変更をどう扱うかを先に決める

システム開発では、開発中の要件定義や仕様変更を巡るトラブルが起きやすくなります。変更管理の手続きを契約時に定め、費用と納期をセットで合意する流れを作っておいてください。

特に、仕様変更を前提とするアジャイル型では、この設計が欠かせません。IPAはアジャイル開発を外部委託する際のモデル契約も別途公開しています。担当者同士の口頭合意が正式な契約変更にはならない点にも注意が必要です。

契約形態の選び方、多段階での進め方、変更管理の設計など、発注前段階のご相談も承っています。事業相談以外のご用件もこちらから。

開発手法の選択が、契約と費用を左右する

外注の設計で見落とされやすいのが開発手法です。どう作るかが決まらないと、契約形態も見積もりの粒度も決まりません。

ウォーターフォール型が向くケース

要件定義、設計、実装、テスト、リリースを順に進める手法です。作るものが明確で、途中で大きく変わらない案件に向きます。総額が早い段階で見えるため、予算管理はしやすくなります。

弱点は、途中の変更に弱いことです。テスト段階で認識のずれが判明すると、手戻りが大きくなります。要件定義に時間をかけられる案件でこそ機能する手法です。

アジャイル型が向くケース

短い期間で開発と確認を繰り返し、動くものを見ながら仕様を固めていく手法です。要求仕様が不明確な状態から始める案件や、市場の反応を見ながら育てるプロダクトに向きます。

課題は契約でした。従来の契約形態がこの進め方に対応していないという指摘があり、IPAはアジャイル開発を外部委託する際のモデル契約を別途公開しています。準委任を前提とし、変更をプロセスの中で扱う設計になっています。

小さく作って育てるという第三の選択

最初から全機能を作らず、必要最低限の機能でリリースし、運用しながら追加していく進め方です。初期投資を抑えられ、使われない機能を作るリスクも減ります。

この場合、契約も段階に分けます。第1弾のリリースまでで一度区切り、実際の利用状況を見てから次の範囲を決める。総額は最初に確定しませんが、無駄な機能に払う金額は確実に減ります。

発注側が準備すべきこと。協力義務という考え方

発注側の協力義務と、ベンダのプロジェクトマネジメント義務は、プロジェクト失敗を防ぐ両輪です。丸投げは、契約上も実務上も成立しません。ここで挙げる材料を揃えてから相談してください。

材料1：目的と成功の定義

何のために作るのか、完成後に何がどう変わっていれば成功なのか。業務時間の削減なのか、売上なのか、ミスの削減なのか。指標を1つに絞り、数値で置いてください。複数並べると全部が中途半端になります。

材料2：現行業務とデータの実態

誰がどの作業に何時間使っているか、扱うデータはどこに何件あるか、連携が必要なシステムは何か。この情報がないと、ベンダーは仮定で見積もるしかなく、着手後の追加費用につながります。

材料3：機能の優先順位

全部を最初に作ろうとすると費用が膨らみます。必須、あったほうがよい、なくてもよいの3段階で分けておくと、予算に合わせた調整がその場でできます。この整理は発注側にしかできません。

材料4：意思決定者と社内体制

誰が最終判断をするのか、現場側の窓口は誰か、月にどれくらいの時間を出せるのか。確認待ちはプロジェクト遅延の主要因です。担当者に決裁権がない場合、その上の承認プロセスも含めて共有しておきます。

材料5：予算と期限の考え方

予算を伝えると足元を見られると考える方もいますが、逆です。上限が分かれば、その範囲で何ができるかの提案が返ってきます。予算を隠したまま相見積もりを取ると、比較できない提案が並ぶだけになります。

開発会社を選ぶ5つの観点

価格は判断材料の一つにすぎません。見るべきは、その会社が曖昧さをどこまで構造化してくれるかです。

観点1：同業種・類似業務の実績があるか

同じ業界や類似業務のシステム開発経験があるかを確認します。製造業向けの生産管理システムと小売業向けの販売管理システムでは、求められる知識がまったく異なります。業務の勘所を知っている相手は、要件の抜けを先に指摘してくれます。

観点2：見積もりの内訳と前提が書かれているか

「一式」の見積もりは比較できません。工程ごとに金額と工数が割り振られ、前提条件と除外事項が明記されているかを確認してください。ここを書ける会社は、範囲を握れている会社です。

観点3：保守・運用の範囲が示されているか

リリース後の障害対応、機能追加、インフラ運用をどこまで持つのか。月額いくらで、どの範囲までか。保守範囲の線引きを契約時に文書化しないと、仕様変更をめぐる水掛け論を招きます。

観点4：成果物の権利帰属が明確か

ソースコード、設計書、デザインデータの権利がどちらに帰属するかを条文で確認します。ここが曖昧だと、将来ベンダーを乗り換えたいときに一から作り直しになります。基本契約書に記載されるのが一般的です。

観点5：上流を整理する力があるか

初回の打ち合わせで、業務の流れについて具体的な質問が出るかを見てください。「その機能は本当に必要ですか」と言える相手なら信頼度は高いと考えていいでしょう。受注のために要望をそのまま積み上げる会社とは、後で揉めます。

要件の整理、相見積もりの条件づくり、提案内容の比較まで伴走します。初回の事業相談は無料です。

よくあるトラブルと回避策

外注のトラブルは、技術の難度ではなく進め方の設計で起きています。頻出の5つを挙げます。

トラブル1：要件が曖昧なまま進む

要件が固まらないまま開発に入り、完成したものが現場で使えない。最も多い失敗です。回避策は、要件定義を独立した工程として準委任で発注し、そこで作るものを確定させてから開発を見積もり直すことです。

トラブル2：仕様変更の扱いが決まっていない

変更が発生するたびに、追加費用なのか当初の範囲内なのかで揉める。回避策は、変更管理の手続きを契約時に定め、変更のたびに費用と納期を書面で合意する流れにしておくことです。

トラブル3：検収の基準がない

何をもって完成とするかが決まっておらず、検収で止まる。回避策は、テスト項目と合格基準を契約時に定義することです。誰がいつテストするかまで含めて決めておきます。

トラブル4：現場が使わない

技術的には動いているのに、担当者が従来のやり方を続けている。既存の業務フローに接続されていない、入力の手間が増えた、といった理由がほとんどです。設計段階から現場の担当者を巻き込むことが回避策になります。

トラブル5：安さで選んで結局高くつく

価格だけで選んだ結果、品質が出ない、納期が遅れる、再開発が必要になる。別の会社に依頼し直すことになれば、総コストは倍以上になります。極端に安い見積もりは、含まれていない範囲がないかを必ず精査してください。

関連記事：採用を諦めた中小企業社長が、AIで人手不足を埋めるまで

AI駆動開発で、外注の相場観は変わりつつある

最後に、いま起きている変化に触れておきます。費用が人月で決まる以上、開発体制そのものが変われば相場も変わります。

工数の前提が動いている

AIコーディングツールを開発工程に組み込むと、設計、実装、テストコード作成、レビューの作業時間が短縮されます。同じ機能を、より少ない人月で作れる体制が現実に存在するようになりました。

つまり、過去の相場をそのまま当てはめると、実態より高い金額を受け入れることになりかねません。見積もりを受け取ったら、どういう開発体制で、どの工程にAIを使っているかを聞いてみてください。

関連記事：Claude Codeを30分で使い始める。CLI型AIエージェントの最短セットアップ

検証の回数が増えることの意味

実装が速くなると、作って見せて直すサイクルが回せるようになります。仕様書だけで合意していた部分を、動くもので確認できる。要件の認識ずれという最大のトラブル要因を、前倒しで潰せるということです。

外注先を選ぶとき、この進め方ができるかどうかは差になります。早い段階で動くものを出してくる相手のほうが、結果として揉めません。

関連記事：Claude Codeチーム導入｜社内展開90日ロードマップ

まとめ

システム開発の外注で買っているのは、機能そのものではなく揉めずにゴールへ到達する進め方です。だからこそ、価格の大小より、内訳の粒度と前提の明記で判断してください。

契約は1本にまとめず、工程ごとに分ける多段階契約が基本です。要件定義は準委任、設計から開発・テストは請負、運用保守は準委任。要件定義が終わった時点で開発費を見積もり直す進め方が、結果的にトラブルもコストも減らします。

そして発注側には協力義務があります。目的と成功の定義、現行業務とデータ、機能の優先順位、意思決定者と体制、予算の考え方。この5つを揃えてから相談すれば、見積もりの精度も提案の質も変わります。

LiftBaseは、要件定義から運用まで一気通貫の受託開発に加え、AIを組み込んだ開発体制の構築も支援しています。外注すべきかどうかを判断したい、という段階からのご相談でも構いません。

外注範囲の切り分け、要件の整理、概算費用の試算まで。初回の事業相談は無料です。