Web制作やフロントエンド開発を外注する際は、RFP（提案依頼書）や要件定義書に、対応ブラウザ・端末、表示速度、アクセシビリティを検収で測れる要件として書きます。
デザインのイメージは伝えられても、これを言葉にできないと見積もりがぶれがちです。全体像をまだ把握していなければ、まずCSS3開発の完全ガイドから読むのがおすすめです。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
対応ブラウザ・端末の定義
CSS3の要件定義でまず決めるべきは、「どのブラウザ・端末まで保証するか」です。これが曖昧だと、ベンダーは「最も古い環境まで対応する」前提で過剰に見積もるか、「最新だけ」で作って後からクレームを受けるか、どちらかのリスクを抱えます。対応範囲は、CSS3でどの機能を使えるかを左右する根幹の要件です。
Baselineを基準とした対応範囲の明記
近年は「Baseline」という業界共通の指標が整備され、対応範囲の議論が格段に楽になりました。Baselineは、ある機能が主要ブラウザ（Chrome・Edge・Firefox・Safari）で安定して使えるかを示す指標です。Baselineには「Newly available（新たに利用可能）」と「Widely available（広く利用可能）」の2段階があります。
発注側は、要件定義書に「Baseline Widely availableの機能を標準採用とし、それ未満の機能を使う場合は代替表示を用意する」と書くだけで、技術選定の前提が明確になります。
たとえばコンテナクエリやカスケードレイヤー、`:has()`、サブグリッドは、いずれも2022〜2026年にBaselineへ到達しています。そのため、現在の標準的な案件であれば安心して採用できます。
一方、業務システムで古いブラウザの利用が残る企業では、「Internet Explorerの後継環境を含むか」などを明記する必要があります。また、対応範囲を1段階広げるごとに工数と検証コストが増えます。そのため、ビジネス上の必要性とのバランスで決めることになります。
- Widely available：標準採用の対象
- Newly available：使うなら代替表示が必要
端末・画面サイズのサポートマトリクス
ブラウザと並んで重要なのが、対応する端末と画面サイズです。「スマホ・タブレット・PCに対応」とだけ書くと、どこまでが範囲かが曖昧になります。
サポートマトリクスを作っておくと、レスポンシブ対応の検証範囲が明確になり、検収時に「この端末で崩れている」と言い合う水掛け論も防げます。
近年はコンテナクエリの登場により、画面サイズだけでなく、コンポーネントの配置場所に応じた表示最適化も可能になりました。要件としては「主要な代表画面幅で崩れないこと」を最低ラインとします。
発注側は、可能であれば推奨要件を加えると、長期保守に強い設計を引き出せます。
- 画面幅：代表的な幅と縦横比を明示
- 推奨要件：コンポーネント単位のレスポンシブ対応
画面幅の例としては、375px／768px／1280pxが挙げられます。
表示速度・パフォーマンス要件の定量化
表示速度は、ユーザー体験とSEOの両方に直結する最重要の非機能要件です。ただし、「速いサイトにしてほしい」という主観的な表現では、検収で合否を判断できません。
CSS3はレイアウトやアニメーションを通じて描画パフォーマンスに関わります。そのため、定量的な基準を要件に組み込むことが欠かせません。
Lighthouse・Core Web Vitalsによる基準点の設定
表示速度の要件は、GoogleのLighthouseスコアやCore Web Vitalsという業界標準の指標で定めるのが実務的です。
たとえば「Lighthouseのパフォーマンススコアをモバイルで80点以上」といった具体的な数値を、検収基準に書きます。これにより、誰が測っても同じ結果が出る客観的な合否判定が可能になります。
CSS3はこれらの指標に直接影響します。特にCLS（レイアウトのずれ）は、Webフォントの読み込みや画像のサイズ未指定によって悪化しやすい指標です。
また、CSS側のチューニング（`font-display`の指定、`aspect-ratio`による領域確保など）で改善できます。要件にこれらの数値を明記しておけば、ベンダーは設計段階からパフォーマンスを意識せざるを得なくなり、納品後の「重い」というトラブルを未然に防げます。
- LCP：最大コンテンツ描画時間の目標（2.5秒以内）
- CLS：レイアウトのずれの目標（0.1未満）
CSSの軽量化方針の要件化
パフォーマンス要件には、CSSそのものの軽量化方針も含めると効果的です。具体的には「未使用CSSの削除（パージ）」「クリティカルCSSの優先読み込み」「JavaScriptで実現していた動きの可能な範囲でのCSS化」といった方針を求めます。
Tailwind CSSのようなユーティリティ系を使う場合、本番ビルドで未使用クラスが削除される仕組みがあるため、最終的なCSSサイズを小さく保てます。
ここで注意したいのは、これらの実装手段を細かく指定しすぎないことです。要件には「LCPが2.5秒以内」のような結果目標を書き、達成手段はベンダーの裁量に委ねるのが理想です。
手段を縛りすぎると、より良い方法があっても採用できず、かえって品質を下げることがあります。役割分担は、発注側が「何を達成するか」を、ベンダーが「どう達成するか」を担う形になります。
- 未使用CSSの削除：本番ビルドで未使用分を取り除く
- クリティカルCSS：表示に先に必要な部分の優先読み込み
アクセシビリティとCSS設計手法の要件
アクセシビリティ（誰もが使える設計）は、近年ますます重視される非機能要件です。また、CSSの設計手法をどこまで指定するかも、要件定義で判断が分かれやすい点です。
この2つは、発注側が「結果」を求めつつ「手段」はベンダーに委ねるという原則が、特に重要になる領域です。
WCAGの達成レベルの明記
アクセシビリティの要件は、WCAG（Web Content Accessibility Guidelines）という国際標準の達成レベルで定めます。
WCAGにはA・AA・AAAの3段階があり、一般的なWebサイトではAA準拠を目標にするのが現実的です。要件定義書に「WCAG 2.1 AA準拠」と書けば、達成すべき水準が明確になります。また、公的機関や大企業のサイトでは、AA準拠が事実上の必須になりつつあります。
CSS3はアクセシビリティに深く関わります。たとえば、文字色と背景色のコントラスト比や、フォーカス時の見やすい枠線表示は、CSS3で作り込む部分です。
アクセシビリティの対応は、いずれもCSSで実装するため、要件に含めておくことで、見た目だけでなく「誰もが使えるか」という品質を担保できます。
アクセシビリティを後付けで対応すると工数が膨らみます。そのため、要件段階で明示しておくのが確実です。
- コントラスト比：AAで4.5:1以上が基準
- 動きを減らす設定：prefers-reduced-motionへの対応
Tailwindかネイティブか、CSS設計手法の指定の是非
「TailwindとネイティブCSSのどちらを使うべきか」を要件で指定すべきかという相談は、よく受けます。原則としては指定せず、ベンダーに委ねるのが賢明です。
Tailwindは、2025年のState of CSS調査で採用率37〜51%、週約3,100万ダウンロードと広く普及しています。さらに、複数人で開発する場合のスピードと統一性にも優れます。
一方、ネイティブCSSはネスト・カスケードレイヤーの登場で進化し、追加ツールなしでも保守性の高い設計が可能になりました。どちらにも合理的な選択理由があります。
発注側が指定すべきなのは手法そのものではなく、その先にある「結果」です。すなわち、「属人化しない標準化された設計」「将来の開発者が引き継ぎやすいこと」「未使用CSSが本番で削除され軽量であること」を採用要件として求めます。特定の手法を強制すると、ベンダーの得意な技術を封じてしまい、かえって品質が下がる恐れがあります。
ただし、社内に既存のデザインシステムやTailwind資産がある場合は、それとの整合性を要件に含めるのが合理的です。技術選定の基準そのものは、後述の必勝法5軸で詳しく整理します。
- 属人化の回避：誰が書いても同じ形になる標準設計
- 引き継ぎやすさ：将来の開発者が読み取れる設計
まとめ
CSS3まわりのRFP・要件定義で大切なのは、見た目の指定ではなく「対応ブラウザ・表示速度・アクセシビリティ」という非機能要件を測れる形で定量化することです。対応範囲はBaselineと代表画面幅で、表示速度はLighthouseとCore Web Vitalsで、アクセシビリティはWCAGのレベルで定めます。ここまで定めておけば、見積もりのブレと検収トラブルが減ります。
CSS設計手法（Tailwindかネイティブか）は原則ベンダーに委ね、「属人化回避・標準化・将来の保守容易性」を採用要件として求めるのが賢明です。
「フワッとした使いやすさ」を要件にせず、結果は数値で、デザインはビジュアルで合意します。この切り分けこそが発注の質を決めます。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を創業。