ラボ型開発と請負・SESはどう違う？向いている案件と契約前に確認すること
システム開発を外部に依頼するとき、見積もりや提案書の中に「ラボ型開発」「請負」「SES」といった言葉が並ぶことがあります。どれも外部のエンジニアに開発を任せる方法ですが、契約上の約束の中身、費用の決まり方、発注側に求められる関わり方が大きく異なります。
違いを理解しないまま契約すると、「完成まで責任を持ってくれると思っていたのに、毎月の稼働に対する支払いだった」「指示を出せば動いてくれると思っていたのに、直接指示してはいけないと言われた」といった食い違いが起こります。どれが優れているという話ではなく、案件の性質と自社の体制に合うかどうかで選ぶものです。
特にラボ型開発は、法律上の契約類型の名前ではなく、開発会社ごとに中身の定義が少しずつ違います。名前だけで判断せず、契約書に何が書かれているかを確認することが欠かせません。
この記事では、ラボ型開発・請負・SESの違いを整理したうえで、どのような案件にどれが向くのか、契約前に何を確認すればよいのかを、発注側の判断基準として解説します。
ラボ型開発・請負・SESの基本
まず、三つの言葉がそれぞれ何を指しているのかを整理します。ポイントは、「何に対してお金を払うのか」と「誰が作業の進め方を決めるのか」の二点です。
請負は「完成した成果物」に対して払う
請負は民法第632条に定められた契約類型で、受注者が仕事を完成させることを約束し、発注者がその結果に対して報酬を支払う契約です。システム開発でいえば、「この仕様のシステムを、この金額で、この納期までに完成させて納品する」という約束になります。
完成責任は開発会社が負うため、発注側から見ると予算と納期が読みやすいのが利点です。その代わり、開発途中で仕様を変えると、追加見積もりや契約変更の手続きが必要になります。
SESは「エンジニアの作業」に対して払う
SES（システムエンジニアリングサービス）は業界で使われている呼び方で、法律上の用語ではありません。一般には、エンジニアの技術的な作業を準委任契約で提供する形を指します。準委任は民法第656条に基づく契約で、成果物の完成ではなく、事務を処理すること自体が約束の対象です。
多くの場合、エンジニア1人ごとに月額の単価と稼働時間の幅を決め、発注側の現場で作業します。人手を柔軟に補えるのが利点ですが、後で述べるように、発注側の担当者がエンジニアに直接指示を出すと偽装請負になるおそれがあります。
ラボ型開発は「専属チームの一定期間の稼働」に対して払う
ラボ型開発は、開発会社の中に発注者専属のチームを一定期間確保し、その期間の稼働に対して費用を払う形です。契約は準委任で結ぶのが一般的で、チームの人数と期間で月額が決まります。
SESとの違いは、個人の作業ではなくチームとしての開発を任せる点にあります。開発会社側にリーダーやプロジェクトマネージャーがいて、発注側は「何を作るか」「どれを優先するか」を決め、開発会社側は「どう作るか」「誰がどの作業をするか」を決めるという役割分担が基本です。
参考：民法／e-Gov法令検索
三つの契約形態はどう違うか
三つの違いを、発注側が気にする項目ごとに比較します。ただし、実際の契約内容は会社によって異なるため、下の表は一般的な形として見てください。
| 項目 | 請負 | SES（準委任） | ラボ型開発（準委任が一般的） |
|---|---|---|---|
| 支払いの対象 | 完成した成果物 | エンジニア個人の稼働 | 専属チームの一定期間の稼働 |
| 費用の決まり方 | 案件ごとの固定額 | 1人あたりの月額単価 | チーム人数と期間による月額 |
| 完成責任 | 開発会社が負う | 負わない（善管注意義務） | 負わない（善管注意義務） |
| 仕様変更 | 契約変更と追加費用が必要 | 稼働の範囲内なら柔軟 | 期間内なら優先順位の入れ替えで対応 |
| 作業の指示 | 開発会社が管理 | 開発会社側の責任者を通す | 開発会社側のリーダーを通す |
| 発注側の負担 | 要件を最初に固める負担が大きい | 作業の割り当てを考える負担がある | 優先順位の判断を継続的に担う |
準委任契約の受注者は、民法第644条により「善良な管理者の注意をもって」事務を処理する義務を負います。これは専門家として通常求められる水準の注意を払って作業する義務であり、完成を保証するものではありません。そのため、ラボ型やSESで「思ったものができなかった」場合、請負のように完成していないことを理由に報酬を払わないという主張はしにくくなります。
一方、2020年4月施行の改正民法では、準委任でも「成果に対して報酬を支払う」形（民法第648条の2）が明文化されました。ラボ型と称していても、契約書を読むと成果物の納品を報酬の条件にしている場合があります。名前ではなく、報酬の発生条件の条文を確認してください。
参考：民法の一部を改正する法律（債権法改正）について／法務省
ラボ型開発が向いている案件、向いていない案件
どの形態を選ぶかは、「作るものが最初にどこまで決まっているか」と「発注側に判断できる人がいるか」で大きく分かれます。代表的な判断基準を表にまとめます。
| 案件と体制の状況 | 向いている形態 | 理由 |
|---|---|---|
| 作るものと予算の上限が決まっていて、途中で大きく変わる見込みがない | 請負 | 完成責任と固定額で予算管理がしやすい |
| リリース後も改善を続ける前提で、優先順位が月ごとに変わる | ラボ型開発 | 契約変更なしに作る順番を入れ替えられる |
| 新規事業や検証段階で、何を作るべきか自体を試しながら決めたい | ラボ型開発（短期から） | 作っては見直す反復に費用の仕組みが合う |
| 自社に開発リーダーがいて、特定の技術の人手だけが足りない | SES、または開発会社側の責任者を置いたラボ型 | 既存チームの戦力を補う形になる |
| 自社のエンジニアが外部の人に直接作業を割り振りたい | 労働者派遣契約を検討 | 準委任のまま直接指示すると偽装請負になる |
ラボ型開発が向かないのは、発注側に「何を優先するか」を決める人がいない場合です。ラボ型はチームの稼働に費用を払うため、判断が止まるとチームが待機し、その間も費用が発生します。決裁者が忙しくて週に一度も相談できない、社内で要望がまとまらないといった状況では、請負で範囲を区切った方が無駄が出にくくなります。
反対に、請負が向かないのは、要件を最初に固めきれない案件です。無理に固めて請負で発注すると、開発中に出てきた変更のたびに追加見積もりが必要になり、結果として総額も期間も膨らみがちです。この場合は、要件定義の部分だけを準委任で依頼し、固まった範囲から請負に切り替えるという組み合わせも選べます。
費用の比較では、ラボ型は月額×期間、請負は固定額という違いがあるため、単純な総額の比較だけで判断しないことが大切です。請負の見積もりには、仕様変更や想定外の作業に備えたリスク分が含まれていることが多く、ラボ型の月額にはそれが含まれない代わりに、期間が延びればその分だけ費用が増えます。どちらが安いかは、仕様がどれだけ変わるかによって変わります。
もう一つ考えておきたいのが、チームが業務を理解するまでの立ち上がり期間です。ラボ型開発では、最初の数週間は業務知識や既存システムの把握に時間を使うことが多く、その間の成果は小さく見えます。数か月で終わる単発の案件より、半年以上の継続を見込める案件の方が、この立ち上がりの費用を回収しやすくなります。期間が短く範囲がはっきりしている案件なら、請負の方が合理的な場合が多いでしょう。
指揮命令の線引きと偽装請負のリスク
ラボ型開発やSESで発注側が最も注意すべきなのが、指揮命令の線引きです。厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）では、受注者が自社の労働者に対する業務の遂行方法や労働時間の管理を自ら行い、業務を発注者から独立して処理していることが、適正な請負等の条件とされています。
厚生労働省の疑義応答集（第3集）は、この考え方が準委任契約にも同じく当てはまると明記しています。契約書が準委任であっても、実態として発注者が受注者側のエンジニアに直接指揮命令していれば、契約の形式を問わず労働者派遣とみなされ、いわゆる偽装請負として労働者派遣法違反になります。
同じ疑義応答集は、アジャイル型開発について、発注者側と受注者側の開発関係者が対等な関係で協働し、受注者側の開発担当者が自律的に判断して開発している場合は、密に情報共有や技術的な助言・提案をしていても偽装請負とは判断されない、という考え方も示しています。問題になるのは、発注者側が受注者側の担当者に直接、作業の進め方や労働時間について指示する場合です。
| 発注側の行動 | 扱いの目安 |
|---|---|
| 作りたい機能と優先順位を決め、チームに説明する | 発注者の役割として問題になりにくい |
| 仕様の背景や業務の事情を開発担当者に直接説明する | 対等な協働の範囲なら問題になりにくい |
| 受注者側の担当者に「今日はこの作業を先にやって」と割り振る | 業務の遂行方法の指示にあたるおそれがある |
| 受注者側の担当者に残業や休日出勤を求める | 労働時間の指示にあたるおそれがある |
| 受注者側の担当者の人事評価や配置換えを指示する | 指揮命令とみなされやすい |
実務上の対策は、役割と連絡経路を最初に決めておくことです。疑義応答集でも、双方の役割や権限、チーム内の進め方をあらかじめ明確にして合意しておくことが重要だとされています。発注側は「何をいつまでに」を決め、作業の割り振りや進め方の調整は開発会社側のリーダーを通す、という線を契約前の打ち合わせで確認しておけば、日々の運用で迷うことが減ります。
もし「自社の担当者が外部のエンジニアに直接細かく指示を出したい」のであれば、準委任ではなく労働者派遣契約を結べる事業者に依頼するのが筋です。どちらの関わり方をしたいのかを先に決めることが、契約形態を選ぶ出発点になります。
参考：労働者派遣事業と請負により行われる事業との区分に関する基準（昭和61年労働省告示第37号）／厚生労働省
契約前に確認すること
ラボ型開発を選ぶ場合、契約前に次の項目を開発会社に確認しておくと、後からの食い違いを防げます。請負やSESを選ぶ場合も、多くの項目は共通です。
- 報酬の発生条件が稼働に対してなのか、成果物の納品に対してなのか
- 月額に含まれる人数、役割、想定稼働時間と、それを超えた場合の扱い
- チームのリーダーやプロジェクトマネージャーを開発会社側に置くかどうか
- メンバーが交代する場合の事前連絡と引き継ぎの方法
- 最低契約期間と、中途解約の申し入れ期限
- 作業の進捗と成果をどの頻度で、どの形式で報告してもらえるか
- ソースコードや設計資料の著作権の帰属と、引き渡しの時期
- 再委託をする場合の事前承諾の要否
このうち見落とされやすいのが、報告の形式と成果の見える化です。ラボ型は完成責任を負わない契約なので、発注側が「この期間に何が進んだか」を把握できないと、費用に見合う成果が出ているかを判断できません。チケット管理ツールでの作業状況の共有や、2週間程度ごとの成果のデモなど、進み具合を確認できる仕組みを契約前に決めておきましょう。
中途解約についても確認が必要です。準委任契約は民法第651条で各当事者がいつでも解除できるとされていますが、相手に不利な時期の解除などでは損害賠償が必要になる場合があります。実務では契約書で「1か月前までに申し入れ」のように解約の手続きを定めることが多いため、その期間を確認してください。
最初から長期間の契約を結ぶのが不安な場合は、1〜3か月程度の短い期間で始め、チームとの相性や進め方を確認してから延長する方法もあります。最低契約期間を設けている開発会社もあるため、試験期間が取れるかどうかも合わせて相談するとよいでしょう。
まとめ
ラボ型開発・請負・SESの違いは、何に対して費用を払うのか、誰が作業の進め方を決めるのかにあります。請負は完成した成果物に対して、SESはエンジニア個人の稼働に対して、ラボ型開発は専属チームの一定期間の稼働に対して費用を払う形です。
選び方の基準は、作るものが最初に決まっていて変わりにくいなら請負、改善を続ける前提で優先順位が変わるならラボ型、自社に開発リーダーがいて人手だけを補いたいならSESや責任者付きのラボ型、自社から直接作業を割り振りたいなら労働者派遣です。ラボ型を選ぶ場合は、発注側に優先順位を決める担当者を置けるかどうかが成否を分けます。
次に開発会社と話すときは、契約書の報酬の発生条件、作業指示の経路、進捗報告の形式、中途解約の手続きの四点をまず確認してください。この四点が自社の想定と合っていれば、どの形態を選んでも大きな食い違いは起きにくくなります。