Webサイト制作の要件定義書とは？必要な項目・書き方を解説

Webサイトの要件定義書とは

要件定義とは、Webサイトの新規制作やリニューアルを行う際に、サイトの仕様や制作体制などを決定するプロセスです。その決定事項を文書にまとめたものが要件定義書です。

要件定義書には、サイトで実現したい仕様・機能・体制・スケジュールが整理されています。単なる「希望のメモ」ではなく、発注者・デザイナー・エンジニア・外注先が共通認識を持って開発に取り組むための判断基準ドキュメントとして機能します。

制作途中で方向性が揺れたとき、部署間で意見が対立したとき、「AとBどちらの方法を取るべきか」と迷ったとき、要件定義書は立ち返る「拠り所」となります。制作完了まで繰り返し参照される文書なので、誰が読んでも理解できる具体性で書くことが大切です。

要求定義との違い

要求定義と要件定義は似た言葉ですが、担う役割が異なります。要求定義は「○○したい」「△△の課題を解決したい」という発注者側の希望や要望を整理する段階です。一方、要件定義は「だからこういう仕様で実装する」と、その希望を具体的な設計・仕様に落とし込む段階を指します。

要求定義が不十分なまま要件定義に進むと、発注者の本来の意図が反映されず、完成物への不満が生じやすくなります。必ず要求定義を先に行い、その内容をもとに要件定義で実現方法を詰めましょう。

RFP（提案依頼書）との違いと作成者

要件定義書と混同されやすい文書にRFP（Request For Proposal：提案依頼書）があります。RFPは、発注先の制作会社を選ぶために発注者が作成する文書で、制作の背景・目的、解決したい課題、予算、希望スケジュールなどを伝え、各社から実現方法の提案を受けるために使います。一方の要件定義書は、発注先が決まったあとに「実際に何をどこまで作るか」を確定させる文書です。

一般的な流れは、要求定義（社内での要望・課題の整理）→ RFPの作成 → 制作会社の選定 → 要件定義・要件定義書の作成の順です。発注先がすでに決まっている場合は、RFPの作成と選定を省き、要求定義から要件定義へ進みます。

要件定義書のとりまとめは制作会社が担うケースが多いものの、サイトの目的やKGI・KPI、ターゲット、掲載する情報の範囲、公開後の更新体制は、発注者側でしか決められません。本記事では、発注者と制作会社が共同で要件定義書を作る前提で、それぞれが担う部分も含めて解説します。

要件定義書が必要な理由

要件定義書が必要な最大の理由は、Webサイト制作を円滑に進めるためです。要件定義を行わないと、デザインの方向性や実装すべき機能を制作チームに共有できず、完成物がイメージと大きく異なるリスクが高まります。

要件定義が曖昧なまま制作を進めると、特に「スコープクリープ」と呼ばれる問題が起きやすくなります。スコープクリープとは、要件の際限ない追加によってプロジェクトの範囲が膨らんでいく現象です。「あれもやりたい」「これも追加したい」という要望が制作途中で次々と浮上し、予算と納期を圧迫します。

また、担当者が途中で交代した場合も問題が生じます。要件定義書という文書があれば、プロジェクトの経緯・方針・決定事項を確実に引き継ぐことができます。しかし文書がなければ引き継ぎが口頭や断片的なメモに頼ることになり、方針のブレや認識ズレが繰り返されます。要件定義書は「担当者が変わっても方針が変わらない」仕組みを作るためにも欠かせない存在です。

要件定義書の作成手順

要件定義書の作成は、4つのステップで進めるのが基本です。①現状分析・課題整理 → ②方向性の検討 → ③関係者との合意形成 → ④文書化と共有という流れをたどります。

なお、①②は要求定義にあたる工程です。RFPを作成して制作会社を選ぶ場合は、RFPの作成前に発注者側で進めておき、③以降を制作会社と共同で進めるのが一般的です。

また、新規制作とリニューアルでは作業のウエイトが異なります。新規制作では市場・競合調査や方向性の検討に時間をかける一方、リニューアルでは既存サイトの課題分析が先決となり、現状分析のウエイトが大きくなります。

要件定義にかかる期間は、サイトの規模よりも関係部署の数に左右されます。1部署主導の小規模サイトであれば1か月前後、複数部署の確認や外部システムとの連携が必要なサイトでは2〜3か月を見込むケースもあります。

①現状分析と課題整理

現状分析では、定量データと定性データの両面から課題を把握します。定量データの収集にはGA4やSearch Consoleが有効で、訪問者の流入経路・閲覧数の多いページ・離脱率の高いポイントを特定できます。一方、ヒートマップツールやユーザビリティテストなどの定性データを組み合わせると、数値だけでは見えない「使いにくさ」や「不満点」を多角的に整理できます。

この分析を丁寧に行うことで、リニューアルで何を変え、何を残すかの判断基準が明確になります。「なんとなくデザインが古い気がする」といった感覚的な判断ではなく、データに基づいた課題設定がプロジェクト全体の質を左右します。リニューアルの場合は、検索流入のあるURLや外部からリンクされているURLもこの段階で洗い出しておきましょう。後述する移行要件の基礎データになります。

②方向性の検討

課題が整理できたら、解決に向けたコンセプト・機能アイデアをリストアップし、KGI・KPIを基準に優先順位を付けて絞り込みます。

方向性がまとまったら、社内のエンジニアや相談できる制作会社に技術的な実現可能性と工数を確認します。発注先がすでに決まっている場合は、制作会社のデザイナー・エンジニアに確認してもらいましょう。

実現が難しい施策や費用対効果の低い施策は、この段階で見送りや次フェーズへの持ち越しを判断します。見送った施策も理由とともに一覧に残しておくと、後から同じ要望が出たときに議論を蒸し返さずに済みます。

③関係者との合意形成

検討した方向性は、関係部署と上層部へ共有して承認を得ます。この合意形成を後回しにすると、完成間近に方針が覆されるリスクが高まります。承認のフローを「誰が・いつ・どこで」確認するかも、あらかじめ決めておきましょう。レビューの締切を設定し、期限までに意見がなければ承認とみなすといった運用ルールを最初に合意しておくと、確認待ちによる停滞を防げます。

④文書化と共有

合意が取れた内容を文書にまとめます。要件定義書は関係者全員がいつでもアクセスできる場所（共有ドライブ・プロジェクト管理ツールなど）に保管することが大切です。

作成のポイントは「制作中に迷ったときの判断軸になるよう書く」ことです。「目的はこれ」「ターゲットはこの人」「優先度はこの順番」といった基準が文書に明示されていれば、判断のたびに関係者に確認しなくても自律的に進められます。文字だけでわかりにくい体制図やワークフローには図表を活用し、途中参加のメンバーでも理解できる構成にしましょう。

また、確定後に変更が入ることに備えて冒頭に改訂履歴欄を設け、いつ・誰が・何を変更したかを記録しておきましょう。

要件定義書の基本要件に書く項目

要件定義書は大きく「基本要件」と「システム・機能要件」の2つに分かれます。基本要件は「なぜ作るか」「誰に届けるか」「どんな構造にするか」を固める部分で、この部分が曖昧なままだとデザインや機能の採否を判断する基準がなくなります。基本要件の多くは発注者の社内事情に関わるため、発注者が主体となって決める領域です。

制作の背景・目的

「なぜ今サイトを作るのか」「解決したい課題は何か」を具体的に記述します。背景・目的はプロジェクト全体の出発点となる項目で、ここが曖昧なままだと制作中の判断がぶれる原因になります。

目的は、達成期限と数値をセットで書くことが基本です。具体的な数値目標の立て方は、次のKGI・KPIの項目で解説します。

あわせて、制作に至る背景（競合状況・市場の変化・組織課題など）も簡潔に添えると、途中参加の関係者が経緯を理解しやすくなります。

KGI・KPIの設定

KGI（最終目標）とKPI（中間指標）は、要件定義書に独立した項目として必ず設定しましょう。KGIは「このプロジェクトで最終的に達成したいゴール」を指し、KPIはその達成状況を測る指標です。

たとえば「KGI＝資料請求数30%増」に対して「KPI＝フォーム到達率・月間セッション数・直帰率」のように設定します。「お問い合わせ数を月50件から70件へ引き上げる」のように、現在値と目標値を並べて書くと判断基準として一層機能します。KGIとKPIが明示されていると、機能選定の優先順位をつける議論がスムーズになります。「この機能はKPIのどれに効くか」という問いかけができるようになるため、感覚的な議論を避けられます。

逆にKGI・KPIが曖昧なまま進めると、制作中に「これもあれも必要では」と際限のない追加が起きやすく、スコープクリープの温床になります。プロジェクトの早い段階で確定させることが重要です。なお、現在値が計測できていない場合は、公開前に計測環境を整えること自体を要件に含めておきましょう。

ターゲット設定

どのようなユーザーに向けてサイトを作るかを明確にします。年齢・職業・抱える課題を具体化したペルソナを設定すると、デザインの方向性やコンテンツ方針が自然に定まります。

BtoBとBtoCではコンテンツや訴求方法が大きく異なります。BtoBであれば「購買決裁者」と「現場担当者」それぞれへの訴求が必要になるケースもあり、ターゲットが曖昧なままだとどちらにも刺さらないコンテンツになりがちです。

デザイン要件と合意の進め方

デザインのトーン＆マナー（色使い・フォントの印象・写真の雰囲気など）の方向感を記載します。ただし「洗練された印象」「親しみやすく」といった抽象的な言葉だけでは、デザイン案の評価が担当者の好みに左右され、差し戻しが長引く原因になります。

そこで、デザインを評価する観点を3〜5個に絞り、具体的な言葉で書いておくことが有効です。たとえば「初めて訪れた人が10秒以内に事業内容を把握できる」「会社のブランドガイドラインに沿っている（既存のロゴやパンフレットの色調から外れない）」「写真は実際の社員・拠点のものを使う」といった形です。あわせて、デザイン案のレビュー回数、意見を出せるメンバー、最終決裁者を決めておくと、公開直前に上層部から方向転換の指示が入るといった事態を防げます。

サイト構成

サイト全体のページ一覧と階層構造を図示化したサイトマップを作成し、どのページがどのように連携するかを整理します。各ページに掲載するコンテンツの概要を添えると、デザイン制作がスムーズに進みます。

ページ一覧は表計算ソフトで管理し、ページごとに以下の情報を記録しておくと、原稿の準備漏れや作業分担の認識ズレを防げます。

• ページ名とURL（リニューアルの場合は旧URLも併記）
• 原稿・画像を新規作成するか、既存のものを流用するか
• 原稿・素材の提供担当者と提供期限
• 公開時に必須のページか、公開後の追加でよいか

決まっていない項目は空欄のままにせず「未定」と明記し、誰がいつまでに決めるかを書き添えましょう。空欄は「決定済み」と誤解されやすく、後から追加費用の原因になります。

また、対応OS・ブラウザ・デバイス（PC・スマートフォン・タブレット）も明記しておきましょう。この指定がないと、「特定のブラウザで動作しない」「古いOSには対応していない」といったトラブルが完成後に発覚することがあります。公開画面と管理画面をそれぞれ分けて記載すると、後から確認しやすく、エンジニアとの認識合わせにも役立ちます。

スコープ（対応範囲）の明確化

今回のプロジェクトで「やること」と「やらないこと」を明記します。たとえば「今回は日本語サイトのみ、英語版は次年度に検討」「会員機能は対象外」のように、対象外とする範囲まで書いておくことがポイントです。

対象外の範囲が明示されていれば、制作途中に出た要望が今回の範囲に含まれるかどうかをすぐに判断でき、スコープクリープを防ぐ有効な手段になります。

プロジェクト体制とスケジュール

要件定義において、体制とスケジュールの明確化はプロジェクト成功の鍵を握ります。以下のポイントを整理して記載しましょう。

担当者と承認者の明確化

「誰が実務を担当するのか」「誰が最終承認を行うのか」を明確にします。責任の所在をはっきりさせることで、確認待ちによる遅延を防ぎます。

コミュニケーションツールの統一

SlackやBacklogなど、情報共有に使うツールを一つに絞りましょう。連絡手段が分散すると情報が追えなくなり、意思決定が遅れる原因となります。

バッファを持たせたスケジュール設定

公開目標日から逆算して各フェーズの期限を設定します。予期せぬトラブルに備え、作業工数の10〜20%程度のバッファ（余裕）を見込んでおくのが安全です。

用語の定義

要件定義書の中で使う専門用語や社内用語、略語の意味を一覧にしておきます。同じ言葉でも部署や会社によって指す範囲が異なることがあり、「CV」「会員」「お知らせ」などの言葉の解釈がずれたまま進むと、仕様の認識違いにつながります。途中から参加するメンバーが内容を理解しやすくなる効果もあります。

要件定義書のシステム・機能要件の項目

システム・機能要件は、サイトを実際に動かすための技術的な取り決めをまとめるパートです。エンジニアや制作会社と相談しながら決める箇所が多く、各項目に「担当者名」と「確認済みステータス」を記録しておくと管理しやすくなります。機能の優先度（必須・推奨・任意）を明記しておくと、開発スケジュールの調整もスムーズに進みます。専門的な内容が多いパートですが、発注者は「業務上どう困っているか」「何ができると助かるか」を伝えれば、制作会社が要件の形に落とし込んでくれます。

機能要件

実装する機能をリスト化します。主な例としては、お問い合わせフォーム・サイト内検索・ログイン機能（会員限定ページがある場合）・パンくずリスト・アクセス解析タグの設置などが挙げられます。

各機能には「Must（必須）」「Should（推奨）」「Could（任意）」の優先度を設定しましょう。これにより、開発スコープの調整が必要になったときに「どこを削るか」「何を次のフェーズに回すか」の議論がスムーズになります。なお、要件定義確定後の機能追加は追加費用の対象になりやすいため、この段階でできるだけ網羅的に検討することが重要です。

機能は見た目ではなく、入力・出力・処理の流れで書くと見積もりがぶれにくくなります。お問い合わせフォームであれば、項目名と必須・任意の別、送信後の画面、自動返信メールの有無、社内の通知先、送信データの保存先まで記載しておくのが理想です。

CMSの更新権限と承認フロー

公開後に「誰も更新できないサイト」になってしまう原因の多くは、更新権限の設計を要件に含めていないことにあります。誰がどのページを更新できるか、公開前に承認が必要か、承認者は誰かを決めておきましょう。

たとえば広報部門だけが更新する場合は権限が1種類で足りますが、各部署が自部署のページを更新し、広報が公開前に確認する運用であれば、投稿者と承認者を分けた権限設計が必要です。また、本文の編集だけを許可するのか、レイアウトの変更まで許可するのかも決めておきます。編集の自由度を上げすぎると、ページごとにデザインが崩れていく原因になります。

システム・技術要件

使用CMS・開発言語・フレームワーク・バージョン管理方法を明記します。

CMSを選定する際は、CMSやプラグインの動作要件と、サーバー環境（PHPなどの言語のバージョン、データベースの種類など）が合っているかを事前に確認しましょう。たとえばPHPで動くCMSの場合、サーバー側のPHPバージョンが古いと、最新のCMSや必要なプラグインが動作しないケースがあります。導入するプラグインやフロントエンドフレームワークの選定も先に行っておくと、後からの変更による工数増を防げます。

インフラ要件

本番環境・検証環境それぞれのサーバー・ドメイン・SSL証明書・DNS・メールサーバーについて、事前に誰がどう管理しているのかを確認し、要件定義書に整理しましょう。

特にドメインとDNSの管理権限は、公開後に制作会社を変更する際にも影響するため、発注者側で保持しておくのが安全です。サービスによって費用が異なるため、予算の確認もあわせて行いましょう。

セキュリティ要件

扱う情報の機密性に応じてセキュリティ対策のレベルを決めます。個人情報や決済情報を扱うサイトと、情報発信のみを目的とするサイトとでは、必要な対策が大きく異なります。

対策の例としては、管理画面へのIP制限・WAF（Web Application Firewall）の導入・定期バックアップ・不正ログイン対策（二要素認証など）などが挙げられます。セキュリティ対策を強固にするほどコストが上がるため、「何をどこまでやるか」をエンジニアや専門業者と相談しながら優先事項を決めることが大切です。

表示速度・アクセシビリティなどの非機能要件

非機能要件とは、機能そのものではなく、サイトの性能や使いやすさ、安定性に関する要件です。「速く表示される」「誰でも使える」といった抽象的な書き方では検収の基準にならないため、できるだけ数値や確認方法で記載します。

表示速度は、GoogleのCore Web Vitalsを基準にするのが一般的です。LCP（主要コンテンツの表示時間）2.5秒以内、INP（操作への応答時間）200ミリ秒以下、CLS（レイアウトのずれ）0.1以下が「良好」とされる目安です。検収時にどの端末・回線環境で計測するかもあわせて決めておきましょう。そのほか、稼働率やメンテナンス時の告知方法なども非機能要件に含まれます。

アクセシビリティについては、2024年4月施行の改正障害者差別解消法により、民間事業者にも障害のある人への合理的配慮の提供が義務化されました。Webアクセシビリティの規格としてはJIS X 8341-3:2016があり、国や地方公共団体などの公的機関には、総務省のガイドラインで適合レベルAAへの対応が求められています。

民間企業のサイトでは一律の準拠義務はありませんが、「文字と背景のコントラスト比」「キーボードだけで操作できるか」「画像に代替テキストがあるか」など、確認できる項目に分解して要件化しておくと、品質のばらつきを防げます。

品質管理・検証要件

公開前に行う検証の範囲・内容・環境を定めます。リンク切れや表示崩れの確認、フォーム送信やメール通知の動作確認、対象デバイス・ブラウザでの表示検証などが代表的な項目です。検証項目は要件定義書の内容に基づいて作成されるため、要件が詳細に書かれているほどテストの精度も上がります。

あわせて、修正対応の回数や範囲、仕様変更が発生した場合に追加費用やスケジュール調整が必要になる条件もここで明記しておくと、検収段階でのトラブルを防げます。

リリース要件

公開日時・担当者・合否の判断基準、公開作業の手順（バックアップの取得、ファイルの反映、公開後の動作確認など）を事前に定めます。

テストから本番公開までは十分な日程を確保し、不備が発見された場合の修正時間を見込んでおきましょう。公開作業は担当者だけでなく、最終確認を行う承認者も事前に決めておくと、リリース直前の連絡漏れを防げます。万一の不具合に備え、旧環境に切り戻す手順も用意しておくと安心です。

運用保守の方針

公開後の更新担当・更新頻度・問い合わせ窓口を決めておきます。「作って終わり」になりがちなサイト制作プロジェクトですが、公開後の運用体制まで要件定義書に盛り込むことで、運用フェーズへのスムーズな移行が可能になります。

外部委託の場合は、保守期間・対応範囲・費用を明記します。保守の対応範囲としては、CMSやプラグインのアップデート、バックアップと復旧、不具合修正、軽微な更新作業などが挙げられます。対応時間（平日のみか、休日も対応するか）もあわせて決めておきましょう。また「誰がCMSを更新するか」をあらかじめ想定し、担当者のITリテラシーに合わせた管理画面の操作性を機能選定の基準に含めることも重要です。操作が難しいCMSを採用してしまうと、更新が滞ってコンテンツが古いままになるリスクがあります。

リニューアルで追加する移行要件

既存サイトのリニューアルでは、新規制作にはない要件が加わります。ここを要件に含めずに進めると、公開後に検索順位が大きく下がる、問い合わせが届かなくなるといった事故につながります。

旧URLと新URLの対応表・リダイレクト

URLが変わる場合は、旧URLと新URLの対応表を作成し、旧URLへのアクセスを新URLへ転送するリダイレクトを設定します。リダイレクトは、検索エンジンの評価を引き継ぐために、サーバー側で設定する恒久的なリダイレクト（301または308）を使うのが基本です。

対応表は全URLを網羅するのが理想ですが、ページ数が多い場合は、検索流入のあるページ、外部からリンクされているページ、印刷物や広告に掲載しているURLを優先します。ドメイン自体を変更する場合は、Google Search Consoleのアドレス変更ツールの申請も必要です。

コンテンツ移行の範囲と分担

既存ページを全件書き出し、「内容を見直して移行する」「そのまま移行する」「廃止して関連ページへリダイレクトする」の3つに分類します。そのうえで、移行作業を誰が何本担当するかを本数単位で明記しましょう。「協力して進める」といった曖昧な書き方では、公開直前に大量の未移行ページが残る原因になります。

計測タグ・フォーム連携の引き継ぎ

見落としやすいのが、画面に表示されない仕組みの引き継ぎです。アクセス解析タグ、広告のコンバージョンタグ、フォームと顧客管理ツールの連携、構造化データなど、旧サイトで動いているものを一覧化し、新サイトのどのページに設定するかを要件に含めます。特にフォーム連携は、公開後に問い合わせが社内に届かないという重大な事故につながるため、事前の動作確認が欠かせません。

要件定義書の記入イメージ

要件定義書の形式に決まりはなく、表計算ソフトで一覧にまとめる方法や、スライド・文書形式でまとめる方法があります。ここでは、採用サイトのリニューアルを想定した架空の案件をもとに、本記事で解説した項目を表計算ソフトにまとめた場合の記入イメージを紹介します。

▼基本要件の記入イメージ

▼システム・機能要件と移行要件の記入イメージ

要件定義書の確認ポイント

作成した要件定義書が判断基準として機能するか、以下の観点で確認しましょう。

なお、記入イメージや確認ポイントの項目をすべて埋めればよいわけではありません。

自社のプロジェクトに不要な項目は削除し、固有の事情に合わせた項目を追加して使いましょう。項目を埋めること自体が目的化してしまうと、実際の制作の場面で判断の根拠として機能しない要件定義書になってしまいます。本記事の項目を起点に自社独自の視点を加えることで、実践的な文書に仕上がります。

失敗しないためのポイント

要件定義書の作成・運用でよく見られる失敗は、「目的が曖昧なまま進めた」「関係者への共有が後回しになった」「運用体制を考えずに機能を選んだ」という3つのパターンに集約されます。それぞれの対策を押さえておきましょう。

目的を数値で定義する

よくあるのは、「ブランドイメージを上げたい」「使いやすいサイトにしたい」といった定性的な目的だけで制作を始め、デザイン案のたびに関係者の好みで議論が割れてしまうケースです。定性的な目的だけでは、制作中の判断基準になりません。数値目標と達成期限をセットで書くことで、はじめて判断軸として機能します。

関係者を早期に巻き込む

よくあるのは、Web担当部署だけで要件をまとめ、デザインがほぼ固まった段階で他部署や役員に共有した結果、大幅なやり直しが発生するケースです。各部署・上層部への確認を先送りにすると、制作が進んだ後に「そんな話は聞いていない」という反発や方針転換が起きるリスクが高まります。早い段階から関係者を巻き込み、それぞれの意見を要件定義の段階で吸収しておくことが重要です。

運用まで視野に入れて作る

よくあるのは、制作時に多機能なCMSを導入したものの、公開後に更新担当者が操作を覚えられず、半年後には情報が古いまま放置されてしまうケースです。

「作って終わり」を防ぐために、更新フロー・外部委託の範囲・サポート期間も要件定義書の段階で明記しておきましょう。公開後の運用まで見据えて機能を選定することが、長期的に成果を出し続けるサイト作りの基本姿勢です。

よくある質問

まとめ

サイト制作の要件定義書は、発注者・制作チーム・関係部署が共通認識を持ってプロジェクトを進めるための「判断基準ドキュメント」です。基本要件（目的・KGI/KPI・ターゲット・デザイン要件・サイト構成・スコープ・プロジェクト体制・用語の定義）とシステム・機能要件（機能・CMS権限・技術・インフラ・セキュリティ・非機能要件・品質管理・リリース・運用保守）の両面をもれなく整理することで、手戻りや追加費用のリスクを大幅に抑えられます。リニューアルの場合は、URL対応表やコンテンツ移行などの移行要件も忘れずに盛り込みましょう。

テンプレートを活用して効率よく作成しつつ、自社プロジェクトに合わせたカスタマイズを加えることが大切です。目的の数値化・関係者の早期巻き込み・運用フェーズまでの視野を持って取り組むことで、制作完了後も判断の拠り所として機能する実践的な要件定義書を仕上げましょう。