ラボ型開発契約 とは、一定期間、専属の開発チームを確保し、継続的に開発を進めるための契約です。オフショア開発の契約形態として広く使われていますが、「請負契約と何が違うのか」「契約書では何を確認すればよいのか」「ラボ型開発は失敗しやすいと聞くが本当か」といった疑問を持つ方も多いのではないでしょうか。
先に結論をお伝えすると、ラボ型開発契約は、継続的な開発や、途中で要件が変わりやすい開発 に向いています。ただし、契約の名称だけで責任の範囲が決まるわけではありません。成果を左右するのは、契約条項の内容 と、発注側・開発会社側の双方による運用 です。
本記事では、ラボ型開発契約の基本的な考え方から、請負契約との違い、向いているケース、よくある失敗と回避策、契約前に確認しておきたい条項までを順に解説します。
本記事で分かること
- 「ラボ型開発」と「ラボ型開発契約」、契約形態の関係
- ラボ型開発契約と請負契約の違い
- ラボ型開発のメリット・デメリットと、向いているケース
- よくある失敗パターンと、その回避策
- 契約前に確認・協議しておきたい契約条項
※本記事は一般的な情報の提供を目的としており、法的助言ではありません。個別の契約については、専門家にご確認ください。
ラボ型開発契約とは？
「ラボ型開発」と「ラボ型開発契約」の関係
ラボ型開発とラボ型開発契約は、似た言葉ですが意味が異なります。
- ラボ型開発：一定期間、専属の開発チームを確保し、継続的に開発を進める開発モデルのことです。「ラボ契約」「オフショア開発センター（ODC）」「専属チーム型開発」などと呼ばれることもあります。
- ラボ型開発契約：その開発体制や業務の進め方（チームの人数、期間、役割分担、報酬の決め方など）を定める 契約 のことです。
契約形態は「名称」ではなく「契約内容」で決まる
「ラボ型開発契約」という名称の契約類型は、民法には定められていません。実務では、準委任契約として締結されるケースが一般的です。
ただし、ラボ型開発契約がすべて同じ法的性質を持つわけではありません。どのような義務や責任を負うかは、契約書の条項によって決まります。さらに、契約書の内容だけでなく、実際にどのように業務が進められているかも問題になることがあります。
ラボ型開発を理解するうえでは、次の3つを分けて考えることが大切です。
準委任契約における報酬の考え方
準委任契約とは、法律行為ではない事務（システム開発などの業務）を委託する契約で、民法の委任に関する規定が準用されます（民法656条）。受任者（開発会社）は、委任の本旨に従い、善良な管理者の注意（善管注意義務） をもって業務を処理する義務を負います（民法644条）。
報酬の定め方については、2020年4月に施行された改正民法で、成果に対して報酬を支払う場合の規定（民法648条の2）が設けられました。実務では、報酬の考え方を次のように区別して説明することがあります。
- 履行割合型：業務の履行（作業時間や期間など）に応じて報酬を支払う考え方です。人数と期間をもとに月額費用を支払うラボ型開発契約は、一般にこちらに近い形です。
- 成果完成型：業務の履行によって得られる成果に対して報酬を支払う考え方です。
これはあくまで報酬の定め方に着目した説明であり、すべての契約がどちらかにきれいに分類されるわけではありません。成果に対して報酬を支払う定めがあるからといって、それだけで請負契約と同じ扱いになるわけでもありません。実際の義務や責任は、契約書の内容によって確認する必要があります。
ラボ型開発が注目される背景
ラボ型開発が選ばれる背景には、国内のIT人材不足があります。経済産業省の「IT人材需給に関する調査」（2019年）では、2030年にIT人材が最大で約79万人不足する可能性があると試算されています。
また、SaaSや自社サービスの開発、DX、AI活用のように、リリース後も改善を続ける開発が増えています。要件を最初にすべて確定させることが難しい開発では、チームを継続的に確保できるラボ型開発が選択肢になります。
ラボ型開発契約の仕組み
契約形態と契約期間
準委任契約として締結される一般的なラボ型開発契約では、報酬はチームの人数と期間をもとに算定されます。
最低契約期間や更新条件は、開発会社や契約内容によって異なります。チームの立ち上げに必要な期間も考慮し、自社の開発計画に合った条件かどうかを確認しておきましょう。
基本契約と個別契約
ラボ型開発契約では、次のように2段階で契約を結ぶ構成がよく使われます。
| 契約 | 主に定める内容 |
|---|---|
| 基本契約 | 取引全体に共通する条件（秘密保持、知的財産権、責任範囲、解約、支払条件など） |
| 個別契約（発注書・注文書など） | 期間ごとの体制（人数、役割、期間、報酬額など） |
この構成にしておくと、チームの人数や構成を変更する際に、基本契約を結び直すことなく、個別契約の変更で対応できます。
チーム体制と役割
ラボ型開発では、発注側と開発会社側の役割分担を明確にしておくことが重要です。一般的な体制の例は次のとおりです。
| 役割 | 主な担当 | 所属 |
|---|---|---|
| プロダクトオーナー（PO） | 開発の目的と優先順位の決定、成果の確認 | 発注側 |
| プロジェクトマネージャー（PM） | チームの進行管理、課題管理、報告 | 開発会社側 |
| ブリッジSE（BrSE） | 要件の理解と伝達、日本語でのコミュニケーション | 開発会社側 |
| エンジニア | 設計、実装 | 開発会社側 |
| QA | テスト、品質の確認 | 開発会社側 |
体制は案件の規模や内容によって異なります。小規模なチームでは、PMとブリッジSEを1名が兼任する場合もあります。
費用の考え方
ラボ型開発契約の月額費用は、おおむね次の考え方で算定されます。
月額費用 ≒ Σ（職種別の人月単価 × 人数）＋ 付帯費用
国別・職種別の人月単価や、チーム構成別の試算例、見積もりを比較する際のポイントについては、ラボ型開発の費用相場【2026年版】で詳しく解説しています。
契約から運用までの流れ
- ヒアリング：開発の目的、範囲、技術、予算、開始時期を共有する
- チーム提案・見積もり：開発会社がチーム構成と条件を提案する
- 契約：基本契約・個別契約の条項を合意する
- 立ち上げ：開発環境、業務ルール、コミュニケーションの方法を整える
- 運用：スプリントなどの単位で開発を進め、定期的に振り返る
- 見直し：成果や計画に応じて、体制の増減や契約の更新を判断する
ラボ型開発契約と請負契約の違い
比較表
ラボ型開発契約（一般的な準委任契約の場合）と請負契約の主な違いは、次のとおりです。
| 観点 | ラボ型開発契約（一般的な準委任契約の場合） | 請負契約 |
|---|---|---|
| 契約の目的 | 一定の期間・体制で業務を遂行すること | 仕事（成果物）を完成させること（民法632条） |
| 報酬の決まり方 | 人数・期間などをもとに算定することが多い | 成果物の完成を目的とし、報酬は契約条件にもとづいて設定する |
| 仕様・範囲の変更 | チーム内の優先順位の入れ替えで対応しやすい | 範囲の変更は、変更手続きや追加見積もりで対応するのが一般的 |
| 管理の仕組み | 発注側が優先順位を決め、継続的に関与することが前提 | 合意した範囲・スケジュールに沿って、受注側が進行を管理する（発注側の関与の度合いは案件による） |
| 責任の考え方 | 契約内容、義務の種類、適用される法令にもとづいて判断する | 合意した仕事の完成義務と、成果物が契約内容に適合しない場合の責任（法令・契約条件による） |
| ノウハウの蓄積 | チームの継続性とナレッジ管理が保たれていれば、蓄積しやすい | 案件ごとに体制が変わる場合は、蓄積しにくいことがある |
| 向いている案件 | 継続的な開発、要件が変わりやすい案件 | 要件と範囲が明確な案件 |
※上記は、ラボ型開発契約が一般的な準委任契約として締結された場合の傾向です。ラボ型開発契約が常に準委任契約になるわけではなく、実際の義務や責任は、個々の契約条項と業務の進め方を踏まえて判断されます。
責任範囲の考え方
ラボ型開発契約と請負契約の違いは、「準委任は過程だけに責任を負い、請負はあらゆる結果を保証する」と説明されることがあります。しかし、実際にはそれほど単純ではありません。
- 準委任契約：受任者は善管注意義務を負います。具体的にどのような義務や責任を負うかは、契約で定めた業務の内容、義務の種類、適用される法令にもとづいて判断されます。
- 請負契約：受注者は、合意した仕事を完成させる義務を負います。成果物が契約内容に適合しない場合には、履行の追完（修補など）、報酬の減額、損害賠償、契約の解除といった責任が問題になることがあります。ただし、その範囲や期間は、法令の定めと契約条件によって異なります。
どちらの契約でも、業務の範囲や責任の内容を契約書で具体的に定めておくことが、トラブルを防ぐうえで重要です。
契約形態は「価格」だけで選ばない
ラボ型開発契約と請負契約のどちらが適しているかは、価格だけでは判断できません。次のような観点を合わせて検討しましょう。
- 要件の安定性：要件や範囲がどの程度確定しているか
- 管理の方法：発注側が優先順位を決め、継続的に関与できるか
- 責任の分担：成果物の完成責任を開発会社に求めたいのか、体制の確保を重視するのか
- 期間：単発の開発か、継続的な開発か
なお、要件が固まった単発の開発では請負契約、要件が変わりやすい継続的な開発ではラボ型開発契約というように、開発の段階によって使い分ける企業もあります。
SES・自社採用との違い
ラボ型開発以外の選択肢との違いを、簡単に整理すると次のとおりです。
| 方式 | 体制の単位 | 主な特徴 |
|---|---|---|
| ラボ型開発 | チーム単位 | 開発会社がチームを編成・管理し、継続的に開発する |
| SES | 個人単位が多い | 特定のスキルを持つ人材を、一定期間確保する |
| 自社採用 | 社員 | 社内にノウハウが残りやすいが、採用と育成に時間がかかる |
指揮命令に関する注意点
準委任契約や請負契約で業務を委託する場合、発注側が開発会社のメンバーに対して業務の遂行方法を具体的に指示したり、勤務時間や人員配置などを管理したりしていると、実態として労働者派遣に当たる、いわゆる「偽装請負」と判断されるおそれがあります。
偽装請負に当たるかどうかは、契約の名称ではなく、実際の業務の進め方を踏まえて判断されます。そのため、契約を準委任契約としているだけで、リスクがなくなるわけではありません。また、「ブリッジSEやPMを通して要望を伝えていれば問題ない」と一概に言えるものでもありません。
一方で、アジャイル型開発のように、発注側と開発チームが日常的に情報を共有しながら進める開発もあります。発注側と開発チームが直接やり取りすること自体が、ただちに問題になるわけではありません。ポイントは、業務の遂行方法の指示や労働時間などの管理を、実態として開発会社側が自ら行っているかどうかです。
判断の基準としては、厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）があり、アジャイル型開発については、同基準に関する疑義応答集でも考え方が示されています。具体的な運用方法については、契約の締結前に専門家に確認することをおすすめします。
ラボ型開発のメリット・デメリット
メリット
- 市場の反応に合わせて開発内容を見直せる：リリース後の利用状況や顧客の声を見ながら、次に開発する機能を入れ替えられるため、計画どおりに作ったが使われない、という事態を減らしやすくなります。
- 立ち上がった後の開発スピードが上がりやすい：同じメンバーが継続して担当すれば、業務やシステムへの理解が深まり、説明や確認にかかる時間が減っていきます。
- 開発体制を早く整えやすい：自社で採用する場合に比べて、短期間でチームを立ち上げやすく、規模の調整もしやすい傾向があります。
- 案件ごとの見積もり・契約の手間を減らせる：契約で定めた体制と業務範囲の中であれば、機能を追加するたびに見積もりや契約を行う必要は通常ありません。ただし、契約期間やチーム構成、業務範囲などの変更には、別途合意や契約変更が必要になる場合があります。
- 条件によってはコストを抑えられる：開発拠点の国や体制によっては、国内で採用する場合より費用を抑えられることがあります。
デメリットと対策
| デメリット | 対策 |
|---|---|
| 発注側にPOやディレクションの工数が必要 | 社内で優先順位を決める担当者と、その工数をあらかじめ確保する |
| 作業量が少ない月も費用が発生する | 先々のバックログを準備し、チームの稼働率を保つ |
| 立ち上げ期は生産性が安定しにくい | 初期の数か月は立ち上げ期間と考えて計画し、少人数から始める |
| 成果物の完成に関する責任の考え方が請負契約と異なる | 品質基準や受け入れ条件を合意し、契約書で責任範囲を確認する |
| 言語・文化・時差によるコミュニケーションコスト | ブリッジSEの役割を明確にし、定例会議や文書でのやり取りのルールを決める |
ラボ型開発が向いているケース・向いていないケース
判断の目安となる4つの条件
ラボ型開発契約が自社に合うかどうかは、次の4つの条件を目安に検討すると判断しやすくなります。点数で判断するものではなく、どの条件が満たされていないかを把握するためのものです。
- 継続的な開発計画があるか：数か月以上にわたって開発を続ける予定があるか
- 要件が途中で変わる可能性があるか：市場や利用者の反応を見ながら、仕様を見直していく開発か
- 社内に優先順位を決め、成果を確認する担当者を配置できるか：POの役割を担える人がいるか
- 一定期間チームを維持する予算を確保できるか：月額の固定費を一定期間負担できるか
向いているケース・向いていないケース
| 向いているケース | 向いていないケース |
|---|---|
| 自社サービスやSaaSの継続的な開発・改善 | 要件と範囲が確定した単発の開発 |
| アジャイル型で開発を進めたい | ごく短期間で終わる開発 |
| MVPのリリース後に機能を追加していく | 社内に開発の優先順位を決める担当者がいない |
| 社内のエンジニア不足を中長期的に補いたい | 予算が固定されており、期間に応じた費用の変動を許容できない |
契約形態を組み合わせるという選択肢
ラボ型開発契約と請負契約は、どちらか一方を選ぶものとは限りません。例えば、要件が明確な初期開発は請負契約で進め、リリース後の運用・改善はラボ型開発契約に切り替える方法があります。反対に、少人数のラボ型チームで検証（PoC）を行い、要件が固まった部分を請負契約で開発する方法もあります。
ラボ型開発でよくある失敗と回避策
ラボ型開発の失敗は、開発会社の技術力だけでなく、発注側の準備や運用の仕方から生まれることも少なくありません。よくある失敗パターンを整理すると、次のとおりです。
| 失敗パターン | 主な原因 | 早期のサイン | 回避策 |
|---|---|---|---|
| 丸投げによる認識のずれ | POが不在、ゴールが不明確 | 手戻りが増える | POの任命、受け入れ基準の明確化 |
| バックログ不足による稼働率の低下 | 開発計画の不足 | 作業待ちが発生する | 先々のバックログの準備 |
| 品質基準のあいまいさによる手戻り | 完了の定義やテスト範囲が未合意 | 同じ指摘が繰り返される | 品質基準の合意 |
| コミュニケーションの齟齬 | ブリッジSEの役割が不明確 | 認識違いが続く | 役割の明文化、定例会議 |
| メンバー交代によるノウハウの喪失 | 特定の人への依存 | キーマンに作業が集中する | 交代ルールの合意、ドキュメント化 |
| 想定外の費用の増加 | 付帯費用の見落とし | 見積もり外の請求 | 見積もりの前提をそろえて比較 |
| 急な増員による管理の混乱 | 一度に体制を拡大 | 進捗が見えにくくなる | 少人数で始めて段階的に拡大 |
ここでは、特に発注側の運用と関係が深い3つの失敗について、詳しく解説します。
失敗1：丸投げによる認識のずれ
「専属チームがあるのだから任せておけばよい」と考え、発注側が開発の目的や優先順位を十分に伝えないまま進めると、期待と異なるものが出来上がることがあります。ラボ型開発契約では、何をどの順番で開発するかを決めるのは、基本的に発注側です。
- 早期のサイン：チームからの質問への回答が遅れる、レビューのたびに「思っていたものと違う」という手戻りが発生する
- 回避策：
- 社内でPOを任命し、判断に必要な時間を確保する
- 機能ごとに「何ができれば完了か」という受け入れ基準を文書で示す
- 開発の目的や背景（なぜこの機能が必要か）もチームと共有する
失敗2：バックログ不足による稼働率の低下
ラボ型開発契約では、チームが作業していない時間にも費用が発生します。次に取り組む作業が決まっていないと、チームに待ち時間が生まれ、費用に見合った成果が得られなくなります。
- 早期のサイン：スプリントの途中で作業がなくなるメンバーがいる、仕様の確定待ちのタスクが増える
- 回避策：
- 少なくとも次の1〜2スプリント分のバックログを、優先順位をつけて準備しておく
- 仕様が未確定の項目は、確定までの期限と担当者を決めておく
- 作業量が中長期的に減る見込みがあれば、早めに体制の見直しを相談する
失敗3：品質基準があいまいなことによる手戻り
「品質」の基準を合意しないまま開発を始めると、発注側と開発会社側で「完了」の認識が食い違い、修正の繰り返しにつながります。
- 早期のサイン：レビューで同じ種類の指摘が繰り返される、リリース後の不具合が続く
- 回避策：
- 完了の定義（Definition of Done）、コーディング規約、テストの範囲を最初に合意する
- コードレビューやQAの体制を、開発会社に事前に確認する
- 合意した基準は、振り返りのたびに見直す
失敗を防ぐための運用ルール
- 定例の報告と振り返り：週次の報告や、スプリントごとの振り返りを行い、課題を早めに共有します。
- 目的に合わせたKPIの設定：プロジェクトの目的に応じて、リードタイム、リリース後の不具合の割合、スプリント目標の達成率などから指標を選びます。
- 指標の使い方に注意する：ベロシティ（チームが一定期間に完了した作業量）は、同じチームの推移を把握するための指標です。見積もりの基準はチームごとに異なるため、異なるチーム同士の生産性を比較する目的には適していません。
ラボ型開発契約で確認すべき契約条項
ラボ型開発契約で定めるべき条項や、その内容は取引ごとに異なります。以下は、すべての契約に共通する必須の条項の一覧ではなく、契約前に確認・協議しておきたい主なポイントです。「運用」「費用・責任」「契約終了時」の3つに分けて整理します。
① 運用に関する条項
| 条項 | 確認・協議しておきたいポイント |
|---|---|
| 業務の範囲・役割 | 委託する業務の範囲、PM・ブリッジSEの役割、発注側が担う役割 |
| 契約期間・更新 | 最低契約期間、自動更新の有無、更新を判断する時期 |
| 体制・人数の変更 | 増員・減員を申し出る期限、変更が反映される時期 |
| メンバーの交代 | 交代を申し出る条件、引き継ぎの期間と費用の負担 |
| 稼働時間・精算 | 基準となる稼働時間、時間外の作業を承認する手続き、稼働時間が上下した場合の扱い |
稼働時間の扱いは、契約によって大きく異なります。基準時間を超えた場合・下回った場合に費用を精算するのか、一定の範囲内であれば精算しないのかを、事前に合意しておきましょう。
② 費用・責任に関する条項
| 条項 | 確認・協議しておきたいポイント |
|---|---|
| 報酬・支払い | 報酬の算定方法、契約通貨と為替の扱い、締め日・支払日 |
| 知的財産権 | 成果物の権利の帰属と移転の時期、開発会社の既存資産の扱い、第三者のライブラリ・OSSの扱い |
| 責任範囲・損害賠償 | 義務の範囲、損害賠償の上限や対象 |
| 秘密保持・情報セキュリティ | 秘密情報の範囲、アクセス管理、データの取り扱い |
知的財産権 については、次の3つを分けて確認することが大切です。
- 開発した成果物：ソースコードやドキュメントの著作権が、いつ、どのような条件で発注側に移転するか。著作権を譲渡する契約で、翻案権など著作権法27条・28条に規定する権利が譲渡の目的として特に記載（特掲）されていない場合、これらの権利は譲渡した側に留保されたものと推定されます（著作権法61条2項）。また、著作者人格権は著作者の一身に専属し、譲渡できないため（同法59条）、実務では著作者人格権を行使しない旨を定めることがあります。
- 開発会社の既存資産：開発会社がもともと保有しているライブラリやツールを使う場合、その権利は開発会社に残し、発注側には利用を許諾する形が一般的です。
- 第三者のライブラリ・OSS：オープンソースソフトウェアは、それぞれのライセンス条件に従う必要があります。使用するOSSとライセンスの管理方法を確認しておきましょう。
責任範囲・損害賠償 については、「準委任契約だから責任は軽い」と一律に考えることはできません。義務の範囲や賠償の上限は契約ごとに異なるため、条項の内容を具体的に確認しましょう。
③ 契約終了時の条項
| 条項 | 確認・協議しておきたいポイント |
|---|---|
| 解約 | 解約の予告期間、中途解約の条件 |
| 引き継ぎ | ソースコード・ドキュメントの引き渡し、移行支援の範囲 |
| アクセス・データ | アクセス権の回収、運用に必要な情報の引き継ぎ、顧客データの返却・削除 |
民法には、委任は各当事者がいつでも解除できるという規定があり（民法651条1項）、準委任契約にも準用されます。ただし、これは「どの契約でも条件なく自由に解約できる」という意味ではありません。民法上も、相手方に不利な時期に解除した場合などには、やむを得ない事由がある場合を除き、損害賠償が必要になることがあります（同条2項）。
また、実務では、契約書で解約の予告期間や中途解約時の精算方法などを定めることが一般的です。こうした特約がどのように扱われるかは、契約の内容や個別の事情によって異なります。途中解約の条件は、契約前に確認しておきましょう。
また、契約終了時には、ソースコードやドキュメントの引き渡しだけでなく、開発環境や本番環境へのアクセス権の回収、運用に必要な情報の引き継ぎ、顧客データの返却・削除までを確認しておくと安心です。
指揮命令に関する取り決め
前述のとおり、偽装請負に当たるかどうかは、実際の業務の進め方によって判断されます。契約書には、発注側からの要望をどの窓口を通じて伝えるか、開発会社側で誰がメンバーの管理を行うかなど、役割分担を明記しておきましょう。そのうえで、契約内容と実際の運用が一致しているかを定期的に確認することが大切です。
本記事は法的助言ではありません。契約の締結にあたっては、専門家にご確認ください。
契約前の準備とラボ型開発会社の選び方
契約前の準備チェックリスト
失敗パターンと契約条項のポイントを踏まえ、契約前に次の項目を確認しておきましょう。
- ラボ型開発で達成したい目的と、成果を確認する指標を決めた
- POと、開発会社とのやり取りの窓口を決め、必要な工数を確保した
- 最初の1〜2スプリント分のバックログを用意した
- 完了の定義や品質基準について、開発会社と協議する準備ができた
- 少人数から始め、どの時点で体制を見直すかを決めた
- 「運用」「費用・責任」「契約終了時」の契約条項を確認した
開発会社を比較する観点
ラボ型開発は長期的な取り組みになるため、開発会社の説明を聞くだけでなく、裏付けとなる材料を確認することが大切です。
| 評価項目 | 確認したい質問 | 判断材料 |
|---|---|---|
| 開発実績 | 類似する業界・規模の開発実績はあるか | 類似案件の内容、担当した範囲 |
| コミュニケーション | 日本語で要件や課題を共有できるか | ブリッジSEの経験、報告の仕組み |
| 品質管理 | コードレビューやテストをどのように実施しているか | QAのプロセス、品質基準 |
| セキュリティ | ソースコードや顧客データをどのように保護しているか | アクセス管理やデータの取り扱いの手順、インシデント発生時の対応フロー、取得している認証とその適用範囲 |
| チームの継続性 | メンバーが交代する際、どのように引き継ぐか | 交代のルール、ドキュメント化の方法 |
| 契約・費用 | 増減員や解約の条件は明確か | 契約書のひな形、見積もりの条件 |
セキュリティ関連の認証は判断材料の一つですが、認証を取得していることだけで、自社の案件に必要な対策がすべて整っているとは限りません。認証の対象となる組織や業務の範囲に加え、実際のアクセス管理やデータの取り扱いの手順も確認しましょう。
また、「高品質」「柔軟に対応」といった説明だけでなく、それを実現する仕組みやプロセスを具体的に説明してもらうことが大切です。
よくある質問
Q1. ラボ型開発契約と準委任契約は同じですか？
同じではありません。ラボ型開発契約は、専属チームで継続的に開発するという開発モデルを実現するための契約を指す呼び方です。実務では準委任契約として締結されることが一般的ですが、具体的な義務や責任は契約書の内容によって決まります。
Q2. ラボ型開発契約と請負契約の違いは何ですか？
最も大きな違いは契約の目的です。請負契約は仕事の完成を目的とするのに対し、ラボ型開発契約（一般的な準委任契約の場合）は、一定の期間・体制で業務を遂行することを目的とします。そのため、ラボ型開発契約は仕様の変更に対応しやすい一方、発注側が優先順位を決めるなど、継続的に関与することが前提になります。
Q3. ラボ型開発の費用はどのように決まりますか？
一般的には、職種ごとの人月単価にチームの人数を掛けた金額に、付帯費用を加えて算定されます。単価は開発拠点の国や職種、スキルによって異なります。詳しくはラボ型開発の費用相場をご覧ください。
Q4. ラボ型開発契約は最低何か月から利用できますか？
開発会社や契約内容によって異なります。チームが業務を理解するまでには一定の期間がかかるため、最低契約期間を設けている場合は、その期間が自社の開発計画に合っているかを確認しましょう。
Q5. ラボ型開発契約は途中で解約できますか？
民法上は委任・準委任の解除に関する規定がありますが、実際の解約の条件や、解約時の精算・損害賠償の扱いは、契約内容や個別の事情によって異なります。契約書では、解約の予告期間（例えば「○か月前までに通知」など）を定めることが一般的です。予告期間や、解約時の引き継ぎの範囲は、契約前に確認しておきましょう。
Q6. ラボ型開発で開発したソースコードの権利はどうなりますか？
契約書の定めによります。成果物の著作権を発注側に移転する契約が一般的ですが、移転の時期（報酬の支払い時など）や、開発会社の既存資産、OSSの扱いは契約ごとに異なります。権利の範囲と移転の条件を、契約前に確認しておきましょう。
まとめ
ラボ型開発契約は、専属チームを確保し、継続的に開発を進めたい企業に適した選択肢です。特に、要件や優先順位が変わりやすい自社サービスの開発・改善では、チームの知識を蓄積しながら柔軟に対応できるメリットがあります。
一方で、期待する成果を得るには、契約形態を選ぶだけでは十分ではありません。契約条項や責任範囲を明確にし、社内の担当者が開発の優先順位を管理するとともに、品質基準やコミュニケーションのルールを整えることが大切です。
自社の開発計画や要件の確定度、社内の管理体制を踏まえ、ラボ型開発契約と請負契約のどちらが適しているかを検討しましょう。開発の段階に応じて、両者を組み合わせる方法もあります。
「ラボ型開発と請負開発のどちらを選ぶべきか」「どのようなチーム体制が適しているか」とお悩みではありませんか。
レリパ（Relipa）では、お客様の開発目的や現在のフェーズ、ご予算を踏まえ、ラボ型開発・請負開発・両者を組み合わせた進め方をご提案します。東京とハノイの拠点を活かし、ブリッジSE・PM・開発チームが連携しながら、日本語でのコミュニケーションを通じて開発を支援します。
契約形態の選定からチーム体制、開発の進め方まで、自社に合った方法を検討したい方は、ぜひレリパ（Relipa）にご相談ください。
