Web/ウェブアプリのRFP（提案依頼書）や要件定義書は、提供方式を決め、非機能要件と機能のMust/Wantを書き分けて作ります。そうすると、ベンダーの提案を横並びで比べられます。
全体像をまだつかめていない方には、まずWeb/ウェブアプリ開発の完全ガイドをおすすめします。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
要件からWeb/PWA/ネイティブを選ぶ進め方
Web/ウェブアプリの要件定義は、まず提供方式を決めるところから始めます。提供方式とは、そのプロダクトをWeb（ブラウザで完結）として作るのか、PWA（オフライン対応やホーム画面追加を備えたウェブアプリ）にするのか、将来ネイティブ化を見据えるのか、という選択です。
画面の一覧から入り、方式が決まらないまま機能だけを並べると、見積りの前提が定まりません。後から「やっぱりネイティブも」と方向を変えれば、その分だけ費用が膨らみます。
Web/ウェブアプリの最大の強みは、ブラウザで完結する点です。インストールが要らずURLからすぐ使え、アップデートはサーバー側の差し替えで全ユーザーに即時反映されます。
また、アプリストアの審査も要りません。MVP（最小実用製品）の段階で最速の市場検証をしたい発注者にとって、この身軽さは大きな利点になります。まずは、この方式選定を要件定義の冒頭に置くことが、ブレないRFPの土台になります。
Web/PWA/ネイティブを要件から判断する基準
方式選定は、感覚ではなく要件から逆算します。その物差しが、ネイティブ化の「移行シグナル3条件」です。具体的には、(1)デイリーアクティブユーザーの増加、(2)プッシュ通知でのリエンゲージメント（再来訪促進）の重要性、(3)カメラなどブラウザの制約では実現できない機能への強い要望です。
この3つが重なったときに、ネイティブ化を本格的に検討すべきです。逆に言えば、3条件が揃わない段階では、Web/PWAで最速に検証するのが合理的です。たとえば、毎日使われる前提がなく、プッシュ通知での再来訪も必須ではなく、高速カメラやOS深部連携も要らないプロダクトなら、Webで十分に成立します。
一方で、毎日の利用とプッシュ通知が成長の生命線で、かつカメラなどデバイス機能が中核なら、ネイティブが視野に入ります。そこで要件定義では、自社のプロダクトがこの3条件にいくつ当てはまるかを整理し、その判断結果をRFPの前提として書きます。これにより、ベンダーは方式に合った技術構成で見積りを出せます。
対応ブラウザ・デバイス・PWA要否のRFP記載
方式を決めたら、その内容をRFPに具体的に落とします。まず対応ブラウザは、Chrome・Safari・Edge・Firefoxのうちどこまでを保証するか、バージョンをどこまで遡るかを明記します。次に対応デバイスは、PC・タブレット・スマートフォンのどの画面幅まで作り込むかを指定します。
レスポンシブ（マルチデバイス対応）は、1つのコードで複数デバイスに対応できるのが強みですが、検証対象を広げるほど工数が増えるため、範囲の指定が費用に直結します。PWAの要否も、ここで明確にします。オフライン対応やホーム画面への追加、一部のプッシュ通知をPWAで実現するのか、それとも純粋なWebで十分かを判断し、RFPに書き分けます。
PWAを求める場合は、後述するSafari/iOSのPWA制約も前提として共有しておくと、ベンダーが過大な期待を提案に盛り込むのを防げます。方式・対応ブラウザ・対応デバイス・PWA要否の4点をRFP冒頭の前提条件として固めることが、提案のブレを抑える第一歩です。なお、どの機能を載せるかという具体の中身については、Web/ウェブアプリの必要機能や標準機能の一覧についての記事もあわせてご覧ください。
RFPに盛り込む項目とMust/Wantの仕分け
方式と対応範囲が固まったら、RFP（提案依頼書）本体に盛り込む項目を整理します。RFPの質が、集まる提案と見積りの質を左右します。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較もできません。
Web/ウェブアプリは費用の幅が大きいため、RFPで前提をそろえておくことが、見積りの妥当性を判断する大前提になります。
RFPに必ず盛り込むべき6項目
ベンダーに前提をそろえて提案してもらうには、目的から体制までの6項目をRFPに書き込みます。
- 目的・KGI：何のために作るのか、達成すべき指標（会員登録数、CV率、受注処理時間の削減など）
- 機能要件：Must/Want付きで実現したい機能と、方式（Web/PWA）の前提
- 非機能要件：対応ブラウザの範囲、表示速度とSEO、同時接続数、セキュリティ
- 既存システム連携：基幹システムや外部API（決済・認証など）と連携する範囲
- 予算・スケジュール：予算の上限の目安と、リリース希望時期
- 体制要求：開発体制図、PMと実開発者の明示、運用保守の前提
この6項目がそろっているほど、ベンダーは前提をそろえた見積りを出さざるを得ず、複数社の提案を横並びで比較できます。
なかでも見落とされやすいのが、3番目の非機能要件です。「ログイン機能」「商品一覧」といった機能だけを書き、表示速度やSEO、対応ブラウザを書かないRFPは少なくありません。しかしWeb/ウェブアプリでは、これらこそが体験と集客を左右します。
非機能要件をRFPに明記しておけば、リリース後に「動くが遅い」「検索結果に出てこない」といった後悔を防げます。非機能要件の中身は、次の節で詳しく扱います。
Must/Wantの仕分けと社内合意形成
機能要件は、Must（必須）とWant（あれば望ましい）に仕分けておくことが大切です。「これがないと成立しないMust機能」と「効果は大きいが初期になくても運用できるWant機能」を分けておけば、見積りが予算を超えたときに、どの機能を初期リリースから外すかを冷静に判断できます。
とくに、すべてをMustにすると、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。Must/Wantの仕分けは、社内で合意を取る場にもなります。現場部門は「あれもこれも欲しい」と多機能を求め、経営層は「コストを抑えて短期で出したい」と考えがちで、両者の板挟みになりやすいのです。
この対立を解く鍵が、Must/Wantという共通の物差しです。現場の要望はWantとして受け止め、初期リリースはMustに絞ると整理すれば、双方が納得しやすくなります。要件定義はそれ自体に工数がかかり、ベンダーによっては有償で支援するのが一般的です。ただ、要件整理を外注する場合も、Must/Wantの最終判断は発注者が握り続けることが、丸投げによる失敗を避ける境界線になります。
非機能要件とクロスブラウザ対応の指定
Web/ウェブアプリの要件定義では、機能要件と同じくらい丁寧に詰めたいのが非機能要件です。非機能要件は「どれだけの品質で動くか」を定めるもので、表示速度、SEO、クロスブラウザ対応、同時接続、セキュリティが代表的です。
Web/ウェブアプリはブラウザという多様な実行環境で動くため、これらの指定が体験と集客の質を直接左右します。
クロスブラウザ対応範囲とSafari/iOSのPWA制約
クロスブラウザ対応は、Web/ウェブアプリ特有の論点です。Chrome・Safari・Edge・Firefoxは描画エンジンやCSSの解釈に差があり、あるブラウザで正しく見える画面が、別のブラウザでは崩れることがあります。この差を吸収する検証には相応のコストがかかるため、RFPでは「どのブラウザを、どのバージョンまで保証するか」を明記します。
範囲を絞れば費用は抑えられ、広げれば品質保証は高まります。このトレードオフは、発注者が意思決定する必要があります。とくに注意したいのが、Safari/iOSのPWA制約です。
- 機能の制約：Android/Chromeと違い、iOSのSafariではプッシュ通知やバックグラウンド処理、ストレージ容量などに制約があります。
- 期待値：ネイティブと同等の挙動は期待できない点。
- 典型的な落とし穴：プッシュ通知を前提に設計したのに、iOSでは思うように届かなかったというずれ。
- 対応：PWAを採用するなら、iOSでどこまで機能するかをベンダーと事前にすり合わせ、制約をRFPと要件定義書に明記します。
表示速度・SEO・同時接続・セキュリティの要件化
表示速度とSEOは、Web/ウェブアプリならではの非機能要件です。表示が遅いとユーザーは離脱し、検索エンジンの評価も下がります。とくにReactやVue、AngularなどのSPA（シングルページアプリ）で画面遷移のない高速なUXを実現する場合は、初期表示や、検索エンジンへのコンテンツ提供（SEO）に工夫が要ります。
そこでRFPには、目標とする表示速度（たとえば主要ページの読み込み時間）や、検索エンジンにインデックスされるべき要件を指定します。集客をWeb経由に頼るプロダクトなら、SEO要件は機能要件と同等の重みを持ちます。これら非機能要件が曖昧だと、リリース後に「遅い」「止まる」「漏れる」「検索されない」といったトラブルが起き、せっかくの機能も活きません。
同時接続数は、想定する同時アクセスのピークを示すことで、ベンダーが適切なインフラ構成を見積もれるようにするものです。ピーク時に画面が固まると、ユーザーは離れてしまいます。セキュリティは、会員情報や決済情報を扱う場合に、通信の暗号化、不正アクセス対策、認証の堅牢性などを、IPA（情報処理推進機構）のガイドラインなどを参照しながら要件化します。
見積りの妥当性を判断する基準と発注先選び
RFPを発信して提案が集まったら、見積りの妥当性を判断します。Web/ウェブアプリは発注先によって価格帯が大きく異なるため、まず相場観を持つことが出発点になります。同じ要件でも、誰に頼むかで金額が数倍変わることは珍しくありません。
発注先別の人月単価による見積りの読み解き
見積りを読み解く最初の物差しが、発注先別の人月単価です。一般に、フリーランスで60〜80万円、中小開発会社で80〜120万円、大手SIerで150〜300万円が目安とされます。同じ機能を実装する人月（工数）が同じでも、この単価差で総額は大きく変わります。
そのため、見積りは総額だけでなく「何人月で、人月いくらか」という内訳を確認し、自社の予算や品質要求に合う発注先かを判断します。機能別の費用感も、妥当性判断の補助線になります。たとえば、会員登録/ログインで30〜80万円、決済で80〜200万円、リアルタイムチャットで150〜400万円が目安です。
また運用保守費は、初期開発費の年間15〜20%が相場とされます。これらを物差しに、見積りが安すぎれば必要な機能や非機能要件が漏れている可能性を、高すぎれば不要な要件が含まれている可能性を疑い、内訳の開示を求めます。「テスト・デバッグ費」「ディレクション費」が一式にまとめられている場合は、機能ごと・工程ごとの工数と単価の明示を依頼すると、ブラックボックスを解明できます。
RFPに織り込むAI駆動開発前提のコスト目線
近年は、AIによるコード自動生成を前提とした開発が広がり、コストの見方そのものが変わりつつあります。実例として、市場相場700〜1,500万円（13〜18人月）規模の案件を、実質8人月・500万円に圧縮し、コストを約3分の1に抑えた事例があります（出典：ぷらすわん合同会社）。発注者がこうしたコスト圧縮の可能性を知っているかどうかで、見積りへの目線は大きく変わります。
その圧縮は、AIコード自動生成と「フリーランス＋小規模専門会社」への分割発注を組み合わせることで実現しています。もちろん、すべての案件でこの圧縮が成り立つわけではありません。ただ、RFPの段階で「AI駆動開発を前提とした効率化の提案を歓迎する」と一言添えておけば、人月の積み上げ一辺倒ではない、コスト効率の高い提案を引き出せます。
将来ネイティブ化を見据えるなら、前述の移行シグナル3条件をRFPの前提に織り込み、「将来ネイティブ化する際の移行のしやすさ」も評価項目に加えておきます。そうすれば、初期はWeb/PWAで身軽に始めつつ、成長後の拡張に備えた設計を引き出せます。要件定義の精度とコスト目線が、見積りの妥当性判断の精度を決めます。
まとめ
Web/ウェブアプリのRFP・要件定義書・提案依頼書は、要件から方式（Web/PWA/ネイティブ）を決め、その前提をRFPに書き切るところから始めます。そのうえで、対応ブラウザ・対応デバイス・PWA要否を指定し、表示速度・SEO・クロスブラウザ・同時接続・セキュリティといった非機能要件を機能要件と同じくらい丁寧に詰めます。
機能はMust/Wantに仕分けて、現場と経営層の合意を形成します。RFPに目的・連携要件・体制要求まで明記すれば、ベンダーの提案を横並びで比較できます。発注先別の人月単価（フリーランス60〜80万／中小80〜120万／SIer150〜300万：出典ripla）やAIコスト目線に照らせば、見積りの妥当性も判断できます。
方式の選択と非機能要件の指定は、Web/ウェブアプリ要件定義の生命線です。要件の質が、そのままプロダクトの成否に直結します。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、方式選定から非機能要件の整理、Must/Wantの仕分け、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を創業。