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

はじめに

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

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

要件定義書とは何か

要件定義書とは、リニューアルプロジェクトで「何を実現するか」を文書化したものです。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の違いと使い分けについても整理します。