スクラッチ開発のRFP/要件定義書/提案依頼書について

スクラッチ開発を成功させられるかどうかは、開発が始まる前の「要件定義」と、それを開発会社へ正確に伝える「RFP（提案依頼書）」の出来でほぼ決まる、と言っても過言ではありません。ゼロから自由に作れるスクラッチは、裏を返せば「何を作るかを発注企業が決めなければならない」開発です。要件が曖昧なまま走り出すと、認識のズレから手戻りが多発し、工数が膨らみ、予算もスケジュールも崩壊します。だからこそ、RFPと要件定義書をどう作り込むかが、数百万から数千万円の投資を守る最大の防波堤になります。

本記事は、スクラッチ開発のRFP・要件定義書・提案依頼書を、発注企業が主体的に作り込むための実務に絞った解説です。RFPに何を書くべきか、機能要件と非機能要件をどう整理するか、見積もりの妥当性をどうチェックするか、そしてAIが生成したコードをどう検収するかという新しい論点まで、一次データを交えて具体的に解説します。なお、費用相場や開発手法、契約まで含めたスクラッチ開発の全体像をまだ把握していない方は、まずスクラッチ開発の完全ガイドから読むことをおすすめします。この記事を読めば、ベンダーに丸投げせず、主導権を握って発注するための準備が整います。

▼全体ガイドの記事
・スクラッチ開発の完全ガイド

スクラッチ開発のRFPに盛り込むべき項目

RFP（提案依頼書）は、開発会社に「こういうシステムを作りたいので、提案と見積もりをください」と依頼するための文書です。スクラッチ開発では作るものが完全に白紙であるため、RFPの質がそのまま各社からの提案の質を決めます。漠然としたRFPには漠然とした提案しか返ってこず、見積もりも各社バラバラで比較できません。逆に的を射たRFPは、各社の実力差を浮き彫りにし、適正な見積もりを引き出します。

RFPの最初に書くべきは、機能の細かい話ではなく「なぜこのシステムを作るのか」という背景・目的・解決したい課題です。今どんな業務の困りごとがあり、それをシステムでどう解決し、最終的に何を達成したいのか。この目的が明確だと、開発会社は単なる御用聞きではなく、目的達成のための最適な提案をしてくれます。逆にここが曖昧だと、言われたものをそのまま作るだけの受け身の提案しか返ってきません。

目的を言語化する際は、できるだけ定量的な目標を添えると効果的です。「受注処理にかかる時間を半分にしたい」「月次の締め作業を3日短縮したい」といった具体的な目標があると、開発会社はその達成に必要な機能を逆算して提案でき、後の効果検証の基準にもなります。スクラッチ開発は手段であって目的ではありません。RFPの冒頭で「何のために作るのか」を明確に示すことが、プロジェクト全体の羅針盤になります。この目的が、後の仕様変更の際にも「やるべきか否か」を判断する基準として機能します。

背景・目的に加えてRFPに記載すべき基本項目が、想定予算、希望する納期、自社側の推進体制、既存システムの状況、そして開発会社に求める実績や条件です。とくに予算感を示すことをためらう発注者は多いのですが、概算でも予算の幅を伝えた方が、現実的な提案が返ってきます。予算を伏せると、各社が思い思いの規模で提案してしまい、比較が難しくなります。

納期についても、絶対に動かせない期限があるなら明記します。法改正対応や繁忙期前のリリースなど、背景とともに伝えると、開発会社はスケジュールの妥当性を含めて提案できます。スクラッチ開発の期間は、小規模で1〜3ヶ月、中規模で3〜6ヶ月、大規模になると6ヶ月以上が一般的な目安です。非現実的な短納期を要求すると、品質が犠牲になるか、対応できる会社が限られます。RFPに基本項目を漏れなく書くことで、提案各社が同じ前提で見積もれるようになり、比較の精度が上がります。

機能要件と非機能要件の解像度を上げる

要件定義の中核が、機能要件と非機能要件の整理です。機能要件は「システムが何をするか」、非機能要件は「どれくらいの性能・品質・安全性で動くか」を指します。スクラッチ開発では両方を発注企業が主体的に定める必要があり、とくに非機能要件は見落とされやすいにもかかわらず、費用と品質に大きく影響します。ここの解像度を上げることが、後の手戻りと追加費用を防ぎます。

機能要件を整理する際のコツは、必要な機能を列挙するだけでなく、それぞれに優先順位をつけることです。「必須」「あると望ましい」「将来的に検討」といった区分を設けておくと、予算やスケジュールの制約に応じて、どこまでを最初のリリースに含めるかを判断しやすくなります。スクラッチ開発はMVPから段階的に拡張するのが王道であり、優先順位づけはこの段階主義を実現する前提になります。

機能要件を書くときは、現場の業務フローに沿って洗い出すと漏れが減ります。誰が・いつ・どんな操作をするのかを業務の流れに沿って書き出すことで、つながりのある一連の機能として整理できます。とくに自社固有の独自ロジックや例外処理は、開発会社が想像で補えない部分なので、丁寧に言語化します。要件が曖昧だと工数が1.3〜1.5倍に膨張するという指摘もあり、機能要件の解像度の低さは、そのまま費用増とスケジュール遅延に直結します。優先順位と業務フローという二つの軸で整理することが、実務上のポイントです。

非機能要件は、機能要件の影に隠れて見落とされやすい一方で、費用とリスクに大きく影響する領域です。具体的には、何人が同時に使うか、何秒以内に画面が表示されるべきか、どれくらいのデータ量を扱うか、どの程度のセキュリティ水準を求めるか、障害時にどれくらいで復旧すべきか、といった項目です。これらが曖昧なまま開発が進むと、いざ本番で「動きが遅い」「同時アクセスに耐えられない」といった問題が噴出します。

非機能要件の解像度を上げるには、できるだけ数値で示すことが大切です。「速くしてほしい」ではなく「主要画面は3秒以内に表示」、「安全に」ではなく「個人情報は暗号化し、アクセスログを保持」といった形です。これらの水準が高いほど開発費は上がるため、自社にとって本当に必要な水準を見極める必要があります。過剰な非機能要件はコストの無駄ですが、不足は本番障害の温床になります。RFPの段階でこの非機能要件を具体的に示しておくと、開発会社の見積もりも現実的になり、後から「これは聞いていなかった」という追加費用のトラブルを避けられます。

見積もりの妥当性チェックと隠れコストの見抜き方

RFPを出して複数社から見積もりが返ってきたとき、発注企業がもっとも頭を悩ませるのが「この見積もりは妥当なのか」という判断です。スクラッチ開発の見積もりは「人月単価×工数」が基本構造であり、この仕組みを理解しておくと、各社の見積もりを冷静に比較できます。安すぎる見積もりには裏があり、逆に高い見積もりにも理由があります。妥当性を見抜く目を持つことが、適正な発注の前提です。

見積もりの妥当性を判断する第一歩は、人月単価と工数の内訳を確認することです。人月単価は職種や体制によって幅があり、目安として、フリーランスで50万〜80万円、中小開発会社で80万〜120万円、大手SIerになると150万〜200万円程度とされます。職種別では、プロジェクトマネージャーが110万〜150万円、設計を担うシステムエンジニアが65万〜110万円、実装のプログラマーが50万〜90万円といった水準が一つの目安です。

見積書を見るときは、総額だけでなく、どの工程に何人月かかると見込んでいるかの内訳に注目します。一般に、要件定義に全体工数の約20%、設計からテストに約80%が割かれ、人件費は開発費全体の40〜60%を占めるとされます。請負契約では人月計算に1.3〜1.5倍の係数が乗り、リスクバッファとして全体の10〜20%が見込まれるのが一般的です。内訳が示されない「一式いくら」の見積もりは、後で追加請求のトラブルになりやすいため、必ず工程ごとの内訳を求めましょう。透明性の高い見積もりを出す会社ほど、信頼できる傾向があります。

見積もりの妥当性を判断するうえで、初期開発費と同じくらい重要なのが、リリース後にかかり続ける「隠れコスト」です。スクラッチ開発は作って終わりではなく、運用・保守が続きます。サーバーやクラウドの利用料、外部APIの従量課金、保守契約費、機能追加の改修費といったランニングコストが、毎月・毎年積み上がっていきます。この試算を怠ると、初期費用は予算内でも、運用が始まってから家計が圧迫されます。

保守費用は一般に、年あたりで初期開発費の15〜25%、月額換算で初期開発費の5〜15%が目安とされます。たとえば1,000万円で開発したシステムなら、年150万〜250万円程度の保守費が継続的にかかる計算です。RFPの段階で「リリース後の運用・保守にいくらかかるか」を各社に見積もらせ、初期費用と運用費を合算した総保有コストで比較することが、賢い発注の鉄則です。発注検討企業の4〜5割が「費用対効果が分からない」を課題に挙げるとされますが、その多くは、この隠れコストまで含めた全体像を描けていないことに原因があります。

AI時代の検収基準と品質保証の取り決め

近年のスクラッチ開発では、開発会社が生成AIを使ってコードを書くケースが急速に増えています。これは開発を効率化する一方で、発注企業にとっては新しい検収上の論点を生みます。AIが生成したコードの品質をどう担保するのか、不具合の責任は誰が負うのか。RFPと要件定義の段階で、こうしたAI時代特有の検収基準と品質保証の取り決めを盛り込んでおくことが、これからの発注では欠かせません。

AIが生成したコードは、一見動いているように見えても、セキュリティ上の脆弱性や、想定外の条件で破綻するロジックを含んでいることがあります。いわゆる「とりあえず動くものを生成する」開発スタイルに丸ごと依存すると、表面的には完成していても、内部に見えない欠陥を抱えるリスクがあります。発注企業としては、納品物がAIの生成物であっても、人間による適切なレビューとテストを経ているかを検収基準として確認する必要があります。

具体的には、要件定義やRFPの段階で、テストの範囲と方法、セキュリティ診断の実施有無、コードレビューの体制を取り決めておきます。LLM（大規模言語モデル）を組み込んだシステムの場合は、AIが誤った回答を返すハルシネーションをどこまで許容するか、その検証方法も検収基準に含めるべきです。「動けばよい」ではなく「自社の要件と品質基準を満たしているか」を確認する仕組みを、契約と検収のプロセスに組み込むことが、AI時代の発注者を守ります。

スクラッチ開発の要件定義・RFPでは、成果物の権利関係を明確にしておくことも欠かせません。著作権法では、開発したプログラムの著作権は原則として制作した受託者側に帰属します。発注企業が自由にシステムを改修・転用したい場合は、契約で著作権を譲渡する旨を明記する必要があり、その際は著作権法27条・28条に定める権利も含めて譲渡を明記するのが実務上のポイントです。これを怠ると、後で他社に改修を頼めない、といった事態になりかねません。

契約形態についても、RFPの段階で意識しておきましょう。完成責任を負う請負契約と、善管注意義務のもとで作業を行う準委任契約では、責任範囲が異なります。要件が固まっている部分は請負、探索的に進める部分は準委任、といった組み合わせも有効です。これらの権利・契約条項は専門的な領域なので、要件定義から契約・保守まで一貫して対応できる開発会社を選ぶことが、トラブル回避につながります。riplaはフルスクラッチ受託の立場から、RFP作成段階での要件整理や、AI時代の検収基準・契約条項の検討まで、発注企業が主導権を握れるよう伴走しています。

まとめ

スクラッチ開発のRFP・要件定義書を作り込むうえで重要なのは、背景・目的・課題を冒頭で言語化し、機能要件は優先順位とともに、非機能要件は性能・セキュリティ・データ量を数値で具体化することです。そのうえで、人月単価と工数の内訳を確認して見積もりの妥当性を判断し、保守費（年あたり開発費の15〜25%が目安）といったリリース後の隠れコストまで含めた総保有コストで比較します。さらに、AIが生成したコードの検収基準や、著作権・契約条項といった新旧の論点を取り決めておくことが、発注者を守ります。

要件が曖昧だと工数が1.3〜1.5倍に膨らむとされるように、要件定義とRFPの精度は、そのままプロジェクトの成否と費用に直結します。ベンダーに丸投げするのではなく、発注企業が主体的に目的と要件を定め、主導権を握ることが、スクラッチ開発成功の最大の条件です。riplaはフルスクラッチ受託と国内開発を組み合わせ、RFP作成や要件整理の段階から伴走し、発注企業が納得して発注・検収できるよう支援します。要件を固める前に全体像を確認したい方は、あらためて完全ガイドもご活用ください。

株式会社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を創業。