この記事の結論
請負と準委任の違いは、何に対してお金を払うかです。
請負は仕事の完成に対して払い（民法632条）、
システム開発では、何を作るかが決まっていない要件定義は準委任、決まった設計にもとづいて作る工程は請負、と工程ごとに分けるのが、IPA（情報処理推進機構）の
発注する側が契約の前に決めておくのは、型の名前よりも、検収で何を確かめるか、仕様を変えるときの手続き、不具合を知らせる期限、どこから保守に移るか、の4つです。
この記事は契約の考え方の整理で、法律の助言ではありません。
自社の契約書の判断は弁護士に確かめてください。
この記事の位置づけ
ここに書くのは、民法の条文とIPAの公開資料をもとにした、発注する側から見た整理です。
個別の契約書の読み方や、トラブルになったときの判断は、法律の助言にあたるため書いていません。
契約を結ぶ前、または結んだ契約に疑問があるときは、弁護士に契約書を見てもらってください。
請負と準委任は、何に対してお金を払うかが違う
民法は、請負を「当事者の
システム開発なら、決まった仕様のシステムを完成させて引き渡すことが、開発会社の義務になります。
準委任は、法律行為でない事務を任せる契約で、委任の決まりが準用されます（民法656条）。
任された側は「善良な
要件定義の手伝いや、調査、運用の支援のように、ゴールの形が最初は決まっていない仕事に使われます。
違いがはっきり出るのは、支払いの時期と、途中で終わったときです。
| 請負 | 準委任（履行割合型） | 準委任（成果報酬型） | |
|---|---|---|---|
| 何に払うか | 仕事の完成 | 作業を進めたこと | 作業で得られた成果 |
| 払う時期 | 引き渡しと同時。引き渡しがいらない仕事は終わった後（633条） | 作業の後。期間で決めたら、その期間が過ぎた後（648条2項） | 成果の引き渡しと同時（648条の |
| 途中で終わったとき | 分けられる部分で発注側が利益を受けるなら、その割合で払う（634条） | すでにした作業の割合で払う（648条3項） | 請負と同じ考え方（648条の |
| 発注側からの解除 | 完成前ならいつでも。ただし損害を賠償する（641条） | いつでも。相手に不利な時期などは損害を賠償する。やむを得ない理由があれば別（651条） | 同じく651条 |
「途中で
発注する側の責任で完成できなかったときは、別の扱いになります。
成果報酬型は、2020年4月に施行された改正民法で新しく条文になった型です。
IPAと経済産業省の検討の場（民法改正対応モデル契約見直し検討WG）は、
議論では、今の準委任の工程は「いわゆる
「準委任」と
報酬を時間や期間で数えるのか、成果物の引き渡しで払うのかを、契約書で確かめておきます。
条文はe-Gov法令検索で
改正の経緯は、IPAの「第一版及び追補版 DX推進のための見直しにおける民法改正を踏まえた整理にあたって（PDF）」に
どちらにするかは、作るものが決まっているかで決める
IPAのモデル契約は、企画から保守までを工程に分け、工程ごとに型を示しています。
システム化の方向性、システム化計画、要件定義は準委任。
内部設計からシステム結合までは請負。
外部設計とシステムテストは、準委任と請負のどちらもあり得るとしています。
発注側の業務の要件に関わる部分が多く準委任になじむ一方、これまでの実務では請負で結ばれることも多い、という説明です。
理由として挙げているのは、要件定義の段階では、発注する側にとっても作るものを具体的に想定できず、開発会社がそれを特定することは通常できない、という点です。
発注する中小企業の立場で言い直すと、次の表になります。
| 今の状況 | 合いやすい型 | 契約書で決めておくこと |
|---|---|---|
| 困りごとはあるが、どんな画面や機能にするかは決まっていない | 準委任（履行割合型） | 作業の範囲と期間、報告のしかた、終わったと確認する方法 |
| 試作を見ながら形を決めたい | 準委任（履行割合型） | 1回の区切りの長さ、区切りごとの報告、やめるときの扱い |
| 要件定義書や画面の資料があり、作るものを書面で示せる | 請負 | 検収の基準と期間、仕様変更の手続き、不具合を知らせる期限 |
| 既存のシステムの改修で、直す箇所がはっきりしている | 請負 | 直す範囲、検収のしかた、ほかの機能に影響が出たときの扱い |
| データの移行や、使い始めるときの支援 | 準委任 | 誰が何を確かめるか、作業の終わりの確認 |
| 公開した後の問い合わせ、修正、更新 | 準委任または請負（作業ごと） | 保守に含む範囲、対応の時間、契約不適合の期間との切れ目 |
一つの開発でも、工程ごとに型の違う契約を結ぶのが、モデル契約の形です。
要件定義を準委任で終えてから、決まった要件で開発の見積もりを取り直すと、金額の根拠がはっきりします。
要件定義で何を決めるかは要件定義とはに、見積もりのどこを見るかは業務システムの見積もりの読み方にまとめました。
私は、型を先に決めるより、自社が今「作る
示せないのに請負で結ぶと、作りながら決めたことがすべて仕様変更の話になり、費用と納期の交渉が続きます。
業務システムの開発を頼むときも、この段階を飛ばさないことが、後の話し合いを短くします。
請負にすれば任せきりでよい、とはならない
請負なら完成の責任は開発会社にある、と考えたくなります。
ただ、IPAのモデル契約の解説には、請負の形をとると、発注する側に「丸投げ」
民法にも、発注する側の関わり方が効いてくる条文があります。
請負で引き渡されたものが契約に合わなくても、その原因が発注者の渡した材料や、発注者の与えた指図にある場合は、直してもらうことや代金の減額などを求められません（民法636条）。
ただし、開発会社がその材料や指図が不適当だと知りながら告げなかった場合は別です。
業務の流れや必要なデータを出すのは、請負でも発注する側の仕事です。
モデル契約も、開発会社から協力を求められたら、発注する側は適時に応じるとしています（第24条2項）。
反対に、準委任だからといって、社内の人が開発会社の技術者に直接、仕事の進め方や働く時間を指示すると、労働者派遣（いわゆる
厚生労働省の疑義応答集は、請負（委任と
アジャイル型の開発を準委任で進める場合も同じ基準で実態から判断し、双方が対等に協働して、受けた側の担当者が自律的に判断しているなら、密に連絡を取り合っていても偽装請負にはならない、とも説明しています（厚生労働省：37号告示に関する疑義応答集（第3集）
社内の人と同じように動いてほしいなら、それは契約の形から考え直すことになります。
雇うか外に頼むかの考え方はエンジニアを雇うか、外部に任せるかに書きました。
検収は、何を確かめたら終わりかを先に決める
請負で一番もめやすいのは、
モデル契約は、ここを検収の手続きで決めています。
2026年10月6日にIPAの受託開発版のひな型（Word）を
まず、発注する側が開発会社と相談して、何をどう試すかを書いた「検査仕様書」を
テストの項目、テストに使うデータ、テストの方法と期間を、システムの仕様にもとづいて決めるものです。
納品されたら、個別の契約で決めた検査の期間内にこの検査仕様書で試し、合っていれば検査合格書を渡し、合っていなければ理由を書いた書面で直してもらいます（第28条1項・2項）。
読んでいて、発注する側が気をつけたいと思ったのは第28条3項です。
検査合格書を渡さなくても、検査の期間内に書面で具体的な理由を示して異議を述べなければ、合格したものとみなす、と書かれています。
準委任の工程でも、開発会社の作業終了の報告書を決めた期間内に点検し、異議を述べなければ終了を確認したものとみなす形になっています（第18条・第32条）。
つまり、検収の期間に社内で試す人と時間を空けておかないと、確かめないまま検収が終わることがあります。
契約の前に決めておきたいのは、誰が試すか、何日あれば試せるか、どの業務の流れを通して試すか、です。
実際に使う担当の人が、普段の仕事の流れで一通り操作してみるのが、私は一番確かだと考えています。
仕様変更は、書面で決める手続きを契約に入れる
作っている途中で「この
問題になるのは、変えたことが口頭やチャットだけで決まり、費用と納期への影響が後から分かるときです。
モデル契約は、仕様を変えるときの手続きを決めています。
変えたい側が、変更の内容と理由を書いた変更提案書を出し（第34条）、
変更管理書に書くのは、変更の名称、提案の責任者、日付、理由、変更の詳しい中身、費用がかかる場合はその額、変更作業の予定、契約の条件への影響、などです。
双方の責任者が承認して変更が決まり、委託料や納期が変わる場合は、書面で変更契約を結んで決まります（第33条・第37条3項）。
もう一つ、発注する側から中断を求められたなど特別な事情があるときは、話し合いが決まらない間、開発会社が作業を止められる、とも書かれています（第37条4項）。
変更を出したまま返事を延ばすと、開発そのものが止まることがあります。
話し合いがまとまらず、発注する側が続けるのをやめる場合は、それまでの作業の委託料と、開発会社に生じた損害を払う形です（第38条）。
その時点で決められないことがある場合の決まりもあります（第36条）。
決まっていない事項と、いつ決めるか、決まったときに費用や納期が変わったら受け入れることを、書面にしておく、というものです。
「ここは
契約不適合の通知の期限は、契約書の数字を確かめる
引き渡されたシステムが、種類や品質の面で契約の内容に合わないとき、発注する側は直してもらうこと（追完）などを
売買の決まりとして民法562条に定められ、請負のような有償の契約にも準用されます（民法559条）。
期限もあります。
請負で、種類や品質が契約に合わない場合、発注する側が不適合を「知った
引き渡しの時に開発会社が不適合を知っていたか、重大な過失で知らなかった場合には、この期限は当てはまりません（同条2項）。
ここで、契約書の数字を確かめる理由があります。
モデル契約の第29条は、契約不適合を「システム仕様書との
数字は空欄で、当事者が決めます。
括弧書きで、
民法の「知った
ただし、検収の時に開発会社が不適合を知っていたか重い過失で知らなかった場合や、故意や重い過失による不適合には、この期間の限りではない、という但書もあります。
契約書を受け取ったら、この期間が何か月か、どこから数えるのかを確かめます。
使い始めてすぐには出てこない処理（月末の
すでに不具合が出て話し合いが進まないときの相談先と、知らせ方はシステム開発のトラブルは、どこに相談するかにまとめました。
開発から保守に移るところに、切れ目をつくる
開発が終わって使い始めると、問い合わせ、不具合の修正、小さな改修、サーバーの更新などが続きます。
これを受けるのが保守の契約です。
モデル契約は、保守を「情報システムや
保守と運用の契約は作業の形がさまざまなので、共通の決まりを基本契約にし、具体的な作業は個別の契約と仕様書で決める形です。
気をつけたいのは、開発の契約不適合の期間と、保守の期間が重なることです。
検収の翌月から保守料を払い始めた場合、その間に見つかったバグを直すのが、開発の契約の追完なのか、保守の作業なのかで、費用の扱いが変わります。
私は、契約不適合の期間中に見つかった仕様との食い違いは追完として扱い、保守には入れない、と保守の契約書か見積もりに書いておくのがよいと考えています。
もう一つは、開発会社を替えても困らないようにすることです。
保守の契約が終わったときに何を受け取れるか、ソースコードやサーバーの名義が誰にあるかは、開発の契約の時点で決めておきます。
保守の範囲と対応の時間の決め方はシステムの保守契約で確かめることに、コードを自社の名義で持つ方法は外注先が書くコードも、GitHubの自社の組織に置くに書きました。
契約書のたたき台には、IPAのモデル契約が使える
経済産業省が2007年に公開した「情報システム・モデル取引・契約書」を、
第二版は2020年12月22日に公開され、解説つきの「受託開発
発注する会社、開発する会社、法律の専門家が加わって議論し、どちらか一方に有利に偏らない契約書を目指した、と説明されています。
パッケージやSaaSを使う場合の追補版と、アジャイル開発版（2020年3月公開）も
Wordで配られていて、解説つきの版と、条文だけのひな型があります。
大きな会社どうしの取引を想定した細かい条文も多いので、そのまま使うより、開発会社から出てきた契約書と並べて、抜けている決まりを探すのに使うのが向いていると私は考えています。
同じページには、公開当時の法律にもとづいているので、参照している法律が改正されている場合があり、使うときは確かめるように、とも書かれています。
よくある質問
システム開発の請負と準委任の違いは何ですか？
要件定義は請負と準委任のどちらで結びますか？
検収の期間に確かめられなかったら、どうなりますか？
契約不適合責任の期間は、いつまでですか？
準委任なら、開発会社の技術者に直接指示を出してよいですか？
この記事の内容で、契約書の判断をしてよいですか？
bundlyzeは、大阪市北区のグラングリーン大阪を拠点に、大阪・兵庫を中心とした関西の会社の業務システムの開発と、既存のシステムの改修や引き継ぎを受け持っていて、打ち合わせはWeb会議でも対面でもできます。
この記事を書いた津嘉山は、業務システム開発とAWSを専門とするエンジニアで、業務システムの要件定義から開発、保守運用までの経験をもとに設計しています。
業務システムについて、
いまの状況をお聞かせください
「何から
- 24時間以内に、担当者からご連絡します。
- 全国からご相談いただけます。打ち合わせはWeb会議でも、対面でも可能です。
