ラボ型契約は、優秀なエンジニアチームを長期間専属で確保できる魅力的な契約形態ですが、いざ発注しようとすると「どこから手をつければよいのか」「どんな準備をすればチームが立ち上がるのか」と戸惑う発注担当者が少なくありません。準委任契約という性質上、成果物に対して対価を支払う請負契約と異なり、発注側のマネジメント力が成果を大きく左右するため、発注プロセスの設計が極めて重要となります。
この記事では、ラボ型契約の発注・外注・委託方法について、POのアサインから初回スコープ設定、シェアードPMの活用、KPI設定、契約条項の落とし穴までを実務目線で解説いたします。さらに、自社マネジメント体制の具体論、ベンダーロックイン対策、ベンダー側の本音とエース確保策、重大バグの責任所在といった、他の解説記事ではあまり触れられない論点まで踏み込んでお伝えします。読み終える頃には、自社で安心して発注できる準備が整うはずです。
ラボ型契約発注の全体像と他契約との違い
ラボ型契約の発注プロセスを理解するためには、まず請負契約やSESとの違いを押さえる必要があります。準委任契約という法的性質を理解せずに発注すると、成果物責任の所在やマネジメント分担の認識ずれが発生し、プロジェクト中盤で大きなトラブルにつながりやすくなります。発注前に契約形態の本質を理解し、自社のマネジメント体制と適合するかを検討することが、成功の第一歩です。
準委任契約としての本質と発注側責任
ラボ型契約は法的には準委任契約に分類され、エンジニアの稼働時間（人月）に対して報酬が支払われる仕組みです。成果物の完成義務を負う請負契約とは異なり、ベンダー側は善管注意義務に基づき業務を遂行する責任を負いますが、特定の機能やシステムの完成を保証するものではありません。この性質を理解せずに「請負と同じ感覚で丸投げ」してしまうと、期待した成果が得られず、責任の押し付け合いが発生します。
発注側に求められるのは、開発の優先順位を決定し、要件を明確にし、進捗を管理する役割です。具体的には、プロダクトオーナー（PO）を自社内に配置し、バックログの管理、スプリント計画への参加、デイリーでの意思決定を担う必要があります。これは請負契約のように「仕様書を渡して納品を待つ」スタイルとは全く異なる発注プロセスとなりますので、社内体制の整備が不可欠です。
請負・SESとの使い分け基準
発注形態を選ぶ際は、仕様の確定度合いと開発の継続性で判断するのが実務的です。仕様が固まっており短期で完結する案件は請負契約が適しており、要件が流動的でアジャイル的に進めたい新規事業はラボ型契約が向いています。SESは特定エンジニアの稼働を確保したいが、自社の指揮命令下で常駐させたい場合に選択されますが、偽装請負リスクや指揮命令系統の整理が課題となります。
実務でよく使われるのが、段階的に契約形態を切り替える方法です。ある小売A社では、新規ECサイトの構築でまずラボ型契約で要件定義とプロトタイプ開発を進め、仕様が確定した段階で請負契約に切り替えることで、予算超過を防ぎながら品質を確保しました。このような柔軟な発注設計ができるのも、ラボ型契約の特徴です。最初の発注時点で「将来どう切り替えるか」まで設計しておくと、無駄なコストを抑えられます。
POアサインと自社マネジメント体制の構築
ラボ型契約で成果を出すには、発注側の自社マネジメント体制が最重要要素となります。多くの企業がここを軽視して「ベンダーに任せれば何とかなる」と発注した結果、チームが方向性を見失い、生産性が大幅に低下する事例が後を絶ちません。自社マネジメント体制を発注前に整備することが、ラボ型契約成功の絶対条件です。
POに必要なスキルセットと人数設計
プロダクトオーナーには、事業理解と技術理解の両方が求められます。具体的には、自社事業の戦略・顧客課題・収益構造を深く理解しており、かつエンジニアと対話できる程度の技術リテラシーを持つ人材が理想です。事業企画出身者であれば技術キャッチアップを行い、エンジニア出身者であれば事業視点を補強するなど、人材像によって育成方針を変える必要があります。
人数設計の目安としては、ラボ型エンジニア5〜6名に対しPOは1名、10名規模になればPO1名に加えてプロダクトマネージャーまたはスクラムマスターを1名追加するのが現実的です。POが片手間で複数プロジェクトを兼務すると、意思決定が遅延し、エンジニアの待ち時間が増えてコストが無駄になります。週20時間以上、できれば専任に近い形で確保できる体制を整えてから発注すべきです。
Jira・Backlog運用ルールの標準化
タスク管理ツールの運用ルールが曖昧だと、ラボチームの生産性は大きく下がります。Jiraを使う場合は、Epic・Story・Sub-taskの3階層を基本構造とし、ストーリーポイントによる見積もり、スプリントごとのベロシティ計測、完了の定義（Definition of Done）を文書化することが重要です。Backlogを使う場合も、カテゴリ・マイルストーン・優先度の設定基準を明確にしておかないと、発注側と受注側で認識がずれていきます。
運用ルールには次の項目を必ず明文化してください。
(1)チケット起票のフォーマット（背景・目的・受入条件を必須化）
(2)ステータス遷移のタイミング（誰がいつ動かすか）
(3)コメント運用ルール（質問は24時間以内に返答）
(4)スプリント期間と振り返りのサイクル
これらを発注前にベンダー候補と擦り合わせ、契約書または運用ガイドラインに明記しておくと、運用開始後の混乱を大幅に減らせます。
デイリースクラム実装の具体的手順
ラボ型開発で生産性を維持するには、デイリースクラム（朝会）の運用が極めて重要です。毎日同じ時刻に15分以内で実施し、各メンバーが「昨日やったこと」「今日やること」「障害となっていること」を共有します。POとスクラムマスターは必ず参加し、障害事項は即座に判断・解消の方針を示します。リモート環境であってもビデオオンを推奨し、表情から温度感を読み取ることでチームの状態を把握できます。
朝会で重要なのは「報告会にしない」ことです。詳細な技術議論は朝会後に関係者だけで実施し、朝会自体は進捗共有と障害発見の場に留めます。週次でスプリントレビューとレトロスペクティブを実施し、ベロシティの変動要因や運用改善点を議論する場を設けると、チームは継続的に改善していきます。発注側のPOが司会進行に慣れていない場合は、最初の数スプリントだけベンダー側のスクラムマスターに進行を依頼し、徐々に巻き取る方法も有効です。
初回スコープ設定とシェアードPM活用
ラボ型契約の発注で最も悩ましいのが、初回のスコープ設定です。要件が完全に固まっていない状態で発注するのがラボ型の特徴ですが、何もないところからスタートするとチームの方向性が定まらず、初月から低稼働になりがちです。スモールスタートとシェアードPMの組み合わせで、リスクを抑えながら立ち上げる方法をご紹介します。
1名1ヶ月からの超スモールスタート
初回発注では、いきなり5名規模で契約するのではなく、エンジニア1名・1ヶ月からのスモールスタートを推奨します。最初の1ヶ月は、開発環境構築、既存システムのキャッチアップ、初期バックログ整備、コミュニケーションルール確立など、立ち上げ作業に充てます。この期間でベンダーの実力や相性を確認できるため、本格稼働前にミスマッチを発見できるメリットがあります。
段階的に増員する具体例として、小売A社のECサイト構築では、1名1ヶ月のPoCフェーズ、3名3ヶ月のMVP開発フェーズ、5名6ヶ月の本格開発フェーズと段階的に拡大しました。各フェーズの終わりに振り返りを実施し、続行か契約形態変更かを判断したことで、最終的に予算超過なく要件確定後は請負契約へスムーズに移行できました。このような段階発注を最初から契約書に盛り込んでおくと、柔軟な発注設計が可能になります。
シェアードPMによるコスト最適化
小規模なラボ型契約では、PMを専任で抱えるとコストが割高になります。そこで活用したいのがシェアードPMの仕組みです。ベンダー側のPMが複数プロジェクトを掛け持ちし、自社プロジェクトには0.3〜0.5人月の稼働で関与する形態で、月額の管理コストを大幅に抑えられます。例えば月単価100万円のPMを0.3人月で確保すれば30万円となり、エンジニア2〜3名規模のプロジェクトでも管理コストの比率を抑えられます。
シェアードPMを活用する際の注意点は、稼働時間と対応範囲を契約で明確にすることです。具体的には「週8時間の定期稼働」「緊急対応は別途精算」「主要会議への必須出席」などを取り決めておくと、稼働実態と請求のズレを防げます。逆に、PMの稼働を見える化しないまま発注すると、関与が薄くなり、エンジニアの質問対応が遅れて生産性が下がる事態を招きやすいので注意してください。
アイドルタイム対策と稼働率最適化
ラボ型契約は固定費型のため、エンジニアに作業を渡せない期間（アイドルタイム）が発生すると、コストが無駄になります。発注時点で「アイドル発生時の代替業務リスト」を準備しておくと、稼働率を80〜90%以上に保てます。代替業務の例としては、技術的負債のリファクタリング、自動テストの追加、ドキュメント整備、社内勉強会用のナレッジ整理、過去機能のパフォーマンス改善などが挙げられます。
具体的な対策として、メインタスクとサブタスクを2:1の比率で常に用意しておき、メインタスクが詰まった時にサブへスムーズに切り替えられる体制を作ります。POは月初にメインタスク3本・サブタスク2本を提示し、スプリント中盤で進捗を確認して追加投入する運用が現実的です。これによりラボの月額固定費が無駄にならず、長期的に技術品質も向上していくという二重のメリットが得られます。
KPI設定とパフォーマンス評価の運用
準委任契約のラボ型では「何で評価するか」が曖昧になりがちです。成果物の納品義務がない以上、ベロシティ・バグ発生率・リードタイムといった定量指標を契約時に合意しておくことが、健全な発注関係を維持する鍵となります。KPIを明示することで、ベンダー側も目指すべき水準が分かり、発注側も低パフォーマンス時に交代要求の根拠を持てます。
ベロシティ・バグ率・リードタイムの設定
代表的なKPIとして、ベロシティ（スプリントあたりの完了ストーリーポイント）、バグ発生率（リリース後30日以内のバグ件数 ÷ 機能数）、リードタイム（チケット起票から本番リリースまでの日数）の3つを設定するのが標準的です。初回3スプリントでベースラインを計測し、4スプリント目以降から「ベロシティ±20%以内」「バグ率5%以下」「リードタイム10日以内」のような目標値を設定します。
注意点としては、KPIだけを追いかけるとベンダーが「数値を作る」行動に走るリスクがあることです。例えばストーリーポイントを意図的に高く見積もる、バグの定義を曖昧にする、軽微な変更を分割してリードタイムを短く見せるなどの対策行動が発生します。これを防ぐには、POが見積もり妥当性を都度レビューし、バグの定義を契約書に明文化し、リードタイムは外形的に計測する仕組みを導入することが重要です。
低パフォーマンス時のエンジニア交代プロセス
KPIが継続的に未達の場合に備え、エンジニア交代の条件と手続きを契約書に明記しておきます。具体的には「3スプリント連続でベロシティ目標未達の場合、発注側は当該エンジニアの交代を要求できる」「交代要求から30日以内に同等スキルの後任を提供する」「立ち上げ期間の追加コストはベンダー負担とする」などを盛り込みます。これにより、口頭でのお願いではなく、契約に基づく正当な要求として進められます。
ただし、エンジニア交代は最終手段です。まずは1on1や振り返りで原因究明を行い、スキルギャップなら学習機会の提供、業務マッチングの問題ならタスク再配分、コミュニケーション課題ならツール改善といった対応を試みます。それでも改善しない場合に限り交代要求を発動する運用にすると、ベンダーとの信頼関係を維持しながら成果を出せます。富士フイルムヘルスケアとFPTの15年170名規模への成長事例は、こうした地道な改善プロセスの積み重ねが背景にあります。
ベンダー側の本音とエース確保策
ここでベンダー側の本音にも触れておきます。受託開発企業のエース級エンジニアは社内でも引く手あまたで、複数の案件オファーから「やりやすい客」を選ぶ傾向があります。発注側が態度の悪い客や、要件を平気で覆す客、PO不在で意思決定が遅い客であれば、エースは敬遠され、二軍三軍のエンジニアがアサインされる現実があります。発注側が「お客様だから何でも言える」という態度では、優秀人材を確保できません。
エースを確保する具体的な策としては、長期契約の確約（最低6ヶ月以上、できれば12ヶ月）、適正な単価（東京基準で100〜150万円/月以上）、明確で挑戦しがいのある技術領域、POの即時意思決定体制、エンジニア個人への直接的なフィードバックと感謝などが挙げられます。発注側が「一緒に良いものを作りたいパートナー」として接するほど、ベンダーは社内最強メンバーをアサインしてくれる傾向があります。これは目に見えにくいですが、成果に直結する重要な要素です。
契約条項の落とし穴と防御策
ラボ型契約では、後々大きな問題に発展しがちな契約条項がいくつか存在します。発注前に法務・調達担当者と確認し、自社にとって不利な条項を見直しておくことが重要です。特に、ベンダーロックイン対策、重大バグの責任所在、知的財産権の帰属、解約条件の4つは必ず確認してください。
ベンダーロックイン対策とExit戦略
ラボ型契約を長期間続けると、ベンダー固有のドキュメント運用や独自フレームワーク採用により、他社への引き継ぎが困難になるベンダーロックインのリスクが高まります。これを防ぐには、契約締結時にドキュメント整備義務を明記することが有効です。具体的には「設計書・運用手順書・API仕様書を四半期ごとに更新」「ソースコードのコメント記述基準の遵守」「主要モジュールのオンボーディング資料整備」などを契約条項に入れます。
さらに踏み込んだExit戦略として、B-O-T方式（Build-Operate-Transfer）の採用も検討してください。これは、最初の2〜3年はベンダーがチームを構築・運用し、最終的に自社へ移管する契約形態です。移管時にはチーム全員を自社雇用するか、別ベンダーへ引き継ぐかを選択できる柔軟性があります。契約書には「移管時の引き継ぎ期間（3ヶ月以上）」「ナレッジ移転の範囲」「移管後の保証期間」を明記しておくと、円滑な移行が実現できます。
重大バグの責任所在の明文化
準委任契約の最大の落とし穴は、本番リリース後の重大バグ発生時に責任の所在が曖昧になることです。請負契約と違い「成果物の瑕疵」という概念が薄いため、誰がどこまで責任を負うかを契約で定義しないと、トラブル時に大きな揉めごとに発展します。具体的には、データ消失、個人情報漏洩、サービス長時間停止などの重大事象について、ベンダー側の善管注意義務違反が認められる場合の損害賠償上限と、賠償対象範囲を明記しておきます。
実務的には「直接損害に限定し、逸失利益・間接損害は対象外」「賠償上限は当月支払い額または直近3ヶ月支払い額」とするケースが多いですが、これでは発注側のリスクが大きすぎる場合があります。重要システムを扱う場合は、サイバー保険の付保義務、第三者によるセキュリティ監査の実施、重大インシデント発生時の無償対応期間（48〜72時間）など、追加条項で守りを固めるのが賢明です。これらは契約締結前に必ず法務と相談して詰めてください。
知的財産権と解約条件の確認
ソースコードや設計書の知的財産権が誰に帰属するかは、契約終了後の自由度を大きく左右します。デフォルトでは発注側に帰属させるのが望ましいですが、ベンダーが汎用フレームワークやライブラリを再利用する場合は、その部分はベンダー帰属とする折衷案が現実的です。重要なのは「成果物のうち、発注側専用に開発したカスタム部分は発注側帰属」「汎用部分はベンダー帰属だが、発注側に永続使用権を付与」のように明確に切り分けることです。
解約条件も見落とされがちです。一般的には30日前または60日前の事前通知で解約可能とするのが標準ですが、ベンダー側の業績悪化や倒産時の対応も契約に入れておくべきです。具体的には「ベンダーが民事再生・破産手続きを開始した場合、発注側は即時解約権を有する」「解約時はソースコード一式・ドキュメント一式を5営業日以内に引き渡す」などを明記します。こうした条項は普段は使わないかもしれませんが、いざという時の自社の選択肢を確保するために必須です。
まとめ
ラボ型契約の発注を成功させるには、契約形態の本質理解、自社マネジメント体制の構築、初回スコープ設定、KPI運用、契約条項の整備という5つの柱を順に固めていくことが重要です。特に、PO配置・Jira運用ルール・デイリースクラム実装といった自社マネジメント体制は、発注前から準備を始めるべき要素であり、ここを軽視するとどんなに優秀なベンダーを選んでも成果は出ません。
さらに、ベンダーロックイン対策としてのドキュメント整備義務とB-O-T方式の導入、重大バグの責任所在の明文化、エース確保のための長期契約と適正単価といった、他では語られない実務ポイントを契約段階で押さえておくと、長期にわたって安定した開発体制を維持できます。1名1ヶ月の超スモールスタートから始め、段階的に拡大しながら、KPIに基づく定量評価で品質を担保する流れが、現実的かつ低リスクな発注プロセスです。本記事を参考に、自社に合った発注設計を進めていただければ幸いです。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。