Web制作の要件定義とは？決める項目・進め方と発注者の作業範囲を解説

Web制作の要件定義は、デザインに入る前に「このサイトで何を達成し、何をどこまで作るか」を文書で確定させる工程です。新規制作でもリニューアルでも、ここが曖昧なまま進むと、公開直前の差し戻しと追加見積もりという形で跳ね返ってきます。この記事では、サイトの目的とKPI、サイト構成図とページ一覧、デザイン要件、機能要件、CMSの更新権限、非機能要件まで、要件定義書に何をどの粒度で書くのかを整理しました。リニューアル案件でだけ追加になる移行要件と、要件を発注前に固め切るべき案件の線引きまで扱います。

まとめ：Web制作の要件定義で先に決める論点と発注者の担当範囲

先に結論を述べます。Web制作の要件定義で発注者が自分で決め切る必要があるのは、サイトの目的とKPI、対象読者、掲載する情報の範囲、更新体制の四つ。この四つは社内の事情でしか決まらないため、制作会社に投げても返ってきません。逆にサイト構成図の粒度、機能の実装方式、CMSの権限設計、表示速度やセキュリティの水準は、発注者が「業務上どう困るか」を伝えれば制作会社が要件の形に翻訳できます。

要件定義書の分量を競うことに意味はありません。必須項目を9個並べて埋めても、更新体制と運用フェーズの責任分界が抜けていれば、公開後に「誰も更新できないサイト」が残ります。リニューアル案件ではさらに、旧URLと新URLの対応表、リダイレクト方式、移行本数と作業分担が要る。要件を発注前に固め切るか段階的に確定するかを分ける軸は、ページ数ではなく関係部門の数と業務システム連携の有無です。

Web制作における要件定義の対象範囲とRFP・要求定義との違い

「要件定義」が指す範囲は、システム開発とWeb制作でずれます。自分の案件でどこまでを要件定義と呼ぶのかを先に揃えておきます。

Webサイト制作の要件定義が扱う作業範囲と成果物の具体的な中身

Web制作の要件定義が扱うのは、企画で決まった方向性を、見積もりと制作指示に耐える具体度まで落とす作業です。成果物は要件定義書1冊にまとめるか、サイトマップ・機能一覧・非機能要件表の3点セットに分けるか。分けたほうが後の更新は楽になります。サイトマップは公開後もページ追加のたびに手が入りますが、機能一覧は初期リリース後ほとんど変わりません。

ページ単位のワイヤーフレーム、原稿、デザインカンプは要件定義の外に置き、設計フェーズの成果物として別にスケジュールを引くのが扱いやすい線です。ワイヤーフレームまで含めると、承認が数週間単位で止まります。

RFPに書く範囲と要件定義で確定させる範囲の分担と線引きの基準

RFP（提案依頼書）と要件定義書は、作成する時点も目的も違います。RFPは発注先を選ぶために「解いてほしい課題」と「譲れない条件」を書く文書で、実現方式は各社の提案に委ねます。要件定義書は発注先が決まった後に「実際に作るもの」を確定させる文書。RFPの段階で実装方式まで書き切ると、より良い提案が出てこなくなります。

線引きの基準は「変えると相見積もりの前提が崩れるか」です。ページ数の概算、必須機能の有無、公開希望日、予算レンジはRFPへ。フォームの項目数、CMSの権限階層、画像の圧縮方式は、後から詰めても見積もりの桁が変わらないため要件定義に送ります。両者の書き分けはRFPと要件定義の違いと発注者の作業分担で範囲別に整理しています。

要件定義を省いた案件で起きる手戻りと追加費用が生じる典型経路

追加費用が発生する経路は、だいたい三つに絞られます。一つ目は、掲載情報の範囲が決まらないまま制作が始まり、原稿が揃わずに公開日が動くケース。二つ目は、フォームの項目や自動返信の仕様を保留し、開発着手後に条件分岐が増えるケース。三つ目が、更新体制を決めずに公開し、後から管理画面の改修を追加発注するケースです。跳ねるのは実装費より調整工数で、承認者が増えるほど1回の差し戻しに要する日数が伸びます。

サイトの目的・構成・デザイン要件を発注者側で決めるときの書き方

まずは発注者が主導で決める領域から。目的・構成・デザインの三つは、制作会社が代わりに決められない部分を含みます。

サイトの目的とKPIを数値で置くときの指標の選び方と粒度の基準

「認知度を上げる」は目的として機能しません。制作会社がどの案を採るべきか判断できないためです。判断材料になるのは、測れる指標と現在値の組。コーポレートサイトなら、問い合わせ件数、採用エントリー数、資料ダウンロード数、指名検索の表示回数あたりが候補になります。

粒度の目安は「四半期で有意な変化が見える単位」です。月3件の問い合わせを月5件にしたいならそう書きます。この数字があると、トップページを情報量重視にするか導線集中型にするかという設計判断が、好みではなく仮説の比較に変わる。現在値が取れていない場合は、公開前に計測環境を整えること自体を要件に含めてください。

サイト構成図とページ一覧で決める粒度と保留項目の扱い方の基準

サイト構成図は第2階層まで、ページ一覧は全ページ分。構成図で第3階層以下まで描くと、下層の1ページ増減のたびに図の更新が必要になり、誰も直さない図が残ります。ページ一覧は表計算で持ち、ページごとに次を記録します。

• ページ名とURLスラッグ（リニューアルの場合は旧URLも併記）
• 新規作成か、既存原稿の流用か、外部ライターへの依頼か
• 原稿の提供責任者と提供期限
• 公開時点で必須か、公開後の追加でよいか
• テンプレートの種別（固定ページ・記事詳細・一覧など）

決め切れない項目は空欄にせず「保留」と明記し、いつまでに誰が決めるかを同じ行に書きます。空欄は「決まっている」と誤読されますが、保留と書いてあれば制作会社がリスクとして見積もりに織り込めます。未確定の要件をリスク要因として文書に明示する扱いは、システム開発の標準ガイドラインでも規定されている考え方です。

デザイン要件を主観で揉めさせないための評価軸の決め方と合意手順

デザインの差し戻しが長引く案件は、評価軸を決めずにカンプを見始めています。要件定義の段階で判断の軸を3〜5個に絞って言語化しておく。たとえば「40代の総務担当が初見で事業内容を把握できる」「既存のロゴと名刺の色調から外れない」「写真は実際の社員と拠点を使う」といった具合です。

合意手順も先に決めておきます。カンプのレビューは何回まで、意見を出せるのは誰と誰、最終決裁者は1名。この3点を書いておくと、役員から公開直前に色の指摘が入る事態を制度的に防げます。好き嫌いを禁じるのではなく、好き嫌いを言う人とタイミングを決めるという発想です。

機能要件・CMS要件・非機能要件で数値化する項目と記載レベル

ここからは制作会社と一緒に詰める領域。発注者は「業務上どう困るか」を持ち寄ります。

フォームと検索・会員機能を要件に落とすときの記載の具体度の目安

機能要件は、画面の見た目ではなく入出力と分岐で書きます。問い合わせフォームなら、項目名と必須任意の別、入力チェックの条件、送信後の遷移先、自動返信メールの有無と宛先、社内通知の送信先、蓄積したデータの保存場所と保持期間。ここまで書けば実装の見積もりが割れません。

サイト内検索は対象範囲を先に決めます。記事本文だけか、PDFの中身も拾うのか、製品名の表記ゆれを吸収するのか。表記ゆれの吸収は実装コストが跳ね上がるため、必要な語を10〜20語に限った同義語辞書で運用するほうが現実的。会員機能は、そもそも必要かを疑ってかかってください。ログイン後にしか見せない情報が3ページ以下なら、URLを知る人だけが到達できる非公開ページで足ります。

CMSの更新権限と編集できる範囲を先に決めるときの判断の基準

公開後に「更新できないサイト」が生まれる原因の多くは、権限設計を要件に入れなかったことにあります。決めるべきは、誰がどのページのどの部分を触れるか、公開前の承認が必要か、承認者は誰か、の3点。広報部門だけが更新するなら権限は1種類で足ります。各事業部が自部門のページを更新し、公開前に広報が確認する運用なら、投稿者と承認者を分けた2階層が要ります。

編集範囲の指定も要件に含めてください。本文だけを編集させるのか、レイアウトブロックの追加まで許すのか。後者は自由度が上がる反面、ページごとにデザインが崩れていきます。記事本文と画像差し替えまでを担当部門に開放し、レイアウトと共通パーツは制作会社側に残す構成が破綻しにくい形。CMSそのものの選定はCMSの種類とWordPress・ヘッドレスの違いで発注視点の判断基準を整理しています。

表示速度・可用性・セキュリティを数値で握る非機能要件の記載方法

非機能要件は「速く」「安全に」では要件になりません。IPAの非機能要求グレード2018は、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーの6大項目で整理していますが、コーポレートサイトで数値まで詰める価値があるのは次の領域です。

表示速度の指標は、LCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下。モバイルとデスクトップに分けたページ読み込みの75パーセンタイルで判定され、3つすべてが基準を満たしたときに合格となります。INPは2024年にFIDに代わる安定版の指標になりました。検収時に測る端末とネットワーク条件を書いておかないと、社内の有線回線では合格し、実利用者の環境では不合格という状態が起こります。アクセシビリティは、改正障害者差別解消法が2024年4月1日施行で民間事業者にも合理的配慮の提供を義務づけた一方、JIS X 8341-3:2016の適合レベルAAは公的機関向けの基準で、民間にJIS準拠が課されているわけではありません。「AA準拠」と一括で書かず、確認できる項目に分解します。

サイトリニューアルで追加になる移行要件とSEO評価を落とさない条件

既存サイトのリニューアルでは、新規制作にない要件が3種類増えます。この3つを握れているかが、公開直後の検索流入の落ち込み幅を決めます。

旧URLと新URLの対応表とリダイレクト方式を要件に書く手順

URLが変わるリニューアルでは、旧URLと新URLの対応表を作ることが出発点。Googleの検索セントラルもサイト移転の手順として、新サイトの準備、URLマッピングの用意、リダイレクトの開始、移転後のトラフィック監視という流れを示しています。リダイレクトは、技術的に可能な場合はサーバーサイドの永続的なリダイレクト（301または308）を使う形が推奨されています。

対応表に載せるのは全URLではなく、被リンクがあるページ、検索流入のあるページ、社外資料に印刷されているURLの3種類です。それ以外の下層ページは統廃合先のカテゴリページへまとめて向ければ足ります。ドメインを変える場合は、サブドメインとwwwあり/なしの各バージョンについてサーチコンソールのアドレス変更ツールを申請します。HTTPからHTTPSへの移行だけなら、このツールは不要。工程管理の全体像はサイトリニューアルの進め方とSEO評価を落とさない手順にまとめています。

コンテンツ移行の対象範囲と作業分担を先に決める判断の順序と基準

コンテンツ移行は、本数と分担を数字で決めないと必ず揉めます。まず既存ページを全件書き出し、検索流入と問い合わせへの寄与で3群に分けてください。移行して原稿も手を入れる群、URLだけ引き継いで原稿はそのまま流し込む群、公開を停止して統合先へリダイレクトする群です。

そのうえで、流し込み作業の担当を本数単位で書きます。「200本のうち150本は制作会社が移行、50本は発注者が入力」といった形。ここを「協力して進める」と書くと、公開2週間前に150本の未入力ページが残ります。原稿の手直しが入る群は、執筆担当と期限も同じ行に紐づけます。

計測タグとフォーム連携の引き継ぎで漏れやすい要件の洗い出し方

移行の抜けが最も起きやすいのが、目に見えない部分です。アクセス解析のタグ、広告のコンバージョンタグ、フォームからマーケティングツールへの連携、資料ダウンロード時のイベント計測。旧サイトで動いていたものを一覧化し、新サイトのどのページに何を仕込むかを書き出します。

フォーム連携は特に注意が要ります。旧サイトが独自実装のフォームで、送信データを社内システムへPOSTしている場合、新サイトで同じ挙動を再現できるかを事前に確認しないと、公開後に問い合わせが社内に届かない事故になります。公開前後の数日は旧サイトの計測も並走させ、数値の断層を検知できる状態にしておいてください。

現状分析から関係部門の合意形成までの五工程と期間・工数の目安値

要件定義は、工程そのものより「誰をいつ巻き込むか」で所要期間が決まります。

アクセス解析と問い合わせ実績から課題を絞り込む現状分析の手順

現状分析で見るのは、アクセス解析、問い合わせの実績、営業や採用の現場が困っている点の3つ。アクセス解析からは流入の多いページと離脱の多いページ、検索経由で入ってくるクエリを取ります。問い合わせ実績からは、成約につながった経路と問い合わせ内容の傾向を拾います。

ここで課題を3〜4個に絞り込んでください。10個並べると優先順位がつかず、すべてが中途半端に反映されたサイトができあがります。要件定義そのものの目的と成果物は要件定義とは何かと進め方の全体像で扱っているため、この記事はWeb制作固有の論点に絞りました。スマホアプリや業務アプリの案件は決める項目が異なるため、アプリ開発の要件定義で決める項目を参照してください。

各部門から集めた要求に優先順位をつけていく進め方と判断の基準

要求の収集は、部門を回るより先に叩き台を作って反応を集めるほうが速く終わります。順序は次のとおりです。

1. 現状分析の結果から、目的とKPI、想定読者の仮案を1枚にまとめる
2. 関係部門に個別ヒアリングし、仮案への異論と各部門固有の要求を集める
3. 集まった要求を「目的に直結」「あると良い」「今回は見送り」の3群に仕分ける
4. 見送りにした要求は、理由と再検討の時期を添えて一覧に残す
5. 仕分け結果を関係部門に返し、異議のある項目だけを対面で議論する

仕分けの基準は、工程1で決めたKPIへの寄与です。「あると良い」に落ちた要求を切り捨てず、理由を書いて残すところに意味がある。記録がないと、公開直前に同じ要求が別の人から再提出されます。

要件定義書のレビューと社内の合意を取り切るまでの段取りと所要期間

要件定義にかかる期間は、サイトの規模より関係部門の数で決まります。1部門主導で30ページ規模なら3〜4週間、3部門以上が関わり業務システムとの連携があるなら8〜12週間が現実的な線。この期間の大半は承認待ちに消えます。

段取りとして効くのは、レビューの締切と「期限までに返答がなければ承認とみなす」運用を最初に合意しておくこと。加えて、最終決裁者には仕分けの過程を都度共有せず、確定した要件定義書を一度だけ通す形にします。途中経過を見せると、決まったはずの論点が繰り返し開き直されることになります。

要件を先に固め切る案件と段階的に決める案件を分ける判断の条件

要件定義は「必ず全部を先に決める」ものではありません。案件の性質によって、先に固め切るべき場合と段階的に確定させたほうが総費用の下がる場合に分かれます。

要件を発注前に確定させ切るべき案件の条件と見極めの具体的手順

次の3条件のうち2つ以上に当てはまるなら、要件を発注前に固め切ってください。第一に、複数社の相見積もりで発注先を決める案件。前提が揃っていない見積もりは比較になりません。第二に、社内の予算承認が年度単位で追加発注の余地がない案件。第三に、業務システムとのデータ連携がある案件です。連携仕様は後から変えると双方の改修が必要になり、費用が二重に発生します。見極めは、予算の追加申請にかかる手続きと日数を先に経理・購買部門へ確認するだけで足ります。

要件を段階的に確定してよい条件と契約・見積もりの書き分けの方法

逆に、発注先が既に決まっていて、予算に一定の幅があり、外部システム連携がない案件では、要件を段階確定にしたほうが総費用は下がります。デザインを見てから機能の要不要を判断できるためです。全部を先に決めると、使われない機能に費用を払うことになります。

この場合、契約と見積もりの書き方を分けます。サイト構成・ページ数・公開日・非機能要件は固定要件として契約に含め、フォームの項目数やCMSの権限階層は「上限を決めた変動要件」として別立てにする。「フォームは3種類まで、1種類あたり項目15個まで」と上限を決めておけば、詳細が未定でも見積もりの精度は保てます。上限のない「柔軟に対応」という書き方だけは避けてください。

発注者だけで要件定義書を仕上げようとして失敗する典型的な場面

発注者が単独で要件定義書を完成させようとして破綻するのは、非機能要件と移行要件を書く段階です。表示速度の目標値を根拠なく「1秒以内」と置き、実現に不要なCDN構成とサーバー増強が見積もりに乗る。あるいは既存サイトのURL構造を把握しないままリダイレクト方式を指定し、実装段階で対応表が作れないと判明する。

もう一つの失敗が、社内の誰も要件定義書を読み切れないケース。書ける範囲だけを自分で書き、技術的な水準の設定は制作会社と一緒に決める。目的は文書を単独で完成させることではなく、公開後に困らない状態を作ることにあります。

要件定義の段階から制作会社に任せる判断基準と委託範囲の決め方

制作会社に要件定義から任せるべきかの判断基準は、社内に「サイト全体の構成を描ける人」がいるかどうかの一点。いなければ、要件定義を工程として切り出し、有償で依頼したほうが結果的に安くつきます。

委託する場合でも、目的・KPI・対象読者・掲載情報の範囲・更新体制の5点は発注者が決めます。ここを含めて委託すると、自社の事情が反映されないサイトができあがる。要件の整理段階から相談したい場合は企業サイト制作・コーポレートサイト制作で対応しています。

よくある質問

Web制作の要件定義について、発注者から実際に寄せられる質問をまとめました。

Webサイトの要件定義書は何ページくらいになりますか？

30ページ規模のコーポレートサイトで、本文20〜40ページ程度に収まる案件が多い形です。ただし分量は品質の指標になりません。ページ一覧と機能一覧を別ファイルの表で持てば、本文は10ページ台でも十分に機能します。逆に100ページを超える文書は決裁者が読み切れず、合意が形骸化しやすくなる。保留項目とその決定期限が明記されているかを確認してください。

要件定義は制作会社に依頼できますか？費用はどれくらいですか？

依頼できます。要件定義だけを別工程として切り出す形が一般的で、その成果物を使って別の会社に相見積もりを取ることも可能です。費用は案件の規模と関係部門の数で幅が出るため、ヒアリング回数と成果物の範囲を先に決めたうえで見積もりを取ってください。社内にサイト全体の構成を描ける人がいない場合は、自力で書いて手戻りを起こすより外部に依頼するほうが総額を抑えられます。

RFPと要件定義書は両方作る必要がありますか？

複数社から提案を受けて発注先を選ぶなら、両方作ります。RFPは発注先を選ぶための文書、要件定義書は発注先が決まった後に作るものを確定させる文書で、時点も目的も違うためです。発注先が既に決まっている場合はRFPを省き、要件定義から始めて構いません。その場合も予算レンジと公開希望日は最初に共有しておかないと、実現できない要件を積み上げることになります。

リニューアルで検索順位が下がるのを防ぐには何を要件に入れますか？

旧URLと新URLの対応表、リダイレクト方式（サーバーサイドの301または308）、公開前後の計測並走、公開後のインデックス状況の監視期間の4点です。ドメインを変えるなら、サブドメインとwwwあり/なしの各バージョンについてサーチコンソールのアドレス変更ツールを申請する作業も含めます。移行対象は全URLに広げず、被リンク・検索流入・社外資料に載ったURLの3種類を優先してください。

要件定義にはどのくらいの期間を見ておけばよいですか？

1部門主導で30ページ規模なら3〜4週間、3部門以上が関わり業務システム連携があるなら8〜12週間が目安。期間の大半は承認待ちに消えるため、レビュー締切と「期限までに返答がなければ承認とみなす」運用を最初に合意しておくと短縮できます。関係部門の数が読めない段階では、まず巻き込む部門を確定させることから始めてください。

関連記事

• ホームページ制作のRFPとは？記載項目・コンペの進め方と発注判断を解説：要件定義の前段でRFPを作る場合の記載項目。
• コーポレートサイトとは？目的・役割と「成果が出る」基本構成をWeb制作目線で解説：サイト構成を決める前提となる基本構成。
• サイトリニューアルとは？目的・タイミング・費用の考え方と進めるべきかの判断：リニューアルの実施可否を判断する段階の記事。
• ホームページ制作費用の相場とは？依頼先・規模別の料金と見積もりの内訳を解説【2026年版】：見積もり金額の妥当性を判断する材料。
• 業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説：業務システム連携がある案件の書き方。