「そのつど請負」でスピードが出なくなったら、チーム貸しを検討する

「そのつど請負で見積を取っていると、追加改修のたびに交渉と待ち時間が発生してスピードが出ない」——プロダクト運営が長期化してくると、多くの発注担当者がこの課題にぶつかります。そこで選択肢に上がるのが、開発チームを一定期間まるごと借りる「ラボ型開発 (チーム貸し)」です。ただし、プロジェクト請負とはコストの積み方も、成果責任の考え方もまったく違います。誤解したまま契約すると「毎月請求は来るのに、思ったほどアウトプットが出ていない」という状態に陥ります。

この記事では、発注側の視点でラボ型開発の見積構造を分解し、費用の考え方、期間契約のメリット、注意すべきリスク、国内とオフショアの違い、そして「向いている案件・向かない案件」の判断基準までを整理します。プロジェクト請負・準委任契約・アジャイル開発との比較を通じて、自社の案件がラボ型に合うのかを判断できる材料をまとめました。

1. ラボ型 (チーム貸し) とプロジェクト請負の違い

ラボ型開発とは、開発会社に「専任の開発チーム (多くは準委任契約)」を一定期間確保してもらい、その期間中は発注側の指示に従って柔軟にタスクを進めてもらう契約形態です。海外の開発拠点を活用するオフショア文脈で普及した用語ですが、国内でも「チーム貸し」「専属チーム」として同じ形態が広く使われています。

プロジェクト請負との違いを整理すると次のようになります。

項目プロジェクト請負ラボ型 (チーム貸し)
契約形態請負契約が中心準委任契約が中心
見積の対象成果物 (スコープ)期間・チーム稼働時間
スコープ変更都度、追加見積期間内は柔軟に差し替え可
完成責任開発会社が負う発注側が仕様と優先度を決める
適する案件要件が固まっている案件継続的に改善が発生する案件

ここが最大の分岐点です。ラボ型では「完成物」ではなく「稼働時間」を買っている、という前提を発注側が理解している必要があります。詳しくは 請負契約と準委任契約の違い もあわせて参照してください。

2. ラボ型開発の見積構造は「人月単価 × 期間」

ラボ型開発の見積は非常にシンプルです。

ラボ費用 = 人月単価 × チーム人数 × 契約期間 (か月) + 管理費

たとえば「PM 1 名・エンジニア 2 名・デザイナー 1 名」の 4 人体制を 6 か月契約する場合、人月単価と人数を掛け合わせた金額が毎月請求されます。個々のタスクごとに見積書は発行されず、期間終了時に更新するか、次期契約を結ぶかを判断するのが一般的です。

チーム構成のパターン例

小さめの改修中心なら「PM 0.5 人 + エンジニア 2 名」で走り、機能追加が多いフェーズでは「PM 1 + エンジニア 3 + デザイナー 1」に拡張する、といった柔軟な組み替えが可能です。人月単価そのものは システム開発の見積相場 で解説した水準 (中堅エンジニアで 80〜120 万円台) に近いレンジで動きますが、期間契約割引が入り、単発案件よりやや下がるケースもあります。

管理費・立ち上げ費用

初回のみ「立ち上げ費」「オンボーディング費」として、既存コードのキャッチアップ工数が別途計上されることがあります。ドキュメントが整理されていない既存プロダクトに合流する場合、この初期工数が数十万〜数百万円規模になることも珍しくありません。見積を受け取ったら、月次のランニング費用と初期費用を分けて確認してください。

「稼働率」の扱いを必ず確認する

ラボ型で最も揉めやすいのは、チームの稼働率をどう保証するのかという点です。「月 160 時間分をコミットする」のか、「ベストエフォートで進める」のかによって、実質的な工数量は大きく変わります。発注側からの指示が途切れると稼働が下がる契約もあり、この場合は「発注側が仕事を切り出せない期間の費用は捨て金になる」というリスクを負います。

FIXITFIXIT

ラボ型ってタスク単位じゃなくて、チームごと借りるって話なの?

TsukasaTsukasa

そのとおりです。一定期間のチーム稼働を買う契約で、成果物ではなく時間を買うイメージです。

FIXITFIXIT

じゃあ、こっちがタスクを渡さなくても請求は来る?

TsukasaTsukasa

結論から言うと、その月の稼働時間分は発生します。指示を出す体制がなければ、そのまま捨て金です。

FIXITFIXIT

それは怖い。逆に向いてない案件ってどんな感じ?

TsukasaTsukasa

判断の軸は指示体制の有無です。完成期限が硬い一発案件と、社内で PdM を立てられない組織はまず避けてください。

3. 期間契約のメリットは継続改善と長期パートナー化

ラボ型が支持される最大の理由は、単発の請負では得にくい「継続性のメリット」にあります。

コンテキスト理解が積み上がる

同じチームが継続的に関わることで、ドメイン知識・コードベース・意思決定の経緯が蓄積されます。請負案件を都度別チームに発注する場合、毎回キャッチアップ工数が発生しますが、ラボ型ではそのロスがほぼゼロになります。半年、1 年と続くほど、単位工数あたりのアウトプット密度は上がっていきます。

優先度の入れ替えが即時にできる

「今月は決済機能を優先」「来月は分析ダッシュボード」といった優先度の入れ替えを、追加見積なしで実行できます。マーケット状況や社内政治で優先度が動きやすいプロダクトほど、ラボ型と相性が良い傾向があります。この特性は アジャイル開発の見積 と近い発想で、実際にラボ型 + アジャイル運用を組み合わせるチームは多いです。

採用リスクを外部化できる

事業会社が正社員エンジニアを採用する場合、採用コスト・教育コスト・退職リスクを負います。ラボ型は「必要な期間だけチームを持ち、フェーズが変われば規模を調整する」というオプションを買っている側面があります。

4. リスクとデメリットは稼働率・モチベーション・ノウハウ帰属

一方で、ラボ型には請負にはない特有のリスクがあります。

(1) 稼働の管理責任が発注側に移る

請負なら「納品されるまでは開発会社の責任」ですが、ラボ型は「毎月チームを回し続ける責任」が発注側にあります。PdM やディレクターを社内に立てられない組織では、指示が出せずに月末を迎えることが起こりえます。稼働率が下がったとしても費用は発生します。

(2) チームのモチベーション低下

同じメンバーが数か月〜数年、同じプロダクトに張り付くため、業務がルーチン化するとエンジニアのモチベーションが下がりやすい構造があります。定期的なメンバー入れ替えや技術チャレンジの機会設計を、契約前に開発会社側と握っておくと安全です。

(3) ノウハウ・知財の扱い

開発チームが外部にある以上、コードやドキュメントが自社内だけに閉じるわけではありません。将来的な内製化や、他社への切り替えを見据えて、コード資産・ドキュメント・環境構築手順の帰属を契約時に明文化しておく必要があります。

(4) 「解約しづらさ」の心理的コスト

長期関係が続くほど、パフォーマンスに不満があっても「関係性を壊したくない」という心理が働き、切り替え判断が遅れがちです。四半期ごとに KPI・アウトプット量・満足度をレビューする仕組みを組み込むことをおすすめします。

コツ

ラボ型のリスクは、そのほとんどが「発注側の稼働管理体制」の問題です。契約前に、社内で誰が優先度を決めるのか (PdM)・誰が仕様を書くのか (ディレクター)・誰が受け入れ判断をするのかの 3 役を確定させておくと、「請求は来るのに進まない」状態を回避しやすくなります。

5. 国内ラボとオフショアラボで単価と体制が変わる

同じラボ型でも、国内で組成するか海外拠点を使うかで、費用構造とマネジメント負荷が大きく変わります。

項目国内ラボオフショアラボ
人月単価の目安中堅で 80〜120 万円台拠点により 30〜60 万円台が中心
コミュニケーション日本語で完結日本語ブリッジ or 英語必須
タイムゾーン同一拠点により 1〜数時間差
ドキュメント要求水準口頭合意も許容明文化必須
向く工程上流〜運用まで一貫実装フェーズが中心

オフショアラボは単価が半額前後になりますが、その差額の一部は「ブリッジ SE の人件費」「仕様書作成の追加工数」「品質保証工程」に消えていきます。表面上の単価だけで判断せず、体制総額で比較することが重要です。この点は オフショア開発の見積 でも詳しく解説しています。

一方、国内ラボは単価こそ高いものの、要件が固まっていない状態でもディスカッションベースで進められる強みがあります。要件定義の解像度が低い初期フェーズは国内、量産フェーズは併用、といった使い分けも現実的です。

6. ラボ型を選ぶべき案件・選んではいけない案件

ラボ型が力を発揮する案件、逆に不向きな案件を整理します。

ラボ型が向いている案件

  • 半年以上の継続的な開発ニーズが見込まれる
  • プロダクトの優先度がマーケットに応じて動く
  • 社内に PdM・ディレクターを立てられる
  • 内製化に向けた助走として外部チームを使いたい
  • 継続的なリファクタリング・改善が必要な既存プロダクト

ラボ型が向いていない案件

  • 完成期限と成果物が厳密に決まっている一発案件
  • 社内に指示出しできる人材がおらず、丸投げしたい
  • 3 か月以下の短期スポット案件
  • セキュリティ要件により外部常駐が制限される案件
  • タスクの切り出しが不定期で、月の稼働に波が大きすぎる案件

短期スポットや丸投げ前提の案件は、フリーランス発注 や請負プロジェクトのほうが結果的にコストが合うことが多いです。

まとめ

ラボ型開発は「成果物」ではなく「一定期間の開発チーム稼働」を買う契約で、見積は「人月単価 × チーム人数 × 期間 + 管理費・立ち上げ費」というシンプルな式で決まります。継続改善と優先度の柔軟な入れ替え、採用リスクの外部化がメリットですが、稼働管理責任が発注側に移ること、モチベーション設計、ノウハウ帰属、解約しづらさは対策すべきポイントです。半年以上続く継続改善型のプロダクトに強く、短期スポットや丸投げ前提の案件には不向き、という距離感を持っておくと、契約形態選びで大きく外すことは減ります。

AI 駆動開発のクリエイティブスタジオである FIXIT では、案件の状況に応じて請負・準委任・ラボ型を組み合わせた提案を行っています。「自社の案件はどの契約形態が最適なのか」を一緒に整理したい方は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。