Webサイトリニューアルの要件定義書には何を盛り込むべき？目標設定から納品までを整理

ウェブサイトのリニューアル要件書には、「なぜリニューアルするのか」「どの範囲まで変更するのか」「どのように納品するのか」を、実行可能な取り決めとして明記します。文書の名称がウェブサイトリニューアル要件書であっても、フランス語の cahier des charges refonte site internet であっても、関係者が同じ資料に基づいて範囲、見積もり、スケジュール、検収結果を判断できる内容にする必要があります。作成にあたっては、まず現状の問題と目標を確認し、そのうえでページ、機能、データ移行、公開に関する責任を項目ごとに定めます。

目標と現状を明確にし、「リニューアルする」だけで終わらせない

リニューアルの目標は、有効な問い合わせの増加、多言語コンテンツの公開への対応、モバイル端末でのフォーム入力の負担軽減など、具体的な業務上の行動と結び付けます。各目標について、現状、期待する変化、測定方法を明記します。問い合わせに関する目標では、フォーム送信後の有効なリードを集計対象とすることや、テスト送信と迷惑情報を除外するルールを明確にできます。信頼できる過去のデータがない場合は、公開後に基準値を設定し、観測期間を定めることを取り決めればよく、根拠のない成長率を記載する必要はありません。

現状については、既存サイトのURL、技術構成、言語版、ページ数、主な問題を記録し、既存のサイトマップ、アクセスデータ、代表的なページのスクリーンショットを添付します。ページのアクセス数減少と問い合わせの減少は、どちらもリニューアルが必要に見えますが、原因は異なる可能性があります。前者ではインデックス登録や流入元の確認が必要で、後者ではフォーム、製品情報、フォローアップの流れも確認する必要があります。確認済みの問題と調査が必要な事項を分け、提供側が仮説を確定済みの要件として扱わないようにします。

範囲を定める：ページ、コンテンツ、機能をそれぞれ明記する

ページ一覧には、トップページ、製品カテゴリー、製品詳細、会社概要、お問い合わせページなどを記載し、それぞれを維持、再制作、統合、削除のいずれとするかを示します。製品数の多いサイトでは、共通テンプレートを使用するページと個別にデザインするページを明記します。また、移行予定のコンテンツの種類と数量、画像や原稿をどちらの当事者が準備するかも記載します。コンテンツがまだそろっていない場合は、提供時期と、遅れた場合のスケジュール調整方法を定めます。

機能要件は、「問い合わせ機能を追加する」とだけ書くのではなく、作動条件と期待する結果を記述します。たとえば、訪問者が製品について問い合わせを送信すると、指定されたメールアドレスに通知が送られ、管理画面に送信記録が保存され、ページに成功または失敗の状態が表示される、といった内容です。必須項目、添付ファイルの制限、迷惑情報の処理方法、通知先も確認する必要があります。顧客管理システムと連携する場合は、連携方法、フィールドのマッピング、テスト環境、インターフェースの保守責任も明記します。

多言語サイトのリニューアルでは、対象言語、対象となるページの範囲、翻訳の提供元をそれぞれ明記します。機械翻訳は初稿として利用できますが、製品仕様、業界用語、連絡先情報は人手で校正する必要があります。各言語で製品データベースを共有するか、コンテンツを個別に編集できるかについても、管理画面の権限要件に記載します。こうした点が明確でないと、デザインが完成した後にコンテンツの管理方法をめぐって手戻りが発生する可能性があります。

建設に SaaS 型のウェブサイト構築サービスを利用する場合は、テンプレートの調整可能範囲、コンテンツのエクスポート方法、アカウント権限、契約終了後のデータの取り扱いも要件書に記載します。たとえば、易營宝SaaSスマートサイト構築・マーケティングシステムを評価する際は、多言語編集、モバイル対応、管理画面の要件を項目ごとに照合できます。具体的な納品範囲は、プロジェクトの取り決めに従います。

検索流入の移行とマーケティングデータを納品範囲に含める

ウェブサイトのリニューアルでは、URLが変更されることがあります。要件書では、旧URLと新URLの対応表を作成し、維持、統合、削除のルールを明確にするとともに、該当する場合は恒久的なリダイレクトを設定するよう求めます。明確な移行先がある旧ページをすべてトップページに転送するのは適切ではありません。代替コンテンツがない場合は、個別に処理方法を定めます。公開前には、ページタイトル、ディスクリプション、サイトマップ、正規URL、検索エンジンのクロール設定も確認し、テスト環境の制限が本番サイトに持ち越されないようにします。

既存のアクセス解析ツール、広告のコンバージョンコード、検索プラットフォームのサイト認証情報も移行リストに含めます。フォーム送信の成功や電話番号のクリックなどのイベントについて、発生条件と検収方法を記載し、テストデータと本番データを区別します。旧サイトに完全なイベント計測記録がない場合は、まず既存アカウントの管理権限を確認してから調査を手配します。ページの見た目だけでは、コンバージョン計測が正常に動作しているか判断できません。

パフォーマンス要件についても、テスト対象のページ、デバイスの種類、ネットワーク環境、使用するツール、許容できる結果を明記します。トップページの読み込み速度だけでは、製品詳細ページや多言語ページの表示状況を判断できません。画像や動画を多く含むページは、個別に抽出してテストする必要があります。世界各地からのアクセスを想定する場合は、テスト地域とテスト時間も定め、1回のテスト結果だけで全体的な使用感を判断しないようにします。

スケジュール、変更、検収を具体的な成果物に結び付ける

スケジュールは、要件の確定、ページデザイン、開発とコンテンツ移行、テスト、公開など、確認可能な成果物ごとに段階を分けます。各工程の成果物、確認担当者、フィードバック期限を明記します。デザイン案の確定後にページの追加や機能ロジックの変更があった場合は、変更内容を記録し、工期と費用を再評価します。口頭での修正依頼が積み重なるのを防ぐためです。

検収基準は、実際の操作で確認できる内容にします。指定のブラウザーやモバイル端末でページのレイアウトを確認する、テスト用メールアドレスからフォームを送信して管理画面の記録を照合する、移行ページやリダイレクトの結果を抜き取り確認する、といった方法を定められます。不具合は影響範囲に応じて記録します。問い合わせを妨げる、またはページにアクセスできなくなる問題と、文字間隔などの表示上の問題は分けて扱い、修正後の再テスト方法も明記します。検収範囲には、主言語のトップページだけでなく、合意したすべての言語版を含めます。

正式サイトに加え、納品物にはドメインや関連アカウントの権限、管理画面の操作資料、ページおよび機能の一覧、リダイレクト表、テスト記録、必要な設定資料も含めます。サードパーティーのシステムを利用する場合は、ソースコードやデータの実際の納品範囲を取り決め、提供できないものを当然の納品物として記載しないようにします。

ロールバックできる状態まで公開計画を定める

公開前に、ドメインのDNS設定、証明書、バックアップ、公開時間帯を確認し、各工程の実施責任者と確認担当者を指定します。旧サイトのバックアップについては、保存場所、復元方法、利用可能性の確認方法を明確にします。公開後にフォームが機能しない、または重要なページにアクセスできない場合に備え、公開の一時停止、修正、ロールバックを行う条件と連絡先を定めます。

公開後には確認期間を設け、主要ページへのアクセス、問い合わせ通知、検索エンジンのクロール、コンバージョンイベントを確認します。保守条件では、納品時の不具合修正と、その後の追加要件を区別し、問い合わせ窓口、対応手順、期限を明記します。要件書は双方の確認後にバージョンを記録し、その後の変更は更新版の取り決めに基づいて行います。