はじめに
本調査の目的
本調査は、Web制作における要件定義書の基本概念、作成方法、必要項目、作成環境、制作工程での活用、そしてRFPや制作会社選定といった前提事項を一つにまとめることを目的としています。要件定義書はプロジェクトの出発点であり、目的や機能要件を明確にして関係者の合意を得るための重要な文書です。
想定読者
この資料は、発注者（企業や担当者）、プロジェクトマネージャー、デザイナー、開発者、そして制作に関わるすべての関係者を想定しています。要件定義の経験が浅い方でも理解できるよう、専門用語は最小限にし具体例を交えて説明します。
本書の使い方
各章は段階的に読めるように構成しました。まず本章で全体像をつかみ、第2章以降で基本概念や実務フロー、具体的な書き方やフォーマットを順に学んでください。小規模な案件と大規模な案件で必要な項目や深さは異なるため、目次やテンプレートをプロジェクトに合わせて調整してください。
本章の位置づけ
本章は本資料の案内役です。以降の章で具体的な手順や実例、テンプレートを示しますので、本章で目的と読み方を確認してから読み進めてください。
要件定義書の基本概念と重要性
基本概念
要件定義書は、Web制作の出発点となる設計図です。クライアントのビジネス目標、ターゲットユーザーのニーズ、サイトで実現したいことを言語化します。目的や範囲、必要な機能、優先順位を整理する役割を果たします。
要件定義書が果たす役割
- 共通認識の形成：発注者、制作チーム、運用担当者が同じゴールを持てます。
- 進行管理の基準：スコープや納期、優先度を明確にし、手戻りを減らします。
- 品質と運用性の担保：非機能要件（速度、セキュリティ、保守性）を早期に決められます。
含めるべき主な項目（具体例付き）
- 目的・目標：売上向上、問い合わせ増加など。具体的な数値目標があると良いです。
- ターゲット：年齢層や利用状況。例：30〜45歳の働く女性、スマホ中心利用。
- 主要機能：商品一覧、検索、決済、会員登録など。
- 非機能要件：表示速度、対応ブラウザ、運用工数。
- 制約・前提：予算、既存システム、法的要件。
- 成功指標（KPI）：コンバージョン率、離脱率。測定方法も書きます。
- リスクと対応策：スケジュール遅延、外部API停止など。
作成のポイント
関係者の合意を得ながら、具体例や画面イメージを交えて書きます。要件は変更履歴を残し、制作中も定期的に見直してください。
Web制作における要件定義の流れ
要件定義は5つのステップで進めます。ここでは各ステップの目的と実務上の注意点を具体例を交えて説明します。
1. ヒアリング・現状分析
クライアントからビジネス目標、ターゲット、現在の数値（訪問者数、コンバージョン率）を聞き取ります。例えば「ECサイトで売上を月間10%増やしたい」なら、現在の購入導線や決済の状況を確認します。技術的制約（既存CMSやAPI）も早めに把握します。
2. 課題整理
ヒアリングで出た情報をもとに、解決すべき課題を洗い出します。課題は優先度をつけて整理します。例：離脱が多ければ「購入フォームの項目削減」を優先、次に「ページ表示速度改善」を検討します。
3. 仮説立案
課題ごとに改善案を立て、効果と工数を見積もります。簡単な例はA/Bテスト案です。フォーム短縮でCVRが上がると予想するなら、具体的に何を減らすかを決め、期待値を数値で示します。
4. 合意形成
要求事項を機能単位に分け、関係者間で合意します。受入基準（例：主要ブラウザでの表示崩れなし、スマホ表示は3秒以内にロード）を明確にします。責任者と期限もここで決めます。
5. 要件定義書の作成
決まった内容を文書化します。目的、範囲、要件、優先度、スケジュール、KPI、ワイヤーフレームや画面イメージを含めます。バージョン管理し、変更履歴を残すと後工程がスムーズになります。
以上が実務でよく使う流れです。各ステップで成果物を用意し、次の工程へ確実に引き継ぐことが成功の鍵です。
要件定義書に盛り込むべき項目
以下は5W1Hを軸に整理した、要件定義書に必ず含めるべき項目です。初心者にも分かりやすく具体例を交えて説明します。
Why（目的・背景・課題）
・事業目的：なぜこのWebを作るのか。例：問い合わせ増加、ブランド認知向上
・現状の課題：現サイトの問題点や改善ポイントを明記します。
When（スケジュール）
・主要マイルストーン：要件確定日、デザイン完了、開発開始、公開日
・納期に関する制約やリリース優先度を示します。
Who（ターゲット・体制）
・想定ユーザー像：年齢層、利用シーン、頻度の例
・プロジェクト体制：発注者側、制作側の役割と連絡窓口
What（納品物・コンテンツ）
・納品物リスト：デザインPSD/FIGMA、HTML/CSS、CMS導入、マニュアル
・コンテンツ範囲：ページ一覧、文章・画像の提供範囲
Where（インフラ・サーバー要件）
・ホスティング形態：自社サーバー、クラウド、レンタル
・ドメイン、SSL、バックアップ方針などを明示します。
How（技術仕様）
・対応ブラウザ・デバイス、CMS指定、API連携、使用する技術スタック
・セキュリティ要件：認証、アクセス制御、脆弱性対策の要件
一般的な項目（具体例）
・機能要件：会員登録、検索、決済、問合せフォームの仕様
・非機能要件：表示速度、稼働率、可用性、運用負荷
・デザイン要件：ブランドカラー、トーン、ボタン配置の指針
・KPI・目標値：月間UU、コンバージョン率など
・予算：概算費用と支払条件
これらを箇条書きで明確にしておくと、誤解を減らし制作が円滑に進みます。必要に応じて付録としてページごとの詳細仕様やワイヤーを添付してください。
要件定義書の作成方法と書き方
前提と役割
要件定義書は主に制作会社が作成し、最終確認は制作会社と依頼会社で共同で行います。作成者は関係者が分かるように連絡先と責任範囲を明記してください。
作成前の準備
目的、対象ユーザー、スコープ（含む／含まない）、納期、予算を整理します。関係者ヒアリングと既存資料の収集を必ず行います。
目次と階層化の作り方
一目で全体が分かる目次を作り、項目は階層化します。大見出し→中見出し→小見出しの順で番号を振ると参照しやすくなります。
用語と前提の明記
専門用語には短い説明を付け、前提条件や制約は箇条書きで示します。例：対応ブラウザ（Chrome/Edge/Firefox）や想定アクセス数。
粒度と数値化
機能はテスト可能な粒度で書き、数値で示します（例：ページ読み込み3秒以内、月間PV10万）。曖昧な表現は避けます。
書き方の実践ルール
・各項目を見出しで区切り、要点を箇条書きで記載します。
・責任者、承認者、受け入れ基準を明記します。
改訂と共有
バージョン管理（例：v1.0→v1.1）と変更履歴を残し、関係者へ定期的に共有します。
レビュー時のチェックリスト
内容の網羅性、再現性（実装／テストできるか）、数値目標の妥当性を確認してください。
要件定義書のフォーマットと作成環境
概要
要件定義書に決まった形式はありません。Word、Excel、PowerPointなどを用途に応じて使い分けます。プロジェクト規模や関係者に合わせて項目や粒度を調整します。
フォーマット別の使い分け（具体例）
- Word: 説明文や背景、非機能要件など文章で残すときに有効です。例）目的、想定ユーザー、詳細仕様。
- Excel: 要件一覧やテストケース、優先度管理に便利です。例）列にID、項目、要件、優先度、担当者を並べる。
- PowerPoint: 経営層やクライアント向けの要約資料を作るときに使います。重要ポイントをビジュアルに示せます。
テンプレートと粒度の設計
テンプレートは必ずしも全項目を埋める必要はありません。機能ごとに「概要」「詳細」「受け入れ基準」を置くと実務で使いやすいです。粒度は開発チームが見積もりや実装に困らないレベルに合わせます。例）画面レベルか機能レベルかは規模で決めます。
共同編集とバージョン管理
クラウド（Google Workspace、Office365、Confluence）での共同編集が効率的です。履歴やコメント機能を活用し、変更内容は必ず差分として残します。ファイル名に日付と版数を入れ、承認者を記録してください。
納品形式と保管
最終版はPDFで固定し、編集用はクラウドで管理します。長期保管はアクセス権を整理してから行い、検索しやすいフォルダ構成を作ると便利です。
実務での注意点（小さなコツ）
- 要件は追記と改定が発生します。更新ルールを最初に決めておきます。
- 重要項目は一ページ目に要約を置き、関係者の理解を促します。
- ExcelのIDとWordの見出しを紐づけると参照が楽になります。
制作工程での要件定義書の活用
はじめに
要件定義書は制作の設計図です。各工程で再確認し、要件を満たしているかを判断しながら進めます。ここでは段階ごとの具体的な使い方と実践的なチェックポイントを説明します。
ワイヤーフレーム段階
要件定義の画面仕様や優先順位を参照して、情報設計と導線を決めます。必須要素（CTA、フォーム、ナビ等）が抜けていないかをチェックリストで確認します。クライアントへの説明資料も要件書を元に作成します。
デザインカンプ段階
ビジュアルが要件のブランドやアクセシビリティ基準を満たしているか確認します。色、フォント、サイズ、画像の比率など要件に照らして不一致があればデザイン指示で差分を明示します。
コーディング（HTML/CSS）段階
マークアップで要件のDOM構造やレスポンシブ動作、SEO要件を満たすか確認します。スタイルガイドやクラス命名も要件に合わせて統一します。小さな逸脱も開発ログに残します。
機能実装（JavaScript）段階
要件のインタラクションや動作条件、性能要件をテストケース化して実装と検証を行います。想定外の挙動は要件に戻して仕様変更の可否を判断します。
承認とQA
受け入れ基準（完成イメージ、性能、動作条件）を要件定義書に明記し、承認ポイントを設定します。QAは要件ベースのチェックリストを使い、合格基準を満たしたらサインオフします。
変更管理と運用
要件変更は変更履歴と影響範囲を明記して管理します。小さな修正でも都度更新し、関係者に共有します。トレーサビリティ（要件→設計→実装）を維持すると後工程の手戻りを減らせます。
実践的なチェックリスト例
- 必須要素の有無確認
- レスポンシブでの表示崩れ確認
- アクセシビリティ基準チェック
- パフォーマンステストの項目
- 承認者と承認日
定期的に要件定義書を参照し、記録を残す運用を徹底してください。これがスムーズな制作進行の鍵になります。
要件定義の前提：RFPと制作会社選定
概要
一般的にはRFP（提案依頼書）作成 → 制作会社の選定 → 要件定義 → 要件定義書の作成、の順で進めます。RFPは良い提案を引き出すための道具であり、要件定義の土台になります。
RFPの目的と役割
目的は候補企業にプロジェクトの全体像を伝え、比較可能な提案を得ることです。例えば「会員向けのマイページを作る」「既存CMSと連携する」など、背景と期待を明確に書きます。
RFPに含める主な項目（例）
- プロジェクト概要と目的
- 想定ユーザーと利用シナリオ
- 必要機能の大枠（優先度を付ける）
- 予算感と納期
- 評価基準（技術、実績、コミュニケーション）
- 提出形式と期限、質問受付窓口
制作会社選定の流れと評価ポイント
- 書類審査でポートフォリオ・業種経験を確認
- ヒアリングで担当者の相性や提案の深さを評価
- 最終提案で見積とスケジュールを比較
評価では「同規模案件の実績」「技術力」「対応の速さ」「責任者の明確さ」を重視します。
良い提案を引き出すコツ
- 要件は細かく書き過ぎず、優先度を示す
- 評価基準を明確に公開する
- 質問期間を設けて公平に対応する
RFPから要件定義へ移る際のポイント
選定後は初期ワークショップで想定ユーザーや業務フローを一緒に掘り下げます。RFPで示した優先度を基に要件を詳細化し、実装の可否やコストを確定していきます。
