入力時間11%減!書きやすいエディタのUIデザイン

こんにちは、投稿開発部の佐野大河(@sn_taiga)です。 先日、クックパッドのiOSアプリでレシピのエディタ画面をリニューアルしました。今日はそのUIデザインの設計についてお話します。

方針は「簡素化」

エディタ画面は、レシピを考えて記録・投稿する人にとって重要な機能の一つです。レシピには材料や作り方、料理写真、タイトル、紹介文などさまざまな項目があり、頭の中にある料理をこれらの形に落とし込んでいくのはなかなか大変な作業でもあります。なので、レシピを書く際の手間を減らし、ユーザーがストレスなくレシピを書けることを目的に「簡素化」という方針を定め、改善に取り組みました。具体的に行ったことは大きく以下の二つです。

1.入力や編集のステップを少なくする

以前のエディタ 新しいエディタ
f:id:sn_taiga:20190329095727g:plain:w300

以前のレシピエディタはひとつの項目を選択するとモーダルが開き、入力を終えたら元の画面へ戻ってくるウィジェット型のUIでした。これはこれで、一つの項目に集中でき、シンプルな画面から徐々に要素を埋めていくため圧迫感が少ないというメリットがある一方、レシピを書き上げるまでのステップは多くなります。今回このウィジェット型から、一画面で入力・編集を完結できる「インライン型」のUIに変更し、各項目の入力の行き来をしやすくサクサク書き進められる構成に変更しました。

2.入力をアシストする

(A)作り方から材料の自動入力 (B)タイトルから材料のサジェスト (C)分量の単位補完
f:id:sn_taiga:20190328220514p:plain f:id:sn_taiga:20190328220534p:plain f:id:sn_taiga:20190328220553p:plain

新しいエディタでは、レシピを書く人の入力をアシストする機能を充実させました。 料理の作り方を書いたら自動で材料欄が入力されます(A)。例えば「鮭を一口大にカットし、玉ねぎをスライスしておく」と書いたら材料欄に「鮭」と「玉ねぎ」が追加されます。 先にタイトルを入力すれば、その内容から材料を予測しサジェストもしてくれます(B)(こちらは研究開発部の機械学習の技術を用いて予測しています。予測のモデルについてはこちらの記事で紹介されていますので興味がある方はぜひ読んでみてください。) また、入力されている材料名から適切だと予測される単位を、分量の入力中にサジェストしてくれます(C) 。

このように「簡素化」という目的に対して「インライン型」「入力アシスト」という手段を用いた中、UIを設計する上での"デザインの方針"を定めました。どのような方針で、具体的にどういう工夫をしたのかについてここからはお話します。

入力量に圧倒されないように

ウィジェット型からインライン型にすることによって入力や編集の行き来がしやすくなる一方、画面内の情報量が増えます。元のUIをそのままインライン型に変更すると、画像のような文字量の多い入力フォームになり、ユーザーが画面を開いたときに「うっ、大変そう...」とレシピを書くハードルを高く感じてしまう危険性があるためこの方針を定めました。

f:id:sn_taiga:20190328220420g:plain:w300

具体的に行ったことをいくつか紹介します。

入力エリア、見出し、プレイスホルダーの同居

f:id:sn_taiga:20190328220720g:plain:w300

各項目の要素は入力エリア、見出し、プレイスホルダーの3つです。自分が今何を入力しているのかわかるように見出しは入力中も表示しておく必要があり、プレイスホルダーは「こういうものを書けばいいんだ」と理解するための手助けになります。ただ、これら3つを常に同時に表示しておく必要はないと考え、初めは入力エリアに重ねる形で見出しのみ表示し、フォーカス時に見出しを上側に移動させプレイスホルダーを表示するようにしました。これにより画面全体の文字量や高さを抑え圧迫感を減らすだけでなく、フォーカス前と後の状態をアニメーションでシームレスに繋ぐことで視覚的な負荷も軽減させました。

スケーラブルな入力エリア

f:id:sn_taiga:20190328221756g:plain:w300

レシピの紹介文やコツポイントといった長めの文章を書く箇所は、入力したテキストの行数に合わせて高さが変わるようにしました。高さを固定させる場合は、決めである程度の領域を確保しなければならず、テキストをあまり書かない人にとっては余分なスペースに、たくさん書く人にとっては狭いスペースになるのに対し、入力量に合わせて変化させることで必要十分な領域にすることができました。

入力中の項目に集中できるように

どこにもフォーカスしてないときは、入力されたテキスト以外は全体的に薄いグレーの配色で、最低限項目を認識できる存在感にし(入力可能な項目だとわかるように見出しの横に鉛筆アイコンを置いています)フォーカスした箇所のみをオレンジ色で強調し対象に集中しやすくしました。

f:id:sn_taiga:20190329091909g:plain:w300

元のUIをそのままインライン型にしたものと比べて画面全体の圧迫感が軽減しました。

自分の手で書き上げているように

入力のアシスト機能は便利になり得るものですが、タイミングや見せ方次第でユーザーの作業の妨げにもなりかねません。レシピを書く一連の流れに溶け込み余計な混乱を招かず、あくまでユーザー自身がアシスト機能を使いこなしながら「自分の手で書き上げた実感」を得られるようにとこの方針を定めました。

自動入力されたものをハイライト

f:id:sn_taiga:20190328224428g:plain:w300

作り方から自動入力された材料には背景色が付き、材料にフォーカスするか分量を入れるかすることで色が消えます。作り方はユーザー自身が書くものでもあり予測の精度はある程度高いためサジェストではなく自動入力という形で表示しているのですが、このような見せ方にすることで「自動で入力されたものだけど最終的にそれを採用するのは自分」だと思えます。

タイトルから材料のサジェストのタイミング

材料予測の通信が行われるのはタイトルを入力したときですが、このタイミングではサジェストせず、ユーザーが材料を入力する際に視界に入る位置に置いています。

タイトル入力直後にサジェスト(不採用) 材料欄の上でサジェスト(採用)
f:id:sn_taiga:20190328222001g:plain f:id:sn_taiga:20190328224423g:plain

タイトル入力直後のサジェストは、自分のアクションに対するフィードバックが明確で驚きが生まれやすい一方、サジェストされた材料を追加したらそのまま足りない材料の入力へ移りたくなります。これはユーザーのエディタの使い方を制限することになっていて、レシピをタイトルから書き始める人もいれば作り方から書き始める人、材料から書き始める人、全部を一気に書いて最後に微調整する人など様々な人がいます。どのような書き方の人でもエディタの使い方を制限されることのないように、材料欄の上でサジェストするUIを採用しました。材料より先に作り方を書く人も上述の補完の恩恵を受けやすくなります。

f:id:sn_taiga:20190328224006g:plain:w300

また「使っている材料はこちらですか?」という投げかけのテキストと顔アイコンを置き、クックパッド側が提案してる風にすることで、ユーザーがサジェストの棄却をしやすいようにしました。合っている材料を追加したあとは右上の×ボタンからサジェスト自体を閉じることができます。

投稿にかかった時間11%減

今回、エディタの「簡素化」という目的に対し「レシピを書き上げるまでにかかった時間」を指標の一つとして置きました。ここまでの改善を行いリリースした結果、リニューアル前のエディタと比べて平均11%の減少率が見られました。画面全体の構成の変更やアシスト機能の追加によって、リニューアル前のエディタに比べて手間が少なくサクサクレシピを書き上げることができるようになったと言えます。

まとめ

具体的なUIを設計していく際に、目的を最大限達成するために何が重要なのか、ユーザーにどう感じてもらうのが良いのかを「デザインの方針」として言語化しておくことで、狙いから逸れることなくUIを設計できました。個人的にUIを作っている最中はついあれもこれもと横道に逸れがちなのですが、あらかじめ方針を定めておくことで、なぜやってるのか、何を狙っているのかでブレることなくUIの案出しや判断がしやすくなります。

最後に、クックパッドでは「より良い体験をユーザーに届けていきたい!」というメンバーを募集中です。興味を持っていただけた方は採用ページをご覧ください。

【RubyKaigi 2019 参加者に捧ぐ】福岡で起業した男が本気で書いた福岡グルメまとめ

f:id:kazzwatabe:20190319180852j:plain

CEO室で新規事業立ち上げをやりつつ、昨年子会社になりましたウミーベ株式会社の代表取締役をやっているカズワタベ(@kazzwatabe)です。

さて、来月には待ちに待った RubyKaigi 2019 が開催されるんですが、クックパッドもRuby Committers' Sponsorとして関わっていたり、たくさんのエンジニアが現地参加するようです。

そんな RubyKaigi 2019 、今年の会場はウミーベが拠点とする福岡! そして福岡と言えば飯が美味い。これは他県から訪れる社内外のみなさんにグルメ情報を提供せねばという思いから、非エンジニアにも関わらず開発者ブログに登場する運びとなりました。

RubyKaigi 2019 に限らず、福岡を訪れる機会があったらぜひ行って欲しいお店ばかりなのでよかったら参考になさってください。

目次

海鮮

福岡では国内有数の漁場である玄界灘の海の幸が楽しめます。鮮度の高い刺し身を、甘み、旨味の豊富な九州醤油で食べるのがおすすめ。また、九州では関東では馴染みの薄い生のサバをよく食べます。特に胡麻だれに和えた「胡麻サバ」は絶品なのでぜひ食べてください。

サバ(きはる、独酌しずく)

tabelog.com

福岡の中でもサバがダントツで美味しいのがこちらの「きはる」。長崎県五島列島のサバを刺し身、炙り、胡麻サバにしていただくことができます。その他に、対馬の穴子の刺し身、天ぷら、焼きサバチャーハンなどがおすすめです。

tabelog.com

きはるが満席の場合は、同じサバが食べれる系列の「独酌しずく」へ。こちらの方が予約が取りやすい印象があります。

イカ(河太郎、表邸)

tabelog.com

佐賀県の呼子の名物である「イカの活造り」を食べれるお店が福岡にもあります。中でも有名店が「河太郎」。透き通ったイカの刺身はもちろん、後づくりとして出てくるエンペラやゲソの天ぷらは絶品です。

tabelog.com

他にイカの活造りが食べれるお店としては「表邸」が挙げられます。こちらは後づくりの天ぷらの衣にイカ墨を混ぜ込むのが特徴的。イカ以外も絶品ですよ。ほぼ全室個室なので、落ち着いた雰囲気で食事を楽しみたい場合におすすめです。

海鮮全般(ふじけん、兼平鮮魚店)

tabelog.com

tabelog.com

海鮮全般を楽しもうと思ったら「ふじけん」「兼平鮮魚店」がおすすめです。どちらも魚屋さんが営むお店で、その日仕入れた生きのいい魚を食べることができます。個人的には以前「ふじけん」で食べたサワラが奇跡的な美味しさだったのでまた食べたいです。

ランチにおすすめ(小野の離れ、梅山鉄平食堂、よし田)

ランチでも海鮮を楽しめるお店がたくさんあります。僕がよく行くのはこちらのお店です。

tabelog.com

僕が「福岡最強ランチ」と呼んでいるのが、こちらの「小野の離れ」。とりあえずヤバいんですが、どうヤバいのかは「小野の離れ ランチ」でググれば分かります。ランチも予約制で、12時スタート、13時半スタートの2回転のみです。予約取れたらラッキーなのでいますぐ電話かけましょう。ちなみに夜は夜でいい店です。

tabelog.com

もう少し気軽に海鮮ランチを楽しみたい方には「梅山鉄平食堂」がおすすめです。その日仕入れたたくさんの種類の魚を、塩焼きな煮付け、唐揚げなどにした定食を食べることができます。

tabelog.com

夜は割烹ですが、ランチはリーズナブルに「鯛茶(鯛茶漬け)」が楽しめるのが「割烹よし田」です。ぷりっぷりの真鯛と胡麻だれ、出汁の相性は格別。こちらも予約可能です。

もつ鍋(やま中、田しゅう、楽天地)

福岡の名物のひとつが「もつ鍋」。ぷりっぷりのもつに旨味たっぷりのスープ。ちゃんぽん麺や雑炊で〆まで楽しむことができます。がっつり食べたい方におすすめです!

tabelog.com

「やま中」は地元の人が観光客をよく案内する、高級もつ鍋屋の代名詞です。すでに行ったことがある方もいそうですね。

tabelog.com

やま中に負けず劣らず、より安く味わえるのが福岡で一番好きなもつ鍋屋が「田しゅう」。清潔感のある店内で、女性のみのグループもよく見られるのが特徴です。みそ味からのチーズリゾットで〆るのがおすすめです。

tabelog.com

最後に安く済ませたいときに使えるのが「楽天地」。食べ放題・飲み放題でもリーズナブル。ぷりぷりというよりは、コリコリしたもつを使った、B級グルメ感のあるもつ鍋の定番です。こっちはこっちで美味しいんですよね。

水炊き(とり田、とりぶどう HANARE)

もつ鍋と対を成す福岡名物が「水炊き」。鶏を長時間煮込んだコクのあるスープは絶品です。

tabelog.com

数ある水炊き屋の中でも大好きなのが「とり田」。2店舗ありますが、博多本店の方が広いので予約が取りやすいです。ここのスープは水筒に入れて持ち帰りたくなること間違いなしです。

tabelog.com

以前はとり田ばかり行ってたんですが、最近は「とりぶどう HANARE」もよく使います。焼き鳥の有名店「とりぶどう」の系列です。こちらはハツや砂肝など、一般的には水炊きに入れない部位が出てくるのが特徴。さらに本店の名物「幻の白レバー」も食べることができるんですが、その臭みのなさには驚きです。

焼き鳥(かわ屋、とりかわ粋恭)

tabelog.com

tabelog.com

福岡は実は人口10万人あたりの焼き鳥店店舗数が日本一で、美味しいお店がたくさんあります。中でも有名なのは「とり皮」が名物の「かわ屋」「とりかわ粋恭」の2店です。

少しずつ脂を落としながら、6日かけて焼いたカリカリのとり皮は絶品。人数×5〜10本くらいオーダーするのが福岡スタイル。こちらは会計も1人2〜3000円とリーズナブルです。

ラーメン(ShinShin、海鳴、おいげん、梟)

福岡でおすすめのラーメン屋の話をし始めると宗教戦争が始まるんですが、独断と偏見で選びます。

tabelog.com

週末は行列ができる「ShinShin」はクセの強くない豚骨ラーメンが名物。深夜まで営業しているので〆にも最高です。高菜トッピングがおすすめ。

tabelog.com

ちょっと変化球な豚骨ラーメンが食べたい方におすすめなのが、「ラーメン海鳴(うなり)」。こちらでは魚介とんこつや、豚骨をベースにイタリア風にしたジェノバ味などが楽しめます。魚介とんこつのスープは最後の一滴まで飲んでしまう魔力があります。

tabelog.com

天神から家に帰る途中にあったので、酔って帰る途中によく吸い込まれてたのが「ラーメンおいげん」。ShinShinに比べるとワイルドな豚骨スープが特徴です。炙ったチャーシューの香ばしさも相まって食が進みます。飲みの〆には最高です。

tabelog.com

こちらも〆によく使ってました。担々麺の名店「梟」。朝の5時までやってるのがありがたいです。辛さよりは旨味を感じるタイプの担々麺です。サイドメニューの串ホルも美味しいのでぜひ。

うどん(牧のうどん、釜喜利うどん、弥太郎うどん)

福岡の名物で、県外の人が真っ先に挙げるのはラーメンです。しかし住んでみるとそれ以上に食べる機会が多いのはうどんだということに気づきます。

うどんはコシがある讃岐うどんとは対照的で、柔らかい麺が特徴的。薄口しょうゆと出汁の透き通ったつゆでとても優しい味がします。具材はごぼ天(ごぼうの天ぷら)、丸天(さつま揚げみたいなやつ)が主流です。だいたいのうどん屋にはサイドメニューにかしわ飯(鶏の炊き込みご飯)があるんですが、こちらも美味しいのでぜひご一緒に。

tabelog.com

福岡らしい柔らかい太麺を楽しめるのが「牧のうどん」。福岡のソウルフードです。少し前まで中心部にはなかったんですが、博多駅に店舗ができて行きやすくなりました。麺がスープを吸ってしまうので、追加のスープがやかんが出てきます。

tabelog.com

個人的に一番好きなうどん屋が「釜喜利うどん」。薬院の有名なうどん居酒屋「二◯加屋長介」の姉妹店です(こちらもおすすめ)。スープも麺も具もすべてが美味しくて、今までの人生で食べた中でも一番のうどん屋です。意外と知られてないのですが、肉うどんにの具をご飯に載せた「和牛丼」が絶品なので、一度うどんを食べた人はぜひお試しください。

tabelog.com

福岡で飲み歩いてたら、みんな一度はお世話になっているであろうお店が「弥太郎うどん」。メイン通りである国体道路沿い、24時間営業という利便性は圧倒的です。〆にどうぞ。

その他(天ぷらのひらお、五穀、ヌワラエリヤ、たんか)

tabelog.com

名物ではないけど有名なのが「天ぷらのひらお」。あの味の天ぷら定食が700円ほどで食べれるのは奇跡です。東京だったら1500円でも安いくらいの味と量。テーブルに置いてある、食べ放題のイカの塩辛が隠れた人気メニューです。これが美味しすぎて天ぷら出てくる前に白飯がなくらないように注意が必要です。

tabelog.com

最近ドラマでも話題になった博多の明太子。その明太子をふんだんに使ったオムライスが食べられるのが「五穀」です。ふわふわのオムレツと、生明太子を和えたご飯の相性は抜群。行列必至なので余裕をもって行きましょう。

tabelog.com

住んで初めて知ったんですが、実は福岡はカレー文化が豊かです。中でも足繁く通っていたのが、スリランカカレーの名店「ヌワラエリヤ」。特にライスではなくビーフンを使った「ヌードルカリー」は絶品です。カレー好きの方はぜひ。

tabelog.com

最後になりますが肉系で一番好きなのが「たんか」です。牛タン、牛さがりの串焼きが出てくるんですが、その柔らかさと旨味にびっくり! これは言葉では説明しきれないのでぜひ行ってください。肉ならここです。

まとめ

他にも美味しいお店が無限にあるんですが、パッと浮かんだものを羅列しただけでこの量になってしまいました。福岡は罪深い土地です。RubyKaigi 2019にご参加の方はぜひ食も楽しんでください!

質問などありましたらTwitterで(@kazzwatabe)までお気軽にどうぞ。

福岡で働きたいエンジニア募集しています

また、そんな住環境最強都市福岡で働きたいエンジニアの方を、クックパッドの子会社であるウミーベで募集しております。ご興味お持ちいただけたら、ぜひウェブサイトからご連絡ください!

umee.be

NPSアンケートを自動分類した話

研究開発部に2月18日から3月15日までアルバイトとして参加している岩手県立大学修士1年の橋本(@funwarioisii)です。大学では画像認識について学びを深めています。

本稿では、アルバイトで行ったNPS®アンケート1の機械学習を用いた分類と、その結果を社内で活用してもらうための取り組みについて紹介します。

NPSアンケートについて

クックパッドではイベントやアンケートなどを通じてユーザーからの声を集計しています。その一環として、2年前からNPSアンケートを実施しています。

NPSアンケートはサービス(今回はクックパッド)を他者にオススメするかを調査するのが目的です。アンケートでは必須回答の「スコア」と任意回答の「コメント」を頂いており、スコアは0~10の値を取ります。

この「スコア」が9、10で回答してくださった方を推薦者、7、8で回答してくださった方を中立者、6以下で回答してくださった方を批判者と定義します(下図参照)。

f:id:kazuyuki-hashimoto:20190315174636p:plain

「NPS」の定義は推薦者の割合から批判者の割合を引いた値になります。

「コメント」は実に様々な意見が寄せられます。従業員全員が全て目を通せると良いのかもしれませんが、難しい話です。しかし、サービス改善に役立てられる貴重な声を無視することはできません。

現在は、社内の担当者が分析し社内で報告しています。社内ではこのアンケートをより一層活用したいという気運が高まっていました。私個人としてもユーザーがサービスについてどう思っているのかということに興味があったため、アルバイトで取り組むタスクに定めました。そこで、現在分析に携わっているスタッフとミーティングし、要件をまとめていきました。要件としては以下が挙がりました。

  • 頂いたコメントが何を話題にしているかを分類したい
  • ある話題に関するコメントのNPSの遷移をグラフなどで見たい

「推薦者はどこに魅力を感じているか」「批判者はどこに不満を感じているか」をより定量的な評価が可能になります。また、機能やサービスに関して早くフィードバックを得ることができます。

これまでも「頂いたコメントが何を話題にしているか」についてはルールベースおよび目視で分類してきました。しかし同時に、目視での作業量の多さなどから分類コストが大きいという問題がありました。そこで我々は機械学習によって分類コストを低減しました。

分析とデプロイ

では、NPSに関する課題を機械学習でどう解決したかを説明します。本プロジェクトは分析とデプロイ、二つのステージに分けられます。

ここで分析はコメントがどういった話題に関するものなのか予測するモデルを作成することを指します。 デプロイは作成したモデルをもとにアプリケーションを作成することを指します。ではまず分析でやったことを紹介します。

分析

今回は各NPSアンケートに含まれるテキストがどういった話題に関するものなのか機械学習を使って自動でラベル付けするモデルを作ります。過去に「検索」「レシピの量」など18種類に社内で人手でラベル付けしたデータがあったため、それを教師データとして教師あり学習を行いました。教師あり学習とは、あるデータに対して正解がわかっているとき、モデルがデータをもとに予測できるようにし、未知のデータが渡されたときに正しく予測出来るようにモデルを訓練することです。

構築したモデルを利用して、ラベルの付いていないコメントにラベルを付けます。今回はマルチラベル問題として取り組み、二値分類器を各話題ごとに構築して独立したラベルを付与しました。 このやり方は以前のtechlifeの記事ご意見分類業務と同様です。(下図参照)

f:id:kazuyuki-hashimoto:20190315174630p:plain

文章のベクトル化

まずは、アンケート文章を分かち書きし、ベクトル化します。 分かち書きは、以下のように単語ごとに文章を分割することです。

(元の文)
毎日の料理を楽しみにする。

(分かち書き後)
毎日 の 料理 を 楽しみ に する 。

導入の容易さから分析時点では分かち書きのフレームワークとしてJanomeを選択しました。今回はベクトル化ではTF-IDFを採用しましたが、将来的にfastTextやWord2Vecとの比較も考えています。

分類

機械学習でよく使われるscikit-learnの公式ドキュメントにはChoosing the right estimatorというページがあり、今回モデルの選定に利用しました。具体的には対象となるデータはラベルつきのデータがあり、かつ量が多くないためLinear SVCを選択しました。

ここでデータの内容を見てみましょう。

ラベル 件数
機能 / 検索 251/1143
レシピ/量 341/1143
レシピ/難易度 152/1143
レシピ/味 177/1143
サービス全般/有料 124/1143
サービス全般/ユーザビリティ 45 /1143
サービス全般/役立ち度 463 /1143

上の表は全コメントに対して各ラベルが付与された比率が記述されています。なお、ラベルは1つのコメントにつき複数のラベルが付いていることがあります。サービス全般/役立ち度のように、正例が多い話題(463件)もあります。しかし、50件に満たないラベルもある不均衡なラベルもあります。

分析をし始めた当初、評価指標については、最初はAccuracyを見ていました。 しかし後日になって、社内のNPS担当者はラベル付けされたデータをさらに人手でチェックして、NPSデータを分析することが判明しました。 そのため、Accuracyを評価指標として使うより、関連する可能性のあるコメントを確実にラベル付けができるようにRecallを重視するほうがよいと考えました。 ちょうどscikit-learnにはclass_weightというパラメータがあり正例と負例の重みを調整できるパラメータが提供されています。 今回の実験ではこのパラメータ class_weightを利用してRecallの重みを大きくした場合についても合わせて検証しました。 単純なグリッドサーチを用いた場合とclass_weightを用いた場合の結果を以下の表にまとめます。

ラベル Recall
(GS)
Recall
(GS+CW)
f1
(GS)
f1
(GS+CW)
機能 / 検索 0.7500 0.8064 0.8413 0.8650
レシピ/量 0.7311 0.7999 0.8051 0.8241
レシピ/難易度 0.7804 0.8555 0.8707 0.8750
レシピ/味 0.5420 0.6600 0.6863 0.6000
サービス全般/有料 0.6712 0.6835 0.7967 0.7999
サービス全般/ユーザビリティ 0.4482 0.6071 0.6190 0.7555
サービス全般/役立ち度 0.8507 0.8505 0.8718 0.8868

※GS: GridSearch, CW: class_weight

上の表にはRecallとF1スコアが記述されており、それぞれ、GridSearchのみ、およびGridSearchとclass_weightを組み合わせた結果です。 上の表をみるとラベルによって、性能が出ているものと出ていないものがあるのがわかります。 十分なデータを確保できていないラベルに関しては性能が十分に出せていません。 しかし、自動分類の効果を確認してもらうため、まずは性能の高いラベルについてのみデータを分析者が見られるようにデプロイすることにしました。

デプロイ

前節で、プロジェクトの分析ステージが終わったので、デプロイに取り掛かります。 クックパッドでは研究開発部の各メンバーがデータの分析からモデルのデプロイまでの責任を持ちます(詳しくはこの記事を参照してください)。

今回のタスク、もともとの要件は以下の通りでした。

  • 頂いたコメントが何を話題にしているかを分類したい
  • ある話題に関するコメントのNPSの遷移をグラフなどで見たい

分析が終了しモデルが構築できたので、分類したデータをRedShiftに入れ、担当者が閲覧できる状態にすることを目標とします。

機械学習の結果をシステムに組み込む方法は逐次処理、バッチ処理に分けられます。 今回はリアルタイムに結果が分かる必要はないため、バッチとしてシステムに組み込むことにしました。 クックパッドではHakoというECS上に展開されるコンテナオーケストレーション環境があり、この上に先に構築した機械学習モデルをデプロイします。 システムの全体構成は以下のようになります。

f:id:kazuyuki-hashimoto:20190315174653j:plain
システム構成図

まずDockerコンテナ環境で実行できるCUIアプリケーションにします。 今回の分析ステージではJupyter Labを使いながら分析を進めたので、関数やクラスなどを抽出する作業が発生します。 このときデータ読み出し時のカラム名や前処理後のベクトルの形などに関するテストを順次追加しました。

次にCI上でテストを動作させる設定を追加しました。このときローカルファイルに依存したテストがFailしていたので、順次ファイル依存の問題を解決しました。 また、前処理の速度が気になる問題がありました。そのため分かち書きの処理をJanomeからMeCabに変更する修正も加えました。

次にHako上でアプリケーションとして動かせるようにします。クックパッドでは、バッチを実行する環境はスポットインスタンスを利用する環境と通常のインスタンスを利用する環境があります。 今回はHakoからS3へCSVの転送が途中で止まってもきちんと再実行できる設計にした上で、スポットインスタンスを利用する環境を選びました。

以上の取り組みから、毎月のデータをロード、NPSでの話題を分析し、RedShiftに保存するバッチフローが完成しました。

ここまでの機能を追加したあと、分析担当者に機能の共有をしました。ぜひこの内容を常に見られるようにしてほしいというフィードバックをもらいました。 そこで、より多くのスタッフにNPSのデータに興味を持ってもらいたいと考え、作成したグラフをSlackのボットで月次で投稿するようにしました。

ふりかえり

機械学習をプロダクションに組み込む作業は初めてでした。アルバイトを通じて機械学習の知識だけではなく、システム設計について考える点がたくさんあることがわかりました。

私は修士の学生として在籍している研究室では画像処理に取り組んでいます。 今回、はじめて自然言語処理のタスクを扱いましたが、思っていた以上に楽しかったです。 画像処理では慣れていることもあり、違和感なくベクトル化できますが、言語は一筋縄でいかないイメージがありました。 今回、自然言語処理タスクに取り組んだことで、この分野でも様々なツールが提供されかなり気軽に始められることが分かったのは収穫です。

今回のタスク(NPS)には自然言語の不均衡データという特徴がありました。 画像であれば、少ないデータに対して回転やクリッピングなどのデータオーギュメントを気軽に適用できます。 離散的な値を特徴とする自然言語では大きく意味が変わりかねず、類語を用いた言い換えは容易ではなく、目視で確認する作業が必要です。 このあたりについて、今後調べて見たいと考えています。


  1. Net Promoter®およびNPS®は、ベイン・アンド・カンパニー、フレッド・ライクヘルド、サトメトリックス・システムズの登録商標です。正味推奨者比率などと訳されます。