システム開発を外部に委託する際によく登場する「準委任」と「請負」の違いは、何に対して支払うかにあります。準委任は仕事の遂行(稼働)に対して支払う契約で、開発会社は完成させる義務を負わず、総額は期間に応じて変動します。請負は仕事の完成に対して支払う契約で、開発会社が完成義務を負い、総額は原則として着手前に確定します。
どちらかが優れているという類の話ではありません。違うのは、着手前に「何が確定していて、何が確定しないか」です。
- 開発会社からの提案書に「準委任」と書かれていたが、請負と何が違うのか分からない。
- 月額制と説明されたけれど、総額がいくらになるのかが見えない。
この記事では、そうした発注側の視点に立って、2つの契約形態の違いと使い分け、そして総額を着手前に確定させる進め方を、専門知識を前提とせずに解説します。
準委任と請負の違いを家造りに例えてみる
わかりやすいよう例え話にすると、準委任は、大工さんに日当で来てもらう契約に似ています。大工さんは誠実に仕事をする義務(法律用語で「善管注意義務」といいます)を負いますが、「家を完成させる義務」までは負いません。支払いは働いた日数分。何日かかるかによって、支払う総額は変わります。
請負は、工務店に「この家を、この金額で建てます」と約束してもらう契約です。工務店は家を完成させる義務を負い、発注側は完成した家に対して、決めた金額を支払います。
システム開発でも構図は同じです。
- 準委任型: 「エンジニア1名 × 月額◯円」のように、稼働に対して月々支払う形。SES、ラボ型開発、技術顧問などで使われる事が多い
- 請負型: 「このシステムを◯円・◯ヶ月で開発します」と、成果物・金額・納期を決めて契約する形
比較表で見る準委任と請負の違い

| 観点 | 準委任 | 請負 |
|---|---|---|
| 支払いの対象 | 仕事の遂行(稼働・工数) | 仕事の完成(成果物) |
| 完成義務 | なし(誠実に遂行する義務は負う) | あり |
| 総額 | 変動する(期間が延びるほど増える) | 原則固定(着手前に確定) |
| 完成しなかった場合 | 稼働した分の支払いは発生する | 原則として報酬を請求できない |
| 納品物と権利帰属 | 契約で定めなければ曖昧になりやすい | 成果物と帰属を定義して契約するのが前提 |
| 向いている場面 | 要件が固まっていない探索段階、運用・保守 | 作るものが決まっている開発 |
ひとつ補足すると、2020年に施行された民法改正で、準委任にも「成果に対して報酬を支払う」型(成果完成型)が定められました。
(成果等に対する報酬)
第六百四十八条の二 委任事務の履行により得られる成果に対して報酬を支払うことを約した場合において、その成果が引渡しを要するときは、報酬は、その成果の引渡しと同時に、支払わなければならない。
2 第六百三十四条の規定は、委任事務の履行により得られる成果に対して報酬を支払うことを約した場合について準用する。
https://laws.e-gov.go.jp/law/129AC0000000089
ただしこの場合も、請負のような完成義務まで負うわけではありません。「準委任=完成義務なし」という原則は変わらず、報酬の支払い方には幅がある、と押さえておけば十分です。
なぜ準委任だと「総額が読めない」のか
準委任の月額は、月々固定の金額のため一見わかりやすい数字です。しかし総額は「月額 × 人数 × 期間」で決まり、このうち「期間」を確定させる仕組みが、契約のどこにも含まれていません。
完成の定義が契約にないため、「どこまで作れば終わりか」が合意されないまま開発が進むことがあります。3ヶ月の予定が6ヶ月になれば、支払いは単純に2倍。しかも毎月の請求は契約どおり。どの時点を切り取っても、誰も契約に違反していません。総額が読めないのは組織として予算組みがなかなか難しいところ。
これは開発会社の悪意で起きる問題ではなく、契約の構造がそうなっている、という話です。要件が固まっていなくても走り出せる柔軟さの裏返しとして、「終わり」も固定されない。準委任という契約の性質そのものです。
もうひとつ、準委任では納品物の定義が契約に含まれないことも珍しくありません。ソースコードや設計書が最終的に誰のものになるかは、将来の乗り換えや内製化の自由度に直結します。これについては、別記事「システムの外注先は乗り換えられる?中小企業のためのベンダーロックイン対策」で整理しました。
準委任が合理的な場面もある
ここまで読むと、「準委任は発注側に不利な契約では?」と感じるかもしれませんが、そうではありません。準委任が合っている場面もあります。
- 要件がまだ固まっていない探索段階: 「何を作るべきか」自体をこれから考えるフェーズでは成果物を事前に定義できないため、遂行に対して支払う形が自然
- 運用・保守: 「完成」という概念になじまない、続いていく系の業務
- 技術支援・アドバイザリー: 助言や伴走そのものが提供価値である場合
実際、経済産業省が公表している契約のひな形「情報システム・モデル取引・契約書」でも、要件定義のような上流工程は準委任、開発工程は請負、というように工程ごとに契約形態を使い分ける構成が示されています。
つまり問題は、準委任という形態そのものではありません。完成形と総額が合意されないまま、開発だけが進んでいく構造です。
完成形と総額を着手前に確定させる方法
「では請負で契約すれば安心か」というと、そう単純でもないのが難しいところ。
請負で総額を固定するには、「何を作るか」が着手前に固まっている必要があります。ところが、文章の仕様書だけで完成形を正確にイメージするのは、発注側にとって簡単ではありません。認識がズレたまま総額だけを固定すると、開発の後半で「出来上がったらイメージと違った」が起き、今度は仕様変更の追加費用をめぐる調整が始まります。これでは請負にした意味が薄れてしまいます。
そこで順序が重要となります。先に完成形の認識を合わせ、そのうえで総額を固定する。この順序を実現する現実的な方法が、本開発に入る前にモックアップで完成形をすり合わせる進め方です。
モックアップとは、中身のロジックを持たない「見た目だけの画面」のことです。文章の仕様書と違い、実際に画面を触って操作の流れを確かめられるため、発注側にITの専門知識がなくても「できあがるもの」の認識合わせができます。

流れは次のとおりです。
- 業務の整理と設計の段階で、モックアップを作成する
- 発注側が実際に触り、完成形の認識を合わせる
- 合意した完成形をもとに、一定規模以上の開発は請負契約として総額・納期を確定する
- 開発されたソースコード・設計書は納品され、所有権は自社に帰属する
準委任の柔軟さである「固まる前から一緒に考えられる」のと、請負の確定性である「総額と納期が決まる」を、段階を分けて組み合わせる形です。モデル契約が示す「工程ごとの使い分け」を、専門知識のない発注側でも機能させる鍵が、間に挟むモックアップだといえます。
ハイファイブクリエイトでも、この進め方を標準にしています。モックアップで完成形を合意したうえで、一定規模以上の開発は請負契約・ソースコード納品で進める形です。全体像は外部IT部門サービスのページで紹介しています。
準委任と請負に関するよくある質問
Q. 準委任契約は避けるべき?
A. 要件が固まっていない探索段階や、運用・保守のように「完成」の定義になじまない業務では、準委任が合理的です。避けるべきなのは契約形態ではなく、完成形と総額が合意されないまま開発だけが進んでいく構造です。準委任で始める場合は、「どうなったら次の段階に進むか」という区切りを、開始前に決めておくことをおすすめします。
Q. 請負契約なら、追加費用は発生しない?
A. 契約で合意した範囲内であれば、総額は原則固定です。ただし、着手後の仕様変更や追加のご要望は別途見積もりになるのが一般的。だからこそ、着手前にどれだけ完成形の認識を合わせられるかが、総額の安定を左右します。モックアップを先に作る進め方は、この「着手前のすり合わせ」の精度を上げるためのものです。
Q. 月々の小さな改修も、毎回請負で契約すべき?
A. 軽微で継続的な改修まで都度請負にすると、見積もりと契約のやりとりのほうが重くなってしまいます。日々の運用・保守や軽微な改修は月額の範囲で対応し、一定規模以上の開発を請負として切り出す。この組み合わせが実務的と言えます。
まとめ: 失敗しないシステム開発は「着手前に何が確定するか」で選ぶ
準委任は遂行に支払う契約で、柔軟な反面、総額は変動します。一方で、請負は完成に支払う契約で、総額を固定できる反面、「何を作るか」が固まっていることが前提です。
判断の軸は2つで、「いま、作るものはどこまで固まっているか」と「着手前に何を確定させたいか」。この2点で整理すると、自社に合う契約形態と、間に挟むべき手順が見えてくるはずです。
なお、契約形態の違いとは別に、見積書そのものの内訳や範囲をどう考えるかについては別記事で解説しました。
参考: IT外注の費用はどう決まる?金額を比べる前に「範囲」を揃えるべき理由
ハイファイブクリエイトでは、「中小企業のための外部IT部門」として業務システムの設計・開発・運用を一貫してお引き受けしています。モックアップで完成形を合意したうえで、一定規模以上の開発は請負契約として進め、開発したソースコードと設計書は貴社に納品し、所有権は貴社に帰属します。外部IT部門という選択肢そのものについては、「外部IT部門とは?社内採用・スポット外注と比べてわかる第三の選択肢」で詳しく整理しています。サービスの内容と料金イメージは外部IT部門サービスのページをご覧ください。契約形態の整理がついていない、という段階のご相談も可能です。






コメントを残す