システム開発を外部に頼むとき、「準委任 請負 違い 発注」をどう判断すればいいのか——ここでつまずく発注担当者は少なくありません。準委任契約と請負契約は、見積金額や納期の見せ方が似ているため、契約書を交わすまで違いに気づかないこともあります。ところが、いざ仕様変更や検収の段になると、この選択ひとつで発注者が大きく損をすることがあります。

この記事は法律解説ではなく、発注者が損をしないための実務目線で書いています。法的定義の羅列ではなく、「請負で仕様変更地獄に陥る」「準委任で成果が曖昧になる」といった実際に起きやすい失敗パターンと、要件の固さや開発スタイルに応じた場面別の選び方を整理します。契約形態そのものが何を意味するかは、外部技術リソースの選び方の全体像とあわせて読むと理解が深まります。

なお契約は準法務的なトピックです。本記事の法的記述は一般に知られた定義の範囲にとどめ、最終的な契約判断は弁護士など専門家に確認することをおすすめします。

準委任と請負の違い早見表

まずは両者の違いを早見表で押さえます。一般に、両者の最大の差は「仕事の完成を約束するかどうか」とされています。

観点 請負契約 準委任契約
約束する内容 一般に「仕事の完成」を約束するとされる 一般に「業務の遂行（善管注意義務）」を約束するとされる
成果物の完成義務 あり（完成させる責任を負う） 原則なし（誠実に業務を行うことが義務）
報酬の発生 完成・引き渡しが基本 稼働・履行が基本（成果完成型もある）
契約不適合への対応 一般に契約不適合責任を負うとされる 原則として負わない（善管注意義務違反は別）
費用・スコープの変動 固定見積りになりやすく、変更は再見積りに 稼働ベースで柔軟に調整しやすい
指揮命令 受注者側が自律的に進める 発注者は指示できるが、指揮命令には偽装請負の論点があるとされる
向きやすい場面 要件が固まり、成果が明確なとき 要件が動く、伴走しながら進めたいとき

ざっくり言えば、請負は「決まったものを完成して納める」契約、準委任は「専門性を提供して一緒に進める」契約です。どちらが優れているという話ではなく、案件の性質に合っていないと発注者が損をします。次章で、その損のかたちを具体的に見ていきます。

発注者が損する“失敗パターン”

筆者は受託・自社サービスの双方で発注と受注を経験してきました。その中で繰り返し見てきた、発注者側の典型的な損のパターンを2つ挙げます。

パターン1：請負で「仕様変更地獄」に陥る

請負は完成義務がある反面、スコープを後から動かしにくいのが弱点です。契約時に固めた仕様を前提に金額と納期が決まるため、開発が進んでから「やっぱりこの画面を変えたい」「この機能を足したい」となると、そのつど追加見積り・契約変更が発生します。

実際にありがちなのは、要件が固まりきっていないのに請負で契約してしまうケースです。要件定義の精度が低いまま着手すると、変更が出るたびに費用と納期が膨らみ、発注者は「変えるたびにお金がかかるなら言い出しにくい」と感じ、結果として使いにくいものが完成してしまうことすらあります。これは丸投げ発注に共通する構造で、開発外注の失敗でも詳しく扱っています。

パターン2：準委任で「成果が曖昧」になる

逆に準委任は柔軟ですが、完成義務がない分、「で、結局何ができたのか」が曖昧になりやすいのが弱点です。稼働に対して報酬が発生するため、ゴールや優先順位の合意が緩いと、「毎月稼働はしているが、欲しかったものが前に進んでいない」という状態になりかねません。

これは契約形態そのものの欠陥ではなく、運用設計の問題です。準委任でも、スプリントごとの成果物、優先度の決め方、定例での進捗確認といった「進め方の合意」をきちんと敷けば、成果は十分に可視化できます。準委任を選ぶなら、契約形態の柔軟さに甘えず、進め方を設計することが発注者の務めになります。

場面別の選び方

どちらが得かは案件次第です。要件の固さと開発スタイルから、場面別の目安を示します。あくまで一般的な傾向であり、最終判断は契約内容と専門家の確認をふまえてください。

  • 要件が固いとき（請負が向きやすい）：仕様・画面・データ設計まで確定しており、変更がほぼ見込めない開発。基幹システムの定型的な置き換えや、明確な完成形がある単発開発など。成果と金額を固定できるメリットが活きます。
  • 要件が曖昧／動くとき（準委任が向きやすい）：これから要件を詰める、市場の反応を見て方向を変える可能性がある開発。固定見積りにすると変更コストで損をしやすいため、稼働ベースで柔軟に進められる準委任が合います。
  • アジャイル開発（準委任が向きやすい）：スプリントごとに優先度を見直し、作るものを調整していく進め方は、完成義務を固定する請負と相性が悪いとされます。準委任で、優先度の調整を前提に契約するのが一般的です。
  • PoC・検証フェーズ（準委任が向きやすい）：成果より「やってみて判断する」ことが目的のため、完成を約束する請負はそもそも馴染みません。期間と稼働を区切った準委任が現実的です。
  • ラボ型開発（準委任が基本）：一定の人員を月単位で確保し、継続的に開発を回す形態。準委任を月額で組むのが一般的で、増減や優先度変更に対応しやすいのが利点です。

迷ったときの考え方はシンプルで、**「完成形が今ハッキリ描けているか」**を起点にすると整理しやすくなります。描けているなら請負、描ききれない・動く前提なら準委任、と当たりをつけたうえで詳細を詰めるのが実務的です。

契約前チェックリスト

契約形態を決めたら、契約書のレビューで以下を必ず確認してください。発注者が後で揉めやすい論点を絞っています。

  • 検収の基準：何をもって「完了・合格」とするかが具体的に定義されているか。検収期間・検収方法・不合格時の取り扱いが書かれているか。
  • 契約不適合（旧・瑕疵担保）への対応：請負の場合、不具合が見つかったときの対応期間・範囲・無償修正の条件が明確か。一般に契約不適合責任は通知期間に定めがあるとされるため、期間の記載を確認する。
  • 再委託の可否と範囲：受注者が第三者に再委託できるか、その場合の責任の所在や情報管理はどうなるか。ブラックボックス化を避けるうえで重要です。
  • 優先度・スコープ変更のルール：準委任なら、優先度を誰がどう決めるか、変更の合意プロセスはどうか。請負なら、追加・変更時の見積りと契約変更の手順が定まっているか。
  • 成果物と権利の帰属：ソースコード・ドキュメントの納品範囲と、著作権など権利の帰属先が明記されているか。
  • 指揮命令と業務形態：準委任で発注者が細かく指示する想定なら、偽装請負の論点に触れないか（業務の進め方は受注者の裁量に委ねる形が一般的とされる）。

繰り返しになりますが、これらは一般的な確認観点であり、個別の契約の妥当性は弁護士など専門家の確認を受けてください。なお、TechMate自体の契約・取引条件は取引条件のページに明記しています。

月額の準委任で柔軟に進める例

要件が動く開発や、社内に技術判断ができる人がいない状況では、月単位の準委任で伴走してもらう進め方が現実的な選択肢になります。TechMateはまさにこの形を基本にしたサービスです。

TechMateは月単位の準委任契約が基本で、最低2か月からの利用を推奨しています。代表・PMの馬込浩を中心に2名以上の体制で入り、受託会社・自社サービス会社のどちらの開発にも対応します。準委任の弱点である「成果が曖昧になりやすい」点に対しては、定例での優先度すり合わせや進捗の可視化を前提に進めることで、柔軟さと成果の両立を図ります。

固定見積りの請負では仕様変更のたびに損をしやすい、かといって人を採用するには時期尚早——そうした「動く前提の開発」に、月額で増減・優先度変更しやすい準委任伴走は相性が良い選択肢です。料金や体制の詳細は月単位の準委任プランをご確認ください。導入が自社に合うか迷う段階でも、無料相談で具体的なケースに即してお話しできます。

よくある質問

Q. 途中で準委任から請負（またはその逆）に契約形態を変えられますか？ A. 双方が合意すれば、フェーズの区切りで契約を切り替えることは実務上よく行われます。たとえば準委任で要件と方向性を固め、仕様が確定した段階で個別機能を請負に切り出す、という進め方です。新たな契約として条件を取り決め直す形が一般的です。

Q. 準委任のほうが安く見えますが、本当に得ですか？ A. 月額の見た目だけでは判断できません。要件が動く開発を請負にすると、変更のたびの追加費用や手戻りでかえって高くつくことがあります。逆に要件が固い開発を準委任にすると、稼働の割に成果が薄く感じることもあります。「変更がどれだけ見込まれるか」で総額が変わると考えるのが実務的です。

Q. 偽装請負が心配です。準委任で指示を出すのは問題になりますか？ A. 一般に、準委任では業務の進め方を受注者の裁量に委ね、発注者は直接的・日常的な指揮命令を行わない形が望ましいとされます。優先度や要望を伝えること自体は通常の範囲ですが、線引きが不安な場合は契約内容を専門家に確認してください。

準委任と請負は「どちらが正解」ではなく、案件の要件がどれだけ動くかで選び分けるものです。要件が固いなら請負、動く前提なら準委任の伴走——この基本を押さえれば、発注者が損をする失敗パターンの多くは避けられます。

自社の開発がどちらに向いているか、契約形態をどう設計すべきか迷ったら、具体的なケースをお聞かせください。無料相談（30分）はこちらからお申し込みいただけます。