ラボ型開発とは？請負・準委任との違いと費用

01はじめに｜この記事でわかること

要点：この記事では、ラボ型開発の仕組みを請負契約・準委任契約と並べて整理し、費用がどう決まるか、どんな案件に向くかまでご説明します。オフショア開発の基本を押さえた方が、次に契約の形を選ぶために読む記事です。

「ラボ型がいいと勧められたけれど、請負と何がちがうのかよくわからない」。オフショア開発のご相談で、契約形態の話になるとよく出てくる疑問です。

比較表を見てもぴんとこないのは、契約書のちがいだけでは自社に合う形を選べないからです。効いてくるのはもっと手前のこと。仕様が固まっているか、公開後も改修が続くか、社内に指示を出せる人がいるか。この3つです。

そこでこの記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、ベトナムの開発チームを運用してきた立場からラボ型の実態をご説明します。読み終えるころには「私の案件はラボ型と請負のどちらか」を自分で判断できます。

次の動画では、システム開発における請負契約と準委任契約の使い分けが短くまとまっています。この記事とあわせてご覧ください。

02ラボ型開発とは｜専属チームを一定期間おさえる進め方

要点：ラボ型開発とは、開発会社の中に自社専用のチームを半年〜1年ほど確保し、その期間ぶんの費用を月額で支払う進め方です。ベトナムオフショア開発でよく使われる形で、ラボ契約やODCとも呼ばれます。

言葉の印象から「実験的な開発」を思い浮かべる方もいますが、そうではありません。ラボは研究室ではなく、社外に置いた自社の開発チームという意味に近いものです。

具体的には、次のような形で動きます。

• 人数と期間を先に決めます。「エンジニア3名を12か月」という形で枠を押さえます。
• 費用は月額固定です。作業量ではなく、人数と期間で決まります。
• 作るものは期間中に変えられます。優先順位の入れ替えが前提の進め方です。
• メンバーは基本的に固定です。案件ごとに解散せず、同じ顔ぶれが担当します。

いちばん大きなちがいは4つめです。請負では案件が終わればチームは解散しますが、ラボ型では業務知識がチームに残ります。2年目の開発が速くなるのは、この蓄積があるからです。逆に言えば、1回きりの開発ではこの利点が効きません。

03請負契約との違い｜完成責任を誰が負うのか

要点：いちばんの違いは完成責任です。請負は「決めたものを完成させる」約束、ラボ型は「決めた期間、開発に取り組む」約束です。要件定義がどこまで固まっているかで、選ぶべき形が変わります。

民法では、請負は仕事の完成を約束する契約と定められています（民法・e-Gov法令検索）。つまり請負では、決めたものが動く状態で納品されるまでが開発会社の責任です。この差は実務で次のように出てきます。

• 仕様変更のあつかい。請負では追加の見積が必要です。ラボ型では期間内の入れ替えで済みます。
• 検収のしかた。請負は成果物の検収で完了します。ラボ型は月ごとの報告と稼働の確認です。
• 止まったときの負担。請負では開発会社が抱えます。ラボ型では発注側が月額を払い続けます。

3つめが実は一番重要です。社内の判断が遅れて指示を出せない月も、費用は同じだけ発生します。人月単価と工数の仕組みとあわせて、社内の体制と見比べてください。

請負は「何を作るか」で買う契約、ラボ型は「誰が何か月働くか」で買う契約です。

04準委任契約との違い｜ラボ型は準委任の一形態です

要点：ラボ型と準委任は対立する概念ではありません。ラボ型は準委任契約の一形態です。ちがうのは、期間と人数を先に固定して専属チームを組む点にあります。外注と内製の判断とあわせて考えてください。

ここは誤解が多いところです。「請負・準委任・ラボ型の3種類がある」と説明されることがありますが、法律上の契約類型は請負と準委任の2つで、ラボ型はその準委任側に含まれます。では一般的な準委任と何がちがうのか。実務での差は次のとおりです。

• 期間の縛り。一般的な準委任は月単位で調整できます。ラボ型は半年〜1年の枠で契約します。
• メンバーの固定度。ラボ型は同じメンバーが継続します。都度アサインではありません。
• 体制の作り方。ラボ型ではブリッジSEやリーダーを含めたチームとして編成します。

この3つめが品質を大きく左右します。窓口が実質的に機能していないと、ラボ型はただの人員確保で終わってしまいます。ブリッジSEの役割を先に確認しておいてください。

05費用の仕組み｜月額固定で何が決まるのか

要点：ラボ型の費用は「1人あたりの月額 × 人数 × 契約月数」で決まります。作業量では変わりません。だから総額を抑える鍵は、単価交渉ではなく人数と期間の設計になります。

請負は積み上げた工数に対して払いますが、ラボ型は確保した席に対して払います。ホテルの部屋を押さえるのに近い感覚です。費用に影響する要素は、おもに次の4つです。

• 職種の構成。ブリッジSE・リーダー・開発メンバー・テスト担当で単価が変わります。
• 技術領域。一般的なWeb開発より、モバイルやデータ処理系は高くなる傾向があります。
• 契約期間。長期ほど月額が下がる設計になっていることが多いです。
• 為替。海外チームの場合、円建てか現地通貨建てかで実質負担が変わります。

4つめは近年とくに影響が大きくなっています。円安が続いた期間は、単価が変わらなくても円ベースの支払いが増えました。契約時に通貨とレートの基準日を決めておいてください。規模別の考え方はオフショア開発の費用相場で整理しています。

06ラボ型が向く案件・向かない案件

要点：ラボ型が向くのは、公開後も改修が続く自社サービスや業務システムです。逆に、仕様が固まった一度きりの制作には向きません。コーポレートサイト制作のような案件は、請負のほうが安く早く終わります。

判断の軸は「作り終わったあとも、出す仕事が残っているか」です。向いている案件は次のようなものです。

• 自社サービスやアプリで、公開後も機能追加が続くもの
• 業務システムで、現場の要望を拾いながら育てていくもの
• ECサイトのように、施策と改修を回し続けるもの

向かない案件もはっきりしています。

• 仕様が完全に固まっていて、納品したら終わりのもの
• 社内に、開発チームへ指示を出す担当者を置けないもの
• 3か月以内で完結する小規模な改修

2つめは見落とされがちです。発注側が優先順位を決めて渡し続けないと、チームは待機したまま費用だけが出ていきます。オフショア開発の失敗事例でも、この損失はよく出てきます。

07契約形態別・判断のものさし

要点：請負・一般的な準委任・ラボ型を6つの軸で並べると、選び方が見えてきます。判断材料は完成責任・仕様変更・期間・精算・体制・向く案件の6つです。RFPの書き方を考える段階で、この表を横に置いてください。

表を縦に見ると、ラボ型だけ「発注側の負担」が重いことがわかります。柔軟さと引き換えに、社内の手間が増える形です。ここを覚悟できるかが判断の分かれ目になります。

08体制規模別・月額と年額のモデル試算

要点：ラボ型の総額は、体制を組んだ時点でほぼ決まります。人数を1名増やすと、年額では数百万円単位で動きます。システム開発の費用相場と並べて、規模感をつかんでください。

月額の差が小さく見えても、年額では大きく開きます。標準の4名体制と拡張の6名体制では、1年で1,000万円近くちがいます。だから体制は「あったら助かる人数」ではなく「毎月確実に仕事を出せる人数」から逆算してください。増やすのは途中からでもできます。

09稼働率が実質単価をどう変えるか

要点：ラボ型でいちばん損が出るのは、チームを遊ばせたときです。稼働率が6割まで落ちると、実質の単価は約1.7倍になります。単価の安さは、この一点で簡単に消えます。

たとえば国内委託より3割安い単価で契約しても、稼働率が7割で推移すれば実質単価は1.43倍になり、その差は消えます。原因は開発側ではなく発注側にあることがほとんどです。仕様の確認待ち、社内の承認待ち、テスト環境の準備待ち。どれも数日の遅れが積み上がって起きます。

10ラボ型チームは何か月目から速くなるのか

要点：ラボ型チームの生産性は、立ち上げ直後がいちばん低く、4〜6か月目で安定します。だから半年未満の契約では、投資した学習期間を回収しきれません。ベトナムオフショア開発の実態とあわせてご覧ください。

大事なのは、1か月目の遅さを「品質が低い」と受け取らないことです。この期間は業務を覚えてもらう投資であって、失敗ではありません。ここで見切りをつけると、投資だけして回収しないまま終わります。半年は続ける前提で始めてください。

11偽装請負にしないための線引き

要点：準委任だからといって、発注側が現場の担当者へ直接こまかく指示を出してよいわけではありません。国内の技術者が入る体制では、実態に即して判断されます。オフショア開発の失敗と対策とあわせて確認してください。

ラボ型は「社外の自社チーム」と表現されるので、つい自社の部下のように扱いたくなります。ここに落とし穴があります。

厚生労働省は、労働者派遣にあたるか請負にあたるかは契約書の名称ではなく実態で判断すると示しています（37号告示に関する疑義応答集・厚生労働省）。同省はシステム開発を請負業務とする場合の考え方も別途示しており、開発の現場でも判断が必要な論点です。

実務では、次の線を守っておくと安全です。

• 指示はチーム単位で出します。個人ではなく、リーダーやブリッジSEを通します。
• 依頼するのは成果物と期限です。作業手順や1日の進め方までは指定しません。
• 勤怠や休暇は開発会社が管理します。発注側が出退勤を指示することはありません。
• 使うツールと環境は契約で決めます。口頭で足すと線があいまいになります。

海外のチームだけの場合と、国内の技術者が加わる場合とでは考え方が変わります。迷う体制であれば、契約前に社会保険労務士や弁護士へ確認しておくと安心です。

12契約前に決めておく6項目

要点：ラボ型でもめやすいのは、メンバーの交代・稼働の報告方法・成果物の権利・解約条件・通貨・引き継ぎの6つです。どれも後から決めようとすると発注側が不利になります。

1. メンバーの交代ルール。通知の期限と引き継ぎ期間を決めます。
2. 稼働の報告方法。何を稼働とみなし、月次でどう報告するかを決めます。
3. 成果物の権利。ソースコードと資料の権利がいつ移るかを明記します。
4. 中途解約の条件。予告期間と精算方法を決めます。
5. 支払い通貨とレート。円建てか、レートの基準日をいつにするかを決めます。
6. 終了時の引き継ぎ。受け取るものを一覧にしておきます。

4つめはとくに確認してください。ラボ型は期間の確保が前提なので、途中でやめる負担が請負より重くなります。6つめも忘れがちです。設計書やテスト仕様書が残っていないと、次の会社に移るときに作り直しが発生します。依頼する前に準備すべきことの段階から意識しておいてください。

13まとめ｜ラボ型は仕事を出し続けられるかで決まる

要点：ラボ型開発とは、専属チームを期間で確保する準委任の一形態です。請負との違いは完成責任の有無。得か損かは単価ではなく、稼働率と契約期間の長さで決まります。

ラボ型の損得は契約書の条文では決まりません。稼働率が6割まで落ちれば実質単価は1.67倍になり、半年で切り上げれば立ち上がりの投資が回収できません。

逆に、出す仕事が続いていて社内に優先順位を決められる人がいれば、ラボ型はとても強い進め方です。2年目以降は同じ費用でこなせる量が増えます。オフショア開発の体制を検討中でしたら、まずは出せる仕事の量から一緒に整理させてください。費用は案件ごとのお見積りです。

14よくある質問

要点：ラボ型開発について、ご相談の場でよくいただく質問をまとめました。最低人数や契約期間、途中で人数を変えられるかなど、判断に直結するところを中心に整理しています。

1. ラボ型開発は最低何名から始められますか

2名から始める例が多くなっています。1名だけの体制は、休暇や退職のときに開発が止まるためおすすめしていません。ブリッジSEを他案件と共有すれば、2名でも運用できます。

2. 契約期間の途中で人数を変えられますか

増員は比較的柔軟に対応できます。ただし新しいメンバーが業務を覚えるまで時間がかかるため、すぐには戦力になりません。減員は契約条件で扱いが変わるので、事前に確認しておいてください。

3. ラボ型と請負を組み合わせることはできますか

できます。よくある形です。基幹となる新規開発は請負で完成責任を持ってもらい、公開後の改修と運用をラボ型に移します。切り替えは初回リリースの直後が自然です。

4. ラボ型は本当に費用を抑えられますか

稼働率が高く保てる場合はそうなります。ただし遊ばせた月があると、実質単価は簡単に上がります。オフショア開発の費用相場で規模別の考え方を整理しているので、あわせてご覧ください。

5. 社内にエンジニアがいなくてもラボ型は使えますか

使えます。ただし、業務の内容を説明して優先順位を決められる担当者は必要です。技術の判断は開発会社が補えますが、「どの機能から必要か」は社内の人しか決められません。その役を置ければ、エンジニアがいなくても運用できます。