ラボ型開発とは？請負型との違いと契約上の注意点、発注側に必要な体制を解説

ラボ型開発は、一定期間、自社専属の開発チームを外部に確保する形態です。仕様が固まっていなくても始められ、期間内であれば作業内容を柔軟に変えられます。

この柔軟さが最大の利点ですが、同時に最大の落とし穴でもあります。作業内容を決めて渡す役割は、発注側に残るためです。

指示を出す人が忙しくて手が回らないと、確保したチームは手待ちになります。それでも費用は発生し続けます。「人を借りたのに何も進んでいない」という状態は、この構造から生まれます。

本記事では、請負型や派遣との違い、契約形態としての整理と偽装請負のリスク、そして発注側に必要な体制までを解説します。導入を判断する材料として整理しました。

確認したいポイント	結論	詳細
ラボ型開発とは？	期間を決めて専属チームを確保する形態	成果物ではなく、要員の確保と稼働に対して費用を払う。
請負型との違いは？	完成責任の有無と支払いの対象	請負は成果物の完成に対して、ラボ型は期間の稼働に対して支払う。
派遣との違いは？	指示を誰が出すかが異なる	委託先の管理者を通じて指示する。直接指示は契約上の問題になる。
成否を分けるのは？	発注側の運営体制	タスクを切らさず渡せるかで、稼働率も成果も決まる。

この記事でわかること

• ラボ型開発の仕組みと、請負型・派遣との違い
• 準委任契約としての位置づけと、契約時に決めておく項目
• 発注側の指示の出し方と、偽装請負とみなされないための運用
• チームを動かすために発注側に必要な体制と工数の目安
• 向いている案件・向いていない案件と、失敗しやすいパターン

システム開発やAI導入の体制づくりについて、支援内容とあわせて資料にまとめています。 ＞＞ 資料請求はこちら

ラボ型開発とは何か

まず仕組みを確認します。似た形態がいくつかあるため、違いを押さえておかないと契約段階で誤解が生じます。

ここでは基本の仕組みと、他の形態との違いを整理します。

期間を決めて専属チームを確保する

ラボ型開発では、委託先が自社のために専属のチームを編成します。契約期間は半年から1年といった単位が一般的で、その間そのメンバーは他社の案件を担当しません。

費用は月額で発生します。作業量が多い月も少ない月も、支払う金額は変わりません。期間内であれば、作業内容を追加したり変更したりできます。

オフショア開発で使われることが多い形態ですが、国内の開発会社でも同様の契約は可能です。海外だけの選択肢ではありません。

請負型との違いは支払いの対象

請負型は、あらかじめ決めた成果物の完成に対して対価を払う形です。完成させる責任は委託先が負い、期日までに仕様どおりのものを納めます。

ラボ型は、要員を確保して稼働してもらうことに対して払う形です。成果物の完成を保証するものではありません。この違いが、後述する契約形態の整理につながります。

仕様が確定しているなら請負型のほうが管理は楽です。逆に、作りながら方針を決めていく開発ではラボ型が向きます。

派遣・SESとの違いは指揮命令

外部の人手を使う形態には、人材派遣や技術者の常駐もあります。ラボ型との違いは、誰が作業の指示を出すかにあります。

派遣では、自社の担当者が派遣スタッフに直接指示を出せます。一方ラボ型では、指示は委託先の管理者を通じて行うのが原則です。

この違いは形式ではなく、実際の運用で判断されます。契約書にラボ型と書いてあっても、日常的に個々のメンバーへ直接指示を出していれば、実態は別のものと評価される可能性があります。

3つの形態の整理

混同しやすいため、支払いの対象と責任の所在で整理すると次のようになります。

形態	支払いの対象	完成責任	指示の出し方
ラボ型	要員の確保と稼働（期間）	なし	委託先の管理者を通じて
請負型	成果物の完成	あり	仕様書で伝える
人材派遣	労働時間の提供	なし	自社が直接出せる

この表のどれに当てはまるかは、契約書の名称ではなく実際の運用で決まります。自社の進め方がどの形に近いかを、契約前に確認してください。

契約形態としての整理

ここは上流の判断に関わる部分です。契約の型を理解しないまま進めると、トラブルの際に拠り所がなくなります。

ここでは4点を整理します。

準委任契約が一般的

ラボ型開発は、多くの場合、準委任契約として結ばれます。業務の遂行そのものを目的とする契約で、成果物の完成は義務になりません。

委託先が負うのは、専門家として適切に業務を行う義務です。「作業はしたが、想定したものができなかった」という場合の扱いが、請負型とは異なります。

IPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書（第二版）は、工程ごとの成果物や当事者の責任分担を整理する際の参照先として使えます。契約書を作る前に目を通しておくと、決めるべき項目が見えます。

完成責任がないことの意味

完成責任がないということは、期待した成果が出なかった場合の責任が発注側にも及ぶということです。指示が不明確だった、優先順位が二転三転した、といった要因は発注側の問題になります。

「お金を払っているのだから作ってくれるはず」という前提は成立しません。何を作るかを決めて渡すのは発注側の役割です。

この点を理解せずに契約すると、期間終了時に「思ったものができていない」という不満が残ります。

逆に言えば、完成責任がないからこそ柔軟に方向を変えられます。請負型では仕様変更のたびに条件の見直しが必要ですが、ラボ型では期間内で吸収できます。この柔軟さと引き換えに、判断の責任を持つという関係です。

指示の出し方と偽装請負のリスク

ラボ型では、実務上、発注側の担当者が現地のメンバーとやり取りする場面が多くなります。ここで直接の指揮命令をしていると、実態として労働者派遣とみなされる可能性が出てきます。

厚生労働省は、この区分の判断を明確にするため「労働者派遣事業と請負により行われる事業との区分に関する基準」（37号告示）に関する疑義応答集を公開しています。契約形式ではなく、実態に即して判断される点が示されています。

判断に迷う場合は、作業の指示を委託先の管理者経由に統一する運用にしてください。個々のメンバーの勤務時間や休暇を発注側が管理するような運用も避ける必要があります。

なお、海外の拠点で作業する場合は日本の労働法制が直接適用されない場面もありますが、国内のニアショアや常駐を伴う形態では特に注意が必要です。

契約時に決めておく項目

契約書には、次の項目を明記しておいてください。曖昧なまま始めると、期間中に交渉が発生します。

• 契約期間と、更新・解約の条件（予告期間を含む）
• チームの構成（人数、職種、経験年数の水準）
• メンバー交代が発生する場合の手続きと引き継ぎ
• 指示の伝達経路（誰から誰へ出すか）
• 成果物の権利の帰属と、ソースコードの引き渡し条件
• 稼働状況の報告方法と頻度

とくにメンバー交代の扱いは、必ず入れてください。ラボ型の利点は知識の蓄積にあるため、頻繁に入れ替わるとその利点が失われます。

契約形態の選定や体制の設計を、発注者側の立場で支援しています。 ＞＞ 相談予約はこちら

メリットと、その裏返しにあるデメリット

ラボ型の利点は、そのまま欠点の裏返しになっています。両方を理解しておくと、判断を誤りません。

ここでは対にして整理します。

仕様が固まっていなくても始められる

要件が確定していない段階から着手でき、作りながら方針を決められます。作ってみて違ったら方向を変える、という進め方が可能です。

裏を返せば、方向を決める人が必要だということです。仕様が固まっていないぶん、判断の回数は請負型より多くなります。

同じメンバーが継続するため知識が蓄積される

案件ごとにチームを組み直す必要がなく、システムの構造や業務の背景を理解したメンバーが継続します。説明の手間が回を追うごとに減ります。

一方で、メンバーが入れ替わればこの利点は消えます。委託先の定着率と、交代時の引き継ぎ体制を確認してください。

期間内なら追加費用が発生しにくい

月額が固定されているため、期間内の作業追加で都度見積もりを取る必要がありません。変更のたびの交渉がなくなり、進行が速くなります。

逆に、作業が少ない月も同じ金額が発生します。渡すタスクが尽きれば、その分は費用の無駄になります。

エンジニアを継続的に確保できる

採用が難しい状況でも、必要な技術領域の要員を期間単位で確保できます。採用にかかる費用と時間を省けます。

ただし、雇用ではないため契約終了とともに要員は離れます。社内に技術が残る仕組みを別途考えておかないと、依存が続きます。

メリットとデメリットの対比

整理すると次のようになります。

メリット	その裏返しとなるデメリット
仕様未確定でも着手できる	方向を決める人が発注側に必要
同じメンバーで知識が蓄積される	交代があれば利点が失われる
期間内は追加費用が出にくい	作業が少ない月も費用は同額
要員を継続的に確保できる	契約終了とともに技術も離れる
機密情報を扱いやすい	情報管理の体制構築が前提になる

発注側に必要な体制

ここが本記事で最も重要な部分です。ラボ型の成否は、委託先の実力より発注側の運営体制で決まります。

必要な役割と工数を具体的に整理します。

タスクを切らさず渡す役割

確保したチームには、常に作業できる状態を用意しておく必要があります。次に何をするかが決まっていなければ、メンバーは待つことになります。

具体的には、作業の一覧を維持し、優先順位を付け、詳細を詰めて渡す役割です。この役割を担う人がいないと、費用だけが発生し続けます。

「余裕を持って2週間分のタスクが常に用意されている」状態を目安にしてください。

質問に答える役割

作業中には必ず確認事項が出ます。「この場合はどうするか」という質問に、短時間で回答する人が必要です。

回答が遅れると、その間メンバーは手を止めるか、独自の解釈で進めます。どちらも損失につながります。時差がある場合、1回の往復に1日かかる点も考慮してください。

「24時間以内に回答する」といった目標を決めておくと、運用が安定します。

成果物を確認する役割

できあがったものが意図と合っているかを確認し、修正点を伝える役割です。まとめて後で確認すると、ずれが大きくなってから発覚します。

週単位で動くものを見せてもらい、その都度確認する運用が安全です。この頻度は契約時に取り決めておいてください。

必要な工数の目安

3つの役割にかかる時間は、チームの規模と案件の性質によって変わりますが、目安としては次のようになります。

チーム規模	発注側に必要な工数の目安	担う人の役割
2〜3名	週8〜10時間程度	兼務でも可。ただし固定の時間を確保する
4〜6名	週15〜20時間程度	主担当を決め、他業務との配分を明確にする
7名以上	実質的に専任が必要	管理を委託先に一部任せる設計も検討する

この時間を確保できないなら、規模を小さくするか、上流の管理まで担ってもらえる委託先を選ぶ判断になります。兼務で片手間という前提では、ラボ型は機能しません。

稼働率という考え方

確保したチームが実際に作業できていた割合を、稼働率として把握してください。タスク待ちや回答待ちの時間は、稼働していない時間です。

稼働率が8割を下回っているなら、渡す側の運営に問題があります。委託先を責める前に、自社の体制を見直してください。

月次の報告で、作業時間と待機時間を分けて出してもらうと、この数字が把握できます。

稼働率は、費用対効果をそのまま左右する数字です。月額200万円のチームが稼働率7割なら、実質的には約286万円分の単価で使っていることになります。逆に稼働率を9割まで上げられれば、同じ費用でより多くの成果が得られます。

この観点に立つと、担当者の時間を確保する投資が、単価交渉より効果的な場面があると分かります。週に数時間を追加で確保するだけで、稼働率が1割上がることは珍しくありません。

ラボ型の運営体制づくりや進め方について、伴走して支援しています。 ＞＞ 相談予約はこちら

向いている案件・向いていない案件

ラボ型はあらゆる案件に適した形態ではありません。判断の基準を整理します。

ここでは3つの観点で見ていきます。

向いている案件

次の条件に当てはまる案件は、ラボ型の利点が生きます。

• 継続的に機能を追加していくサービス開発
• 要件が固まりきっておらず、作りながら決めたい案件
• 既存システムの保守と改善が長期的に続く案件
• 技術検証を繰り返しながら方向を探る案件
• 社内に管理できる人がいて、時間を確保できる状況

共通するのは、作業が途切れず続くことです。発注する仕事が常にある状態でなければ、費用が無駄になります。

とくに相性がよいのが、小さく作って反応を見ながら改善を重ねる進め方です。この進め方では仕様変更が前提になるため、都度見積もりが必要な請負型では手続きが追いつきません。

向いていない案件

逆に、次の場合は請負型や他の手段を検討してください。

仕様が完全に確定していて期日までに作りきる案件、単発で終わり継続の予定がない案件、社内に管理できる人がいない状況、そして3か月未満の短期案件です。

とくに短期案件では、立ち上げに使う期間の比率が高くなります。チームがシステムを理解する前に契約が終わり、投資が回収できません。

判断の目安

次の3点をすべて満たすかを確認してください。1つでも欠けるなら、他の形態を検討したほうが安全です。

• 6か月以上、継続して発注する作業があるか
• タスクを整理して渡せる人が社内にいるか
• その人が必要な時間を確保できるか

2つ目と3つ目は、契約前に具体的な名前と時間で確認してください。「誰かがやる」という状態で始めると、開始後に誰もやらない状況になります。

導入の進め方6ステップ

契約前の準備が、その後の稼働率を決めます。順序を守って進めてください。

ここでは6つのステップに分けて説明します。

ステップ1｜発注する作業の量を見積もる

今後6か月から1年で、どれだけの作業があるかを洗い出します。機能追加の計画、保守の見込み、検証したい項目を並べます。

この量が、確保すべきチームの規模を決めます。作業量より多い人数を確保すると、手待ちが発生します。

ステップ2｜社内の担当者と時間を決める

前節の3つの役割を誰が担うか、週に何時間使えるかを決めます。兼務であれば、他の業務との優先順位も明確にします。

この確認をせずに契約すると、開始直後から回らなくなります。上長を含めて合意を取っておいてください。

ステップ3｜小さく始めて相性を見る

いきなり大きなチームを組まず、2〜3名の規模で3か月程度から始めます。品質だけでなく、質問への回答の速さや報告の分かりやすさを確認します。

この段階で、自社の運営が回るかも実測できます。想定より時間がかかるなら、規模を広げる前に体制を見直せます。

ステップ4｜作業の受け渡しの型を作る

どのツールで作業を管理するか、どの粒度で渡すか、完了の判断を誰がするかを決めます。この型ができると、以降の進行が安定します。

作業の説明に必要な情報を一定の形式にそろえてください。毎回書き方が違うと、確認の往復が増えます。

ステップ5｜稼働状況を月次で確認する

作業時間と待機時間を分けて報告してもらい、稼働率を把握します。低い場合は、その原因を委託先と一緒に確認します。

原因の多くは、タスクの準備不足か回答の遅れです。どちらも発注側で改善できます。

ステップ6｜規模と期間を見直す

契約更新のタイミングで、規模が適切かを見直します。作業量が増えているなら増員、稼働率が低いなら縮小という判断になります。

継続することが目的ではありません。発注する作業がなくなれば、縮小や終了も正しい判断です。

開発体制の設計や委託先の見極め方について、資料でご確認いただけます。 ＞＞ 資料請求はこちら

失敗しやすい4つのパターン

ラボ型がうまくいかなかった事例には、共通する型があります。着手前に知っておけば避けられます。

ここでは4つ挙げます。

タスクが切れてチームが手待ちになる

最も多い失敗です。渡す作業が尽き、メンバーが待機している状態で費用だけが発生します。

確保する人数は、確実に発注できる作業量から逆算してください。足りなくなったら増やすほうが、余らせるより損失は小さくなります。

回答が滞って進行が止まる

質問への回答が数日かかり、その間メンバーが手を止める状態です。担当者が兼務で時間を取れない場合に起こります。

回答の期限を運用ルールとして決めてください。担当者が不在の場合の代理も決めておくと、進行が止まりません。

メンバーが頻繁に入れ替わる

知識が蓄積されるはずが、交代のたびに説明をやり直す状態です。ラボ型を選ぶ意味が失われます。

契約前に定着率と、交代時の引き継ぎ手順を確認してください。交代が発生した場合の引き継ぎ期間の扱いも、契約に含めておきます。

成果の確認を後回しにする

まとめて最後に確認した結果、想定と違うものができていたという状態です。期間の大部分を作り直しに使うことになります。

週単位で動くものを見せてもらってください。ずれが小さいうちに修正できれば、手戻りの量は大きく減ります。

費用の考え方

最後に、費用面の判断について整理します。月額の金額だけでは、得か損かは判断できません。

3つの観点で見ていきます。

月額に含まれるものを確認する

開発者の人件費のほかに、橋渡し役の人材、進行管理、品質確認の費用が含まれているかを確認します。含まれていなければ、後から加算されます。

チーム規模が小さいほど、管理側の費用が総額に占める比率は高くなります。2〜3名の規模では、1人あたりの実質的な費用が想定より上がる点に注意してください。

稼働率を掛けて実質単価を出す

月額を人数で割った金額が、そのまま1人あたりの費用ではありません。稼働率が7割なら、実質的な単価はその分だけ上がっています。

この計算をすると、運営体制への投資が費用対効果に直結することが分かります。担当者の時間を確保するほうが、単価交渉より効果が大きい場合もあります。

社内工数を含めて比較する

請負型や社内での開発と比べる際は、社内で発生する工数も金額に換算して並べてください。ラボ型は、この社内工数が最も大きくなる形態です。

それでも選ぶ理由があるとすれば、柔軟性と知識の蓄積です。費用だけで判断すると、ラボ型の利点が評価に反映されません。

業務でのAI活用を広く整理した内容は、業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法でも紹介しています。オフショア開発の費用や委託先の選び方は、ネクストスケールのブログ一覧に掲載している個別の記事もあわせてご覧ください。

まとめ

ラボ型開発は、期間を決めて専属チームを確保する形態です。成果物の完成ではなく、要員の確保と稼働に対して費用を払います。

契約は準委任として結ばれるのが一般的で、完成責任は委託先にありません。何を作るかを決めて渡すのは発注側の役割です。この前提を理解せずに契約すると、期間終了時に不満が残ります。

また、個々のメンバーへ直接指示を出す運用は、契約形態との齟齬を生みます。指示は委託先の管理者経由に統一してください。

成否を分けるのは、発注側の運営体制です。タスクを切らさず渡す人、質問に短時間で答える人、成果を確認する人が必要で、チーム規模に応じた時間の確保が前提になります。

そして、稼働率を必ず把握してください。8割を下回っているなら、原因は渡す側にあります。単価を交渉するより、担当者の時間を確保するほうが効果が大きい場合もあります。

システム開発やAI導入を、どこから・どの順番で進めるべきか。現状を伺ったうえで、具体的な進め方をご提案します。 ＞＞ 相談予約はこちら