オフショア開発を依頼する際に一般的な契約形態が2つあります。それが請負型とラボ型です。
この2つ、どちらが優れている・劣っているもしくは、発注元や開発会社にとって得する・損するというものでは無く、それぞれ特色があり、開発する内容と合致した契約形態が望ましいというものになります。
一方で近年では、多くの会社がラボ型契約（ラボ型開発）を選んでいます。それはなぜなのか？
今回は、オフショア開発を利用する際の契約形態である「請負型」と「ラボ型」の違いや、選び方について解説します。
1. 請負型開発（Contract-type Development）とは？
オフショア開発に限らず、日本国内でのソフトウェア開発においても過去から一般的に利用されている形態です。会社によっては、「受託開発」と呼んでいたりもします。
1-1. 請負型開発の流れ
発注者（開発を依頼する会社）が事前に提示した要件定義書や詳細仕様書に基づき、それを受ける＝受託側（開発会社）が、それを作る際の期間や費用の見積もりを提示します。
場合によっては、発注者側で要件定義書作成などができていない場合、受託側で「要件定義書を作る」という部分だけを見積もりし、その部分だけをまず契約して対応する場合もあります。
どちらが要件定義を行うにせよ、請負型で見積もりをする場合、要件が明確になっていないと見積もり自体がそもそもできなくなってしまいます。
また不明な点が多い場合、受託側では、その分のバッファー（変動リスク）を多めに積むことになり、結果、見積金額が大きくなってしまうので注意が必要です。
発注者は、このように作られた見積もり提案に納得できるのであれば、両社合意のうえで発注（契約）をします。
それは受託側から見た時に、そのシステムやソフトウェア（成果物）を期日までに完成させることを約束したことになります。
そして、この「成果物の納品」に対して報酬が支払われる契約形態が「請負型開発」です。
成果物が納品される際は、発注者側で検収（正しく作られているのかの確認）を行い、問題なければ「検収完了通知」を受託側へ提示し、それをもって納品完了となり受託側からの請求が行われます。
なお支払いタイミングは、着手前と納品完了後の2回に分けて行われることが多いものの、金額や期間、プロジェクトの内容によっては分割されて実施されたり、納品完了後だけのケースとなったりとまちまちです。
またもしその成果物に当初合意した仕様と異なる点、例えばバグや不具合などがあって後日発覚・判明した場合、契約内で合意した期間中に限り受託側は、無料で修正対応をすることになります。
日本の民法における「請負契約」の概念に相当する開発形態が請負型開発です。
1-2. 請負型開発の特徴
この形態の最大の特徴とは何でしょうか？
それは、受託側（開発会社）へ「仕事の完成義務」および「契約不適合責任（旧来の瑕疵担保責任に相当）」を課すことができる、この点にあります。
受託側へは、合意された納期までに、合意された機能要件および非機能要件を完全に満たすシステムを完成させる、全ての責任を負わせることができます。
そして万が一、納品されたシステムにバグや仕様との不一致（契約不適合）が発見された場合は、期間限定でありつつも無料で修正対応をさせる義務を負わせています。
これは、発注者側にとっての大きなメリットとなります。
一方で、受託側（開発会社）は、約束した通りの仕様で期日までに作って納品できればよく、仮に期日よりも早く作ることができたのであれば、エンジニアの稼働を他の作業に充てることで会社としての生産性（売上及び利益）を高めることができます。
よって開発工程におけるプロジェクトの進行管理、リソースの配分、技術的な課題解決の裁量と責任は、すべて受託側に委ねられる開発形態となります。
1-3. 請負型開発の問題点
こういった請負型開発ですが、問題点として考えられるポイントは、2つあります。
1つ目は、既に述べたように事前の要件定義や仕様策定が重要であるものの、ここがどこまで作り込まれているのかという点です。
どういう仕様で作るのかが明確になっていない場合、成果物自体がはっきりせず、いつまでも納品が終わらない、スケジュールが遅延するという事になります。またその後の不具合と見られる現象が発生した場合も、それは仕様なのかそれとも不具合なのかがはっきりしません。
最初に要件定義がきっちりされて仕様が詳細まで明確になっている、それを元に見積もりをして開発に取り掛かるというケースは、実際のところ限られます。発注者側でもそれができていないケースも多く、あとからここはこうだった、やはりこうして・・・と受託側が想定していなかった開発工数が発生することがあります。
そしてこういったプロジェクトでは、発注者と受託者側でその遅延の責任や、想定外にかかった費用負担について揉めることも多いです。
2つ目は、合意した仕様通りにつくることに起因する硬直性とスピード感です。
特に時間をかけて開発するような大きなプロジェクト、例えば1年間以上かけて請負型開発で作り上げるようなケースでは、顕在化しやすいポイントとなります。
最初の仕様策定時は、これがベストだと考えて合意し、その開発を開始しますが、出来上がるのは、だいぶ先、例えば1年後です。
この1年という期間、時間軸は、そのビジネス内容によって重みづけが異なるものの、ITビジネス、特に新しい技術を取り入れてサービスの提供をしていくものの場合、大きな市場環境の変化を受けることになります。
また作っている最中にテスト版にふれた発注者の社員からフィードバックがあって、こうしたい、こう変更したいという意見が出たとします。
しかし仕様を変更・追加したい場合、受託側（開発会社）は、再設計や手戻りの工数が発生するため、必ず再見積もりとスケジュールの引き直しを作り、両社でそれに合意し追加契約の手続きが必要となります。そしてこれには、時間がかかるため場合によってはその対応稼働によって本来の開発スケジュールへ影響が出てくる可能性もあります。
そしてこのような変更が1回だけでなく複数回発生することも考えられ、その場合は、毎回時間や発注者側も含めた対応稼働がかかることになります。
それゆえ請負型開発は「仕様の変更に柔軟に対応できない」「途中で仕様を変更するとスピードが遅くなる」と評価される事が多いです。
2. ラボ型開発（Lab-type Development）とは？
一方でラボ型開発（ラボラトリー型開発、または専属チームによる開発と呼ばれることもあり）は、開発エンジニア（開発リソース）の「稼働時間」を保証する形態です。
2-1. ラボ型開発の流れ
まず発注者は、開発したいソフトウェアやITサービスの内容、それをいつまでに利用できるようにしたいのかなどについて、開発会社に対して要望を伝えます。
開発会社は、それを受けてそれが実現できる開発チームを提案します。例えば、日本語ができる人材が1人、エンジニアが2人で計3人のチームを作り、〇ヶ月のスケジュールの中でいついつまでにどこまで作るのかといった工程の提示です。
この内容に発注者が合意した場合、契約を結び開発を進めていきますが、契約上保証されるのは、「開発エンジニアの稼働時間」です。なお派遣契約ではないため、開発チームに対する指揮命令は、開発会社が行います。そして契約上の成果物は、稼働時間を記した「稼働報告書」となります。
支払いタイミングは、毎月の開発役務の提供に対して請求され、毎月支払いとなるケースが多いです。
ソフトウェアが出来上がった際の検収や、バグなどが発覚した際の修正対応は、あくまでも開発エンジニアの稼働時間の中で実施されることになります。
ちなみにラボ型契約が終了した後に判明したバグなどについては、新たに開発会社と契約を結び、その分だけの修正依頼をすることになります。
日本の民法における「準委任契約」の「履行割合型」。成果物の完成ではなく、「費やした時間や工数（プロセス）」に対して報酬が支払われる契約形態の概念に相当するのがラボ型開発です。
1-2. ラボ型開発の特徴
この契約形態の特徴、それは請負型で問題となっている仕様変更に対する柔軟性です。
ラボ型開発において契約上の合意内容は、「開発チームの稼働時間」である為、その稼働時間が変わらない限り、開発する内容を柔軟に変更できます。
例えば当初、AとBという機能を作る予定で開発を開始した、しかし途中でBを後回しにして、AとCという機能を作ることにしたという場合、請負型であれば再見積もり&再契約となる可能性が高いものの、同じ作業時間内に収まるのであれば、ラボ型の場合、契約変更なしに対応できます。
そしてそれを何度か繰り返す場合であっても同様ですので、変更を頻繁に行う可能性のあるプロジェクトにおいては、請負型と比べて圧倒的なスピード感の違いを体感できます。
また請負型の場合、見積もり前に作るものをはっきりと提示する、仕様を明確にする必要がありますが、ラボ型の場合、仕様や要件が完全に決まっていない状態、あるいは抽象的なコンセプトの段階からでも開発プロジェクトをスタートさせることが可能となります。
なんとなくこんなイメージというのをまず形作るところから開始して、実際に手にふれてその感想を元に、次の開発の内容方向性を決めていくことができる。
そのため、開発開始にあたっても要件定義書などができてからでないと開始できない請負に比べて、スピードを早くできると言えるでしょう。
1-3. ラボ型開発の問題点
ではそんなラボ型開発の問題点は何かというと、契約上は完成責任が無く、稼働時間しか保証されないという事になります。
既に述べたように請負型開発の場合は、合意した内容（仕様）で期日までに完成させることの責任を開発会社に対して負わせているため、それができていない場合、あとから契約期間内（旧瑕疵担保期間）において無料で修正をさせることや、検収できるまで支払いを行わないこと、場合によっては損害賠償責任を追求することもできます。
しかしラボ型の場合、契約上合意しているのは「開発チームの作業時間」のみです。よって仮に開発チームが契約上の開発稼働をしたものの、ソフトウェアができなかった、バグや不具合が残っていたという場合であっても、開発会社側の役務は提供したことになりますので、発注者側はその対価を支払う義務があります。
もちろん開発会社には、専門家として期待される水準で誠実に業務を遂行する「善良なる管理者の注意義務（善管注意義務）」がありますので、開発稼働したものの善管注意義務さえも満たさない水準のソフトウェアであれば、クレームを入れることはできます。しかし請負型の「成果物の完成」というほど強い義務を負わせているわけではない点で注意が必要です。
3. オフショア開発でラボ型を選ぶケースが増えた理由とは？
請負型、ラボ型共にそれぞれ特徴があることをご理解いただけたと思いますが、オフショア開発でご依頼いただくことが多いのは、会社によっても異なるもののラボ型開発が多いという印象を持っています。実際、弊社VitalifyAsiaでいうと9割超（ほぼ100％に近いくらい）の開発が、ラボ型開発となります。
なぜそうなのかというとビジネス環境の変化があります。
かつては、パソコン上で動くソフトウェア（Windows上で動作するソフトウェア）開発や、顧客の施設やデータセンター内にサーバを物理的に置いて、そこで動作する基幹システムを開発するといったことがオフショア開発の主流であった時代もありました。
しかし現在ではクラウドサービス（AWS、Azure、GCP）上に構築し、ブラウザ上で動作するアプリケーションやスマホアプリ、特に近年では、様々な生成AIと組み合わせたサービス開発を求められることが多いです。
そしてこれらのサービスは、短期間でどんどん変わっていきます。
例えば各種生成AI、ChatGPTにせよGeminiにせよ、1年前と現在とでは、できることや性能が大きく変わっていることは皆様もご存じでしょう。この1年前の前提、その当時はそれが最適だとして設計され、1年間に多額の開発費をかけてようやく今になって公開された場合、その商品にどこまで市場競争力があるのかという点が問われるようになっています。
自社の考えた仕様が完璧と思われるものであったとしても、他社がもっと良いものを出してくることだって考えられるでしょう。
思いもしないほど急速にビジネス環境は変化し、それを事前に、そして正確に予測することは不可能ともいえる状況です。
そういう環境を変えられない以上、「短期間で素早く形作り、実際に触ってみて、その感想を元に素早く変更をしていく」ことが最適解となります。
そしてそれに適した契約形態が、開発チームの作業時間だけを約束する形態「ラボ型開発」となります。それゆえ近年では、ラボ型開発を選ぶ会社が多いと考えられます。
4. 請負型とラボ型それぞれに適した開発内容
上記で述べたようなビジネス環境の変化はあるものの、そのような環境下でも請負型、ラボ型、それぞれに優位性があると考えられる開発内容があります。
4-1. 請負型開発に向いている開発内容
技術面やビジネス面において不確実性が極めて低く、開発開始前の段階で最終的なゴール（完成形）が明確になっており、かつ仕様変更の可能性が乏しい開発プロジェクトであれば、請負型開発形態の方が向いていると考えられます。具体的には、
（1）既存の社内基幹システムの刷新（リプレイス）や、古い言語から新しい言語へのマイグレーション（移行）プロジェクトです。
こういったプロジェクトにおいて「現行システムと同じ仕様・同じ業務フローを新環境で再現できればよい」という事であれば、後からこういう機能をといった仕様の変動、ブレが置きづらくなりますし、ビジネス環境に合わせて途中から仕様を変えるといったことも発生しづらいと考えられます。
こういったウォーターフォール型の開発手法が適している領域では、受託側（開発会社）に完成責任を負わせる請負契約が、発注者側にとってはリスクを低減できると考えられます。
（2）キャンペーン用のランディングページ（LP）制作、単発の小規模な社内管理ツール開発、特定のAPI連携モジュールの開発などです。
開発期間が数日といった1ヶ月にも満たないものから、最大でも3ヶ月程度と短く、納品後の継続的な機能追加や頻繁なアップデートを前提としていない開発プロジェクトです。
（3）補助金関係の開発プロジェクト
日本では、新しいソフトウェアを作るにあたって政府や自治体など公共機関が開発費を補助する「補助金」制度が豊富です。
こういった「補助金」においては、開発契約を「請負型」に限定しているケースもあり、この場合は「請負型」で開発をしないと補助金の対象外となってしまいます。
4-2. ラボ型開発に向いている開発内容
何が市場で評価されるか分からないため、市場の反応を継続的に探りながら柔軟にプロダクトを成長させていくもの、いわゆる「アジャイル型と呼ばれるプロジェクト」などにおいては、ラボ型開発形態の方が向いていると考えられます。具体的には、
（1）新規事業、新規サービスの開発
こういった場合では最初の要件定義が市場のニーズと合致する保証はありません。要件定義した内容は、あくまでもこれならうまくいくだろうという想定でしかないためです。
よって仕様や要件が決まっていない状態から開発をスタートさせ、話し合いながらプロトタイプを作成し、実際にプロトタイプを使ってもらったユーザーからのフィードバックを得ては即座に仕様を変更・修正するというサイクルを高速で回していくようなプロジェクトです。
この様なピボット（方向転換）を前提とする開発においては、仕様変更にも柔軟に対応できるラボ型開発は不可欠な形態となります。
近年よく聞かれる、MVP（Minimum Viable Product：実用最小限の製品）開発から、その後のプロダクトマーケットフィット（PMF）を目指す成長フェーズなどでもラボ型は合致する開発形態となります。
（2）企業のR&D（研究開発）
すぐに市場に投入するかは分からないものの、アイデアをまずは形作ってみる。出来上がったものをいろいろ試してみて、その中から商品化できるものを探していく。こういった開発内容にもラボ型開発が向いています。
（3）AI開発やPoC
機械学習モデルの構築やディープラーニングを活用したサービス開発などです。
AI開発では、事前に「精度〇〇%のモデルを完成させる」といった約束をして開発をすることは困難であるため、PoC（概念実証）と呼ばれるAIモデルを作っては評価し、再学習やチューニングを繰り返していくことになります。
このような開発において、完成責任を負う請負契約は適していません。
5. 結論
以上で述べてきた様にオフショア開発における契約形態として、請負型、ラボ型、そのどちらかが優れている・劣っているというものでは無いことがご理解いただけたのではないでしょうか。
場合によっては、同じオフショア開発会社を使う場合においても、プロジェクトの内容に応じてあるものは請負型、あるものはラボ型で契約するという事もあります。
それぞれの特徴を踏まえたうえで開発するプロジェクトに応じて上手く使い分ける、これこそがオフショア開発で成功したと言われる会社が実践している体制の選び方となります。
