国内/日本ラボ型開発のRFP/要件定義書/提案依頼書について

ラボ型開発というと、まずベトナムやインドといったオフショアを思い浮かべる方が多いかもしれません。しかし近年は、国内のニアショア拠点に専属チームを確保する「国内（日本）ラボ型開発」を選ぶ発注企業が着実に増えています。時差や言語の壁が小さく、個人情報や機密情報の取り扱い、国内法への準拠、そして対面でのすり合わせを重視する案件では、国内ラボ型のほうが現実的な選択肢になるからです。そして、この国内ラボ型を成功させる起点になるのが、発注側が準備するRFP（提案依頼書）と要件定義書です。

この記事では、国内ラボ型開発に特化して、発注側が準備すべきRFP・要件定義書の書き方を実務レベルで解説します。日本語・商習慣を前提にした要件記述、個人情報保護法やセキュリティへの対応、地方拠点・対面要件の決め方、そして国内ニアショア委託先をどの評価軸で選ぶかまで、オフショア前提との違いを明確にしながら整理します。単価相場や人材市場の一次データも示すため、読み終えた時点で自社の国内ラボ型RFPの骨子をそのまま書き起こせる状態を目指します。フルスクラッチ受託と国内ラボ型・要件整理の伴走を手がけるriplaの視点でまとめました。なお、全体像はラボ型開発の完全ガイドでも解説しています。

国内ラボ型開発がRFPで問われる前提の違い

国内ラボ型開発も、法的にはオフショアと同じく準委任契約に該当し、成果物の完成ではなく一定期間の稼働（チームの確保）が対価になります。この点はラボ型に共通する基本構造です。ただし、委託先が国内のニアショア拠点である場合、RFPで問うべき論点の力点がオフショアとは大きく変わります。発注側が同じ感覚でRFPを書くと、せっかくの国内委託の強みを引き出せません。

最大の違いは、言語と時差の障壁が小さいことです。オフショアでは、ブリッジSEの日本語レベルや英語でのコミュニケーション設計がプロジェクトの生死を分けますが、国内ラボ型ではこの負荷がほぼ消えます。その代わり、発注側はRFPの記述リソースを別の論点、すなわち国内法・セキュリティ・対面体制・地方拠点の安定性に振り向ける必要があります。「言語の心配が要らない分、何を要件に書くべきか」を再設計するのが国内ラボ型RFPの出発点です。

オフショア前提のRFPでは、ブリッジSEの配置、日本語または英語の運用ルール、時差を吸収する非同期コミュニケーションの設計、為替変動やカントリーリスクへの対応条項などが重要な記載項目になります。これらは海を越えた委託に固有の論点であり、要件定義書のかなりの分量を占めます。

国内ラボ型のRFPでは、これらの論点の多くが不要、または大幅に簡略化できます。一方で、個人情報を国内サーバで保管する要件、委託先のセキュリティ認証の有無、対面での定例やワークショップの頻度、地方拠点の人材確保の安定性といった、国内委託ならではの要件が前面に出てきます。同じ「ラボ型のRFP」でも、要件の重心が「言語・時差・為替」から「法対応・セキュリティ・対面・拠点」へ移ると理解すると、書き分けが明確になります。

国内ラボ型も「仕様が固まっていなくても始められる」柔軟性が魅力です。ただし稼働に対価を払う以上、チームが何を優先して動くべきかを発注側が示せなければ、確保したエンジニアの工数が空転します。国内だからすぐに相談できるという安心感が、かえって「要件は後で詰めればよい」という油断を生みやすい点には注意が必要です。

準委任契約におけるベンダーの責任は善管注意義務（善良な管理者としての注意義務）の範囲にとどまり、特定の成果物の完成を保証するものではありません。バグ修正の負担範囲や不具合の責任分界点は、国内ラボ型でもRFPと契約の段階で明確にしておく必要があります。委託先が国内で連絡を取りやすいからといって口頭の合意で済ませると、後の保守範囲をめぐって揉める原因になります。riplaが要件整理の伴走で重視するのも、この責任分界をプロジェクト初期に文書で握っておく点です。

国内ラボ型RFPに盛り込む要件の力点

ここからが本記事の中心です。ラボ型開発に共通する目的・優先順位・KPI・交代基準といった基本要素を踏まえたうえで、国内ラボ型に固有の力点を「日本語・商習慣を前提にした要件記述」「国内法・セキュリティ要件」「対面・地方拠点の要件」の3つに分けて深掘りします。これらは競合記事が手薄な領域であり、国内委託先選定の精度を直接左右します。

国内ラボ型の大きな利点は、要件定義書やドキュメントを日本語の自然な表現でそのまま運用できることです。オフショアでは翻訳や用語の標準化に工数を割きますが、国内では業務ドメイン特有の言い回しや暗黙の前提が伝わりやすく、要件の解像度を保ったまま開発に渡せます。RFPには、ドキュメントの言語（日本語）、用語集の整備方針、社内の業務フローを前提とした要件の書き方を明記しておくと、認識のずれを減らせます。

商習慣の前提も重要な要件です。日本の業務システムでは、稟議・承認フロー、見積から請求までの商流、和暦や年度の扱い、取引先ごとの帳票フォーマットなど、国内特有の仕様が頻出します。これらを「説明しなくても理解してくれる」ことを期待するなら、委託先が国内の業務システム開発に慣れているかをRFPの前提条件として確認すべきです。商習慣の理解度は、要件の伝達コストを大きく左右します。

RFPで明示しておきたい商習慣・言語まわりの要件を整理します。
・要件定義書・設計書・議事録を日本語で作成・管理すること
・国内特有の業務仕様（稟議フロー、和暦、年度処理、帳票要件など）への対応経験
・社内の既存システムや業務用語を前提とした要件のすり合わせ体制
・問い合わせや確認への日本時間ベースでの応答

これらを前提化すると、伝達のロスを最小化したチーム編成をベンダーが提案しやすくなります。

国内ラボ型を選ぶ理由として最も多いのが、個人情報や機密情報の取り扱いに関する安心感です。RFPでは、個人情報保護法への準拠、データの国内保管、再委託の可否と範囲、アクセス権限の管理方針などを明文化します。海外にデータを置かないこと自体が要件になるケースも多く、これは国内委託でこそ満たしやすい条件です。

委託先のセキュリティ体制も評価対象です。プライバシーマークやISMS（ISO/IEC 27001）といった認証の保有、秘密保持契約（NDA）の締結範囲、開発環境のセキュリティ（端末管理・ネットワーク分離・ログ監査）への対応をRFPで問います。金融・医療・公共など規制の厳しい業界では、業界固有のガイドラインへの対応経験も要件に加えると、後の監査対応がスムーズになります。

RFPに盛り込むセキュリティ・法対応の確認項目を整理します。
・個人情報保護法その他の国内関連法令への準拠と対応体制
・取り扱うデータの国内保管とアクセス制御の方針
・プライバシーマーク／ISMSなどのセキュリティ認証の保有状況
・秘密保持契約の締結と再委託時の管理ルール
・業界固有の規制やガイドライン（金融・医療・公共など）への対応実績

これらは委託先の信頼性を見極める客観的な物差しになり、提案各社を横並びで比較しやすくなります。

国内ラボ型の隠れた強みは、必要なときに対面で集まれることです。新規事業の立ち上げ期や、業務理解が深く求められる基幹系の刷新では、最初のワークショップや要件すり合わせを対面で行うと、認識のずれが一気に減ります。RFPには、対面定例の頻度（例：キックオフは対面、月次は対面、週次はオンライン）、出張・常駐の要否、想定する移動コストの負担者を明記します。すべてをオンラインで済ませるオフショアとは、ここが決定的に異なる要件です。

地方拠点の前提も国内ラボ型固有の論点です。国内ニアショアは地方都市の開発拠点を活用してコストを抑える形が多く、委託先がどの拠点で何名の体制を組めるかが、確保人数の安定性に直結します。日本のIT人材は首都圏に集中しており、地方の人材プールには限りがあるため、RFPで「どの拠点で、何名を、どのくらいの期間継続的にアサインできるか」を確認しておくと、立ち上げ後の増員可否を現実的に見積もれます。

体制要件は職種別に書き出すのが基本で、PM・シニアエンジニア・ジュニアエンジニア・QA担当などの人数・役割・想定稼働率を提示します。国内ラボ型ではここに「主たる拠点」「対面対応の可否」「増員時の人材供給見込み」を加えると精度が上がります。なお、ラボ型でチームが提供する役割（専属チーム確保・継続アサイン・ナレッジ蓄積・スプリント運用・品質保証体制など）の全体像は、兄弟記事「国内/日本ラボ型開発の必要機能や標準機能の一覧について」で整理しています。

国内ニアショアの単価相場と人材市場の一次データ

国内ラボ型の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万円程度のパイロット契約で立ち上げの相性を見るケースもあります。国内ニアショアはオフショアより単価が高い傾向ですが、その分を言語・時差・品質面の安心感とすり合わせの速さで回収する、というのが選定の基本的な考え方です。

この相場を踏まえると、RFPで「PM1名＋シニア2名＋ジュニア2名」といった体制を要求した場合に、国内ニアショアとオフショアでそれぞれ月額がどの程度になるかを概算できます。提案された見積がこのレンジを大きく外れていれば、その根拠をベンダーに確認すべきというシグナルになります。国内ラボ型では単価の高さを許容する代わりに、セキュリティや対面体制といった非価格要件の充足を強く求める、というトレードオフを意識した予算配分が現実的です。

国内ラボ型の体制要求が現実的かどうかは、国内の人材供給状況に左右されます。日本のIT人材は約125万人とされ、そのうち約76万人が首都圏に集中しています。地方のIT人材は枯渇傾向にあり、この偏在こそが国内ニアショア（地方拠点の活用）が注目される構造的な背景です。発注側がRFPで地方拠点中心の体制を求める場合、その拠点で確保できる人数の現実性を、委託先に具体的な数字で確認しておくと安全です。

国内ニアショアの担い手としては、ニアショアIT協会に正会員93社・技術者約5,000名が参画しています。この規模感は、首都圏に集中する人材を地方拠点で補完しようとする業界全体の動きを示しています。一方、参考としてオフショア側の供給状況を見ると、ベトナムのIT労働人口は約126万人で、2030年までに300万人を育成する国家計画が進み、AI技能保有者も約8.5万人（2023年以降で約340%増）にのぼります。豊富な人材供給というスケーラビリティはオフショアの強みであり、ここを安心感・近接性と天秤にかけるのが委託先選定の本質です。

国内ニアショア委託先を選ぶ評価軸

RFPを各社に提示したあと、返ってきた提案をどの評価軸で比較するかが、国内ラボ型の成否を分けます。オフショアでは単価とスケーラビリティが評価の中心になりがちですが、国内ニアショアでは非価格要件の比重が高くなります。発注側は「安いから」ではなく「自社の要件に最も合うか」で選ぶべきです。

国内ニアショア委託先の比較で重視すべき評価軸を整理します。
・セキュリティ：プライバシーマーク／ISMSの保有、国内データ保管、再委託の管理
・拠点の安定性：主たる開発拠点、その地域での人材確保力、増員時の供給見込み
・業務理解：国内の業務システム・商習慣に関する実績、対象業界のドメイン知識
・対面対応力：キックオフやワークショップの対面対応、必要時の常駐・出張の可否
・ドキュメント文化：日本語での設計書・議事録の整備、ナレッジ蓄積の仕組み

これらを点数化して横並びで比較すると、単価だけでは見えない委託先の実力差が浮かび上がります。

あわせて、ラボ型に共通するKPIと交代基準もRFPで定義します。準委任契約では稼働が対価になるため、KPIはスプリントごとのベロシティ、計画消化率、重大バグの件数と平均修正時間といった「進め方が機能しているか」を測る運用指標に置きます。週次・月次の報告サイクルを明記し、稼働の空転を早期に発見できる仕組みを要件化しておくことが、立ち上げ失敗の回避につながります。

要員交代の基準と費用負担も、国内ラボ型で必ずRFP・契約に入れておきます。具体的には、交代を申し入れできる基準と評価期間、新メンバーアサインまでのリードタイム上限、引き継ぎ期間中の重複稼働費用を誰が負担するか、退職などベンダー都合の交代における無償引き継ぎの範囲です。国内であってもメンバーの退職やスキルミスマッチは起こり得るため、「ベンダー都合の交代に伴う引き継ぎ稼働は無償」「発注側都合の交代は事前通知から所定日数以内に対応」といった条件を提示して各社の回答を比較すると、体制の安定性に対する本気度が見えます。

交代やナレッジ蓄積の仕組みが機能すると、ラボ型は段階的に拡大できます。たとえば富士フイルムヘルスケアとFPTの取り組みでは、小規模なラボから始まり、約15年をかけて170名規模の統合開発ラボへと拡大しています。医療機器ソフトという高品質が求められる領域でこの規模まで成長できた背景には、初期からのナレッジ蓄積と体制の継続性があったと考えられます。これはオフショアの事例ですが、ナレッジを資産として積み上げる設計の重要性は、国内ラボ型にもそのまま当てはまります。

国内ラボ型の場合、対面でのすり合わせや日本語ドキュメント文化を活かすことで、ナレッジの蓄積と継承を一段とスムーズに進められます。RFPで対面体制とドキュメント整備義務を要件化しておくことは、目先のトラブル回避だけでなく、地方拠点のチームを長期的な資産として育てられるかを左右する投資なのです。逆に、近いからと口頭中心で進めてナレッジを文書化しないと、人の入れ替わりのたびにキャッチアップが発生し、拡大どころか縮小に向かいます。

国内ラボ型RFPの骨子テンプレート

ここまでの要件を、実際のRFPに落とし込む際の章立てとして整理します。この骨子をベースに自社の情報を埋めていけば、仕様が流動的でも提案精度の高い、国内ラボ型向けのRFPになります。

推奨するRFPの章立ては以下の通りです。
1. プロジェクト概要・目的・ビジネスゴール
2. スコープと優先順位（機能の仕分け、やらないことの明記）
3. 求める体制とスキル要求（職種別人数・役割・主たる拠点・対面対応の可否・増員見込み）
4. 日本語・国内商習慣を前提とした要件記述方針（ドキュメント言語・業務仕様の対応経験）
5. 国内法・セキュリティ要件（個人情報保護法準拠・国内保管・認証保有・再委託管理）
6. 対面/オンラインの稼働要件（定例の頻度・常駐や出張の要否・移動費の負担）
7. KPIと報告サイクル（ベロシティ・消化率・バグ指標、定例の頻度と内容）
8. 交代基準と費用負担（交代条件・リードタイム・引き継ぎ費用の取り扱い）
9. 契約条件・前提（準委任の確認・責任分界点・保守範囲・契約期間と更新条件）
10. 提案依頼事項（提案チーム構成・拠点・見積根拠・類似実績・セキュリティ体制）

記載粒度のコツは、確定している部分は具体的に、流動的な部分は「想定」「方向性」と明示して書くことです。すべてを断定せず、不確実性を不確実なまま正直に伝えるほうが、ベンダーはリスクを織り込んだ現実的な提案を返せます。とくに国内ラボ型では、4・5・6章（商習慣・法対応・対面体制）の記述の厚みが、オフショア前提のRFPとの差別化ポイントになります。

国内ラボ型のRFPに必要な要件を社内だけで言語化するのが難しい場合、要件整理から伴走してくれるパートナーに相談する選択肢もあります。riplaはフルスクラッチ受託を主軸としつつ、国内ラボ型や要件整理の伴走で、発注側が抱える「何を優先すべきか分からない」「委託先の妥当性を判断できない」「セキュリティ要件をどう書けばよいか分からない」といった課題に並走しています。

自社の業務要件と国内特有の前提に合わせて体制を組み立て、目的・優先順位・法対応・対面要件・交代基準まで含めた現実的なRFPに落とし込むことで、立ち上げ初期の空転を最小化できます。仕様が固まっていない段階での相談こそ、国内ラボ型を成功させる第一歩になります。

まとめ

国内ラボ型開発は、オフショアと同じ準委任契約のラボ型でありながら、RFPで問うべき要件の重心が大きく異なります。言語や時差、為替の論点が小さくなる分、発注側は個人情報保護法・セキュリティ・対面体制・地方拠点の安定性といった国内ならではの要件にしっかり力点を置く必要があります。日本語・国内商習慣を前提に要件を記述できることは、要件の解像度を保ったまま開発に渡せる大きな利点です。

委託先選定では、単価の安さではなく、セキュリティ認証・拠点の安定性・業務理解・対面対応力・ドキュメント文化という非価格の評価軸で横並び比較するのが定石です。国内ニアショアの単価相場や首都圏へのIT人材集中という統計を物差しにすれば、提案の妥当性も冷静に判断できます。仕様が固まっていない段階でこそ、国内特有の前提を踏まえた要件整理から伴走してくれるパートナーへの相談が、国内ラボ型を成功に導く近道になります。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。