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

元のページ: <https://chot-inc.com/knowledge/site-renewal-requirements>

サイトリニューアル完全ガイド（大規模サイト対応）

サイトリニューアルの要件定義で整理すべき項目（目的・ターゲット・機能要件・非機能要件・移行・SEO）を一覧で解説。社内で決めることと制作会社に任せることの切り分け、要件定義書の構成とテンプレート、大規模サイトで追加になる項目をまとめています。

## **はじめに**

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

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

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

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

| 項目 | 決める内容 | 誰が決めるか | 関連記事 |
| - | - | - | - |
| 目的・KPI | 解決する課題と達成を判断する指標 | 発注側の決裁者 | [サイトリニューアルとは？](https://chot-inc.com/knowledge/site-renewal-basics) |
| ターゲット | 届けたい相手とその相手の目的 | 発注側の事業部門 | 目的別アプローチ |
| サイト構成 | ページ一覧と新規・継続・廃止の区分 | 発注側と制作会社で協議 | [リニューアルの進め方](https://chot-inc.com/knowledge/site-renewal-process) |
| 機能要件 | 必要な機能と優先度（必須・推奨・将来対応） | 発注側が起案し制作会社が判断 | [リニューアルのCMS選定](https://chot-inc.com/knowledge/cms-selection-for-renewal) |
| 非機能要件 | 表示速度・アクセシビリティ・セキュリティの水準 | 制作会社が提案し発注側が承認 | モダンWeb開発支援 |
| 移行・SEO要件 | 移行対象・URLの扱い・リダイレクト方針 | 制作会社が提案し発注側が承認 | [リニューアル時のSEO対策](https://chot-inc.com/knowledge/site-renewal-seo) |
| 体制・スケジュール | 社内の確認担当者・承認フロー・各工程の期限 | 発注側の決裁者 | [RFPの書き方](https://chot-inc.com/knowledge/rfp-for-web-renewal) |
| 予算 | 投資の上限と分割する場合の区切り | 発注側の決裁者 | [リニューアルの費用相場](https://chot-inc.com/knowledge/site-renewal-cost) |

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

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

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

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

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

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

提案依頼書の具体的な書き方については、[RFP（提案依頼書）の書き方｜Web制作会社への依頼を成功させる](https://chot-inc.com/knowledge/rfp-for-web-renewal)で詳しく解説しています。

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

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

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

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

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

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

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

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

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

数千ページ規模のサイトリニューアルのご相談は、[大規模サイトリニューアル](https://chot-inc.com/services/large-scale-site-renewal)までお問い合わせください。

## **要件定義書とは何か**

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

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

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

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

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

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

サイトリニューアルの目的設定や全体の進め方については「[**サイトリニューアルの基本（目的設定から全体の流れ）**](https://chot-inc.com/knowledge/site-renewal-basics)」で解説しています。

## **要件定義書の構成**

### **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段階で優先度を付けて記載します。

#### 機能要件の記載例

| **機能** | **優先度** | **詳細仕様** |
| - | - | - |
| お問い合わせフォーム | 必須 | 項目：会社名・氏名・メール・電話・お問い合わせ内容。自動返信メール・担当者への通知メール必須 |
| ニュース管理（CMS） | 必須 | 非エンジニアが更新可能。カテゴリ・タグ機能。公開予約機能 |
| 導入事例管理（CMS） | 必須 | 業種・課題・規模でフィルタリング可能 |
| HubSpot連携 | 推奨 | フォーム送信時にHubSpotへリード情報を送信 |
| AIチャットボット | 将来対応 | 第2フェーズで実装予定 |

### **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の違いと使い分けについても整理します。

## よくあるご質問

目的・ターゲット・予算・体制は発注側が決め、技術構成や非機能要件は制作会社が提案して発注側が承認する分担が一般的です。発注側だけで書き切ると実現性の判断が難しく、制作会社に任せきりにすると事業上の狙いが反映されません。要件定義を支援する契約を分けて結ぶ方法もあります。

期間は規模により異なります。目安になるのはページ数ではなく、関係する部署の数と承認の段数です。決裁者と各部署の合意が取れるまでを要件定義の期間と考え、社内確認の時間をスケジュールに明示すると後工程の遅延を防げます。

合意内容の基準が存在しないため、途中で仕様の解釈が分かれ、追加作業が発生したときに費用と期間の根拠を示せなくなります。テストの合格基準も定まらず、公開直前に想定との違いが指摘されて手戻りになりがちです。

## エージェント型Web・AIアプリ 開発のご相談

chot inc.ではエージェント型Webの設計・構築・ 運用を 一貫してサポートしています。

[お問い合わせ](https://chot-inc.com/contact)

## このテーマの他の記事

- ### [サイトリニューアルとは？目的の設定から考える全体の流れ](https://chot-inc.com/knowledge/site-renewal-basics)
  [サイトリニューアルの定義・目的の設定方法・全体の流れを体系的に解説。リニューアルの7つのフェーズと成功のための3つの前提条件を紹介します。](https://chot-inc.com/knowledge/site-renewal-basics)
- ### [サイトリニューアルが必要なサインとは？チェックリスト10項目](https://chot-inc.com/knowledge/site-renewal-checklist)
  [サイトリニューアルが必要なサインをチェックリスト10項目で解説します。表示速度・デザイン・SEO・CVRなど、今すぐ確認すべき指標を整理しています。](https://chot-inc.com/knowledge/site-renewal-checklist)
- ### [コーポレートサイトリニューアルの目的別アプローチ｜SEO・採用・ブランド](https://chot-inc.com/knowledge/corporate-site-renewal-purpose)
  [コーポレートサイトリニューアルをSEO強化・採用ブランディング・ブランド刷新の目的別に解説します。目的に合った進め方と設計のポイントをまとめています。](https://chot-inc.com/knowledge/corporate-site-renewal-purpose)

[サイトリニューアル完全ガイド（大規模サイト対応）一覧](https://chot-inc.com/knowledge/themes/site-renewal)
