開発会社との契約の注意点(請負と準委任)
開発会社との契約では、まず「完成に責任を持ってもらう請負」なのか「専門家として作業してもらう準委任」なのかをはっきりさせることが最も重要です。要件が固まっていない新規事業の開発では準委任が合う場面が多い一方、準委任では完成が約束されないため、進め方と成果物の権利、途中でやめるときの扱いを契約で補っておく必要があります。
この記事では、民法の規定と独立行政法人情報処理推進機構(IPA)が公開しているモデル契約書をもとに、発注者が押さえるべき点を整理します。
請負と準委任の違い
請負:仕事の完成に対して報酬を払う
民法第632条は、請負を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定めています。開発会社は完成の義務を負い、発注者は完成した結果に対して報酬を払います。
報酬の支払時期は、原則として仕事の目的物の引渡しと同時とされています(第633条)。また、引き渡されたものが種類や品質に関して契約の内容に適合しない場合、発注者は修補などの履行の追完、報酬の減額、損害賠償、契約の解除を求めることができます(売買の規定を有償契約に準用する第559条、第562条・第563条など)。
準委任:事務の処理そのものに対して報酬を払う
委任は法律行為を委託する契約で(第643条)、法律行為でない事務の委託には委任の規定が準用されます(第656条)。これが準委任で、システム開発の作業を依頼する契約はこちらに当たります。
受任者(開発会社)は、「委任の本旨に従い、善良な管理者の注意をもって」事務を処理する義務を負います(第644条)。専門家として求められる水準の注意を払って作業する義務はありますが、仕事の完成そのものは約束しません。
準委任の報酬には、大きく2つの形があります。
- 履行割合型: 作業した期間や工数に応じて報酬を払う形。委任事務を履行した後に請求でき、期間で報酬を定めた場合はその期間の経過後に請求できます(第648条第2項)
- 成果完成型: 事務の履行によって得られる成果に対して報酬を払う形。成果の引渡しが必要な場合、報酬は引渡しと同時に払います(第648条の2第1項)
成果完成型は請負と似ていますが、完成の義務を負わない点で異なります。
違いの整理
| 項目 | 請負 | 準委任 |
|---|---|---|
| 開発会社の義務 | 仕事を完成させる | 善良な管理者の注意をもって作業する |
| 報酬の対象 | 仕事の結果 | 作業そのもの(または成果) |
| 完成しなかった場合 | 原則として完成の責任を問える | 注意義務を尽くしていれば責任は問いにくい |
| 仕様変更への強さ | 変更のたびに契約変更が必要になりやすい | 作業の範囲内で柔軟に対応しやすい |
新規事業の開発ではどちらを選ぶか
要件が固まっていないなら準委任が合う
請負契約は「何を完成させるか」が明確であることが前提です。新規事業のMVP開発のように、顧客の反応を見ながら仕様を変えていく開発では、完成の対象を最初に確定できません。無理に請負にすると、仕様を変えるたびに追加見積もりと契約変更が必要になり、開発会社側も変更のリスクを見込んで見積もりを高くする傾向があります。
IPAが2020年3月に公開した「情報システム・モデル取引・契約書(アジャイル開発版)」は、準委任契約を前提としています。IPAは、あらかじめ特定した成果物の完成に対価を払う請負ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を払う形を採ったと説明しています。この契約書は、ユーザ側がプロダクトオーナーを選任し、ベンダ側がスクラムマスターを選任して、ユーザ側の事業部門と連携しながら開発を進める体制を想定しています。また、契約前にプロジェクトの目的、プロダクトのビジョン、アジャイル開発への理解、体制などを両者で確認するチェックリストが用意されています。
工程によって使い分ける
一つのプロジェクトの中で、工程ごとに契約を分ける方法もあります。IPAの講演資料(2025年4月)では、要件定義までを準委任、外部設計を準委任または請負、内部設計から結合テストまでを請負、システムテストを準委任または請負とする整理が示されています。要件の不確定さやリスクに応じて契約方式を選び、見積もりの精度を段階的に上げていくという考え方です。
新規事業では、次のような組み立てが考えられます。
- 検証段階・MVP開発: 準委任で、短い期間ごとに契約を区切る
- 仕様が固まった機能の追加や作り直し: 請負で、完成の対象を明確にして発注する
契約で確認すべき点
1. 契約の種類を明記する
契約書の表題が「業務委託契約書」でも、中身が請負なのか準委任なのかは条文の内容で判断されます。どちらの考え方なのかを契約書に明記し、報酬の支払条件もそれに合わせて定めます。見積書と契約書で前提が食い違っていないかも確認します。
2. 準委任の場合は、進め方と報告を決める
準委任では完成が約束されないため、発注者が進み具合を把握できる仕組みが重要です。
- 作業の範囲と体制(担当者、稼働の目安)
- 報告の頻度と方法(定例会、作業報告書)
- 優先順位を決める人(発注者側の責任者)
- 作業時間の上限と、超える場合の扱い
アジャイル型の開発では、発注者側の担当者が優先順位の判断や確認に継続して関わる必要があります。発注者が関与できない体制では、準委任の開発はうまく進みません。
3. 成果物の著作権の扱い
開発されたプログラムの著作権は、契約で定めなければ、原則として作成した側(開発会社)に残ります。発注者が著作権の譲渡を受ける場合、著作権法第61条第2項により、翻案権など(第27条・第28条の権利)を譲渡の対象として特に明記していないと、譲渡した側に留保されたものと推定されます。譲渡を受けるなら、この2つの条文の権利を含むことを明記します。
一方、開発会社が以前から持っている汎用的なプログラムや部品まで譲渡を求めると、交渉が難航したり費用が上がったりします。「発注者のために新たに作った部分は譲渡、開発会社が従前から持つ部分は利用許諾」のように分けるのが一般的な考え方です。オープンソースソフトウェアを使う場合は、その利用条件に従う必要があることも確認します。
また、ソースコード、設計書、利用しているサービスのアカウントなど、将来ほかの開発会社に引き継ぐときに必要なものを、いつ、どの形で受け取るかも決めておきます。
4. 契約不適合責任の期間
請負で引き渡されたものが契約の内容に適合しない場合、発注者は不適合を知った時から1年以内に開発会社に通知しないと、追完請求や報酬減額請求などができなくなります(民法第637条第1項)。ただし、引渡しの時に開発会社が不適合を知っていた、または重大な過失で知らなかった場合は、この制限は適用されません(同条第2項)。
これは民法の原則で、契約で異なる期間や起算点を定めることもあります。検収の方法と期間、不具合の対応期間を契約書で確認し、社内で受け入れテストを行う体制も準備しておきます。
5. 途中でやめるときの扱い
新規事業では、検証の結果によって開発を途中で止めることがあります。
- 請負: 注文者は、仕事が完成しない間は、いつでも損害を賠償して契約を解除できます(第641条)。また、完成前に解除された場合でも、既にした仕事の結果のうち可分な部分によって注文者が利益を受けるときは、その割合に応じて報酬を請求できるとされています(第634条)
- 準委任: 各当事者はいつでも解除できますが、相手方に不利な時期に解除した場合などは、やむを得ない事由がない限り損害を賠償しなければなりません(第651条)。履行の途中で終わった場合、受任者は既にした履行の割合に応じて報酬を請求できます(第648条第3項)
契約書では、解除の予告期間、途中までの作業の精算方法、途中までの成果物とソースコードの引渡しを決めておきます。
6. 発注者側の協力
システム開発では、開発会社が技術の専門性を持つ一方、発注者は自社の業務や事業に通じています。IPAのモデル契約書(第二版)の改訂では、プロジェクトマネジメント義務と協力義務が主な論点の一つとして扱われました。発注者も、情報の提供、判断、確認を期限どおりに行う必要があります。発注者の対応が遅れて開発が止まった場合の扱いも、契約で確認しておきます。
大企業と起業家で異なる点
大企業の場合
社内の標準契約書は、請負を前提にしていることがあります。アジャイル型で準委任の契約を結ぶ場合は、法務・購買部門と早めに相談し、IPAのモデル契約書などを参考に調整します。また、取引の内容や双方の資本金・従業員数によっては、2026年1月1日に下請法から名称が変わった「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」(取適法)や、個人の開発者に依頼する場合の「特定受託事業者に係る取引の適正化等に関する法律」(フリーランス・事業者間取引適正化等法)が適用されることがあります。適用の有無は購買・法務部門で確認してください。
起業家の場合
契約書のひな型を開発会社から提示されることが多いため、少なくとも契約の種類、支払条件、著作権の帰属、ソースコードの引渡し、途中解約の扱いは自分で読み、疑問点は契約前に質問します。資金が限られている段階では、短い期間ごとに区切った準委任で進め、成果を見ながら継続を判断する方法がリスクを抑えやすくなります。
発注先の選び方と見積もりの読み方はMVP開発を外注するときの発注先の選び方と見積もりの読み方で扱っています。検証段階の技術検証を外部と行う場合はPoCの契約:モデル契約書で押さえる点も参考にしてください。
まとめ
- 請負は完成に対して、準委任は作業そのもの(または成果)に対して報酬を払う
- 要件が固まっていない新規事業の開発は、準委任を短い期間で区切るのが合いやすい
- 工程ごとに請負と準委任を使い分ける方法もある
- 著作権の譲渡を受けるなら、著作権法第27条・第28条の権利を含むと明記する
- 契約不適合責任の期間、検収、途中解約の精算とソースコードの引渡しを決めておく
- 発注者も判断と協力の責任を負う
法律や制度は改正されます。契約の前に公式情報を確認し、弁護士など専門家に相談してください。
参考資料
進め方に迷ったら、相談してください
起業家ポータル のメンバーが話を伺います。初回の相談は無料です。
同じ工程の記事
MVPの要件定義の進め方:検証に必要な範囲だけを決めて合意する
MVPの要件定義は、すべての機能を決め切る作業ではなく、検証したい仮説から逆算して「作るもの」「作らないもの」「できたと判断する基準」を決め、関係者と合意する作業です。進め方の手順、非機能要件の最低ライン、要件シートの項目例を整理します。
アジャイル開発の進め方と発注側の役割:スプリントごとに何をするか
アジャイル開発は、短い期間の開発を繰り返し、動くものを見ながら優先順位を変えていく進め方です。IPAの資料をもとにスクラムの基本の流れを整理し、発注側がスプリントごとに担う役割、予算と進み具合の管理、うまくいかない場面の対処を解説します。
プロトタイプでのユーザーテストの進め方
プロトタイプのユーザーテストは、5人程度の対象者に2〜3個の操作課題を実際にやってもらい、つまずく箇所を観察するのが基本です。準備、進行、記録、結果の整理と、ヒアリングとの違いを解説します。
PoCの評価指標と成功基準の決め方
PoCの評価指標は、技術・業務・事業の3層で「何が分かれば次に進むか」から逆算して決めます。現状値の測り方、成功基準を3段階で置く方法、判断者と記録の残し方まで、大企業の担当者向けに解説します。