ラボ型開発とは？請負・SESとの違い、メリット・デメリット、費用相場と向き不向きの判断軸【2026年版】

「継続的に開発を頼める外部チームがほしいが、SES・請負・ラボ型のどれを選べばよいかわからない」「ラボ型は月額固定と聞くが、仕事が少ない月も払うのは損ではないか」——開発リソースの確保を検討する担当者から、こうした相談を受けることが増えました。契約形態の名前が多く、違いを整理しないまま選んで失敗している会社が少なくないのが実情です。

先にお伝えしたいのは、ラボ型開発とは「開発会社の側に自社専属の開発チームを一定期間確保し、月額で継続契約する手法」であり、請負やSESと優劣があるのではなく、向く案件が違うということです。法律上は準委任契約で、成果物の完成責任はない代わりに、仕様変更や優先順位の変更に追加費用なしで対応できます。継続的に開発が発生し、要件が動き、社内に優先順位を決める人がいる。この3つが揃う案件では、ラボ型が総額と速度のバランスで最も有利です。

一方で、タスクがない期間も固定費がかかる、立ち上がりに1〜3か月かかる、発注側に管理負荷が残る、という弱点も事実です。ただし、バックログを整備し、プロダクトオーナー役を置き、日本人PMをフロントに置く体制を選び、1〜2名でスモールスタートすれば、この弱点は管理できます。

私は人材業界の出身で、2018年からホーチミンで約100社の開発体制を支援してきました。SESで管理役が疲弊した会社や、請負で仕様変更のたびに開発が止まった会社がラボ型に切り替える相談を数多く受けてきた立場から、本記事ではラボ型開発の定義と請負・SES・派遣との違い、メリットとデメリットへの対処法、向く案件と向かない案件を分ける3つの判断軸、費用相場と進め方、そして当社の体制と事例の順で整理します。

読み終えるころには、自社の案件にラボ型が向くのか、向くならどんな体制でいくらから始めるのかを、社内に説明できる形で整理できているはずです。まずは定義と、似た契約との違いから確認していきましょう。

ラボ型開発とは——専属チームを月額で確保する準委任契約。請負・SES・派遣との違い

ラボ型開発とは、開発会社(ベンダー)の側に「発注者専用の開発チーム(ラボ)」を設け、一定期間、月額で継続契約する開発手法です。この章では定義と語源、注目される背景を押さえたうえで、混同されやすい請負・SES・派遣との違いを比較表で整理します。ここが理解できれば、後の章の判断軸はすべてつながります。

結論: 開発会社の側に自社専属チームを一定期間置き、月額で継続契約する手法。完成責任はない代わりに仕様変更に強い

ラボ型開発は、法律上は準委任契約に分類されます。「契約期間中、発注者のために誠実に開発業務を行うこと」を約束する契約で、請負契約のような「成果物の完成責任」は負いません。その代わり、契約期間中であれば仕様変更・機能追加・優先順位の変更を、追加見積もりや再契約なしで柔軟に行えるのが最大の特徴です。

契約は一定の期間を定めて結び、専属のチームを確保します。発注者から見ると、自社の外に専用の開発部門(サテライトオフィス)を持つイメージに近く、継続的な開発や運用保守に向いています。なお「ラボ契約」は契約形態そのものを指し、「ラボ型開発」はラボ契約を用いた開発手法を指す、という整理が一般的です。

語源と背景——ラボ(研究室)・ODC、IT人材不足とアジャイルの一般化

「ラボ」はLaboratory(研究室・専用施設)の略で、海外では ODC(Offshore Development Center)とも呼ばれます。注目される背景は2つあります。1つはIT人材の不足で、経済産業省の調査(2019年)では2030年に最大約79万人のIT人材が不足するとされ、「必要なスキルを持つエンジニアチームを安定的に確保する手段」としてラボ型の需要が高まりました。もう1つはアジャイル開発の一般化で、作りながら改善する進め方には、成果物単位で契約が切れる請負よりも、チームが継続稼働するラボ型が合います。

請負・SES・派遣との比較表——契約の目的、完成責任、指揮命令、提供単位、仕様変更、費用構造

表で最も大事なのは「契約の目的」と「提供単位」の行です。請負は完成物を買う契約、SESは個人の時間を買う契約、ラボ型はチームの継続稼働を買う契約です。準委任である以上、ラボ型でもSESでも発注者がエンジニアに直接指揮命令することはできず、開発会社側のPMやリーダーを通す建付けが要ります。契約の法的な違いは準委任と請負の違いで詳しく整理しています。

ラボ型とSESは同じ準委任でも「チームか個人か」「どこで働くか」「ノウハウがどこに残るか」が違う

ラボ型とSESは同じ準委任契約なので混同されやすいのですが、運用面で3つの違いがあります。第一に提供単位で、SESがエンジニア個人の労働力を提供するのに対し、ラボ型はPMやリーダーを含む「チーム」としての提供が前提です。第二に開発場所で、SESは発注者のオフィスに常駐し、ラボ型は開発会社側(オフショア拠点やリモート)で稼働します。第三にノウハウの蓄積先で、SESは個人のスキルに依存して属人化しやすく、ラボ型は同じチームが継続するため、発注者とチームの双方に蓄積されます。

SESは「自社に管理役がいて、個人単位で手を借りたい」場面に向き、ラボ型は「チームごと継続的に開発を任せたい」場面に向きます。SESの詳しい仕組みはSESとはをご覧ください。では、ラボ型を選ぶと具体的に何が得られ、何に注意すべきなのでしょうか。次章でメリットとデメリットを整理します。

ラボ型開発のメリット5つとデメリット4つ——固定費・立ち上がり・管理負荷への対処法

ラボ型開発は「仕様変更に強く、ノウハウが貯まる」という長所と、「タスクがなくても固定費がかかり、管理は発注側に残る」という短所を併せ持ちます。この章ではメリット5つとデメリット4つを整理し、デメリットごとの対処法を示します。対処法まで含めて理解すれば、ラボ型は多くの会社にとって管理可能な選択肢になります。

メリット: 仕様変更に柔軟、優秀な人財を専属で確保、ノウハウが蓄積、見積もり・契約の手間が減る、コストを最適化

第一に、仕様変更に柔軟です。契約期間中であればプロジェクトの進捗に応じて開発内容を変えられ、請負でよくある「納品後に修正点が見つかり追加費用が発生した」という想定外の出費を防げます。作りながら改善するアジャイル開発との相性は特によく、スクラムやカンバンと組み合わせて短いサイクルで価値を届け続けられます。

第二に、優秀な人財を一定期間専属で確保できます。採用には求人費・面接・教育・定着のコストがかかり、売り手市場では育てた人が転職するリスクもあります。ラボ型なら必要なスキルセットを持つチームを、採用と育成の手間をかけずに即戦力として確保できます。第三に、ノウハウが蓄積されます。同じチームが長期間関わることで、システムの設計思想やコードの経緯が記録・継承され、メンバー入れ替わり時の引き継ぎコストが低く抑えられます。

第四に、見積もり・契約の手間が減ります。案件ごとにパートナーを探し、見積もりを取り、契約を結び直す工程がなくなり、事業の意思決定と同じ速度で開発を動かせます。第五に、コストを最適化できます。特にオフショアを活用すれば、国内で同規模のチームを組むより費用を抑えられ、月額固定なので予算管理も容易です。当社の公開単価は市場相場の約1/2(当社調べ)です。

デメリット(表): タスクがない期間も固定費、立ち上がりに1〜3か月、発注側の管理負荷、少額・不定期は割高

4つとも、ラボ型の構造上避けられない性質です。ただし「避けられない」と「管理できない」は違います。次の対処法を契約前に用意しておけば、大半は問題になりません。

対処法: バックログの整備、プロダクトオーナーの設置、PM/BrSE込みの体制、オンボーディング資料

固定費に対しては、バックログ(将来やりたいことの一覧)を常に整備しておくことです。優先度は低くても改善したい機能、技術的負債の解消、ドキュメント整備を事前にリストアップし、数か月先まで着手できる分量を切らさないように積み、毎週優先順位を見直せば、チームの稼働を無駄なく使えます。当社の運用では、次の四半期に着手できる項目が常に残っている状態を保てているかを目安にしています。管理負荷に対しては、社内に専任の窓口担当(プロダクトオーナー)を置き、週1回程度の定例ミーティングを設定します。あわせて開発会社側にPMやブリッジSEを含む体制を組んでもらえば、日々のタスク管理と品質確認はそちらに移り、発注側は優先順位を決めることに集中できます。

立ち上がりに対しては、契約開始前にシステム全体の設計書・業務フロー・過去の意思決定の背景をまとめたオンボーディング資料を用意し、最初の2〜3週間は密なコミュニケーションに集中します。割高リスクに対しては、そもそも発注量が少ない案件にラボ型を選ばないことです。判断の軸は次章で示します。

私が見てきた切り替えの動機——SESで管理役が疲弊、請負で仕様変更のたびに停止

私が相談を受ける中で多いのは、SESで個人を3名入れたものの社内の管理役が指示と確認に追われて疲弊した会社と、請負で機能単位に発注したものの仕様変更のたびに追加見積もりで開発が止まった会社です。どちらも「継続的に開発が発生し、要件が動く」案件に、それに合わない契約形態を選んだことが原因でした。では、自社の案件はラボ型に向いているのでしょうか。次章で3つの判断軸を示します。

ラボ型開発が向く案件・向かない案件——開発期間・体制の安定性・コスト構造の3つの判断軸

請負・SESとの違いは理解できても、「結局、自社の場合はどれが向いているのか」は別の問題です。この章では、ラボ型が向く案件と向かない案件を示したうえで、開発期間の見通し・体制の安定性ニーズ・コスト構造という3つの軸で判断できるようにします。

向く案件: 要件が固まっていない新規事業、継続的な機能追加・改善、アジャイル、運用保守と小規模開発の継続、内製化の前段階

ラボ型が向くのは、第一に発注段階で方向性が定まりきっていない新規事業やPoCです。要件を固めてから発注する請負と違い、作りながら要件を詰められます。第二に、リリース後も継続的に機能追加・改善が発生するプロダクトです。第三に、開発とテストを短期間で繰り返すアジャイル開発です。第四に、既存システムの運用保守と小規模な改修が継続的に発生する案件で、明確な成果物を定義しにくい業務は準委任の方が実態に合います。第五に、将来の内製化や開発力強化を見据えている会社で、専属チームにノウハウを蓄積しながら段階的に社内へ引き取る土台になります。

向かない案件: 要件が確定した単発・短期、少額・不定期、成果物単位で費用を確定したい

逆に向かないのは、「この仕様で、この期間で」と要件が完全に固まった単発・短期のプロジェクトです。この場合は請負の方が費用の見通しを立てやすく、完成責任も負ってもらえます。発注量が少額・不定期なら、月額固定のラボ型は無駄が出るので、請負や単発のSES活用が向きます。成果物単位で費用を確定させたい予算管理の会社も同様です。ラボ型は「稼働時間に対して支払う」モデルなので、その考え方に納得感があるかどうかが分かれ目になります。

判断の3軸(表): 開発期間の見通し、体制の安定性ニーズ、コスト構造——2軸以上でラボ型が向く

3つの軸のうち2軸以上でラボ型が向く状態に当てはまるなら、ラボ型の検討を勧めます。1軸以下ならSESか請負を優先し、事業が進んで継続開発のニーズが高まった段階でラボ型への切り替えを検討すれば十分です。私の経験では、「継続的に開発が発生し、要件が動き、社内に優先順位を決める人がいる」の3つが揃う案件は、ほぼ例外なくラボ型が総額と速度のバランスで有利です。

管理役がいないなら、PM/BrSEをフロントに置く体制を選ぶ

判断軸2で引っかかりやすいのが「社内に管理担当を置けない」場合です。非エンジニアの担当者しかいない、あるいは開発責任者が多忙で日々のタスク管理まで見られない会社は少なくありません。この場合、ラボ型を諦める必要はなく、開発会社側にPMやブリッジSEをフロントに置いてもらう体制を選べば解決します。発注側は週1回の定例で優先順位を決め、日々の指示・進捗管理・品質確認はPMが担う形です。当社ではこれを「パターンA」として推奨しており、詳しくは第5章でお伝えします。安易に「管理できないから請負で」と決めると、仕様変更のたびに止まる案件では失敗のもとです。

ラボ型開発の費用相場と進め方——体制別の月額、失敗パターン、パートナー選びの確認項目

ラボ型に向くと判断できたら、次は費用と進め方です。この章では、体制別の月額相場(国内とオフショア)、立ち上げから運用までの4ステップ、よくある失敗4つと対策、パートナー選びで確認する項目を整理します。数値は2026年時点で公開されている相場の目安で、体制と技術領域で変動する点はご了承ください。

費用の見方(表): 体制別の構成例と、役割別の人月単価(市場相場と当社の公開単価)

ラボ型の費用は「チームの人数×役割別の人月単価×契約期間」で計算します。

役割別の人月単価は、ベトナムの市場相場としてオフショア開発白書2025年版(オフショア開発.com、2026年9月21日確認)がプログラマー40.1万円、シニア50.0万円、ブリッジSE59.0万円、PM71.4万円を示しています。当社の場合、実務3年目安のエンジニアが月額1,500USD(約22.5万円)、5年目安が2,000USD(約30万円)、ブリッジSEが3,000USD(約45万円)で、日本人PMをフロントに置いた2〜3人月の最小構成が月額約80万円からと、相場よりさらに低い水準です(いずれも1USD=150円換算の目安)。理由は第5章で説明します。

進め方4ステップ: ニーズ整理(2週間)→複数社を比較(1〜2か月)→1〜2名でスモールスタート(1〜3か月)→拡張

ステップ1は自社のニーズ整理で、何を作りたいか(新規か保守・改善か)、必要な技術スタック、チーム規模と期間の目安、月額予算の上限を明確にします。前章の3つの判断軸を整理する作業でもあります。ステップ2はベンダーの比較選定で、候補を複数社に絞って問い合わせ、類似案件の実績、技術領域、コミュニケーション体制(日本語対応・定例の頻度)、契約の柔軟性、開発プロセスの透明性を確認します。

ステップ3はスモールスタートで、いきなり大きなチームで始めず、1〜2名で試験的に開始してチームとの相性・コミュニケーション品質・技術力を確認します。ステップ4は拡張で、成果を見ながら人数と範囲を広げます。オンボーディング資料を用意し、最初の数週間は密に同期することが立ち上がりを早めます。

よくある失敗4つと対策: タスク管理の放置、コミュニケーション不足、いきなり大規模、契約の柔軟性を未確認

失敗1は、フェーズが変わってタスクが減った後にチームが「何をすべきかわからない」状態になることで、対策はバックログの維持と毎週の優先順位見直しです。失敗2は、週次定例だけで済ませて仕様の認識ずれが蓄積し、リリース直前に作り直しになることで、対策は仕様のテキストと画面での明文化、チケットでの記録、チャットでの随時確認です。

失敗3は、最初から5〜7名の体制を組んで相性が悪く3か月で解散することで、対策は1〜2名のトライアルからです。失敗4は、契約の柔軟性を確認せずに長期契約を結び、事業計画が変わっても縮小できず使われないリソースに費用が発生し続けることで、対策は契約前に「途中解約の予告期間」「チーム縮小の条件」「最小契約期間」を確認することです。失敗パターンの全体像はオフショア開発の失敗パターンでも整理しています。

パートナー選びの確認項目: 実績、技術領域、日本語対応と定例、契約の柔軟性(途中解約・縮小・最小期間)、開発プロセスの透明性

相見積もりの面談では、次の5項目を確認してください。自社に近い案件の実績があるか。チームの技術スタックと得意領域が合うか。日本語での窓口と定例ミーティングの頻度はどうか。増員・縮小・交代・途中解約の条件はどうか。タスク管理と進捗報告の方法は透明か。加えて、単価に何が含まれるか(PM・レビュー・テストは別料金か)と、実装するエンジニアと契約前に面談できるかも聞いてください。品質を人の努力ではなく工程の仕組みで担保しているかはオフショア開発の品質の8つの質問が使えます。

相場を体制別に押さえ、小さく始め、契約の柔軟性を先に確認する。これがラボ型で失敗しない進め方の要点。

当社のラボ型開発——日本人PM付きの2パターン体制、公開単価、最短2週間で開始、事例

ここまでの判断軸と相場を踏まえ、当社(TALENTBASE VIETNAM)のラボ型開発の体制と単価をお伝えします。「日本人PMをフロントに置く」「単価を公開する」「1名から最短2週間で始めて1か月単位で増減する」の3点が、前章までの弱点と失敗パターンへの当社なりの答えです。相見積もりの比較対象としてお使いください。

2パターンの体制(表): パターンA 日本人PM/BrSE+エンジニア(推奨)、パターンB エンジニアのみ

パターンAは第3章で述べた「管理役がいない会社」の解決策で、当社が推奨する体制です。パターンBは、エンジニアの手だけ増やしたい会社向けで、SESに近い使い方をラボ型の契約でできます。

単価と最小構成: 実務3年1,500USD(約22.5万円)・5年2,000USD・10年/BrSE 3,000USD、日本人PM+2〜3人月で月額約80万円〜

当社の単価は公開しています。実務3年目安のエンジニアが月額1,500USD(約22.5万円、1USD=150円換算目安)、5年目安が2,000USD、10年目安とブリッジSEが3,000USDです。前章で挙げた市場相場(オフショア開発白書2025年版のベトナム プログラマー40.1万円、ブリッジSE59.0万円)と比べると低い水準ですが、理由は単純で、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインし、協力会社や紹介経由の紹介料・仲介マージンが構造的に発生しないためです。当社調べで市場相場の約1/2です。日本人PMをフロントに置いた2〜3人月の最小構成で月額約80万円からとなります。単価には日本人PMによる設計レビュー、Gitプルリクエストによるコードレビューの標準化、リリース前のダブルチェックが含まれます。

開始と調整: 1名から、最短2週間、増員は約1週間、1か月単位のリプレイスメント、日本国内契約

契約は1名から可能で、最短2週間で開始できます。増員は約1週間、メンバーの交代(リプレイスメント)は1か月単位で対応するので、前章の失敗4「契約の柔軟性」への答えになります。流れは、打ち合わせで要件と体制を確認し、人財データベースから候補をアサイン(約1週間)、お客様と候補者の面談(約1週間)、開発開始の4段階です。契約と支払いは日本国内の法人と日本法準拠で行い、海外送金は不要です。生成AIやAIコーディング支援を標準で使うAI活用開発体制で、AWS認定11冠のクラウド・生成AIスペシャリストが在籍しています。

事例(表): 介護SaaS(BrSE1+FS2でコスト半分以下)、介護士マッチング(FS4名)、FinTechマッチング(PM1+FS2)

3件とも、第3章の判断軸で言う「継続的に開発が発生し、要件が動く」案件です。介護SaaSの例は、社内に技術リーダーがいたためブリッジSEをフロントにしたパターンAの構成で、仕様変更の多いSaaS開発を月額固定で回しています。事例の詳細はオフショア開発の事例でも紹介しています。

自社の案件にラボ型が向くか、向くならどの体制でいくらから始められるか。現在の体制と要件をお聞かせいただければ、2パターンのどちらが合うかと概算見積もりでお答えします。ラボ型開発サービスの詳細はサービスページをご覧ください。

ラボ型開発でよくある質問

ラボ型開発の相談で繰り返し聞かれる5つの質問に、ここまでの内容を踏まえて短く答えます。契約前の社内説明や、開発会社への質問リストの下書きとしてお使いください。

Q1. ラボ型開発には成果物の完成保証がありますか

ありません。ラボ型は準委任契約なので、開発会社は「契約期間中、誠実に業務を行う義務(善管注意義務)」を負い、成果物の完成責任は負いません。完成保証が必要なら、要件を固めて請負契約にする方が適しています。ただし、進捗の報告義務や品質管理の仕組み(レビュー・テスト)は契約で定められるので、契約前に確認してください。

Q2. 契約期間はどのくらいで、途中で縮小・解約できますか

一定の期間を定めて契約し、更新していく形が基本です。期間の長さと縮小・解約の条件は会社によって大きく異なるので、契約前に「途中解約の予告期間」「チーム縮小の条件」「最小契約期間」を必ず確認してください。当社は1か月単位で増減・交代に対応しています。

Q3. タスクが少ない月も月額を払うのは無駄ではありませんか

月額固定のラボ型では、タスクが少ない月も費用が発生します。無駄にしないためには、バックログ(将来やりたいことの一覧)に数か月先まで着手できる分量を常に積んでおき、開発の隙間に技術的負債の解消・テスト整備・ドキュメント整備を進める運用が有効です。それでも発注量が少額・不定期に収まる見込みなら、そもそもラボ型は向きません。

Q4. 国内のラボ型とオフショアのラボ型はどう選べばよいですか

費用は、同じ人数ならオフショアの方が大きく低くなります(当社の公開単価は市場相場の約1/2・当社調べ)。一方でオフショアは言語と時差の管理が必要です。ベトナムなら時差2時間で、日本人PMやブリッジSEをフロントに置けば、国内と同じ感覚で進められます。まず1〜2名で試し、コミュニケーション品質を確かめてから拡張するのが安全です。

Q5. SESとラボ型はどう使い分ければよいですか

社内に管理役がいて、個人単位で手を借りたい、常駐で直接指示したいならSES。チームごと継続的に開発を任せたい、開発会社側でノウハウを蓄積させたい、仕様変更が多いならラボ型が向きます。どちらも準委任である以上、発注者から個人への直接の指揮命令はできない点は共通です。両者の違いの詳細はSESとはの記事で解説。

まとめ: ラボ型開発は「継続・要件が動く・POがいる」案件で選ぶ。小さく始めて契約の柔軟性を確認する

ラボ型開発とは、開発会社の側に自社専属の開発チームを一定期間確保し、月額で継続契約する手法です。法律上は準委任契約で、請負のような完成責任はない代わりに、仕様変更や優先順位の変更に追加費用なしで対応できます。同じ準委任のSESとは、チームか個人か、開発会社側で働くか常駐か、ノウハウがどこに残るかが違います。

向くのは、継続的に開発が発生し、要件が動き、社内に優先順位を決める人がいる案件です。開発期間の見通し・体制の安定性ニーズ・コスト構造の3軸で2軸以上当てはまればラボ型を検討し、要件が固まった単発案件や、発注量が少額・不定期なら請負やSESを選んでください。固定費・立ち上がり・管理負荷という弱点は、バックログの整備、プロダクトオーナーの設置、PM/BrSE込みの体制、オンボーディング資料で管理できます。費用は同じ人数ならオフショアのほうが国内より大きく低くなり、当社は実務3年目安1,500USD(約22.5万円・1USD=150円換算の目安)、日本人PMを含む最小構成で月額約80万円からと単価を公開しています。複数社を比較し、1〜2名でスモールスタートし、途中解約・縮小・最小契約期間を契約前に確認するのが失敗しない進め方です。

当社は日本人PMをフロントに置くパターンAとエンジニアのみのパターンBの2体制で、実務3年目安1,500USD(約22.5万円)の公開単価、1名から最短2週間で開始、1か月単位の増減・交代に対応しています。SESとの違いをさらに詳しく知りたい方はSESとは、失敗パターンの全体像はオフショア開発の失敗パターンもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、ラボ型が向くかどうかの判断と概算見積もりでお答えします。