ラボ型契約の進め方は、スコープの仮設定から始まります。そのあと、ベンダー選定と契約締結、チーム編成とキックオフを経て、定常運用とExitへと進みます。
請負と違い、契約後の運用設計とExit設計が成否を左右します。
Webサービス開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
- ラボ型契約と請負・SESの違い
- 契約締結からキックオフまでの進め方
- 定量KPIと発注側マネジメントの方法
- TCO、Exit戦略、生成AI時代の運用ポイント
ラボ型契約の全体像と請負・SESとの違い
ラボ型契約とは、発注者専属のエンジニアチームを一定期間（一般的には半年〜数年）にわたって確保し、月額固定で稼働してもらう開発体制を指します。法的には準委任契約に分類され、「成果物の完成」ではなく「労働力の提供」に対して対価を支払う点が大きな特徴です。
請負契約のように仕様確定後に成果物を納品するわけではないため、仕様変更や優先順位の入れ替えに柔軟に対応できます。SES（システムエンジニアリングサービス）も同じ準委任の枠組みですが、個別のエンジニアを客先常駐で派遣する性格が強く、チームとしての継続性やノウハウ蓄積はラボ型ほど期待できません。
ラボ型は、同じメンバーが長くチームとして稼働し続ける点で、SESと明確に異なります。請負・SES・ラボ型の三つを正しく使い分けることが、外部開発リソース活用の出発点です。
請負契約・SESとの根本的な違い
請負契約は、仕様書に基づいて成果物を完成させて納品する義務をベンダーが負う契約形態です。仕様が明確で、納期と金額が固定された短期の単発案件に適しています。ただし、仕様変更のたびに追加見積と契約変更が必要になり、新規事業のように要件が動き続けるプロジェクトでは事務処理コストが膨らみがちです。
完成責任を負う分、ベンダー側はリスクバッファを単価に上乗せするため、金額も高止まりしやすい性質があります。これに対してSESは、個別のエンジニアを月単位で派遣し、稼働時間に対して対価を支払う形態です。ラボ型と同じ準委任ですが、SESは「人を貸す」性格が強く、エンジニアが入れ替わることも珍しくありません。
一方、ラボ型は、PMやリードエンジニアを含むチームを長期で固定し、ベンダー社内でも独立した「ラボ」として運営される点が決定的に異なります。富士フイルムヘルスケアとFPTのラボでは、少人数からスタートし、15年で170名規模に拡大しています。同じメンバーが長期で関与し続けるからこそ、業務知識の蓄積とアウトプット品質の向上が両立するのです。
メリット・デメリットと向くプロジェクトの特徴
ラボ型契約の最大のメリットは、優秀な人材を長期で確保しながら仕様変更に柔軟に対応できる点です。追加見積が発生しないため、要件が頻繁に動く新規事業でも、意思決定のスピードを落とさずに開発を進められます。また、長く同じチームで動くほど業務ドメインの理解が深まり、リファクタリングや改善提案が自発的に生まれる効果も大きいです。
たとえば、大手飲料子会社のチャットボット新機能ではラボ型運用で売上が120%増加し、LeaLea合同会社の石垣島予約サイトは企画未確定の状態から4ヶ月で初期開発を完了しています。一方デメリットとして、発注量が少ない月でも月額固定費が発生するため、アイドルタイムが割高になります。立ち上げには数ヶ月の慣熟期間が必要で、発注側にもプロダクトマネジメント力が強く求められます。
仕様が明確で短期で終わる案件は請負のほうが適しており、逆に運用保守・継続改善が前提の自社プロダクトや、仕様変更が前提の新規事業ではラボ型が圧倒的に有利です。「動くものを早く出して育てる」フェーズの長いプロダクトほど、ラボ型に向いていると言えます。
ラボ型契約の進め方｜契約締結からキックオフまで
請負と違い、ラボ型では契約を結んだ時点が出発点になります。契約後の運用設計とExit設計が成功率を左右するため、契約締結からキックオフまでの工程を順番に見ていきます。
ラボ型契約の進め方は、スコープの仮設定、ベンダー選定、条件交渉と契約締結の順に始まります。そのあとチーム編成とキックオフに進み、定常運用を経て、Exit戦略の実行へと至ります。
初期スコープ設計とスモールスタート
最初のステップは、初期スコープの仮設定です。ラボ型は仕様変更を許容する代わりに、「何を作るチームなのか」というプロダクトミッションを明確にしておく必要があります。プロダクトのコアバリュー、向こう半年で達成したい主要マイルストーン、想定ユーザーや業務シナリオを言語化したうえで、必要なスキルセット（フロント／バック／インフラ／QAなど）と人数を仮置きします。
最初から大人数で立ち上げると、慣熟期間中にコストだけが膨らみます。そのため、1〜3名規模で開始し、品質と相性を確認しながら段階的に増員するスモールスタートが推奨されます。完璧な体制を最初から組まず、走りながら整える前提でスコープを置くことが成功の鍵です。
PMは0.3人月程度のシェアード稼働で確保するモデルも有効です。一方、専任PMをフルアサインすると月100万円規模ですが、複数案件を兼任するシェアードPMなら月30万円前後で同等の管理品質が得られます。小売A社では、ラボ型でMVPを開発しつつ、仕様が固まった機能から請負契約に切り替える「段階発注」を行い、予算超過を防ぎながら本番ローンチに到達しています。
ベンダー選定と契約条項の落とし穴
ベンダー選定では、技術スキルだけでなく、エース人材を継続的にアサインしてくれるかと、離職率はどの程度かを確認することが重要です。業界平均の離職率は14%ですが、フォーサイトシステム社のように4-5%の高い定着率を維持する企業もあります。離職率が低ければ、知見が蓄積され、ラボの生産性も右肩上がりに伸びていきます。
提案書や面談では、「具体的に誰がアサインされるのか」を必ず開示してもらい、可能なら稼働前にコアメンバーと一対一で面談する場を設けてください。契約条項で見落とされがちなのは、(1)エンジニア交代要求の条件、(2)成果物の著作権帰属、(3)秘密保持と競合避止の範囲です。ほかに、(4)解約予告期間と(5)Exit時の引継ぎ範囲も欠かせません。
特に解約予告期間が90日と長いと、撤退判断後も3ヶ月分の固定費が発生してしまいます。一般的には30〜60日が落としどころで、重大な品質問題がある場合は予告期間を短縮できる例外条項も盛り込んでおけます。著作権は原則として発注者に帰属させ、ソースコードと設計書のリポジトリ管理権限を確保しておくことが、後述するExit戦略の前提になります。
キックオフとチーム編成のコツ
ラボ型は「人月単価×人数」で動くため、メンバー構成の妥当性が生産性に直接効きます。一般的には、PM、テックリード（シニア）、プログラマー2〜3名、QAという構成が小規模スタートの標準形です。また、3拠点連携（東京PM＋北海道React＋九州モバイル）で8ヶ月80人月の案件を完遂したニアショア事例のように、機能領域ごとに地域を分けて組むパターンも実用的です。
キックオフでは、プロダクトミッションとKPIをチームで共有します。そのうえで、コミュニケーションルールや定例MTG、緊急時の連絡経路を一度に決めておきます。Jira/Backlogの設定、Git/GitHubのブランチ戦略とPRレビュールール、Slackチャンネル構成、デイリースクラムの開催時刻と参加者まで合意してから、稼働を始めるのが理想です。
フェーズが進んだらUI/UXデザイナーやDevOpsエンジニアを追加し、運用フェーズに入ったらQA比率を上げるというように、構成は時系列で変化させていきます。なお、立ち上げ後1ヶ月は「慣熟期間」と割り切り、生産性ではなくドメイン理解の深さで進捗を測ることをおすすめします。
運用フェーズの進め方｜定量KPIとマネジメント体制
ラボ型開発で最も差がつくのは、契約後の運用フェーズの進め方です。準委任契約は成果物の完成責任を負わない契約のため、評価軸を決めておかないと、「稼働はしているのに前に進まない」状態に陥りがちです。そこで、定量KPIの設計、発注側のマネジメント体制、アイドルタイム対策とエース確保の三つを順に見ていきます。
準委任契約の評価指標｜ベロシティ・バグ率・リードタイム
準委任契約では成果物の完成責任は問えませんが、稼働の質を測るKPIは契約書か運用合意書に明記できます。代表的な指標は次の三つです。(1)ベロシティ：1スプリント（1〜2週間）で完了するストーリーポイントの平均値で、直近4スプリントの中央値が「期待値の±20%以内」に収まっているかを見ます。
(2)バグ発生率：機能リリース後30日以内に発生する不具合の本数を、リリースされた機能数または変更行数で正規化した指標です。(3)リードタイム：チケット起票からプルリクエストマージまでの平均日数で、一般的に5営業日以内が健全な目安です。
これら三指標は月次レビューで定点観測します。たとえば、ベロシティが期待値の70%を3スプリント連続で下回ったらアラートを出すといった閾値を運用合意書に書いておくと、低パフォーマンス時のエンジニア交代要求の根拠になります。準委任契約は「結果を保証しない」契約ですが、運用合意のレベルでは結果を測れるため、この設計を最初に握れているかが、ラボ型運用の成否を分けます。
発注側マネジメント体制の作り方
ラボ型は、発注側のマネジメント力が品質を大きく左右します。最低限、プロダクトオーナー（PO）を1名アサインし、要件の優先順位付け、受け入れ基準（Acceptance Criteria）の言語化、リリース判断を担当させる必要があります。また、POの稼働は最低でも週20時間（0.5人月）が目安で、これを下回るとチームが意思決定待ちで止まりがちです。
POは事業部門から選任し、技術側にはテックリードもしくはエンジニアリングマネージャーを別途置く二頭体制が現実解になります。そのうえで、チケット管理はJiraまたはBacklogでEpic／Story／Taskの階層を明確にし、各スプリント開始時にバックログリファインメントを実施します。
また、デイリースクラムは15分以内に固定し、「昨日やったこと／今日やること／障害」の3点に絞ります。週次でスプリントレビューとレトロスペクティブを開き、月次で経営層向けレポートを発行する階層的なリズムを最初に組んでおくと、運用が安定します。たとえば、ミニストップの基幹システム入替では、テスト・改修工程にラボ型を組み込み、本番移行までスケジュール通りに到達しています。
アイドルタイム対策とエース確保策
ラボ型は月額固定費の契約のため、開発要件が一時的に減ったときの「アイドルタイム」が割高化の主犯になります。そこで、空き時間を技術的負債の解消、自動テストの拡充、ドキュメント整備などに振り向けるルールを最初に決めておけば、稼働率と価値の両方を維持できます。振り向け先には、CI/CDパイプラインの強化や内部勉強会も含められます。
合同会社STUの北海道ニアショア事例では、空き時間を活用したパフォーマンスチューニングで、ECサイトのレスポンスを3倍に高速化しました。アイドル時間を「投資の機会」に変える文化づくりが鍵です。もう一つの論点は、ベンダー側もエース人材は希少なので複数の案件を見比べて配置を決めている中で、継続的にアサインしてもらう工夫です。
そのため、発注側として「意思決定スピードが速い」「技術的に魅力のある課題がある」「ベンダー社員にも学びがある」と感じてもらえる関係を築くことが、結果的にアサイン品質を底上げします。また、半期ごとにベンダー側マネジメントと面談し、現場メンバーへの感謝とフィードバックを直接伝えるだけでも、定着率と意欲は大きく変わります。
費用構造とTCO（隠れコスト込み）の見方
ラボ型契約の費用は、表面上の人月単価だけで判断すると、後でほぼ確実に誤算が出ます。実際に支払うコストは、ブリッジSEの稼働費や渡航費、撤退時の引継ぎコストなどを含めた総所有コスト（TCO）で評価する必要があります。
TCOを比べるときは、「年間人月単価×12ヶ月×人数＋隠れコスト合計」の一つの数式で、国内ニアショア・国外オフショア・首都圏内製の三つを横並びにすると、意思決定が一気に楽になります。
単価相場｜首都圏・ニアショア・オフショアの比較
東京の人月単価は、およそ100〜150万円が一般的なレンジで、PMクラスでは月150万円を超える例も少なくありません。国内ニアショア（北海道・沖縄・九州）は、ここから5〜30%低減し、月70〜130万円程度に収まります。具体的には、プログラマーで月52.8〜63.5万円、シニアエンジニアで月68〜75.2万円、PMで月85〜104万円というレンジが目安です。
ベトナムオフショアは国内の30〜50%程度で、プログラマー30〜40万円、シニア40〜60万円が目安です。ブリッジSEは59〜88万円、PMは70〜160万円で、インドネシアはさらに低く、プログラマー20〜30万円という水準も見られます。また、ベトナムIT人材は50万人超、AI関連は8.5万人（2023年比340%増）に拡大しており、最先端領域では国内より調達しやすいケースもあります。
円安の局面では、汎用的なWeb開発はニアショアが価格でもオフショアと拮抗しやすくなっています。一方、AIやブロックチェーンといった先端領域では、人材プールの厚みからオフショアが優位になるという逆転現象も起きています。国内と海外の比較は、単価だけでなく、円相場と人材プールの特性を踏まえて行う必要があります。
隠れコスト一覧とTCO計算の考え方
ラボ型のTCOで見落とされがちな隠れコストとして、オフショアでは必須のブリッジSE稼働費（PM相当の単価）があります。このほか、通訳や翻訳費、年に数回必要となる渡航費（往復と滞在で1回30〜50万円）も見ておく必要があります。また、コミュニケーションロスによる手戻りコストや、立ち上げ期の慣熟期間中のスループット低下分も見逃せません。
さらに、セキュリティ対策費（VPN、端末管理、SOC2やISMSなどの認証維持費）と、Exit時のドキュメント整備コストも加わります。これらを年間ベースで積み上げると、表面の人月単価の20〜40%増しになるケースが珍しくありません。
たとえば、東京単価で計算すると「130万円×6名×12ヶ月＝9,360万円」です。一方、ベトナムでは「ベトナム単価60万円×6名×12ヶ月＋ブリッジSE 90万円×12ヶ月＋渡航費年200万円＋セキュリティ年300万円＝5,720万円」となり、隠れコストを明示することで比較がフェアになります。単価だけの議論はやめ、TCOで判断する文化を社内に持ち込みましょう。
Exit戦略｜B-O-T方式と内製化への移行プロセス
ラボ型契約で語られることは少ないものの、最も重要なのがExit戦略です。ラボ型は便利な反面、ベンダーへの依存度が時間とともに高まり、いざ内製化したいときに引継ぎが事実上できない、という状況に陥りがちです。
そのため、契約開始の時点でExitの条件を決めておくことが、ベンダーロックインを避ける唯一の方法と言えます。
B-O-T方式の実装ステップ
B-O-T方式（Build-Operate-Transfer）は、ベンダーがラボを構築・運営し、最終的に発注者へ移管するモデルです。ラボは、立ち上げ、運用、移管の順に進みます。
- Build：ベンダー主導でのチーム編成・採用・拠点立ち上げ
- Operate：安定運用の達成
- Transfer：人員ごと発注者の子会社や直接雇用への移管
実際に、富士フイルムヘルスケアとFPTの15年170名規模のラボも、長期で運営するうちに事実上のB-O-T的な展開をたどっています。
契約時にTransferの条件（年限・移管対価・対象人員）を握っておくと、Exitの可能性が一気に上がります。ただし、B-O-Tを取らない場合でも、契約終了時の引継ぎを前提に動くことが重要です。そのためには、コードの置き場所、ドキュメント、権限、知識の移し替えを、それぞれ発注者が手元で扱える形にしておく必要があります。
- コードリポジトリ：発注者のGitHub/GitLab Organization配下での管理
- 設計書・運用マニュアル・障害対応手順：Confluence等での常時更新
- アクセス権限と各種SaaSの管理者：発注者側での保持
- ナレッジ移管セッション：四半期に1回の開催
これらを「契約終了直前にまとめてやる」のは現実的に不可能で、平時から整備し続けるしかないテーマです。
内製化移行と請負への切替パターン
Exitの選択肢は、内製化だけではありません。仕様が固まったプロダクトであれば、ラボ型から請負契約や保守運用契約へ切り替える方法も有効です。たとえば、小売A社の段階発注では、ラボ型でMVPを開発しつつ、仕様が固まった機能から請負化することで、予算超過を防ぎながら本番ローンチに到達しました。
FLINTERSのように「ラボ型／ソリューション型／コンサル型」の三つの契約モデルを使い分けるベンダーであれば、フェーズに応じた切替をそのまま提案できます。一方、内製化を選ぶ場合は、ラボメンバーの一部を直接雇用する、もしくは社内エンジニアと半年間並走させてからベンダー稼働を縮小する「ペアプロ移管」が現実的です。
いきなりベンダーを切り離すと知見断絶のリスクが大きいため、3〜6ヶ月の重複期間を予算化しておくのが安全です。Exitを「次の体制への移行」と捉え、ベンダーにもメリットのある形（移管対価や継続保守契約など）で着地させると、関係を悪化させずに切り替えられます。
生成AI時代のラボ型存続戦略
GitHub Copilot、Cursor、Claude Codeなどの生成AIツールの普及により、単純なコーディングの工数は急速に減りつつあります。そのため、ラボ型のように人月課金で固定費を払うモデルは「割高では？」と問われる時代に入りました。それでも、ラボ型が存続する理由を明確にしておかないと、社内稟議でも通らなくなります。
求められるスキルセットの変化
生成AI時代のラボ型に求められるスキルは、「コードを書く速さ」から「AIを使いこなしてプロダクトを設計・統合する力」へと明確にシフトしています。具体的には、プロンプトエンジニアリング、LLM連携アーキテクチャの設計、RAG（検索拡張生成）の実装が挙げられます。さらに、AIが生成したコードのレビューと品質担保、AIエージェントの組み込み、ベクトルデータベース運用も含まれます。
発注時のスキル要件にこれらを盛り込めるかどうかで、ラボ型の費用対効果は大きく変わります。同時に、人間にしかできない領域の比重も上がります。業務ドメインの深い理解、ステークホルダー調整、UX設計は、AIだけでは到底完結しません。
加えて、セキュリティ・コンプライアンス対応や技術的負債の判断も、AIだけで進めるのは難しい領域です。ラボ型は「同じチームが長く関与する」という構造的優位を持つため、こうした「AIに置き換えられない領域」に強い人材を抱え込めれば、むしろ価値はこれまで以上に高まります。
新しい契約形態と価格モデル
生成AI時代のラボ型では、純粋な人月課金から「アウトプット連動型」への移行も視野に入ります。たとえば、機能リリース数やストーリーポイント、運用安定性などをKPIに組み込み、人月単価＋成果ボーナスのハイブリッド構造にする方法があります。完全な成果報酬は準委任契約の趣旨から外れますが、人月固定費＋達成度に応じた変動報酬の組み合わせは現実的に運用できます。
ベンダーにも「効率化すれば儲かる」インセンティブが働くため、AIツールの積極的な導入が進みます。また、ラボ規模そのものを縮小し「少数精鋭＋AIツール」で同じアウトプットを出す方向も、主流になりつつあります。
実際に、これまで5名で行っていた開発を、3名＋Copilot/Claude Codeなどの活用で同等以上のスループットに置き換える例も増えています。ラボ型は、人数で稼ぐモデルから「人材の質×AI活用度」で稼ぐモデルへ進化する局面に入ったと理解しておきましょう。
まとめ
ラボ型契約は、準委任契約のもとで専属チームを長期確保する開発体制で、仕様変更が頻発する新規事業や、継続的な改善が必要な自社プロダクトと相性の良いモデルです。契約締結からチーム編成、運用、Exitまでを、進め方の手順に沿って見てきました。
押さえるべき論点は多岐にわたります。スモールスタートと定量KPI設計、ブリッジSEや渡航費まで含めたTCO評価、B-O-T方式や請負切替を含むExit戦略、生成AI時代の存続戦略がそれにあたります。
富士フイルムヘルスケアの15年170名規模のラボや、小売A社の段階発注、ミニストップの基幹システム入替は、実際に成果を出してきた事例です。LeaLea合同会社の4ヶ月での初期開発や、合同会社STUのレスポンス3倍高速化からも学べることは多くあります。
共通するのは、最初に「ミッション・KPI・Exit条件」を握り、運用フェーズで定量的に改善し続け、フェーズ変化に応じて契約形態を切り替えていく柔軟さです。円安と生成AIという二つの大きな環境変化のなかで、自社のプロダクトフェーズに合ったラボ型契約の使い方を設計し、外部リソースを最大限活かしてください。
開発を相談する前に、Webサービス開発の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。