PDCAとは?Google Analyticsを使ってみてわかった仮説とKPIの話
こんにちは．
このブログは自分用のメモが主目的で，ついでにこれからプログラミングとか電子工作とかを始めようとされる方の助けにもなったらいいなという気持ちで始めたのですが，意外と読んでくださっている方がいるようなので，そういった方々に喜ばれるにはどうすればよいかなと考えたりしています．
ただ，そのために過剰に私の工数を割いてしまって本来やりたかったものづくりが出来なくなってしまうと本末転倒なので，いかに手間を少なく，かつ多くの人の役に立つ情報を発信できるかというところが肝になってきます．
ここでふと気づいたのですが，この考え方はビジネスと全く同じなのです．手間を少なく多くの人に役に立つのがこのブログのミッションで，最小限のコストで最大限の付加価値を提供することがビジネスのミッションです．
私はビジネスのポイントはどれだけ素早くPDCAを回すかだと思っているのですが，今回はこのブログの運営を例に，そのあたりを説明しようと思います．
そもそもPDCAがなぜ大事かという話を3分くらいで読める分量で説明させてください．
-------------------ここから--------------------
PDCAは，成功に再現性を持たせるために必要です．PDCAなしでも偶然ヒット商品を出したり，思いつきで投資したベンチャー企業の株価が1万倍くらいになってボロ儲けをすることはありえますが，それらはまず一発屋になってしまいます．
重要なのはこうすればヒットするんじゃないか，こういう基準に当てはまる会社は急成長するのではないかという仮説に基づいて(P)行動を起こし(D)，行動の後に自分の仮説は合っていたか，合っていなければどこが間違っていたかを見直し(C)，次にプランを立てる時はどのような点に気を付けるかを洗い出す(A)ことを繰り返すことで，少しずつ方向転換し，最終的な目標に近づいていくわけです．下の図はPDCAがある場合とない場合の最終目標への道程のイメージ図です．
PDCAが回っていないケースでも計画を立てて行動を起こすというプロセス自体は存在するので，私はよくPDプロセスと言うのですが，左図はそのPDプロセスの場合のイメージです．右図はPDCAがきちんと回っている場合を表しています．
両者とも一発目の行動では同じくらい外していますが，次が違います．どこがダメだったのかを考えているPDCAプロセスでは少し目標に近づきます．PDでも偶然目標に近づくこともありますが，それも偶然なので継続的に目標に近づく可能性はPDプロセスが多くなればなるほど低くなっていきます．成功からよりも失敗から学ぶことの方が多いとよく言いますが，それはPDCAが回っている場合に限るのです．
------------------以上で約3分くらい---------------------
というわけで私は何か事をなすうえでPDCAが非常に重要だと考えているのですが，ちまたにあふれるPDCAの実例は，それが経営においてコアな話であるがゆえに隠されている部分も多く，具体性に欠けます．そこで，すべてをさらけ出しても構わないこのブログを例にとって，PDCAの方法論を展開していきたいと思います．
1. PLAN
PDCAサイクルは1個ずつ順に回していくよりは，複数のものを同時に回していくことがほとんどです．なぜならある目標を達成するために発生する仮説は複数である場合が多く，その仮説の数だけPDCAを回す必要があるからです．
例えば私はこのブログに関していくつかの仮説を立てました．ゴールは冒頭でも申し上げた通り，余計な手間を掛けずに，より喜ばれるコンテンツを提供することです．
【仮説】
- 初歩向けのHow to情報(ラズパイの環境構築など)が人気なのでそういった情報を充実させていった方が良い
- ラズパイとかRaspberry Piなどのキーワード検索からの流入が多いのでそのあたりのキーワードを多く入れていく
- 検索流入よりは同ブログの記事からのリンクやTwitterからの流入の方が実際に読んでくれる人が多いのでブログ内リンクやTwitterへの発信に力を入れる
- ラズパイ2発売みたいなニュース記事はアクセスは増えるがすぐに離脱されるのでたまにしか書かない
- 記事がすぐに読破できるくらいの分量を脱する(100記事くらいから?)とブックマーク登録される(何記事くらいでその傾向が見えるか知りたい)
- 同ジャンルの記事(ラズパイ関連)が増えたらまとめ記事書いた方がよくて，そこはブックマーク登録が増える
- 内容的にPCからの閲覧が多いためスマホ向けのページ最適化は不要
ざっとこんな感じです．
次にこれらを定量的に見るために数値を決めるのですが，これがいわゆるKPIですね．
- 初歩向けのHow To情報が人気かどうかはページ別のPV数(閲覧された回数)を見ればわかります．
- 検索からの流入が多いかどうかは参照元別のPV数を見ることでわかります．
- 検索流入よりも自分のブログからのリンクやTwitterからのアクセスの方が実際に読んでくれているかどうかは参照元別の平均ページ滞在時間でみることが可能そうです．
- ニュース記事が読まれているかどうかもページ別滞在時間で見ることが出来ます．
- 記事数が溜まるとブックマークに登録されるかどうかは，日別の総ユーザ数と新規ユーザ数を時系列でみれば読み取れそうです．
- まとめ記事のアクセス数もページ別PV数と滞在時間および各ページの参照元ごとのPV数などで見ることが出来そうです．
- PCからのアクセスが多いかどうかは端末別のPV数でわかりそうです．
これらを勘案して，以下のKPIを追いかけることにしました．
- 日別のPV数と閲覧開始数
- 日別の総ユーザ数と新規ユーザ数
- アクセス元別PV数と平均ページ滞在時間
- ページ別のPV数と平均ページ滞在時間
- デバイスジャンル別PV数と平均ページ滞在時間
Google Analyticsのマイレポート機能で上記を1画面で見るようにしました(下図)．週に1回くらいこれを見るだけでCheckができるので手間はそんなにかかりませんね．
さて，仮説を立ててそれを確認するためのKPIまで定めました．あとはどのような方針で行動するかを決めます．
上記の仮説を元に，下記のような行動を起こすことにします．
【行動】
- How to系の内容を増やす．どこかのページで紹介されていてもリンクを貼って省略するのではなく噛み砕いて説明する．
- Raspberry Piとラズパイどちらのキーワードにも対応するため，タイトルはRaspberry Piで統一，本文中はラズパイに統一．
- 記事を書くたびにTwitterへ投稿．内容があまりテクニカル過ぎないものはfacebookにも投稿．
- ニュース記事は基本的には書かないが，新規ユーザ取り込みを行う目的と，本当にニュース記事は直帰率が高いか検証するためにたまに書く．
- 記事数増やすために1項目1記事にする．(これは目当ての内容を探しやすくする目的でもともとその予定だった)
- ある程度記事が溜まったらまとめ記事を書く
- スマホ向けのページ最適化(画像サイズ，段落分けなど)は行わない
2. DO
ここまでで一応PLANが出来上がったので，実際に行動を起こしてみます．PLANを作成した2015/2/12から今日までの記事を見ればわかると思いますが，基本的に上記の行動指針に愚直にしたがって記事を書きました．以下は期間中の記事の一覧です．
Raspberry Piの初期設定をキーボードとディスプレイ無しで実行する - ものづくりブログ
How to系の記事です．予想ではPVが高いはずです．タイトルではRaspberry Pi，本文ではラズパイという表記に統一しています．
SSH接続する際にホスト側が変わってしまって接続できない時の対処法 - ものづくりブログ
こちらもHow to系の記事です．
Raspberry Piの使い方まとめ - ものづくりブログ
まとめ記事です．ここへの流入はずっとコンスタントにあって，流入元はブックマークが多く，新規ユーザより再来訪ユーザが多いというのが当初の予想です．
Raspberry Piをサーバ化する その1(目次) - ものづくりブログ
How to系です．
非エンジニアがFirefox OS WoTハッカソン - Fx0 meets mbed -に参加して得たこと #fx0xm - ものづくりブログ
ニュース系です．PVは増えるが，あまり固定ユーザ増には貢献しないという予想です．
Raspberry Piをサーバ化する その2(サーバを立てる) - ものづくりブログ
How to系です．
PHPについてちょっとだけ勉強してみた - ものづくりブログ
これは完全に自分用のメモなのであまり関係ありません．でも一応PVなどは確認します．
3. Check
しばらくしてデータが溜まったら仮説が合っていたかどうか確認します．一つずつ検証していきましょう．
- 初歩向けのHow To情報が人気かどうかはページ別のPV数(閲覧された回数)を見ればわかります．
- 検索からの流入が多いかどうかは参照元別のPV数を見ることでわかります．
- 検索流入よりも自分のブログからのリンクやTwitterからのアクセスの方が実際に読んでくれているかどうかは参照元別の平均ページ滞在時間でみることが可能そうです．
- ニュース記事が読まれているかどうかもページ別滞在時間で見ることが出来ます．
- 記事数が溜まるとブックマークに登録されるかどうかは，日別の総ユーザ数と新規ユーザ数を時系列でみれば読み取れそうです．
- まとめ記事のアクセス数もページ別PV数と滞在時間および各ページの参照元ごとのPV数などで見ることが出来そうです．
- PCからのアクセスが多いかどうかは端末別のPV数でわかりそうです．
仮説1について検証してみます．以下はHow to系の記事とその他の記事のの平均PV数と平均滞在時間を比較したものです．
予想に反して，How to系よりもその他の記事のほうが合計PVも1PVあたりの平均滞在時間も高いという結果になりました．
次にHow to系全般の人気が低いのかを検証していきます．以下は記事ごとのPV数と平均滞在時間を比較したものです．
2/16のニュースの人気が圧倒的であることと，2/13のHow toが不人気であることが目立ちます．前者はハッカソン参加の記事で，後者は非常に限られたケースでのみ使えるHow toでした．また，滞在時間を見ると2/12の記事は実際に読まれる率が高いことがわかります．これはラズパイを買った人ならほとんどの人が使えるHow toだったため，実際に役立つことが多かったのだと想像ができます．逆に2/17の記事は殆どの人が直帰していることがわかりました．これはHow toというよりも基礎的な勉強的な内容でした．
また，仮説4について，ニュース記事の滞在時間は短いという予想でしたが，それが間違っていることもわかりました．
次に仮説2と3について検証していきます．以下は流入元別のPV数と滞在時間です．
予想通りGoogle検索からの流入が大部分を占めています．また，予想でははてなブログ内(同一ブログ内)で遷移してきたユーザの方が滞在時間が長いと考えておりましたが，そのような結果は得られませんでした．滞在時間という観点ではYahoo!からの流入ユーザの平均滞在時間が飛び抜けて高いことがわかりました．
仮説5と6について確認していこうとしましたが，まだデータ数が少なく，有意と言える結果が得られませんでした．
仮説7については，下記のような結果になり，概ね予想通りPCからのアクセスが大部分を占めました．
このように，合っている仮説もあれば間違っている仮説もありました．立てた仮説があっていたかどうかを振り返るのがCheckです．
4. Action
次は先ほどのCheckの結果を受けて，次のPlanではどのようなことを意識すべきなのかを考えていきます．
How to記事かニュース記事かという違いはPVや滞在時間に影響しないことがわかったので，もう少し違う軸で考える必要があります．今回わかったのは場合が非常に限られるようなHow toよりも誰もが一度は通る道のような内容を説明した記事が人気ということでした．また，逆に基礎的な内容はほとんど読まれないことがわかったため，自分用のメモに必要な場合をのぞいて書く必要は無いことがわかりました．
流入経路別では，Googleからの流入が非常に多いことがわかりました．また，Yahoo!からの流入で滞在時間が飛び抜けて高いため，その原因を探る必要がありそうです．
まとめ記事の効果と，記事数がたまったことによるブックマーク入りの可能性は検証できなかったので，引き続き見ていく必要がありそうです．
5. PLAN(2周目)
ここからは最初のPLANと同じです．違うのはその前のActionによってノウハウが溜まっている点です．このように，PDCAサイクルを回せば回すほどノウハウが蓄積され、PLANの精度が上がっていくのです．さらにやってみるとわかりますが，KPIの立て方なども実情に最適化されるため，PDCAが回るのがどんどん早くなっていきます．
引き続きこのブログに関してはPDCAを回していきますので，またもう少ししたら経過をご報告致します．
参考文献
特になし
