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