レシピ連動調味料サーバー「OiCy Taste」の設計情報を公開、解説します

研究開発部のスマートキッチングループ プロトタイプエンジニアの山本です。専門分野はロボティクスです。
スマートキッチングループでは、 レシピを様々な機器とつなぐスマートキッチンサービス「OiCy」の開発を進めています。今年の5月、OiCyの開発を発表した際に、コンセプトモデルレシピ連動調味料サーバー「OiCy Taste」を公開しました。クックパッドからハードウェアが発表されたことに驚いた方も少なくないかと思います。かく言う私もその一人で、「OiCy Taste」を見てクックパッドのスマートキッチンの取り組みに興味を持ち、この夏からハード系エンジニアとしてプロジェクトに加わることになりました。よろしくお願いします。 このエントリでは、このレシピ連動調味料サーバー「OiCy Taste」の設計情報を公開します。

最初に

皆さんは料理をしますか?料理を楽しんでいますか? 料理とエンジニアリングはとても良く似ていると私は考えています。レシピが設計図で、材料の調達をして、加工(料理)をして、完成品を顧客に評価してもらう。加工の過程で廃材(生ゴミ)が出るので処分が必要で、設計図通り作ったはずなのに同じになるとは限らない図面や文章に載らないノウハウがあること。エンジニアリングが好きな人間は料理にもハマれると思います。何より、家族が美味しいと言ってくれたときの喜びは、苦労して作った製品やサービスが顧客からイイネって言われたときに勝るとも劣らない喜びだと思います。 では、自分自身を顧みて、日常的に料理はしていますがその料理を楽しめているのか?と自問してみると、仕事や育児に追われて時間のない中で、料理をタスクの様に感じて必ずしも楽しめていない事に気が付きました。楽しくて当然のことなのに楽しめていない。この問題をエンジニアとしてどう技術で解決するのか?この気付きを与えてくれたのが、今年5月のクックパッドの[レシピを様々な機器とつなぐスマートキッチンサービス「OiCy」]との出会いでした。

レシピ連動調味料サーバー[OiCy Taste]の設計情報公開の意図について


動画:レシピ連動調味料サーバー「OiCy Taste」
※本品はコンセプトモデルであり現時点で発売の予定はありません。

レシピを様々な機器とつなぐスマートキッチンサービス「OiCy」では、クックパッドに投稿されたレシピを、機器が読み取り可能な形式(MRR: Machine Readable Recipe)に変換して機器に提供します。レシピのMRR化ついては、9/7の大谷のエントリ:OiCyサービス(開発中)の裏側 〜レシピのMRR化〜で紹介されています。ぜひそちらも読んでいただければと思います。
さて、レシピ連動調味料サーバー「OiCy Taste」は、スマートキッチンサービス「OiCy」を利用した調理機器のコンセプトモデルです。クックパッドで作りたい料理を検索してレシピを閲覧すると、機器側が連動して簡単な操作でそのレシピで用いる調味料を配合して出すことができます。レシピを見ながらの調味料の配合は、レシピに書かれた分量を自分が作る料理の量に合わせて計算したり、各調味料の蓋を開ける、分量を測る、蓋を閉める、といった細かな作業の繰り返しです。実際料理をしていると、これはこれで結構手間がかかる作業で億劫だったりします。また、料理をしている最中は、手が濡れていたり汚れていたりしますので、音声を使って調味料を出せると手を拭く手間を省けますし、現在している調理作業を中断する必要がなくなり作業の効率性があがります。
本機の公開時、早期の商品化を期待するポジティブな声を多くいただきました。本当にありがとうございます、スマートキッチングループ関係者はますます奮い立っております。一方残念なお知らせになりますが、現時点でクックパッドが本機を製品化して販売する計画はありません。

本機は、レシピを様々な機器とつなぐスマートキッチンサービスOiCyを実証する一つのコンセプトモデルです。クックパッドの目指しているのは『毎日の料理を楽しみにする』ことであり、クックパッドの進めているスマートキッチンは『人間と機器が協調して調理』することを、スマートキッチンレベルの最高位のレベル5に掲げています。しかし、この取組はクックパッド一社だけで達成できるものではありません。料理をする作り手の皆さん、調理家電を開発販売する電機メーカー各社、キッチンを設計施工するハウスメーカー各社など、多くの関係者の協力があって初めて実現できると考えています。今回、レシピ連動調味料サーバー「OiCy Taste」の設計情報を公開するのは、スマートキッチンのムーブメントを盛り上げ、個人企業を問わず、一緒にスマートキッチンの研究開発に取り組む仲間を増やしたいという意図があります。今回公開された情報の利用に制限はありませんので、個人企業で本機のコピー機を開発するなり改良機を開発していただいてもなんの問題もありません。むしろウェルカムですので、その時は一報をいただけるとありがたいです。

免責事項:公開された情報を利用して開発製作行為をした結果生じたトラブルや損失・損害等について、当方は一切責任を問わないものとします。

OiCy Tasteのシステム構成

f:id:ymmttks:20180911143612p:plain
OiCy Tasteのシステム構成

調味料サーバー「OiCy Taste」は、本体上のボタン操作によって選択された調味料を設定量出すことができます。また、スマホのアプリ操作やスマートスピーカーの音声入力を用いて本体に触れることなく調味料を出すこともできます。このような本機のシステムは、上図の構成で実現されています。 本機は、ボタン操作やWiFiコマンドにより指定された調味料を指定された量だけ出す様になっています。本体側には非常にシンプルな機能しか持っておらず、複雑な情報処理(レシピ情報から調味料の決定や分量計算、音声操作のための音声認識など)は、スマホアプリやクラウドサービス側で実装されています。そのため、調味料サーバー「OiCy Taste」本体には高度な情報処理を行うプロセッサや高度な認識認証を行うセンサ類は不要で比較的低コストに実現可能な構成になっています。

OiCy Tasteのハード構成

f:id:ymmttks:20180911143603p:plain
OiCy Tasteのハード構成
調味料サーバー「OiCy Taste」のハード構成は上図のようになっています。 4種類の液体調味料が独立した4本のガラスボトルに封入されていて、4つの独立したポンプでボトル内を加圧し液体調味料を押出してノズルから排出します。各ボトルとポンプをつなぐ空気流路は三股になっていて電磁弁が取り付けられています。この電磁弁は、調味料を出し終わった際にボトル内の気圧を大気圧レベルに戻せるようにするために取り付けられています。この電磁弁がないと、ボトルとノズルの間のチューブに液体調味料が残ってしまい、ノズルから残った調味料が垂れてきたりチューブ内で調味料が固まり流路閉塞をおこすなどトラブルの原因となります。
排出される調味料の分量は、ロードセルを用いて重量変化をフィードバック制御し管理されています。調味料の配合は、レシピ上で少々(=小さじ1/8、1g未満)と記載されるレベルの精度が要求されます。開発初期段階では、単純にポンプの駆動時間によるオープンループ制御も検討されていましたが、要求される精度を実現することが困難で、電磁弁を用いたボトル内気圧の減圧機構が追加されました。イメージビデオでは、4つの調味料が同時に出ている映像が流れますが、これは電磁弁をつける前の状態で、現在の仕様では重量計測が配合調味料を受ける容器一箇所で行われている都合上、複数の調味料を同時に出すことができません。安価な非接触の液体流量センサーなど、いいセンサー情報をお持ちの方は是非教えていただければと思います。 なお、4つの液体調味料は、醤油、みりん、日本酒、お酢が選ばれています。これは、クックパッドに投稿されたレシピとそのアクセス頻度などのデーターベースを活用し、最もよく利用される調味料の組み合わせとして選ばれています。
以下が、本機で使用した主要な機構部品と本体メカ部品の3Dデータ(STEP形式)です。一部の機構部品については現在入手が困難になっているものもありますので参考情報になります。また、3Dデータは重量センサーのロードセル対応前かつ電磁弁改良前の仕様になっています。

主な機構部品

OiCy Tasteの3Dデータ

OiCy Tasteの電子回路構成

f:id:ymmttks:20180911143645p:plain
OiCy Tasteの電子回路構成
調味料サーバー「OiCy Taste」の電子回路構成の概要は上図のようになっています。以下、各ブロックごとに解説していきます。実際の回路図は下にリンクしています。

①マイコンボード

機体の制御は、電子工作等でおなじみのESPr® Developer(ESP2866)ボード(以降、ESPrボード)を使用しています。WiFi通信をする装置をプロトタイピングするにあたって、ESP8266や後継のESP32は低コストで導入できる最有力のマイコンボードだと思います。ただし、電源周りで苦労することが多いデバイスですので電源回路の設計、評価に注意が必要です。

②I/O拡張

スイッチやLEDなどのUI周りは、マイコンボードからSPIインターフェイス接続によりSPI I/O ExpanderのMCP23S17を用いて拡張します。マイコンの接続されるI/Oのうち入力は、『醤油』、『みりん』、『料理酒』、『お酢』を選択する4つのボタン入力、調味料を出す『出す』ボタン入力、分量切り替えと調味料を出す操作をするジョグダイヤルで3個の入力が必要で、合計8の入力ポートになります。出力は、『醤油』、『みりん』、『料理酒』、『お酢』の選択対象表示をするLEDが4個、ジョグ操作で切り替えられる調味料の量を表示するLED(小1、小2、大1、大2、大3、大4、連続)が7個、通電状態及びWiFi接続状況を表示するLEDが1個が必要となり、合計12の出力ポートになります。従って、入出力合わせて20個のI/Oが必要になるためマイコンボード単体のI/Oが不足します。そこで、SPI接続可能なMCP23S17を使ってI/Oを拡張するわけですが、MCP23S17で拡張できるI/Oポートは16個のためこれでもポートが不足します。そこで、調味料の出す量を表示するLEDは同時には一つしか点灯しませんので、デコードICの74HC138を使って3bitのI/Oから7個のLEDを制御してポートの不足を補っています。

③モータードライバ

ポンプの駆動は、I2C接続式のモータードライバIC DRV8830を用いています。ポンプのモーターを駆動する場合はモーターの回転方向を制御できる必要はないのでこのようなモータードライバICは必須ではありませんが、I/Oポートの数が限られている中で、DRV8830を使うと複数のモーター(ポンプを)I2Cバス最大9個までぶら下げて個別に回転数を制御できます。もともとは、複数の調味料を同時に出すことを想定して、各ボトルごとに独立したポンプをもたせる設計になっていました。しかし、重量センサーによるフィードバック制御で調味料を高精度に出すようになったことから同タイミングで複数のボトルから調味料を出せる必要性はなくなり、ポンプと電磁弁のコストバランス次第ではポンプを1つにして複数電磁弁による流路切り替えにしたほうが良いかもしれません。抜本的に再設計をする機会があれば、ぜひとも再検討したいところです。

④電磁弁駆動回路

電磁弁は、マイコンボードのI/OポートからFETを介して直接駆動しています。4つの電磁弁を1つのI/Oポートで駆動している回路の都合上、4つの弁は同じタイミングでしか開閉できません。このあたりは、設計データを見渡した際に「なんでこんな微妙な仕様になっているんだろう?」と気がつくところです。なんのことはない、開発の途中で必要になって追加された機能でポートが空いてなかったという話で、ハードウェアの試作開発ではよくある話です。リバースエンジニアリングで設計の時系列を読み解くのが楽しいのはこういう発見があることだと思います。

⑤アナログ回路

アナログ回路部分では、ひずみゲージを用いた重量センサーであるロードセルの出力、増幅、A/D変換しています。ロードセルは非常にデリケートなセンサーデバイスですので、信号はインスツルメンテーションアンプを用いた差動増幅で行っています。この出力を原点調整機能付きのヴォルテージフォロアを介して、I2C出力の12bit ADCにてアナログデーターをデジタル化します。この回路ブロックは、非常にノイズに対してセンシティブなため、基板回路設計において十分なノイズ対策を擦る必要があります。回路図を見るとわかりますが、当初はこのアナログ回路の電源は①のマイコンボードから供給される3.3Vのデジタル電源と共用になっていましたが、WiFi通信をするとこのESP2866のマイコンボードは電源電圧が暴れるためアナログ回路の電源が振られるという最悪の状態になってしまいます。そこで、アナログ回路は電源に自前のLDOを抱える仕様に変更されました。

主な電気部品

OiCy Tasteの回路図(改修指示含む)

OiCy Tasteのファームウェア

本機のファームウェアは、Arudino IDEで開発されています。組み込み系のプロトタイピングツールとしてすっかり定着したArudino IDEですのでESP8266向けの開発環境構築に関する説明は他の詳細に解説しているサイトを参照してください。一般的なArudinoのコードのように、setup()関数で周辺デバイスの初期化処理と内部変数の初期化を、反復的に呼び出されるloop()でメインの処理を行っています。メインループでは、HTTPリスクエスト(WiFiコマンド)の処理と物理UIボタン操作から、実行するべき操作を抽出し、動作に反映させるという処理を行います。このメインループとは独立に、モーターや電磁弁、重量センサーなどリアルタイムに処理する必要がある部分がタイマーtimer0_ISR()により10ms周期(100Hz)で制御されます。 また、使用しているライブラリのバージョンアップによって、以前動いていたプロジェクトファイルを再ビルドするとビルドは通ってファームウェア更新はできるけれども実機で正しく動かなくなるという現象が起こります。このあたりはOSSを使っている場合に避けられない問題ですが、スマートな管理解決方法を教えていただきたいところです。 以下が、本機のソースコードになります。元々公開を前提としていないプロトタイプ検証用のソースコードですので、アドホックな実装な部分が多々あるところはご理解とご容赦をお願いします。

OiCy Tasteのファームウェアソースコード

公開設計情報のGitHubリポジトリ

https://github.com/cookpad/oicy-taste

おわりに

本エントリでは、コンセプトモデルレシピ連動調味料サーバー OiCy Tasteについて設計情報の解説をさせていただきました。
8月9日のプレスリリースで、レシピを様々な機器とつなぐスマートキッチンサービスOiCyのパートナー企業10社を発表しましたが、クックパッドでは「OiCy」と連携した製品やサービスの実用化をパートナー企業様と協力してすすめていきます。今後も、「毎日の料理を楽しくする」コンセプトモデルを開発公開していきますのでご期待下さい。

最後に、クックパッドの研究開発部では、「毎日の料理を楽しみにする」ためのスマートキッチンデバイスを開発提案する仲間を募集しています。 ご興味がある方は採用ページを是非ご覧ください。ご連絡をお待ちしております。

中途採用:プロトタイプエンジニア(ハードウェア)

OiCyサービス(開発中)の裏側 〜レシピのMRR化〜

f:id:ShinyaOhtani:20180907180851p:plain
Smart Kitchen Summit Japan 2018での様子 : 左からクックパッドの住、金子、大谷(私)

こんにちは、研究開発部のスマートキッチングループの大谷です。 私はスマートキッチンサービス"OiCy"の進むべき方向を考えつつ技術に落とし込む役割を担ってます。 その過程で見つかった大きな技術課題レシピのMRR化(Machine Readable Recipe)について紹介いたします。

レシピのMRR化

先日Smart Kitchen Summit Japan 2018でクックパッドはスマートキッチンレベルを発表しました。 スマートキッチンレベルは、人間がすべての調理タスクを実行するレベル0から始まり、レベルが上がるにつれキッチンの機器から人間への支援の度合いが増え、レベル4では全自動、そして最高位のレベル5では人間と機器が協調して調理できると定義しています。

クックパッドでは、OiCyサービスを通じて最高位のレベルである「人間と機器が協調して調理できるスマートキッチンの世界」を実現しようとしています。

f:id:ShinyaOhtani:20180907174003p:plain
スマートキッチンレベル : レベル5

人間と機器が協調して調理できるスマートキッチンを目指すためにまず越えなければならない課題のひとつは、 レシピを機器が理解できるように機械可読性の高いレシピ(Machine Readable Recipe)に変換すること、 すなわちレシピのMRR化です。

人間が読むのに適した現在のクックパッドレシピのままでは、機器がガスコンロの火力すら読み取ることが困難であり、 人間と機器が協調して調理することなど到底できません。 そこでクックパッドではOiCyサービスを通じてレシピをあらかじめ構造化し機械が解釈しやすい状態にしたレシピを提供しようとしています。

f:id:ShinyaOhtani:20180907174528p:plain
OiCyサービス : レシピを機器が読める形式にして提供 (開発中 2018/08現在)

人間と機器が協調するスマートキッチン

さてそれでは将来のスマートキッチンの機器がレシピから読み取りたい情報とはどのようなものでしょうか。 整理するために料理の基本工程を書き出してみます。

f:id:ShinyaOhtani:20180910124514p:plain:w400
調理工程

他の分類もあるかもしれません。分類の方法はさておきこのように料理工程を書き出してみると、 将来、人間と協調しながら動作してほしい機器は多岐にわたることがわかります。 また機器が多岐であるため、機器が必要とするレシピ情報は更に多岐にわたることが想像されます。

例えば近い未来のコンセントモデルとしてクックパッドが発表したOiCy Tasteが行っている「下処理::下味::調味料をあわせる」では 一度に利用する調味料の種類分量をレシピから読み取ることが求められますし、 また、現代の調理機器の代表格である「本処理::加熱の種類::レンジ加熱」では、 レンジの出力(600Wなど)や時間、電子レンジに入れる材料などをレシピから読み取ることが求められるでしょう。

このような情報をすべて手作業で読み解いて準備することはレシピの数から考え現実的ではありません。 クックパッドでは自然言語処理等を使った自動化を検討しています。

調味料サーバ用途の情報抽出

f:id:ShinyaOhtani:20180907174218p:plain:w300
材料欄

クックパッドのレシピの材料欄の記入は自由度が高いため、「醤油」でも「しょうゆ」や「しょう油」と様々な記述ができます。 また一行に「醤油・みりん・酒・酢」 : 「各大さじ1」などという記述がされていることもあります。 漢字・平仮名や意味の同じ別表現を正規化されたひとつの表現として扱うにはこの記事 で触れている技術を使って機器が読み取りやすい形に変換するようにしています。

あとは一行に「醤油・みりん・酒・酢」と記載されているような特殊ケースや、 「大さじ1」や「大1」など非常に豊かな多様性ある表記の多い単位部分の扱いも難しいところだったのですが、 いくつかのルールを用意することで調味料サーバOiCy Tasteでは9割以上のレシピで正しく動作するようになりました。 エラーケースとしては人間でも理解に苦しむ「オイスターソース : 小さじ1・1/2」などが残っています。 初期検討段階なのでルールベースで処理していますが、この辺は随所で今後機械学習の視点を入れて更に高性能にしたいところです。

少し余談ですが初期検討段階で意識すべきは、課題がざっくりとどのくらいの難易度で、 どんな前処理でどのくらい問題が簡単になるのかといった課題の特徴をクイックに発見することにあると考えています。

そのため初期検討段階では性能を追い求める作業はしません。かわりに性能評価のためのアノテーションと評価環境を作ることは必須であり、時間を割いて構築しています。 性能評価環境と課題の特徴に関する知見さえあればあとで機械学習などを使ってじっくり性能向上を図ることもできます。

電子レンジでの温め用途の情報抽出

f:id:ShinyaOhtani:20180907174006p:plain:w300
各ステップの文章

現代の調理機器の代表格である電子レンジについても情報抽出を試みてみました。 ルールベースの自然言語処理でレシピの各調理ステップの文章から、電子レンジを使うステップなのかどうかの判別は精度95%、再現率100%の性能であることがわかりました。

  • 例:

スープ皿に水、コンソメ、玉ねぎを入れラップをします。500Wで5分、ひっくり返して皿に7分

  → use_microwave

また同様にルールベースの自然言語処理で電子レンジの設定(ワット数と時間)や電子レンジにかける対象物を認識させてみましたところ、設定: 精度90% 再現率95%, 対象物: 精度81% 再現率85%の性能でした。

  • 例:

スープ皿に水、コンソメ、玉ねぎを入れラップをします。500Wで5分、ひっくり返して皿に7分

  → [500W, <300sec, 420sec>, 水+コンソメ+玉ねぎ]

MRR化の今後

将来のスマートキッチンの機器が必要とする情報は、それぞれバラバラのMRRとして用意されるのではなく、 理路整然と構造化され、情報が増えても理解しやすい構造に保存されます。詳細は述べませんがMRRは面白い構造をしています。

まだまだ情報抽出課題は山のように残っています。 もしMRR化やクックパッドの研究開発に興味がある方はぜひ私達と一緒に開発してみませんか?

データドリブンでユーザー体験を改善する試み

こんにちは。サービス開発エンジニアの出口貴也 (@dex1t) です。
私は4月までユーザーファースト推進室にて、ユーザー体験の数値化や、その下地作りに取り組んでいました。まだ模索段階ではありますが、本エントリにてこの試みの現状をご紹介します。

点だけでなく線も検証する

リーンスタートアップのBMLループに代表されるように、サービス開発において、検証のフェーズは非常に重要です。 クックパッドでも、開発と検証はセットで考えられており、施策の良し悪しを指標から判断することは日常的に行われています。

ただ同時に、施策単体の検証だけでなく、施策を実施した結果、サービスを通してユーザーが得る体験がどうなったかを検証することも重要です。 クックパッドで言えば、「レシピを探す」機能 (点) だけを改善するのはもちろん、その前後関係を含め「レシピを探し、レシピを決め、作ってよかった!と思えた」という一連の体験 (線) の達成度合いも検証する必要があると言えます。

このような、サービスを通してユーザーが得た体験を、数値化し検証することは難しいものです。クックパッドではこれまで、ご意見ボックスを設置するなどして、定性的なデータを元に判断してきました。 しかしモバイルアプリを提供する機会が増えるにつれ、サービスを機能として捉えるのではなく体験として捉え、エンジニアもデザイナーも数値を武器にしつつ、機能やUIをデザインし開発をしていくことが、これまで以上に重要になってきました。

ユーザー体験をストーリーとして定義する

ユーザー体験を検証するにあたって、まずはサービス開発者が、どのような体験をユーザーに提供したいのかを定義する必要があります。これをユーザーストーリーと呼びます。

クックパッドでは、新しくサービスを企画する際に、アプリケーション定義ステートメントシートと呼ばれる企画フレームワークをよく使います。このシートのなかに、ユーザーストーリーも項目として含まれています。これにより、サービスを企画する際には、ストーリーについて考える機会が生まれます。アプリケーション定義ステートメントシートの詳細については、こちらのエントリで触れられていますので、ぜひご覧ください。

ここでは、以前私が企画・開発を担当していた、iOS版みんなのカフェのユーザーストーリーをご紹介します。 みんなのカフェは、食や暮らしの話題を中心とした掲示板です。その中で、「のんびり時間をつぶしたいユーザー」のストーリーとして以下を定義しました。

  1. 家事の合間にほっと一息。面白そうなスレッドを読んで時間を潰そうと思う
  2. 特に目的は持たずに、スレッド一覧から気になる話題を探してみる
  3. 気になったスレッドの内容、レスを見る
  4. わかる!確かに!と共感する
  5. まだ時間があるので他のスレッドも探してみる

f:id:dex1t:20150610163604p:plain

ユーザーストーリーの達成状況を測る

ここからは先ほど定義したユーザーストーリーの達成状況をもって、ユーザー体験の検証を行っていきます。

ユーザーの行動を測るためのツール

クックパッドでは、ユーザー行動を計測し分析するためのツールとして、Mixpanelを新規アプリを中心に導入し始めています。 この手のツールとしてはGoogle Analytics (以下, GA)が一般的ですが、GAは多くのユーザーの行動を俯瞰的に捉えることを得意とする一方で、ある特定のユーザーがどんな行動を取っているのかを捉えることは不得意です。 Mixpanelは、このGAのデメリットを補完する役割として併用しています。 またMixpanelの利点として、イベントトラッキングをファネル分析やリテンション分析と連携することが容易な点が挙げられます。

なお、ここからはMixpanelについての言及が多くなりますが、Localyticsなど他のツールも同等の機能を備えており、Mixpanelに限った内容ではありません。

Mixpanelでファネル分析

ユーザーストーリーは、ユーザーがサービス内で行う複数の行動から構成されるものです。この行動 (イベント) の発生を、Mixpanelでトラッキングしていきます。

例えば、先ほどのユーザーストーリーであれば、以下のようにストーリーをアプリ内の行動に近似します。

  1. 家事の合間にほっと一息。面白そうなスレッドを読んで時間を潰そうと思う
    • [行動] アプリを起動する (Open App)
  2. 特に目的は持たずに、スレッド一覧から気になる話題を探してみる
    • [行動] スレッド一覧を一定量スクロールする (Find Topic)
  3. 気になったスレッドの内容、レスを見る
    • [行動] スレッド詳細画面に遷移する (View Topic)
  4. わかる!確かに!と共感する
    • [行動] Likeボタンを押す / レスを投稿する (React)
  5. まだ時間があるので他のスレッドも探してみる
    • [行動] スレッド一覧画面に戻り、一定量スクロールする (Find Topic)

そして、これら一つ一つの行動をファネルと捉え、その達成状況をファネル分析することで、ユーザーストーリーの達成状況が計測できます。例えば、このストーリーをファネル化したものが以下です。

f:id:dex1t:20150610163826p:plain 注: 図中の値は、実際の値とは異なります

この例だと、CVR 42.0%という数字が、このストーリーの達成状況となります。

最重要指標を決める

Mixpanelのようなツールを導入すると、ついついあらゆるボタンのクリック数を測りたくなってしまいます。 クックパッドでは、GAとの使い分けとして、Mixpanelはユーザーストーリーの達成状況を計測することに限って使うことにしています。

また1つのサービスには、複数の登場人物が存在することが多々あります。例えばみんなのカフェで言えば、暇つぶしに色々なスレッドを閲覧したいユーザーのほか、食に関する疑問があり質問を投稿しようと思っているユーザーなど、モチベーションの異なる複数のユーザーがアプリ内に混在します。そして、そのユーザーそれぞれに利用ストーリーが考えられます。

全ての登場人物のストーリーを追うのは難しく、それを目指すと数値に溺れるような感覚になりがちです。そのため、サービスが成長する上で、現段階で最重要となるストーリーに絞って、達成状況を測ることが重要になります。

みんなのカフェであれば、新規に立ち上げたコミュニティであるため、まずはスレッドを投稿してもらうことが最重要だと考えていました。そのため、まずはPVや回遊率ではなく、スレッドの投稿数を重要指標としていました。したがって、先程の例で言えば、「食に関する疑問があり、質問を投稿しようと思っているユーザー」に関するストーリーの達成状況を最重要視していました。

このような考え方は、Lean AnalyticsのなかでOMTM (One Metric That Matters)と呼ばれています。また同様の考え方がMixpanelの設計思想にも現れており、Mixpanelのヘルプページでも重要指標のみに集中せよとあります。そのため、このような考え方のもとで使うツールとして相性が良いと考えています。

iOS版みんなのカフェでの改善例

以上のような考え方に沿って、実際に数値ドリブンでユーザー体験の改善を行った、iOS版みんなのカフェの事例をご紹介します。

先にも述べましたが、iOS版みんなのカフェでは、コミュニティというサービス特性上、アプリ起動からスレッド投稿にいたるまでのユーザーストーリーの達成状況を、最重要視していました。 実際にスレッド投稿を行うためには、大きく分けてユーザーに以下のような行動をとってもらう必要があります。

  1. スレッド投稿ボタンを押す
  2. カテゴリーを選択する
  3. スレッド内容を入力する
  4. スレッドを投稿する

f:id:dex1t:20150610163918p:plain

ここでMixpanel上で、投稿ボタンを押してから投稿が完了するまでのファネルを作ってみると、以下のようになります。

f:id:dex1t:20150610163937p:plain

ここで気になるのは、最初のステップです。投稿ボタンを押してから、カテゴリーの選択を完了したユーザは、全体の58%しかおらず、約42%のユーザーがここで離脱してしまっています。 カテゴリーを選択するだけのシンプルな画面にもかかわらず、離脱率が高いことから、改善の余地がありそうです。

そこで、改善するための仮説として以下を考えました。

  • 投稿する気持ちが高まっているユーザーに対しては、カテゴリー選択画面よりも入力画面を最初に出したほうが、ユーザーの期待に沿っているのではないか
  • 文章を入力する前から、これから入力する文章のカテゴリーを選ぶのはそもそも難しいのではないか

この仮説のもと、カテゴリー選択画面と、スレッド内容入力画面を入れ替えてみることにしました。これにより、以下のようなフローになりました。

f:id:dex1t:20150610164000p:plain

そして、再びファネル分析をおこなった結果が以下です。仮説通り、入力画面からカテゴリー選択画面への遷移での離脱は少なく、全体のCVR (投稿ストーリーの達成率) も向上しました。また、念のため検定にかけてみると、有意な差がみられました。

f:id:dex1t:20150610164016p:plain

ここでご紹介した事例は、かなりシンプルなものですが、Mixpanelでファネル分析を行いつつ、ユーザーストーリーの達成状況を改善していく雰囲気を感じていただければと思います。

特に、今回のような分析は、あえて専門のツールを使うまでも無いかもしれません。ツールを使ったからといって、これまで分からなかった何かが分かるわけではありませんし、仮説を立てるところこそ、サービス開発者の頭の使い所です。 Mixpanelのようなツールを使うことで、分析が手軽にわかりやすく可視化され、仮説を立てやすくなり、その結果サービス開発のスピードがあがることに価値があると思っています。

まとめ

本エントリでは、ユーザー体験をストーリーとして定義し、その達成状況を計測し改善するための試みについてご紹介しました。実際には本エントリのようなアプローチだけで、ユーザー体験の検証が十分かと言えばそうではなく、インタビューやユーザーテスト、開発者自身によるドッグフーディングなど、他の手法と組み合わせることが重要だと考えています。

UXというとデザイナーの仕事のように思われがちですが、UXはデザインだけでなく、エンジニアリングも含めて成り立つものです。個人の感覚だけに頼るのではなく、チームの共通認識として重要指標を決めることで、エンジニア, デザイナー, ディレクターが一丸となってユーザー体験の向上に取り組むことができるのではないかと思っています。このようなサービス開発にご興味がある方は、ぜひエンジニア・デザイナー採用にご応募ください!