ラボ型開発（ラボ契約・ODC）の外注は、外注前の判断から発注後の管理まで、順を追って進めます。
社内のエンジニアが足りなくても中長期の開発を続けられるのが利点ですが、請負開発とは契約も進め方も異なるため、準備不足は想定外のトラブルにつながります。全体像は、次のガイドで確認できます。
▼全体ガイドの記事
・ラボ型開発の完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
ラボ型開発を外注する前の基礎知識
ラボ型開発は、専属のチームを中長期で確保できる一方、請負開発と比べて発注側の関与やマネジメントが求められます。そこで、まずは外注が適する案件かを見極め、発注先の種類と契約形態を把握しておきましょう。
外注が向くケースと内製・請負が向くケース
外注と内製・請負のどちらが合うかは、案件の性質によって変わります。
- 外注が適する条件：中長期の継続開発や仕様変更が見込まれる場合
- 内製・請負が適する条件：単発開発や要件・納期が明確な場合
ラボ型開発は、中長期にわたって機能改善や改修を続けるWebサービス・アプリに向いています。アジャイルでプロダクトを育てる場合や、開発中に方向性を調整したい場合にも合います。
国内でエンジニアを採用しにくい場合は、オフショア（海外）を活用して、コストを抑えつつ人材を確保する方法もあります。
単発の案件では、完成責任を負う請負のほうが管理しやすく、費用も見通しやすくなります。
内製なら社内に知見を蓄積しやすく、機密情報も管理しやすいでしょう。案件の性質に合わせて手法を選ぶことが大切です。
発注先の種類と特徴
発注先は拠点によって費用や意思疎通のしやすさが変わり、SESとラボ型では、チームの継続性も違います。
- 発注先の種類：国内・オフショア・ニアショアの違い
- 発注形態の違い：SESとラボ型開発の特徴の比較
ラボ型開発の発注先は大きく「国内ベンダー」「オフショアベンダー（海外）」「ニアショアベンダー（地方）」の3種類に分けられます。国内ベンダーは意思疎通や品質管理がしやすい反面、人件費が高く、人材確保にも課題があります。エンジニア1名あたりの相場は、月50万〜100万円程度です。
オフショアベンダーは、ベトナム・フィリピン・インドなどに拠点を置いており、コストは国内比30〜50%程度まで抑えられる場合があります。ただし、言語・文化・時差の壁があるため、専任のブリッジSE（ブリッジエンジニア）を介した連絡体制が不可欠です。
ニアショアベンダーは、北海道・東北・九州などの地方拠点で開発を行う企業です。国内での開発ながら、コストを抑えられる点が魅力です。
発注形態では、SES（システムエンジニアリングサービス）とラボ型開発の違いも押さえておく必要があります。SESは特定のエンジニア個人を派遣する形態のため、開発生産性を継続的に高めることは期待しにくい面があります。一方、ラボ型開発は案件専用のチームとして複数のエンジニアが一体となって動くため、学習効果や品質向上が見込めます。
発注する側は、地域だけでなく、必要な連携やチームの継続性も踏まえて、自社に合う発注形態を選びます。
ラボ型開発の発注・外注の具体的な手順
ラボ型開発を円滑に外注するには、見積もりを急ぐ前に要件を整えることが欠かせません。準備が足りないまま見積もりを取ると、発注先との認識がずれやすく、後のトラブルにつながりかねません。要件整理から契約まで、順を追って進めます。
要件整理とRFP作成
RFPを作る前に、必要なエンジニア人数、使用したい言語・フレームワーク、契約期間、予算を文書にしておくと、複数社へ同じ前提を伝えられます。
- 開発ニーズの整理：目的・チーム規模・技術スタック・期間・予算を、RFPの前提として具体化する。
- RFPの作成：背景・目的・技術要件・体制・期間・費用感を盛り込んだ文書を作る。
RFP（Request for Proposal：提案依頼書）は、発注先へ開発の背景や希望する進め方を共有する文書です。希望するチーム体制や連絡頻度も含めて書くと、開発会社は自社に合う提案を組み立てられます。
要件が曖昧なままだと、複数社の提案を同じ基準で比べにくくなります。RFPの前提が具体的なほど、開発会社の提案も自社のニーズに沿いやすくなります。反対に、曖昧なRFPでは価格だけの比較に偏り、自社に合わない会社を選ぶおそれがあります。
未確定の仕様は、変更の余地があると明記し、現時点の方向性も伝えておきます。そうすれば、より現実的な提案を受けられます。
発注先の選定と比較
候補会社は、価格だけでなく、同じ基準で比べることが大切です。
- 候補会社の選定：複数社へ提案を依頼し、候補を絞り込む。
- 比較の視点：技術力、実績、体制、費用の透明性
RFPが完成したら、目安として3〜5社に提案を依頼します。発注側は、ビジネスマッチングサービス（発注ナビ・リカイゼンなど）、知人・取引先からの紹介、各種SEO記事や比較サイトを使って発注先を探せます。
候補が絞れたら、提案書と見積書を同じ観点で比べます。技術スタックに合う開発経験があるか、同業種や類似案件での実績があるかも確認します。
また、日本語で連絡できるか、専任PM（プロジェクトマネージャー）やブリッジSEがいるかも比べます。特にオフショアでは、ブリッジSEの日本語力と技術力が連携の質を左右します。
チームの安定性を見るため、離職率や平均勤続年数も確認します。さらに、月額費用に含まれる工数・稼働時間と、追加費用が発生する条件を確かめます。最後に面談を設定し、担当者の対応力や誠実さも含めて総合的に判断します。
ラボ型開発の契約時に押さえるべきポイント
発注先が決まったら、契約の段階に進みます。ラボ型開発の契約は準委任契約を基本とするケースが多く、請負契約とは責任の範囲や費用の発生タイミングが異なります。
「なんとなく口頭で合意して進めてしまった」という状態は、後々の紛争リスクを高めます。契約書に条件を書き残しておくことが欠かせません。
契約形態の選び方
仕様の変化に対応したいのか、決まった成果物を完成させたいのかによって、契約形態を選びます。
- 準委任契約の適性：仕様の流動性や開発期間に応じた向き不向き
- 契約形態の組み合わせ：成果物が明確な開発で、請負契約を取り入れる方法
ラボ型開発の契約形態として最も一般的なのが準委任契約です。準委任契約では、ベンダーは「善管注意義務（善良な管理者の注意義務）」を負いますが、成果物の完成は保証されません。
つまり、プロジェクトが途中で頓挫した場合でも、発注側は作業した分の費用を支払う必要があります。この点は、完成責任を負う請負契約との最大の違いです。
準委任契約が向いているのは、仕様が流動的でアジャイル開発を行うケース、長期継続開発でチームを固定したいケースなどです。
一方、成果物を明確に定義できる開発フェーズ（例：初期バージョンのリリース）では、請負契約を部分的に組み合わせるハイブリッド型も有効な選択肢です。
最近は、まず3〜6か月の試用期間を請負契約で始め、信頼関係を築いてからラボ型（準委任）へ移るアプローチも広まっています。いきなり長期のラボ型契約を結ぶより、段階的に関係を深めるほうが、双方にとってリスクを抑えられます。
契約書で確認すべき重要条項
契約書では、後から争いになりやすい条件を、あらかじめ確認しておく必要があります。
- 知的財産権の帰属：成果物・ソースコード・設計書などの権利関係
- 秘密保持・費用・解除条件：NDA・稼働時間・追加費用・解除通知期間など
ラボ型開発の契約書では、知的財産権の帰属を特に丁寧に確認する必要があります。開発した成果物の著作権が発注者側に帰属するよう、契約書に明記しておきます。
なお、著作権法27条・28条に定められる翻案権・二次的著作物利用権は、条文で特掲しなければ譲渡対象外と推定されます。契約書をレビューする際は、弁護士に確認してもらうことをおすすめします。
秘密保持（NDA）では、自社の機密情報が外部に漏れないよう、対策を契約で定めます。顧客データやビジネスロジック、設計資料などを対象に、秘密保持契約を別途結ぶか、契約書内に秘密保持条項を明記します。情報が漏洩した場合の報告義務や損害賠償の範囲も、明確にしておく必要があります。
月額費用に含まれる稼働時間（例：月160時間）と、超過した場合の追加費用の計算方法を確かめます。稼働の報告方法は、タイムトラッキングツールを使うかどうかまで確認しておきます。
契約の解除や更新の条件は、事前に詰めておく必要があります。具体的には、解除通知期間（一般的には30〜60日前）、メンバー交代の申請方法と対応期限、契約更新時の価格改定ルールなどが挙げられます。こうした条項が曖昧なままだと、想定外の費用が発生したり、成果物の権利をめぐる問題に発展したりするおそれがあります。
ラボ型開発の発注後のプロジェクト管理
ラボ型開発は、契約を結んだあとも発注側が主体的に関わることが欠かせません。請負型のように「あとはよろしく」と丸投げすると、開発の方向性がずれたり、進捗が見えなくなったりしがちです。発注後の管理では、連絡の体制を整えることと、進捗や品質が分かる状態にしておくことが特に大切です。
コミュニケーション体制の構築
コミュニケーション体制では、連絡の手段と会議の進め方を先に決めておくと、行き違いを抑えられます。
- 連絡手段の整備：SlackやMicrosoft Teamsなどの共通プラットフォームの設定
- 定例と意思決定：週次・日次のミーティングと発注側PMの役割の決定
ラボ型開発では、日常的な連絡の体制が品質を保つうえで大切になります。とりわけオフショア開発では、言語・時差・文化の違いから認識がずれがちです。そのため、発注側の意思決定者も含めて、連絡の進め方を早めに固めておく必要があります。
日次・週次の定例では、作業内容や課題を共有します。週次の定例に加えてデイリースクラムを行う場合は、毎日15〜30分程度を目安に設定します。
オフショアベンダーの場合は、時差を考慮して、双方が参加しやすい時間帯を事前に調整します。たとえばベトナムなら、日本との時差は2時間のため比較的調整しやすく、午前9時台や午後3時台にミーティングを設定するケースが多いです。
発注側は、PMなどの意思決定者を明確にし、開発チームからの質問や確認事項に24時間以内に回答できる体制を整えます。ブリッジSEがいる場合は、日々の情報連携を任せることで、認識のずれを早く把握しやすくなります。
進捗管理と品質保証の方法
進捗管理では、プロジェクト管理ツールの活用が効果的です。そのうえで、コードレビューやテスト基準まで決めておくことで、品質を保てます。
- 進捗の把握：JiraやBacklog、Trelloなどのツールによるタスク管理
- 品質保証の仕組み：コードレビュー、テスト基準、修正対応フローの合意
進捗は、スプリント（2週間単位が一般的）ごとに、完了・進行中・未着手のタスクに分けて確認します。バーンダウンチャートやベロシティ（1スプリントあたりの完了タスク量）を継続的に計測すると、開発のペースを見通せるうえ、将来の予測も立てられます。
稼働時間は、Togglやクロノスなどのタイムトラッキングツールを導入して記録します。月単位の工数レポートを受け取れば、費用対効果の評価にも役立ちます。
コードレビューは、プロジェクト開始前に仕組みを合意しておき、GitHubやGitLabのプルリクエスト機能を使って、発注側のエンジニアかベンダー内の上位エンジニアが行う必須の工程にします。加えて、ユニットテストと結合テストの実施基準（カバレッジ目標など）を文書にし、テスト工程が飛ばされないようにします。
品質の問題が見つかった場合は、修正対応フロー（バグ報告→優先度判定→修正→確認というサイクル）を事前に決めておくと、迅速に対処できます。
発注後3か月を目安に、開発スピード、品質、コミュニケーションの満足度などの観点でパートナーを評価します。必要に応じて体制を見直すことも、成功の秘訣です。
まとめ
ラボ型開発を外注するときは、まず継続開発や仕様変更の有無から適性を判断します。そのうえで、RFPで要件を共有し、発注先を比べます。
中長期の案件やアジャイル開発にはラボ型が向いています。一方、単発で仕様が固まった案件では、請負や内製も選択肢になります。
発注先は、技術力と実績、連絡体制を見て選びます。チームの安定性や、国内・オフショア・ニアショアの違いによる費用や連携面も、あわせて考慮します。
次に、準委任契約の性質を踏まえて、知的財産権と秘密保持を中心に、稼働時間や解除条件も契約書に明記します。契約後は、SlackやJiraなどで進捗と課題を共有しましょう。
運用を始めたあとも、定期的にパートナーを評価し、開発速度や品質、コミュニケーションの状態に応じて体制を見直すことが、継続的な成果につながります。ラボ型開発は正しく活用すれば、社内では確保が難しい専門人材と、スピーディーな開発体制を同時に得られる、強力な手法です。
この記事を参考に、自社に合ったラボ型開発のパートナーを見つけ、開発を前に進めてください。
詳しい全体像は、関連するガイドもあわせてご覧ください。
▼全体ガイドの記事
・ラボ型開発の完全ガイド
RFP作成前に読みたい無料ホワイトペーパーはこちらです。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。