Web/ウェブアプリの開発を外注しようと考えたとき、多くの発注担当者が最初につまずくのが「何をどう要件としてまとめ、RFP（提案依頼書）に書けばよいのか分からない」という壁ではないでしょうか。とくにWeb/ウェブアプリは、ブラウザで完結させるのか、PWA（プログレッシブウェブアプリ）にするのか、将来ネイティブ化するのかといった方式の選択や、対応ブラウザ・対応デバイスの範囲、表示速度やSEOといったWeb固有の論点が絡みます。これらを曖昧にしたまま見積りを取ると、ベンダーごとに前提がバラバラの提案が返ってきて、比較も判断もできなくなります。
本記事は、Web/ウェブアプリ開発で発注者が準備すべき要件定義・RFP・提案依頼書の実務を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。要件からWeb/PWA/ネイティブのどれを選ぶかをRFPに落とす方法、機能要件と非機能要件（クロスブラウザ対応範囲・表示速度・SEO・同時接続・セキュリティ）の整理、Must/Wantの仕分けと社内合意形成、RFP記載項目と見積りの妥当性判断軸まで掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。全体像をまだ把握していない方は、まずWeb/ウェブアプリ開発の完全ガイドから読むことをおすすめします。
要件から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項目
Web/ウェブアプリのRFPには、最低限以下の6項目を盛り込みます。
1. 目的・KGI：何のために作るのか、達成すべき指標（会員登録数、CV率、受注処理時間の削減など）
2. 機能要件：実現したい機能をMust/Want付きで列挙し、方式（Web/PWA）の前提も明記
3. 非機能要件：対応ブラウザ範囲、表示速度・SEO、同時接続数、セキュリティ
4. 既存システム連携：基幹システムや外部API（決済・認証など）との連携範囲
5. 予算・スケジュール：予算の上限感とリリース希望時期
6. 体制要求：開発体制図、PM・実開発者の明示、運用保守の前提
この6項目が明確であるほど、ベンダーは前提を揃えた見積りを出さざるを得ず、複数社の提案を横並びで比較できます。
とくにWeb/ウェブアプリで見落とされがちなのが、3番目の非機能要件です。「ログイン機能」「商品一覧」といった機能だけを書き、表示速度やSEO、対応ブラウザを書かないRFPが少なくありません。しかしWeb/ウェブアプリでは、これらこそが体験と集客を左右します。非機能要件をRFPに明記することで、リリース後に「動くが遅い」「検索結果に出てこない」という後悔を防げます。非機能要件の中身は次のh2で詳しく扱います。
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制約です。PWAはAndroid/Chromeでは比較的自由に機能を使えますが、iOSのSafariではプッシュ通知やバックグラウンド処理、ストレージ容量などに制約があり、ネイティブと同等の挙動を期待できません。PWAでプッシュ通知を前提に設計したのに、iOSでは思うように届かなかった、という齟齬は典型的な落とし穴です。PWAを採用する場合は、iOSでどこまで機能するかをベンダーと事前にすり合わせ、その制約をRFPと要件定義書に明記しておくことが欠かせません。
表示速度・SEO・同時接続・セキュリティの要件化
表示速度とSEOは、Web/ウェブアプリならではの非機能要件です。表示が遅いとユーザーは離脱し、検索エンジンの評価も下がります。とくにReactやVue、AngularなどのSPA（シングルページアプリ）で画面遷移のない高速UXを実現する場合、初期表示や検索エンジンへのコンテンツ提供（SEO）に工夫が要ります。RFPでは、目標とする表示速度（たとえば主要ページの読み込み時間）や、検索エンジンにインデックスされるべき要件を指定します。集客をWeb経由に頼るプロダクトなら、SEO要件は機能要件と同等の重みを持ちます。
同時接続数とセキュリティも忘れてはいけません。同時接続は、想定する同時アクセスのピークを示すことで、ベンダーが適切なインフラ構成を見積もれます。ピーク時に画面が固まるようでは、ユーザーは離れてしまいます。セキュリティは、会員情報や決済情報を扱う場合、通信の暗号化・不正アクセス対策・認証の堅牢性などを、IPA（情報処理推進機構）のガイドラインなどを参照しつつ要件化します。これら非機能要件を曖昧にすると、リリース後に「遅い」「止まる」「漏れる」「検索されない」というトラブルが起き、せっかくの機能も活きません。機能要件と同じ熱量で非機能要件を詰めることが、Web/ウェブアプリの品質を担保します。
見積りの妥当性を判断する軸と発注先選び
RFPを発信して提案が集まったら、見積りの妥当性を判断します。Web/ウェブアプリは発注先によって価格帯が大きく異なるため、相場観を持つことが妥当性判断の出発点になります。同じ要件でも、誰に頼むかで金額が数倍変わることは珍しくありません。
発注先別の人月単価で見積りを読み解く
見積りを読み解く最初の物差しが、発注先別の人月単価です。一般に、フリーランスで60〜80万円、中小開発会社で80〜120万円、大手SIerで150〜300万円が目安とされます。同じ機能を実装するのにかかる人月（工数）が同じでも、この単価差によって総額は大きく変わります。見積りを見るときは、総額だけでなく「何人月で、人月いくらか」という内訳を確認し、自社の予算や品質要求に合った発注先かを判断します。
機能別の費用感も、妥当性判断の補助線になります。たとえば会員登録/ログインで30〜80万円、決済で80〜200万円、リアルタイムチャットで150〜400万円が目安です。また運用保守費は、初期開発費の年間15〜20%が相場とされます。これらを物差しに、見積りが安すぎる場合は必要な機能や非機能要件が漏れている可能性、高すぎる場合は不要な要件が含まれている可能性を疑い、内訳の開示を求めます。「テスト・デバッグ費」「ディレクション費」が一式でまとめられている場合は、機能ごと・工程ごとの工数と単価の明示を依頼すると、ブラックボックスを解明できます。
AI駆動開発前提のコスト目線をRFPに織り込む
近年は、AIによるコード自動生成を前提とした開発が広がり、コスト目線そのものが変わりつつあります。実例として、市場相場700〜1,500万円（13〜18人月）規模の案件を、AIコード自動生成と「フリーランス＋小規模専門会社」への分割発注を組み合わせることで、実質8人月・500万円に圧縮した事例があります（出典：ぷらすわん合同会社）。コストを約3分の1に抑えた計算です。発注者がこうしたコスト圧縮の可能性を知っているかどうかで、見積りへの目線は大きく変わります。
もちろん、すべての案件でこの圧縮が成立するわけではありませんが、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作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。