はじめに
目的
本書は、Webサイト制作における「仕様書」について、定義から作成方法、注意点、作成後の流れまでをまとめた案内です。制作関係者が共通認識を持ち、スムーズに進行できるようにすることを目的とします。
対象読者
発注者（クライアント）、プロジェクトマネージャー、デザイナー、エンジニア、制作に関わる全ての方を想定しています。技術に詳しくない方でも読みやすい内容にしています。
本書の使い方
各章で必要な項目や手順を順を追って説明します。実際の案件では本書の各項目をチェックリストとして利用してください。具体例を交え、実務で使える形にしています。
仕様書の役割
仕様書は作業範囲、成果物、スケジュール、責任範囲を明確にします。これにより認識違いを減らし、無駄な手戻りを抑えます。例えば、ページ数や機能を明記することで見積りと実装のずれを防ぎます。
この先の構成
第2章以降で、仕様書の具体的な内容、作成手順、注意点、作成後の流れを順に説明します。まずは全体像をつかんでください。
Webサイト仕様書とは
概要
Webサイト仕様書は、制作するサイトの構造や見た目、動き、納期などを具体的にまとめた文書です。サイトマップやワイヤーフレーム、デザインイメージ、機能一覧、スケジュールが含まれます。要件定義書が「何を作るか」を示すのに対し、仕様書は「どのように作るか」を明確にします。
主な構成要素（例）
- サイトマップ：ページの構成と階層を図示します。
- ワイヤーフレーム：各ページのレイアウト骨子を示します。
- デザインイメージ：色やフォント、参考ビジュアルを載せます。
- 機能仕様：ログインや問い合わせフォーム、検索などの動きを具体化します。
- スケジュール・工数：納期と作業分担を示します。
目的と効果
仕様書は発注者と制作側の共通認識をつくります。要件のあいまいさを減らし、手戻りを抑えます。見積りの精度も上がり、納期管理がしやすくなります。
誰が使うか
発注者、プロジェクトマネージャー、デザイナー、エンジニア、テスターなど関係者全員が参照します。
記載レベルの目安
短めの仕様書は概略を共有する時向きです。詳細な仕様書は実装やテストまで想定する場合に必要です。目的に合わせて粒度を決めてください。
注意点
曖昧な表現は避け、図や例を用いて具体化してください。変更履歴を残すと後の確認が楽になります。
仕様書作成の重要性
なぜ仕様書が必要か
ホームページ制作を依頼する際、仕様書は発注側の意図を明確に伝えるための最も有効な手段です。目的や必要な機能、優先順位を前もって示すことで、制作会社との認識ズレを防げます。結果として手戻りや追加費用を減らし、スケジュール通りに進めやすくなります。
仕様書の役割と流れ
発注者が全体像や希望を記載し、制作会社はそれを基に機能面を詰める要件定義書を作成します。発注段階で完璧を求める必要はありません。まず現状の要望を可能な範囲で書き出し、制作会社がヒアリングで詳細を補完する流れが一般的です。
実務でのポイント（具体例）
- 目的：問い合わせ数を増やしたい、ブランド認知を高めたい等
- 優先機能：お問い合わせフォーム、スマホ対応、CMS導入など
- 参考例：競合サイトのURLや既存サイトの改善点を記載
- 制約：予算、納期、対応ブラウザなど
これらを丁寧に書くことで、制作の質と効率が高まります。
仕様書に記載すべき項目
概要（プロジェクト全体）
- 目的：サイトで達成したいことを一文で書きます（例：資料請求の増加、ブランド認知向上）。
- ターゲット：年齢層・職業・利用シーンを具体的に示します。
- 課題：現状の問題点を箇条書きにします。
- 予算・納期：予算の目安と最終納品日を明確にします。
- 背景・ゴール・コンセプト：背景説明と目標、サイトの軸となるコンセプトを記載します。
- キーワード・コンバージョン目標値・公開日：SEOの基礎キーワードとCV目標、公開予定日を入れます。
構造・デザイン・機能
- サイトマップ：ページ構成と階層を図で示します。
- ワイヤーフレーム：主要ページのレイアウトを簡潔に作ります。
- デザインイメージ：色味、トーン、参考サイトの例を示します。
- 機能詳細：お問い合わせ、検索、会員機能などの要件を項目ごとに書きます（優先度や非対応ブラウザも明記）。
- 技術要件：CMS、対応言語、外部連携（API）やセキュリティ要件を具体的に記します。
運用・保守・その他
- レスポンシブ対応／ブラウザ対応：必須の対応範囲を明確にします。
- サーバー・ドメイン管理：ホスティング、SSL、バックアップの責任範囲を決めます。
- コンテンツ準備：テキスト、画像、動画の納品フォーマットと担当を示します。
- 支払方法・スケジュール：支払条件、検収期限を記載します。
- その他：SEO対策、アクセス解析、権限管理、想定リスクと連絡体制も忘れずに。
ホームページリニューアル時の仕様書作成ステップ
以下はリニューアル仕様書を作るための9ステップです。各ステップで何を決め、どのように書くかを具体例で示します。
1. 目的の明確化
何のためにリニューアルするかを書きます。例：問い合わせ数を2倍にする、ブランドイメージを刷新するなど。KPI（数値目標）を必ず記載します。
2. 現状課題の整理
現サイトの問題点を箇条書きにします。例：離脱率が高い、スマホ表示が崩れる、更新が手間など。現状データ（アクセス数、直帰率）も添えます。
3. ターゲット設定
主な利用者像を具体的に書きます。年齢層、職業、利用シーン、期待する行動（購入、資料請求）を明記します。
4. ページ構成とサイトマップ作成
主要ページをリスト化し、階層構造を図示します。例：TOP、サービス、料金、事例、採用、問合せ。
5. 必要機能の洗い出し
検索、会員機能、フォーム、CMS連携など必要な機能を機能ごとに要件（例：入力項目、必須バリデーション）と合わせて書きます。
6. デザイン要件まとめ
トーン＆マナー、カラー、フォント、参考サイトを列挙します。レスポンシブ優先やアクセシビリティ対応の有無も記載します。
7. スケジュールとマイルストーン設定
企画、デザイン、開発、テスト、公開の期日を作り、重要な納期（マイルストーン）を明示します。
8. 予算とリソース明確化
総予算、外注範囲、社内担当者、レビュー体制を決めます。見積もり前提の条件も書きます。
9. 運用計画記載
公開後の更新頻度、担当者、保守費用、効果測定方法（KPIの追跡方法）を記載します。
各項目を具体的に書けば、認識齟齬を防げます。仕様書はチームの共通のものさしになります。
仕様書作成時の注意点
技術的対応の確認
スマホ・タブレットや主要ブラウザでの動作を明記します。例：iOS/Androidの最新2世代、Chrome/Edge/Firefox/Safariで表示確認。レスポンシブ対応の有無、画面幅ごとのデザイン基準、JavaScript無効時の代替表示も記載するとトラブルを避けられます。
契約・支払いに関する項目
支払い方法（銀行振込・カード・分割）と時期を明確にします。成果物ごとの検収基準と支払条件、追加作業の料金ルールやキャンセル時の取り扱いも契約に盛り込みます。納期遅延や仕様変更時の対応も決めておくと安心です。
コンテンツ・素材の準備
原稿、写真、ロゴなどの納品形式と締切を指定します。画像は推奨解像度やファイル形式（例：PNG/JPEG/原図）を明示し、著作権や使用許諾の確認方法も書きます。クライアント側で用意するものと制作側で用意するものを分けておくと混乱を防げます。
公開・運用に関する確認
公開担当者、ドメイン・サーバーの権限、バックアップ・復旧手順、運用保守の範囲と料金を明確にします。更新頻度や緊急対応の窓口、ログイン情報の管理方法も記載すると現場の混乱を減らせます。
運用に向けた実務的な注意
ステージング環境での動作確認、テスト項目、受け入れテストの合格基準を決めます。変更履歴とバージョン管理のルールを定め、仕様書は更新時に版数と改訂日を残しておくと後で証拠になります。
最後に
不明点は早めに洗い出し、書面で合意を取ることが重要です。細かな点を先に決めておくことで、制作がスムーズに進みます。
仕様書作成後の流れ
1. 初回打ち合わせとすり合わせ
制作会社と仕様書を丁寧に読み合わせます。疑問点を洗い出し、優先度を決め、連絡窓口と決裁者を明確にします。ここで大まかなスケジュール案と見積もり方針が提示されます。
2. 詳細要件定義
仕様書をもとに画面ごとの詳細や機能の動き、非機能要件（対応環境や性能、セキュリティ）を詰めます。承認フローや変更管理のルールも決めます。
3. 制作計画と契約
マイルストーン、納期、成果物一覧、テスト基準を含む制作計画を作成し、見積もりと契約を確定します。修正回数や追加費用の扱いを明文化しておくと安心です。
4. デザインとプロトタイプ
ワイヤーやデザイン案を作成して確認します。プロトタイプで操作感を確かめ、フィードバックを反映します。レビューのタイミングと回数を合意しておきます。
5. 開発・中間確認
開発を進める間に定期的な進捗報告や中間確認を行います。ステージング環境で動作確認を行い、仕様とずれがないかチェックします。
6. テストと検収
機能テスト、動作検証、ブラウザ確認を行います。バグ修正と再テストを経て、検収基準に基づいて最終承認を行います。
7. 公開・引き渡しと運用
本番公開作業、DNS設定、データ移行を行い、運用マニュアルと管理者アカウントを引き渡します。保守契約や定期的な改善提案の体制を整えます。
ワンポイント
仕様書は完成後も更新される「生きた文書」です。変更履歴や検収基準を明確にし、連絡窓口を一本化するとトラブルを減らせます。
