システム開発を外部に頼もうと調べ始めると、まず出てくるのが「受託開発」という言葉です。なんとなく「外注のこと」とは分かっても、SESや派遣とどう違うのか、どんな契約で、いくらかかり、どういう流れで進むのかまでは、初めての発注ではイメージしにくいものです。
結論から言うと、受託開発とは「外部の開発会社にシステム開発を委託し、完成した成果物を納品してもらう頼み方」で、契約は成果物に対して報酬を払う請負契約が基本です。この記事では、受託開発の仕組みをSES・派遣・自社開発と並べて整理したうえで、依頼から納品までの流れ、契約と費用で押さえるべき点、失敗しない依頼先の選び方までを、発注側の目線でまとめます。個別テーマは関連記事に詳しく譲り、ここでは全体像を最短でつかめるようにしています。
この記事のポイント
- 受託開発とは成果物の完成・納品に対して報酬を払う請負契約の頼み方
- SESや派遣は労働時間への対価で、指示権や責任の所在が受託開発と異なる
- 流れは相談から要件定義・開発・検収・納品・保守までが基本形
- 契約では著作権の帰属・検収基準・契約不適合責任を発注前に確認する
目次
受託開発とは？仕組みと頼み方の違い
受託開発を理解する近道は、他の頼み方と並べて「何が違うのか」を掴むことです。まずは定義を確認し、そのうえでSES・派遣・自社開発との違い、発注側から見たメリット・デメリットまでを整理します。
受託開発とは何か（請負で成果物を納品）
受託開発とは、発注者が求めるシステムやソフトウェアの開発を外部の開発会社に委託し、完成した成果物を納品してもらう開発の頼み方です。「受託」は業務を請け負って引き受けるという意味で、開発会社は依頼された仕様どおりのものを作り上げ、納期までに納品する責任を負います。
契約形態としては、成果物の完成に対して報酬を支払う請負契約が基本になります。発注側は「何を作ってほしいか」を伝え、開発会社はそれを形にして納める、という役割分担です。裏を返すと、発注側が作りたいものを言語化できていないと、受託開発はうまく機能しません。仕様が曖昧なまま任せると、出来上がったものが想定と食い違い、追加費用や作り直しにつながります。
私の感覚では、受託開発を「お金を払えばいい感じのシステムが出てくる仕組み」と捉えている発注担当者ほど、後で苦労しがちです。実際には、受託開発は「発注側が決めたことを、プロが確実に形にする」頼み方だと考えたほうが、期待値のズレが起きにくくなります。
SES・派遣と受託開発の違い
受託開発と混同されやすいのが、SES（システムエンジニアリングサービス）と派遣です。この3つは「何に対してお金を払うか」と「誰が作業を指示するか」で明確に分かれます。
| 頼み方 | 対価の対象 | 指示・責任 |
|---|---|---|
| 受託開発（請負） | 完成した成果物 | 指示は開発会社。完成責任を負う |
| SES（準委任） | エンジニアの労働・稼働時間 | 指示は開発会社。成果物の完成責任は負わない |
| 派遣 | エンジニアの労働時間 | 指示は発注側（派遣先）が出す |
受託開発は「成果物」に、SESと派遣は「人の稼働時間」に対価を払う点が根本的な違いです。受託開発では発注側がエンジニアに直接作業指示を出すことはできません。指示や進め方は開発会社が管理し、その代わり完成した成果物に責任を持ちます。SESも指示権は開発会社側にありますが、成果物の完成までは保証しません。派遣は逆に、発注側（派遣先）が直接指示を出せる代わりに、成果物への責任は問えません。
「完成したシステムを納めてほしい」なら受託開発、「自社主導で進めたいが人手が足りない」ならSESや派遣、というのが基本の使い分けです。この違いは頼み方選びの土台になるので、契約形態ごとの責任範囲は最初に押さえておくと安心です。
自社開発（内製）との違い
もう一つ比較しておきたいのが、自社で作る「内製（自社開発）」との違いです。受託開発は外部に任せる分、社内に開発人材がいなくても前に進められ、必要なスキルをすぐに確保できます。一方で、開発のノウハウが社内に残りにくく、要件を正確に伝える手間や、社外とのコミュニケーションコストが発生します。
内製は、社内に人材がいれば意思決定や修正が速く、ノウハウも蓄積されます。ただし採用や育成に時間とコストがかかり、規模の大きい開発では社内リソースだけでは回らないこともあります。長く運用して頻繁に改修するシステムは内製寄り、専門スキルが足りない・短納期・スポット的な開発は受託開発寄り、というのが目安です。
内製と外注のどちらが自社に向くかをもう少し踏み込んで判断したい場合は、システム開発を外注するメリット・デメリットと判断基準を解説した記事で、IT人材の有無・開発規模・スケジュールの3点から整理しています。あわせて読むと、受託開発を選ぶべきかどうかの判断がぶれにくくなります。
受託開発のメリットとデメリット
発注側から見た受託開発のメリットは、大きく3つあります。第一に、社内に開発チームを持たなくても、必要なスキルとリソースをプロジェクト単位で確保できること。第二に、契約で納期と工程を決めるため、スケジュール通りに進めやすいこと。第三に、請負契約であれば納品物に対する責任を開発会社が負うため、不具合があっても契約範囲で修正対応を受けられることです。
一方でデメリットもあります。開発のノウハウが自社に蓄積されにくく、将来内製へ切り替えたい場合は契約段階で技術やドキュメントの引き渡しを取り決めておく必要があります。また、開発会社は自社の業務に精通しているとは限らないため、要件を正確に伝えないと仕様とニーズがずれます。費用面でも、外部の利益や管理費が上乗せされるため単価だけを見れば内製より高く見えることがあります。ただし採用・育成・設備のコストや、人材が稼働しない期間のリスクまで含めれば、必要なときだけ使える受託開発のほうが総額で有利になるケースも少なくありません。「外注だから高い・楽になる」と単純に決めつけず、総コストで比較する姿勢が大切です。
受託開発の進め方と費用・契約の基本
受託開発の仕組みが分かったら、次は実際にどう進み、何にいくらかかり、契約で何を確認するかです。ここを押さえておくと、初めての発注でも大きな失敗を避けられます。
依頼から納品までの流れ
受託開発は、おおむね次の流れで進みます。全体像を先に持っておくと、いま自分がどの段階にいるかが分かり、開発会社とのやり取りもスムーズになります。
- 相談・問い合わせ：作りたいものの概要と予算感を伝え、開発会社に相談する
- 要件定義：何を・なぜ作るか、必要な機能や条件をすり合わせて固める
- 見積もり・契約：要件をもとに費用・納期・範囲を確定し、契約を結ぶ
- 設計・開発：仕様に沿って開発会社が設計・実装を進める
- テスト・検収：納品物が要件どおりか発注側が確認して受け入れる
- 納品・運用保守：本番稼働後の保守や改修を契約に沿って継続する
この中で発注側が主体的に関わるべきなのは、特に要件定義と検収です。要件定義は「何を作るか」を決める工程で、ここが曖昧だと後工程すべてに影響します。検収は「要件どおりにできているか」を確認して受け入れる工程で、ここを流してしまうと、納品後に「思っていたものと違う」と気づいても手戻りが大きくなります。丸投げにせず、要所で自社が判断を握ることが、受託開発を成功させる基本姿勢です。
契約で確認すべきこと
受託開発の契約は請負契約が基本ですが、要件が固まりきらない開発では、要件定義工程だけを準委任契約で進め、仕様が確定してから請負契約に切り替えるケースもあります。契約形態によって責任の重さが変わるため、どの契約でどこまでを頼むのかは最初に確認しておきましょう。
特に発注側が見落としがちで、後々トラブルになりやすいのが次の3点です。
- 著作権・ソースコードの帰属
- 完成したシステムやソースコードの権利が、発注側と開発会社のどちらに帰属するかは契約で決まります。将来の改修や別会社への乗り換えを見据えるなら、権利の帰属と引き渡しの条件を明記しておきます。
- 検収の基準と期間
- 何をもって「完成」とするか、検収でどこまで確認できるか、期間はどれくらいかを決めておきます。基準が曖昧だと、不具合の責任の線引きがあいまいになります。
- 契約不適合責任（旧・瑕疵担保）
- 納品後に不具合が見つかった場合、いつまで・どの範囲で無償修正を受けられるかを確認します。運用保守の契約範囲とあわせて押さえておくと安心です。
これらは法律の専門的な判断が絡む部分もありますが、発注側としては「契約前に確認すべき観点」として押さえておけば十分です。不安な点は契約書のドラフト段階で開発会社に質問し、あいまいなまま押印しないことが何よりの防御になります。
費用と見積もりの考え方
受託開発の費用は、基本的に「工数（人月）×人月単価」で算出されます。人月とは「エンジニア1人が1か月働く作業量」の単位で、必要な作業量に単価をかけて概算が出ます。受託開発には定価がなく、同じようなシステムでも開発会社や要件によって金額が変わるのが特徴です。請負契約であれば、契約で決めた金額以外は基本的に発生しないため、予算計画を立てやすいという利点もあります。
逆に言えば、要件を後から追加すれば費用は膨らみます。だからこそ、見積もりを受け取ったときに「どこまでが含まれ、何が含まれないか」の線引きを確認することが重要です。極端に安い見積もりは範囲が絞られていたり、後から追加費用が乗ったりすることもあるため、金額の高低だけでなく前提条件まで読み解く必要があります。受託開発の見積もりが妥当かを自分で点検したいときは、システム開発見積もりチェックシート（危険サインを見抜く60項目）で、抜けやすい前提や危険なサインを確認できます。
費用の相場感をシステムの種類・規模別につかんでおきたい場合は、システム開発費用の相場と内訳を開発パターン別に解説した記事もあわせて確認してください。なお金額はあくまで一般的な目安であり、実際の費用は要件と依頼先によって変わるため、最終判断は個別の見積もりで行ってください。
失敗しない依頼先の選び方
受託開発の成否は、どの開発会社に頼むかで大きく変わります。会社選びで見るべきポイントは、価格よりもむしろ「相性」と「実力」です。
具体的には、コミュニケーションの取りやすさ、自社が作りたいシステムの分野を得意としているか、開発実績が十分か、そして多重下請け構造になっていないか、の4点を確認します。下請けに再委託する比率が高い会社では、要望が伝言ゲームになって仕様がずれやすくなります。自社開発の比率が高く、営業担当と開発開始後の窓口が近い会社ほど、要望どおりのシステムに仕上がりやすい傾向があります。
依頼先を探す流れや、相見積もり・コンペの進め方といった具体的な手順は、システム開発を依頼する流れと会社選びを解説した記事で詳しくまとめています。受託開発の依頼先を本格的に比較する段階に入ったら、そちらを参照すると判断材料がそろいます。
受託開発のよくある質問
初めての発注でよく聞かれる疑問をまとめました。
- Q. 受託開発とSESはどちらを選べばよいですか？
- A. 完成したシステムを納品してほしいなら受託開発、自社主導で進めつつ人手を足したいならSESが向きます。SESは成果物ではなく稼働時間への支払いで、成果物の完成責任は負わない点に注意します。
- Q. 受託開発は個人（フリーランス）にも頼めますか？
- A. 頼めますが、実績や継続性の確認がより重要になります。連絡が取れなくなるリスクや、保守を継続できるかを見極め、契約で成果物とサポート範囲を明確にしておきましょう。
- Q. 要件が固まっていなくても受託開発を頼めますか？
- A. 要件定義から相談できる会社が多いです。仕様が固まりきらない場合は、要件定義を準委任で進めてから請負契約に移る進め方もあります。まずは概要と予算感を伝えて相談するとよいでしょう。
- Q. 納品後の保守も受託開発に含まれますか？
- A. 含めるかどうかは契約次第です。開発だけに目が向きがちですが、公開後の運用・保守を契約に含めておかないと、更新やトラブル対応ができなくなります。発注前に保守の範囲も確認しておきましょう。
