Webサイトの制作やリニューアルを制作会社に依頼すると、打ち合わせの途中で「要件定義書を確認してください」と言われることがあります。システム開発の用語のように聞こえ、何を見ればよいのか、自社が何を決めなければならないのか分からないまま承認してしまう担当者の方も少なくありません。
要件定義書は、サイトで「何を・どこまで・いつまでに・どの条件で作るか」を発注者と制作会社が合意して残す文書で、書くのは主に制作会社でも、中身を決めて承認する責任は発注者にあります。ここがあいまいなまま進むと、デザインの段階での手戻りや、見積もりにない追加費用の原因になります。
この記事では、要件定義書の役割、提案依頼書（RFP）などほかの文書との違い、Webサイト制作の要件定義書に書く項目、要件定義の進め方、サイト設計との関係、発注者が確認するときのチェックリストとよくある失敗を解説します。
要件定義書とは
要件定義書とは、Webサイトやシステムを作る前に、目的・制作範囲・機能・品質・スケジュール・体制などの「満たすべき条件（要件）」をまとめ、発注者と制作会社の合意内容として残す文書です。
「要件定義」はその条件を決める工程を、「要件定義書」は決めた結果をまとめた文書を指します。Webサイト制作では、要件定義書という名前ではなく「仕様書」「設計書」「要件シート」などと呼ぶ会社もあり、形式もWord・Excel・PowerPoint・スプレッドシートなどさまざまです。名前や形式よりも、後で挙げる項目が文書で合意されているかどうかが重要です。
要件定義書は制作会社がまとめるのが一般的ですが、発注者が関わらずに作られるものではありません。目的、ターゲット、載せる情報、予算と時期、公開後の運用といった中身は発注者にしか決められないため、ヒアリングで伝え、ドラフトを確認し、承認するところまでが発注者の役割です。
提案依頼書（RFP）・見積書・設計書との違い
Webサイト制作で使う文書は作る人とタイミングが違い、要件定義書は「制作会社を決めた後、設計に入る前」に双方の合意を固める文書です。
| 文書 | 作る人 | タイミング | 主な中身 |
|---|
| 情報提供依頼書（RFI） | 発注者 | 制作会社を探す段階 | 会社の概要、実績、体制、対応できる範囲など、情報提供の依頼 |
| 提案依頼書（RFP） | 発注者 | 制作会社に提案を依頼するとき | 背景、目的、課題、範囲、予算、スケジュール、提案してほしいこと |
| 提案書・見積書 | 制作会社 | RFPを受け取った後 | 進め方、構成案、体制、費用の内訳 |
| 要件定義書 | 主に制作会社（発注者が確認・承認） | 契約後、設計の前（契約前に概要を詰めることもある） | 目的、範囲、機能要件・非機能要件、体制、スケジュール、運用 |
| 設計書（サイトマップ・ワイヤーフレーム） | 制作会社 | 要件定義の後 | ページの構成と階層、各ページに載せる要素と配置 |
RFPは「こういうことを実現したいので提案してほしい」という依頼の文書で、要件定義書は「この条件で作る」という合意の文書です。RFPの内容が不十分だと、制作会社は正確な要件を引き出せず、要件定義の段階で前提が大きく変わることになります。RFPの書き方は、提案依頼書とは？重要な理由や作成ポイントを解説で解説しています。
Service
コーポレートサイト制作のご相談はフェニックスデザインへナレッジベースを運営するフェニックスデザインが、今のサイトの数字を見るところから対応します。URLを入れるだけの無料簡易診断から。
要件定義書が必要な理由
要件定義書が必要なのは、口頭の合意だけでは、発注者と制作会社、さらに社内の関係者の間で「作るもの」の認識がずれるからです。
- 認識のずれを防ぐ：「スマホ対応」「SEO対策込み」「更新しやすい」といった言葉は、人によって想定する範囲が違います。具体的な条件として書くことで、完成後の「思っていたものと違う」を防げます。
- 費用と期間の前提を固める：ページ数、機能、原稿の担当が決まって初めて、見積もりとスケジュールが確定します。
- 追加費用の線引きができる：合意した範囲が文書にあれば、後から出た要望が範囲内か追加かを判断できます。
- 社内の承認を得やすくなる：経営層や関係部署に、何をいくらでいつまでに作るのかを1つの文書で説明できます。
- 検収と公開後の基準になる：納品物の確認や、公開後に効果を確かめるときの基準として使えます。
Webサイト制作の要件定義書に書く項目
Webサイト制作の要件定義書には、目的・範囲・コンテンツ・デザイン・機能・品質・SEOと計測・インフラ・体制・運用・費用と権利にわたる、次の13の項目を書きます。
| 項目 | 書く内容 | 発注者が確認すること |
|---|
| 1. 背景・目的・KPI | 新規制作やリニューアルの背景、目的、成果を測る指標と目標値 | 社内で合意した目的とずれていないか。指標が測れる形になっているか |
| 2. ターゲット | 想定する閲覧者（見込み客、求職者、取引先など）と、その人が知りたいこと | 営業・採用の現場の実感と合っているか |
| 3. 制作範囲 | ページ一覧とページ数、新しく作るページと流用するページ、対応するデバイス・ブラウザ | 必要なページが漏れていないか。範囲外のものは何か |
| 4. コンテンツ | 原稿・写真・図解を誰が用意するか、旧サイトから移す内容、提出の期限 | 社内で期限までに用意できるか |
| 5. デザイン | トーン＆マナー、参考サイト、ロゴやブランドカラーの扱い、修正回数 | 判断の基準と最終決定者が決まっているか |
| 6. 機能要件 | 問い合わせフォームの項目と通知先、CMSで更新できる範囲、サイト内検索、多言語、資料ダウンロード、外部システムとの連携 | 目的に必要な機能がそろっているか。不要な機能が入っていないか |
| 7. 非機能要件 | 表示速度、セキュリティ、アクセシビリティ、バックアップ、稼働の監視 | 「速く」「安全に」ではなく、目標や対策が具体的に書かれているか |
| 8. SEO・計測 | 対策キーワードとページの対応、title・description、構造化データ、GA4・Search Consoleの設定、計測する行動（GA4のキーイベント）、旧URLからの301リダイレクト | 公開後に成果を数字で確認できるか |
| 9. インフラ | サーバー・ドメイン・SSLの種類、契約の名義、手配する担当 | 自社名義で契約できるか。管理アカウントを誰が持つか |
| 10. 体制・スケジュール | 双方の担当者と決定者、工程ごとの期限、打ち合わせと連絡の方法 | 社内の確認期間を見込んだ日程になっているか |
| 11. テスト・公開 | 確認する範囲と方法、公開日、公開の手順 | 誰がどこまで確認するか |
| 12. 運用・保守 | 公開後の更新担当、保守の範囲、マニュアル、問い合わせの対応時間 | 公開後の費用と社内の作業が見えているか |
| 13. 費用・権利 | 費用と支払い条件、追加費用が発生する条件、著作権とデータの引き渡し | 範囲外の作業の費用と、権利の扱いが書かれているか |
機能要件と非機能要件の違い
機能要件は「サイトで何ができるか」、非機能要件は「どのくらいの品質で動くか」です。たとえば、問い合わせフォームで「会社名・氏名・メールアドレス・相談内容を送信でき、担当者に通知メールが届く」は機能要件、「スマートフォンでも待たされずに表示される」「送信内容は暗号化された通信で送る」「毎日バックアップを取る」は非機能要件にあたります。非機能要件は見落とされやすいものの、表示速度やセキュリティは公開後の成果と信頼に直結するため、目標や対策を具体的に書いておきます。
要件定義の進め方
要件定義は、社内で目的を整理し、制作会社のヒアリングを経て要件を洗い出し、優先順位をつけて文書にし、承認する順に進めます。
- 社内で目的と課題を整理する：現状のアクセス数や問い合わせ数、営業・採用担当の声を集め、何を解決したいのかをまとめます。
- 提案依頼書（RFP）をまとめ、制作会社を選ぶ：同じ内容を複数の候補に渡し、提案と見積もりを比べます。
- ヒアリングと現状の確認を受ける：制作会社が事業・顧客・競合と、現サイトの数字を確認します。
- 要件を洗い出し、優先順位をつける：「必須」「あれば望ましい」「公開後に検討」の3段階に分けると、予算とスケジュールに合わせて判断しやすくなります。
- 要件定義書のドラフトを確認する：あいまいな表現、範囲外の項目、社内の作業と期限を確認します。
- 関係者の承認を得る：経営層や関係部署の確認は、デザインに入る前のこの段階で済ませます。
- 変更のルールを決める：承認後に要件を変えたい場合の手続きと、費用・期間への影響の扱いを決めておきます。
要件定義とサイト設計の関係
要件定義で「何を作るか」を決めたら、サイト設計で「どう組み立てるか」を決め、その設計に沿ってデザインを判断します。
要件がまとまると、サイト全体のページの階層を示すサイトマップ（ディレクトリマップ）と、各ページに載せる要素と配置を示すワイヤーフレームを作ります。この2つがあると、発注者と制作会社が同じものを見ながら話せるため、「あの情報が抜けていた」「問い合わせボタンが分かりにくい」といった問題を、デザインに入る前に見つけられます。設計の手順はサイト設計とは？設計前にチェックしたい項目や具体的な手順、ワイヤーフレームの見方はワイヤーフレームとは？作り方や役立つツールを紹介で解説しています。
デザインを担当者や決裁者の好みで選ぶと、要件と設計で決めた導線や機能が考慮されず、制作が進んでから「必要な機能が入っていない」「イメージと違う」といった手戻りが起きます。デザインは、要件定義で決めた目的とターゲット、設計で決めた構成に合っているかで判断します。
発注者が要件定義書を確認するときのチェックリスト
要件定義書を承認する前に、次の項目を確認します。
- 目的と数値目標が、社内で合意したものと同じか
- 「おしゃれに」「使いやすく」など、人によって解釈が変わる表現が残っていないか
- ページ一覧に、必要なページがすべて入っているか
- スマートフォン対応と、対応するブラウザが明記されているか
- 「SEO対策」の範囲（技術的な設定のみか、キーワード調査やコンテンツ制作を含むか）が書かれているか
- 原稿・写真を誰がいつまでに用意するかが決まっているか
- デザインの修正回数と、それを超えた場合の費用が書かれているか
- 問い合わせなどの成果を計測する設定が含まれているか
- ドメイン・サーバーの契約名義と、管理アカウントを誰が持つかが書かれているか
- 公開後の更新・保守の範囲と費用が分かるか
- 範囲外の作業と、追加費用が発生する条件が書かれているか
要件定義でよくある失敗と防ぎ方
要件定義の失敗の多くは、目的と判断基準を文書にしないまま、デザインや機能の話に進んでしまうことから起きます。
| よくある失敗 | 主な原因 | 防ぎ方 |
|---|
| デザインの段階で「イメージと違う」と全面的にやり直した | 目的とトーン＆マナーを文書で合意せず、デザインで初めて方向性を話し合った | 要件定義でトーン＆マナーと判断基準を決め、トップページのデザインで方向性を確認する |
| 機能の追加が続き、費用と納期が膨らんだ | 必須の機能と、あれば望ましい機能を分けていなかった | 優先順位を3段階に分け、公開後に追加するものを決めておく |
| 公開直前に別の部署から修正が入った | 関係者の承認を要件定義の段階で取っていなかった | ドラフトの段階で関係部署に確認してもらう |
| 公開後、社内で更新できなかった | CMSで更新できる範囲を要件に入れていなかった | 更新の担当と頻度を決め、更新したいページを要件に書く |
| 公開後に成果が分からない | 計測する行動と指標を決めていなかった | KPIとGA4のキーイベントを要件に入れる |
当社の進め方：要件を工程ごとの成果物で合意する
当社フェニックスデザインでは、要件にあたる内容を工程ごとの成果物として文書にまとめ、確認・合意してから次の工程に進めています。
| 工程 | 期間の目安 | 文書にまとめる内容 | 発注者にお願いすること |
|---|
| 01 ヒアリング・現状診断 | 1〜2週 | ヒアリングシート、現状診断レポート（アクセス・順位・導線・速度・セキュリティ）、課題と優先順位の一覧 | ヒアリング（1〜2時間）への参加、GA4・Search Console・サーバーの閲覧権限の共有 |
| 02 ブランディング設計 | 2〜3週 | ブランディング設計書（コンセプト、トーン＆マナー、キャッチコピー、求める顧客像） | ヒアリングシートの記入、設計書の確認・承認（1週間程度） |
| 03 情報設計・ワイヤーフレーム | 2週 | サイトマップ、全ページのワイヤーフレーム、対策キーワード一覧、CTA・計測の定義 | 確認・承認、掲載する情報（実績・数字・制度など）の提供 |
以降のデザイン・実装は、この3つの工程で合意した内容を基準に進めます。合意後に内容を変える場合は、影響する範囲に応じて追加の費用と期間をご相談のうえ対応します。デザインから公開後までを含む全工程と成果物は、制作の流れに載せています。
よくあるご質問
要件定義書は発注者が作るものですか？
一般的には制作会社がまとめ、発注者が中身を伝えて確認・承認します。発注者が事前に用意するのは、要件定義書そのものではなく、目的・課題・範囲・予算・時期をまとめた提案依頼書や要望の整理メモです。
小規模なサイトでも要件定義書は必要ですか？
5ページ程度のサイトでも、目的、ページ一覧、原稿と写真の担当、必要な機能、公開後の運用、費用の範囲は文書に残しておくことをおすすめします。1〜2枚の簡単なものでも、後から「言った・言わない」になるのを防げます。
要件定義書を承認した後に内容を変えることはできますか？
変えられますが、影響する範囲に応じて費用と期間が変わることがあります。どの段階でどんな変更をすると何に影響するのかを、変更のルールとして先に決めておくと、判断がしやすくなります。
提案依頼書がなくても制作会社に相談できますか？
相談できます。目的、今のサイトの状況、予算と時期の目安が分かれば、制作会社がヒアリングの中で要件を整理していきます。当社では30分の無料相談でこれらを伺い、2〜3日で現状確認と構成案を作ったうえで、1週間以内に内訳つきのお見積りをお出ししています。
まとめ
要件定義書は、Webサイトで「何を・どこまで・いつまでに・どの条件で作るか」を発注者と制作会社が合意して残す文書です。まとめるのは主に制作会社でも、目的・ターゲット・範囲・原稿の担当・公開後の運用といった中身は発注者が決め、承認します。13の項目とチェックリストで確認し、承認後の変更ルールまで決めておくと、手戻りと追加費用を防げます。
当社では、ヒアリングから設計までの工程ごとに要件を文書にし、合意してから制作に進めています。進め方と料金はコーポレートサイト制作のページでご覧いただけます。
関連記事：Web制作会社の選び方：失敗しない比較ポイントと依頼前の準備／ホームページ制作の見積書の見方／コーポレートサイトに必要なページ構成一覧