Published on

ラボ型開発とは?仕組みと契約形態、向いている開発体制を解説

要点 / TL;DR

ラボ型開発とは、準委任契約で開発チームを一定期間確保し、発注側が優先順位を調整しながら継続的に開発を進める体制です。完成物の責任をどこが負うかという点で、受託開発(請負型)とは契約の考え方が異なります。仕組み、契約形態の違い、向いている開発体制、費用の決め方を整理します。

この記事はAIの支援で作成し、人間が確認しています

Authors
  • avatar
    Name
    MK1編集部
    Twitter
ラボ型開発とは?仕組みと契約形態、向いている開発体制を解説

ラボ型開発とは?

ラボ型開発とは、発注側と受託側が準委任契約を結び、開発チームを一定期間継続的に確保して開発を進める体制です。発注側が優先順位を判断し、受託側がその指示に沿って設計・実装・テストを進める形が基本となります。完成物を引き渡して終わりにするのではなく、チームの稼働を一定期間確保し続ける点が特徴です。

「場所」と「契約」を分けて考える

ベトナムオフショア開発は、開発拠点をどこに置くかという軸の話です。ラボ型開発は、どの契約で開発を進めるかという軸の話になります。2つは対立する選択肢ではなく、ベトナムのチームを準委任契約で確保するという組み合わせも成り立ちます。体制を検討するときは、場所と契約を分けて考えると論点が混ざりません。

ラボ型開発の仕組みはどうなっている?

チームを継続的に確保し、要件定義から設計・実装・テストまでを短いサイクルで回します。発注側は優先順位を決め、受託側は決まった範囲を実行し、結果を定例で共有する流れです。契約期間のあいだ、同じチームが同じプロダクトに向き合い続けます。

チームの役割分担

一般的な体制では、次の役割を組み合わせます。

  • BrSE(ブリッジSE):発注側との窓口になり、日本語の要件をベトナム側のチームに伝わる形に落とし込む
  • プロジェクトマネージャー:スケジュール、要員、進捗を管理し、課題を洗い出す
  • エンジニア:設計、実装、コードレビューを担当する
  • QA担当:テストの設計と実施、品質基準の確認を担う

役割の分け方はチームの規模によって変わります。小さい体制では、エンジニアがQAを兼ねることもあります。

1か月単位の進め方

進め方は、次の流れが基本になります。

  1. 月初に作業範囲と優先順位を合意する
  2. 1〜2週間のサイクルで設計、実装、レビューを回す
  3. 定例で進捗と課題を共有し、優先順位を見直す
  4. 月末に成果と翌月の予定を確認する

発注側が関与する頻度は、定例の回数とレビューの場で決まります。判断を待つ時間が長くなると、その分の稼働を活用しきれなくなります。確認のタイミングは先に決めておきます。

ラボ型開発と受託開発(請負型)は契約形態がどう違う?

起点になるのは契約の種類です。ラボ型開発は準委任契約、受託開発は請負契約という違いがあり、この違いが完成物の責任、指示の出し方、費用の決まり方に表れます。どちらかが優れているという話ではなく、発注側がどこまで関与するかで選び分けます。

比較表で見る違い

比較項目ラボ型開発(準委任契約)受託開発(請負型)
契約の種類準委任契約請負契約
完成物の責任業務を適切に遂行する責任を負う受託側が完成物の完成責任を負う
指示の出し方発注側が作業の指示と優先順位を出す要件を伝え、進め方は受託側に委ねる
費用の決まり方単価と工数(稼働)に応じて変動する成果物の範囲に対して固定金額とするのが基本
仕様変更への対応優先順位の見直しとして組み込む契約変更の手続きが必要になる
向くケース仕様が固まりきらず、継続的に改善したい仕様が固まり、完成物と時期を明確にしたい

責任の範囲は、最終的には契約書の定めによって決まります。個別の判断は契約書の記載を確認してください。

どちらが向くか

仕様が固まっていて、成果物と完成時期を固定したい場合は受託開発(請負型)が前提をそろえやすい形です。方向性は決まっているが詳細が変わりそうな場合や、リリース後も改善を続ける場合は、ラボ型開発が候補になります。社内に要件を判断できる担当者がいるかどうかも、判断の分かれ目になります。

ラボ型開発はどんな開発体制に向いている?

仕様が固まりきっていない段階から、継続的に手を入れながらプロダクトを育てたい場合に向いています。発注側が優先順位を判断し、その内容をチームに伝えられる状態であることが前提です。

向いているケース

次の項目に当てはまる場合は、ラボ型開発が候補になります。

  • 優先順位が途中で変わる可能性が高い
  • リリース後の改善を同じチームで続けたい
  • 発注側に要件を判断できる担当者がいる
  • 内製チームや別のベンダーと並走して開発したい
  • 長期的にプロダクトを育てる前提がある

向かないケース

成果物の範囲と完成時期を固定して発注したい場合は、受託開発(請負型)のほうが前提をそろえやすいです。また、発注側が優先順位の判断やフィードバックを継続的に出せない体制では、ラボ型開発の利点が活かしにくくなります。業務の進め方を細かく指定せず、完成物だけを受け取りたい場合も、請負契約のほうが噛み合います。

ラボ型開発の費用はどう決まる?

費用は単価と工数の組み合わせで考え、月単位で把握する形が基本です。固定金額ではなく、確保するチームの人数と期間に応じて変わるため、月ごとの単位で予算を立てます。

単価を左右する要素

  • 求めるスキル(経験や専門領域)
  • BrSEの関与(要件の確認や窓口をどこまで担うか)
  • 契約形態(準委任か請負か)
  • 使用する技術(Web、モバイル、クラウド、AIなど)

工数を左右する要素

  • 要件定義の進め方(発注側がどこまで固めるか)
  • スコープの範囲(対象となる機能や利用者)
  • 非機能要件(性能、セキュリティ、運用の体制)
  • 体制変更のタイミング(増員や減員の時期)

月単位で契約する場合でも、実際の稼働は月ごとに変わります。増員には採用と立ち上げの期間がかかるため、必要が見えた時点で相談しておくと調整がしやすくなります。体制を変更するときの手続きは、契約書の定めに従います。

導入はどのような手順で進める?

目的と優先順位を決めるところから始めます。契約形態と見積もりの条件を確認し、キックオフで進め方を合意してから稼働を始める流れです。

  1. 目的と成果の指標を定める
  2. 必要な役割を洗い出す
  3. 契約形態と見積もりの条件を確認する
  4. キックオフで進め方と報告の頻度を合意する
  5. 定例で進捗と優先順位を見直す

発注側が準備しておくこと

  • 要件を判断できる担当者のアサイン
  • フィードバックの頻度と場の設定
  • ドキュメント、リポジトリ、開発環境へのアクセス
  • 優先順位の付け方の取り決め

見積もりでは、次の項目を確認しておきます。

  • 単価の内訳(役割ごとの考え方)
  • 対象範囲(対象期間と稼働の定義)
  • 追加作業の扱い
  • 体制を変更するときの手続き

まとめ

ラボ型開発は、準委任契約で開発チームを一定期間確保し、発注側が優先順位を調整しながら継続的に開発を進める体制です。受託開発(請負型)とは完成物の責任と費用の決まり方が異なるため、仕様の固まり具合と発注側の関与体制で選び分けます。費用は単価と工数の組み合わせとして月単位で把握し、導入は目的と優先順位の整理から始めます。

当社は2020年7月にベトナム・ハノイで設立し、日本企業向けのソフトウェア開発を手がけ、これまで100件以上のプロジェクトに携わってきました。自社の場合にどちらが合うかを検討したい場合は、お問い合わせからご相談ください。

FAQ

ラボ型開発と受託開発(請負型)は、どちらを選べばよいですか?

仕様が固まっていて完成物を明確に定義できる場合は、受託開発(請負型)のほうが前提をそろえやすいです。一方、優先順位が変わりやすく、継続的な改善を前提とする開発では、準委任契約でチームを確保するラボ型開発が選択肢になります。どちらが適するかは、目的と社内の体制によって変わります。

要件が固まっていない段階でも始められますか?

ラボ型開発は、仕様を確定させてから発注する形態ではありません。方向性と優先順位が定まっていれば開始でき、要件定義を並行して進める前提で体制を組みます。ただし、誰が要件を判断するかは決めておく必要があります。

ラボ型開発では、途中で体制や人数を変更できますか?

一般的には、契約や稼働の見直しのタイミングで人数や役割を調整します。増員には採用と立ち上げの期間がかかるため、必要が見えた時点で早めに相談するのが実務的です。変更の手続きは契約書の定めに従います。

ラボ型開発で品質はどのように確保しますか?

要件定義や設計のレビュー、テスト工程の設計、受け入れテストまでを工程として組み込みます。QA担当を体制に含めるか、開発チーム内でレビューを回すかは規模によって変わります。品質の基準は着手前に発注側と受託側でそろえておきます。

ラボ型開発に向かないのはどんな場合ですか?

成果物の範囲と完成時期を固定して発注したい場合は、受託開発(請負型)のほうが前提をそろえやすいです。また、発注側が優先順位の判断やフィードバックを継続的に出せない体制では、ラボ型開発の利点が活かしにくくなります。

参考文献