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