開発の内製化を外部パートナーと進めるとき、最初の関門になるのがRFP（提案依頼書）や要件定義書の作成です。とくに内製化の場合、求めるのは「完成したシステムの納品」ではなく「自社が自分たちで開発・運用できるようになること」、すなわちノウハウの移譲そのものです。ところが、多くの企業がこのRFPを通常の受託開発と同じ感覚で書いてしまい、結果として「作ってもらって終わり」になり、内製の地力が育たないという失敗に陥ります。さらに、内製化は走りながら要件が変わることが前提なのに、社内の稟議は予算を固定したがる。この矛盾をどう乗り越えるかが、内製化のRFP・要件定義の最大の難所です。
本記事は、開発内製化のRFP・要件定義書・提案依頼書を、非IT人材の担当者でも書けるよう、推進する企業の視点から具体的に解説する記事です。ノウハウ移譲を目的に据えたRFPの書き方、非IT人材でも扱える要件の粒度、変動を前提としたRFPと予算固定を求める社内稟議をどう両立させるか、そして見積りの妥当性を判断する軸まで、内製化の実務に即して掘り下げます。読み終えるころには、伴走型パートナーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まず開発内製化の完全ガイドから読むことをおすすめします。
ノウハウ移譲を目的に据えるRFPの書き方
内製化のRFPが、通常の受託開発のRFPと決定的に異なるのは、その目的です。受託開発では「完成したシステムを納品してもらう」ことがゴールですが、内製化では「自社が自分たちで開発・運用できるようになる」ことがゴールです。この違いをRFPの冒頭で明確に宣言しないと、提案するパートナー側も、自社の担当者も、ゴールを見誤ります。
「移譲のゴール」をRFPに明記する
内製化RFPには、「プロジェクト終了時に、自社のどのメンバーが、どの範囲を、どのレベルで内製できるようになっているか」という到達目標を具体的に書きます。たとえば「機能追加を自社エンジニアだけで実装・リリースできる状態」「障害発生時に一次対応を自社で完結できる状態」といった形です。この移譲のゴールが明記されていれば、提案するパートナーは「作って渡す」のではなく「一緒に作りながら教える」進め方を提案せざるを得なくなります。
このゴール設定を怠ると、丸投げの失敗を招きます。外部に巨額を投じても自社にノウハウが残らなければ、NHKと日本IBMの約89.5億円委託が16か月の延伸を経て頓挫したような事態のように、自社でコントロールできないリスクを抱え続けます。内製化のRFPでは、成果物の仕様と同じ熱量で「移譲の到達目標」を定義することが、丸投げを防ぐ最大の防衛策です。ソースコードや設計ドキュメントの帰属が自社になることも、忘れずに要件として書き込みます。
伴走支援と育成プログラムを要件化する
ノウハウ移譲を実現するには、RFPに「伴走支援」と「育成」を明確な要件として盛り込みます。具体的には、ペアプログラミングやコードレビューを通じた技術移転、自社メンバーが主体的に手を動かす機会の設計、ドキュメントや標準化ルールの整備支援、定期的な勉強会やふりかえりの実施などです。これらを「あれば望ましい」ではなく「必須要件」として書くことで、伴走の実態が伴った提案を引き出せます。
育成の要件化では、自社メンバーの現在のスキルレベルも正直に開示します。「社内にエンジニアはいないが、Excelの関数やマクロを使える業務担当者はいる」「インフラの知識はないが、業務の理解は深い」といった実態を伝えれば、パートナーは現実的な育成プランを提案できます。スキルを過大に申告すると、移譲のペースが合わずに失敗します。内製化のRFPは、自社の現在地を正直に示し、そこからの成長プロセスを要件として描くことが大切です。この移譲を支える具体的な仕組みについては、詳しくは『開発内製化の必要機能や標準機能の一覧について』もあわせてご覧ください。
非IT人材でも書ける要件の粒度
内製化を主導する担当者は、必ずしもITの専門家ではありません。情報システム部門ではなく、業務改善やDX推進を任された非IT人材が、要件をまとめる立場に立つことも多いものです。だからこそ、要件を「非IT人材でも扱える粒度」に落とすことが、現実的なRFP作成の鍵になります。
技術用語でなく業務起点で要件を書く
非IT人材が要件を書くとき、無理に技術用語を使う必要はありません。むしろ「今、この業務に毎日何時間かかっていて、何が大変で、どうなったら嬉しいか」という業務起点の言葉で書くほうが、本質を外しません。たとえば「Excelで管理している受発注を、毎回手で転記していて月に40時間かかっている。これを自動化して、ミスもなくしたい」といった具体的な業務課題こそが、要件の出発点になります。技術的な実現方法は、パートナーと協働で詰めればよいのです。
業務起点で書く利点は、内製化のスモールスタートとも相性が良いことです。kintone（月1,000〜3,000円/ユーザー）やExcel業務のWeb化（月1万円〜）といったノーコード/ローコードツールは、まさに「Excel業務のアプリ化」から始める非IT部門のためのものです。要件を業務課題のレベルで明確にできていれば、こうしたツールで小さく内製を始める判断もしやすくなります。技術の言葉で身構えるより、業務の言葉で課題を正確に描くことが、非IT人材にとっての正しいRFP作りです。
AsIs/ToBeを現場の言葉で整理する
要件の粒度を整えるには、現状（AsIs）とあるべき姿（ToBe）を、現場の言葉で可視化するのが有効です。今どの業務を、誰が、どんな手順でやっているか（AsIs）を書き出し、それが内製化によってどう変わってほしいか（ToBe）を描く。この作業は技術知識がなくてもでき、しかも要件の漏れを防ぐ最良の方法です。現場の担当者へのヒアリングを通じて、明文化されていない例外処理や属人的な運用まで拾い上げることが、後の手戻りを防ぎます。
このAsIs/ToBeの整理は、内製化ならではの意味も持ちます。外注なら一度きりの要件定義で済むかもしれませんが、内製化では自社が継続的に改善していくため、「今どうなっていて、次にどこを変えるか」を考える習慣そのものが、内製の文化として根づきます。RFP作成のためのAsIs/ToBe整理は、単なる発注準備ではなく、内製化チームの思考の型を育てる訓練でもあるのです。非IT人材でも、現場の言葉でこの整理ができれば、十分に質の高い要件を描けます。
変動前提のRFPと社内稟議の両立
内製化のRFP・要件定義における最大の難所が、ここです。内製化は走りながら要件が変わるのが前提であり、最初にすべてを固められません。ところが、社内の稟議や予算承認は「いくらかかるのか、何ができるのか」を最初にFixすることを求めます。この「変動前提」と「予算固定」の矛盾をどう両立させるかが、内製化を社内で通すうえでの核心的な課題になります。
フェーズ分割で予算を段階的に承認する
変動前提と予算固定を両立させる第一の方法が、フェーズ分割です。プロジェクト全体を一度に承認しようとすると、変動する要件と固定したい予算がぶつかります。そこで、まず「スモールスタートで効果を検証するフェーズ」を小さな予算で承認し、効果が確認できたら「本格展開のフェーズ」をあらためて稟議にかける、という段階的な予算化を行います。各フェーズの予算は固定でき、フェーズ間で要件を見直せるため、両者の矛盾が解けます。
このフェーズ分割は、稟議を通すうえでも有利です。「いきなり数千万円」ではなく「まず数百万円で検証し、効果が出たら拡大」という提案は、経営層にとってリスクが小さく承認しやすいものです。星野リゾートが混雑可視化を1〜3か月で内製したような小さな成功を、まず一つ作る。その実績を稟議の根拠にすれば、次の投資は格段に通りやすくなります。フェーズ分割は、変動への対応と稟議の通しやすさを同時に実現する、内製化RFPの王道です。
準委任契約で変動する要件に対応する
契約形態の選択も、変動前提への対応に直結します。成果物を確定して発注する請負契約は、要件が固まっている場合に向きますが、内製化のように走りながら要件が変わる場合は、準委任契約が適しています。準委任契約は「成果物の完成」ではなく「専門的な労務の提供」に対して対価を払う形態で、伴走支援やナレッジ移譲のように、何をどこまでやるかが柔軟に変わる取り組みに馴染みます。RFPの段階で、どの契約形態を想定しているかを示しておくと、提案のミスマッチを防げます。
ただし、準委任契約は「成果物の完成義務がない」ため、漫然と進めると成果が曖昧になりかねません。これを防ぐには、フェーズごとに到達目標と中間成果物（動くプロトタイプ、移譲できたスキルの範囲など）を取り決めておくことです。請負の硬直性も、準委任の曖昧さも避け、「柔軟だが到達点は明確」という設計にする。契約形態とフェーズ設計を組み合わせることで、変動前提のRFPと予算固定を求める稟議を、無理なく両立できます。riplaはフルスクラッチ受託と伴走型パートナーの立場から、こうした契約とフェーズの設計も含めて、内製化の要件整理を支援しています。
見積りの妥当性を判断する軸
RFPをもとに集まった提案と見積りの妥当性を、どう判断すればよいのでしょうか。内製化の見積りは、通常の受託開発と費用の構造が異なるため、相場観を持って読み解くことが大切です。ここでは、内製化の見積りを評価する軸を整理します。
内製化支援の相場と移行コストの考え方
内製化の伴走支援の相場は、支援の範囲によって大きく変わります。一次データによれば、限定的な支援で月額100万円〜数百万円、全社的なDXの伴走となると数千万円〜億単位という幅があります。これに加えて、自社側で整える内製化体制の月額は、人件費20〜50万円、ツール費1〜10万円、教育費が初期に5〜20万円が目安です。見積りを読むときは、「伴走パートナーへの支払い」と「自社内製体制の運用費」を分けて把握します。
見積りの妥当性は、取引コスト理論で捉えると判断しやすくなります。内製化の総コストは「直接開発コスト＋外部調達コスト＋調整コスト＋移行コスト」で構成されます。一見すると伴走費（移行コスト）は割高に見えるかもしれませんが、これを払うことで調整コストを抑え、将来の外部調達コストを減らせます。目先の見積額だけでなく、「この投資で、将来どれだけ自社で回せるようになるか」という移譲の到達度まで含めて、費用対効果を判断することが大切です。
移譲度合いと内訳の透明性を確認する
内製化の見積りで特に注意すべきは、「どこまで自社に移譲されるか」が見積りに反映されているかです。安い見積りは、伴走や育成の工数が削られ、結局は「作って渡すだけ」になっている可能性があります。逆に、ペアプログラミングや勉強会、ドキュメント整備支援といったナレッジ移譲の工数がきちんと積まれている見積りは、一見高くても、内製の地力を育てる本来の目的に適っています。見積りの内訳に「移譲のための工数」が明示されているかを必ず確認します。
また、「ディレクション費」「教育費」が一式でまとめられている場合は、内訳の開示を求めます。何にどれだけの工数がかかり、その結果として自社が何をできるようになるのかが見える見積りこそ、信頼できる提案です。RFPで移譲のゴールを明確にしておけば、パートナーはそれに応じた具体的な工数を示さざるを得ません。要件定義の精度が、見積りの妥当性判断の精度を決めます。riplaはフルスクラッチ受託と伴走型パートナーの立場から、移譲の到達目標と工数を透明に示す進め方を重視しています。
まとめ
開発内製化のRFP・要件定義書・提案依頼書は、通常の受託開発と違い「成果物の納品」ではなく「ノウハウ移譲」を目的に据えるのが鉄則です。要件は技術用語ではなく業務起点の言葉で書き、非IT人材でも扱える粒度に落とす。そして、内製化につきものの「変動前提」と社内稟議が求める「予算固定」の矛盾は、フェーズ分割と準委任契約という設計で両立させる。見積りは、ナレッジ移譲の工数が明示されているかを確認し、移譲の到達度まで含めて費用対効果を判断します。
移譲のゴールを明記しないRFPは、巨額を投じても自社にノウハウが残らず、外部依存のリスクを抱え続けます。業務起点の要件、フェーズ分割、準委任契約、移譲工数の確認という4点を押さえれば、「作ってもらって終わり」を避け、内製の地力を育てられます。riplaはフルスクラッチ受託と伴走型パートナーを組み合わせ、業務起点の要件整理から移譲のゴール設定、フェーズ・契約設計までを協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。