ラボ型契約は準委任契約のため、請負契約と違って成果を左右するのは発注側のマネジメント力です。そのため、発注の進め方は自社の体制を整えるところから組み立てます。
大きな流れは5つの段階に分けられます。段階ごとに何を決めるかを押さえると、立ち上げ時の戸惑いを減らせます。
- 契約形態の本質と、発注側の責任範囲の確認
- POの配置と、自社マネジメント体制の整備
- 初回スコープと、シェアードPMの活用方法の決定
- KPIの設定と、パフォーマンス評価の運用ルールの決定
- ロックイン対策、責任所在、知財、解約条件の契約への明記
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
ラボ型契約発注の全体像と他契約との違い
ラボ型契約の発注を進めるには、まず請負契約や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は、ベロシティ、バグ発生率、リードタイムの3つで、これらを設定するのが標準的です。ベロシティは「スプリントあたりの完了ストーリーポイント」、バグ発生率は「リリース後30日以内のバグ件数 ÷ 機能数」、リードタイムは「チケット起票から本番リリースまでの日数」として定義します。
初回3スプリントでベースラインを計測し、4スプリント目以降から「ベロシティ±20%以内」「バグ率5%以下」「リードタイム10日以内」のような目標値を設定します。ただし、KPIだけを追いかけると、ベンダーが「数値を作る」行動に走るリスクがあります。
たとえば、ストーリーポイントを意図的に高く見積もる、バグの定義を曖昧にする、軽微な変更を分割してリードタイムを短く見せるといった行動が起きます。これを防ぐには、POが見積もりの妥当性を都度レビューし、バグの定義を契約書に明文化し、リードタイムを外形的に計測する仕組みを導入することが大切です。
低パフォーマンス時のエンジニア交代プロセス
KPIが継続的に未達の場合に備え、エンジニア交代の条件と手続きを契約書に明記しておきます。具体的には、「3スプリント連続でベロシティ目標未達の場合、発注側は当該エンジニアの交代を要求できる」と定めます。さらに、「交代要求から30日以内に同等スキルの後任を提供する」「立ち上げ期間の追加コストはベンダー負担とする」などを盛り込みます。
これにより、口頭でのお願いではなく、契約に基づく正当な要求として進められます。ただし、エンジニア交代は最終手段です。まずは1on1や振り返りで原因究明を行い、スキルギャップなら学習機会の提供、業務マッチングの問題ならタスク再配分、コミュニケーション課題ならツール改善といった対応を試みます。
それでも改善しない場合に限り交代要求を発動する運用にすると、ベンダーとの信頼関係を維持しながら成果を出せます。また、富士フイルムヘルスケアとFPTの、15年で170名規模に成長した事例にも、こうした地道な改善プロセスの積み重ねが背景にあります。
ベンダー側の本音とエース確保策
受託開発企業のエース級エンジニアは社内でも引く手あまたで、複数の案件から「やりやすい客」を選ぶ傾向があります。発注側が態度の悪い客や、要件を平気で覆す客、PO不在で意思決定が遅い客であれば、エースは敬遠され、二軍三軍のエンジニアがアサインされる現実があります。また、「お客様だから何でも言える」という態度では、優秀な人材を確保できません。
エースを確保する具体策としては、長期契約の確約（最低6ヶ月以上、できれば12ヶ月）と、適正な単価（東京基準で100〜150万円/月以上）があります。さらに、明確で挑戦しがいのある技術領域、POの即時意思決定体制、エンジニア個人への直接的なフィードバックと感謝などが挙げられます。
発注側が「一緒に良いものを作りたいパートナー」として接するほど、ベンダーは社内最強メンバーをアサインしてくれる傾向があります。これは目に見えにくい一方で、成果に直結する要素です。
契約条項の落とし穴と防御策
ラボ型契約には、後々大きな問題に発展しがちな契約条項がいくつかあります。発注前に法務・調達の担当者と確認し、自社にとって不利な条項を見直しておくことが大切です。
特に確認が欠かせないのは、ベンダーロックイン対策と重大バグの責任所在です。ほかに、知的財産権の帰属と解約条件も、必ず押さえておく必要があります。
ベンダーロックイン対策と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に基づく定量評価で品質を担保する流れが、現実的かつ低リスクな発注プロセスです。自社に合った発注設計を進める際の参考にしてください。
▼RFP作成前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・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を創業。