サイトリニューアルの要件定義書の書き方｜テンプレート付き

はじめに

「制作会社に発注したら思っていたものと違うものができた」——このトラブルの多くは、要件定義が不十分なまま発注が進んだことに起因します。要件定義書は、発注者と制作会社が「何を作るか」について共通認識を持つための最重要ドキュメントです。

本記事では、サイトリニューアルの要件定義書の構成と各項目の書き方、よくある失敗とその対策を実践的に解説します。

要件定義で整理すべき項目一覧｜目的・ターゲット・機能要件・非機能要件・移行・SEO

要件定義でつまずくプロジェクトの多くは、項目そのものよりも「誰が決めるか」が曖昧なまま進んでいます。決裁者が決めるべき項目を制作会社に委ねると、後から方針が覆り手戻りになります。整理すべき項目と決定の主体を一覧で確認してください。

要件定義の進め方｜社内で決めること・制作会社に任せること

要件定義は、発注側がすべてを書き切る作業ではありません。事業として何を達成したいかは社内でしか決められず、技術的にどう実現するかは制作会社のほうが精度の高い判断ができます。この分担を前提に、次の4ステップで進めます。

1. 現状把握：現行サイトのページ数、CMS、アクセス状況、更新業務の実態を洗い出します。社内でしか行えない作業です。

2. 目的の確定：洗い出した課題のうち、今回解決するものを決裁者が選びます。絞り込みが後の判断のぶれを防ぎます。

3. 要件の優先順位付け：必要な機能を必須・推奨・将来対応に分類します。実現方法は制作会社に任せ、発注側は「何のために必要か」を説明できる状態にします。

4. RFPへの反映：整理した内容を提案依頼書にまとめて複数社に提示します。前提条件がそろえば各社の提案を同じ基準で比較できます。

提案依頼書の具体的な書き方については、RFP（提案依頼書）の書き方｜Web制作会社への依頼を成功させるで詳しく解説しています。

大規模サイト（数千ページ規模）の要件定義で追加になる項目

ページ数が数千を超えると、中小規模では問題にならなかった論点が前面に出ます。移行と権限の設計を要件定義で固めないと、実装後の修正が手戻りになります。

• コンテンツの棚卸し基準：移行・統合・廃止を判断する基準を先に決めます

• URL設計とリダイレクト方針：URLを維持するページと変更するページを区別し、対応表の作成責任を決めます

• 移行方式：機械的に変換するものと人手で作り直すものを分け、作業量を見積もります

• 編集権限とワークフロー：部署・役割ごとの編集範囲と承認フローを設計します

• 複数部署の運用ルール：更新担当者の範囲、公開タイミング、表記ルールを定めます

• 多言語・多地域対応：言語ごとの出し分けと翻訳の更新フローを決めます

• 段階公開の可否：全面公開か領域ごとの公開かを決め、並行稼働期間の扱いを定めます

数千ページ規模のサイトリニューアルのご相談は、大規模サイトリニューアルまでお問い合わせください。

要件定義書とは何か

要件定義書とは、リニューアルプロジェクトで「何を実現するか」を文書化したものです。RFP（提案依頼書）が「制作会社への依頼内容」であるのに対し、要件定義書は「発注者と制作会社が合意した仕様の詳細」として機能します。

要件定義書が果たす役割は以下の通りです。

• 発注者・制作会社の認識齟齬を防ぐ

• 制作中の「言った・言わない」のトラブルを防ぐ証跡になります

• 追加要件が発生した際の基準ラインになります

• テスト・品質保証の基準として活用できます

サイトリニューアルの目的設定や全体の進め方については「サイトリニューアルの基本（目的設定から全体の流れ）」で解説しています。

要件定義書の構成

1. プロジェクト概要

記載内容

• プロジェクト名

• 目的（なぜリニューアルするのか）

• 目標KPI（定量的な成功指標）

• プロジェクト期間・公開目標日

• 予算の上限

記載例

> プロジェクト名：株式会社○○ コーポレートサイト全面リニューアル
> 目的：現行サイトのスマートフォン対応不足・SEOスコアの低下を改善し、問い合わせ数を月20件から40件に増加させる
> 目標KPI：問い合わせ数月40件（公開6ヶ月後）、PageSpeed Insightsスコア80以上
> 公開目標日：20○○年○月○日

2. 現状サイトの情報

記載内容

• 現行サイトのURL

• 制作時期・使用CMS

• 現在のアクセス数・主要指標（GA4データ）

• 現状の課題（具体的に）

3. ターゲットユーザー

記載内容

• メインターゲットの属性（業種・職種・年代・役職等）

• サブターゲットの属性

• 各ターゲットが抱える課題・ニーズ

• 各ターゲットのサイト利用目的

記載例

> メインターゲット：製造業（従業員100〜500名）の情報システム部長・IT担当者（35〜50歳）
> サイト利用目的：業務効率化ツールの比較検討・導入事例の確認
> サブターゲット：同社の経営層（最終意思決定者）

4. サイトマップ（ページ構成）

リニューアル後の全ページをリスト化します。新規ページ・継続ページ・廃止ページを区別して記載します。

5. 機能要件

必要な機能を「必須」「推奨」「将来対応」の3段階で優先度を付けて記載します。

機能要件の記載例

6. デザイン要件

記載内容

• ブランドガイドラインの有無（使用するロゴ・カラー・フォントの制約）

• デザインの方向性・トーン（モダン・クリーン・プロフェッショナル等）

• 参考にしたいサイト（2〜3件とその理由）

• 避けたいデザイン・表現

記載例

> ブランドカラー：メインカラー #2C3E50、アクセントカラー #3498DB
> デザイン方向性：シンプル・プロフェッショナル。過度なアニメーションは避ける
> 参考サイト：example.com（清潔感・情報の整理の仕方が参考になる）

7. 技術要件

記載内容

• CMS・フレームワークの希望または制約

• ホスティング環境の希望

• 連携する外部サービス（MAツール・CRM・分析ツール等）

• セキュリティ要件（SSL・WAF・バックアップ頻度等）

• パフォーマンス要件（PageSpeed Insightsスコアの目標値等）

記載例

> CMS：ヘッドレスCMSが望ましい。WordPressの場合は高速化施策を必須で実施すること
> 連携ツール：HubSpot（フォーム連携）・GA4（アクセス解析）・Google Search Console
> パフォーマンス：PageSpeed Insightsのモバイルスコア75以上を要件とします

8. コンテンツ要件

記載内容

• 各ページのコンテンツの制作担当（自社・制作会社・外注ライター等）

• 写真・動画の手配方針（既存素材の活用・新規撮影・素材購入）

• コンテンツの提供スケジュール

• 多言語対応の有無

9. スケジュール

各工程のマイルストーンと社内確認期限を明記します。

スケジュール記載例

10. 納品物のリスト

リニューアル完了時に受け取る成果物を明記します。

納品物リストの例

• 完成したWebサイト（本番環境）

• ソースコード一式（GitHubリポジトリ）

• デザインデータ（Figmaファイル）

• サイトマップ・ワイヤーフレーム（PDF）

• 運用マニュアル（CMS操作方法）

• テスト結果レポート

よくある失敗と対策

失敗1：「一式」でまとめた機能要件

「お問い合わせ機能一式」という記述では、自動返信・通知・MAツール連携が含まれるのか不明です。機能は可能な限り細分化して記述します。

失敗2：デザインの方向性が主観的すぎる

「かっこいいデザインにしてほしい」「センスの良いデザイン」という要件は解釈が難しいです。参考サイトとその理由（「○○のような清潔感が欲しい」）を合わせて記述します。

失敗3：スケジュールに社内確認時間が含まれていない

制作会社の作業期間だけを積み上げたスケジュールは、社内確認・承認の時間が考慮されていません。各マイルストーンに「クライアント確認期間（○営業日）」を明示します。

失敗4：「将来対応」の機能が設計に影響する場合に事前確認しません

「将来AIチャットボットを追加したい」という要件は、現行の設計・データ構造に影響する可能性があります。将来追加したい機能は要件定義の段階で制作会社に伝え、将来の拡張を考慮した設計になっているかを確認します。

まとめ

要件定義書は、プロジェクトの成功を左右する最重要ドキュメントです。10の構成要素を丁寧に埋めることで、制作会社との認識齟齬を防ぎ、品質の高いリニューアルを実現できます。

次の記事では、Web制作会社への提案依頼書（RFP）の書き方を解説します。要件定義書とRFPの違いと使い分けについても整理します。