はじめに
オフショア開発を検討すると、ほぼ必ず「ラボ型開発」と「請負開発」という2つの契約形態が出てきます。どちらも海外の開発会社に開発を任せる点は同じですが、契約の考え方、費用の決まり方、仕様変更への強さは大きく異なります。
本記事では、ラボ型開発の基本を整理したうえで、請負との違い、費用の考え方、向いている案件と注意点を解説します。オフショア開発全体の進め方については「オフショア開発とは？メリット・費用・進め方」もあわせてご覧ください。
1. ラボ型開発とは
ラボ型開発とは、一定期間、自社専任の開発チームを海外の開発会社に確保し、優先順位を見直しながら継続的に開発を進める形態です。「ラボ契約」「ODC（オフショア開発センター）」と呼ばれることもあります。
契約は準委任契約（T&M：Time & Material）で結ぶのが一般的です。対価は「完成した成果物」ではなく、「確保したチームが一定期間、業務を遂行すること」に対して支払います。そのため、開発の途中で作る機能や順番を入れ替えても、契約そのものを結び直す必要はありません。
2. 請負開発との違い
もう一つの代表的な形態が請負契約です。請負は、あらかじめ合意した範囲の成果物を完成させることを約束する契約で、仕様と納期と金額を最初に固めて進めます。
| 比較項目 | ラボ型開発（準委任） | 請負開発 |
|---|---|---|
| 約束するもの | 一定期間の業務の遂行 | 合意した成果物の完成 |
| 費用の決まり方 | チームの人数・役割 × 期間 | 合意したスコープに対する固定金額 |
| 仕様変更 | 優先順位の入れ替えで柔軟に対応 | 原則として追加見積もり・契約変更が必要 |
| 完成責任 | 開発会社は善管注意義務を負うが、完成義務は負わない | 開発会社が完成義務と契約不適合責任を負う |
| 発注側の関与 | 優先順位の判断や受け入れに継続的に関わる | 要件定義と受け入れが中心 |
| 向いている案件 | 要件が流動的、継続改善、長期開発 | 要件・範囲・納期が明確なシステム開発 |
民法上、請負は「仕事の完成」を目的とする契約（第632条）、準委任は「事務の処理」を委託する契約（第656条）です。2020年の民法改正で、成果物の引き渡しに対して報酬を支払う「成果完成型」の準委任も明文化されました。ラボ型でどちらの形にするかは、契約書で確認しておくと安心です。
3. ラボ型開発のメリット
仕様変更や優先順位の入れ替えに強い
市場の反応を見ながら機能を追加したい、途中で優先順位が変わる可能性が高い、といった案件では、請負のように変更のたびに見積もりと契約を見直す必要がありません。バックログの順番を入れ替えるだけで、チームはすぐに次の作業に移れます。
業務知識やノウハウがチームに蓄積される
同じメンバーが継続して担当するため、システムの構成や業務ルールへの理解が深まっていきます。案件ごとにチームが変わる場合に比べて、立ち上げや引き継ぎにかかる時間を減らせます。
必要なスキルを持つ人材を継続して確保できる
国内では採用が難しい職種でも、一定期間チームとして確保できます。IT人材の不足が続く中で、開発体制を安定させる手段の一つとして選ばれています。
4. ラボ型開発の注意点
発注側にも判断と関与が求められる
ラボ型では、何をどの順番で作るかを決めるのは発注側です。プロダクトオーナーなど優先順位を判断する人がいないと、作業が始まっては止まる状態が続き、チームの力を活かせません。
作業がない期間も費用が発生する
費用はチームを確保している期間に対して発生します。依頼する作業が途切れると、その分も費用になります。月ごとの計画とバックログをあらかじめ用意しておくことが大切です。
品質の基準は運用で担保する
準委任では、開発会社に完成義務はありません。そのため「何をもって完了とするか（DoD）」、レビューのルール、週次の報告内容を最初に合意し、品質を運用で担保する仕組みが欠かせません。
指示の出し方に気をつける
国内の準委任契約では、発注者が受託側の個々のエンジニアに直接指揮命令すると、いわゆる「偽装請負」とみなされるおそれがあります。オフショアの場合も、依頼や指示は開発会社のPMやブリッジSE（BrSE）を通じて行い、役割分担を契約で明確にしておくのが安全です。BrSEの役割については「ブリッジSE（BrSE）とは？」で詳しく解説しています。
5. ラボ型開発の費用の考え方
ラボ型の費用は、基本的に次の式で考えます。
月額費用 ＝ 各メンバーの月額単価 × 人数（＋PM・BrSE・QAなどの役割）
総額は、この月額費用に契約期間をかけたものです。見積もりを比較するときは、単価だけでなく次の点を確認しましょう。
- 体制に含まれる役割：エンジニアだけか、PM・BrSE・QAまで含むか
- 単価を左右する要素：技術スタック、経験年数、日本語力、シニアメンバーの比率
- 立ち上げ期間の扱い：環境構築やドメイン理解にかかる最初の数週間
- 発注側の工数：優先順位の判断、仕様確認、受け入れに必要な社内の時間
請負の見積もりには、仕様の不確実さに備えたリスク分が含まれやすい傾向があります。一方、ラボ型はその分を含まない代わりに、進め方次第で総額が変わります。単価の安さだけで判断せず、管理工数や品質確保の手間を含めた総コストで比べることをおすすめします。
6. ラボ型開発が向いている案件・向いていない案件
向いている案件
- MVPをリリースした後、ユーザーの反応を見ながら継続的に改善したい
- 長期のロードマップがあり、同じチームに継続して担当してほしい
- 仕様変更が継続的に発生する、または要件がまだ固まっていない
- 稼働中のシステムの保守と機能追加を同じチームで回したい
向いていない案件
- 要件・範囲・納期がはっきりしていて、予算を固定したい
- 社内に優先順位を判断する担当者を置けない
- 開発期間が短く、一度作れば大きな変更が見込まれない
後者の場合は、請負開発のほうが向いています。詳しくは「請負開発（固定スコープ）」をご覧ください。
7. ラボ型と請負は組み合わせられる
実際の案件では、どちらか一方に決める必要はありません。たとえば次のような組み合わせがよく採用されます。
- PoCや小規模な請負で始める：進め方やコミュニケーションを確認してから体制を広げる
- 要件が固まった機能だけを請負に切り出す：継続改善はラボで回す
- 保守と改善を一つのラボで担う：障害対応、小改修、運用改善まで同じチームで対応する
アジャイルで進める場合のポイントは「オフショアでのアジャイル開発」でも紹介しています。
8. ARIS Vietnamのラボ型開発
ARIS Vietnamでは、ホーチミンとハノイの開発拠点で、日本語対応のPM・BrSEを窓口としたラボ型開発を提供しています。冒頭の図のように、お客様側の体制や関わり方に合わせて、BrSE・開発メンバー・PMOの配置を選べます。
柔軟に進められる反面、運営ルールが弱いとスコープや品質が崩れやすいのがラボ型の難しいところです。そのため、議事録、課題・リスク管理、変更管理、DoD、週次レポートを標準化し、柔軟性と統制の両立を図っています。まずは1〜3か月で立ち上げ、成果や運用状況を見て継続を判断する進め方が一般的です。
体制の詳細は「ラボ型開発（準委任 / T&M）」のページでご紹介しています。
まとめ
- ラボ型開発は、一定期間専任チームを確保し、優先順位を見直しながら開発を進める形態で、準委任契約が一般的です。
- 請負は成果物の完成を約束する契約で、要件・範囲・納期が明確な案件に向いています。
- ラボ型は仕様変更や継続改善に強い一方、発注側の判断と、品質を運用で担保する仕組みが欠かせません。
- 費用は「単価 × 人数 × 期間」が基本です。役割の範囲や発注側の工数まで含めて比較しましょう。
自社の案件にラボ型と請負のどちらが合うか迷われている場合は、無料相談からお気軽にお問い合わせください。目的や体制をお聞きしたうえで、無理のない進め方をご提案します。
