講師 自己紹介
はじめまして。リクルートジョブズ IT戦略室 カスタマウェブ開発1G Web Develop Director の takumin です。エンジニア、ソーシャルゲームプランナー兼アナリストを経験した後、昨年10月に入社しました。現在は新規事業のプロジェクトリーダーや、新規開発のリーダーを担当しており、WebサービスのPDCAサイクルを回すことが日々の業務となっています。
本稿では、WebサービスのPDCAサイクルのうち、サービス運営に当たる「Check」と「Action」において何に注目し、何を行うべきかについて解説します。
ユーザーのサービス利用時間は開発時間より圧倒的に長いんです
ちなみに、皆さんは「何のため」にサービスを作りたいですか？ この問いかけには、「○○な人が、△△をするため」という回答がよく返ってくるのですが、正しくは「○○な人たちが、△△をするため」と考えるべきです。
それは、サービスというのは「使う時間 ＞ 作る時間」という関係にあるからです。つまり、ユーザーがサービスを利用する時間のほうが開発時間より長い、それも何倍も長いということを、皆さん認識してください。
ちなみに、サービス運営では何をすべきか、十分なサービスを提供できているかを知るためのKPIを設定する必要があります。KPIは「Key Performance Indicators」の略で、日本語では「重要業績評価指標」と訳されます。意味を正確に言い表すと次のようになります。
「組織の目標達成の度合いを定義する補助となる計量基準群である。KPIはビジネスインテリジェンスにおいて、現在のビジネスの状態を示すものとして使われ、今後の対応策でどうなるかを予測するのに使われる。」（Wikipediaを引用・一部変更）
「え？ KPIとか言われてもわかんないよ」
という方がいらっしゃるかもしれませんね。端的に言うと「成功可否の判断に使う指標（数値）」です。
ダイエットをしている人を思い浮かべてください。目標は「来月までに5kg減らす！」もしくは「現体重マイナス5kg」です。このとき、KPIになるのはマイナス5kgです。相対値ではなく絶対値、つまり具体的な体重もKPIになります。私の場合、今の体重65kgからマイナス5kgすると60kgになります。
Webサービスの運営で使用される指標には、次のようなものがあります。
- DAU、WAU、MAU
- いずれも一定期間内におけるWebサービスのアクティブユーザー数で、DAUは日次（Daily Active Users）、WAUは週次（Weekly Active Users）、MAUは月次（Monthly Active Users）でカウントしたもの。
- 遷移率（フォールアウト）
- Webサービス運営者が意図したとおりにユーザーがページ遷移した割合。一般に、遷移率を向上させることで、CVR（コンバージョン率）も高まる。
- RR
- 回帰率（Return Rate）や維持率（Retention Rate)のこと。意味は同じで、過去にWebサービスを利用したユーザーが再び利用している割合。Webサービスに対する関心度やロイヤルティを計ることができる。
- CTR
- クリック率（Click Through Rate）のこと。Webサービス利用者のうち、特定ページ（Webサービス運営者が誘導したいページなど）のリンクをクリックした割合。メールやバナーの質を計ることが多い。
- CV、CVR
- CVはコンバージョン（Conversion：成約）、CVRはWebサービス利用者のうちコンバージョンに達した割合（Conversion Rate：成約率）のこと。
その他、「メールの開封率」「直帰率」「滞在時間」などWebサイト運営時に見る指標は様々です。
指標が満たすべき条件
ただし、数値化すれば何でも指標になるわけではありません。指標は、次に示す4つの要件を満たしていることが必要です。
- Understandable（理解可能）
- Comparative（比較可能）
- A ratio or rate（比率）
- Behavior changing（行動を変える）
Understandable（理解可能）は、ただ数字を出すのではなく、その数字を出した目的や数字が表す意味まで誰にも明確であることを求めるものです。指標なのですから、ごく基本的な要件といえるでしょう。
Comparative（比較可能）は、指標は「過去と現在」「自社と競合」といった比較ができ、さらにそこから自サービスの弱み、強みが浮き彫りにならなければならないという要件です。Webサービスはその性格によって「学生のうち男性には刺さっている（関心が高い）けれども、女子にはそれほどでもない」「昼間はアクセス数がとても多いけれども、夜は少ない」といった違いがあります。そうした違いは指標の比較によって明確化できる必要があります。
A ratio or rate（比率）は、2つの数字を1つの値として扱うことを指標に求めます。例えば、弊社にはタウンワークとフロム・エーナビという仕事・求人サイトがありますが、両サイトに集まった応募数を単純に比較しても、応募につながりやすいのはどちらのサイトかは判断できません。応募数ではなく、たとえば求人数に対する応募率を比較することで、応募へのつながりやすさを判断する材料にできます。
Behavior changing（行動を変える）は、「指標はとるべきアクションが具体的になる数字にする」という要件です。Comparative（比較可能）やA ratio or rate（比率）の要件を満たしている指標は、自ずと次にとるべきアクションが浮かび上がってきます。これはWebサービスの運営側に限らず、ユーザー側のアクションを変えることも含みます（タウンワークとフロム・エーナビのどちらで求人すべきかとか）。
指標の深掘りでは時系列の視点も忘れずに
また、書籍『Lean Analytics』の著者であるAlistair Crollさんは、指標について次のような指摘をしています。ポイントは「指標をいかにアクションへつなげるか」です。
- いかにデータを細かくするか
- セグメンテーションする（ユーザーを分類する）
- 時系列を無視した平均化はダメ
いかにデータを細かくするかのデータとは指標のことです。Slicing and Dicingのイメージで指標が表している事象（意味）をさらに深掘りし、特定のユーザー層（セグメント）に顕著な傾向（トレンド）をつかんで、とるべきアクションを定めます。
そのために、指標に対しセグメンテーションを行ってユーザーを分類します。例えば、ユーザーを分類する場合、性別（男性、女性）、年齢（10代、20代、……）、職業（学生、会社員、自営業、主婦[1]、……）などからセグメンテーションを行います。このとき、思いつく限りセグメントするのが理想です。
ただし、ユーザーの行動は時間に応じて変化しています。セグメントに顕著なトレンドをつかむ（ユーザーの平均化を行う）場合には、時系列でユーザーの行動を見ることも忘れてはなりません。トレンドは時期的な要因など、サービス外からも影響を受けます。今週や今月といった局所的な数値や、前年同時期の数値を見ることで、こういったトレンドが把握できることが多くあります。
また、学生は平日の昼間は授業、土日は休日なので行動は日曜日と月曜日とで全然変わってきます。一方、主婦であれば多くの方が平日でも昼下がりに比較的時間があります。この場合、ユーザーの属性と曜日とを掛け合わせてセグメントを決め、トレンドをつかまなければ、正しいアクションはとれないことになります。
まとめましょう。指標が満たすべき要件の4つ目は「Behavior changing（行動を変える）」でした。これは、深掘り（PDCAサイクルのCheck）することで正しいアクション（PDCAのAction）が定まるようでなければ指標として使えないということです。しかし、深掘りする際に時系列で見ることを忘れると、誤ったアクションを定めてしまう恐れがあります。この点には十分注意してください。
[1] 本稿でいう主婦は、主に専業主婦を指します。
指標をアクションにつなげた成功事例
ここからは指標をアクションにつなげて改善に成功した話として、「タウンワーク」で成果を大幅に高めた事例をお話しします。
問題点の整理
タウンワークでは会員向けに、求人を紹介するメールを送信しているのですが、そこからの応募数が低いという問題を以前から抱えていました。少し調べてみると、次のような問題点があることが明らかになりました。
-
1週あたりの通数が少ない
- 1桁でした
-
ユーザーに合った適切な情報が送られていない
- メールのタイトル、内容が全メールで同じ
- パーソナライズされていない
- 登録内容と紹介求人のミスマッチ
そこで、これらの問題点を解決するべく、次のように指標（KPI）とアクションを設定しました。
- 指標（KPI）
- ・メールからの応募数（CV数）
- 「通数が少ない」ことへのアクション
- ・配信頻度を増やす
- ・種類を増やす
- 「ユーザーに合った適切な情報が送られていない」ことへのアクション
- ・タイトル、内容の見直し
- ・求人抽出ロジックの改善
メール配信の改善
アクションの設定では、会員を年齢や職業などさまざまにセグメンテーションして、指標であるメールからの応募数を細かく見ていきました。メールの配信については「通数が少ない」という問題点が挙がっていましたが、それ以前に「この会員に対し、なぜこんな時間にメールを配信するのか」という現状が明らかになりました。そもそも配信時刻の設定に、会員のセグメントが考慮されていないようでした。
これを、次のように改善しました。
改善として何をしたのか？ この答えはシンプルです。
「セグメントごとに、
適した内容で、
適した時間に配信した」
というだけのことです。デモグラメール[2]は、例えば主婦と学生には次のように配信しました。
- 主婦に配信するデモグラメール
- ・主婦向け求人のみに絞る。
- ・家事などの忙しい時間を避ける。
- 学生に配信するデモグラメール
- ・学生から人気のある求人のみに絞る。
- ・昼間は学校に行っているので夜に送る。
一方、レコメンド（おすすめ）メールは次のように改善を行いました。
- 「検索率」をベースに時間を決める
- ・昼、夕方、夜で波があるがピークが20〜22時にくるため、送信時間を20時に決定。
- ・データはBigDataから取得。
- 内容はBigDataチーム独自のロジックから抽出
- ・ユーザーが見た情報と求人の関連をスコアリング。
これらはまさに、Alistair Crollさんの指摘である「いかにデータを細かくするか」「セグメンテーションする（ユーザーを分類する）」「時系列を無視した平均化はダメ」を実施したものです。
[2] デモグラはデモグラフィックの略で、年齢や性別、職業など人口統計学上の属性のこと。デモグラメールはこうした属性別に送信するメール。
改善は驚きの成果に
改善の結果、KPIである「メールからの応募数」はどうなったかというと、次の図のように約2倍という成果を得ることができました。
その後、こうした成功事例が積み重なっていき、会員を増やし、1日の間に応募数のピークをいくつも作ることができました。
おわりに
サービス運営ではKPIと計測、アクションを正しく組み合わせることにより、具体的な成果が得られます。サービスを実装する側の方も、経験と勘だけで運営を続けてきた方も、KPIを意識して業務を遂行してみてください。
- 使う時間 ＞ 作る時間
- KPI＝施策・サービスの成功判断に使う指標（数値）
- データとユーザーは細かく分類する
- 数値を見る＝ユーザーの行動を想像する
- アプローチにはKPIと対象のセグメントが必要
- ちゃんと結果は出る！
