・この記事がお役に立つ人
・オフショア開発の「ラボ型開発」を検討している人
・オフショア開発で「ラボ型開発」を利用しているがうまく行ってない人
オフショア開発のひとつの開発形態である、「ラボ型開発」はお手軽に自社のチームを海外エンジニアで組成できるとあって、最近広まっている開発・契約形態です。
ただ、「ラボ型開発」にも当然いくつもの課題があり、契約形態も含めて注意する必要があります。具体的な課題と注意点を見ていきましょう。
オフショア開発における「ラボ型開発」のメリット、デメリット
それでは最初に、「ラボ型開発」がどのようなものなのかをきちんと確認しましょう。
オフショア開発における３つの開発形態（委託・ラボ型・子会社）
現在、オフショア開発においては大きく３つの開発形態があります。それぞれの特徴を見ていきましょう。
・業務委託開発（請負型）
システム開発を特定の開発会社に委託して開発してもらう形態。一般に業務委託契約と言われるもので、契約形態としては「請負契約」が主流です。
・ラボ型開発
顧客が求めるスキルを保有するエンジニアチームを一定期間専属で用意してもらうものです。人数が多ければ専用のプロジェクトルームを用意する場合もあります。一般に「ラボ型契約」と言われる契約を結びます。
契約自体は「準委任契約」となります。
・現地子会社による開発
海外に子会社を設立するのは大変ですが、一番効果のある開発形態です。
必要なエンジニアを自分の目で見て採用することができ、長期的な観点で育成することが可能です。
ただ、ある程度の規模がないと会社自体を維持するのが難しくなります。
※参考の図：オフショア開発パターン
以下に、３つの開発形態の比較表を添付します。
オフショア開発の詳細は以下の記事も参考にしてください。
利用者側からみた、ラボ型開発のメリット
・オフショア開発一般のメリットと同じ。
・人月単価が日本と比べた場合、非常に安いので全体としてコストを抑えることができます。ただ、オフショア開発特有の費用（ブリッジSEや翻訳者、出張費など）が別途発生するので考慮が必要です。
・請負契約と違って、最初に仕様をきちんと決めて合意する必要がありません。また、プロジェクトの途中で仕様の追加変更も自由です。
・中長期的に要員を固定したチームを確保できるため、①ノウハウが蓄積しやすい、②優秀なエンジニアを常に確保できる、といったメリットがあります。
・中長期に要員が固定化されることで、期間経過とともに開発スピードの向上が見込めます。
・ラボ型開発では、固定費である人件費を変動費にすることができることも大きなメリットです。
・エンジニアを自社採用した場合は、仕事の如何に関わらず人件費が発生します。でもラボ型の場合は、半年や1年といった一定期間の契約なのでプロジェクト単位で人員、人件費を変動費として調整でき、柔軟性があります。
利用者側からみた、ラボ型開発のデメリット
・ラボ型開発（ラボ契約）は、一定期間一定の人数を確保する契約形態になります。そのため、期間中はそのリソースを無駄にしないためにも、該当期間でこなせる一定量の仕事を確保する必要があります。
・ラボ型開発の契約期間中は自社専属チームとなるため、チーム内のコンセンサスをとり、業務になれるまでに時間がかかります。
・業務内容にもよりますが、最初から想定のパフォーマンスを望むのは難しいのが実情です。
・ラボ型契約は準委任契約となるため、受任者側に成果物の完成責任はありません。つまり、プロジェクトの責任は委任者側が負うということです。
・また、請負契約ではないため、瑕疵担保責任（契約不適合責任）もありません。よって、後日バグが発生しても無料で修正してもらうことはできません。
・ラボ型開発は結局のところ、場所と要員だけを提供するサービスです。
・そのため、良い開発場所・開発環境と高いスキル要員が提供されないと、結果として高い買い物になってしまします。
・コロナ禍を通して自宅開発が主流になっているので、提供されるエンジニアのスキル・レベルがより重要になっています。
・なお受任者の会社から自社チームに対する技術的なアドバイスやサポートが有料（別料金）の場合もあります。
ラボ型開発における契約上の留意点
準委任契約である
業務委託契約（請負契約）と違って、ラボ型開発は準委任契約となります。
請負契約とはいろいろ違いがあります。IT関連の請負契約と大きく違うところは以下の５点です。
・業務遂行が目的であって、業務自体を完成させて納品する義務はない。
・つまり、完成責任は委任者（顧客）になるということ。
２．瑕疵担保責任（契約不適合責任）がない
・受任者が業務遂行で作成した作成物において、欠陥や品質不良があった場合の責任は負わない。つまり、後日プログラムにバグが発生しても、無償での修正責任はない。
※民法改正により、「瑕疵担保責任」は「契約不適合責任」という名称に変更された。
３．契約相手の責任は「善管注意義務」のみ
・「一般的に要求されるレベルの注意をする」ことが求められる。ただし、「業務遂行の過程」に対しては責任が発生する。ラボ型開発の目的が特定のプログラム作成であれば、専門性を生かしてプログラムを作成することの義務は発生すうｒが、完成責任はないということ。
４．中途解約が可能
・法律的には中途解約が可能。ただ、通常のラボ型開発では契約期間を定めているので、中途解約はしないのが普通。
もちろん、契約書上に特定条件のもと中途解約する旨入れることは可能（例：要員のスキル・質が依頼条件と違う、など）。
５．再委託はできない
・受任者（受託企業）が下請け業者などの第三者に業務を委託することはできない（「請負」は可能）。つまり、提供されるエンジニアは全て受任企業社員でなければならない。
もちろん、委任者の承諾があれば再委託は可能。
エンジニアに対する指揮命令権は誰？
委任者側（発注側）が直接受任者側（オフショア企業）のエンジニアに対して仕事の指揮命令はできません。
指揮命令は、受任者側の責任者を通して行います。なぜなら、仕事の遂行は受任者側でコントロールされることになっているからです（法律でそうなっている）。
私は以前、某社の「ラボ型開発契約書」を見たことがありますが、その中で、
「委人側の人が直接オフショアのエンジニアを指揮する」旨の文言があり、ビックリしたことがあります。これはかなりグレーな文言だと思います。
プロジェクトがうまく行かないときの責任は誰が負う？
プロジェクトがうまく行かない場合は、もちろん委任者側（発注側）の責任です。
受任者側（オフショア企業）は、「善管注意義務」のみ履行すればOKです。つまり、「一般的に要求されるレベルの注意をする」ことができれば責任は問えません。
もともと完成責任がないので、プロジェクトに大きな問題が発生しても、オフショア会社の責任を問うことは難しいといえます。
よくある問題として「エンジニアのスキル・資質問題」があります。
例えば、Javaエンジニアを要望したのに、Javaが書けないエンジニアだった場合（実際にあった話）、さすがきこれは要員交代させます。
でもこれくらいがせいぜいです。エンジニアのスキルレベルを正確に契約書上に反映させることはなかなか困難です。エンジニアの質が良くないと文句を言っても、揉めてるうちに契約期間が終了した、なんてことは良くある話です。
こういうことからも「ラボ型開発」を選択するときは、参画予定のエンジニアの面談（インタビュー）は必須です。できればコーディング・テストとかできればもっと良いでしょう。
また、「ラボ型開発」を選択するときは契約書の文言には注意し、履行してもらうべきところはきちんと契約書上に載せるべきでしょう。
なぜ、「ラボ型開発」が選ばれるのか？
以上のように、一見委任者側から見ると不利な面も目につく「ラボ型開発」ですが、なぜ世の中で流行っているのでしょうか？
それは、ラボ型開発のメリットで見た通り、「安くてお手軽、簡単そう」だからです。まあ、これが大きな落とし穴になりかねないのですが。
金額の大きなプロジェクト案件（企業の基幹業務開発、等）では、委託側（発注側）がリスクを分散させることを主眼に置くため、「ラボ型開発」を選ぶという選択はあまりしません。基本は「請負開発」を選択します。
それでは、具体的に「ラボ型開発」を採用するパターンを見ていきましょう。
ベンチャーや新規サービスを立上げるパターン
―金もなく人もいない場合－
実績のないベンチャー企業や、既存企業でも新しいサービスを立ち上げたいときなど、開発要員がいない場合が多いものです。
このような場合、お金の安いオフショア開発会社に開発要員を準備してもらうことはよくあることです。
オフショア開発どころか、他社と協業してソフトウェア開発などやったことのないメンバーでプロジェクトを立ち上げる場合も多いため、失敗が多いパターンといえます。
当初契約の半年とか１年でプロジェクトが頓挫するというのはよく聞きく話です。ネット上で「オフショア開発なんかうまく行くことなんてない！」と豪語しているのはこのパターンではないでしょうか（実際のところ、オフショア開発の成功割合はまあまあ高いです）。
※私が以前在籍したオフショア会社では、私が関わった案件は全て成功して、きちんと利益も確保しています。もちろん途中でそこそこ問題は出ますが、致命的にならないようマネージするのがPMの仕事です。
既存サービスのメンテ中心（そのうちなくなる仕事）
－コスト削減中心の案件－
既存の古いシステムのメンテナンスをオフショアのラボ型開発で行う場合があります。
メンテナンス業務は請負契約にしにくい性格のものであり、仕様書も不十分な場合がほとんどなので、ラボ型に向くタイプとも言えます。（メンテナンス業務は最初に年度の工数を決め、メンテ案件に優先順位をつけて工数の範囲内で行うことが多い。つまり、契約時点では工数は決まっているが、案件が決まってない状態。）
また、自社の開発要員はできるだけ新規サービスの開発にシフトし、やがてリプレースされる既存システムはいつでも捨てられる、ということからもオフショアに向いていると言えます。
現在稼働しているという裏付けがあるので、契約自体は中期的に安定しており委任側、受任側ともメリットがあります。ただ、コスト的にはかなりギリギリまで絞られる傾向があります。仕事は安定しますが、高収益は望めないということです。要員のモチベーション維持も大変です。
研究開発型（仕様書なし・試行錯誤）
研究開発や各種リサーチでオフショア開発を使うことも多いパターンです。いわゆるPOC型案件なども多いです。
※POC: Proof Of Concept（概念実証のプロジェクト）
研究開発では、開発物自体に仕様書がなく試行錯誤になることが多いので、請負型を選択することができません。また、試行錯誤するのにオフショアであれば大きな手戻りが発生した場合でも安く済みます。
また、先端技術などは英語資料だけと言う場合も多いので、英語の得意なエンジニア（インド・フィリピン）であれば一石二鳥になるというものです。
オフショア企業には旨味のある「ラボ型開発」
今まで見てきた通り、ラボ型開発は委任者側（発注者）にも需要があるのは事実です。
でも、ぜひとも「ラボ型開発」をやりたいのは受任者側（オフショア会社側）なのです。
なぜそうなのか、具体的に見ていきましょう。
「ラボ型開発」は受任企業にとって割の良い仕事
「ラボ型開発」はオフショア企業にとっては、とても旨味のあるビジネスモデルです。
なぜなら、場所と人を用意するだけで、作業結果の責任は問われないからです。
長年「請負契約」の悪夢に苛まれてきた私などにとっては「天国のような契約形態」です。指揮命令まで顧客に任せることができれば、開発の結果など他人事で済ませることが可能です。
極端なことを言えば、人材の斡旋業に他なりません。自社にIT開発のスキルが全くなくてもこのビジネスモデルなら遂行することが可能なのです。
（実際はそこまで極端なオフショア会社はないと思いますが）
こんな会社に当たったら悲劇です。よく見極めましょう。
「ラボ型開発」受任企業側のメリット・デメリット
ラボ型開発のメリットと言った場合、一般的には委任側企業（お客様）のメリットだけが強調されますが、実は今見た通り受任側のメリットが大きい契約形態ともいえます。
具体的に、受任側のメリット・デメリットを整理してみましょう。
受任企業側からみた「ラボ型開発」のメリット
・完成責任がない
・瑕疵担保責任（契約不適合責任）がない
・契約上の善管注意義務だけ果たせばよい
・自社要員の稼働率が上がる
・会社としての要員計画が立てやすい
・タダで要員教育をしてもらえる（新規分野の場合）
・プロジェクトが順調なら契約の継続は容易
・固定客として営業がし易い（各種接待攻勢、など）
・案件開始時は、必要スキルに合わせて既存要員を当てはめ、不足すスキルはそのとき要員調達すれば済む
・長期契約の場合は委任側（顧客側）がスキル教育をすることが多い
受任企業側からみた「ラボ型開発」のデメリット
・どこのオフショア会社でもできるのでので競合が激しい
※必要なスキル要員はいつでも人材市場から調達可能なため
・差別化が難しく単価競争になりやすい
（収益の圧迫要因になる）
（※優秀なエンジニアはできるだけ、新規の案件獲得のために回したいのが本音）
・要員のローテーション交渉が厳しい
・要員が固定化するものの単価上げ交渉も厳しい
・エンジニアはプロジェクトへの固定化は嫌がる
・新しいスキル獲得機会が減る
・給与を上げることでの対応は一時しのぎ
「ラボ型開発」って結局何？（人集めだけ？）
「ラボ型開発」の場合、契約が取れてから人材市場で必要なスキル要員を都度調達すれば済む話です。
※オフショア国の人材流動化は高いのでこのようなことが可能となる
結局「ラボ型開発」では、最もオフショア企業に必要とされるスキルは「採用」と「要員管理」、「オフィス管理」、「自国の役所対応」、といったHR,Adminスキルが中心になります。（まあ、これが実際難しく、差別化の要因にもなりえます）
このような会社が良い・悪いと言っている訳ではありませんが、ラボ型開発だけやっている会社の場合、技術的な問題が発生しても的確な技術サポートがあまり期待できない可能性があります。
技術的な支援も受けたい場合は、会社として技術力向上・維持のためにきちんと投資をしているかどうか見極めることが大事でしょう。
※一般的に、オフショア会社に技術力は蓄積しません。スキルはエンジニア個人に蓄積します。
ラボ型開発の課題と、今後について
ラボ型開発の課題とは？
ラボ型開発の案件を継続受注するのは難しい
ラボ型開発は以下の理由により継続案件の受注が難しいのが実情です（除く、一部メンテ案件）。ただ、日本国内のエンジニア不足により、オフショアを求める新規案件が次々発生するため、日々新しい案件を獲得できているようです。
（大人数では圧倒的に子会社が安くなる。また、要員への長期投資も可能となる）
・ベンチャー企業で開発がうまく行かなかった会社は撤退する
（会社自体がなくなることも）
・研究開発は流行りすたれがあって安定しない。継続するかしないかには運もある。
結果として、
・常に新規顧客を開拓していく必要がでてくる（自転車操業になる）
・案件を継続受注していくためには、スキルと価格のバランスが重要と思われる
ローリスク・モデルはいつまでも続かない
・オフショア国の賃金上昇によるエンジニア単価の上昇。結果として利益が圧迫される。
→安い国を求めて移動する「イナゴ型ビジネス」の終焉は近い
・利益率向上のためロースキル・エンジニアをあてがうと、顧客からクレームの嵐となる
・新卒は低賃金だがロースキル。新人教育をするには一定規模以上でないと厳しい。結果として要員バランスをうまく構築できる大規模オフショア企業への集約化が進む。
離職率の高止まりとジョブ・ローテーションの困難性
・そのため、スキル要員本人の異動希望が叶わず、結果として離職となるケースが多発する。
※代替要員が豊富な大手だと多少はましだが・・・
・中長期間メンバーが固定化されることで、個人の成長機会がなくなりメンバー全体に不満が蓄積する
・中長期にわたる特定プロジェクトへのアサインで、給与とポジションをどう上げていくかは難しい問題
・有能なエンジニアほど離職率が高いのは常識
・世界的な人材の枯渇は現実化している。その中での有能なエンジニアの獲得競争はだんだん厳しくなっている
（世界的にも若者は少なくなりつつある）
「ラボ型開発」の今後
「ラボ型開発」の３極分化
※ラボ型開発は、従来のラボ型（中小規模）、子会社設立・集約化（大規模）、ダイレクト雇用（少人数）へ３極分化する？
現在、「ラボ型開発」への需要があることは確かです。お手軽に試行錯誤的な開発ができる、仕様書が不明確で逐次開発的な手法をとりたい、などの需要を満たすことができます。
ただ、今後の動向を考えると以下の３つの方向に分かれていくのではないかと考えられます。
１．現在の「ラボ型開発」形態の存続
・お手軽に一定期間チームを組成できるメリットは大きい
・言語（日本語）の壁がまだある現状では、当面のビジネスモデルとして有効
・ただし、特定業務やスキルに強い（特化した）会社が選ばれる傾向が進むと思われる。
２．子会社化や特定の大規模オフショア開発会社への集約
・ラボ型チームからの移管が必要になるが、委託側企業の業務増大やオフショア関連ノウハウの蓄積により、子会社化という選択は現実的である
３．個別に直接現地エンジニアと業務委託契約をする
・単発案件・単機能であれば、国際クラウドソーシングによる直接個別契約により圧倒的なコスト削減効果が見込める（日本ではまだまだリスクも大きく現実的ではないが）
・組織的で中長期的案件の場合は、クラウドソーシングでなく現地で必要なスキル要員の求人をして個人と直接業務委託契約を結ぶほうがまだ現実的。ただ現地での採用・契約や開発のトラブル時対応などを低価格で支援可能な業者のサポートが必要となる。
以上、３つの方向性を見てみましたが、いずれにしても現地のオフショア企業、担当予定のエンジニアを確実に見定める必要もあります。
現在における現実的な”個別エンジニアとの直接契約サービス”として、以下の「国際越境リモート採用支援サービス（有期の業務委託契約）」も検討してみてはいかがでしょうか。
エンジニアの採用活動だけでなく、現地での開発業務遂行上の支援もいたします。
自動翻訳が変えるオフショア開発の未来（国際クラウドソーシング）
現在、日本国内で急拡大している「クラウドソーシング」が今後は国際的なレベルで拡大するのではないかと考えられます。
つまり、国境を越えた個人（フリーランス）とのオープンな「業務委託契約」です。
現在でも国際クラウドソーシングは存在はしますが、日本から仕事を依頼するのはまだまだ言葉の壁や仕事のやり方の違いがあり現実的ではありません。しかし今後は自動翻訳や各種サポート業務の充実により、近い将来は国際クラウドソーシングがより身近になってくるのではないでしょうか。
＜今後を考える上でのポイント＞
（例：チャットでの即時自動変換、自動翻訳会議、などが現実化する）
・国際クラウドソーシングの進化により、国境を越えた「個人」人材の流動化が加速する
・従来は会社単位に案件を依頼したが、これからは「個人」へ依頼する時代へ
（チーム組成や仕事の分解等検討余地は大きいが）
・小さな案件からピンポイントで必要なスキルを国際的に調達できる世の中へ。
・人的な量的充足の時代から、スキル価値重視への転換。
・各種リスクをどう担保できるかが大きな課題
（お金だけでなく、失敗時の機会損失をどう防ぐかなども重要）
【ご参考：国際クラウドソーシング会社】
アメリカの大手クラウドソーシング会社Upworks社
https://www.upwork.com/
witmart社（中国社名：猪八戒（中国資本））
http://www.witmart.com/
まとめ
さて皆さん、いかがでしたか？
「【本当にラボ型開発でいいの？】オフショア開発におけるラボ型開発の課題と契約上の注意点」をご紹介しました。これからオフショア開発を検討する上での参考になったでしょうか。
オフショア開発は「ほとんどが失敗する！」などという話がネット上で飛び交っていますが、実際のところ失敗プロジェクトは少なくなってきています。（もちろん、何をもって成功・失敗とするかの定義も難しいものがありますが）
「ほとんどが失敗する！」と騒ぎ立てている人たちの理由を見ると、ちゃんとしたソフトウェア開発プロジェクトをやったことがない人達のようにに見えます。たぶん国内のプロジェクトでも他社と協業する場合、うまく行かないのでは？と勘繰ってしまいます（上から目線で済みません。半分隠居ジジイの戯言です）。
プロジェクトに国内もオフショアもありません。基本をまず押さえて、プロジェクト特有の条件に適応するように運営方法をカスタマイズするだけです。（プロジェクトの定義の１つは「ユニーク性」というのはご存知だと思います）
基本を押さえたら、あとは先人たちの知見を参考に、スピード感を持ってPDCAを回すということでしょうか。最初から100%を狙わず、問題が出ることを前提に体制を組み、日々改善していくことが重要ではないかと思います（オフショアの場合は特に）。
ラボ型開発には当然、メリット、デメリットがあります。
その特性を十分理解してどのように活用するか、考えていきたいものです。
もし、ご質問やサポート依頼等がございましたら、当ブログの「お問合せ」からお願いいたします。
では、明るく、楽しく、前向きに、毎日をお過ごしください。
コメント