2026年10月8日にGOV.UKのDiscoveryとユーザーニーズガイドを再確認した。作る前に問題、利用者、制約、代替案、成功の測り方を調べ、解決策と問題を分けて証拠で検証する考え方を確認した。匿名化した相談事例は成功率や業界の典型性を示すデータではないため、見た目の要求、利用者の行動、現状の証拠、代替案、検証指標を別欄に置く。小さな試験は全サイトの因果効果や長期成果を証明しない。
「サイトをリニューアルして」と言われたら、制作会社はすぐ見積もりを出せます。ですが、見た目の不満と、採用・問い合わせ・運用の問題は同じ原因とは限りません。作る前に、何を解くのかを一つへ切ります。
公式資料を読み直した日と範囲
2026年10月7日に、GOV.UKのDiscoveryガイドと、ユーザーニーズのガイドを再確認しました。公式ガイドは、作り始める前に問題、利用者、制約、代替案、成功の測り方を調べ、調査の結果として進めない判断も認めています。以下のケースは匿名化した実務上の例で、統計的な効果や典型性を主張しません。
30秒で要点
- リニューアルは目的ではなく、問題を解くための一つの手段
- まず利用者の行動、現状の証拠、制約、作らない選択肢を同じ表へ置く
- 問い合わせの量、質、採用、運用負担を一つの成果に混ぜない
- 見積もりの前に、最も危険な仮定を小さく確かめ、進める・止める条件を置く
表が収まらない場合は、横にスクロールできます
| 先に見る欄 | 例 | 確認する証拠 |
|---|---|---|
| 目的 | 応募の質、問い合わせの適合 | 面談、問い合わせ内容 |
| 現状 | どこで離れるか | 分析、検索、録音、観察 |
| 選択肢 | 修正、再構成、待つ、別施策 | 比較と費用 |
| 検証 | 何が変われば進むか | 小さなテスト、期限 |
相談の入口で結論を保留する
匿名ケースでは、担当者から「サイトが5年以上前で、採用と問い合わせの質が上がらない。上司からリニューアルを求められ、複数社へ見積もりを取り始めた」と聞きました。
確かなのは、見た目への不満と、社内で動きを示したい圧力があることです。不確かなのは、採用応募の減少や問い合わせの質がサイトの見た目に起因するか、候補者がどこで迷うか、期限と予算がどこまで硬いかです。
ここで制作案を出すと、見積もりという形が結論を強めます。まず「何が起きると困るのか」「誰の行動が変わってほしいのか」「サイト以外の原因は何か」を聞きます。
問題を四つに分ける
目的：量ではなく行動を書く
「応募を増やす」を、誰が、どの情報を理解し、どの段階で応募するのかへ分けます。「問い合わせを増やす」も、受けたい顧客の条件、問い合わせ後の対応、成約までの負担を分けます。
現状：見た目の印象と行動を分ける
アクセス、検索語、離脱、フォームの入力、面談での発言、営業が受けた質問を同じ表へ置きます。競合が新しいという印象は仮説であり、失注や離職の直接原因だと決めません。
制約：期限と体制を明示する
年度内に公開したい、更新担当は兼任、既存CMSを変えられない、法務確認が必要、といった条件を硬い制約と仮定へ分けます。制約を隠して作業を始めると、後から納期と品質のどちらかを切ることになります。
選択肢：作らない案を同じ土俵に置く
ページを再構成する、重要な一ページだけ直す、応募フォームを変える、採用広報を変える、顧客との説明を変える、いったん調査する、という選択肢を比べます。作らない案を置くと、リニューアルが本当に問題へ近いかが見えます。
失敗像：制作が成果の代理になる
- 新しいデザインが公開され、社内は動いたが、応募の質や問い合わせ後の対応は変わらない。
- アクセス数だけが増え、受けたい顧客との会話が増えたか分からない。
- 期限を守るため、分析・法務・更新体制の確認が後回しになる。
- 公開後に「次はSEOか広告か」と手段だけが連鎖する。
これらを避けるには、公開日ではなく、最初に変えたい利用者の行動と、測る期間を決めます。
最小検証：一つの仮説を一週間で見る
- 「候補者が仕事内容を理解できず、応募前に離れる」のように問題を一文にする。
- 分析、検索ログ、問い合わせ、面談記録から、根拠と未確定事項を三つずつ拾う。
- 一ページの文章、導線、フォーム、説明資料のどれか一つだけ変える。
- 応募数ではなく、適合、離脱、質問、対応時間など目的に近い指標を見る。
- 変わらなければ、制作を広げず、仮説か対象者を更新する。
公式資料の範囲を外さない
GOV.UKのDiscoveryとユーザーニーズのガイドは、行政サービスの文脈で書かれた実務ガイダンスです。自社サイトの成果、業界、契約、法務、予算を直接決めるものではありません。ケースの手順は、公式の「問題を理解してから作る」という考えを、自社の小さな検証へ翻訳したものです。
判断の土台として押さえておくこと
- リニューアルを結論にしない：見た目の要求を、解く問題と利用者の行動へ言い換える。
- 現状の証拠を並べる：アクセス、発言、離脱、対応負担を印象と分ける。
- 作らない案を含める：一ページの修正、運用、説明、待つことも比べる。
- 小さく検証する：公開規模を広げる前に、仮説と指標を一つ試す。