スクラッチ開発は、目的・要件・見積もり・検収の順に進みます。要件が曖昧だと手戻りで工数が増え、予算や日程が崩れます。
RFPと要件定義書の作り込みは、数百万〜数千万円の投資を守り、発注側が主導権を握るための準備になります。全体像はスクラッチ開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・スクラッチ開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
スクラッチ開発のRFPに盛り込む項目
RFP（提案依頼書）は、開発会社にシステムの提案と見積もりを依頼する文書です。スクラッチ開発は作るものが白紙の状態から始まるため、RFPの質が提案の質を左右します。
RFPの内容が漠然としていると、提案も曖昧になり、各社の見積もりを比べにくくなります。一方、目的に沿って書かれたRFPなら、各社の実力の差が見えるとともに、適正な見積もりを得る材料になります。
背景・目的・課題の言語化
機能の詳細より先に、なぜそのシステムを作るのかをRFPに書いておく必要があります。背景・目的・解決したい課題を示し、業務上の困りごとと、システムで達成したいことを明確にします。
- 現状の課題：いま困っている業務の具体的な内容
- 達成目標：「受注処理にかかる時間を半分にしたい」など、数値で測れる目標
- 解決の目的：システムの導入で実現したいこと
目標が具体的であれば、開発会社は達成に必要な機能を逆算して提案でき、導入後の効果を検証する基準にもなります。月次の締め作業を3日短縮する、といった目標もその一例です。
スクラッチ開発は目的を実現する手段で、目的そのものではありません。そのため、目的は仕様変更の要否を判断する基準になり、プロジェクト全体の指針にもなります。さらに、目的が明確であれば、開発会社は言われたものを作るだけの御用聞きにとどまらず、達成に向けた提案もしやすくなります。
予算・納期・体制など基本項目の記載
背景と目的に加えて、RFPには基本情報も書いておきます。提案各社が同じ前提で見積もれるようにするためです。
- 想定予算：概算でも幅を伝えると現実的な提案を得やすい
- 希望納期：動かせない期限と、その背景
- 推進体制：自社側の担当体制
- 既存環境と実績条件：既存システムの状況と、開発会社に求める実績・条件
予算を伏せたままだと、各社が異なる規模で提案してしまい、比較が難しくなります。納期の背景に法改正への対応や繁忙期前のリリースがあるなら、あわせて伝えておきます。
スクラッチ開発の期間の目安は、小規模で1〜3ヶ月、中規模で3〜6ヶ月、大規模で6ヶ月以上とされています。この目安があれば、開発会社は希望納期が妥当かどうかも検討できます。
非現実的に短い納期を求めると、品質が犠牲になるか、対応できる会社が限られてしまいます。基本項目を揃えておくと、提案各社の見積もりを同じ条件で比べられます。
機能要件と非機能要件の解像度
要件定義の中核は、機能要件と非機能要件を整理することです。機能要件はシステムが何をするかを示し、非機能要件は性能・品質・安全性をどの水準で満たすかを示します。
スクラッチ開発では、発注企業が両方を主体的に定める必要があります。とくに見落とされやすい非機能要件は、費用と品質に大きく影響し、曖昧なままだと手戻りや追加費用につながります。
機能要件の優先順位付け
機能要件は並べるだけでなく、最初のリリースに含める範囲を判断できるように、優先順位を付けておきます。
- 必須：初回リリースに必要な機能
- あると望ましい：予算や日程に応じて含める機能
- 将来的に検討：初回リリース後に検討する機能
スクラッチ開発では、MVP（Minimum Viable Product）から段階的に広げていく進め方が基本です。優先順位が決まっていれば、この段階的な開発を進めやすくなります。
機能を洗い出すときは、現場の業務フローに沿って、誰がいつどの操作をするかを整理すると、機能の漏れを減らせます。また、機能同士のつながりも確認できます。
自社固有の独自ロジックや例外処理は、開発会社が想像で補えないため、丁寧に言葉にしておく必要があります。加えて、要件が曖昧だと工数が1.3〜1.5倍に膨らむとの指摘もあります。機能要件の解像度が低いと、費用増とスケジュール遅延に直結します。
非機能要件の性能・セキュリティ・データ量での具体化
非機能要件は見落とされやすい一方で、費用とリスクに大きく影響します。解像度を高めるには、できるだけ数値で示すことが大切です。
- 性能：同時利用者数や画面表示にかける秒数
- データ量：想定される扱い量
- 安全性：求めるセキュリティ水準
- 復旧：障害からの回復に求める時間
要件が曖昧なままだと、本番で動作が遅い、同時アクセスに耐えられないといった問題が起こり得ます。たとえば、「速く」と書くのではなく、主要画面は3秒以内と具体化します。
「安全に」と書くのではなく、個人情報を暗号化してアクセスログを保持する、と記します。水準が高いほど開発費も上がるため、自社に必要な範囲を見極めることが大切です。
過剰な要件はコストの無駄になり、不足は本番障害の温床になります。RFPで要件を具体化しておけば、現実的な見積もりを得られ、追加費用をめぐるトラブルも避けられます。
見積もりの妥当性チェックと隠れコストの見抜き方
複数社から見積もりが届くと、発注企業はその金額が妥当かどうかの判断に迷いがちです。見積もりの基本構造は「人月単価×工数」です。この仕組みを理解しておくと、冷静に比べられます。
安すぎる見積もりにも、高すぎる見積もりにも理由があります。そのため、金額の根拠を見極めることが、適正な発注の前提になります。
人月単価と工数の内訳の確認
妥当性を判断するには、人月単価と工程ごとの工数を確認する必要があります。人月単価は、職種や体制によって幅があります。
- 会社・契約形態別：フリーランス50万〜80万円、中小開発会社80万〜120万円、大手SIer150万〜200万円程度
- 職種別：プロジェクトマネージャー110万〜150万円、システムエンジニア65万〜110万円、プログラマー50万〜90万円
上記はいずれも目安です。見積書では、総額だけでなく、各工程に何人月を見込んでいるかを確かめます。「一式いくら」と書かれている場合は、工程別の内訳を求めます。
一般に、要件定義が全体工数の約20%、設計からテストまでが約80%を占めるとされます。人件費は、開発費全体の40〜60%とされています。
請負契約では、人月計算に1.3〜1.5倍の係数が掛けられ、リスクバッファとして全体の10〜20%を見込むのが一般的です。
内訳のない見積もりは、あとから追加請求をめぐるトラブルになりやすいものです。また、透明性の高い見積もりを出す会社ほど、信頼できる傾向があります。
リリース後の隠れコストの試算
初期開発費と同じく、リリース後に続く運用・保守費用も重要です。初期費用だけでなく、継続してかかる費用も試算しておきます。
- 利用料：サーバーやクラウドの料金
- 従量課金：外部APIの利用料
- 保守・改修：保守契約費や機能追加の改修費
こうしたランニングコストは、毎月・毎年積み上がっていきます。試算を怠ると、初期費用が予算内に収まっていても、運用開始後の負担が重くなります。
保守費用は一般に、年あたり初期開発費の15〜25%が目安とされています。たとえば、開発費が1,000万円なら、年150万〜250万円程度になります。
RFPでは、リリース後の運用・保守費も各社に見積もらせ、初期費用と合わせた総保有コストで比べます。
発注を検討する企業の4〜5割が、「費用対効果が分からない」を課題に挙げるとされています。隠れコストを含む全体像を描けていないことが、その一因です。
AI時代の検収基準と品質保証の取り決め
近年は、開発会社が生成AIでコードを書くケースが増えています。効率化につながる一方で、コードの品質や不具合の責任など、発注企業に新たな検収上の論点が生じます。
RFPと要件定義の段階で、AI時代の検収基準と品質保証を取り決めておくことは、これからの発注で欠かせません。
AI生成コードの検収基準の設定
AI生成コードには、見た目では分からないセキュリティ上の脆弱性や、想定外の条件で破綻するロジックが含まれることがあります。
発注企業は、納品物がAI生成であっても、人間によるレビューとテストを経ているかを検収基準で確かめます。生成AIに頼る場合は、完成しているように見えても欠陥が残るおそれがあります。
- テスト：実施範囲と方法
- セキュリティ診断：実施の有無
- コードレビュー：人間による確認の体制
- LLMの検証：大規模言語モデルを組み込む場合のハルシネーションの許容範囲と検証方法
こうした条件は、要件定義やRFPの段階で取り決めておきます。動くかどうかだけでなく、自社の要件と品質基準を満たしているかを、契約と検収の手順で確かめます。
著作権・契約条項のRFPでの明示
要件定義やRFPの段階では、成果物の権利関係も明確にしておきます。著作権法では、開発プログラムの著作権は原則として、制作した受託者側に帰属します。
発注企業が自由に改修・転用するつもりであれば、契約で著作権の譲渡を明記しておく必要があります。その際は、著作権法27条・28条の権利も含めて譲渡すると書くのが、実務上のポイントです。
権利関係を決めておかないと、後から他社に改修を頼めなくなりかねません。契約形態もRFPの段階で意識し、責任の範囲を確かめておきます。
- 請負契約：完成に対する責任
- 準委任契約：善管注意義務のもとでの作業
要件が固まった部分は請負、探索的に進める部分は準委任とする組み合わせも有効です。
権利・契約条項は専門性の高い領域です。そのため、要件定義から契約・保守まで一貫して対応できる開発会社を選ぶと、トラブル回避につながります。
riplaは、フルスクラッチ受託の立場から、RFP作成時の要件整理や、AI時代の検収基準・契約条項の検討まで伴走します。
まとめ
RFPでは、背景・目的を言語化し、機能要件に優先順位を付けて、非機能要件を数値で具体化します。見積もりについては、人月単価と工数の内訳を確認します。
保守費は、年あたり初期開発費の15〜25%が目安です。リリース後の隠れコストも含めた総保有コストで比べます。
AI生成コードの検収基準や著作権・契約条項も、事前に決めておきます。要件の曖昧さは工数を1.3〜1.5倍に膨らませるとの指摘もあり、RFPの精度はプロジェクトの成否や費用に直結します。
発注企業が目的と要件を主体的に定めることが、スクラッチ開発を成功させる条件です。riplaは、フルスクラッチ受託と国内開発を組み合わせ、RFP作成や要件整理から発注・検収まで伴走します。
要件を固める前に全体像を確認したい方は、完全ガイドもご活用ください。
▼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を創業。