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