HTML5のRFP（提案依頼書）では、機能に加えて、対応ブラウザ・端末、表示速度、アクセシビリティを検収できる数値で書くことが要点です。HTML5でWebサイトやWebアプリを外注するとき、見落とされがちなのが要件定義の質です。なかでも、解説記事で手薄になりがちな「非機能要件の定量化」が、RFPで差の出る部分です。
RFPに数値を書かずに発注すると、完成後に「特定の端末で崩れる」といったトラブルに直結します。
全体像は、まずHTML5開発の完全ガイドでご確認ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
HTML5開発で非機能要件の定義が重要な理由
HTML5開発のRFPでは、画面イメージや機能一覧といった機能要件に目が行きがちです。
発注後のトラブルの多くは、非機能要件の曖昧さから生まれています。
フロントエンドでは、どの環境で、どれだけ速く、どれだけ誰にでも使えるかが品質を左右します。そのため、ここを定量化しないと、検収の基準そのものが持てなくなります。
「使いやすいサイト」が工数爆発を招く理由
もっとも危険なのは、「とにかく使いやすいサイトを」のようなフワッとした要件です。使いやすさの解釈は人によって異なり、完成基準も明確でないため、発注側とベンダーの認識がいつまでもずれ続けます。
何度も作り直しが発生し、工数が爆発的に膨らみます。
作り直しと工数の膨張は、フロントエンド開発で最も典型的な失敗パターンの一つです。
解決策は、抽象的な要望を計測できる指標に置き換えることです。たとえば「使いやすい」は、次のような検収できる条件に言い換えられます。
- 表示速度：主要ページの読み込みを一定秒数以内に収める
- アクセシビリティ：Lighthouseのアクセシビリティスコアを基準値以上にする
指定した端末・ブラウザで崩れないことも、検収の条件として書けます。そうすれば、発注側は完成の合否を客観的に判断できます。
要件定義の本質は、主観を客観に変える作業だと言えます。
この置き換えを発注側だけで行うのは難しく、riplaも要件整理を起点に伴走しています。何を数値で縛れるかは、技術知識がないと分かりにくいためです。
発注側の事業目的を聞き取り、検収できる非機能要件に落とし込めば、後工程のトラブルを未然に防げます。
RFP・要件定義書・提案依頼書の役割の違い
RFP（提案依頼書）と要件定義書は、どちらも発注内容を文書にするものですが、使われる段階が異なります。
- RFP（提案依頼書）：発注側が解決したい課題や前提条件をまとめ、ベンダーに提案を依頼する文書
- 要件定義書：提案を採用したあとに、何を作るかを具体的に確定させる文書
HTML5開発では、RFPの段階で非機能要件の方向性を示しておくことが、後の要件定義をスムーズにします。
RFPに非機能要件の骨子があれば、ベンダーは提案の段階でそれを織り込んだ見積もりと体制を示せます。
逆に、RFPに何も書かず提案後に「実はWCAG準拠が必須だった」と伝えると、見積もりの前提が崩れ、追加費用や納期遅延を招きます。だからこそ、RFP段階で非機能要件に触れておくことは、見積もりの精度とプロジェクトの安定性を高める投資になります。
発注側がすべての技術要件を最初から書ける必要はありません。まず押さえたいのは、譲れない条件と判断を委ねたい部分を切り分けることです。前者は明記し、後者はベンダーに提案を求めます。
発注側が譲れない条件と委ねる部分を切り分けておくと、提案どうしを比べやすくなり、ベンダー選定の精度も上がります。
RFPに明記すべき3つの非機能要件
HTML5開発のRFPで定量的に書くべき非機能要件は、3つに整理できます。対応ブラウザ・端末、表示速度（Lighthouse基準）、アクセシビリティ（WCAG基準）です。
RFPで3つの要件を検収できる形で定めておくと、トラブルを防ぐうえで効果が大きくなります。
対応ブラウザ・端末の定め方
第一の要件は、対応ブラウザと端末の明記です。HTML5の機能は多くが主要ブラウザで使えますが、新しいWeb APIや一部の入力タイプは、ブラウザや端末によって挙動が異なります。
発注側が、どこまで対応するかを定めずに開発すると、「特定のブラウザで動かない」という想定外の手戻りが起きます。
RFPには、次の2つを具体的に示します。
- 対応ブラウザ：種類とバージョンの範囲
- 対応端末・画面：PC・スマートフォン・タブレットと、想定する画面幅
発注側は、自社サイトのアクセス解析があれば、利用者の多いブラウザ・端末を根拠に対応範囲を絞り込めます。
古いブラウザまで全方位に対応しようとすると工数が膨らむため、利用実態に基づく取捨選択が費用対効果を左右します。
W3Techsの2025年データでは、全Webサイトの約73.5%がいまもjQueryを使っています。これは、古い環境のユーザーがなお一定数いることの表れでもあります。
発注側が、自社の利用者層を踏まえてどこまでの環境を保証するかをRFPで明確にすることが、現実的な品質と工数のバランスを取る出発点になります。
Lighthouseスコアとアクセシビリティ基準の検収条件化
第二の要件は表示速度、第三の要件はアクセシビリティです。どちらも検収できる条件として定めると、完成の合否を判断しやすくなります。
- 表示速度：Lighthouseのパフォーマンススコアで測り、主要ページの基準値を決める
- アクセシビリティ：WCAGの適合レベルを決め、Lighthouseのアクセシビリティスコアと組み合わせて検収する
GoogleのLighthouseは、パフォーマンス・アクセシビリティ・ベストプラクティス・SEOの4観点をスコア化する無料ツールで、誰でも同じ条件で計測できます。速度は離脱率や検索順位に直結するため、ビジネス成果に近い指標です。
国際的な指針であるWCAGには適合レベルがあり、一般にAAレベルが実務上の目標とされています。特に、公共性の高いサイトや大企業では、WCAG準拠が必須要件となるケースも増えています。
これら3つの要件は、HTML5の機能と表裏一体です。セマンティック要素を正しく使えばアクセシビリティスコアが上がり、不要なライブラリを減らせばパフォーマンススコアが上がります。
そのため、機能を理解しているほど、適切な検収基準を設定できます。HTML5の機能の詳細は、関連記事の機能編で扱っています。
技術選定とベンダーロックイン回避の要件化
非機能要件と並んで重要なのが、技術選定の方針です。HTML5そのものは標準仕様なので特定企業に縛られませんが、その上に乗せるフレームワークや配信基盤の選び方によって、将来の保守性やリプレイスのしやすさが変わります。
発注側がここを要件として意識するかどうかで、長期コストが分かれます。
RFPでのSSR要否と構成方針の判断
HTML5ベースのサイトでは、サーバー側でHTMLを生成するSSR（サーバーサイドレンダリング）や、事前にHTMLを書き出すSSG（静的サイト生成）を採るかどうかが、SEOや初期表示速度に関わります。
検索エンジンからの流入が重要なサイトでは、初期表示でコンテンツが揃っているSSRやSSGが有利になることが多いです。また、ピクセルグリッド社のAstro移行事例も、この考え方に沿っています。
RFPでは、次の2点を示します。
- SEOの重視度：検索流入をどこまで重く見るか
- 初期表示速度の目標値：どの程度の水準にするか
そのうえで、SSR・SSGの要否はベンダーに判断と提案を求める形が現実的です。発注側がすべての技術判断をする必要はありません。
「SEO重視」という事業要件を明示すれば、ベンダーは適切な構成を提案しやすくなります。ここでも、要件と技術判断を切り分けることが生きてきます。
注意したいのは、SSRやSSGは運用の複雑さやインフラ費用を伴う点です。Vercelなどの従量課金サービスは便利な一方、アクセス増でランニングコストが跳ね上がることもあります。
そのため、RFPには初期費用に加えて、運用フェーズのインフラ費用の見通しも含めて提案を求めます。これが、後の費用トラブルを防ぐ手立てになります。
ベンダーロックインを避ける指定の仕方
ベンダーが独自のフレームワークや、そのベンダーしか扱えない特殊な構成で開発すると、将来そのベンダーから離れられなくなるベンダーロックインのリスクが生じます。
発注側は、改修のたびに同じベンダーに依頼せざるを得ず、価格交渉力も失います。
これを避けるには、RFPに次の条件を示すのが有効です。
- 技術の選び方：標準的で広く使われている技術を優先し、独自構成は理由と移行性を説明させる
- 納品物：ソースコードと設計ドキュメント、他社でも保守できる構成
HTML5自体は標準仕様で移行性が高いため、その特性を活かす意味でも、上に乗せる技術はできるだけ標準的でシェアの高いものを選ぶのが安全策です。
発注側が、上に乗せる技術の条件をRFPに明記しておけば、将来のリプレイスや内製化の選択肢を残せます。
riplaはフルスクラッチ受託の立場から、発注側の将来の選択肢を狭めない構成を重視しています。
標準的な技術を土台に、ソースコードとドキュメントを含めて納品することで、ロックインを生まない開発を心がけています。技術選定の判断軸については、メリット・デメリットを扱う関連記事もあわせてご覧ください。
まとめ
HTML5開発の要件定義を振り返ると、成否を分けるのは「フロントエンド特有の非機能要件を、検収可能な数値に落とし込めるか」という一点に集約されます。
対応ブラウザ・端末を明記し、Lighthouseのスコアで速度とSEOの基準を定め、WCAGでアクセシビリティを担保する。この3つを定めるだけで、「使いやすいサイトを」という曖昧な発注が招く工数爆発やトラブルの大半を予防できます。
発注側がSSR要否やベンダーロックイン回避といった技術選定の方針をRFPに織り込めば、初期費用だけでなく長期の運用コストまで見据えた発注が可能になります。
事業要件と技術判断を切り分け、譲れない条件は数値で明記します。判断を委ねたい部分は提案を求めます。この姿勢が、発注側の主導権を支える要件定義の核心です。
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を創業。