ラボ型開発は「仕様が固まっていなくても始められる」と紹介されることが多く、発注側にとってハードルが低い契約形態に見えます。ところが実際に立ち上げてみると、目的や優先順位が言語化されていないチームは初月から空転し、稼働時間に対価を払うラボ型では「動いていないのに費用だけが発生する」という事態に陥りがちです。柔軟だからこそ、発注側が最低限のRFP（提案依頼書）と要件を整えておく実務が成否を分けます。
この記事では、ラボ型開発で発注側が準備すべきRFP・要件定義書の「最低限の中身」を、目的・優先順位・体制要求・KPI・交代基準という5つの観点から実務レベルで解説します。単価相場や市場統計などの一次データ、テンプレート化できる記載項目、契約に必ず入れておきたい交代条項まで踏み込み、読み終えた時点で自社のRFP骨子をそのまま書き起こせる状態を目指します。フルスクラッチ受託と国内ラボ型・要件整理の伴走を手がけるriplaの視点から、発注側がつまずきやすい論点を整理します。なお、全体像はラボ型開発の完全ガイドでも解説しています。
なぜラボ型開発でもRFP・要件が必要なのか
ラボ型開発は法的には準委任契約に該当し、成果物の完成ではなく一定期間の稼働（人材の確保）が対価になります。請負契約のように「この仕様のものを納品する」という約束ではないため、仕様が固まっていなくても着手できる柔軟性が最大の魅力です。ただし、この柔軟性が「要件を準備しなくてよい」という誤解につながると、立ち上げ初期に大きなロスが生まれます。
稼働に対価を払う以上、チームが何を優先して動くべきかを発注側が示せなければ、確保したエンジニアの工数が空転します。これはラボ型に特有のリスクで、請負契約なら「完成しなければ支払わない」という形でベンダー側がリスクを負いますが、ラボ型では発注側のマネジメント力がそのままアウトプットの質を左右します。だからこそ、最低限の要件をRFPの形で整える意味があります。
請負・SESとの違いがRFPの粒度を決める
請負契約では、納品物の品質をめぐる責任はベンダーにあり、発注側は完成した成果物に対して検収を行います。そのためRFPには「実現したい仕様」を可能な限り詳細に書く必要があります。一方ラボ型は準委任契約であり、ベンダーは善管注意義務（善良な管理者としての注意義務）を負うものの、特定の成果物の完成を保証するわけではありません。
この違いから、ラボ型のRFPは「完成形の仕様」ではなく「目指す方向性と、それを実現するチームに求める条件」を中心に書くべきだと整理できます。SES（システムエンジニアリングサービス）が個人単位の労働力提供であるのに対し、ラボ型はチーム単位で中長期に確保する点も異なり、RFPには個人のスキルだけでなくチーム構成と継続的なアサインへの要求を盛り込む必要があります。
善管注意義務の限界と責任分界点
準委任契約におけるベンダーの責任は、あくまで善管注意義務の範囲にとどまります。つまり「プロとして適切に注意を払って業務を遂行する」義務はあっても、バグのない完璧な成果物を保証する義務はありません。バグが発生した場合の修正対応をどこまでベンダーが負担するのか、不具合の責任分界点をどこに置くのかは、RFPと契約の段階で明確にしておかないと後でもめます。
具体的には、リリース後の保守範囲、重大バグの定義と対応SLA、仕様変更に起因する不具合の扱いなどをRFPの前提条件として記載します。riplaが要件整理の伴走で重視しているのも、この責任分界をプロジェクト初期に発注側とベンダーで握っておく点です。曖昧なまま走り出すと、稼働は続いているのに「誰の責任で直すのか」で時間が溶けていきます。
RFPに盛り込む最低限の5要素
ここからが本記事の中心です。ラボ型開発のRFPに最低限盛り込むべき要素を、(1) 目的とゴール、(2) 優先順位、(3) 体制・スキル要求、(4) KPIと報告、(5) 交代基準と費用負担、の5つに分けて解説します。逆に言えば、この5点さえ言語化できていれば、詳細仕様が固まっていなくてもベンダーは精度の高い提案を返せます。
(1) 目的とゴール、(2) 優先順位の言語化
最初に書くべきは、プロジェクトの目的（なぜやるのか）と、達成したいビジネスゴールです。「新規事業の検証MVPを最短で市場に出したい」のか「既存サービスの長期保守と漸進的改善をしたい」のかでは、求めるチームの性質がまったく異なります。目的が明確だと、ベンダーは初動でどのスキルセットをアサインすべきかを判断でき、立ち上げ期のミスマッチを防げます。
次に重要なのが機能の優先順位付けです。仕様を細かく決めきれないラボ型だからこそ、何を先にやり何を後回しにできるかの優先順位は発注側が示す必要があります。実務ではMoSCoW法（Must have / Should have / Could have / Won’t have の4段階）で仕分けると、ベンダーとの合意形成がスムーズです。
RFPに書く優先順位の例を整理します。
・Must（必須）：ログイン認証、決済連携など事業継続に不可欠な機能
・Should（重要）：管理画面、レポート機能など早期に欲しいが代替手段がある機能
・Could（任意）：UI改善、通知の細分化など余力があれば実装する機能
・Won’t（今回見送り）：将来構想として外部連携APIなど今回スコープ外と明示する機能
このように「やらないこと」まで明記すると、ベンダーが余計な工数を割く事故を防げます。
(3) 体制・スキル要求の書き方
ラボ型はチームを中長期に確保する契約なので、求める体制を職種別に書き出します。具体的には、PM（プロジェクトマネージャー）／ブリッジSE（オフショアの場合は橋渡し役）／シニアエンジニア／ジュニアエンジニア／QA担当など、職種ごとの人数・役割・想定稼働率を提示します。これがそのままベンダーの見積根拠になり、提案チームの妥当性を比較できます。
スキル要求は「使用技術スタック（言語・フレームワーク・クラウド）」「業務ドメインの理解度」「日本語または英語でのコミュニケーションレベル」の3軸で書くと過不足がありません。特にオフショアの場合、ブリッジSEの日本語レベルとコミュニケーション設計はプロジェクトの生死を分けるため、RFPで明示的に条件化しておくべきです。
体制要求の精度を上げるうえで参考になるのが、各職種でどの程度の単価が発生するかという相場感です。リサーチで把握している単価レンジ（次章で詳述）を踏まえると、PMやシニアを厚くするほど月額は跳ね上がるため、優先順位とセットで「どの職種にどれだけ予算を配分するか」をRFP段階で粗くでも決めておくと、提案比較が現実的になります。なお、ラボ型でチームが提供する役割（専属チーム確保・継続アサイン・ナレッジ蓄積・スプリント運用・ブリッジSE/PM体制・品質保証体制）の全体像は、兄弟記事「ラボ型開発の必要機能や標準機能の一覧について」で整理しています。
(4) KPIと報告サイクルの設計
請負契約なら成果物の完成がゴールになりますが、ラボ型は稼働が対価なので、KPIは「チームと進め方が機能しているか」を測る運用指標に置くのが定石です。具体的には、スプリントごとのベロシティ（消化ポイント）、計画に対する消化率、重大バグの発生件数と平均修正時間、レビュー指摘の傾向などを定例で確認します。
報告サイクルもRFPに明記します。デイリーの進捗共有、週次のスプリントレビュー、月次の体制・予算レビューといった頻度と、それぞれで何を報告してもらうかを定義しておくと、稼働の空転を早期に発見できます。KPIと報告がないラボ型は「動いているように見えて成果が出ていない」状態に気づくのが遅れ、これが立ち上げ失敗の典型パターンです。
単価相場と市場統計でKPI・予算を裏づける
RFPの体制要求と予算を現実的に組むには、職種別の単価相場を知っておく必要があります。ここでは国内ニアショアとオフショアの単価レンジ、そして市場の人材供給状況という一次データを示します。これらは提案を比較する際の「妥当性の物差し」になります。
職種別の単価レンジ（一次データ）
当社が把握している月額単価レンジは以下の通りです。
・ベトナムオフショア：ジュニア30〜40万円／シニア40〜60万円（平均約48万円）／ブリッジSE約59〜88万円／PM約70〜160万円
・インドネシアオフショア：20〜30万円
・国内ニアショア：ジュニア約52.8〜84.7万円／シニア約68〜100万円／PM約85〜138万円
このほか、お試しとして1人月30〜35万円程度のパイロット契約で立ち上げの相性を見るケースもあります。
この相場を踏まえると、RFPで「PM1名＋シニア2名＋ジュニア2名」といった体制を要求した場合に月額がどの程度に収まるかが概算できます。提案された見積がこのレンジを大きく外れていれば、その根拠をベンダーに確認すべきというシグナルになります。逆に、優先順位（前章のMoSCoW）と単価レンジを突き合わせれば、限られた予算でMust機能を確実に押さえる体制設計が可能になります。
人材市場の統計とニアショアの背景
体制要求が現実的かどうかは、その地域に人材が供給されているかにも左右されます。ベトナムのIT労働人口は約126万人で、2030年までに300万人を育成する国家計画が進んでいます。AI技能保有者は約8.5万人にのぼり、2023年以降で約340%増加しているとされ、新技術領域でも人材確保の余地が広がっています。
一方、国内に目を向けると、日本のIT人材約125万人のうち約76万人が首都圏に集中しており、地方のIT人材は枯渇傾向にあります。この構造が国内ニアショア活用の追い風になっており、ニアショアIT協会には正会員93社・技術者約5,000名が参画しています。RFPで「国内ニアショア中心の体制」を求める場合、こうした供給状況を前提に、確保できる人数の現実性をベンダーに確認しておくと安全です。
(5) 交代基準と費用負担をRFP・契約に明記する
競合記事の多くが触れず、しかし実務で最も揉めるのが要員交代の取り扱いです。ラボ型は中長期にチームを確保する前提ですが、アサインされたメンバーのスキルが期待に満たない、あるいは突然退職するといった事態は珍しくありません。このときの交代手続きと費用負担をRFPと契約で先に決めておかないと、稼働は続いているのにアウトプットが出ない宙ぶらりんの状態に陥ります。
交代条項に盛り込むべき項目
交代条項では、次の項目を具体的に定めます。
・交代を申し入れできる基準（スキルミスマッチの判定方法、評価期間）
・交代申し入れから新メンバーアサインまでのリードタイム上限
・引き継ぎ期間中の費用負担（旧メンバーと新メンバーの重複稼働分を誰が持つか）
・退職などベンダー都合の交代における無償引き継ぎの範囲
・ナレッジ流出を防ぐためのドキュメント整備義務
特に「引き継ぎ期間の重複稼働費用」は曖昧にされがちで、ここを発注側負担にされると交代のたびにコストが膨らみます。
RFPの段階で「ベンダー都合の交代に伴う引き継ぎ稼働は無償とする」「発注側都合の交代は事前通知から〇営業日以内に対応」といった条件を提示し、各社の回答を比較すると、体制の安定性に対する各社の本気度が見えます。riplaが要件整理の伴走で必ず確認するのも、この交代と引き継ぎのルールです。
長期運用を見据えた事例と軌道修正
交代やナレッジ蓄積の仕組みが機能すると、ラボ型は段階的に拡大できます。たとえば富士フイルムヘルスケアとFPTの取り組みでは、小規模なラボから始まり、約15年をかけて170名規模の統合開発ラボへと拡大しています。医療機器ソフトという高品質が求められる領域でこの規模まで成長できた背景には、初期からのナレッジ蓄積と体制の継続性があったと考えられます。
逆に言えば、立ち上げ初期に交代ルールやナレッジ整備を怠ると、人が入れ替わるたびにゼロからのキャッチアップが発生し、拡大どころか縮小に向かいます。RFPで交代と引き継ぎを設計しておくことは、目先のトラブル回避だけでなく、長期的にチームを資産として育てられるかを左右する投資なのです。
そのまま使えるRFP骨子テンプレート
ここまでの5要素を、実際のRFPに落とし込む際の章立てとして整理します。この骨子をベースに自社の情報を埋めていけば、仕様が流動的でも提案精度の高いRFPになります。
RFP章立てと記載粒度
推奨するRFPの章立ては以下の通りです。
1. プロジェクト概要・目的・ビジネスゴール
2. スコープと優先順位（MoSCoWでの機能仕分け、やらないことの明記）
3. 求める体制とスキル要求（職種別人数・役割・技術スタック・コミュニケーション要件）
4. KPIと報告サイクル（ベロシティ・消化率・バグ指標、定例の頻度と内容）
5. 交代基準と費用負担（交代条件・リードタイム・引き継ぎ費用の取り扱い）
6. 契約条件・前提（準委任の確認・責任分界点・保守範囲・契約期間と更新条件）
7. 提案依頼事項（提案チーム構成・見積根拠・類似実績・コミュニケーション設計案）
記載粒度のコツは、確定している部分は具体的に、流動的な部分は「想定」「方向性」と明示して書くことです。すべてを断定せず、不確実性を不確実なまま正直に伝えるほうが、ベンダーはリスクを織り込んだ現実的な提案を返せます。曖昧さを隠すより、曖昧さの所在を共有するのがラボ型RFPの肝です。
要件整理を伴走する選択肢
RFPの5要素を社内だけで言語化するのが難しい場合、要件整理から伴走してくれるパートナーに相談する選択肢もあります。riplaはフルスクラッチ受託を主軸としつつ、国内ラボ型や要件整理の伴走で、発注側が抱える「何を優先すべきか分からない」「体制の妥当性を判断できない」といった課題に並走しています。
自社の業務要件に合わせて体制を組み立て、目的・優先順位・交代基準まで含めた現実的なRFPに落とし込むことで、立ち上げ初期の空転を最小化できます。仕様が固まっていない段階での相談こそ、ラボ型を成功させる第一歩になります。
まとめ
ラボ型開発は仕様が固まっていなくても始められる柔軟な契約ですが、稼働が対価になる準委任契約である以上、発注側が最低限の要件をRFPで整えておくことが成否を分けます。本記事で示した目的・優先順位・体制要求・KPI・交代基準の5要素を言語化すれば、詳細仕様が流動的でもベンダーは精度の高い提案を返せます。
とりわけ、競合があまり触れない要員交代の基準と費用負担、善管注意義務の限界と責任分界点は、立ち上げ後の炎上を防ぐ要です。単価相場や人材市場の統計を物差しに使えば、提案の妥当性も冷静に判断できます。仕様が固まっていない段階でこそ、要件整理から伴走してくれるパートナーへの相談が、ラボ型を成功に導く近道になります。
株式会社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を創業。