Web改善仕様書の書き方

サイト分析の結果を受け取っても、制作会社や社内のエンジニアがその日のうちに着手できるとは限りません。多くの場合、資料が現状の説明で止まっており、どのファイルの何を、どう書き換えるかが一意に決まらないためです。

分析と実装をつなぐ書類が、Web改善仕様書です。1件の課題につき1枚、対象URLから完了条件と評価指標までを固定の様式で記述します。

この記事では、当社が実務で使っている14項目の様式、全項目を埋めた記入例、完了条件と検証の決め方を解説します。

この記事が扱う範囲と扱わない範囲

この記事は、分析結果を実装可能な様式へ変換する書き方だけを扱います。

扱う範囲は次のとおりです。

• 改善仕様書に入れる14項目と、各項目の書き分け
• 全項目を埋めた記入例
• 完了条件と検証時期の決め方
• 制作会社へ渡すときの前提条件

扱わない範囲は、次のページへ委ねます。

• 改善が実装されないまま止まる組織側の原因は、SEOレポートを受け取っても改善が実装されない7つの理由で扱っています。
• 当社が実際に発行しているレポートの現物は、SIGNALの無料診断レポート例で公開しています。
• 支援範囲や進め方は、Netsujo SIGNALのサービスページに記載しています。

結論：レポートと仕様書の違いは、次の行動が一意に決まるかどうか

レポートと改善仕様書を分ける基準は、分量でも図表の多さでもありません。読んだ実装担当者が、次に何をすればよいかを迷わず決められるかどうかです。

レポートは、順位、表示回数、流入、競合との差、技術的なエラーなど、現状を説明する資料です。読み手が状況を理解するところまでを担当します。

改善仕様書は、変更を実行するための資料です。対象URL、変更する箇所、変更後の文言やコード、担当、完了条件、検証手順までを含みます。

たとえば「タイトルを改善してください」は、レポートの表現です。同じ内容でも、対象URL、現在のtitle、変更後のtitle、変更理由、公開後に見る指標まで書かれていれば、仕様書の表現になります。

判断のしかた：その1項目を制作会社へそのまま転送したとき、追加の質問が発生するなら、まだ仕様書になっていません。

この判定基準は当社の運用目安であり、普遍的な正解ではありません。社内に実装チームがある場合は、前提の共有が済んでいる分だけ記述を省略できます。

改善仕様書の14項目

1件の課題につき、次の14項目を埋めます。項目を減らすと、実装者側で判断を補う必要が生まれ、依頼者の意図と異なる実装につながります。

当社が無料診断で発行しているMini ChangeSpecも、優先度、対象URL、対象サーフェス、観測事実、根本原因の分類、変更手順、完了条件、検証手順、推奨担当、想定工数、成功指標、必要な内部アクセスという、ほぼ同じ項目で構成しています。現物は無料診断レポート例で確認できます。

根本原因は分類してから書く

根本原因を自由記述だけで書くと、担当の割り当てが揺れます。当社では次の8分類を先に選び、そのうえで説明文を書いています。この分類も当社の運用目安です。

1. コンテンツ不足
2. 情報設計
3. レンダリング（初期HTMLに情報が出ていない等）
4. 構造化データ
5. 内部リンク
6. コンバージョン導線
7. 計測
8. 表記の不一致

分類が決まると、推奨担当と想定負荷がほぼ自動的に決まります。レンダリングと構造化データは開発、コンテンツ不足は編集と事業側、計測は分析と開発の混成になりやすい傾向があります。

記入例：サービスページのtitleが検索意図とずれている

14項目を実際に埋めると、次のようになります。以下は様式を説明するための架空の例であり、特定の顧客の案件ではありません。

この1枚があれば、実装者は確認事項をほぼ発生させずに着手できます。逆に、どこか1項目でも空欄があると、その項目についての質問が往復し、着手が遅れます。

症状・事実・根本原因を分けて書く理由

この3つを1文にまとめると、仕様書としては使えなくなります。書く場所を分けるのは、それぞれの読み手と用途が違うためです。

• 観測された症状は、経営層や依頼元へ「なぜ直すのか」を説明する材料です。
• 確認した事実は、実装者が現状を再現し、変更前後を比較するための材料です。
• 実装上の根本原因は、触る場所を決めるための材料です。

たとえば「titleが弱いのでクリック率が低い」という1文には、症状（クリック率が低い）、事実（titleの文言）、原因の解釈（titleが弱い）が混ざっています。この状態では、実装者はtitleを変えるべきなのか、descriptionを変えるべきなのか、そもそも別ページの問題なのかを判断できません。

分けて書くもう1つの効果は、外れたときに切り分けられることです。変更後も症状が改善しない場合、事実は正しく観測できていたのか、原因の解釈が違ったのかを分けて見直せます。1文にまとめてしまうと、施策全体を丸ごと否定するしかなくなります。

根拠の強さも書き分けます。公式資料や実測で確認した内容は事実として、複数の情報からの推測は推測として記述し、推測には確かめる手順を添えます。

完了条件の決め方

完了条件は、公開後に誰が見ても同じ判定になる状態で書きます。指標の増減を完了条件にしません。

順位、クリック数、問い合わせ件数は、自社の変更以外の要因でも動きます。これらを完了条件にすると、実装が正しく終わっているのに未完了と判定されたり、逆に実装漏れがあるのに完了と判定されたりします。

完了条件として使える書き方は、次のような形です。

• 本番URLの公開HTMLに、変更後の文言が含まれている
• 変更対象以外のページに、意図しない変化が出ていない
• スマートフォン幅で、対象要素が表示され操作できる
• 構造化データが画面の表示内容と一致している
• 計測イベントが、想定した名前とパラメータで1回だけ発火する
• 日本語版と英語版の両方で、事実の記述が一致している

完了条件を書けない場合、変更内容がまだ具体化していない可能性があります。その場合は、完了条件を先に書いてから変更内容に戻ると、記述の粒度が揃います。

公開直後の検証と28日後の評価を分ける理由

検証と評価は、確認する対象が違います。同じ欄にまとめると、どちらも中途半端になります。

公開直後の検証で確認するのは、実装の正しさです。変更が意図どおり反映されているか、他の箇所を壊していないかを、公開当日に確認します。ここで問題が見つかれば、その日のうちに戻せます。

28日後の評価で確認するのは、需要側の反応です。検索エンジンの再クロール、順位の変動、利用者の行動の変化には時間がかかるため、公開翌日の数値で判断できません。

28日という期間は当社の運用目安であり、普遍的な正解ではありません。更新頻度の低いサイトや、季節性の強い商材では、比較期間を長く取る必要があります。期間を決めたら、その期間を仕様書に書き、後から変えないようにします。

評価時に守る点が2つあります。

1. 基準値を公開前に保存します。公開後に取得した数値だけでは、変化を確認できません。
2. 同時期に実施した他の変更を併記します。複数の変更が同じ期間に走っている場合、指標の変化を1つの施策の成果として説明できません。

指標が改善しても、その変更が原因であると計測できていない限り、因果として断定しません。評価欄には、観測できた変化と、確認できていない点を分けて記録します。

制作会社へ渡すときの注意

仕様書が整っていても、権限・環境・リリース単位の3点が合っていないと着手できません。渡す前にこの3点を確認します。

権限

変更に必要な権限を、仕様書に列挙します。実務では次のような権限が必要になります。

• CMSの編集権限、およびテンプレートを編集できる権限
• リポジトリへのアクセスと、デプロイの実行権限
• タグ管理ツールの公開権限
• 解析ツールの編集権限（イベント定義の変更を伴う場合）
• ドメイン設定の変更権限（リダイレクトを伴う場合）

権限の所在が依頼元と制作会社で分かれている場合、どちらが実施するかを仕様書に書きます。当社の無料診断レポートでも、必要な内部アクセスを独立した項目として明示しています。

環境

同じ変更内容でも、実装方法はサイトの構成によって変わります。次の点を先に共有します。

• CMSかコードか、metadataがどこで生成されるか
• 初期HTMLに含まれるのか、JavaScript実行後に描画されるのか
• 多言語対応の有無と、言語間で同期が必要な範囲
• 既存の計測タグとの重複の有無
• 検証環境の有無と、確認できる範囲

環境を確認せずに変更内容だけを渡すと、実装箇所が特定できない、全ページへ反映される、CMSの更新で消えるといった問題が起こります。

リリース単位

1つの仕様書は、1つのリリースで完結する大きさにします。複数の課題を1回のリリースにまとめると、28日後の評価でどの変更が効いたかを切り分けられません。

同じ日に複数の変更を公開する場合は、公開日と変更範囲を記録し、評価時に併記します。切り分けを優先するなら、影響の大きい変更を単独で公開します。

よくある書けていないパターン

仕様書が実装につながらないとき、原因は次のどれかに当てはまることが多くあります。

項目を埋められない場合、その項目を空欄のまま渡すより、未確認であることと、確認する方法を書くほうが実装は進みます。

まとめ

改善仕様書は、分析結果を実装可能な状態へ変換するための書類です。次の14項目を1件ごとに埋めます。

1. 課題ID
2. 対象URL
3. 観測された症状
4. 確認した事実
5. 実装上の根本原因
6. 対象コンポーネントまたは設定
7. 変更内容
8. 変更理由
9. 優先度
10. 推奨担当
11. 想定負荷
12. 完了条件
13. 公開直後の検証
14. 28日後の評価指標

症状・事実・根本原因を分けて書き、完了条件は公開面で確認できる状態にし、公開直後の検証と28日後の評価を別の欄に置きます。ここまで揃うと、既存の制作会社を変更しなくても、分析結果を実装へ渡せます。

書き方だけでは判断が難しい場合は、自社サイトを対象に1件の改善仕様を作ってみると、不足している情報が具体的に分かります。SIGNALの無料診断では、公開情報をもとに、この様式で1件の改善仕様をお返ししています。