ラボ型開発とは
ラボ型開発とは、一定の期間、社外に専属の開発チームを構築し、体制開発を委託するという開発形態であり、ラボ契約とも呼ばれます。一般的には、委託先の企業と半年~1年間ほどの中長期契約を結び、その期間、開発チームは、依頼元企業の案件だけを扱います。
専任のエンジニア(4-5名程度)で体制構築され、契約期間中は開発に注力してもらえるため、一定期間、社外に専属チームを確保する目的で利用されます。オフショアやニアショアでよく用いられる契約形態です。
ラボ型開発の契約が締結すると依頼先は案件専任のチームを編成し、一定期間、依頼元の指示を受けながら、開発業務を行います。依頼元は依頼先のPMやブリッジSEとのやり取りをし、それを通して、開発の指示を行います。
「国内ラボ型開発」と「海外ラボ型開発」の2種類がある
「オフショア開発センター(ODC)」が「ラボ型開発」と同義に扱われるケースも多々あるため、「ラボ型開発=海外(オフショア)」と捉えられることが多いですが、実際には、海外だけでなく国内にもラボ型開発を請け負う企業もあります。
国内型の場合は、オフショア開発で課題となっている言語や時差、文化の壁がなくコミュニケーションも円滑にとれます。一方で、コスト面においてはオフショア型の方が低く抑えられます。一般的に、システム開発にかかるコストのうち、人件費はその7割を超えるとも言われています。つまり、人件費を抑えるには開発コストの削減につながります。開発内容や予算、納期などを考慮し、適した方を選択する必要があります。
オフショア
ビジネスの場における「オフショア」は、自国から離れた地域、つまり海外を指します。 業務の一部を物価や人件費の安い地域に移すことでコストの削減を実現します。
ラボ型開発が注目される背景
昨今、ラボ型開発が注目される背景としては、経済産業省の「IT人材需給に関する調査」において2030年には最大で79万人のITエンジニアが不足するといわれています。その解消策として、ITエンジニアを確保できるラボ型開発を活用する企業が増えているのです。
また、オンラインミーティングの普及も追い風になっています。定期的に依頼元と依頼先で連絡を取って情報共有を行うことでコミュニケーションや進捗管理を行えるようになりました。
従来は請負型開発が主流でしたが、柔軟な開発が行えるラボ型開発は今後より需要が高まっていくでしょう。
ラボ型開発と請負型開発の違い
簡単にいうと、ラボ型契約(準委任契約)は、「作業人数×時間」の契約である一方で、請負型契約は「成果物」に対する契約です。既に決定した案件があり、完成品を求める場合は請負型契約、一定期間の人手の確保や柔軟な仕様変更を目的とする場合はラボ型契約がおすすめです。
ここからは両者の違いについて詳しく解説します。
Web開発を外注する場合、ラボ型開発と請負型開発のいずれかの契約を結ぶ場合がほとんどです。どちらが適しているか知るためにも両者の特徴を比較します。まず、2つの違いについて表でまとめてからそれぞれ言及していきます。
請負型契約 | ラボ型契約 | |
契約形態 | 請負契約(民法第632条) | 準委任契約(民法第656条) |
責任範囲 | 契約期間内での成果物の納品 | 業務の遂行 人員の確保・稼働 ※成果物に対する責任はない |
契約期間 | 短期(納期による) | 中長期 |
開発体制 | ウォーターフォール型 | ウォーターフォール型 アジャイル型 |
開発モデル | 開発者が決定 | 依頼元と依頼先で決定 |
メリット | ・完成品の納品が保証される ・案件ごとの契約で開発コストを把握しやすい | ・一定期間エンジニアチームを確保できる ・開発コストを抑えられる ・仕様変更や修正が柔軟にできる ・開発ノウハウを蓄積できる |
デメリット | ・依頼時点で要件定義書や仕様書が必要になる ・仕様変更や修正には追加で費用が発生する可能性がある ・開発ノウハウが蓄積されない | ・チームビルディングに時間が必要になる ・発注が少ないとコストパフォーマンスが低くなる ・発注元にマネジメント負荷がかかる |
適したケース | ・開発要件、仕様が決まっている ・単発の案件 | ・定期的に発注する案件がある ・仕様変更が予想される、または仕様が決まっていない ・既存アプリやサービスの運用、改修 ・アジャイル型開発 |
契約形態・責任範囲
契約の形態として、ラボ型開発は「準委任契約(民法第656条)」を結ぶケースが多いです。準委任契約は契約期間中に決められた業務を遂行することのみを約束する契約であり、成果物の完成や納品は求められません(※契約書に記載された内容に準ずる)。そのため、案件が継続的に発生し、その開発に人的リソースを確保したい場合に、外部エンジニアを一定期間確保するのに適しています。一方で請負型契約は仕事の完遂や成果物の納品を求められます。
契約期間
ラボ型開発は中長期案件(半年~1年間ほど)であり、案件単位の発注ではありません。一方で、請負型契約は短期案件であることが一般的です。プロジェクト単位の契約であり、プロジェクトが終わり次第、開発チームは解散します。
開発体制・開発モデル
請負型契約はすでに決められた完成内容を基に、開発者が工程を決め、ウォーターフォール開発で行います。その一方で、ラボ型開発は期間内であれば柔軟に開発を行えるため、依頼元と依頼先で決めながら開発を進めていきます。これは細かい周期で開発を繰り返すアジャイル開発に適しています。
ウォーターフォール開発
ウォーターフォール開発は、従来から使われてきた開発手法で、あらかじめソフトウェアにおける全ての機能に関する要件定義や設計を綿密に行った上で、プロジェクト全体で「企画→計画→設計→実装→テスト→運用」という順に工程を進めます。ウォーターフォール開発は、これらの工程を水が下に落ちていくように一方通行で行うことからこう名付けられました。開発初期に定めた要件定義や設計が重視されているため、基本的には、後からの仕様変更は想定されていません。
アジャイル開発
アジャイル開発とは、システム開発における手法の一つで、機能ごとに細かく分け、小さなサイクルで反復的に開発を進めていくという開発手法のことです。優先度の高いものから機能単位で開発していき、それぞれを組み合わせることで1つの大きなシステムを形成します。一般的なやり方に比べて、短い期間でリリースできることから、「アジャイル(素早い)開発」と呼ばれています。
この手法は、「プロジェクトの進行途中で仕様変更は必ず出てくるもの」という前提のもとで開発を進めるので、容易に仕様設計の変更や機能の追加ができます。
アジャイル開発は機能ごとに小単位で反復的に開発を進めていくのに対し、ウォーターフォール開発は企画からリリースまで一方向の大きなスケジュールで開発を進めます。
機能ごとに工程を細かく分けて開発を進めていくアジャイル開発では、重要な機能や優先度が高いものから着手できるため、速やかにリリースして、後からユーザの感想や使い勝手を参考にしながら、追加機能や改善を行うなど、質や価値を上げていくことが可能です。
それに対し、手順ごとに開発を進めていくアジャイル開発では、リリース時にすべての要求を満たしていることが求められます。工程の変更や後戻りを想定していない手法であるため、途中で機能追加や致命的な欠陥が見つかった場合、最初からやり直さなくてはいけないといったリスクもあり、修正に多大なコストや労力がかかります。ウォーターフォール開発では、綿密な打ち合わせを重ね、企画段階でかなり具体的に内容を検討し、設計段階では画面やデザインなどもより詳細に決めていきます。
アジャイル開発とは?【入門】メリット・デメリット、進め方
・案件ごとの契約であり、完成後チームは解散するため、開発ノウハウが蓄積されない
ラボ型開発のチーム体制
ラボ型開発と請負型開発のチーム体制の違いについては以下の図を参照してください。
ラボ型開発では、エンジニアチームを編成し、チームを統括するPMまたはブリッジエンジニア(ブリッジSE)もチームの一員として開発に携わります。開発チームは、契約期間中は専属になるため自社開発チームと同じような開発チームを社外に持つイメージです。依頼元は、ブリッジエンジニアに対して、作業指示を出します。
同じく準委任契約の「SES」との違いは?
ラボ型開発と同じ契約形態の「SES(System Engineering Service)」は、開発する拠点が異なります。ラボ型開発は開発チームが属する企業のオフィスなどで開発しますが、SESでは基本的に委託元の企業にチームまたはエンジニアが常駐して開発します。また作業内容に関しても、ラボ型開発が中長期的に特定のプロジェクトを遂行する一方で、SESは長期的に日常的な業務・サポートを行うのが一般的です。
ラボ型開発のメリット
開発コストを抑えられる
ラボ型開発は「人員✕期間」での契約になっているため、契約期間中に仕様変更や機能追加があった場合でも原則的に追加費用は発生しません。請負型開発の場合は仕様変更や機能追加が発生する度に改めて見積りが必要になったり、コストも追加でかかってくる場合もあるのでラボ型開発の方が低コストで柔軟な開発が行えます。
優秀な人材を一定期間確保できる
ラボ型開発では自社で採用や育成することなく優秀なエンジニア人材を専属として一定期間確保できます。請負型ではほかの案件も並行して請け負う場合もあり、そちらにもリソースを割くため、望んだように人材を確保できるわけではありません。特に、PL以上の人材であるほどその可能性が高いです。ラボ型開発であれば、専属になる上、基本的にメンバー編成が変わることもないので優秀なエンジニアを確保し、ノウハウを共有・蓄積しながら開発を進められます。
仕様変更・機能追加にも柔軟に対応できる
ラボ型開発は「人員✕期間」での契約になっているため、契約期間中であれば仕様変更や機能追加があった場合でも契約人員内で対応可能な工数の範囲内であれば、開発リソースを自由に使えます。請負型開発の場合は仕様変更や機能追加が発生する度に改めて見積りを作成しなくてはなりません。こういった点からラボ型開発の方が柔軟な開発が行えます。
コミュニケーションが円滑にとれる
ラボ型開発は基本的にラボメンバーが固定されることでラボメンバー内・依頼先と依頼元間でもコミュニケーションも円滑にとりやすくなります。これによって開発スピードや品質の向上も期待できるでしょう。単発で開発を行い、プロジェクトごとにメンバーが編成される請負型ではそのたびに時間を要すでしょう。
開発ノウハウをラボチーム内で蓄積できる
ラボ型開発は基本的にラボメンバーが途中で変わったりいなくなったりしないため、ラボメバー内でノウハウを共有・蓄積しながら開発を進められます。これによって開発スピードや品質も向上します。単発で開発を行い、プロジェクトごとに新たなチームを組む請負型ではその都度、位置から認識のすり合わせや情報の共有を行う必要があり、時間がかかってしまうでしょう。ラボ型開発はそ時間が必要ない分、工数や時間を削減できます。
ラボ型開発のデメリット
発注が少ないと費用対効果が低くなる
ラボ型開発では、「人員✕期間」での契約になっているため、契約期間中は一定量の業務を発注する必要があります。それが少ない場合も費用は発生するので、その場合はかえって費用対効果が低くなってしまいます。継続して発注する案件がある場合に向いています。また、発注する案件がなくなり、人材リソースの空きが発生した場合は、余ったリソースを別の業務にあてるなどの対策も事前に練る必要があります。
チームビルディングに時間が必要になる
中長期間にわたって案件を専属で任せるため、ただメンバーを集めればいいというわけではありません。また、ラボメンバーは固定されるため、チームの立ち上げ時が極めて重要になります。求めるスキルを持つ人材を選定し、チームを編成します(※依頼先によっては選定できないケースもあります)。編成後も開発を進めるための体制を整える必要があり、一定の時間がかかります。
発注元がマネジメントを担う必要がある
請負型の場合、依頼元は要件定義書や仕様書を渡して発注するのみで、その後の開発は依頼先に任せますが、ラボ型開発の場合は、依頼元の担当者がメンバー選定のほか、チームメンバーの編成後は、個々のラボメンバーのスキルレベルや性格に合わせてコミュニケーションをとったり、開発を円滑に進められるようマネジメント業務も行う必要があります。また、開発中もブリッジエンジニアを通してチームに対して指示を出したり、チェックを行うなど、社内開発と同じようなマネジメントが必要になります。専属チームを持つことで得られる恩恵は大きいですが、そのマネジメントの負荷も発生することには注意が必要です。
ラボ型開発向きの開発案件
定期的に発注する案件がある場合
一定量以上の開発業務が恒常的にあり、その人員を求める場合にラボ型開発が適しています。請負型だと案件ごとに依頼先を選定したり、案件内容を説明したり、見積もりを作成したり、依頼先とすり合わせを行ったりと、何かと手間がかかってしまいます。ラボ型では外部に自社と同様の開発チームを持つようなものなのでそういった面倒事はありません。
仕様変更が予想される場合
仕様変更や機能追加が想定される場合もラボ型開発がおすすめです。契約期間中であれば、仕様変更や機能追加があった場合でも原則的に追加費用は発生しません。請負型開発の場合は仕様変更や機能追加が発生する度に改めて見積りが必要になったり、コストも追加でかかってくる場合もあるのでラボ型開発の方が低コストで柔軟な開発が行えます。また、長期間、固定化されたラボメバー内でノウハウを共有・蓄積しながら開発を進めるので理解も早く、開発スピードや品質も向上します。
アジャイル開発
上記と同様に、仕様変更の度に見積もりを作成したりチーム体制を変更する必要のないラボ型開発の開発形態は、アジャイル開発のように、開発途中で仕様変更が発生することを前提とし、小さなサイクルで開発を繰り返していく開発手法にマッチします。
また、ラボ型開発では契約時に要件も仕様が明確に決まっていない場合でも開発しながら開発内容を詰めていくという方法もとることができます。詳細を決めずとも早い段階で開発に着手でき、まずリリースしてから改善・改修していけます。
請負型開発では事前にすべての仕様や予算、スケジュールを確定させた状態でスタートするため、あらかじめ決まった成果物を納品することが決まっています。この手法は昨今の開発スピード重視のシステム開発には不向きです。ラボ型開発では期間中、自社の開発チームと同じように開発を依頼できるのでこういったことは起こりません。
既存のアプリやサービスを運用・改修する場合
定期的な改善・改修、不具合に対する対応が必要になる既存アプリやサービスの運用・改修には、同じメンバーで継続的に開発を行うラボ型開発が向いています。
ラボ型開発における注意点
契約期間は一定量の発注を行う必要がある
ラボ型開発では、契約期間中に発注する仕事が少ないとコストパフォーマンスが低くなるので期間中は継続して案件をは注する必要があります。
依頼先の実績を確認する
依頼先を選定する場合、必ず十分な実績を確認しましょう。発注しようとしている案件と似たような実績があれば、安心して任せられます。
メンバー変更は難しい
中長期案件であり、基本的にメンバー変更などはないので契約前に案件を遂行するのに必要なスキルや工数を把握しておく必要があります。また、企業によっては契約期間ごとに人数の見直しができるので発注する業務量が少ない時は人数を減らし、多いときは増加させるといったことができます。また、メンバー選定や契約期間ごとの人数が変更できる企業家も調べる必要があります。
タスク管理を徹底する
ラボ型開発では原則、成果物の納品がないのでスケジュールや作業進捗が曖昧になってしまう傾向があります。そのため依頼元でもブリッジSEと定期的に連絡を取り、タクスの管理を行うようにしましょう。
指示内容は明確に伝える
ラボ型開発に限ったことではありませんが、コミュニケーションのずれによって重大なミスに繋がりかねません。特にプロジェクトの立ち上げ時には信頼関係の構築や積極的なコミュニケーションを取る必要があります。
セキュリティ
ラボ型開発では基本的に開発会社側の社内で開発作業を行います。そのため、発注を依頼する企業を探すときは、セキュリティ面をよく確認しておく必要があります。
ラボ型開発の流れ
開発会社の選定
開発実績や開発コスト、セキュリティ面などを考慮して案件を発注する企業を選びます。発注内容や予算に合った企業を選びましょう。
発注内容のヒアリング・見積もり
開発会社を決めたら、先方とヒアリングを行い、案件内容の説明や見積もりを説明します。また、依頼先のスキルや開発の進め方をききます。その結果から依頼先とで人員と費用の概算を出します。
スタッフ人選
案件を任せるエンジニアのスキルや人柄などを考慮して選定します(※選定可否は企業による)。エンジニアの人選は開発を左右するので重要な工程です。
契約
両者が合意したら正式に契約となります。ラボ型開発には基本的に「完成責任」と「瑕疵担保責任」がありません。これらを保証してもらいたい場合は誓約書に記載するか、元からそういった保証を行っている企業を選ぶようにしましょう。
瑕疵担保責任
成果物の質が想定以上に低い場合や不具合や欠陥が見つかった場合に依頼先が保証する義務です。
ラボの立ち上げ・開発
契約締結後はいよいよ開発が始まります。期間中であれば修正や機能追加なども柔軟に行えます。継続的に案件を発注してラボ型開発を最大限に活用しましょう。
ラボ型開発ならテックマニアがおすすめ!
一般にラボ型開発で多いのは、国外のエンジニアと契約を結ぶオフショア開発になります。一方で、テックマニアは完全国内契約です。日本人のエンジニアチームが専属となって開発を進めるため、コミュニケーションを取りやすく仕様変更や機能追加にも柔軟に対応可能です。
また、弊社所属のエンジニアは自社開発によるノウハウがあるので、プロジェクトにもスムーズにアサインできます。さらに、開発経験10年以上のメンバーやWebに特化したエンジニアも多く在籍しており、ラボメンバーを統率しながら中心となって開発を進めます。こうした理由から質の高い開発体制を提供できるのがテックマニアの強みです。
ラボ型開発を検討されている企業様は無料相談を受け付けておりますので、今すぐ下記のリンクからお問い合わせください。