BLOG
ラボ型開発とは ― 向いている案件と、請負・準委任との違い
「案件のたびに見積もりを取り、チームが毎回変わる。前の開発を知っている人がいない」「社内にエンジニアを採用したいが、すぐには集まらない。でも開発は止められない」。改善を続けるサービスを持つ会社から、こうしたご相談が増えています。
ラボ型開発は、専属の開発チームを一定期間確保し、月額で契約する開発の形です。案件ごとに契約する請負開発と違い、同じチームが継続して開発に関わるため、知識が蓄積し、優先順位を柔軟に変えられます。その代わり、何を作るかを決める役割は発注側が持ち続けます。
この記事では、ラボ型開発とは何か、請負や単発の準委任と何が違うのか、メリットとデメリット、向いている案件、そして始める前に決めておくことを整理します。

ラボ型開発とは
ラボ型開発は、法律上の用語ではなく、開発会社との契約の組み方を指す業界の呼び名です。発注側の専用チーム(ラボ)を開発会社の中に作り、半年や1年といった期間、月額で確保します。チームはその期間、発注側の開発だけを担当します。
契約の形としては、多くの場合、業務の遂行に対して報酬を支払う準委任契約(民法656条)で結ばれます。決めた成果物の完成を約束する請負契約(民法632条)とは異なり、期間の中で何を作るかを変えながら進められます。契約の中身については準委任契約とはで解説しています。
もともとは海外の開発拠点を使うオフショア開発で広まった形ですが、国内の開発会社でも同じ組み方が使われています。当社はネパールの開発拠点と日本のPMでチームを組み、この形で継続開発を担当しています。
請負開発・単発の準委任との違い
| 請負開発 | 単発の準委任 | ラボ型開発 | |
|---|---|---|---|
| チーム | 案件ごとに編成 | 案件ごとに編成 | 期間を通じて固定 |
| 支払い | 成果物に対して一括 | 期間や成果に対して | 月額 |
| 仕様の変更 | 追加契約 | 都度調整 | 優先順位の入れ替え |
請負開発は、作るものが決まっている案件に向きます。総額と納期が先に決まり、完成の責任を開発会社が負います。詳しくは請負開発とはにまとめています。
単発の準委任は、要件定義や調査のように、期間を区切った業務に向きます。ラボ型開発はその準委任を、同じチームで継続する形にしたものと考えると分かりやすいです。
ラボ型開発のメリット
- 知識がチームに残る。業務の背景、過去の判断、コードの癖を知っている人が続けて担当します。案件ごとに説明し直す時間がなくなります。
- 優先順位を変えられる。利用者の反応や事業の状況に合わせて、次に作るものを入れ替えられます。追加見積もりの往復が要りません。
- 採用せずにチームを持てる。自社で採用と育成を行わずに、専属のチームを確保できます。社内のエンジニア採用と並行して進めることもできます。
- 小さな改善を続けやすい。請負では見積もりに乗りにくい細かな改善を、月の中で順番に片付けられます。
ラボ型開発のデメリット
- 仕事がなくても費用がかかる。チームを確保する契約なので、開発の依頼が途切れても月額は発生します。常に次の仕事がある案件でないと割高になります。
- 完成の責任がない。準委任契約が基本のため、決めた期日に決めたものが完成する約束はありません。期日が動かせない納品物には向きません。
- 発注側の関与が要る。何を作るかの優先順位は発注側が決めます。判断する人が社内にいないと、チームが待つ時間が増えます。
- 立ち上がりに時間がかかる。チームが業務を理解するまでの数週間は、成果が見えにくい期間です。短期の契約ではこの期間の比重が大きくなります。
ラボ型開発が向いている案件、向いていない案件
向いているのは、終わりのない開発です。自社サービスの継続的な改善、社内業務システムを順番に作り足していく計画、実用最小限の製品(MVP)を公開した後に利用者の反応を見て機能を変えていく段階が典型です。
向いていないのは、一度作って終わる案件です。既存システムの移行、仕様の決まった受注システムの開発、数か月で完結する単発の開発は、請負で総額を決めるほうが双方にとって分かりやすくなります。
迷う場合は、最初の開発を請負で行い、公開後の改善をラボ型に切り替える進め方もあります。
ラボ型開発の進め方
- 立ち上げ。最初の数週間で、チームが業務とシステムを理解します。既存のコードや資料の引き継ぎ、開発環境の整備、やり取りの方法の決定をこの期間に行います。
- 作業の一覧づくり。やりたいことを一覧(バックログ)にし、発注側の責任者が優先順位を付けます。すべてを細かく決める必要はなく、直近の分だけ具体的にします。
- 短い周期で開発。1、2週間の周期で、優先順位の高いものから作って確認します。周期の終わりに動くものを見て、次の優先順位を決め直します。
- 振り返りと見直し。月ごとに使った時間と成果を確認し、契約の見直し時期には体制と継続を判断します。
費用は、体制と期間で決まります。月額に含まれるのは、多くの場合、エンジニアの稼働、PMやチームリーダーの関与、やり取りの仕組みの利用です。クラウドの利用料や外部サービスの費用は別に発生します。請負のような総額ではなく、月額と期間の掛け算で考え、期間の途中に見直しの時期を置いてください。
始める前に決めておくこと
- 発注側の責任者。チームに優先順位を伝え、確認の判断をする人を一人決めます。アジャイル開発ではプロダクトオーナーと呼ばれる役割です。
- 期間と見直しの時期。半年や1年の契約期間と、途中で体制や継続を見直す時期を決めます。終了の条件も先に置いてください。
- 体制の固定と交代のルール。誰がチームに入るか、交代が必要になったときの引き継ぎをどうするかを確認します。
- 指示の出し方。発注側が開発会社のエンジニアに作業の進め方や労働時間を直接指示すると、いわゆる偽装請負として労働者派遣法に違反するおそれがあります。厚生労働省の疑義応答集は、発注側と受注側が対等な関係で協働し、受注側が自律的に判断していれば偽装請負にはあたらないとしています。要望は責任者を通して伝え、進め方の判断はチームに残します。
- 見える化の方法。週次の報告、残っている作業の一覧、使った時間の内訳を、どのツールで共有するかを決めます。
- 成果物とコードの帰属。作ったコードや設計書の著作権と、契約が終わった後の引き渡しを確認します。
なお、ここでの説明は一般的な整理です。個別の契約については、契約書の文面と、必要に応じて専門家の確認をお願いします。
当社のラボ型開発の進め方
当社は、ネパールの開発拠点のエンジニアと日本のPMで専属チームを組みます。日本のPMが発注側の責任者と要件を整理し、チームは短い周期で開発と確認を繰り返します。進捗、残っている作業、使った時間は、自社開発のプロジェクト管理ツールで発注側にもそのまま見えるようにしています。
最初の開発を請負で行い、公開後の改善からラボ型に切り替える案件も多くあります。どちらの形が合うかは、開発が一度で終わるのか、続くのかで判断します。
よくあるご質問
ラボ型開発と準委任契約は同じですか?
同じではありません。準委任は契約の形、ラボ型開発はチームの組み方です。ラボ型開発の多くは準委任契約で結ばれますが、準委任には単発の要件定義支援なども含まれます。
最低どのくらいの期間から契約できますか?
開発会社によりますが、チームの立ち上がりに数週間かかるため、半年程度からが一般的です。短期であれば単発の準委任や請負のほうが合うことが多いです。
途中でチームの人数を変えられますか?
多くの契約で、見直しの時期に増減できます。急な増員は人の確保に時間がかかるため、見直しの時期と予告の期間を契約時に決めておいてください。
ラボ型開発でも納期を約束してもらえますか?
準委任契約が基本のため、完成の約束はありません。ただし、期日が決まっている機能は、その部分だけを請負で切り出すなど、組み合わせで対応できます。
海外のチームでも、日本語でやり取りできますか?
開発会社によります。当社は日本のPMが窓口になり、要件の整理と日々のやり取りを日本語で行います。
まとめ
ラボ型開発は、専属のチームを期間で確保し、優先順位を変えながら開発を続ける形です。知識が蓄積し、小さな改善を続けやすい一方、仕事がなくても費用がかかり、何を作るかは発注側が決め続ける必要があります。
続く開発にはラボ型、一度で終わる開発には請負、と使い分けるのが基本です。自社の開発がどちらに当たるか、無料見積相談で担当PMが体制と費用の目安を一緒に整理します。
関連する記事とページ
- 請負開発とは ― メリット・デメリットと、受託開発・準委任との違い
- 準委任契約とは ― システム開発での使いどころと、請負契約との違い
- 受託開発とは何か ― 契約の形と、発注前に決めておくこと
- PoCとMVPの違いとは ― 目的・期間・進め方の比較
- MVP開発とは何か ― 進め方、費用の考え方、PoCとの違い
- システム開発は内製化すべきか、外注すべきか
- 無料見積相談 ― 担当PMに範囲と費用の目安を相談
出典
- e-Gov法令検索「民法(明治二十九年法律第八十九号)」第632条、第656条
- 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」2026年5月25日更新(疑義応答集(第3集)Q1・Q2)
- IPA「情報システム・モデル取引・契約書(アジャイル開発版)」2020年3月31日
この記事の監修者

永田 一郎代表取締役
ヤフー(Yahoo! JAPAN)のエンジニア出身。スタートアップ、大手事業会社にて18年以上にわたり、toC/toB向けの新規事業開発、業務DX化など、多種多様なプロジェクトに従事。エンジニアとして自ら開発に携わる一方、体制構築やマネジメント、事業設計、仮説検証にも関わり、事業の立ち上げとグロースを幅広く体得。これまでに三回の事業売却を経験。共創でより効果的にプロダクトをつくり、アイディアをマーケットで検証できることを確信し、共創プラットフォームを提供するため wesionaryTEAM を創業。