「開発会社から『ラボ型でやりませんか』と提案されたけれど、請負と何が違うのか分からない」
「専属チームが持てるのは魅力だが、うちの規模で毎月の費用に見合うのか判断できない」
ラボ型開発を検討する中小企業の担当者から、こうしたご相談をいただくことが増えています。
ラボ型開発は「完成品を買う」契約ではなく「チームの稼働を月単位で借りる」契約で、発注側に決める人と仕事量がそろって初めて元が取れる方式です。
本記事では、ラボ型開発の仕組み、請負・準委任との違い、中小企業に向くケースと向かないケース、費用の目安、契約前に確認すべき点を、受託開発会社の立場から解説します。
ラボ型開発とは
ラボ型開発とは、開発会社のエンジニア数名を自社専属のチームとして一定期間確保し、その期間中に何を作るかを発注側が優先順位をつけて渡していく発注方式です。
「ラボ契約」とも呼ばれ、もともとは海外の開発拠点を使うオフショア開発の文脈で広がった言葉です。
現在は国内の地方拠点（ニアショア）や、国内の開発会社がラボ型を提供するケースもあります。
一般的なラボ型開発には、次のような特徴があります。
- 料金は「月額×人数」で決まる
作る機能の量ではなく、チームの人数と期間で費用が決まります。 - 契約期間は半年〜1年が目安
チームを立ち上げて慣れてもらうまでに時間がかかるため、数か月単位の契約が前提になることが多いです。 - 作る内容は途中で入れ替えられる
機能ごとに見積もり直すのではなく、決まった枠の中で優先順位を変えながら進めます。 - 同じメンバーに業務知識がたまる
案件ごとに担当が変わらないため、説明の手間が回を追うごとに減っていきます。 - 窓口はチーム側のリーダーやPMになる
発注側は、チームのリーダーやブリッジSE（橋渡し役のエンジニア）と要望や優先順位をやり取りします。
ラボ型開発は、法律で定義された契約の名前ではありません。
業界で使われている呼び方で、契約の中身は多くの場合、民法上の準委任契約にあたります。
この点を押さえておくと、次の章の「請負・準委任との違い」が整理しやすくなります。
ラボ型開発と請負・準委任の違い
システム開発の契約は、大きく請負と準委任の2つに分かれます。
請負は「完成した成果物」に、準委任は「専門家の作業そのもの」にお金を払う契約です。
ラボ型開発は、このうち準委任の一つの使い方だと考えると分かりやすくなります。
| 比較の軸 | 請負（一括請負） | 準委任（スポット・工数型） | ラボ型開発 |
|---|---|---|---|
| お金を払う対象 | 完成したシステム | 作業した時間・工数 | チームの月額稼働 |
| 契約の法的な性質 | 請負契約 | 準委任契約 | 準委任契約が一般的 |
| 完成の責任 | 開発会社が負う | 原則負わない | 原則負わない |
| 費用の決まり方 | 見積もり時に総額が決まる | 実際の工数で精算 | 人数×月数でほぼ固定 |
| 仕様変更 | 追加見積もり・変更契約が必要 | 柔軟に対応しやすい | 枠内で優先順位を入れ替える |
| 契約期間 | 納品まで | 作業ごと・数か月 | 半年〜1年が目安 |
| 向いている案件 | 要件が固まっている開発 | 要件定義・調査・保守 | 継続的な機能追加・改善 |
請負との一番の違いは「完成の約束」があるかどうか
請負では、開発会社が「この仕様のシステムを、この金額で完成させる」と約束します。
仕様どおりに動かなければ、開発会社が直す責任（契約不適合責任）を負います。
一方ラボ型開発では、チームは期間中しっかり働く義務を負いますが、特定の機能を完成させる約束はしていないのが原則です。
そのため、ラボ型で「半年で予定の機能が終わらなかった」としても、それだけで開発会社の責任になるとは限りません。
何をどこまで作るかの舵取りは、ラボ型では発注側の仕事になります。
普通の準委任との違いは「チームを専属で押さえる」こと
準委任の中でも、要件定義だけを数か月お願いする、保守を月◯時間お願いする、といった使い方は「作業を頼む」イメージです。
ラボ型は、それをチーム単位・長期間に広げたものです。
メンバーが固定されるぶん業務理解が深まりますが、仕事を渡せない月も費用は発生します。
請負と準委任の法的な違いや、工程ごとの使い分けは準委任契約と請負契約の違い｜システム開発の工程別の使い分けと、2026年5月に厚労省が広げた「偽装請負」の線引きで詳しく解説しています。
SES・派遣とも混同しやすい
SESは「この技術を持った人を1名、◯か月」という個人単位の契約で、ラボ型はチーム単位で開発を任せる点が違います。
派遣は、発注側が派遣されたエンジニアに直接作業の指示を出せる契約です。
ラボ型（準委任）では、発注側がメンバー一人ひとりに直接指示を出すことはできません。この点は後の章で詳しく触れます。
ラボ型開発のメリット
ラボ型開発の良さは、「決めきれない」「止められない」開発を進めやすい点にあります。
メリット1：仕様変更のたびに見積もりをやり直さなくてよい
請負では、途中で「この画面も追加したい」となると、追加見積もりと変更契約が必要になります。
ラボ型では、月の枠の中で「今月はこちらを優先する」と入れ替えるだけで済みます。
使いながら改善していく新規サービスや社内システムでは、この手間の差が大きく効きます。
メリット2：業務知識がチームに蓄積する
同じメンバーが継続して担当するため、「この業務ではこういう例外がある」といった知識が残ります。
案件ごとに別の担当者へ一から説明し直す必要がなくなります。
メリット3：採用せずに開発体制を持てる
エンジニアの採用は、中小企業にとって時間も費用もかかります。
ラボ型なら、採用・育成をせずに数名規模の開発チームを確保できます。
契約期間が終われば体制を縮小することもできます。
ラボ型開発のデメリットと注意点
メリットの裏返しとして、発注側が負うものも増えます。
提案を受けたときは、次の4点を自社で引き受けられるかを確認してください。
注意点1：仕事を渡せない月も費用がかかる
ラボ型の費用は、チームが手を動かしたかどうかに関係なく、月額で発生します。
社内の確認が遅れて仕様が決まらない月は、チームが待ちの状態になり、費用だけが出ていきます。
当社にご相談いただく中でも、「専属チームを組んだが、社内で次に作るものが決まらず持て余した」という話は珍しくありません。
注意点2：発注側に「決める人」が必要
ラボ型では、何を・どの順番で作るかを発注側が決め続けます。
週に1回程度は打ち合わせに出て、優先順位を判断できる担当者が欠かせません。
この役割はアジャイル開発でいう「プロダクトオーナー」にあたります。役割の中身はプロダクトオーナーとは？発注側が担う5つの仕事とPMとの違いで解説しています。
注意点3：立ち上がりに時間がかかる
新しいチームが業務を理解し、開発のペースが安定するまでには、一般的に1〜2か月程度かかります。
最初の数か月は「思ったより進まない」と感じやすい時期です。
短期間で1つのシステムを作り切りたい場合は、ラボ型の良さが出る前に契約が終わってしまいます。
注意点4：直接指示を出すと「偽装請負」になるおそれがある
ラボ型は準委任契約なので、発注側がメンバー個人に「今日はこの作業をして」と直接指示を出すことはできません。
実態として直接指示をしていると、契約書が準委任でも労働者派遣とみなされ、いわゆる偽装請負として法律違反になるおそれがあります。
厚生労働省は2026年5月に関連する疑義応答集を更新し、アジャイル型以外のシステム開発にも同じ考え方が当てはまることを示しています。
要望や優先順位は、必ずチーム側のリーダーやPMを通して伝える体制にしておくことが大切です。
チャットツールでメンバーとやり取りする場合も、誰が作業の割り振りを決めるのかを契約前に取り決めておきましょう。
ラボ型開発は中小企業に向くか
結論から言うと、中小企業がはじめてシステムを外注する場面では、ラボ型開発が向かないケースのほうが多いと当社は考えています。
ただし、条件がそろえば中小企業でも十分に効果が出ます。
判断の目安を表にまとめました。
| 確認すること | ラボ型が向く状態 | ラボ型が向かない状態 |
|---|---|---|
| 作りたいものの量 | 半年先まで作りたい機能・改善が並んでいる | 1つのシステムを作れば当面は十分 |
| 仕様の固まり具合 | 使いながら変えていく前提 | 作るものがほぼ決まっている |
| 社内の担当者 | 週に数時間、判断できる人が出られる | 担当者が兼務で、打ち合わせ時間が取りにくい |
| 予算の考え方 | 毎月の固定費として開発費を確保できる | 総額を先に決めて社内承認を取りたい |
| システムの位置づけ | 自社サービスなど、事業の中心になるもの | 社内業務の効率化ツール |
| 社内のIT知識 | エンジニアや情シスがいて、技術的な会話ができる | ITに詳しい人が社内にいない |
向いているのは、こんな中小企業
- 自社のWebサービスやアプリを事業として運営し、毎月改善を続けたい
- 社内にエンジニアが1〜2名いて、手が足りない部分を補強したい
- すでに稼働しているシステムに、機能追加の要望が途切れずに来ている
- 新規事業で、利用者の反応を見ながら仕様を決めていきたい
向いていないのは、こんな中小企業
- Excelや紙で管理している業務を、1つのシステムに置き換えたい
- はじめてシステムを外注するため、まず総額と納期をはっきりさせたい
- 総務や現場責任者が兼務で窓口を担当する
- 完成後は、たまの修正と保守ができれば十分
業務システムを1つ作るような案件は、作るものが比較的はっきりしているため、要件を固めて請負で発注したほうが総額を抑えやすく、社内の稟議も通しやすくなります。
ラボ型の「柔軟さ」は、決めきれない開発が長く続くときに初めて費用に見合う価値になります。
ラボ型開発の費用の目安
ラボ型開発の費用は「1人あたりの月額単価×人数×期間」で考えます。
単価は拠点（海外・国内）やエンジニアの経験、PMやブリッジSEを含むかどうかで大きく変わります。
以下は公開されている調査や各社の料金例をもとにしたおおよその目安です。実際の金額は必ず見積もりで確認してください。
| 体制の例 | 1人あたり月額の目安 | 3名×6か月の総額の目安 | 補足 |
|---|---|---|---|
| 海外（オフショア）のラボ | 30万〜60万円程度 | 540万〜1,080万円程度 | ブリッジSEは実装者より高い単価になることが多い |
| 国内地方拠点（ニアショア）のラボ | 50万〜90万円程度 | 900万〜1,620万円程度 | 日本語でのやり取りがしやすい |
| 国内（都市部）のラボ | 70万〜120万円程度 | 1,260万〜2,160万円程度 | PM・上級エンジニアを含むと上振れする |
見積もりを比べるときは、次の費用が月額に含まれているかを確認してください。
- PM・リーダー・ブリッジSEの費用
- テスト担当の費用
- サーバーや開発ツールなどの実費
- 立ち上げ時の初期費用
オフショアは単価が安く見えますが、仕様の伝達や確認にかかる発注側の手間も費用の一部です。
単価の安さだけでなく、社内の担当者が毎月どれだけ時間を使うかまで含めて比べることが大切です。
請負で業務システムを作る場合の費用感は、業務システム開発の費用相場｜受託開発の実例11件と規模別の目安・人月単価で紹介しています。
中小企業がラボ型以外に取れる3つの選択肢
「柔軟に進めたいが、専属チームを抱えるほどではない」という場合は、次のような進め方も検討できます。
| 進め方 | 中身 | 向いているケース |
|---|---|---|
| ①工程で契約を分ける | 要件定義は準委任、設計・開発は請負、と工程ごとに契約を切り替える | 作りたいものはあるが、細部がまだ決まっていない |
| ②小さく作って段階的に広げる | 最低限の機能を請負で作り、使ってみてから次の機能を追加発注する | はじめての外注で、予算を区切りたい |
| ③保守契約に改善の枠をつける | 完成後の保守契約に、月◯時間程度の改善作業の枠を含める | リリース後も少しずつ手を入れたい |
当社がご相談を受ける場合も、まずは①か②で始め、要望が途切れずに出てくるようになった段階で、改善の枠を広げていく進め方をおすすめすることが多いです。
最初からチーム単位で契約するより、自社に合う開発のペースが分かってから体制を決めるほうが、無駄な固定費を避けられます。
完成後の保守と改善の考え方はシステム開発後の保守運用とは？「作って終わり」にしない開発会社の選び方もあわせてご覧ください。
ラボ型開発の契約前に確認したい6項目
ラボ型開発で進めると決めた場合は、契約書と体制について次の6点を確認してください。
| 確認項目 | 具体的に確認する内容 |
|---|---|
| ①チームの構成 | 人数、役割（PM・エンジニア・テスト）、経験年数、専属か兼務か |
| ②指示の出し方 | 要望を伝える窓口は誰か、作業の割り振りを決めるのは誰か |
| ③成果の見える化 | 週次・月次でどんな報告が出るか、進み具合をどう共有するか |
| ④契約期間と解約 | 最低契約期間、途中解約の条件と予告期間、人数の増減のルール |
| ⑤メンバー交代 | メンバーが入れ替わるときの引き継ぎ方法と、交代を求められるか |
| ⑥成果物の権利 | ソースコードや設計書の著作権・所有権がどちらに帰属するか |
特に④の解約条件は見落とされがちです。
「1年契約で途中解約できない」「解約は3か月前の予告が必要」といった条件だと、合わなかった場合の撤退に時間と費用がかかります。
はじめてのラボ型であれば、3か月程度の試行期間を設けられるかも相談してみましょう。
ラボ型開発で失敗しやすい3つのパターン
パターン1：「おまかせ」で始めてしまう
ラボ型は、発注側が優先順位を決める前提の契約です。
「チームがいるから、あとはうまくやってくれるはず」と任せきりにすると、作りやすい機能から進み、本当に必要な機能が後回しになります。
丸投げが失敗する仕組みはシステム開発の丸投げが失敗する理由｜発注側が管理すべき6項目で解説しています。
パターン2：請負と同じ感覚で「完成」を期待する
「半年で◯◯システムを作ってもらう」というつもりでラボ型を契約すると、終わらなかったときに揉めやすくなります。
ラボ型は完成を約束する契約ではありません。
期間内に何を目標にするかは、月ごとに発注側とチームで確認しながら調整していくものです。
パターン3：単価の安さだけで選ぶ
月額単価が安くても、仕様の伝達に手間取ったり、手戻りが多かったりすると、結果的に高くつきます。
過去のラボ型の実績、報告の仕方、日本語でのやり取りのしやすさなど、単価以外の点も比較してください。
よくある質問
Q. ラボ型開発とラボ契約は同じ意味ですか？
A. ほぼ同じ意味で使われています。
「ラボ契約」は契約の呼び方、「ラボ型開発」はその契約で進める開発のスタイルを指すことが多いです。
どちらも法律上の用語ではないため、契約書では準委任契約や業務委託契約として結ぶのが一般的です。
Q. ラボ型開発は何名から依頼できますか？
A. 開発会社によって異なりますが、2〜3名程度からのチーム編成を条件にしている会社が多く見られます。
1名だけの場合は、ラボ型というよりSESや工数型の準委任に近い契約になります。
Q. ラボ型開発でもソースコードは自社のものになりますか？
A. 契約書の定め方しだいです。
準委任契約だから自動的に発注側のものになるわけではありません。
著作権の譲渡や利用の範囲を、契約前に必ず確認してください。
Q. 社内にエンジニアがいなくてもラボ型開発はできますか？
A. 不可能ではありませんが、難易度は上がります。
技術的な判断をチーム側に任せられるよう、PMや上級エンジニアを含む体制を組んでもらう必要があり、そのぶん月額は高くなります。
優先順位を決める担当者は、エンジニアでなくても構いませんが、毎週判断できる時間は確保してください。
Q. 請負で始めて、途中からラボ型に切り替えることはできますか？
A. できます。
最初のシステムを請負で作り、稼働後の機能追加や改善を準委任やラボ型で続けるのは、よくある進め方です。
同じ開発会社で切り替えれば、業務知識もそのまま引き継げます。
まとめ
- ラボ型開発は、開発会社のチームを月額で一定期間確保し、作る内容を発注側が決めていく方式
- 契約の中身は準委任が一般的で、請負と違い完成の約束はない
- 仕様変更に強く、業務知識がたまる一方、仕事を渡せない月も費用がかかる
- メンバーへの直接指示は偽装請負のおそれがあるため、窓口はチームのリーダーに一本化する
- 中小企業がはじめて業務システムを外注するなら、請負や段階的な発注のほうが合うことが多い
- 継続的な開発が見込め、社内に判断できる担当者がいるなら、中小企業でもラボ型は有効
ラボ型開発は「柔軟で便利な契約」ですが、その柔軟さを使いこなすのは発注側です。
自社に作りたいものがどれだけあり、誰が決めるのかを整理してから、請負・準委任・ラボ型のどれで進めるかを選んでください。
株式会社みんなシステムズでは、中小企業の業務システムやWebサービスの受託開発を手がけています。
専門用語を使わずに、お客様の業務に合った契約形態と進め方を一緒に整理します。
ラボ型開発や契約形態でお悩みの際は、現在の運用と作りたいものをお聞かせいただければ、合った進め方と概算費用をご提示します。お気軽にご相談ください。
