準委任と請負は、好みで選ぶものではありません。
請負は「完成した成果物」に対してお金を払う契約、準委任は「専門家の稼働（働き）」に対してお金を払う契約です。そして、どちらを選ぶべきかを決めるのは会社の方針ではなく、「要件がどれだけ固まっているか」という事実のほうです。要件が固まっているなら請負、流動的なら準委任。この原則を外すと、契約形態そのものがトラブルの火種になります。
この記事では、両者の違いと選び方、契約不適合責任の扱い、そして「要件の固まり具合に自信がない」ときの現実的な選択肢までを、非エンジニアの発注担当者に向けて解説します。
準委任と請負は何が違いますか？
請負と準委任の違いは、次の5点で整理できます。
【対価の対象】
- 請負：成果物の完成 ・準委任：業務の遂行（稼働時間・工数）
【開発会社の責任】
- 請負：完成させる責任（完成責任）を負う ・準委任：専門家として誠実に業務を行う責任（善管注意義務）を負う
【仕様変更】
- 請負：原則、追加見積もり・契約変更が必要 ・準委任：柔軟に対応しやすい
【費用】
- 請負：原則固定（合意した金額） ・準委任：稼働に応じて変動
【向く状況】
- 請負：要件が固まっている ・準委任：要件が流動的・伴走してほしい
言い換えると、請負は「結果を買う」契約、準委任は「プロの時間と専門性を借りる」契約です。※準委任は法律上「委任」の一種で、システム開発の実務では一般に「準委任契約」と呼ばれます。本記事は一般的な整理をご紹介するもので、個別の契約条件は案件ごとに異なります。
請負が向くのはどんなケースですか？
「何を作るか」が明確に固まっているケースです。仕様書があり、「これができたら完成」という定義がはっきりしているなら、請負は発注側にとって分かりやすい契約です。金額は原則固定され、成果物の完成が対価支払いの前提となります（途中で終了した場合の精算方法など、具体的な扱いは契約条件によります）。予算が先に決まっている稟議文化の企業とも相性がよい形態です。
また、請負では引き渡した成果物が契約内容に適合しない場合、開発会社が契約不適合責任を負います。以前は「瑕疵担保責任」と呼ばれていたもので、納品後に契約と異なる不具合が見つかった場合、修補や代金減額などを求められる余地があります（具体的な範囲や期間は契約条件によります）。
ただし、この安心感には前提があります。「契約内容＝仕様」が明確に文書化されていることです。仕様が曖昧なら、「契約に適合しているかどうか」の判定基準そのものが存在しないことになり、責任を問うにも問えません。請負の保護は、仕様の明確さとセットで初めて機能します。
準委任が向くのはどんなケースですか？
要件がまだ流動的で、走りながら固めていくケースです。新規事業やAI活用のように「作ってみないと正解がわからない」領域では、仕様を最初に確定させること自体が困難です。無理に確定させても、検証が進めば必ず「やっぱりこうしたい」が出てきます。準委任なら、検証結果を見ながら方向転換ができます。変化を前提にした契約だからこそ、AI活用のような不確実性の高いテーマと相性がよいのです。
一方で、準委任では開発会社は完成責任を負いません。成果物の完成が保証されない代わりに、専門家チームの稼働を柔軟に使える——このトレードオフを理解した上で選ぶことが大切です。「完成保証がないなんて不安だ」と感じるかもしれませんが、要件が動く前提のプロジェクトでは、固定した完成物を約束させること自体に無理があります。無理な約束は、品質か関係性のどちらかにしわ寄せが行きます。
準委任を選ぶ場合、発注側にも役割があります。進捗を一緒に確認し、意思決定に参加すること。丸投げではなく伴走が前提の契約だからこそ、報告の頻度・体制・成果の確認方法を契約時に具体的に決めておいてください。
要件が固まっていないのに請負で発注するとどうなりますか？
これが実務上、最もトラブルになりやすいパターンです。
請負は「仕様が決まっていること」が最低ラインの契約です。要件が曖昧なまま請負で契約すると、開発の途中で仕様変更が必ず発生します。そのたびに**「それは元の契約範囲か、追加費用か」の揉め事**が起きます。発注側は「当然含まれていると思っていた」、開発側は「聞いていない」。追加見積もり、納期延長、相互不信——最悪の場合、プロジェクトそのものが頓挫します。
なお、こうした「契約範囲の解像度」は、実は契約前の見積書の段階である程度見抜けます。工程の内訳が具体的か、「一式」表記が多くないか——見積書の読み方は別記事「見積書のどこを見れば技術力がわかるか」で詳しく解説しています。【見積書のどこを見れば技術力がわかる？】
さらに根深いのが、「何をもって仕様が決まったとするか」が曖昧になる問題です。打ち合わせで口頭合意したつもりでも、議事録がなければ後から「言った・言わない」になります。請負で進めるなら、「◯月◯日にこの内容で合意した」というエビデンスを双方で残し、その後の変更は追加見積もりか次フェーズへ回す——この変更管理の規律が、請負契約の生命線です。
「固定金額で安心だから請負にしたい」という気持ちはよくわかります。しかし要件が固まっていない段階での請負は、安心どころか揉め事の予約になりかねません。契約形態は先に決めるものではなく、要件の固まり具合という「事実」に合わせて選ぶものです。もし今、要件が固まっているか自信を持って言えないなら、それは契約形態を決めるタイミングではない、というサインです。
【補足】要件定義の後から「見えていなかった業務」が出てくる
過去の経験ですが、これは本当に多い例として挙げます。要件定義が終わった後に、新しい（見えていなかった）業務フローが出てくることです。
だいたい会社のDX部門の担当者や情報システム部門の担当者の方がいたりしても、会社の業務の細かいフローまでを把握していない場合がほとんどですし、私も会社の全業務のフローを隅から隅までわかっているわけじゃないです。
ですから現場担当者にヒアリングするのですが、そのヒアリングをうまくできるかどうかに重要なポイントが秘められています。ただ、これができる人はなかなかいないです（そもそもこれが、コンサルタントというプロフェッショナルが世の中で必要とされている理由でもあります）。
なので体感としては、ほとんどのお客さんの案件は準委任が適切なケースが多いです。それでも会社の都合で予算を確定させて請負でやりたいという場合もあると思いますが、その場合は要件定義に入る前に、必ずシステムコンサルのフェーズを入れて、業務フローややりたいことの整理から入るのが良いと思います。
もちろん、そういった業務フローやシステム的なコンサル部分も、まずは無料で相談していただきたい部分となります。
契約形態を決める前に「まず作って確かめる」という選択肢
ここまで読んで、「そもそも、うちの要件がどれくらい固まっているのか自信がない」と感じた方も多いはずです。実は、それが普通です。そして、その状態で契約形態を先に決める必要はありません。
そこで有効なのが、PoC（概念実証）の考え方——つまり、契約や本開発の前に「小さく作って確かめる」というアプローチです（PoCの基本は別記事「PoCとは？」で解説しています）。
ワンテックワールドの「ゼロスタート」（無料プロトタイプ作成サービス）では、契約の前に動くプロトタイプを無料で作成し、認識を揃えてから、買取・準委任・請負の中から契約形態を選択できます（もちろん辞退も可能です）。
選択肢が3つあるのもポイントです。買取は、作成したプロトタイプ（の権利や資産）を買い取ってそのまま活用する形。検証した内容がそのまま使えると判断できたときの最短ルートです。請負は、プロトタイプで固まった仕様をもとに、完成保証のある本開発として進める形。そして準委任は、検証を続けながら伴走で育てていく形です。つまり、プロトタイプを見た時点の「要件の固まり具合」に応じて、この記事で解説してきた選び方の原則をそのまま適用できるようになっています。
動くものを見れば、要件がどこまで固まっていて、どこが流動的なのかが具体的にわかります。「固まっている部分は請負で、検証が必要な部分は準委任で」といった、フェーズごとの現実的な組み合わせも、プロトタイプを見た後なら判断できます。契約形態の選択は、要件の解像度が上がってからのほうが失敗しません。
【補足】なぜ「辞退できる」形にしているのか
ゼロスタートで実際に作ってみると、開発会社側でも「あと、どのようなことをしたら完成に導けるのか？」という道筋が見えてきます。
そうすると、要件はだいたいこれくらいで固められて、開発はこのくらいだろうという算段がつく請負型が適切なものも出てきますし、逆に変動要素が多く、検証的に走りながら修正していく準委任型が適切なものもわかります。
その上でお客さんが「PoCで小さく始めるべきか？」「本開発に踏み込むべきか？」「いったん辞退すべきか？」の判断ができるというのは、開発市場においてお客さんも開発会社もwin-winになる一つの形だと思っているのです。
開発会社は、何もお金を稼ぎたいだけではないです。特にエンジニアは「世の中で使われるシステムを作りたい」という欲求があります。ですから、何でもいいからお金のもらえる契約をしたいのではなく、お客さんに喜んでもらえて、ユーザーが便利に使ってくれる、そんなシステムを作っていくのが喜びなんです。
だから、辞退することも一つの判断として尊重したいという想いがあります。
まとめ：迷ったら「要件の固まり具合」に立ち返る
最後に、この記事の要点を振り返ります。
- 請負は「結果を買う」契約。要件が固まっているなら請負
- 準委任は「プロの時間と専門性を借りる」契約。要件が流動的なら準委任
- 要件が曖昧なまま請負で契約すると、仕様変更のたびに揉め事になる
- フェーズごとに契約形態を分ける（検証は準委任、本開発は請負）のも現実的な方法 ・要件の固まり具合に自信がないなら、契約の前に「まず作って確かめる」
なお、本記事の契約解説は一般的な整理です。個別の契約条件は案件によって大きく異なりますので、実際の契約前には必ず専門家や開発会社にご相談ください。WEB開発ナビでは、企画段階からプロのエンジニアに無料で相談できます。契約形態の悩みも、遠慮なくお持ちください。
よくある質問
Q. 準委任だと、開発会社は「完成しなくても責任を取らない」のですか？
A. 完成責任は負いませんが、無責任という意味ではありません。準委任でも開発会社は専門家として誠実に業務を遂行する義務（善管注意義務）を負います。進捗報告の頻度や体制など、稼働の中身をどう担保するかを契約時に確認してください。
Q. ラボ型開発と準委任は同じものですか？
A. ラボ型開発は「専属の開発チームを一定期間確保する」開発スタイルの呼び名で、契約形態としては準委任で締結されるのが一般的です。スタイルの名前と契約形態の名前が混在しやすいので、契約書上どちらの形態かを必ず確認してください。
Q. 途中で請負から準委任へ（またはその逆へ）切り替えることはできますか？
A. フェーズごとに契約形態を分けることは実務上よく行われ、要件の固まり具合の変化に契約を合わせる合理的な方法です。たとえば要件定義や検証は準委任で行い、仕様が固まった開発フェーズは請負で契約する、という組み合わせです。切り替えの条件は事前に開発会社と協議してください。
無料で相談する →こちら