BLOG

請負開発とは ― メリット・デメリットと、受託開発・準委任との違い

「開発会社から届いた契約書に『請負』と書いてある。受託開発と何が違うのか」「請負なら全部任せられると思っていたら、仕様の追加は別料金だと言われた」。システム開発を初めて外部に依頼する方から、こうしたご相談をよくいただきます。

請負開発は、仕事の完成に対して報酬を支払う契約で進める開発です。総額と納期が先に決まる安心感がある一方、何を「完成」とするかを契約の時点で決めておかないと、追加費用や受け入れをめぐる行き違いが起きやすい形でもあります。

この記事では、請負開発とは何か、受託開発・準委任・SESと何が違うのか、メリットとデメリット、向いている案件、契約前に決めておくことを、請負でも準委任でも開発を行っている当社の視点で整理します。

請負開発は完成した成果物に対して報酬を支払い、準委任は業務の遂行に対して期間ごとに報酬を支払う。仕様が決まっている部分だけを請負にするのが基本

この記事を書いた人

wesionaryTEAM 編集チーム

株式会社wesionaryTEAMのプロジェクトマネージャーとエンジニアで構成する編集チームです。業務システム開発、AI導入支援、DX推進の案件で日々得ている知見をもとに、検討中の方が判断に使える情報を、事例と数字を添えてお届けします。

請負開発とは

請負開発とは、請負契約でシステムやソフトウェアを開発することです。民法632条は、請負を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定めています。開発会社は決めた成果物を完成させる義務を負い、発注側はその結果に対して報酬を支払います。

ここで報酬の対象になるのは、かけた時間ではなく「仕事の結果」です。開発に想定より時間がかかっても、原則として契約金額は変わりません。逆に、決めた成果物が完成しなければ、開発会社は報酬を請求できないのが原則です(完成前に解除された場合などは、民法634条により、発注側が利益を受ける部分について割合に応じた報酬が認められます)。

「受託開発」と「請負開発」は混同されやすい言葉です。受託開発は、開発を外部の会社に委ねる形態全体を指す言葉で、契約の形までは指しません。その契約が請負契約であれば請負開発、準委任契約であれば準委任での受託開発になります。つまり請負開発は、受託開発のうちの一つの契約の形です。受託開発そのものについては、受託開発とは何かで整理しています。

準委任・SES・派遣との違い

外部に開発を依頼する契約は、請負のほかに準委任と労働者派遣があります。SES(システムエンジニアリングサービス)は多くの場合、準委任契約で結ばれます。

請負準委任労働者派遣
報酬の対象仕事の完成業務の遂行労働時間
完成責任ありなしなし
現場への指揮命令開発会社開発会社発注側

準委任契約は、業務の遂行そのものに対して報酬を支払う契約で、成果物の完成は約束されません。民法644条により、受任者は「善良な管理者の注意」をもって業務を行う義務を負います。詳しくは準委任契約とはで解説しています。

労働者派遣では、発注側が派遣されたエンジニアに直接指示を出せます。請負と準委任では、現場への指示は開発会社の側にあり、発注側が開発会社の社員に直接業務の進め方や労働時間を指示すると、いわゆる偽装請負として労働者派遣法に違反するおそれがあります。この区分は契約書の名前ではなく、厚生労働省の告示(37号告示)に基づいて実態で判断されます。

請負開発のメリット

  • 総額と納期が先に決まる。予算の承認が取りやすく、社内の計画も立てやすくなります。
  • 完成の責任を開発会社が負う。想定より時間がかかった分は、原則として開発会社が負担します。
  • 納品後の不具合に責任がある。納品物が契約の内容に適合しない場合、発注側は修補などの追完、報酬の減額、損害賠償、契約の解除を求められます(民法559条、562条から564条)。
  • 発注側の日々の負担が小さい。進め方の判断は開発会社に委ねられるため、要件定義と受け入れの工程に集中できます。

請負開発のデメリット

  • 仕様を先に固める必要がある。何を完成とするかが決まっていなければ、請負の金額は出せません。要件が固まっていない段階で総額を求めると、開発会社はリスク分を上乗せするか、範囲を狭く解釈するかのどちらかを選ぶことになります。
  • 変更が追加契約になる。決めた範囲を超える変更は、見積もりと契約のやり直しです。使いながら仕様を変えたい案件とは相性がよくありません。
  • 途中でやめると負担が残る。民法641条により、発注側は完成前にいつでも契約を解除できますが、開発会社の損害を賠償する必要があります。
  • 現場に直接指示できない。進め方の判断は開発会社にあるため、日々の細かな要望を現場のエンジニアに直接伝える進め方は取れません。窓口と変更の手続きを決めておく必要があります。

請負開発が向いている案件、向いていない案件

向いているのは、作るものが決まっている案件です。既存システムの移行や作り直し、仕様書がすでにある業務システム、要件定義を終えた後の設計と開発の工程が典型です。

向いていないのは、作りながら決める案件です。新規事業の最初の製品、試験導入(PoC)や実用最小限の製品(MVP)、利用者の反応を見て機能を変えていく開発は、準委任やラボ型開発のほうが実態に合います。

実務では、要件定義の工程を準委任で行い、仕様が固まってから開発の工程を請負で契約する、という工程ごとの契約がよく取られます。経済産業省とIPA(情報処理推進機構)の「情報システム・モデル取引・契約書」も、工程ごとに契約を結ぶ多段階契約の形を採っています。

請負開発の流れ

請負開発は、おおむね次の順で進みます。

  • 要件定義。何を作るかを決めます。この工程は準委任で行うか、発注側が社内で行います。
  • 見積もりと契約。固まった要件をもとに、成果物の範囲、金額、納期、検収の条件を契約書にします。
  • 設計と開発。開発会社が進め方を判断して進めます。発注側は週次の定例などで進捗と判断の確認を行います。
  • テストと納品。開発会社のテストを経て納品され、発注側が検収を行います。
  • 公開後の保守。不具合の修正や小さな改修は、別の契約(多くは準委任)で続けます。

請負の金額を決めているのは、画面と機能の数、外部システムとの接続、データ移行の有無、対応する端末、そして要件の不確実さです。同じものを頼んだつもりでも、各社が含めている工程と不確実さの見込み方が違えば、金額は大きく開きます。見積もりを比べるときは、この前提を先に揃えてください。

請負で契約する前に決めておくこと

  • 完成の基準。何ができていれば完成とみなすかを、画面と機能の一覧、対応する端末やブラウザ、性能の条件まで書面にします。ここが曖昧なまま始めると、受け入れの段階で意見が割れます。
  • 検収の手順と期限。納品から何日以内に確認し、どう連絡するかを決めます。検収の完了は、報酬の支払いと契約不適合責任の起算点に関わります。
  • 変更の扱い。仕様の追加や変更が出たときに、誰が、どの手順で、費用と納期にどう反映するかを決めておきます。
  • 契約不適合責任の期間。民法637条では、注文者が不適合を知った時から1年以内に通知する必要があります。契約書で別の定め方をすることも多いため、期間と起算点を確認してください。
  • 著作権と納品物の範囲。ソースコードや設計書の帰属と、納品後に自社で改修してよいかを確認します。将来の内製化を考えるなら特に重要です。

なお、ここでの説明は一般的な整理です。個別の契約については、契約書の文面と、必要に応じて専門家の確認をお願いします。

よくあるご質問

請負開発と受託開発は同じ意味ですか?

同じではありません。受託開発は開発を外部に委ねる形態全体を指し、請負開発はそのうち請負契約で行うものです。準委任契約で行う受託開発もあります。

請負契約なら、仕様の変更は無料で対応してもらえますか?

契約で決めた範囲内の修正は対応の対象ですが、範囲を超える追加や変更は追加の契約になるのが一般的です。変更が起きる前提なら、その手続きを契約時に決めておいてください。

納品後に不具合が見つかったら、どうなりますか?

納品物が契約の内容に適合しない場合、修補などの追完を求められます。民法では不適合を知った時から1年以内の通知が必要で、契約書で期間を別に定めることもあります。

請負開発でも、開発の途中で進捗を確認できますか?

できます。週次の定例や中間レビューを契約や進め方に組み込むのが一般的です。ただし、現場のエンジニアに直接作業の指示を出すことは偽装請負にあたるおそれがあるため、窓口を通して行います。

請負と準委任、どちらが安くなりますか?

一概には言えません。仕様が固まっていれば請負で総額が確定しますが、固まっていない段階の請負はリスク分が上乗せされます。探りながら進める段階は準委任、固まってからは請負、と工程で分けるのが費用の面でも合理的です。

まとめ

請負開発は、仕事の完成に対して報酬を支払う契約で、総額と納期が先に決まり、完成と不具合の責任を開発会社が負います。その代わり、何を完成とするかを先に決める必要があり、変更は追加契約になります。

作るものが決まっているなら請負、決めながら作るなら準委任、と工程で使い分けるのが基本です。どちらの形が合うか迷う段階でも、無料見積相談で担当PMが範囲と契約の形から一緒に整理します。

関連する記事とページ

出典

この記事の監修者

永田 一郎代表取締役

ヤフー(Yahoo! JAPAN)のエンジニア出身。スタートアップ、大手事業会社にて18年以上にわたり、toC/toB向けの新規事業開発、業務DX化など、多種多様なプロジェクトに従事。エンジニアとして自ら開発に携わる一方、体制構築やマネジメント、事業設計、仮説検証にも関わり、事業の立ち上げとグロースを幅広く体得。これまでに三回の事業売却を経験。共創でより効果的にプロダクトをつくり、アイディアをマーケットで検証できることを確信し、共創プラットフォームを提供するため wesionaryTEAM を創業。