Webサイト改善の優先順位を決めるバックログの作り方と記入例

Webサイトの改善は、利用者に支障が出ている問題への対応を優先します。原因が分からない変化は調査へ分け、変更の根拠がある案同士で事業への影響を比べます。実施できる担当や公開条件も、着手順を左右します。

改善バックログには、候補名と順位だけでなく、その判断の根拠を残します。「サービスページを直す」だけでは、何をよくしたいのか分かりません。「対応条件が伝わらず、対象外の相談が届いている」と分かれば、説明の修正を別の改善案と比較できます。後から条件が変わったときも、順位を見直す理由が明確になります。

障害は改善候補とは別の手順で扱う

最初に分けたいのは、比較会議まで待つことで影響が広がる問題です。問い合わせを完了できない、主要なページを表示できない、重要な提供条件を誤って掲載しているといった状態が当てはまります。

こうした問題は、ほかの改善候補と点数を比べません。影響の範囲と緊急性を判断できる担当へ渡します。バックログへ残す場合も、順位待ちの候補ではなく、対応記録への参照として扱います。

どこからを緊急対応とするかは、サイトの役割によって変わります。見た目の違いをすべて障害にする必要はありません。利用者が目的を完了できるか、誤った判断をするおそれがあるかを基準にします。検知した問題を定例日まで待たせない考え方は、Webサイト運用スケジュールの確認表でも詳しく説明しています。

原因が分からない気づきは調査項目として扱う

変化を見つけたことと、直す場所が分かったことは別です。「検索流入が減った」「問い合わせの内容が変わった」「この説明は分かりにくい気がする」という段階では、改善作業を決める根拠が足りません。

自然検索の減少には、技術的な問題やセキュリティ上の問題が関わる場合があります。検索需要の変化やサイト移行が影響することもあります。Googleの検索トラフィック減少を調べる手引きでも、複数の原因候補を分けて確認する流れが示されています。

Search ConsoleとGoogle Analyticsの数字が違うだけで、どちらかの設定が壊れているとも決められません。Search ConsoleはGoogle検索結果での表示とクリックを中心に見ます。Google Analyticsはサイトへ来た後の行動を見ます。観測する範囲や集計方法の違いは、Googleの二つのデータを併用する説明で確認できます。

直近の数値には、処理中のデータが含まれることもあります。Search Consoleの暫定値は後から変わり、Google Analyticsも処理中はレポート値が更新されます。比較期間と対象範囲をそろえ、集計が途中ではないかを確かめることで、実際の変化とデータの見え方の違いを区別しやすくなります。

調査は、原因を完全に証明できるまで続けるものでもありません。対象ページや影響範囲が分かり、試す変更を根拠とともに説明できれば、検証として着手する判断もあります。反対に、どのページで何が起きたのか分からない段階では、広い範囲を書き換えても結果を解釈しにくくなります。その場合は実装案を増やすより、変化が起きた範囲の特定を先にします。

改善候補は根拠と事業への影響から比べる

改善候補として比べられるのは、対象のページや導線が分かり、何をよくしたいのかと変更の根拠を説明できる案です。読者が迷う説明の修正も、既存顧客が必要な情報へたどり着きやすくする変更も含まれます。

最初に見るのは根拠です。Search Consoleやアクセス解析の数値だけに限りません。問い合わせ記録、営業で繰り返している説明、公開時の検査結果も使えます。誰かの印象だけでなく、別の担当者が確認できる記録へ戻れるかを確かめます。

次に、その問題が事業へどう影響するかを書きます。問い合わせ数だけでなく、商談前の判断や既存顧客の利用に関わることもあります。不要な広告費や対応工数が生じている場合も、影響の経路を説明できます。ただし、記録がない金額や成果を作って大きく見せる必要はありません。

効果の見込みと実施できる条件を分ける

事業への影響が大きそうな案でも、掲載する契約条件が確定していなければ、その説明は公開できません。優先度が低いのではなく、着手に必要な条件がそろっていない状態です。バックログに不足している前提を残すと、何が決まれば進められるかが分かります。

反対に、短時間で終わることだけを理由に、根拠の弱い案を先にしても目的には近づきません。期待する影響が同程度なら、必要な作業量や公開リスクが着手順を決める材料になります。大きな改修でも段階を分けられるなら、準備ができている範囲から始める方法があります。

根拠の確かさと事業への影響を、そのまま同じ点数へ換算することはできません。点数を使う場合も、推測を高い得点で補っていないかが問題になります。この記事では、確認できた事実と期待する変化を分けて記録し、実施条件まで含めて比較する方法を使います。これはGoogleが定めた優先順位手法ではありません。

二つの改善案を比較した記入例

次は、法人向けの設備保守サービスで、二つの案が同じ制作担当の作業時間を使うと仮定した例です。実際の顧客事例や成果の記録ではありません。どちらも緊急の障害ではなく、公開内容に誤りはないものの、必要な情報が見つけにくい状態とします。

案Aは、サービスページに対応設備と対象地域の説明を追加する変更です。問い合わせ記録から、対象外の設備や地域について相談が届き、営業が同じ条件を説明し直していることが分かったとします。案Bは、既存顧客向けの点検資料へのリンクを分かりやすくする変更です。資料の場所を尋ねる問い合わせがあり、現行ページではリンクが本文の末尾に埋もれているものとします。

この例では、相談前の判断を助けることを当面の事業課題としています。Bには差し迫った利用期限がないため、Aを先にしています。Aのほうが売上に効くと証明されたわけではありません。対象外の相談が減るかどうかは、公開後の確認が必要です。

同じ二案でも、点検日が迫っていれば事情が変わります。資料を入手できず顧客の作業準備に支障が出るなら、Bの優先度が上がります。Aの対応条件が見直し中なら、その確定を待つ間にBを進める判断もあります。担当と変更箇所が独立し、同時に進めても公開確認へ支障がないなら、二案を並行して扱うこともできます。

記録に担当と完了条件があれば、決定を実作業へ引き継げます。たとえばAでは、Web担当が確定した対応条件を掲載し、事業側の確認者が文面と公開表示を確かめるところまでを作業範囲とします。Bの見直し時期はAの作業終了時とし、点検日が先に決まれば再判断すると記録します。後回しにした理由と、判断を変える条件の両方が残ります。

完了条件と公開後の成果を分ける

バックログでいう「完了」は、決めた変更作業が終わったという意味です。成果まで出たという意味ではありません。合意した変更が対象範囲へ反映され、必要な公開確認と記録の更新まで終わった状態です。

公開直後に数字が変わらなくても、失敗とは限りません。検索上の変更が反映されるまでの時間は、変更内容によって異なります。GoogleのSEOスターターガイドも、効果が見えるまでの時間には幅があると説明しています。商談まで時間がかかるBtoBサイトでは、問い合わせ後の結果がまだ確定していない場合もあります。

結果をまだ確認できないときは、判断に足りないものを記録します。データが処理中なのか、問い合わせが少なく傾向を読めないのか、商談が進行中なのかで見直す時期が変わるためです。

観測中に同じ導線へ別の変更を加えれば、結果を一つの修正だけの効果として説明することは難しくなります。ただし、障害や誤情報の修正まで待つ理由にはなりません。変更日と内容を残し、結果を解釈する範囲を調整します。

公開後の成果は、変更前に決めた問いに沿って別に確認します。上のAの例なら、対応条件の掲載と公開確認が済んだ時点で作業は完了です。その後の問い合わせ記録に対象外の相談が残っていれば、説明が届いていないのか、条件を理解したうえで個別対応を希望しているのかで次の判断が変わります。件数の増減だけで修正の成否を決めず、当初解消したかった確認の往復がどう変わったかまで見ると、完了済みの作業を次の改善へつなげられます。