準委任と請負、どちらで外部開発を発注すべきか
「外部の開発チームに頼みたいが、準委任と請負のどちらで契約すべきか分からない」——プロダクト開発の発注で最初につまずくのがこの選択です。ここを間違えると、成果物が曖昧なまま費用だけがかさむ、要件変更のたびに追加見積もりで揉める、あるいは知らないうちに偽装請負という労務リスクを抱える、といった事態になります。
この記事では、どちらの契約形態が向いているかを判断するための具体的な基準を、契約条件の違い・費用感・チェックリストとともに、発注者の視点で整理します。
準委任と請負の違いを一言で
- 請負: 「決めた成果物を完成させること」を約束する契約（民法632条）。完成責任は受注側にあり、未完成なら報酬は原則発生しない。仕様が固まっているほど向く。
- 準委任: 「決めた稼働・専門性を提供すること」を約束する契約（民法656条）。完成責任ではなく、善良な管理者の注意義務（善管注意義務）をもって業務を遂行することが対象。仕様が動くほど向く。
つまり 「作るものが確定しているか」 が分かれ目です。ここから先、両者は検収・責任・指揮命令の3点で具体的に違ってきます。
契約条件の違い：発注者が実務で効いてくる3点
1. 検収と支払いのタイミング
- 請負: 成果物を納品→検収（発注側が仕様通りか確認）→検収完了をもって支払い義務が発生、が基本形。検収に落ちれば修正義務は受注側にあり、追加費用は発生しない（契約範囲内の不具合なら）。
- 準委任: 稼働した分（月額・工数）に対して支払いが発生する。成果物の出来不出来にかかわらず、稼働の実態があれば報酬請求権が発生するのが原則。だからこそ発注側は「何にその稼働を使ったか」を可視化する仕組み（週次報告・スプリントレビュー・バックログの消化状況）を契約と別に持っておく必要がある。
2. 契約不適合責任（旧・瑕疵担保責任）
請負契約には契約不適合責任が発生する。納品物が契約内容と異なる（バグがある、仕様と違う）場合、発注側は追完請求（修正）・代金減額・損害賠償・契約解除を求められる（民法562〜564条、2020年改正で「瑕疵担保責任」から名称・内容が変更）。この責任は契約書に期間の定めがなければ、契約不適合を知った時から1年以内に通知すれば主張できる（民法637条）。多くの受託契約では「検収後6か月」「1年」など期間を短縮する特約を入れているため、契約書のこの条項を必ず確認する。準委任にはこの契約不適合責任がなく、代わりに善管注意義務違反（重過失・注意不足による損害）を問う形になるが、立証のハードルは請負より高い。
3. 指揮命令権と偽装請負リスク
ここが発注者が知らずに踏みがちな法的リスク。請負・準委任いずれの契約でも、発注側が受注側のメンバーに直接指揮命令（作業時間の指定、日次のタスク割り振り、常駐席での上司的な管理）を行うと「偽装請負」とみなされうる（職業安定法・労働者派遣法違反）。
- 準委任は「業務委託」であって「労働者派遣」ではないため、発注側は受注側の担当者に対して指揮命令をしてはならない。「何を」達成してほしいかは合意できるが、「誰が」「何時から何時まで」「どの順番で」作業するかは受注側の裁量。
- 実務でありがちな踏み外し: 常駐エンジニアに対して発注側の上長が直接朝会で指示を出す、Slackで「今日中に◯◯やって」と個人タスクを割り振る、発注側の勤怠システムに打刻させる——これらは偽装請負の兆候として労基署の是正指導対象になりうる。
- 対策は、窓口を受注側のPM・リーダー1人に絞り、タスクの割り振りは受注側に委ねること。準委任型のラボ契約・チーム常駐型を組むときほど、この線引きを契約書と運用ルールの両方で明文化しておく必要がある。
請負が向いているケース
- 作りたい機能・画面・仕様が、発注前にかなり具体的に決まっている（画面数・API仕様・データ構造が見積もり可能な粒度）
- 「この範囲をこの金額で、この期日までに」と切り出せる
- 例: 既存仕様書があるリニューアル、決まった帳票の出力機能、確定したAPIの実装、管理画面への機能追加1本
費用の考え方: 範囲と成果物が切り出せるぶん、着手前に費用と納期の見通しが立てやすい。期間は小〜中規模の機能追加で数週間、要件定義から必要な中規模開発（MVP相当）で数か月が目安になる（要件の複雑さで大きく変動する）。
請負のメリットは、費用と納期の見通しが立てやすいこと。デメリットは、途中で仕様を変えると再見積もり（変更契約・追加発注）になり、変更が多いと結局割高・遅くなることです。目安として、要件変更が全体スコープの2割を超えるようなら、そもそも請負に向いていない仕事だったサインと見てよいでしょう。
準委任が向いているケース
- 何を作るべきか自体が、走りながら固まっていく
- 新規プロダクト・MVP・PoCで、検証しながら方向を変える前提がある
- CTOやPdMの右腕として、要件整理から実装・改善まで継続的に入ってほしい
- リリース後の改善フェーズ（機能追加・グロース施策・障害対応が混在し、事前に範囲を切れない）
費用の考え方: 稼働量（フルタイム相当か部分稼働か）と、求める人材の役割（実装中心か、要件整理・PdM的な上流も含むか）で月額が決まる。稼働に対して支払う形のため、何を作ったかを発注側が握れているかが費用対効果を左右する。
準委任のメリットは、要件変更に柔軟で、意思決定のスピードが落ちないこと。デメリットは、稼働に対して支払うため「何を作ったか」を発注側が握れていないと成果が見えにくくなることです。だからこそ、準委任ではバックログと優先順位を発注側と共有し続けることが成否を分けます。具体的には、週次でスプリントレビュー（デモ＋消化タスクの確認）を設定し、次週のバックログを発注側が承認する運用を最低限のガバナンスとして敷くことを推奨します。
判断チェックリスト
以下の項目にYesが多いほど請負向き、Noが多いほど準委任向きです。
- 画面・機能一覧を今の時点でリストアップできるか（Yes=請負向き）
- 途中で「やっぱりこの機能はいらない／別の機能に差し替えたい」が起きない自信があるか
- 発注側に、要件を最初に固め切る時間と専門知識（PdM的な役割）があるか
- 納期が固定で、遅延リスクを受注側に負ってほしいか
- 検収基準（何をもって「完成」とするか）を文章で書き下せるか
逆に、以下に当てはまるなら準委任を検討すべきサインです。
- ユーザーの反応を見てから機能の優先順位を変えたい（PoC・MVP段階）
- 発注側に開発の内製化を進めたい意図があり、伴走してほしい
- リリース後の運用フェーズで、機能追加と保守・改善が混在して事前に線引きできない
- 「まず動くものを見てから決めたい」状態で、仕様書自体がまだ書けない
「請負で入り準委任で続ける」をフェーズ別に具体化する
多くのtoBプロダクト開発では、最初から一方に決めきらないのが現実的です。torcheeesでも、次の流れを推奨しています。
- フェーズ1（2〜4週間・請負）: 要件整理・開発診断——課題整理・優先順位付きバックログ・技術構成案を成果物として切り出し、請負で発注する。ここで「作るべきもの」の解像度を上げ、次フェーズの見積もり精度も上がる。
- フェーズ2（1〜3か月・状況に応じて）: 開発フェーズ——スコープが固まっていればMVPを請負で（費用目安は前述の中規模開発レンジ）。走りながら変わる前提なら準委任で月次契約に。
- フェーズ3（継続・準委任）: リリース後の改善——改善は要件が動き続けるため、月額の準委任・チーム支援に接続する。週2〜3日の部分稼働から始め、事業の伸びに応じて稼働量を調整するケースが多い。
この「請負で入り、準委任で続ける」形は、費用の見通しと変更への柔軟性を両立させる現実解です。フェーズの切れ目ごとに契約形態を見直すという前提を、最初の契約時点で発注側・受注側の双方が合意しておくと、後のフェーズ移行がスムーズになります。
失敗しやすいパターン（具体例）
- 仕様が曖昧なのに請負で発注する: 「ざっくりこんな管理画面が欲しい」という要望だけで請負発注し、いざ納品されたものが「思っていたのと違う」となるケース。完成責任を負う受注側は、曖昧さをリスクとして高めに見積もるか、記載のない部分は受注側の解釈で進める。結果、検収で揉めて追加費用の交渉になり、当初想定より2〜3割高くつくことも珍しくない。
- 成果を握らずに準委任で丸投げする: バックログを共有せず「お任せします」で稼働だけ買うと、3か月経って「請求書は毎月来るが、何がリリースされたのか分からない」状態になる。週次レビューを設定していないケースでよく起きる。
- 契約形態だけで比較する: 「請負の方が安心」「準委任の方が柔軟」という表面的な理解だけで選び、本質である「作るものが確定しているか」を整理しないまま契約すると、形態と実態がずれて機能しない。
- 常駐準委任で発注側が直接指示を出してしまう: 悪意なく「早く進めたいから」で担当者に直接タスクを振り続けた結果、偽装請負の状態になっていたケース。契約書上は準委任でも、実態が労働者派遣に近ければ是正指導の対象になりうる。窓口を1本化するルールを事前に敷いておくことで防げる。
まとめ
- 作るものが確定 → 請負、走りながら固まる → 準委任。契約不適合責任の有無・検収の要否・指揮命令の可否が、実務上の具体的な違い。
- 準委任型で常駐・チーム型の体制を組むときは、偽装請負リスク（発注側からの直接指揮命令）に注意し、窓口を1本化する。
- 迷ったら「要件整理を小さく請負で始め、開発・改善は状況に応じて準委任へ」が実務的。判断チェックリストのYes/Noで方向性を仮決めしてから相談すると精度が上がる。
- どちらの形態でも、バックログと優先順位を発注側と共有し続けることが成否を分ける。
契約形態の選び方に迷う段階から、まずは開発課題の整理からご相談いただくのがおすすめです。発注前の見積もり精度を上げたい方は開発の見積もりがどう決まるか、開発パートナー選び全般で迷っている方は開発パートナーの選び方も参考にしてください。既存プロダクトの改善から始めたい場合は既存プロダクト改善の最初の一手もあわせてご覧ください。
torcheees は請負・準委任のどちらにも対応し、初回の「要件整理・開発診断」から継続的な開発支援まで、状況に合わせて進め方を提案します。契約形態の選び方も含めて、まずは開発課題の整理からお問い合わせください。