「ラボ型契約を結びたいが、RFP（提案依頼書）や要件定義書に、契約条件まで書いておくべきなのか」「準委任という契約形態を前提に、稼働体制や費用上限、知財をどう発注時点で提示すればよいのか」とお悩みではないでしょうか。ラボ型開発は、専属の開発チームを一定期間確保し、稼働時間に対して対価を払う準委任契約が基本です。そのため、機能仕様を固めることよりも、どんな契約条件で体制を組むのかを発注側が先に提示できるかどうかが、後の契約交渉とプロジェクトの成否を大きく左右します。
この記事では、ラボ型”契約”を結ぶ前段階のRFP・要件定義を、システムの開発要件ではなく「契約条件の提示」という観点から解説します。RFPに準委任という契約形態、稼働体制、メンバー交代基準、費用上限、知財条件をどう明記するか、そして契約交渉を有利に進めるためのRFPの作り方と、提示された契約書を点検するための契約条件チェックリストを、単価相場や市場統計などの一次データを交えて具体的にまとめました。フルスクラッチ受託と国内ラボ型開発の両方を手がける株式会社riplaの実務視点から、そのまま使える内容にしています。最後まで読めば、契約交渉で後手に回らないRFPを自分で組み立てられるようになります。なお、全体像はラボ型開発の完全ガイドでも解説しています。
結論：RFPには「契約条件5点」を発注側から先に提示する
先に結論をお伝えします。ラボ型契約のRFP・要件定義書では、システムの機能要件以上に、次の5つの契約条件を発注側から先に提示しておくことが重要です。これらを空欄にしたまま提案を募ると、各社が自社に有利な前提で見積もり、後の契約交渉で発注側が不利になります。
(1) 契約形態：準委任を前提とし、完成責任を負わせない代わりに何を求めるかを提示する
(2) 稼働体制：人数・職種構成・稼働の下限上限・コミュニケーション体制を提示する
(3) 交代基準：スキル不足や離脱時のメンバー交代の要件と費用負担を提示する
(4) 費用上限：月額の上限、超過時の扱い、稼働率の前提を提示する
(5) 知財条件：成果物・ソースコードの権利帰属と再利用の可否を提示する
RFPは「やってほしいことを並べる書類」ではなく、「どんな契約条件で組みたいかを宣言し、その条件を満たせる相手を選ぶ書類」です。とくにラボ型契約は完成物ではなく稼働を買う形態のため、機能の細かさよりも、稼働と費用と権利をどう取り決めるかが本質になります。以下では、この5点をRFPにどう書き込み、契約交渉につなげるかを順に解説します。
RFPに契約形態（準委任）をどう明記するか
ラボ型契約のRFPで最初に提示すべきは、契約形態です。ラボ型開発は、成果物の完成を約束する請負契約ではなく、稼働時間に対して対価を払う準委任契約に該当します。この前提をRFPの冒頭で明示しておかないと、各社が請負前提で完成物の見積もりを出してきたり、逆に稼働だけ確保して品質を一切担保しない提案が混ざったりして、提案の比較ができなくなります。
準委任を前提とし、求める品質水準をセットで提示する
RFPには「本件は準委任契約を前提とする」と明記したうえで、完成責任を負わせない代わりに何を求めるのかをセットで書きます。準委任では、受託側は仕事の完成ではなく、善良な管理者の注意をもって業務を遂行する善管注意義務を負います。つまり「バグがゼロであること」を契約上は約束させられません。だからこそ、求める品質の水準をRFPで定義しておく必要があります。
具体的には、レビュー体制の有無、テストカバレッジの目標値、重大障害が起きた際の対応時間、バグ修正をどこまで稼働内で行うかの分界点などを、求める条件として提示します。これらをRFP段階で示しておくと、各社は同じ品質前提で稼働見積もりを出すため、提案の比較が容易になり、契約書の品質条項を協議する際もRFPの記載が起点になります。
請負・SESとの違いをRFPで誤解させない書き方
請負契約は成果物の完成と契約不適合責任を伴い、SES（システムエンジニアリングサービス）は技術者の労働力提供を主とする準委任の一形態です。ラボ型契約も準委任ですが、SESのような単発の人員提供ではなく、専属チームを中長期で確保し、継続的にナレッジを蓄積していく点が異なります。RFPでこの位置づけを書き分けておかないと、各社がSES的な人月単価の切り売り提案をしてくることがあります。
RFPには「専属チームを最低◯か月確保し、その間は他案件と兼任させない」「チームの固定メンバーを契約期間中は維持する」といった、ラボ型ならではの条件を明記します。これにより、単なる人材派遣的な提案を排除でき、ナレッジ蓄積を前提とした体制の提案だけを比較対象にできます。契約交渉の段階でも、この記載が専属性を担保する条項の根拠になります。
稼働体制と交代基準をRFPで提示する
ラボ型契約で最もトラブルになりやすいのが、稼働体制とメンバーの交代です。専属チームを確保するということは、その人材のスキルやコミットメントにプロジェクトの成否が直結するということです。RFP段階で稼働体制の要求水準と、メンバーが期待に届かなかった場合の交代基準を提示しておくことが、契約交渉と運用の両方で発注側を守ります。
人数・職種構成・稼働下限上限を数値で書く
稼働体制は、希望する人数と職種構成、各メンバーの月あたり稼働時間の下限と上限、そしてブリッジSEやプロジェクトマネージャーを含めるかどうかを、できる限り数値で提示します。たとえば「フロントエンド2名、バックエンド2名、PM1名、各160時間/月を基本とし、繁忙期は最大40時間まで増減可能」といった具合です。稼働の下限上限を示すのは、ラボ型では稼働の空きでも費用が発生するためです。
あわせて、コミュニケーション体制も提示します。日次・週次のミーティング頻度、使用ツール、レポートの形式と提出タイミング、日本語でのやり取りが必要かどうかなどです。国内ラボ型なら日本語コミュニケーションは前提にできますが、オフショアを併用する場合はブリッジSEの配置を必須条件として書きます。これらをRFPで数値化しておくと、各社の稼働見積もりが同じ前提で並び、費用の妥当性を判断しやすくなります。
交代基準と費用負担をRFPで先に宣言する
メンバーのスキルが期待に届かない、あるいは突然の離脱が起きたとき、誰の費用負担で交代させるのか。これはラボ型契約で最も揉める論点です。交代要員の立ち上げにはオンボーディング期間が必要で、その間の稼働を発注側が払うのか受託側が吸収するのかで、数十万円単位の差が出ます。RFP段階で交代基準を提示しておくと、各社がこの条件を織り込んで提案するため、後の契約交渉での押し問答を避けられます。
RFPには、交代を請求できる要件（成果が一定基準を下回る、勤怠不良など）、交代要員のスキル保証（離脱者と同等以上）、交代に伴う引き継ぎ期間の稼働を誰が負担するか、を提示します。たとえば「発注側がスキル不足を理由に交代を求めた場合、引き継ぎ期間2週間の稼働は受託側負担とする」といった水準まで書ければ理想的です。ここを曖昧にすると、交代のたびに発注側がオンボーディング費用を二重に払うことになりかねません。
費用上限・知財条件をRFPに書き込む
費用と知財は、契約後に取り返しのつかない論点です。費用は稼働率の前提しだいで実質単価が大きく変わり、知財はRFPで触れておかないと、開発したソースコードの権利が受託側に帰属したまま、というケースが起こります。どちらも単価相場という一次データを踏まえて、上限と前提をRFPで提示しておくことが重要です。
単価相場を踏まえた費用上限と稼働率の前提を示す
費用条件を提示する前提として、単価相場を押さえておきます。国内ニアショアの月額単価は、ジュニアで約52.8〜84.7万円、シニアで約68〜100万円、PMで約85〜138万円が目安です。海外オフショアを併用する場合、ベトナムはジュニア30〜40万円・シニア40〜60万円、ブリッジSEで約59〜88万円、インドネシアは20〜30万円程度が相場です。これらの相場をもとに、月額の上限額をRFPに提示します。
あわせて重要なのが、稼働率の前提です。ラボ型では稼働の空きでも費用が発生するため、「稼働率が一定を下回った月は精算する」「月の下限稼働時間を保証する代わりに、上限を超えた分は別途協議する」といった条件を提示しておくと、実質単価が想定より跳ね上がるのを防げます。いきなり長期契約を結ぶのが不安な場合は、まず1人月30〜35万円程度のパイロット契約から始め、稼働の実態と相性を見てから本契約に移行する進め方も提示できます。
知財・ソース帰属とOSSの責任分担を提示する
知的財産権は、RFPで触れておかないと発注側に不利になる典型です。契約に取り決めがなければ、開発したプログラムの著作権は制作した受託側に原則として帰属します。自社の資産にするには、納品物と中間生成物の著作権を発注側へ譲渡する旨、著作者人格権を行使しない旨を、RFP段階で要求条件として提示しておく必要があります。
あわせて、オープンソースソフトウェア（OSS）のライセンス遵守をどちらの責任で担保するか、開発で得た汎用的なノウハウやライブラリを受託側が他案件で再利用してよいかも提示します。再利用の可否を曖昧にすると、自社専用に作らせたつもりのモジュールが競合に流用される懸念が残ります。これらをRFPで宣言しておけば、契約書の知財条項を協議する際に、RFPの記載がそのまま発注側の主張の根拠になります。
契約条件を裏づける単価・市場データ
RFPで費用上限や体制条件を提示するには、根拠となる相場感を持っておくことが欠かせません。ここでは、契約条件を交渉する際の裏づけになる単価相場と市場統計を整理します。これらの数値を把握しておくと、提示された見積もりが妥当かどうかを発注側が自分で判断でき、契約交渉で主導権を握れます。
国内・オフショアの単価相場（一次データ）
単価の目安を職種別に整理します。
・国内ニアショア：ジュニア約52.8〜84.7万円/月、シニア約68〜100万円/月、PM約85〜138万円/月
・ベトナムオフショア：ジュニア30〜40万円/月、シニア40〜60万円/月（平均約48万円）、ブリッジSE約59〜88万円/月、PM約70〜160万円/月
・インドネシアオフショア：20〜30万円/月
・パイロット契約：1人月30〜35万円程度
国内とオフショアで2倍前後の差がありますが、国内は日本語コミュニケーションの円滑さと品質・安心感、オフショアはコストとスケーラビリティが強みです。RFPでは、どの体制を前提にするかを明示したうえで上限額を提示すると、提案の比較がぶれません。
市場統計から見る体制条件の考え方
体制条件を考えるうえで、人材の供給状況も判断材料になります。日本のIT人材は約125万人のうち76万人が首都圏に集中しており、地方ではIT人材の枯渇が課題です。国内ニアショアを担う組織として、ニアショアIT協会には正会員93社・技術者約5,000名が所属しています。一方、ベトナムはIT労働人口126万人を抱え、2030年までに300万人を育成する計画を掲げ、AI技能保有者は2023年以降340%増の8.5万人に達しています。
こうした統計は、専属チームを長期確保するという契約条件の現実味を裏づけます。実際に、富士フイルムヘルスケアはFPTとの協業で、小規模なラボから15年かけて170名規模の統合開発ラボへと段階的に拡大し、医療機器ソフトの高品質領域を任せられる体制を築いた事例があります。RFPで「将来的に体制を◯名規模まで拡大したい」といった成長前提を提示しておくと、長期目線で体制を組める相手かどうかを見極められます。
契約交渉を見据えたRFPの作り方と契約条件チェックリスト
ここまでの5つの契約条件を、実際のRFP作成と契約交渉にどう落とし込むかをまとめます。RFPは契約書の前段階であり、ここに書いた条件がそのまま契約条項の協議の出発点になります。発注側がRFPで先に条件を提示できていれば、契約交渉は「RFPの条件をどう条文化するか」という建設的な議論になり、ゼロから条件を取り合う消耗戦を避けられます。
契約交渉を有利にするRFPの作り方
契約交渉を見据えたRFPは、要望の羅列ではなく、契約条件を優先順位とともに提示する構成にします。まず目的とゴールを冒頭に置き、続けて契約形態・稼働体制・交代基準・費用上限・知財条件の5点を、それぞれ「必須」「できれば」のレベル分けで示します。レベル分けをしておくと、提案各社がどこを譲れて、どこを譲れないかが明確になり、契約交渉で論点が整理されます。
あわせて、契約期間・更新の前提、KPI（稼働率や品質指標）の報告方法、契約終了時の引き継ぎ義務まで触れておくと、交渉の終盤で揉めやすい解約・移行の論点を先回りできます。仕様が完全に固まっていなくても、ラボ型は走りながら詰められる形態なので、機能の細部より契約条件の骨格を優先して書くのが、発注側にとって賢いRFPの作り方です。
RFPに盛り込むべき契約条件チェックリスト
RFP提出前と、提案各社から受け取った契約書ドラフトを点検する際に使えるチェックリストを示します。
・契約形態を準委任と明示し、完成責任を負わせない代わりに求める品質水準を提示したか
・稼働人数・職種構成・稼働の下限上限・コミュニケーション体制を数値で提示したか
・メンバー交代の要件・スキル保証・引き継ぎ期間の費用負担を提示したか
・月額の費用上限・稼働率の前提・超過時の扱いを提示したか
・成果物とソースコードの著作権譲渡・著作者人格権の不行使を要求したか
・OSSライセンスの責任分担と、ノウハウ・モジュールの再利用可否を提示したか
・契約期間・更新・解約予告期間・契約終了時の引き継ぎ義務を提示したか
・秘密保持（NDA）の範囲・期間・再委託時の扱いを提示したか
このチェックリストで空欄が残る項目があれば、それが契約交渉で発注側が後手に回るポイントです。RFP段階ですべて埋めておくことを推奨します。
riplaでは、フルスクラッチ受託と国内ラボ型開発の両方の経験から、発注側の目的と体制要求を整理し、契約条件まで見据えたRFP・要件定義の作成を支援しています。準委任という形態のもとで、稼働・費用・知財をどう取り決めれば自社が守られるのか、契約交渉の前段階からご相談いただけます。
まとめ
ラボ型契約のRFP・要件定義は、機能仕様を固める作業ではなく、契約形態（準委任）・稼働体制・交代基準・費用上限・知財条件という5つの契約条件を、発注側から先に提示する作業です。これらをRFPで提示しておけば、各社の提案を同じ土俵で比較でき、契約交渉もRFPの記載を起点に建設的に進められます。逆に空欄のまま提案を募ると、想定外の費用負担や知財の帰属トラブルを招き、発注側が後手に回ります。
国内ニアショアでジュニア約52.8〜84.7万円/月、PMで約85〜138万円/月といった単価相場を踏まえ、費用上限と稼働下限を提示し、本記事の契約条件チェックリストで抜け漏れを点検することが、割高化とトラブルを防ぐ近道です。仕様が固まりきっていなくても、契約条件の骨格を優先して書くのが賢いRFPの作り方です。契約交渉を見据えたRFP・要件定義の整理にお悩みであれば、ぜひ一度ご相談ください。
株式会社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を創業。