ラボ契約と請負契約・準委任契約の違い｜オフショア開発の契約形態の選び方

オフショア開発を調べていると、 「ラボ契約」という言葉をよく目にします。

請負契約との違い。準委任契約との関係。 専属チーム。仕様変更への柔軟性。

言葉としては見かけるけれど、 具体的に何がどう違うのか、はっきりとはわからない。

実は、この「わかりにくさ」には理由があります。

この違いが腑に落ちると、 ベンダー資料の読み方も、打ち合わせでの質問も変わってきます。

そしてこの理解は、今まさに必要になっています。 オフショア開発の現場では、 ラボ型（準委任型）の契約が主流になりつつあるからです。

この記事では、Rabiloo（ラビロー）が スタートアップや新規事業の開発を支援する中で見えてきたことをもとに、 ラボ契約の仕組み、請負契約との違い、 そしてそれぞれのリスクと選び方を整理します。

ラボ契約と請負契約の決定的な3つの違い（準委任契約との関係）

ソフトウェア開発の外注には、 大きく分けて2つの契約形態があります。 「請負契約」と「準委任契約」です。

オフショア開発では、 この準委任契約が「ラボ契約」という名前で登場します。 （自社専用の開発チーム＝開発ラボを設置することから、そう呼ばれます）

実務において、この2つの契約形態はプロジェクトの進め方を根底から変えます。 発注者が比較検討する上で、絶対に理解しておくべき「3つの決定的な違い」を整理しました。

1. 責任の所在（成果物の完成か、業務の遂行か）

最大の法的違いは「約束するもの」です。

請負契約（民法第632条）は、「システムの完成」に対して報酬が支払われます。 一方のラボ契約（民法第656条）は、エンジニアが適切に稼働したこと（善管注意義務）に対して対価が発生します。

シンプルに言い換えると、こうなります。

• 請負契約 ＝「決められた納期までに、完成品を納品してもらう」契約

• ラボ契約 ＝「人（チーム）を一定期間確保し、その中で開発を進める」契約

請負は、何を・いつまでに作るかが決まっていて、 その完成と納品に対してお金を払います。 納期に遅れればベンダーの責任（債務不履行）です。

ラボは、誰が作るかを確保して、その稼働に対してお金を払います。 「いつまでに何を完成させるか」は契約上の義務ではなく、 発注者とチームが一緒に計画し、優先順位で調整していくものです。

「完成を保証してくれないなんて不利だ」と感じるかもしれません。 しかし、これは次の「柔軟性」という最大のメリットを得るためのトレードオフです。

2. 要件変更への柔軟性（硬直的 vs 柔軟）

ここが実務上、最も差がつくポイントです。

請負契約は、契約に基づいて仕事をします。 ベンダーが行うのは、契約で決められた作業だけです。

逆に言えば、契約に書かれていないタスクはそもそもできません。

途中で「やっぱりこの画面を変えたい」「この機能を追加したい」となった場合、 契約をし直す必要があります。 当然、当初の納期にも影響します。

完成が約束されている安心感がある反面、 ベンダー側は「契約通りに完成させなければならない」というリスクを負っています。 そのため仕様をガチガチに固め、 予期せぬトラブルに備えた「リスクバッファ」を見積もりに上乗せします。

対するラボ契約は、チームのスキルと労働力に対して対価を支払う契約です。 ベンダーが責任を負うのは、与えられたタスクの遂行であり、成果物の完成ではありません。

そのため、期間内であれば何を作るか、何を優先するかは自由に変えられます。

3. マネジメントの主体（ベンダー vs 発注者）

3つ目の違いは、プロジェクトを牽引するのは誰かという点です。

請負契約では、どう作るかのプロセスはベンダーに委ねられます。 発注者の仕事は「要件を伝えること」と「納品物をテストすること」だけです。

しかしラボ契約では、マネジメントの主体は発注者側に移ります。

発注者は「プロダクトオーナー」として、 チームに対して「今週は何を優先すべきか」を常に提示し続ける必要があります。 ベンダーと発注者という壁を取り払い、 一つのチームとして伴走する体制が求められます。

補足1：なぜオフショア開発でラボ型が主流になっているのか

日本のシステム開発は長らく「請負」が当たり前でした。 しかし現在、DXや新規事業のアプリ開発において、 「最初に決めた要件が最後まで変わらない」ことはほぼありません。

ユーザーの反応を見ながら優先順位を変え、走りながら作り続ける。 このアジャイルな開発スタイルにおいて、仕様変更のたびに再見積もりが必要な請負契約は、構造的に機能しにくくなりました。

「作りたいものをフェーズごとに拡大し、作るためのチームを確保する」。 この発想が広まったことで、オフショア開発の主流はラボ型へと移行してきています。

補足2：派遣契約との違い（指揮命令権の所在）

「期間で人を確保するなら、派遣と同じでは？」 そう誤解されることがありますが、明確な違いがあります。 それは指示系統（指揮命令権）の所在です。

派遣契約の場合、エンジニアは発注者の指揮下に入ります。 直接「これをやってくれ」「残業してくれ」と指示ができます。

一方、ラボ契約（準委任）の場合、発注者に直接の指揮命令権はありません。 発注者が行うのは、ベンダー側の管理者（ブリッジSEなど）に対する【業務の依頼】です。 それを受けた管理者が、自社のエンジニアに作業指示を出します。

これを混同して直接指示を出すと「偽装請負」などのコンプライアンス違反になるため、注意が必要です。

ラボ契約と請負契約、どちらを選ぶべきか？（案件別の判断基準）

ラボ契約と請負契約に、絶対的な優劣はありません。 「自社の開発プロジェクトにおいて、仕様変更がどの程度発生するか（ビジネスの不確実性）」によって、選ぶべき契約形態は決まります。

ラボ契約（準委任契約）が向く案件

• DX推進や新規事業におけるプロダクト開発

• アジャイルで仮説検証と改善を繰り返したい案件

• リリース後も継続的な保守・エンハンス開発が必要な案件

作ってみなければユーザーの反応がわからない新規事業や、 業務フローの大幅な見直しを伴うDX推進。

こうした領域において、「最初に決めた要件」が正解であることは稀です。 「変化することが前提」のプロジェクトには、 都度の再見積もりが不要で、柔軟に方向転換できるラボ契約が適しています。

実際、Rabilooのクライアントの約70%がラボ契約を選択しています。 これは、現代のシステム開発において 「仕様を固定しきれないプロジェクト」がいかに多いかを示しています。

請負契約が向く案件

• 既存システムの完全なリプレイス（機能変更なし）

• 仕様が100%確定しており、後から一切変更が発生しない案件

• 予算の上限が厳格に決まっており、1円も動かせない案件

「Aというシステムを、全く同じ機能のまま新しい言語で作り直す」。 こうしたゴールが明確で不確実性のない案件であれば、 完成責任をベンダーに持たせる請負契約のメリットが活きます。

また、社内の稟議構造上、 「完成品の機能と予算」を最初に完全に固定しなければ発注できない場合も、 請負契約を選択せざるを得ません。 （ただしこの場合、途中の仕様変更は諦める必要があります）

ラボ契約（準委任型）を成功させる体制設計のポイント

初めて開発を外注する際、多くの方が 「まずはこのシステムを1つ、いくらで作ってくれるか」と考えます。 これは、非常に自然な発想です。

しかし、スタートアップや新規事業において、リリースはゴールではなくスタートです。 ユーザーの反応を見ながら、長期的にプロダクトを育てていくのであれば 毎回ゼロからベンダーを探してプロジェクトを立ち上げるより、 自社専属のチームを確保し、その中でタスクを回す（ラボ契約）方が、 圧倒的に理にかなっています。

チームを固定する最大のメリット「ノウハウの蓄積」

同じチームで開発を続ける最大の恩恵は、 ベンダー側に自社のビジネスやシステムの「ノウハウが蓄積されること」です。

請負契約で毎回違うベンダーやチームに発注していると、 その都度、ドメイン知識の共有やルールのすり合わせから始めなければなりません。 しかし、ラボ契約でチームを固定すれば、 お互いの考え方やコードの癖が完全に共有されていきます。

結果として、「あうんの呼吸」で開発が進むようになり、 開発スピードが飛躍的に上がり、品質も安定していくのです。

ただし「丸投げ」はNG（発注者に求められるマネジメント力）

このように、長期的なパートナーシップにおいてラボ契約は最強の仕組みです。 しかし、発注者として必ず理解しておくべき注意点があります。

それは、ラボ契約はクライアント側にもマネジメント力が求められるということです。 決して「丸投げ」には向きません。

「仕様書がなくても作ってくれる」という誤解

「アジャイルで柔軟に対応してくれるなら、 仕様書をカッチリ作らなくてもベンダーがいい感じに作ってくれるだろう」。

これは、初めてラボ契約を利用する発注者が陥りがちな誤解です。

目的が曖昧なままチームだけを確保しても、 エンジニアは何を作ればいいかわかりません。 コストだけが月額で消費されていく「迷走状態」に陥ります。

ラボ契約における「バグ対応」の正しい認識

請負契約の感覚が抜けていない発注者が、 最も起こしやすいトラブルが「不具合の無償対応要求」です。

請負契約では、納品後に見つかったバグは ベンダーの責任（瑕疵）として無償で修正されます。

しかしラボ契約において、「納品」にあたるのは システム全体の完成ではなく「月ごとのタスクの完了」です。 発注者の受け入れテストで指摘が出なければ、そのタスクは完了とみなされます。

アジャイルにバージョンアップを繰り返す中で、 「初期のテスト環境では問題なかったが、本番環境で動かしたら不具合が生じた」 というのは、ソフトウェア開発では日常茶飯事です。

ここで「品質が悪い」「手戻りだ」とベンダーに責任を押し付け、 無償での修正を要求してしまうケースが後を絶ちません。 これは準委任契約の性質を理解していないために起こる軋轢です。

ただし、受け入れテスト期間中に見つかった不具合は、 合意したタスクの完了確認の一部として、その月の工数内で優先的に対応します。 また、ベンダー側の明らかな作業ミスや注意義務違反による不具合であれば、 責任範囲の協議対象になります。

重要なのは、「バグ＝すべて無償修正」と短絡的に考えるのではなく、 検収条件、発生原因、合意済みの仕様との関係を 冷静に切り分けて判断することです。

発注者側に「判断できる人（PO）」を置く

ラボ契約をマネジメントし、成功させる最大の鍵は、 日本側（発注者側）にプロダクトオーナー（PO）を配置することです。

プロダクトオーナーとは、 「限られた期間とリソースの中で、何を優先するか」 というビジネス上の判断を下す責任者です。

開発途中で「Aの機能も、Bの機能も欲しい」となったとき、 ベンダー側は「どちらを先に作りますか？」と問いかけます。 このとき、即座にジャッジできる体制がなければ、 アジャイルな開発スピードは生まれません。

「契約形態の選び方」とは、 ベンダーにどう責任を負わせるかという話ではありません。 「自社がどこまでプロジェクトの判断に関与できるか」。 この体制を作るための構造設計なのです。

自社だけで要件の判断を頻繁に行うのは難しい。 そうした場合は、ラボ契約でチームを確保しつつ、 事業目的に踏み込んで伴走してくれるパートナーを選ぶ必要があります。 （※パートナー企業の選び方については、ベトナムオフショア企業の選び方｜比較表では見えない3つの判断軸で詳しく解説しています）

よくある質問（FAQ）

Q. ラボ契約で納期は保証されますか？

A：法的な「納期保証」はありません。代わりに、スプリント計画とスコープ調整で納期をコントロールします。

請負契約のように「〇月〇日までに完成させる」という法的義務は、 ラボ契約（準委任契約）には存在しません。

では、どうやって期日を守るのか。

実務では、チームの開発速度（ベロシティ）を計測しながら、 「この期日までにリリースしたい」というゴールに向けて、 発注者（PO）が機能の範囲（スコープ）を調整していきます。

間に合わない場合は「ベンダーに無理をさせる」のではなく、 「この3機能は間に合うが、残り2機能は次のスプリントに回す」と判断する。 これがラボ契約における納期管理の基本的な考え方です。

Q. ラボ契約でも途中で解約できますか？

A：契約書で定められた「解約通知期間」を守れば可能です。

ラボ契約は「半年」や「1年」といった期間で契約するのが一般的です。 しかし多くの場合、「〇ヶ月前までに通知すれば中途解約可能」という条項が設けられています。 （Rabilooの場合は通常1ヶ月前通知です）

「一度契約したら絶対に最後まで費用を払い続けなければならない」。 そうした硬直的なものではありません。

Q. 最初に請負で作り、その後ラボに移行することは可能ですか？

A：可能です。初期開発と保守・運用で契約形態を分けるハイブリッド型はよく使われます。

例えば、MVP（必要最小限の機能）の初期バージョンまでは、 要件を固定して「請負契約」で開発する。 リリース後、ユーザーのフィードバックを受けながら改善していくフェーズから、 「ラボ契約」に切り替えるという手法です。

プロジェクトのフェーズによって「不確実性の度合い」は変わります。 それに合わせて契約形態を移行するのは、非常に合理的な判断です。

Q. 準委任契約（ラボ型）の場合、エンジニアがサボるリスクはありませんか？

A：成果物という「結果」での縛りがない分、プロセスと稼働状況の透明性が重要になります。

請負のように「完成しなければお金がもらえない」というプレッシャーはありません。 そのため、マネジメントが機能していないと生産性が落ちるリスクはゼロではありません。

これを防ぐには、日々のソースコードのコミット量、 タスクの消化状況（ベロシティ）、稼働時間のレポートなどを可視化し、 発注者側が常にモニタリングできる体制を提供してくれるベンダーを選ぶことが重要です。

まとめ｜契約形態の選択は「ビジネスの不確実性」との向き合い方

ラボ契約と請負契約の違いは、「どちらが優れているか」という比較論ではありません。 「自社のビジネスが、どれくらい変化を前提としているか」という不確実性に対するアプローチの違いです。

• ゴールが明確で絶対に変わらないなら、請負契約

• 走りながら最適な形を探っていくなら、ラボ契約（準委任契約）

契約形態を決めることは、 プロジェクトの「体制」を設計することそのものです。

単なる法的な手続きとしてではなく、 事業を成功させるための「戦略」として、契約形態を選んでください。

（※契約形態の選択を含む、オフショア開発の戦略的全体像については、ベトナムオフショア開発の現在地｜2026年の構造変化と選び方で包括的に解説しています）

Rabilooでは、ラボ契約のメリットである「柔軟性」を最大限に活かすため、 要件定義が固まりきっていない構想段階からのご相談を歓迎しています。

「実現したいビジネスのアイデアはあるが、何から作り始めるべきか迷っている」 「自社の体制で、プロダクトオーナーが務まるか不安がある」

そのような段階から、最適な体制設計と開発ロードマップを共に考えます。 「何をどう作るか」が決まっていなくても構いません。 まずは、解決したいビジネス課題をお聞かせください。