技術部の根岸(@negipo)です。おもにトクバイのウェブサービスを触っています。昨日の夜は一晩中イソギンチャクが泳ぐ動画を眺めて過ごしていました。
みなさん、サービス開発やってますか? ぼくはやってます。きわめて困難なことばかりでおもしろいですよね。ぼくはいつのまにか困難なことにめちゃくちゃなおもしろみを感じるようになってしまいました。たとえば成功指標の取扱いなんてわりとむずかしいのでおもしろいです。
「私たちはサービス全体のPVに対して責任を持っています」
「そうですね」
「今回の施策はサービス全体のPVを向上させるものです」
「わかりました。やってみました」
「よくわかりませんでしたね。PV、あんまり上がらなかったし」
「はい」
こういうこと、ありませんか? そんなことはないですか? あなたが一番最近やった施策ではどうでしたか? 「出したら前よりよくなるのが自明だから成功指標を立てなかった」みたいなことになってませんか?
ぼくは成功指標にはふたつの役割が与えられていると考えています。
- 成功の定義付けをし、共通認識をつくる。
- 成功したかどうかを判断する。
この記事では上記それぞれの観点で、ぼくが最近やった施策ではどういうふうに指標がつかわれたのかを紹介します。みなさんがサービス開発をする上で成功指標をどのように取り扱うとよりよくなるのかを考える一助になれば幸いです。
成功の定義付けをし、共通認識をつくる
正直なところ「今回の施策はサービス全体のPVを向上させるものです」は経験的にけっこうよくある状況です。つきつめていくと、このように成功指標がぼんやりしているという状況は「機能開発の目的を先鋭化しきれていないこと」に原因があるとぼくは考えています。我々が提供しようとしているサービスがある側面においてどのような状態であり、それをどうすべきなのかという探索的な意思決定が、指標を決定するプロセスにおいてはかならず必要です。
トクバイでは、日本全国をさまざまに細分化した各地域に『地域ページ』というページを割り当てており、それぞれお店などを紹介しています。このページに対して最近おこなわれた改善を例に挙げて、どのように指標を決定していくのか、その過程でどのような価値が生まれていったのかという一連のプロセスを紹介したいと思います。
施策の妥当性の確認
改修前の地域ページは、県単位、エリア単位、市区町村や駅周辺など、漸次追加されていった価値も仕様もバラバラなページ群でした。エンジニア(ぼく)とディレクター兼デザイナのふたりチームは、ある日マネージャーから次のような注力事項の提案をうけました。
- 地域ページでは、検索エンジン経由でランディングしたひとたちがうまく価値を見いだせていないように見受けられるので、改修をおこなってより良くしていきたい。
- 価値があるページを作ることができれば、回遊が伸びると思われる。成功指標として回遊数を置いてはどうか。
たしかにすべてのページが古めかしく、あまり整っていません。しかしこれは、『検索エンジン経由で地域ページにランディングしているひと』が少ないため、メンテナンスコストがこれまでかけられていないことには合理性があるという事実に基づいたこれまでの意思決定の結果だと我々は見ていました。この点についてマネージャーと会話し、施策自体の妥当性の確認をしました。マネージャーはこの事実をもちろん知っていて、その上で「あたらしいランディングキーワードの切り口を模索しており、地域ページをユーザが目的を順当に果たすページにすることができれば、地域系キーワードの検索ランキングが上がる可能性がある」という見立てがあることがわかりました。このねがいと地域ページの改修のあいだにある論理的つながりがよく理解できたので、我々は施策の検討に入ることにしました。
成したい価値の確認
改修をやるということは決まりましたが、この時点で誰の何を解決するページにするのかが決まっていませんでした。すでに作成されていたデザインモックにはいろいろな要素が載ってしまっています。我々はこれまでの地域ページの特徴がすべて『店舗のリスト』だったことや、トクバイがすでに持っているリソースなどを踏まえて、最初のリリースの目的を『買い物をする人の行くお店が決まる状態にする』と明文化し、マネージャーとも意見の一致をみました。
成功指標の決定
この時点で、「回遊数」は目的の達成に対する指標として適していないことは明らかだと我々は考えました。「買い物をする人の行くお店が決まる」ことに対してただしい指標はどんなものがありそうでしょうか。我々は過去の知見から『成功セッション比率』をこの指標にしようとあたりをつけました。
- 検索エンジンから地域ページにランディングし
- 店舗ページへ一度でもアクセスした
このようなセッションを『成功セッション』と定義し、『検索エンジンから地域ページにランディングしたセッション』に対する比率を成功指標として検討することを決めました。
妥当性を検証するために、現状実装されているそれぞれの地域ページや、比較対象としておおむね同じ目的でよりよくメンテナンスされているページでこの指標がどのような値を取るかを確認しました。我々はログ分析基盤にArm Treasure Dataの製品を用いているため、このような指標の分析ではUDFであるTD_SESSIONIZE_WINDOWを用いたクエリで自由なセッション分析を行っています。結果として
- 異なる特徴を持った地域ページ間では成功セッション比率に相当な差がある。
- 比較対象となったよりよくメンテナンスされているページでは、成功セッション比率が地域ページのそれの二倍程度高い。
ことが事実として確認できました。比較対象のページの成功セッション比率がわかったために、これをベンチマークとして到達したい成功指標の目標が容易に決定されました。また、ページ間の特徴の差分から、地域ページの特徴としてどのようなものを採用すれば良さそうなのかを確認することができました。
以上の内容についてマネージャーと再び話し合うことで、施策の成功に対する組織レイヤ間の共通認識をつくることができました。
成功したかどうかを判断する
我々の施策が成功したかどうかを判定する必要が当然あります。A/Bテストを行ったり、リリース後の変化を見たりして、成功指標のとる値が施策の結果どのように変化したのかを確認しましょう。
もし失敗しても大丈夫です。サービス開発はきわめて困難であるために失敗するのが当然です。また、我々は詳細な成功指標をすでに決定しているため、要因のブレイクダウンによる失敗の振り返りをおこなうことは(まったくなにも指標を設定せずに施策をおこなった場合とくらべると)比較的容易です。
すべてのひとびとが成功したかどうか確認できるようにする
協働する上で成功指標を確認できるロールがエンジニアだけという状況はよくありません。我々はRedashをもちいてこまかな各施策の成功指標をダッシュボード化し、成功指標をすべてのロールのひとびとが確認できるようにしています。
起きた変化を定点観測できるようにする
トクバイのような会社ではひとりのひとが関わる施策は同時並行にいくつも走っていますし、プロジェクトも同様に同時並行にいくつも走っています。個人がすべての成功指標を常に確認し続けるのは大変困難です。トクバイではコミュニケーションツールとしてSlackをもちいており、すべてのプロジェクトはproj_
プレフィクスがついた状態でそれぞれチャンネル化されています。
我々は各プロジェクトがおこなった施策の成功指標やサービス全体のヘルスチェックを定点観測化するために、redashbotをもちいています。redashbotに話しかけることで、Redashの特定のグラフがどのような状況にあるかを確認できます。これとSlackのreminderを組み合わせる(/remind here @redashbot https://... every weekday
)ことで、直近でおこなった施策やそのプロジェクトが責任を持っている指標の状況がどのようになっているかが各プロジェクトのチャンネルに日次で流れるようになっています。
さて、地域ページの改修ではどうだったでしょうか。今回の施策ではいくつかの機能の段階リリースを行う予定でしたが、ごく初期のリリース状態で成功指標の目標値を超えてしまいました。
これも目的を先鋭化させてそこにリソースを集中したおかげですね。チームのみんなもおおよろこびでした。
お給料も上がってくれるといいですね。
まとめ
これまで述べてきたように、詳細な成功指標を決定すると個人においても組織においてもよいはたらきがあります。
- 目的や仕様を先鋭化できる。
- 目的が決まっていない場合、成功指標を決める過程で施策の目的を詳細に定義できる。
- 何を重視するかが定義づけられ共有されるため、協働において仕様が比較的容易に決定できる。
- この機能はまじでぶっ壊れててやばいからやっていこうということに確信が持てる。
- どれくらい壊れているかということが理想的な目標との乖離によって認識できるため、投入するリソースの量や技術的な意思決定に強い影響がある。
- 施策の各段階で未来がイメージできる。
- 施策前にこう成功したら偉いねということがわかり、施策後に偉かったねということがわかるし、もし偉くなかったねということがわかったら次にやるべきことを決定しやすい。
- みんなでよろこべる。
- 成功できたら当然偉いけど偉いかどうか分からなかったらよろこべない。
詳細な成功指標を一エンジニアの立場から決定するためには、当然ながら戦略を策定する役割に近いところへと身を置くことになります。それは我々のような「どうやるか」とともに「なにをやるか」を重視するようなサービス開発エンジニアにはチャレンジする価値のある領域だとぼくは考えています。
どうせサービス開発ではなにもかもがきわめて困難です。この記事を読んだひとびとの中から、役割の壁という見えないボーダーをどんどん越えてはたらくエンジニアが増えてゆくとうれしいな〜と思っています。