第14回：施策の実行 – 改善案の発案と実行

2019.09.11

施策を実行する前に「記録の仕組み」を整える

WEB解析HTML_アイキャッチ画像前回までで、改善案のブレストから施策の絞り込みまでをお話ししました。ここまで来ると、編集作業を行い、計測環境を整え、あとはファイルをアップロードするだけ、という段階に入ります。「早く試してみたい」という気持ちが出てくる頃ではないでしょうか。

ですが、その前にやっておくべき作業があります。これを怠ると、ノウハウの蓄積やその後のPDCAサイクルに響きます。それは「きちんと記録をとっておく」ということです。

変更意図と変更日時を必ず残す

まず、変更日時とともに、変えた部分とその意図、そして想定している数字の変化を記録として残してください。ソフトウェアのリリースノートのように、どこかで履歴としてまとめて見渡せる状態が理想です。

記録するフォーマットは何でも構いませんが、誰でも簡単に見られて、後から加工しやすいものを選びましょう。特にこだわりがなければ、Googleスプレッドシートがおすすめです。

特定のPCに縛られず、クラウドなのでどこからでもアクセスでき、エクセルのように計算も画像の貼り付けもできます。優秀なスクラップブックとして機能してくれます。

「覚えているだろう」と思うかもしれません。しかし私の経験上、忙しさに追われて他のことをやっているうちに、きれいさっぱり忘れます。後から変更前と変更後を比較しようとしたとき、履歴がなければ手も足も出なくなってしまうのです。

変更のタイミングにも気を配る

理想の変更タイミングは、0時ちょうどです。アクセス解析のことを考えると、日別できれいに区切れたほうがデータの比較がしやすくなります。とはいえ、深夜にアップロードして検証するのは現実的ではないという方も多いでしょう。その場合は、朝一番がおすすめです。

夜は意外と遅くまでサイトが見られていますが、朝は出勤後しばらく、みなさん朝の作業に没頭するのか、アクセス数はそこまで多くありません。ターゲットがビジネスパーソン以外の場合は、一度アクセス数を時間別に確認してみてください。深夜0時から朝9〜10時頃までと、夜の帰宅時間帯から24時までを比較して、アクセスが少ないほうを選ぶとよいでしょう。

スクリーンショットを残しておく

変更履歴に加えて、画面のスクリーンショットも記録しておくと、振り返りの精度がさらに上がります。変更前と変更後の状態が画像として残っていれば、アクセス解析だけでは読み取れなかった部分を、その画像を使った簡易ユーザーテストである程度フォローすることもできます。

できればただの画像ではなく、HTML形式で保存しておくのがベストです。ページ内のリンク構造も含めて残るため、ページ遷移の流れを追うときに助かります。ただし、毎回HTML形式で保存するのは手間がかかりますから、通常のスクリーンショットと併用するくらいの運用が現実的でしょう。

記録の運用は「忘れる前提」で設計する

参考までに、私自身は次の三つを変更のたびに行っています。

  1. メールで関係者に概要を告知する（件名は振り分けのために固定）
  2. 変更履歴ポータルに変更内容と変更ファイルを記載する
  3. 特定の共有フォルダに、年月日と時間を入れたアーカイブファイルを保存する

忘れっぽい自覚があるからこそ、仕組みで補っているわけです。また、Google Analyticsのアノテーション機能も便利です。画面上部のグラフにメモを付けられる機能で、変更履歴ドキュメントへのリンクを書いておけば、解析画面から直接たどることができます。

とにかく大切なのは、「変更箇所は忘れる」という前提で記録の仕組みを作っておくことです。短いスパンなら記憶でなんとかなるかもしれません。しかし、「昨年の梅雨時期に商品のキャッチコピーを何をどう変えて、結果がどうなったか」と聞かれて、即答できる人はまずいないでしょう。季節要因はWebサイトの数字に大きく影響しますから、こうした過去の記録が思わぬ場面で役に立つのです。地道ではありますが、この積み重ねが改善サイクルの土台になります。

コンテンツナビゲーション

コンテンツ一覧・目次