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

国内ラボ型開発を成功させる起点になるのは、発注側が準備するRFP(提案依頼書)と要件定義書です。

国内ラボ型では、要件の重心を言語や時差から、国内法・セキュリティ・対面体制・地方拠点へ移して書きます。全体像はラボ型開発の完全ガイドでも解説しています。

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

オフショア前提と国内ラボ型で、RFPに記載する論点の違いを左右に並べた図。
委託先に合わせて、RFPの重点も移ります。

国内ラボ型開発も、法的にはオフショアと同じく準委任契約に該当します。そのため、成果物の完成ではなく、一定期間の稼働(チームの確保)が対価になります。この点は、ラボ型に共通する基本構造です。

ただし、委託先が国内のニアショア拠点の場合、RFPで問うべき論点の力点がオフショアとは変わります。オフショアと同じ感覚でRFPを書くと、せっかくの国内委託の強みを引き出せません。

両者の最大の違いは、言語と時差の障壁が小さいことです。オフショアでは、ブリッジSEの日本語レベルや英語でのコミュニケーション設計がプロジェクトの生死を分けますが、国内ラボ型ではこの負荷がほぼ消えます。

その代わり、発注側はRFPの記述の力を別の論点へ振り向ける必要があります。その論点とは、国内法・セキュリティ・対面体制・地方拠点の安定性です。

「言語の心配が要らない分、何を要件に書くべきか」を再設計するのが、国内ラボ型RFPの出発点です。

オフショア前提のRFPとの違い

オフショア前提のRFPでは、ブリッジSEの配置、日本語または英語の運用ルール、時差を吸収する非同期コミュニケーションの設計が、記載項目になります。

為替変動やカントリーリスクへの対応条項も重要です。

これらは海を越えた委託に固有の論点で、要件定義書のかなりの分量を占めます。一方、国内ラボ型のRFPでは、これらの多くが不要か、大幅に簡略化できます。

代わって前面に出てくるのは、個人情報を国内サーバで保管する要件、委託先のセキュリティ認証の有無、対面での定例やワークショップの頻度といった、国内委託ならではの要件です。

地方拠点の人材確保の安定性も、国内委託ならではの論点です。

同じラボ型のRFPでも、要件の重心は「言語・時差・為替」から「法対応・セキュリティ・対面・拠点」へ移ります。この違いを押さえると、書き分けが明確になります。

両者の論点の違いは、次のように整理できます。

  • 言語と時差:オフショアでは重い負荷になるが、国内ラボ型ではほぼ消える
  • 国内ならではの論点:国内法・セキュリティ・対面・地方拠点の安定性

国内でも欠かせない要件整理

国内ラボ型も「仕様が固まっていなくても始められる」柔軟性が魅力です。ただし、稼働に対価を払う以上、発注側の示し方があいまいだと、確保したエンジニアの工数が空転します。

国内だからすぐに相談できるという安心感が、かえって「要件は後で詰めればよい」という油断を生みやすい点には注意が必要です。

準委任契約におけるベンダーの責任は善管注意義務(善良な管理者としての注意義務)の範囲にとどまり、特定の成果物の完成を保証するものではありません。そのため、バグ修正の負担範囲や不具合の責任分界点は、国内ラボ型でもRFPと契約の段階で明確にしておく必要があります。

委託先が国内で連絡を取りやすいからといって口頭の合意で済ませると、後の保守範囲をめぐって揉める原因になります。

riplaが要件整理の伴走で重視するのも、この責任分界をプロジェクト初期に文書で決めておく点です。

柔軟さを生かしつつ空転を防ぐため、発注側は次の2点を示します。

  • 優先順位:チームが何を先に進めるべきかを、発注側が示す
  • 責任の境目:バグ修正の範囲と不具合の責任分界点を、RFPと契約の段階で決める

ポイント

言語や時差の負担が小さくなる分、RFPで力を入れて書く論点を国内法・セキュリティ・対面・地方拠点へ移せているかが、迷ったときの判断の目安になります。

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

国内ラボ型RFPで重視する日本語と商習慣、国内法とセキュリティ、対面と地方拠点の3領域を示す図。
3領域をそろえると、国内委託の強みを要件に反映できます。

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

日本語・国内商習慣を前提にした要件記述

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

RFPでは、社内の業務フローを前提に要件を書いておくと、認識のずれを減らせます。

商習慣の前提も、重要な要件です。日本の業務システムには、稟議・承認フローや見積から請求までの商流といった国内特有の仕様が頻出します。和暦や年度の扱い、取引先ごとの帳票フォーマットも、同じく国内ならではの要件です。

こうした仕様を「説明しなくても理解してくれる」と期待するなら、委託先が国内の業務システム開発に慣れているかを、RFPの前提条件として確認すべきです。商習慣の理解度は、要件を伝えるコストを左右します。

言語と商習慣は、次の2つの観点で書き分けます。

  • 言語:要件定義書や設計書の言語と、用語集の整備方針を明記する
  • 商習慣:国内特有の業務仕様に慣れた委託先かどうかを、前提条件として確かめる

RFPで明示しておきたい商習慣・言語まわりの要件は、次のとおりです。

・要件定義書・設計書・議事録を日本語で作成し、管理できること

・国内特有の業務仕様(稟議フロー、和暦、年度処理、帳票要件など)への対応経験

・社内の既存システムや業務用語を前提とした要件のすり合わせ体制

・問い合わせや確認への日本時間での応答

これらを前提にすれば、伝達のロスを抑えたチーム編成を、ベンダーに提案してもらえます。

国内法・セキュリティ要件の明文化

国内ラボ型を選ぶ理由として最も多いのが、個人情報や機密情報の取り扱いに関する安心感です。

RFPでは、個人情報保護法への準拠を明文化します。

海外にデータを置かないこと自体が要件になるケースも多く、この条件は国内委託でこそ満たしやすいものです。

委託先のセキュリティ体制も評価対象です。プライバシーマークやISMS(ISO/IEC 27001)などの認証の保有、秘密保持契約(NDA)の締結範囲を確認します。

RFPでは、開発環境のセキュリティ(端末管理・ネットワーク分離・ログ監査)への対応も問います。

金融・医療・公共など規制の厳しい業界では、業界固有のガイドラインへの対応経験も要件に加えると、後の監査対応がスムーズになります。

法対応とセキュリティは、次の2つの軸で固めます。

  • データの扱い:国内保管、再委託の範囲、アクセス権限の管理方針
  • 委託先の体制:認証の保有状況、秘密保持契約、業界固有の規制への対応実績

RFPに盛り込むセキュリティと法対応の確認項目は、次のとおりです。

・個人情報保護法その他の国内関連法令への準拠と対応体制

・プライバシーマーク/ISMSなどのセキュリティ認証の保有状況

・業界固有の規制やガイドライン(金融・医療・公共など)への対応実績

これらは委託先の信頼性を判断する客観的な基準になり、提案各社を横並びで比べやすくなります。

対面・地方拠点の要件の決め方

国内ラボ型の隠れた強みは、必要なときに対面で集まれることです。

すべてをオンラインで済ませるオフショアとは、ここが決定的に異なる要件です。

地方拠点の前提も、国内ラボ型に固有の論点です。国内ニアショアは地方都市の開発拠点を活用してコストを抑える形が多く、委託先がどの拠点で何名の体制を組めるかが、確保人数の安定性に直結します。その背景には、日本のIT人材が首都圏に集中し、地方の人材プールに限りがあることがあります。

RFPでは、「どの拠点で、何名を、どのくらいの期間継続的にアサインできるか」を確認しておくと、立ち上げ後の増員可否を現実的に見積もれます。

対面と拠点の要件は、次の2つで決めます。

  • 対面の場面:キックオフやワークショップなど、対面で行う定例を決める
  • 拠点と人数:主たる拠点で何名を、どの期間アサインできるかを数字で示させる

新規事業の立ち上げ期や、業務理解が深く求められる基幹系の刷新では、最初のワークショップや要件のすり合わせを対面で行うと、認識のずれが一気に減ります。

RFPでは、対面の頻度の例(キックオフは対面、月次は対面、週次はオンライン)を挙げ、出張・常駐の要否、想定する移動コストの負担者も明記します。

体制要件は職種別に書き出すのが基本で、PM・シニアエンジニア・ジュニアエンジニア・QA担当などの人数・役割・想定稼働率を提示します。

国内ラボ型では、ここに「主たる拠点」「対面対応の可否」「増員時の人材供給見込み」を加えると、精度が上がります。

ラボ型でチームが提供する役割には、専属チーム確保、継続アサイン、ナレッジ蓄積、スプリント運用、品質保証体制などがあります。その全体像は、兄弟記事「国内/日本ラボ型開発の必要機能や標準機能の一覧について」で整理しています。

ポイント

迷ったときは、どの要件が自社の業務と国内委託の強みに直結するかで優先順位を決めると、書き分けがぶれにくくなります。

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

国内ラボ型のRFPで体制と予算を現実的に組むには、国内ニアショアの単価相場とオフショアとの差、そして国内の人材供給状況を知っておく必要があります。次に示すのは、その一次データです。

これらは、提案の金額や体制が妥当かを測る「妥当性の物差し」になります。

国内ニアショアとオフショアの単価レンジ

当社が把握している月額単価レンジを、国内ニアショアとオフショアに分けて示します。

  • 国内ニアショア:ジュニア約52.8〜84.7万円/シニア約68〜100万円/PM約85〜138万円
  • オフショア:ベトナムはジュニア30〜40万円/シニア40〜60万円/ブリッジSE約59〜88万円/PM約70〜160万円、インドネシアは20〜30万円

ベトナムのオフショアでシニアの平均単価は約48万円です。

このほか、お試しとして1人月30〜35万円程度のパイロット契約で立ち上げの相性を見るケースもあります。

国内ニアショアはオフショアより単価が高い傾向にあります。その分を、言語・時差・品質面の安心感とすり合わせの速さで回収する、というのが選定の基本的な考え方です。

この相場を踏まえると、RFPで「PM1名+シニア2名+ジュニア2名」といった体制を求めたとき、国内ニアショアとオフショアそれぞれの月額を概算できます。

提案された見積がこのレンジから外れていれば、その根拠をベンダーに確認すべきです。

国内ラボ型では、単価の高さを受け入れる代わりに、セキュリティや対面体制といった非価格要件の充足を強く求めます。このトレードオフを意識して予算を配分するのが現実的です。

国内IT人材の偏在とニアショアの背景

国内ラボ型の体制要求が現実的かどうかは、国内の人材供給状況に左右されます。日本のIT人材は約125万人とされ、そのうち約76万人が首都圏に集中しています。

地方のIT人材は枯渇傾向にあり、この偏在こそが国内ニアショア(地方拠点の活用)が注目される構造的な背景です。

国内ニアショアの担い手としては、ニアショアIT協会に正会員93社・技術者約5,000名が参画しています。この規模感は、首都圏に集中する人材を地方拠点で補完しようとする業界全体の動きを示しています。

参考までにオフショア側の供給状況を見ると、ベトナムのIT労働人口は約126万人で、2030年までに300万人を育成する国家計画が進んでいます。

AI技能保有者は約8.5万人(2023年以降で約340%増)にのぼります。

豊富な人材を確保しやすいスケーラビリティはオフショアの強みです。委託先の選定では、この強みと、国内の安心感や近接性とを比べることが要点になります。

国内の人材供給は、次の2点で確かめます。

  • 拠点の人数:その地域で確保できる人数を、委託先に具体的な数字で確認する
  • オフショアとの比較:海外の供給規模を参考にしつつ、国内の人材供給を見る

ポイント

提案された見積が国内ニアショアとオフショアの単価レンジから外れている場合は、その根拠を示してもらうことが判断の出発点になります。

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

国内ニアショア委託先を比較するセキュリティ、拠点、業務理解、対面、ドキュメントの5項目。
同じ項目で提案を並べると、単価以外の差が見えます。

RFPを各社に提示したあと、返ってきた提案をどの評価軸で比較するかが、国内ラボ型の成否を分けます。

オフショアでは単価とスケーラビリティが評価の中心になりがちですが、国内ニアショアでは非価格要件の比重が高くなります。発注側は、単価の安さより「自社の要件に最も合うか」で選ぶべきです。

非価格の評価軸とKPI・交代基準

単価の比較だけでは足りず、非価格の面で委託先の信頼性と体制を見ます。

  • 比べ方:単価の安さではなく、自社の要件にどこまで合うかで点数化する
  • セキュリティ:プライバシーマーク/ISMSの保有、国内データ保管、再委託の管理

・拠点の安定性:主たる開発拠点、その地域での人材確保力、増員時の供給見込み

・業務理解:国内の業務システム・商習慣に関する実績、対象業界のドメイン知識

・対面対応力:キックオフやワークショップの対面対応、必要時の常駐・出張の可否

・ドキュメント文化:日本語での設計書・議事録の整備、ナレッジ蓄積の仕組み

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

あわせて、ラボ型に共通するKPIと交代基準もRFPで定義します。準委任契約では稼働が対価になるため、KPIにはスプリントごとのベロシティや計画消化率を置きます。また、重大バグの件数と平均修正時間は、「進め方が機能しているか」を測る運用指標として置きます。

RFPでは、週次・月次の報告サイクルを明記し、稼働の空転を早期に発見できる仕組みを要件化しておくことが、立ち上げ失敗の回避につながります。

要員交代の基準と費用負担も、国内ラボ型では必ずRFPと契約に入れておきます。具体的には、交代を申し入れる基準と評価期間、新メンバーのアサインまでのリードタイム上限を決めます。引き継ぎ期間中の重複稼働費用を誰が負担するか、また退職などベンダー都合の交代で無償引き継ぎをどこまで行うかも、明確にしておきます。

国内であってもメンバーの退職やスキルのミスマッチは起こり得ます。だからこそ、交代の条件を事前に決めておく必要があります。

「ベンダー都合の交代に伴う引き継ぎ稼働は無償」「発注側都合の交代は事前通知から所定日数以内に対応」といった条件を提示して各社の回答を比べると、体制の安定性に対する本気度が見えます。

長期運用を見据えた事例の示唆

交代やナレッジ蓄積の仕組みが機能すると、ラボ型は段階的に拡大できます。たとえば富士フイルムヘルスケアとFPTの取り組みでは、小規模なラボから始まり、約15年をかけて170名規模の統合開発ラボへと拡大しています。

医療機器ソフトという高い品質が求められる領域で、この規模まで成長できた背景には、初期からのナレッジ蓄積と体制の継続性がありました。

これはオフショアの事例ですが、ナレッジを資産として積み上げる設計の重要性は、国内ラボ型にもそのまま当てはまります。

国内ラボ型では、対面でのすり合わせや日本語ドキュメントの文化を活かすことで、ナレッジの蓄積と継承を一段と進めやすくなります。RFPで対面体制とドキュメント整備の義務を要件に入れておくことは、目先のトラブル回避だけでなく、地方拠点のチームを長期的な資産として育てられるかを左右する投資でもあります。

発注側が近いからと口頭中心で進め、ナレッジを文書化しなければ、人の入れ替わりのたびにキャッチアップが発生し、拡大どころか縮小に向かいます。

長期運用の前提として、次の2点を確認します。

  • 交代の仕組み:要員交代の基準と引き継ぎの費用負担を、契約前に決めておく
  • ナレッジの文書化:口頭中心で進めず、ナレッジを文書で残す

ポイント

委託先は単価の安さより、自社の要件にどこまで合うかを基準に比べると、非価格の評価軸で差が見えやすくなります。

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

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

RFP章立てと記載粒度

RFPの章ごとに盛り込む内容は、体制・法対応・対面・契約など、判断に関わる項目ごとに分けて書きます。

  • 構成:目的から提案依頼まで、10章に分けて順に書く
  • 1. プロジェクト概要・目的・ビジネスゴール

2. スコープと優先順位(機能の仕分け、やらないことの明記)

3. 求める体制とスキル要求を書きます(職種別人数・役割・主たる拠点・対面対応の可否・増員見込み)。

4. 日本語・国内商習慣を前提とした要件記述の方針を書きます(ドキュメント言語・業務仕様の対応経験)。

5. 国内法・セキュリティ要件を書きます(個人情報保護法準拠・国内保管・認証保有・再委託管理)。

6. 対面/オンラインの稼働要件(定例の頻度・常駐や出張の要否・移動費の負担)

7. KPIと報告サイクル(ベロシティ・消化率・バグ指標、定例の頻度と内容)

8. 交代基準と費用負担(交代条件・リードタイム・引き継ぎ費用の取り扱い)

9. 契約条件・前提(準委任の確認・責任分界点・保守範囲・契約期間と更新条件)

10. 提案依頼事項を書きます(提案チーム構成・拠点・見積根拠・類似実績・セキュリティ体制)。

記載粒度のコツは、確定している部分は具体的に、流動的な部分は「想定」「方向性」と明示して書くことです。すべてを断定せず、不確かな部分は不確かだと正直に伝えるほうが、ベンダーはリスクを織り込んだ現実的な提案を返せます。

とくに国内ラボ型では、4・5・6章(商習慣・法対応・対面体制)の記述の厚みが、オフショア前提のRFPとの差別化ポイントになります。

要件整理を伴走する選択肢

国内ラボ型のRFPに必要な要件を社内だけで言語化するのが難しい場合、要件整理から伴走してくれるパートナーに相談する選択肢もあります。

riplaは、フルスクラッチ受託を主軸としつつ、国内ラボ型や要件整理の伴走も手がけています。発注側が抱える「何を優先すべきか分からない」「委託先の妥当性を判断できない」「セキュリティ要件をどう書けばよいか分からない」といった課題に、並走しています。

こうした伴走では、自社の業務要件と国内特有の前提に合わせて体制を組み立て、目的・優先順位・法対応・対面要件・交代基準まで含めた現実的なRFPに落とし込みます。その結果、立ち上げ初期の空転を最小限に抑えられます。

仕様が固まっていない段階から相談するのが、国内ラボ型を成功させる第一歩です。

相談の前に、次の2点を社内で整理しておくと役立ちます。

  • 優先順位:何を先に作るべきかを、業務要件と照らして決める
  • 判断の基準:委託先の提案が妥当かを、単価と非価格の評価軸で確かめる

まとめ

国内ラボ型開発は、オフショアと同じ準委任契約のラボ型でありながら、RFPで問うべき要件の重心が異なります。

言語や時差、為替の論点が小さくなる分、発注側は個人情報保護法・セキュリティ・対面体制・地方拠点の安定性といった国内ならではの要件に、しっかり力点を置く必要があります。

日本語・国内商習慣を前提に要件を記述できることは、要件の解像度を保ったまま開発に渡せる大きな利点です。

委託先の選定では、単価よりも非価格の評価軸で横並びに比べるのが定石です。セキュリティ認証、拠点の安定性、業務理解などが、その中心になります。

国内ニアショアの単価相場や、首都圏へのIT人材集中という統計を基準にすれば、提案の妥当性も冷静に判断できます。

要件整理を伴走してくれるパートナーへの早めの相談が、国内ラボ型を成功に導く近道になります。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。