ラボ型開発とは？準委任・請負との違い・費用・選び方を解説
はじめに
2025年6月5日に公開した旧記事では、専任チームを長期的に確保する「ラボ型開発」と、成果物の完成を前提とする「請負型開発」の違いを中心に解説しました。しかし、実際に開発体制を選ぶ場面では、「ラボ型と準委任は同じものなのか」「ラボ型でも請負契約になるのか」「人月で支払う場合と固定価格で支払う場合は何が違うのか」といった疑問が生まれやすく、開発体制と契約形態が混同されがちです。
そこで本記事では、旧記事の内容を現在のオフショア開発・継続型プロダクト開発の実務に合わせて整理し直します。最初に押さえておきたいのは、ラボ型開発は主に「どのようなチーム体制で開発を続けるか」を表す開発・提供モデルであり、準委任と請負は「何を責任の中心に置き、どのように報酬を決めるか」を定める契約上の考え方だという点です。3つを完全に同列の選択肢として扱うと、費用や責任範囲を誤解しやすくなります。
ラボ型開発の本当の価値は、単に海外のエンジニアを月単位で確保できることではありません。同じチームが一定期間プロダクトへ関わり続けることで、仕様書に書き切れない業務知識、過去の設計判断、コードベースの癖、品質基準、利用者からの反応などを蓄積できる点にあります。特に、要件が定期的に変わるサービス開発や、数年単位で改善を続ける社内システムでは、この「チームに知識が残ること」が速度と品質の両方に影響します。
一方で、仕様が完全に決まっていて短期間で納品したい案件までラボ型にする必要はありません。重要なのは「ラボ型が良いか、請負が良いか」を先に決めることではなく、要件の変化量、発注側がどこまで意思決定へ関与できるか、成果物をどこまで事前定義できるか、そして知識をどのくらい長くチームへ蓄積したいかを整理したうえで、体制と契約を組み合わせることです。
1. ラボ型開発とは？「チームの持ち方」として理解する
ラボ型開発を理解するときは、まず「契約の名前」ではなく「同じチームをどのように維持し、何を継続的に任せるのか」という視点で考えると整理しやすくなります。
1.1 専任チームを一定期間確保し、継続的に開発する
ラボ型開発では、一定期間にわたって専任または専任に近い開発チームを確保し、同じプロダクトやシステムを継続的に改善します。案件ごとに毎回メンバーを組み直すのではなく、同じチームが仕様、利用者、業務ルール、技術的制約を理解しながら開発を続ける点が大きな特徴です。
たとえば新しいサービスを立ち上げる場合、最初の3か月で必要とされた機能と、実際の利用者データが集まった半年後に必要とされる機能は同じとは限りません。ラボ型であれば、当初の計画をすべて固定するのではなく、ロードマップや優先順位を見直しながら同じチームが改善を続けられます。
1.2 ラボ型の価値は「知識がチームに残ること」
長期開発では、仕様書だけでは共有しきれない知識が増えていきます。なぜこの設計を採用したのか、どの機能で過去に障害が起きたのか、どの顧客要望を優先したのか、どの処理は将来置き換える予定なのか。こうした背景をチームが理解していると、新しい機能を追加するたびに前提を説明し直す必要が減ります。
つまりラボ型開発は、単なる「人月の購入」ではありません。継続的なチームへプロダクト知識を蓄積し、意思決定の速度を上げる仕組みとして設計したときに、本来の効果が出ます。
1.3 SYPでは専任・プロジェクト型・ハイブリッド型を使い分ける
SYPのオフショア開発サービスでは、長期的なプロダクト開発に向く専任チーム、明確な成果物・期間を持つプロジェクト型、要件整理や初期設計から入り、方向性が固まった後に専任チームへ移行するハイブリッド型を提示しています。案件の不確実性が高い初期段階と、継続開発の段階で同じ契約・同じ体制に固定する必要はありません。
ラボ型の費用対効果は、初月の作業量だけでなく、同じチームへ知識が残ることで後から生まれる効率まで含めて評価する必要があります。
2. ラボ型・準委任・請負の違いを一覧で比較
3つを横並びで見る前に、「ラボ型＝体制」「準委任・請負＝契約」という違いを置いておくと、費用・責任・変更のしやすさが理解しやすくなります。
| 比較項目 | ラボ型開発 | 準委任契約 | 請負契約 |
|---|---|---|---|
| 位置づけ | 開発・提供モデル | 契約類型 | 契約類型 |
| 中心となる考え方 | 専任性の高いチームを継続確保 | 一定の業務を適切に遂行 | 定めた仕事・成果物を完成 |
| 費用 | 人数 × 役割別人月単価 × 期間が中心 | 人月・時間・月額などで設計されることが多い | スコープ・成果物をもとに固定価格化しやすい |
| 要件変更 | 柔軟性が高い 優先順位の入れ替えに向く | 契約範囲内で調整しやすい | 追加見積り・変更合意が必要になりやすい |
| 完成責任 | ラボ型という名称だけでは決まらない | 仕事の完成そのものが中心ではない | 仕事の完成が中心 |
| 発注側の関与 | 高い。ロードマップ・優先順位へ継続関与 | 比較的高くなりやすい | 仕様確定後は受託側の管理比重が高くなりやすい |
| 知識蓄積 | 蓄積しやすい 同じチームが継続参加 | 契約期間・体制による | 案件完了で体制変更が起きる場合がある |
| 向いている案件 | プロダクト開発、継続改善、モダナイゼーション | 継続開発、保守、上流支援、反復開発 | 仕様・納期・成果物が明確な開発 |
3. 準委任と請負では「何に責任を持つか」が違う
同じ開発業務でも、要件の確定度や責任分担によって、準委任と請負の向き・不向きは変わります。
3.1 準委任は「専門業務の遂行」を中心に考える
準委任では、あらかじめ完成形を厳密に固定するよりも、一定期間にわたり専門的な業務を適切に遂行することを中心に考えます。要件定義の支援、継続的な設計・開発、保守改善など、作業を進める中で判断や優先順位が変わる領域と相性があります。
ただし「準委任なら何でも自由に変更できる」という意味ではありません。どの業務を対象にするか、どのように報告するか、どの責任者同士が意思決定するかを明確にしないと、稼働時間は増えているのに成果が見えにくい状態になります。
3.2 請負は「仕事の完成」を中心に考える
請負は、契約で定めた仕事を完成させることが中心です。仕様、成果物、納期、検収条件を事前に明確化できる案件では、予算と責任範囲を管理しやすくなります。短期間の移行作業、仕様が固定されたモジュール、明確な納品物がある開発では有力な選択肢です。
一方、要件が毎月変わるサービス開発を最初から固定価格の請負へ押し込むと、変更のたびに追加見積りと合意が必要になり、変更管理そのものが負担になることがあります。
3.3 ラボ型と契約形態は組み合わせて考える
実務では、プロダクトのコア開発を専任チームで継続しつつ、仕様が固まった一部の移行作業やデータ整備だけを別の請負スコープとして切り出すこともできます。また、最初の要件整理を業務遂行型で進め、仕様が確定した後に請負へ移す方法もあります。
→ 準委任と相性がよい
固まる
→ 請負を検討しやすい
4. ラボ型開発の費用は「人数 × 役割別単価 × 期間」で考える
ラボ型では、機能ごとの一括見積りよりも、「どの役割を何人、何か月確保するか」で予算を組む方が実態に近くなります。
4.1 2026年のベトナム人月単価を参考にすると
2026年のベトナムオフショア開発に関する公開相場では、プログラマー40.1万円、シニアエンジニア50.0万円、ブリッジSE59.0万円、プロジェクトマネージャー71.4万円が1人月あたりの参考値として示されています。実際の単価は、経験年数、技術領域、日本語対応、難易度、契約期間などによって変わります。
4.2 SYPの料金目安は40万円〜／1名・月
SYPのオフショア開発サービスでは、料金目安を1名・月あたり40万円〜（税別）と案内しています。また、安定した専任チームは通常5名程度からの開始を想定しているため、最低単価だけで単純計算すれば5名体制で月200万円〜が一つの入口になります。
ただし、実際のチームは全員が同じ単価になるわけではありません。シニア、ブリッジ、品質保証、プロジェクト管理などを組み合わせれば平均単価は変わります。そのため「5名だから月200万円」と固定的に見るのではなく、必要な役割と投入比率から見積りを作る方が現実的です。
4.3 月額だけでなく、立ち上がりと知識蓄積まで含めて見る
ラボ型では、最初の1〜2か月に仕様理解、環境構築、開発規約の習得などが集中するため、開始直後の生産性だけを見て評価すると判断を誤ることがあります。チームがプロダクトを理解し、レビュー指摘や手戻りが減り、改善速度が上がっていく過程まで含めて評価する必要があります。
5. 同じ5名チームでも費用が変わる5つの要因
ラボ型の見積りは「人数」だけでは決まりません。チーム構成と業務難易度によって、必要な役割と単価が変わります。
一般的な業務システムと、AI・データ基盤・高負荷処理・クラウド移行では必要な経験値が異なります。
ジュニア中心か、設計判断まで担えるシニア中心かで平均人月単価は大きく変わります。
日本側との要件調整、会議、文書化を誰が担うかによって、ブリッジや管理役の比率が変わります。
単体テストだけか、自動化、性能、セキュリティまで含むかで品質保証の工数が変わります。
長期で体制を維持できる案件ほど採用・配置を計画しやすく、短期・頻繁な増減は調整コストが増えます。
6. ラボ型開発が向いている案件・向いていない案件
- 半年〜数年単位で改善を続けるプロダクト
- 利用者の反応を見ながら要件を変えたい
- 反復的な開発や定期リリースを行う
- 業務・システム知識を外部チームにも蓄積したい
- 開発量に応じてチーム規模を調整したい
- 保守・改善まで一体で考えたい
- 仕様が完全に確定し、変更予定がほぼない
- 短期間の単発案件で継続チームが不要
- 成果物・納期・金額を最初に固定したい
- 発注側に優先順位を決める責任者がいない
- 毎月のチーム稼働より納品物単位で管理したい
ラボ型の柔軟性は、変更があるからこそ価値を持ちます。反対に、作るものが最初から明確で変更がほとんどない案件では、専任チームを長期間維持するより、成果物と納期を固定したプロジェクト型の方が予算管理しやすい場合があります。
7. ラボ型・準委任・請負は、4つの質問で整理すると選びやすい
「どれが優れているか」ではなく、案件の不確実性と発注側の関与度から選びます。
頻繁に変わるなら、専任チームや業務遂行型の契約と相性が良くなります。仕様が固定されていれば請負を検討しやすくなります。
プロダクト責任者やプロジェクト責任者が継続して意思決定できるなら、ラボ型の柔軟性を活かしやすくなります。
明確に定義できるほど請負と相性が良く、探索や改善が中心なら柔軟な契約の方が管理しやすくなります。
継続的な製品知識や業務知識が競争力になる場合、同じチームを維持する価値が高くなります。
8. ラボ型を「人を並べるだけ」にしない4つの条件
8.1 メンバーを頻繁に入れ替えず、専任性を守る
ラボ型の価値は、同じチームが長く関与することで生まれます。短期的な単価最適化を優先して頻繁にメンバーを入れ替えると、仕様理解や開発環境の習得を毎回やり直すことになり、知識蓄積の効果が薄れます。
8.2 日本側と開発側の間に「翻訳」ではなく「判断の橋」を置く
オフショア開発では、日本語を話せる人がいるだけでは十分ではありません。なぜこの機能を優先するのか、どこまで品質を求めるのか、どの条件なら仕様を変更できるのかといった背景まで理解し、開発側へ伝えられるブリッジ役が重要です。
8.3 上流工程から参加し、作る理由を共有する
実装部分だけを切り出すと、チームは「何を作るか」は理解できても「なぜ作るか」を理解しにくくなります。SYPでは要件整理、基本設計、技術計画など上流からの参画も可能としており、初期段階で方向性をそろえたうえで専任体制へ移る方法を示しています。
8.4 品質・進捗・アクセスを日常運用として管理する
ラボ型は長期契約だからこそ、進捗報告、コードレビュー、品質保証、アクセス権限、参加・離任手順などを最初から運用化する必要があります。「信頼して任せる」ことと「見えなくする」ことは同じではありません。透明性のある運用が、発注側と開発側の双方に必要です。
9. 準委任・請負では「指揮命令」と実際の運用を確認する
契約書の名称だけを整えても十分ではありません。実際に誰が誰へ、どのように作業指示を出しているかが重要です。
9.1 契約名ではなく、実態で区分される
厚生労働省は、請負では請負事業主が自社の労働者を指揮命令し、注文主と労働者の間に指揮命令関係を生じさせないことを重要な区分として示しています。形式上は請負であっても、発注者が受託側の労働者へ直接作業指示を行うなど、実態が労働者派遣に当たる場合には、いわゆる偽装請負の論点が生じます。
9.2 ラボ型では「優先順位の共有」と「直接指揮」を混同しない
ラボ型では、発注側がロードマップやプロダクトバックログへ深く関与するため、コミュニケーション量が多くなります。そのため、発注側が何を決め、受託側の責任者がどのようにチームへ作業指示を出すのかを明確にしておくことが重要です。
ロードマップへ深く関与することと、受託側の個々の労働者へ直接指揮命令することは同じではありません。
10. SYPの専任チームはどう立ち上がる？
ラボ型は、契約を締結した瞬間から高い生産性が出るわけではありません。最初の数週間で、技術要件、役割、働き方、品質基準をそろえることが重要です。
約2週間のディスカバリーで、技術要件、役割、開発文化を確認。
候補者の経歴を確認し、主要メンバーとは事前面談も可能。
4週目を目安に最初のスプリントを開始し、定期的に成果を確認。
ロードマップに応じ、スコープ・役割・人数を継続的に調整。
ここで大切なのは、最初から最大人数を入れることではありません。初期の課題が設計中心ならシニアやブリッジを厚めにし、実装量が増える段階で開発者を追加するなど、フェーズに合わせてチーム構成を変える方が費用を使いやすくなります。
11. ラボ型開発で起こりやすい4つの失敗
安い人月でも確認・修正・手戻りが多ければ総費用は増えます。自走できる範囲まで見る必要があります。
優先順位を決める人がいないと、柔軟な体制が「何を作るか決まらない体制」へ変わってしまいます。
交代のたびにオンボーディングが発生し、ラボ型の知識蓄積という最大の利点を失います。
何人月使ったかだけでなく、リリース速度、障害、手戻り、自走度なども合わせて評価する必要があります。
ラボ型では、発注側にも一定の運営能力が求められます。優先順位の決定、受入確認、業務知識の共有をすべて受託側へ丸投げすると、柔軟性は活かせません。逆に、発注側が細かな作業指示まで行えば、チームの自律性を失い、契約上の運用リスクも高まります。
12. ラボ型開発・準委任・請負に関するよくある質問
Q1. ラボ型開発と準委任契約は同じですか？
同じではありません。ラボ型は専任性の高いチームを継続的に確保する開発・提供モデル、準委任は業務遂行を中心とする契約類型です。実務ではラボ型の体制を準委任契約で運営することがありますが、用語の意味は分けて考える必要があります。
Q2. ラボ型開発では成果物の完成責任はありませんか？
「ラボ型」という名称だけでは完成責任の有無は決まりません。責任範囲は実際の契約内容によって定まります。準委任として継続開発する部分と、成果物を明確に定義して請負とする部分を分ける方法もあります。
Q3. ラボ型開発の費用はどのくらいですか？
一般には人数、役割別の人月単価、契約期間で考えます。2026年のベトナムの公開相場では、プログラマー40.1万円、シニアエンジニア50.0万円、ブリッジSE59.0万円、プロジェクトマネージャー71.4万円が1人月の参考値です。SYPでは1名・月40万円〜（税別）を料金目安として掲載しています。
Q4. ラボ型と請負を同じプロジェクトで組み合わせられますか？
可能です。コアプロダクトは専任チームで継続開発し、仕様が固定された移行作業や特定モジュールだけ請負として切り出すなど、不確実性に応じて分ける考え方があります。
Q5. ラボ型では発注者がエンジニアへ直接タスクを指示できますか？
契約形態と実際の運用によって確認が必要です。請負・準委任等の名目であっても、発注者が受託側の労働者へ直接指揮命令する実態がある場合、労働者派遣との区分が問題になる可能性があります。
Q6. 何人くらいからラボ型チームを始めるべきですか？
案件によって異なりますが、SYPでは安定した専任チームを通常5名程度から想定しています。重要なのは人数そのものではなく、設計・実装・品質・橋渡しに必要な役割が揃っていることです。
まとめ
ラボ型開発、準委任契約、請負契約を比較するときに最も重要なのは、3つを同じレベルの言葉として扱わないことです。ラボ型は、専任性の高いチームを一定期間維持し、知識を蓄積しながら開発する「体制」の考え方です。一方、準委任と請負は、何を責任の中心に置き、どのように成果と報酬を定義するかという「契約」の考え方です。
要件が変わりやすく、継続的に改善するプロダクトでは、専任チームと柔軟な契約の組み合わせが機能しやすくなります。一方、成果物、仕様、納期が明確で変更が限定的な案件では、請負の方が予算と責任を管理しやすい場合があります。さらに、長期的なコア開発はラボ型、確定した一部工程は請負というように、同じプロジェクト内で使い分ける方法もあります。
SYPでは、専任チーム、明確なスコープを持つプロジェクト型、上流工程から専任チームへ移行するハイブリッド型を用意し、要件整理から設計、開発、品質保証、保守まで支援しています。単価だけで体制を決めるのではなく、必要な役割、期間、発注側の関与方法、要件変更の多さを整理したうえで、最も運用しやすい組み合わせを設計することが重要です。
必要な人数、役割、開発期間、要件の確定度、社内の意思決定体制を確認し、専任チーム・プロジェクト型・ハイブリッド型のどれが現実的かを整理します。
オフショア開発について無料相談する →※費用は公開情報をもとにした参考値です。本記事は契約・開発モデルの一般的な整理を目的としており、法的助言ではありません。個別の契約設計は法務・専門家へご確認ください。
