新サービスを使い続けてもらうために工夫した2つのこと

こんにちは。くらしのきほんグループのエンジニアの長田です。

私たちのチームでは、「くらしのきほん」という普段の暮らしの楽しさや感動を再発見するサービスを提供しています。 くらしのきほんでは、料理をはじめとした日々の暮らしを丁寧に送るためのコンテンツを提供しています。

また、くらしのきほんのサービスの一部として、「わたしのきほん」という、ユーザーが普段の生活の中で大切にしている事を言葉で投稿するサービスをスマートフォンWebで提供しています。

この記事では、わたしのきほんを使い続けてもらうために工夫したことと、その効果についてご紹介します。

わたしのきほんとは

わたしのきほんは、TwitterやFacebookのように自分の近況を投稿するのではなく、自分が今までの人生の中で出会った、素敵だと思う言葉を投稿するサービスです。

投稿の例としてはこんなものがあります。

f:id:osadake212:20160809181103p:plain

このサービスの1番面白いポイントは、「投稿を重ね、言葉を振り返ることで、自分の輪郭がはっきりしてくるところ」です。

日々の生活を送る中で、大切にしていることや信条のようなものは誰しもが持っていると思うのですが、それを言語化する機会はありません。ブログやSNSで自分を発信していたとしても、それは近況報告だったり、心からの言葉ではなかったりします。

わたしのきほんは、ブログやSNSにあるようなタイムラインやシェア機能を設けておらず、自分の書いたものだけが常に見られるようになっており、他の人の目をあまり気にすることなく投稿できるようになっています。

なので、サービスを使うたびに「ああ、自分ってここに気をつかってるんだ」という再確認ができ、自分という人間の輪郭がよりはっきりしてきます。

わたしのきほんを使い続けてもらうために

わたしのきほんは投稿サービスなので、どんどん投稿をして欲しいのですが、自分が大切にしている言葉をずっと投稿し続けていくのは難しいです。例えば、投稿することを思いつかなくなってきて、投稿できなくなってきた人や、ただ投稿し続ける動作に疲れてしまった人などがその例だと思います。

そのようなユーザーは、自分一人で投稿し続けることに限界を感じているのではないかという推測をし、他の人との接点をもつと、より投稿しやすくなるかもしれないという仮説をたてました。

当初は自分の言葉を振り返ることを主目的にしていたので、SNS的な要素はできるだけシンプルにしていたのですが、上に書いたような課題を解決するためにも、他人とのつながりをもう少し強化して、投稿のモチベーションを上げてもらう改善を試みました。

モチベーションを上げてもらうためにやった2つのこと

改善は日々行っているのですが、その中から2点だけ、その内容と効果について紹介させていただきます。

トップページからいいねできるようにして、いいねUUが1.6倍に

この改善の目的は、ユーザーが書いたきほんに、より多くのいいねをつけてもらうためでした。

自分が投稿したものに対していいねがつくと嬉しいですよね。それは、わたしのきほんでも例外ではなく、ユーザーにもっと喜んでもらうために、いいねを増やすことにしました。

そこで、既にくらしのきほんトップページに表示していた、スタッフがピックアップしたユーザーの投稿に、いいねボタンを配置し、くらしのきほんに訪れたユーザーが、すぐにいいねできるようにしました。

[左: いいねボタンなし, 右: いいねボタンあり] f:id:osadake212:20160809220926p:plain

トップページにはその他のコンテンツも表示していることもあり、情報量を少なくする目的で、当初はいいねボタンを置いていませんでしたが、毎日訪れてくれるコアユーザーにとっては、いいねがすぐできるほうが嬉しいですし、初めて訪れるユーザーにとっては、わたしのきほんというサービスがどんなサービスかをより説明できると考え、いいねボタンを置きました。

結果としては、これまでいいねの機会を逃していたユーザーを獲得することができ、いいねのUUが1.6倍になりました。

スタッフがピックアップしたものをユーザーに通知して、投稿数が1.2倍に

投稿した言葉がいいねされると嬉しいということは、自分が書いたきほんが他の人にも共感して欲しい、という承認欲求があるということです。 とはいえ、ユーザー同士のつながりを過剰に強化することで、いわゆるSNS疲れのような状態になってしまうのも防ぎたいと考えていました。

そこで、スタッフがピックアップしたことをユーザーにお知らせする機能を追加しました。 スタッフからの通知であれば、ユーザー同士のつながりではないので、SNS疲れの心配もないですし、ピックアップされるとくらしのきほんトップに掲載されるため、投稿のモチベーションになります。

f:id:osadake212:20160809181109p:plain

結果としては、通知によりユーザーの投稿のモチベーションを上げることができ、投稿数が1.2倍になりました。

おわりに

この記事では、くらしのきほんのサービスである、わたしのきほんについてのご紹介と、サービスを使い続けてもらうために工夫したこととその効果について紹介させていただきました。

開発者が意図していたことは必ずしもプラスに働いている訳ではありません。また、開発者の懸念が、よりユーザーの行動を制限している場合があります。

この改善を通して、サービスの使いやすさや分かりやすさはバランスが重要であることを再確認しました。 新規サービスの場合、開発者はサービスのヘビーユーザーなので、今日はじめて訪れるライトユーザーの気持ちになることを心がけ、サービスをバランスよく改善していくことが大切です。

このわたしのきほんの事例が、これから投稿サービスを開発する人にとって、何かのお役に立てれば幸いです。

データベースドキュメント管理システム dmemo のご案内

こんにちは、みんなのウェディングに出向中の小室 (id:hogelog) です。

今回はクックパッドとみんなのウェディングで利用しているデータベースドキュメント管理システム dmemo を紹介します。

https://github.com/hogelog/dmemo

f:id:hogelog:20160808041022p:plain

dmemo を作成し導入した経緯

私は2016年3月頃からみんなのウェディングで Redshift, bricolage, embulk, re:dash 等を利用したデータ分析基盤の構築を進めています。 (みんなのウェディングのデータ分析基盤の現状 - みんなのウェディングエンジニアリングブログ)

社内の誰でも扱えるデータベース、データの集約・計算・加工、ダッシュボードの作成、クエリの共有などは上記ブログ記事でも書いたように Redshift, bricolage, embulk, re:dash 等を組み合わせることで実現できました。ですがそれだけでは DWH を社内の誰でも簡単に扱える状態とは言えません。たくさんのデータがあっても意味がわからなければ役にはたたないからです。

ソースコードを読み解くことでしかデータの仕様を理解できない環境では一部のエンジニアと周辺の人しか高度な分析をおこなえません。データの仕様のドキュメント化も進めていましたが、なかなか整備しきれるものではありません。

しかし実際のところデータベースに存在するスキーマ・テーブル・カラムなどのスキーマ情報はプログラムで自動的に取得できる情報です。スキーマ情報からはわからない「このテーブルはなんのためのテーブルなのか」「このカラムが取りうる値はなんなのか」といった情報のみを人が管理していけば良い、そんなツールを目指して作ったのが dmemo です。

dmemo の仕組み

dmemo は DBとして PostgreSQL を利用するごく標準的な構成の Rails アプリケーションです。

  • 接続可能データソース(データベーススキーマ情報の取得元)
    • Redshift
    • PostgreSQL
    • MySQL
  • Google OAuth 2.0 認証
  • バッチ実行によるデータソースとの同期処理

Dockerfile, Docker Imageも提供しているため、多くの環境ではDocker経由で稼働させるのが簡単でしょう。

ユーザ認証

ユーザ認証は Google OAuth 2.0 認証のみ提供しています。

接続先データソースなどの編集は Admin ユーザのみに許可されていますが、最初の Admin ユーザは DB を直接編集するか rake タスクから作成する必要があります。

$ ./bin/rake admin:activate EMAIL=konbu.komuro@gmail.com
 or
$ docker run --env-file .env.docker hogelog/dmemo ./bin/docker_admin_activate.sh konbu.komuro@gmail.com

データソースとの同期処理

dmemo はデータソースとなるデータベースのスキーマ・テーブル・カラムなどのスキーマ情報は半ば自動的に取得します。

Admin ユーザならば dmemo の Web 画面上からも実行できるのですが、基本的にはバッチ処理による同期を推奨します。

$ ./bin/rails r 'SynchronizeDataSources.run'
  or
$ docker run --rm --env-file .env.docker -t hogelog/dmemo ./bin/rails r 'SynchronizeDataSources.run'

みんなのウェディングとクックパッドでは上記処理を日次で実行し、実データと dmemo を同期させています。

Markdown による記述と履歴の保持

肝心のデータの仕様についてはデータベース・スキーマ・テーブル・カラムそれぞれに Markdown で説明を記述できるようになっています。データの現在の正しい仕様について誰でも恐れず更新していってほしいため、記述内容については差分を保持しています。*1

f:id:hogelog:20160808064011p:plain

辞書機能

データベースの説明にはドメイン固有の言葉がたくさん出てきます。

例えばクックパッドで文脈無しで「ユーザID」と言えば「main データベースの users テーブルの id カラム」のことです。このような説明を記述しておくため辞書機能を実装しました。

説明文の中に記述したテーブル名と辞書項目については自動的にリンクされるため、説明文における重複した記述を避けることができます。

HTML::Pipeline

余談ですが dmemo では Markdown 処理部分に HTML::Pipeline を利用しています。HTML::Pipeline は HTML を入力として Filter を通し HTML を出力するためのライブラリであり Markdown から HTML の変換も Filter として提供されています。HTML 構造を理解して処理するため文脈に応じた拡張文法の実装が容易であり dmemo のテーブル名・辞書項目の自動リンク機能も Filter の一つとして実装されています。

注意点

現在の dmemo は社内で設置し特定の Google Apps ドメインのユーザのみアクセスできる状態での動作を想定していおり、 Markdown 記述機能に関して一切の制限をかけていません。script タグなどもそのまま記述できるため、インターネットから不特定ユーザからアクセスできる状態で設置すると危険です。

OSS として開発したことによるメリット

実のところ dmemo はみんなのウェディングの DWH に感じた課題から、余暇にちょっとずつ開発していたソフトでした。2016年6月頃にはある程度の完成度に至り「意外とこれは本当に便利そうだし会社でも導入した方が良さそうだな」と感じていたのですが、まだ完成度に不安があったのと、日々の業務に追われみんなのウェディング社内には導入していませんでした。

そんな頃にふとクックパッドで DWH 基盤を構築している id:InoHiro id:mineroaoki もクックパッドのデータベースの仕様ドキュメント化に同様の課題を抱えていると聞き dmemo を紹介したところ、id:mineroaokiの「いいじゃないすか、そういうのが欲しかったんすよ」という一声により、あっという間にクックパッド社内に導入されてしまいました。*2

導入され運用が始まると手元で開発していた時には気づけなかった様々なフィードバックが届きます。例えば当初の dmemo はデータソースとの同期はオンラインでおこなう作りでしたが、 Redshift などに大量のテーブルが存在する場合同期処理の間アクセスができなくなる、デプロイの度にキャッシュが消えて特定巨大テーブルへのアクセスがタイムアウトするなど運用が辛いものでした。テーブル名の自動リンク、辞書機能などもまったく発想になかった機能もフィードバックから実装に至りました。

OSS として広くフィードバックを受けながら開発しているというにはまだちょっと狭いかもしれませんが、とりあえず会社の枠は超えた改善が実現できました。

まとめ

クックパッドとみんなのウェディングでは dmemo を利用しデータベースの暗黙知を組織内で共有し、誰でも簡単に使えるデータ分析基盤の構築を進めています。

クックパッドでは id:mineroaoki を中心としたプロフェッショナルなチームにより世界一使われている料理とレシピのサイトのデータ分析基盤が構築されており、みんなのウェディングでは id:hogelog id:takai_naoto らによりもう少し小規模なデータとチームでスピード感を持ってデータ分析基盤を構築しています。

クックパッド、みんなのウェディングどちらでも興味のある方は是非お声掛け下さい。実際に運用している dmemo の画面を見てみたいとか、そんなカジュアルな見学もいつでも歓迎しています。もちろん本格的な採用情報への応募もお待ちしております。

*1:日付つき但し書きが大量に書かれた仕様書、よく見かけますけど読むのは辛いですね

*2:実際のところクックパッド社内にも導入させてやろうという目論見のもと開発していましたし、紹介しました。業務でバリバリに使われるOSSを個人で開発したかったので、狙い目だったのです

アプリのユーザーテストをGoogle Play ベータテストで行う

 こんにちは。検索事業部 ディレクターの五味です。クックパッドにレシピを探しに来るユーザーの体験向上を使命に、レシピ検索に纏わる技術・UIの改善、プラットフォームをまたいだサービス全体の編成に関わる仕事をしています。

 プロダクトのリリースや改善にあたり、ユーザーテストによる仮説検証は不可欠です。今回は、先日クックパッドAndroidアプリで初めて、Google Playのベータテスト機能を使ってユーザーテストを行った話をご紹介します。

ベータテストに踏み切った背景

 クックパッドアプリでのユーザーテストはこれまでも実施してきましたが、すべて通常版アプリにテストを内包する手法をとってきました。

 しかしあるプロジェクトで、これまでのユーザー導線を根底から変える規模の改変を含んだプロダクトのテストを行う必要が生じました。アプリ全体の体験から大きく異なるテストプロダクトを通常版アプリに統合することはコストが高すぎる上、メリットもありません。

 そこで、テスト版アプリを通常版と別バイナリとして配信でき、またその対象者も既存のアプリユーザーから募ることのできる、Google Playのベータテスト機能を利用してみることにしました。

既存アプリで大胆な価値検証ができた

 1つの仮説にとことん集中し、その仮説を満たす最低限の機能のみで構成されたプロダクトを実際のユーザーに配信して反応を測る。今回ベータテストを実施してもっとも良かった点は、そのような大胆な価値検証を、クックパッドという既存アプリで遂行できたことです。

 今回のテストは、従来であれば、新規の別アプリを作って検証する等の手段を取らざるを得ない内容でした。しかしその手法では、将来的に既存アプリをテストプロダクトでリプレイスする可能性がある場合、その際に生じるネガティブな反応の大きさを計り知ることができません。

 この検証は、ユーザーが普段使っているアプリがテスト版に置き換わるというGoogle Playベータテストの仕様によって可能になったものでした。

f:id:natsuki53:20160803091737p:plain

ベータテストの実施で考慮すべき点

 ここからはベータテストに興味をお持ちの方向けに、テスト実施の際に一考いただきたいポイントをご紹介します。この3項目は今回我々が苦慮した点でもあります。

1. オープン?クローズド?

 ベータテストにはGoogle Appsアカウントでテスターを管理できるクローズドベータと、テスター数の上限だけを設定するオープンベータの2種があります。テストの目的や要件をよく考慮し、状況に合った方式を選ぶことが大切です。

 今回のケースでは数千単位のテスターを必要としており、アカウント管理のコストを考慮すると、本来はオープンベータを採択するべき案件でした。しかし以下の理由から、敢えてクローズドベータを選択しました。

  • 仮説がきちんとターゲットに響くか確かめるため、テスト参加者を既存アプリの利用パターンから選出した方に限定したい
  • テストプロダクトがMVP検証のため既存機能を大幅に削ってあるため、注意事項をご理解いただいた上で参加いただきたい

 結果、テスト参加者は想定より大幅に少なくしか集客できませんでしたが、この施策段階では条件に合うユーザーにテストアプリを使っていただくことが、数を揃えるより優先度が高かったと考えています。

2. ベータテスト参加のユーザー体験

 サービスによって差異はあるとは思いますが、ユーザーはこのようなテストアプリを利用することに熟達していないという点を忘れてはいけないと思います。

 試しにアプリのベータテストに参加してみると、テスター募集からテスト参加、テスト版アプリのインストールまで、画面遷移は多く、導線も複雑です。Google Play Developer Consoleでの作業の簡単さと引き換えに、Google Play側の各画面は編集できる領域が少なく、使われる用語もユーザーにとってわかりやすくはないように思えます。

f:id:natsuki53:20160802185251p:plain

 テスト参加の敷居を下げ、多くのユーザーにテスターとなってもらうため、以下のような準備をしました。

・テスト参加ご案内ページ

 テストにスカウトしたユーザーに概要を知っていただくためのページです。参加規約や、テストアプリを入手するまでのフロー解説、お問い合わせ導線をまとめています。

f:id:natsuki53:20160802185310p:plain

・テスター専用FAQ

 事前にFAQを作成。テストアプリ内のわかりやすい場所に導線を設けました。テストを途中離脱したい場合の解説等も併記しています。

f:id:natsuki53:20160802185330p:plain

・ユーザーサポートチームの協力

 サポートチームに担当をつけてもらい、事前にテストアプリの機能表や想定問答集を共有。専用チャットルームも準備して密にコミュニケーションを取れる体制を作りました。

3: テスターの募集方法

 テストアプリの配信はGoogle Playに助けていただけますが、参加者確保はすべて自前で行う必要があります。今回はこの点になかなか苦戦しました。

 リクルーティング導線として、今回はAndroidアプリのスタートスクリーンにテスター募集のバナーを表示しました。しかしこの導線のパフォーマンスが予想以上に厳しく、3000人にバナーを表示しても、100名程度しか反応が得られませんでした。てこ入れ策として対象ユーザーにメール配信も行いましたが、そちらも思うほど効果がなく、最終的にテストアプリをインストールしていただけたのは200名弱という結果になりました。

f:id:natsuki53:20160802185351p:plain

今後に向けて

 今回のベータテストでの1番の収穫は、既存アプリで作り上げられている環境を制約とせず、新しい機能に集中した急進的なテストプロダクトを、実際に今のアプリを使っているユーザーに試用いただけたことです。

 テストにご参加いただいたのに利用反応がなくなってしまった方に、プロジェクトメンバーが直接電話インタビューを行い、リアルなご意見をいただいて悄気てしまう日もありました。しかしそこからのプロダクト改善は目覚ましく、そのようなネガティブな反応をいただけたのも、既存のクックパッドアプリから更新する形でテストアプリをお使いいただくことができたおかげだと思います。

 次はより多くのテスターに使っていただくなど、段階に合わせたテスト方法も検討していく必要があります。折しもGoogle社からオープンベータの機能増幅やテスター参加導線の強化がいくつか発表されていますので、それらもうまく取り入れ、より柔軟にテストを活用できるようにしていきたいと考えています。

 なおクックパッドでは、このようなサービス改善に一緒に取り組み続けてくださる方を、職種問わず募集しています 。ご興味のある方はこちらからどうぞ。