ホームページの要件定義とは｜要件定義書の作り方・項目・テンプレート

ホームページ制作の要件定義とは、制作を始める前に「何のために作るか」「誰が使うか」「何を掲載し、どの機能を備えるか」「どの状態を完成とするか」を関係者で合意する作業です。要件定義書には、目的やページ構成だけでなく、速度・セキュリティ、担当者、予算、公開条件、公開後の管理まで記録します。

小規模なホームページでも要件定義は必要です。ただし、大企業向けの長い文書を作る必要はありません。決めたこと、未決定のこと、誰がいつ決めるかを一つの資料へまとめるだけでも、見積もりのずれ、原稿待ち、仕様変更、公開後の管理者不明を防ぎやすくなります。

ホームページ制作における要件定義とは

要件定義は、希望する見た目を伝えるだけの工程ではありません。事業上の目的を、ページ、掲載情報、機能、品質、運用、確認方法へ置き換える工程です。たとえば「問い合わせを増やしたい」という希望だけでは、必要なページも完成条件も決まりません。対象者、問い合わせ前に必要な情報、受付方法、返信担当者、計測方法まで具体化します。

要件定義書は発注者と制作者の共通基準になります。見積もりでは依頼範囲をそろえ、制作中は追加・変更か当初範囲かを判断し、検収では完成条件と照合します。自作の場合も、作業の順番と公開後の管理を見失わないために役立ちます。

要件定義書・サイトマップ・ワイヤーフレーム・デザインカンプの違い

制作資料は役割が異なります。要件定義書で条件を決めた後、サイトマップでページの関係、ワイヤーフレームで画面内の情報順序、デザインカンプで完成時の見た目を確認します。

ページ構成はホームページのサイト構成とページ数の決め方、画面内の配置はワイヤーフレームの作成方法で詳しく確認できます。

要件定義書に含める項目一覧

必要な深さはサイトの規模とリスクで変わります。まず次の区分を用意し、決定済み、未決定、対象外を分けます。

背景・目的・成果指標を決める

最初に、現在どのような問題があり、ホームページで何を改善したいかを書きます。「古いから作り直す」だけでなく、会社情報が確認しにくい、問い合わせ前の説明が不足している、採用情報を更新できないなど、現在の状態を具体化します。

目的は中心となるものを決め、成果指標を対応させます。問い合わせが目的なら、送信件数だけでなく、対象外の相談を減らせたか、必要情報をそろえて受け付けられたかも確認できます。公開直後に十分なデータがない場合は、重要ページの閲覧、フォームの正常動作、検索での表示回数など段階的な指標を置きます。

対象者・利用場面・業務要件を整理する

「30代の男性」のような属性だけでなく、どの場面で訪れ、何を確認し、次に何をするかを整理します。初めて会社を知った人、比較中の人、既存顧客、採用応募者では必要情報が異なります。

ホームページ上の操作だけでなく、送信後の業務も要件です。問い合わせを誰が受け、何時間または何営業日以内に返信し、予約変更や資料請求をどこへ記録するかを決めます。受付後の業務が決まっていない機能は、画面だけ完成しても運用できません。

サイト構成・ページ・掲載情報を決める

目的と対象者の疑問から必要ページを決めます。トップページは全体案内、サービスページは提供範囲と条件、会社情報は運営主体の確認というように、ページごとに役割を一つ置きます。似たページを増やさず、詳しい情報は担当ページへ集約します。

ページ名だけでなく、各ページの主な見出し、必要な事実、原稿責任者、写真・図・表、関連ページ、公開優先度を一覧にします。原稿や画像が未準備なら、提供者と期限を決めます。仮文章や仮画像を完成素材として扱わないことが大切です。

機能要件を決める

機能要件には、利用者と管理者がホームページ上で行う操作を書きます。問い合わせなら入力項目、必須・任意、確認・完了、通知先、自動返信、保存、迷惑送信対策、削除までが対象です。予約・決済・会員機能では、変更、取消、失敗時、権限、外部サービス停止時も決めます。

必要機能の候補はホームページに必要な機能と選び方で確認できます。導入できるかだけでなく、利用頻度、担当者、月額費用、保存する情報、保守できる範囲から必要・不要を判断してください。

非機能要件を決める

非機能要件は、機能の数では表しにくい品質や運用条件です。「速く」「安全に」とだけ書かず、対象端末、確認環境、権限、更新方法など確認できる条件へ置き換えます。

• 表示速度：主要ページと画像の軽量化、計測する端末・回線・時期
• セキュリティ：HTTPS、管理者権限、多要素認証、更新、バックアップ、障害連絡
• レスポンシブ：確認する画面幅、実機、表・画像・メニュー・フォームの動作
• アクセシビリティ：見出し、代替テキスト、色だけに依存しない表示、キーボード操作
• 対応環境：対象ブラウザー、OS、古い環境をどこまで含めるか
• 可用性・復旧：停止時の連絡、バックアップ範囲、復元担当者、復旧目標

安全性の基本はホームページのセキュリティ対策で確認できます。

ドメイン・サーバー・CMS・外部サービス・管理権限を決める

利用するサービス名だけでなく、契約名義、支払い、管理者、復旧先メール、更新日、解約・移管方法を記録します。ドメインと主要アカウントは、制作担当者が変わっても事業者が確認・更新できる状態にします。

CMSでは、投稿・固定ページの更新者、公開承認、バックアップ、ソフトウェア更新を決めます。フォーム、予約、解析、地図など外部サービスを使う場合は、保存データ、利用規約、月額、障害時の代替手段、契約終了時のデータ取得も確認します。

SEO・Search Console・アクセス解析を決める

SEO要件には、検索語を並べるのではなく、ページごとの検索意図、title・H1、URL、内部リンク、canonical、XMLサイトマップ、構造化データの担当範囲を書きます。検索順位やインデックスを成果物として保証することはできません。

Google Search Consoleやアクセス解析は、誰のアカウントで作成し、誰が管理者となり、どの行動を計測するかを決めます。既存設定がある場合は二重設置を避けます。詳しい基本項目はホームページ作成時のSEO対策で確認してください。

既存サイト移行・旧URL・301・テスト・検収・公開条件を決める

リニューアルでは、現行ページ、画像、PDF、投稿、フォーム、計測、メール、ドメイン設定を一覧にし、移行、統合、削除を決めます。URLを変えるページは旧URLと新URLの対応表を作り、必要な301リダイレクト、内部リンク、サイトマップ、canonicalを同じ正規URLへそろえます。

テストは「見た目を確認する」だけでなく、対象端末、ブラウザー、フォーム送受信、リンク、権限、バックアップ、404、検索を妨げる設定まで範囲を決めます。検収では、誰が、どの資料と照合し、どの期間内に承認するかを決めます。公開条件を満たさない場合の延期判断と責任者も必要です。

担当者・承認者・予算・スケジュールを決める

依頼者側にも、事業情報を提供する人、原稿・画像を用意する人、法務・個人情報を確認する人、最終承認者が必要です。一人が兼任する場合も役割名を分けると、確認待ちの原因が分かりやすくなります。

予算は制作費だけでなく、撮影、原稿、素材、外部サービス、移行、公開後の保守を分けます。見積もりの考え方はホームページ作成費用の相場と内訳で確認できます。スケジュールには制作作業だけでなく、素材提供、社内確認、修正、検収、公開後確認の期間を含めます。

要件変更を管理する

制作開始後に要件が変わることはあります。変更を禁止するのではなく、変更理由、対象ページ・機能、費用、日程、他の要件への影響、承認者を記録します。口頭やチャットの一文だけで決めず、要件定義書と工程表を更新します。

必須条件、希望条件、公開後に追加できる条件を分けると、予算や日程が変わったときに優先順位を判断できます。ただし、会社情報の正確性、問い合わせの動作、必要な法的表示、セキュリティなど、公開条件として外せないものは後回しにしません。

小規模サイト向け要件定義書テンプレート

次の書式を一枚から始め、必要な説明だけ追加します。未決定事項には決定者と期限を書いてください。

• 背景・課題：現在困っていること
• 中心目的：ホームページで達成したいこと
• 対象者・利用場面：誰が、いつ、何を確認するか
• 期待する行動：問い合わせ、予約、来店、応募、資料確認など
• 成果指標：公開・動作・表示・問い合わせ等の確認方法
• 必要ページ：ページ名、役割、優先度、原稿・画像担当
• 必要機能：利用者、管理者、通知、保存、失敗時の動作
• 品質条件：スマホ、速度、セキュリティ、アクセシビリティ
• 公開環境：ドメイン、サーバー、CMS、外部サービス、管理者
• SEO・計測：URL、title、内部リンク、Search Console、アクセス解析
• 移行：旧URL、301、データ、メール、計測設定
• 体制：窓口、作成者、確認者、最終承認者
• 予算・日程：制作、素材、外部契約、保守、各確認期限
• 納品・検収：受け取るデータ、アカウント、マニュアル、確認方法
• 公開後：更新、保守、バックアップ、問い合わせ、契約更新
• 変更履歴：変更日、理由、影響、承認者

よくある質問

小規模なホームページにも要件定義は必要ですか

必要です。ただし大きな文書は要りません。目的、読者、必要ページ、機能、原稿担当、公開日、更新担当、契約管理者を一枚にまとめるだけでも、制作中の判断と変更理由を共有できます。

要件は制作開始後に変更できますか

変更できます。変更理由、対象範囲、費用・日程・他ページへの影響、承認者を記録してください。必須条件と希望条件を分けると、公開日を守るために何を後回しにできるか判断しやすくなります。

ワイヤーフレームは要件定義の前に作りますか

基本は目的、読者、必要ページ、掲載内容を整理した後です。画面の配置を先に決めると、必要情報が枠に合わせて削られることがあります。先に各ページの役割と必要素材を決めてください。

要件定義書は誰が作成しますか

制作者だけで完成させるものではありません。事業目的、サービス条件、承認、公開後の業務は依頼者が決め、技術要件や確認方法は制作者と整理します。最終的には発注責任者と制作責任者が同じ版を確認します。

まとめ

ホームページの要件定義では、目的、対象者、ページ、掲載情報、機能、非機能、公開環境、SEO・計測、移行、体制、予算、日程、検収、公開後の運用を共通認識にします。抽象的な希望を、対象ページ、必要な事実、担当者、確認方法へ置き換えることが大切です。

決まっていない事項には決定者と期限を付け、変更時は費用・日程・他要件への影響と承認を記録します。小規模サイトでは一枚のテンプレートから始め、見積もり、制作、検収、公開後の引き継ぎに同じ要件定義書を使ってください。