改善の優先順位は、重大な不具合を先に扱い、その後に影響、原因の確かさ、工数で決めます。見た目が気になる順に直すと、問い合わせに関わる問題が後回しになることがあります。実施だけでなく確認まで含めた作業量で比較しましょう。
最優先で扱う問題
フォーム送信不能、主要ページのエラー、誤った料金・連絡先、重要な操作を妨げる表示崩れなどです。原因が明らかな問題は、効果測定のために放置せず修正します。改ざんなどが疑われる場合も、通常の改善計画とは別に対応します。
改善案を評価する表
| 評価軸 | 確認すること |
|---|---|
| 事業への影響 | 有効な問い合わせや重要情報に関わるか |
| 利用者への影響 | どのページで誰が困るか |
| 根拠の確かさ | 再現、データ、問い合わせ記録があるか |
| 工数 | 調査、制作、確認、今後の運用にどれだけ必要か |
| 依存関係 | 先に別の作業を終える必要があるか |
再現できる不具合と、まだ推測の施策を同じ確度で扱わないようにします。工数が小さいだけで、根拠のない変更を次々に行わないことも重要です。
優先順位の仮の例
| 改善案 | 判断の理由 | 順番の考え方 |
|---|---|---|
| 通知メールが届かない | 問い合わせを取りこぼす | 最優先で原因調査と修正 |
| 料金条件を追加 | 同じ質問が繰り返される | 情報確認後に早めに実施 |
| CTAの色を変更 | 効果の根拠がまだ弱い | 導線の問題を調べてから |
| CMSを刷新 | 全体への影響と費用が大きい | 基盤の問題を調査して計画 |
これは考え方の例で、すべてのサイトに同じ順番が当てはまるわけではありません。
小さな修正を続けるか全体を見直すか
同じ修正が多くのページで必要で、個別対応が複雑になっているなら、共通部分の改修を検討します。事業構成とCMSが合わない場合も、追加を重ねる前に全体設計を比較します。
一方、課題が限定されているなら、全面リニューアルを先に決める必要はありません。残る問題と将来の追加費用まで見て、必要な範囲を選びます。
点数で優先順位を決める場合の注意
影響と確からしさを3段階、工数を作業日などで評価する方法もありますが、点数は見積もりの補助です。低工数の案ばかりが上位になり、必要な基盤修正が永久に後回しにならないようにします。
大きな改修は調査、設計、実装へ分け、まず判断に必要な調査を進めることもできます。短期の修正と中期の改善を別枠で持ち、同時に進める量は、実装後に確認できる範囲へ絞りましょう。
一施策ごとに結果を戻す
対象、仮説、担当、実施日、確認する指標を決めます。実施後は同じ条件で確認し、結果が不明なら何が不足しているかを記録します。順位表を固定せず、新しい事実が分かったら次の順番を変えていく運用にしましょう。