Webディレクターズマニュアル 中村健太のディレクション講座

ゼロディレ, Vol.3 2013.06.29

0からのウェブディレクション講座： 運用編

ご挨拶と自己紹介

中村健太 Twitter：@cafekenta Facebook： http://www.facebook.com/cafekenta

2010年からディレクターズマニュアルの 中の人として活動。 子ども：2人（年長と小3） 趣味：筋トレとランニング 飲食店経営⇒アフィリエイター⇒ディレクター 趣味：筋トレとモータースポーツ マイナビから年内刊行予定の 『Webディレクターズマニュアル』書籍版を 現在執筆中

今日やること ゼロディレと運用とＷｅｂ解析

解析の意味とメリット・目的について

具体的に何をどうすればいいのか？な話

ワークショップ説明・ワークショップ＆発表

まとめと質疑応答

1

2

3

4

5

0からのウェブディレクション講座 『運用編』てなに？

『設計編』 ・企画 ・情報設計 ・マーケティング調査 ・ワイヤー作成 ・原稿・素材準備 などなど

『制作・進行管理編』 ・実装方法策定 ・チーム編成と座組 ・進行管理 ・クリエイティブ管理 などなど

3

『運用編』 ・更新 / 修正懸案管理 ・Web解析と報告 ・改善企画立案 ・計画策定と実行

1 2

ディレクションの大きな流れ

『設計編』 ・企画 ・情報設計 ・マーケティング調査 ・ワイヤー作成 ・原稿・素材準備 などなど

『制作・進行管理編』 ・実装方法策定 ・チーム編成と座組 ・進行管理 ・クリエイティブ管理 などなど

3

『運用編』 ・更新 / 修正懸案管理 ・Web解析と報告 ・改善企画立案 ・計画策定と実行

1 2

ディレクションの大きな流れ

ここね。ここ。

では、はじめましょう。

まず前提として

Webサイトは完成しない

作って終わりということは無く、かならずPDCAサイクルと呼ばれる例のアレを回して改善し続けないといけない。

Plan（企画して） Do（実行して）

Action（んで次の一手を･･･）

Check（上手く行ってんのか判断して）

中でもとにかく大事なのが、

Action（んで次の一手を･･･）

Check（上手く行ってんのか判断して）

ここにナイスパスが無いと、そこでプロジェクトのの成長・進行が止まる。と僕は考えている。

Webに当てはめて言うと

Check（アクセスを解析して） Action（改善施策を決める）

てこと ※すげー大雑把だけど・・・

さてここで質問

「Web解析って好きですか？」 ※アクセス解析と言い換えてもOK

大抵はこんな感じのリアクションだと思う

制作ディレクター「いや・・・あの・・・」

デザイナー「そーいうのは俺の仕事じゃないから」

プログラマー「え？なに？なんて？」

Web解析の意味とメリットと目的 について

解析の意味

いろいろやりたくなってくるサイトの運用において、「何からやるのか？」を明確にすることができる。

しかも根拠をハッキリ出せる

解析のメリット

制作ディレクター ・リニューアル案件の提案成功率がとんでもなく上がる ・コンサル料も取れちゃうかもしれない（ていうか取るべき） ・「好みの問題」に振り回されなくなる

デザイナー ・デザインに明確すぎるくらい明確な根拠が持てる ・ディレクターと本気でケンカできる ・とにかく驚くほどスピードが上がる

プログラマー ・不要な仕様を蹴っ飛ばせる。そのための根拠を持てる。 ・自分のコードにもっと自信がもてるようになる ・ユーザーへのインパクトの大きなモノに対し注力できるようになり、スピードが上がる

とかなんか色々。他にもいっぱい。

解析の目的 以下のような事を考えるため。もしくは考えるための指標を探すため。

サイトの「良くないところ」を探して、 改善する理由を見つけ出すため。

ユーザーが本当は何をしたいのか？を把握して「次このサイトでなんかやるとしたら何しよう？」を考えるため。

ユーザーが「こっちの思惑通り動いてるか？」を計測して、その通りになっていればその強化を。なってなければ「じゃあ何でだろう？」という仮説を立てる。

平たく言うと

「このサイトって○○じゃね？（仮説）△△△したほうが良くない？（提唱）」

と、言い切るためにやる

そう。 仮説を取りに行く行為なのよ。

数値データを 調べる仕事じゃ 無いんだよ。

仮説が立てば、やるべきことが見えてくる。

例：

このサイトコンバージョン低くね？（課題）

フォームがグダグダだからじゃね？（仮説）

じゃフォームの導線改善しようか（やるべきこと）

やるべきことが見えてくれば、 項目をまとめて行動が起こせる。

例：

フォームのどこが悪いんだ？（調査）

そうか。長すぎて途中で逃げちゃうのか（問題発見）

じゃ短くしよう（方針決定）

これとこれとこれはカットしても問題ないな（施策草案）

じゃ短くなったバージョンのワイヤー書くわ（設計）

デザインやり直しだから3営業日はかかるな（工数算出）

プログラムは処理変えるだけだから1日だな（工程決定）

じゃやるか！（実行）

大事なことなのでもう一度

解析は、PDCAサイクルのCからA

につなげる大事なポイント。

P D C A

だから、Cでとめちゃだめだし、Aにつながらないパスは出しちゃだめ。 Cで止めちゃう＝膨大な数値データをキレイに並べて満足しちゃう Aにつながらない＝「このサイトじゃダメです」みたいなどーにもならん結論を出しちゃう

Web解析の基本的なやりかた

具体的に何をどうすればいいのか？

前提条件 Googleさんはまぁ大体の事を知っている

具体的なやりかた4ステップ。

理想の導線を考える

仮説を立てる

何をどの順番でやるのか決める

このサイトはなんかダメだ！と決めちゃう

読んで字のごとく サイトは完成しない。 であれば完璧なサイトなんて存在しない。 だから、まずは「未完成なものである」という前提で数字に向きあいます。

このサイトはなんかダメだ！と決めちゃう

理想の導線を考える

トップ 一覧 個別ページ

フォーム 確認画面 完了画面

そのサイトにおける「こういう道筋を辿ってくれたらいいなー」 という導線を考える。 「初見の理想導線」「2回目の理想導線」 「5回目の理想導線」を分けて考えるとなかなか面白い

仮説を立てる

「もしかしてこのサイトがダメなのって〇〇だからじゃない？」

「もしかしてこのサイトがダメなのって〇〇だからじゃない？」

〇〇には、「ユーザーの気分」を代入してやると上手く行きやすい 例： もしかしてこのサイトがダメなのってユーザーがこのページ来た時にクリックしたくなるようなものがスグに出てこないからじゃない？ みたいな

解析結果データに書いてある数字は数字じゃない 誰かが、それぞれの事情や悩みや欲求にそって行動したその履歴だもの 数字の向こう側に人間を見なければ、解析はうまくいかない

何をどの順番でやるのか決める

その仮説を「なんとかする」ために「何をするべきか？」を考える 考えた結果を並べる そして優先度を付ける

中村が良く使う判断基準 ・ユーザーに届くスピード

・数字に対するインパクトの大きさ ・施策の簡易さと実装の早さ

さて、大体わかった？ じゃやってみよう

ワークショップ

ワークショップでの課題

・このサイトは何がダメなの？――課題の明文化

・で、何から何をどうするべき？――施策の明確化と優先度設定

・それはなんで？――根拠となる数値を明示

これをワークショップでやってみましょう。 ※これメモ取ったほうがいいよー。

ワークのルール 1 時間はたっぷり1時間！

2 かならずパソコン持ってる人をグループに入れてください。 グループができたらとりあえず自己紹介

3 他決めること ・リーダー（ファシリテーター） ・書記（ライター） ・発表者（リーダー以外の人でも面白いよ）

4 発表（1チーム5～10分）×5チーム＝30～50分程度

GAワークショップやりました

アカウントの公開はさすがにできないので、ワークショップ実施時の写真でご容赦ください。

おつかれさまでした

みんなで解析やってみていかがでした？

結構楽しかったんじゃないでしょうか？

仮説が出てくるの早かったんじゃないでしょうか？

会社に戻ったらぜひやってみてください。 デザイナーも プログラマーも SEも プロマネも ディレクターも 一緒になってやってみてください。

ディレクションにおける Web解析に必要なのは、 アナリティクスを手足のように使えるテクニックじゃない。

数字の先にあるユーザーの 気分と気持ちと想いと理由を妄想できる イメージング能力。

それが最も重要

イメージをふくらませるなら 誰かと話すのが一番早い。 経験談だし、ディズニーの「イマジニア」のやり方でもある。

という訳でまとめ

解析はPDCAを回してプロジェクトを加速させるエンジンになる 1

数字に意味はない。その先にある人間の姿を捉えなければいけない。 2

一人でやると結構しんどい。でも皆でやるとすげーエキサイティング 3

以上。 ご清聴ありがとうございました。

質疑応答

なんでもOKです。時間の許す限りお答えいたします。 時間なくなった場合は懇親会のときに聞いてください。語ります。