こんにちは、株式会社ビットジャーニーに出向中の出口 (@dex1t) です。ビットジャーニーでは、社内情報共有ツール Kibela*1のサービス設計やプロダクトマネジメントに責任を持ちつつ、エンジニアとして開発全般に携わっています。
今回は、新サービスの立ち上げ時にどのような考えで重要指標*2を設計し、それを実際の開発のなかでどう使っていくかという話をします。
なぜ検証をするのか
そもそもなぜ新サービス立ち上げ時に、重要指標や検証といった考えが必要になるのでしょうか。それを考えるにあたって、クックパッド的なサービス開発の流れを改めて整理してみます。
企画と検証は表裏一体
サービス開発といえば、企画・開発・検証をぐるぐる回すというのが一般的だと思います。指標は検証段階で活用する道具です。企画で考えたことを確かめるのが検証段階であり、企画と検証は表裏一体です。 したがって、指標の設計をするにあたっては、その前段階である企画段階について抑えておくのが重要です。
サービス企画には様々な方法論があると思いますが、「何を作るべきか定義する」ことは、どんな方法にも共通しているのではないでしょうか。クックパッド内でもやり方は様々ですが、私の場合は次のような流れで定義しています。
- 思想を定める
- サービス価値、目指す世界観を定義する
- 体験を定める
- サービス価値を実現するためにどんな体験が必要を定義する
- 機能を定める
- 体験を提供するためにどんな機能が必要か逆算する
これらをフォーマット化したものが、この開発者ブログでも何度か紹介されている、アプリケーション定義ステートメントシートやEOGSです。上記3点を抑えられれば、フォーマット自体は自分の慣れたものを使うのが一番だと思います。
思い込みを確かめる
ここで大切なのは、企画はあくまで開発者の思い込みであり、企画を具現化した後にはそれを確かめる必要があることです。先に挙げた3点で言えば、次のような確かめどころがあります。
- 提供している「体験」が、「思想/価値」を実現できているか
- 例) 「今晩の献立がすぐに決まる」体験は、「毎日の料理を楽しみにする」という価値に繋がっているか
- 提供している「機能」が、「体験」に寄与しているのか
- 例) 「人気順検索」機能は、「今晩の献立がすぐに決まる」体験に寄与しているのか
- 提供している「機能」は、意図通り「機能」しているのか
- 例) 「人気順検索」機能は、どんな人にどれぐらい利用されているか
1.を定量的に正しく検証するのは難しく、定性的手法での検証が向いていると思います。本エントリは指標を使った定量的な検証の話なので、2.と3.について考えます。
指標をみる2大シーン
先の2.と3.の言い換えになりますが、指標をみる2大シーンとして次が挙げられます。
- 機能が定めた体験に寄与しているか (線の検証)
- 機能 (feature) が機能 (work) しているか (点の検証)
クックパッドにおけるレシピを探す体験を例にすると、次のようなイメージです。
一般的に「検証」というと、CTRなどの比較によるA/Bテストを思い浮かべるのではないでしょうか。それはあくまで「点の検証」であり、ある機能の最適化はできても、その機能が体験全体にとって必要かどうかは判断が難しいところです。
サービスの立ち上げ時は、ある一点の機能だけを磨きこむことに集中するよりも、定めた体験がそもそも正しいのかをまずは確かめるべきだと私は考えています。これは、ほとんどの新サービスの場合、一機能の良し悪し以前に、定めた体験がユーザーの欲求に合致していないことが多いからです。そのため、サービスの立ち上げ時こそ、「線の検証」を重視すべきだと考えています。
何を測るのか
それでは先に挙げた、体験 (線) の検証をするためには、具体的に何をすればいいのでしょうか。
体験の定義としてのユーザーストーリー
体験 (線) を検証するためには、まずはその体験の定義が必要です。定義の表現方法には様々な手法があるかと思いますが、私のプロジェクトでは、複数のシナリオから成るユーザーストーリーを書いています。ユーザーストーリーとは、ざっくり言えば、開発者が頭のなかに描く「サービス上でユーザーはこう考えて、こう行動する」という妄想を文章にしたものです。
敢えて妄想と書いたのは、サービス開発初期はユーザー理解がまだ浅いことが多く、ストーリー自体の妥当性は低いと考えられるからです。あくまで妄想ですが、文書化やそのレビューを通して、ユーザーに期待する行動についての認識が、チーム内で統一される効果は得られます。チーム内での認識のブレは、新規サービス立ち上げ時に立ち向かうべき問題の1つです。これを解消できるのは大きな効果です。
ユーザーストーリーの構成
サービス開発初期のユーザーストーリーは、未検証であることは自体は仕方がありませんが、それでもあまりに現実味が無さすぎると使い物になりません。そのため、書き方には注意が必要です。ユーザーストーリーを構成するシナリオは、次の2つを分けて書くようにしています。
- アクティビティシナリオ
- ユーザーの心情と行動にフォーカスして書いたシナリオ
- クックパッドではセリフ調で書くことが多いです
- 例) (仕事帰りに) 今日の晩ごはんどうしよう。たしか冷蔵庫に茄子があったから消費したいな。へー茄子のチーズ焼きか。簡単そうだし美味しそう！帰ったら作ってみよう。
- インタラクションシナリオ
- 目的を達成するための、サービス上での具体的な操作を書いたシナリオ
- 例) クックパッドiOSを開く、検索ボックスをタップ。茄子と入力し検索する。人気順検索の1位になっていた茄子のチーズ焼きのレシピをタップ。材料欄と手順欄をスクロールして確認し、MYフォルダに保存。
アクティビティシナリオを書く上での注意点は、具体的な操作名や機能名を出さないことです。つい「この導線をクリックする」のような表現を使いがちですが、普段の生活の中で導線やクリックといった言葉は使いません。結構書くのがしんどいのですが、ここでのシナリオに現実味が感じられない場合は、おそらく実装しても同じことが起きるでしょう。
このようにユーザーストーリーを書く上では、アクティビティとインタラクションを区別すること、そして何より、開発を進める中で深まったユーザー理解を随時ストーリーに反映し、妥当性を高めていくことが重要です。
どのストーリーを検証すべきか
ストーリーといっても、多くの場合サービス上には無数のストーリーが考えられます。サービス上の登場人物 (キャスト) が多ければ多いほど、ストーリーも増えていきます。例えば、私が今携わっている社内情報共有ツール Kibelaでは、社内ツールという性質上、「記事を閲覧する人」「記事を投稿する人」だけでなく、「Kibelaを社内で管理する人」といった、多様なキャストが存在し、そのそれぞれに提供すべき体験 (ストーリー) があります。
サービス立ち上げ初期は、全てのストーリーを網羅して検証することは難しいですし、検証だけに時間をかけることになると本末転倒です。そのため、このストーリーが欠けたらサービスが成り立たない、という一点にまずは集中して検証すべきです。
Kibelaの場合は、「記事を投稿する人」のストーリーにまずはフォーカスしています。情報共有ツールである以上、記事の投稿による情報共有が成立しないと元も子もないからです。このような考え方は、書籍『Lean Analytics』においてOMTM (One Metric That Matters) として紹介されています。書籍のなかでは、様々なサービスのOMTMが紹介されているので、指標を設計する上ではぜひ一読をオススメします。
どうやって測るのか
ここまでは設計の話でしたが、次は目指すべき体験 (ストーリー) に対する現状の達成度をどうやって測るかについてです。
これは、定めたインタラクションシナリオから、ユーザーの行動を抜き出し、それらを行動トラッキングツールで測ることで実現できます。クックパッドではそのツールとして、Mixpanelを使うことが多いです。具体的な方法については、データドリブンでユーザー体験を改善する試みのなかでご紹介していますので、よろしければご覧ください。
重要指標を活用する
ここまでで体験を定め、ストーリーを通して指標化し、実際に数値として計測することができました。ここからは実際のサービス開発の中で、定めた指標をどう活用していくかについてお話します。
ダッシュボードでモニタリングする
サービス開発初期は、大胆なサービス設計の変更や、ユーザー層の変化など、指標に影響を与える要因が多く存在します。そのため、一度定めた重要指標は継続的にモニタリングしていくことが重要です。また、モニタリングする指標はダッシュボードとして、一箇所にまとめています。見るべき指標が色んなツール上にバラバラしていてアクセスし辛い状況だと、見ること自体が億劫になり、設計した指標も無意味になります。
Kibelaでは行動トラッキングツールとしてMixpanelを使っているため、ダッシュボードもMixpanel上に作りました。Mixpanelには、Platform機能というものがあり、これを使うとMixpanel APIを使って、Mixpanel上の値をよしなに操作した上で可視化しダッシュボード化できます。これがベストとは言えませんが、Kibelaでは見るべき指標をMixpanelに集約しているため、今のところ必要十分でした。
意識せずに重要指標を見てしまう状況をつくる
詳しくは後述しますが、ここで定めた重要指標はチームの共通理解であるべきです。そのため、ダッシュボードを活用するのがチーム内でひとりだけだと不十分です。チームメンバーの日常の導線の中にダッシュボードを置き、意識せずに重要指標を見てしまう状況を作ることも大切です。
私のチームでは自分たちのサービスであるKibelaをドッグフーディングしているため、メンバーは常日頃Kibelaを見ています。手前味噌になりますが、Kibelaは社内ポータル的な使い方ができ、iframeで上記のダッシュボードをKibela内に埋め込んでいます。これで、毎日Kibelaを開く度に重要指標のグラフが目に飛び込んできます。
また関連して、Statsbotを使って、重要指標のサマリーをSlackに定期的に流すといったこともしています。
このようにして、サービスの健康状態をチーム全員が無理せず把握できるような状況を作っています。
毎週定例で分析し共有する
ここまで述べてきたような「体験 (線) 」は、「機能 (点) 」への変更の積み重ねによって変化が起きるものです。そのため、サービスのアップデート起因とは別に、定点観測的に分析をおこなっています。
Kibelaの場合は、毎週月曜日に定点観測しています。結果はドキュメントとしてまとめてチームメンバーに共有します。繰り返しになりますが、これも重要指標の理解を個人に留めずチームの共通理解にするための試みです。
重要指標を軸にコミュニケーションする
基本的にサービス開発は、正解がない中での細かい意思決定の連続だと思います。そのため、チーム内で何らかの基準を持った上で、議論するのが大切だと考えています。ここで定めた重要指標はその際にも有用です。
タスクの優先順位付けや、製品仕様の決定、デザインの方向性の決定、カスタマーサポートの方針、などサービスに関係するあらゆることは常に重要指標を軸にして判断するようにしています。こうすることで、議論の方向性がブレず、意思決定の速度が上がると考えています。
まとめ
本エントリでは、新サービス立ち上げ時の指標設計とその活用方法についてご紹介しました。指標というテーマだったため、インタビューに代表される定性的な検証手法には触れませんでしたが、決して蔑ろにしているわけではありません。実際Kibelaでも、オンライン・オフライン問わずインタビューによる生の声は非常に重要視しています。定量と定性の両方の良さを組み合わせつつ、サービスの検証を進めていくことが重要だと考えています。
最後になりますが、クックパッドはもちろんビットジャーニーでも、デザイナー・エンジニアを募集しています。このようなサービス開発にご興味あるかたは、@dex1t までお気軽にお声がけください！
*1:8/1にティザーサイト https://kibe.la/ を公開したばかりのサービスです。現在、先行登録いただいた方にベータ版へのご招待を順次進めています。
*2:KPIやKGIといった用語とほぼ同義です
