ラボ型開発は、一定期間、自社専属の開発チームを外部に確保しておく契約の形です。オフショア開発でよく使われ、「ラボ契約」「専属チーム型」とも呼ばれます。
この記事では、ラボ型開発と請負の違いを民法の条文から整理します。そのうえで、偽装請負にならないための指揮命令の線引き、向いている案件と向かない案件、立ち上げの流れ、見積もりの確認点を説明します。契約形態を決める立場にある発注側の方を想定しています。
ラボ型開発とは
ラボ型開発では、半年や1年といった期間を決めて、エンジニアのチームを確保します。費用は成果物ごとではなく、チームの人数と期間で決まるのが基本です。期間中は、そのチームに依頼する開発の内容や優先順位を、発注側の事情に合わせて入れ替えられます。
契約は、多くの場合、準委任契約で結びます。請負のように「この機能を、この日までに完成させる」と約束するのではなく、決められた期間、専門家として業務を遂行することを約束します。
似た言葉に「オフショア開発センター（ODC）」があります。海外に自社専用の開発拠点を持つという考え方です。ベンダーの中に専属チームを置く点で、ラボ型開発とほぼ同じ意味で使われています。
オフショア開発.comの『オフショア開発白書（2025年版）』は、ラボ契約の割合が微減した一方でSES契約が急伸し、契約形態が多様になっていると報告しています。同じ白書は、ラボ契約の本質的な価値を「継続性」と「柔軟性」にあるとまとめています（オフショア開発.com「オフショア開発白書（2025年版）」）。
準委任と請負の違い
ラボ型開発を理解するには、準委任契約と請負契約の違いを押さえておく必要があります。民法では、請負は「仕事の完成」を約束する契約です（第632条）。一方で準委任は、法律行為ではない事務の処理を委託する契約で、委任の規定が準用されます（第656条）。条文はe-Gov法令検索「民法」で確認できます。
| 比較する点 | 準委任契約（ラボ型） | 請負契約 |
|---|---|---|
| 約束する内容 | 業務の遂行 | 仕事（成果物）の完成 |
| 報酬の決まり方 | 期間と人数（稼働）に応じて支払う | 成果物の完成・引き渡しに対して支払う |
| 受注者の主な責任 | 善良な管理者の注意義務（善管注意義務） | 完成義務と契約不適合責任 |
| 仕様変更への対応 | 期間内で優先順位を入れ替えて対応しやすい | 変更契約や追加見積もりが必要になりやすい |
| 発注側の関与 | 継続的に要件を出し、成果を確認する | 要件定義と受け入れ検査が中心 |
| 作業者への指揮命令 | 受注者側が行う | 受注者側が行う |
なお、2020年4月施行の改正民法では、成果に対して報酬を支払う「成果完成型」の準委任も明文化されました（第648条の2）。ラボ型でも、履行割合型と成果完成型のどちらで契約するのかは、契約書で確認してください。
契約書のひな形を検討する際は、IPAが公開している「情報システム・モデル取引・契約書」が参考になります。第二版に加えてアジャイル開発版も公開されています。契約書に盛り込むべき項目は、オフショア開発サービス契約の基本構成と注意点でも解説しています。
指揮命令は誰が行うのか
比較表の最後の行は、ラボ型開発で誤解が多い点です。準委任契約であっても、発注側の担当者がベンダーのエンジニアに直接作業の指示を出し、勤務時間まで管理すると、実態として労働者派遣と判断されるおそれがあります。いわゆる偽装請負の問題です。
労働者派遣か請負等かは、契約の形式ではなく実態で判断されます。その基準が「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）です。厚生労働省は、この基準の解釈を疑義応答集として公開しています（厚生労働省「37号告示関係疑義応答集」）。
ラボ型開発にとくに関係するのが、アジャイル型開発を扱った疑義応答集（第3集）です。第3集は、準委任契約で行う場合も同じ基準が適用されると明記しています。そのうえで、発注側と受注側が対等な関係で協働し、受注側の開発担当者が自律的に判断して進めている限り、偽装請負とは判断されないとしています。
発注側がしてよいこと、避けるべきこと
第3集の内容を、発注側の行動に置き換えると次のようになります。
| 発注側の行動 | 第3集での考え方 |
|---|---|
| プロダクトバックログの内容と優先順位を決める | 発注側の開発責任者の役割として想定されている |
| バックログの詳細を説明し、要件を明確にするための情報を渡す | それだけで直ちに偽装請負とはされない |
| 会議やチャットに双方の関係者が全員参加する | それだけで直ちに偽装請負とはされない |
| エンジニア個人に作業の進め方や労働時間を指示する | 指揮命令にあたり、偽装請負と判断される |
| 進捗が遅れたときに、仕事の割り付けや順序を直接指示する | 受注者側が管理責任者を通じて行う必要がある |
MOHAのラボ型開発でも、エンジニアへの指揮命令はMOHA側のPM・ブリッジSEを通じて行います。お客様に決めていただくのは、開発したい内容と優先順位、受け入れの基準です。PMとブリッジSEがそれをタスクに分け、誰がどう進めるかをMOHA側で決めます。定例会議や仕様の相談でお客様とエンジニアが直接話すことはありますが、作業の割り振りと勤務の管理はMOHAが担います。
ラボ型開発が向いている案件
仕様を最初から固めきれない開発や、同じチームで長く続ける開発には、ラボ型開発が合います。たとえば次のような案件です。
- リリース後も機能追加と改善を続ける自社サービス、SaaS
- 市場の反応を見ながら仕様を決めるMVP、新規事業
- 既存システムの保守と小規模な改修が途切れずに発生する案件
- 社内の開発チームと並走し、同じバックログを分担する案件
- AI機能のPoCから本番導入まで、検証と修正を繰り返す案件
こうした案件で請負を選ぶと、仕様が変わるたびに見積もりと変更契約をやり直すことになります。ラボ型なら、確保したチームの中で優先順位を入れ替えれば済みます。また、同じメンバーが続けて担当するので、業務知識もチームに蓄積されます。
ラボ型開発が向かない案件
次のような案件では、請負も検討してください。
- 要件と納期が固まっていて、途中で大きな変更がない開発
- 数か月で終わる単発の開発で、リリース後の改修予定がない案件
- 発注側で要件を出したり成果を確認したりする担当者を置けない案件
- 予算を成果物単位で固定したい案件
ラボ型では、チームを確保している間は費用が発生します。依頼するタスクの少ない月は、その分だけ割高になります。そのため、発注側で毎月の優先順位を決められるかどうかが、ラボ型を選ぶ前の確認点です。
請負から始めてラボ型に移る進め方
ラボ型か請負かは、案件全体で一度だけ決めるものではありません。フェーズごとに契約を分ける進め方もあります。たとえば、要件が固まった初期開発は請負で進め、リリース後の改善と保守をラボ型に移す形です。反対に、仕様が固まらない構想段階をラボ型で進め、固まった部分から請負で切り出すこともできます。
MOHAのオフショア開発センターでは、専属チームモデル、スタッフ補強モデル、プロジェクト単位型モデルの3つを用意しています。また、仕様が固まっていない段階では、初期にプロトタイプを作り、ご要望と仕様が確定してから本格的な開発に入ります。仕様変更による見直しを最小限に抑えるための進め方です。
ラボ型開発の立ち上げの流れ
MOHAのオフショア開発センターでは、次の5つの段階で立ち上げます。
| ステップ | 内容 |
|---|---|
| 1. 発見フェーズ | 事業の状況、課題、目標を伺います。 |
| 2. 要件の策定 | お客様と一緒に、具体的なプロジェクト要件を決めます。 |
| 3. チームの編成 | 案件に合う専門知識、スキル、経験を持つメンバーを選びます。 |
| 4. プロジェクトの開始 | 開発環境、コミュニケーションの手段、定例の頻度を決めて着手します。 |
| 5. パフォーマンスの監視 | 進捗、品質、マイルストーンを追跡し、計画とのずれを早めに共有します。 |
契約の相手は、横浜市西区みなとみらいにある日本法人の合同会社MOHAジャパンです。立ち上げまでの期間は、必要な人数とスキルによって変わります。そのため、ヒアリングの段階で希望の開始時期をお伝えください。
日本とベトナムの時差は2時間で、日本時間の10時はベトナム時間の8時です。日本の午前中から夕方まで双方の業務時間が重なるため、定例会議の時間を決めやすくなります。
よくある失敗と対策
仕様をまとめて渡して終わりにしてしまう
ラボ型は、請負のように「要件を渡せば完成品が届く」契約ではありません。発注側が優先順位を決めずにいると、チームは何から手をつけるべきか判断できません。対策として、発注側にプロダクトの責任者を1人決め、週次でバックログの優先順位を確認する場を設けてください。
依頼するタスクが足りず、稼働が空く
チームの人数に対してタスクが少ないと、費用に見合う成果が出ません。立ち上げ時は少人数から始め、バックログがたまった段階で増員すると、無駄を抑えられます。
受け入れの基準が決まっていない
「できた」の判断が人によって違うと、手戻りが増えます。完了の定義（テストの範囲、レビューの有無、ドキュメントの要否）を最初に文書で合意しておきます。
MOHAは、要件書からテスト観点とテストケースを生成するツール「Design Checklist」を自社で開発しています。観点、シナリオ、高レベル、低レベルの4段階で出力でき、要件とテストの対応関係も残せます。受け入れ基準を決める際の抜け漏れ確認に役立ちます。
窓口が1人に集中する
ブリッジSE1人にすべてのやり取りが集まると、その人が休んだだけで開発が止まります。PMとブリッジSEの役割分担、不在時の代わりの担当者を、契約の段階で確認しておいてください。
エンジニアに直接指示を出してしまう
前述のとおり、発注側がエンジニアに作業の進め方や労働時間を直接指示すると、偽装請負と判断されるおそれがあります。要望はPM・ブリッジSEに伝え、タスクの割り振りはベンダー側に任せる運用を最初に決めておきます。
海外ベンダーとの契約で起きやすいトラブルは、オフショア開発契約で失敗しないための7つのチェックリストも参考にしてください。
見積もりを確認するときのポイント
ラボ型開発の費用は、成果物ではなく、チームの構成と期間で決まります。見積もりを確認するときは、総額だけでなく次の点をご確認ください。
- 役割ごとの人数と稼働率（PMやブリッジSEが専任か、複数チームとの兼任か）
- 契約期間の最低単位と、増員・減員の条件
- 立ち上げ期間の扱い（業務の理解やドキュメント整備の期間が含まれているか）
- タスクが少ない月の扱い（期間中も費用が発生するため、人数をどう調整できるか）
国内で同じ体制を組む場合と比べるときは、人件費だけを並べても判断を誤ります。採用や教育の費用、管理工数、やり取りにかかる時間まで含めて比べてください。具体的な金額は条件によって変わるため、MOHAでは概算見積もりで個別にご提示しています。
よくある質問
ラボ型開発とSESは同じですか？
どちらも準委任契約で結ぶことが多い点は共通しています。一般に、SESは技術者1人ひとりの稼働を提供する形を指します。ラボ型開発は、ベンダー側でチームを組み、PMやブリッジSEを含めて開発を進める形を指します。
ラボ型開発でも成果物の品質は保証されますか？
準委任契約では、請負のような完成義務や契約不適合責任は原則としてありません。そのため、テストの範囲やレビューの手順、完了の定義を契約書や運用ルールで決めておくことが、品質を担保する手段になります。
発注側のプロダクトオーナーがエンジニアと直接話してもよいですか？
バックログの内容を説明したり、要件を明確にするための情報を渡したりするだけであれば、直ちに偽装請負とはされません。問題になるのは、作業の進め方や労働時間を直接指示する場合です。
途中で請負に切り替えられますか？
可能です。切り替える際は、範囲と成果物をあらためて定義し、別の契約を結びます。
仕様が決まっていなくても始められますか？
はい。MOHAでは、仕様が固まっていない段階ではプロトタイプを作り、ご要望と仕様が確定してから本格的な開発に入ります。ラボ型はこの進め方と相性のよい契約形態です。
ご相談・資料請求
ラボ型と請負のどちらが合うかわからない段階でも、ご相談いただけます。お問い合わせフォームからお気軽にご連絡ください。体制と事例をまとめた会社紹介資料もご用意しています。
参考文献
- e-Gov法令検索「民法」https://laws.e-gov.go.jp/law/129AC0000000089
- 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」https://www.mhlw.go.jp/bunya/koyou/gigi_outou01.html
- 厚生労働省「37号告示に関する疑義応答集（第3集）」https://www.mhlw.go.jp/content/001704257.pdf
- IPA「情報システム・モデル取引・契約書」https://www.ipa.go.jp/digital/model/index.html
- オフショア開発.com「オフショア開発白書（2025年版）」https://www.offshore-kaihatsu.com/news/articles/wp_2025/
