インターン参加報告:Word2vecによるページ掲載店舗の検索結果とページ生成スケーラビリティの向上

こんにちは。
今年の1月7日から1月18日までの約2週間、Rettyでエンジニアとしてインターンをさせていただきました、ボストン大学3年の小林です。

インターンを終え、大学に戻って約3週間が経ちますが、この冬のRettyでの経験がその後の大学生活に少なからず良い影響を与えていると感じており、また自分自身での振り返り、今後Rettyでのインターンを考えている方への紹介も兼ねて、今回、Retty Tech Blogにインターン体験談を書かせていただきます。

自己紹介

The Social Networkという映画を観たのがきっかけで、現在はFacebookが生まれた地、米国ボストンでコンピューターサイエンスと哲学を勉強しています。ちなみに今学期は、授業としては、関数型言語であるHaskellを入り口としたプログラミング言語の仕組みについての授業、MASONなどを用いたシミュレーションの授業、統計・確率、マクロ経済学倫理学などを取っていて、研究としては自然言語処理機械学習の最適化について、また趣味ではWebサービスやモバイルアプリの開発を行っています。
それ以外に、最近はアートや文学などの芸術方面にも興味が湧いており、将来的にはエンジニアリングやビジネスに留まらず、政治・経済・哲学・文学・芸術など多種多様な領域で動いていきたいと思っています。

なぜRettyなのか

今回インターンに参加した理由としては、Rettyの企業理念である、

食を通じて世界中の人々をHappyに

というビジョンに共感したというところが一番大きいです。日本が世界に誇る文化の一つである"食"という領域を、日本から世界に向けて発信していこうという姿勢は、非常に価値のあるものであると感じます。

また、Rettyの採用ページや過去のインターンに関する記事などを読んだところ、自分のやりたいことや興味のあることに打ち込めるサポート体制が整っており、企業でしか持ち得ない価値のある密なデータをある程度自由に扱うことができる環境であると感じたため、今回短期間ながらもインターンをすることに決めました。

インターン中のタスク

自然言語処理の分野に興味があったので、実際にそれらの技術を使った業務はないかという相談をしました。話し合いの結果、お店まとめサービスである、Rettyテーマページの生成に検索式が必要なのですが、ここにWord2vecが使えそうだ、ということでインターンの方向性が決まりました。

具体的な概要・目的

そもそもなぜこのタスクをやる価値があるのか、ということについてはタスク自体に取り掛かる前に自分の中で明確に言語化しておく必要がありました。今回のタスクの目的を一言でまとめると、

Rettyテーマページ内部の検索式生成の(半)自動化

です。

Rettyテーマページは、以下のようにテーマ (e.g. 渋谷の500円ランチ)とそれに関連するお店のリストから構成されているのですが、このお店のリストを生成するためには検索インデックス(DB)にクエリを投げて条件に合致したデータを取ってくる必要があります。これまではその検索式を手動で書いていたのですが、今後ページ数 (つまりテーマの種類)を増やしていくにあたって、手動では厳しくなりそうということもあり、今回、少なくとも半自動で検索式を生成できる仕組みを考案することになりました。つまり、ページ数を1万から100万にスケールするとなった際に必要となる、スケーラビリティー向上のためのツールであるといえます。

retty.me

今回のタスクの大まかな流れを簡単な図で表すと以下のようになります。

f:id:rettydev:20190218151840p:plain

ツールの選択

手動での検索式生成のもう一つの大きな問題点として、検索したいキーワードがあったとして、検索式を生成する際にはそれに近いキーワードなども推測して含めてあげる必要がありました。
例えば、「和食」というキーワードを考えた際に、それが「寿司」なのか「カツ丼」なのか「懐石料理」なのかといった具合に、そのキーワードの言い換えや具体化をしてあげないと、理想的な検索結果が得られずテーマページ (i.e. まとめページ)の存在価値がなくなってしまいます。
ではどのようにしてそういった近い意味のキーワードを探し出すか、ということ考えたときに一番理想的なのは、ユーザーが言語化できなかったものを補足するようなキーワード群を探すことです。つまり、Rettyが持つ店舗情報やユーザーの口コミを元にそういったキーワード群を推測することが理想的でした。そのため、今回はユーザーからの口コミデータを扱い、周辺語生成のツールとしてWord2vecを用いることにしました。

Word2vecについて

Word2vecは、GoogleのリサーチャーであるTomáš Mikolovらによって開発された単語の分散表現(Word Embeddings)を生成するためのモデル群の名称で、CBOW(Continuous Bag-Of-Words)と呼ばれる周辺語から中心語を予測する(i.e. 類似キーワード群から元のキーワードを見つけ出す)モデルと、skip-gramと呼ばれる中心語から周辺語を予測するモデルの2種類があります。
名前からもわかるように、Word2vecは単語をベクトルとして表現し、重みをニューラルネットワークに学習させていくことで、コサイン類似度の大小などから単語同士の近さを導き出します。また、ベクトルであるため単語同士の足し算や引き算なども可能となり、有名な例だとKing - Man + Woman = Queenなどの計算もできるようになります。

今回は上に挙げた目的から、skip-gramモデルにレストラン説明や口コミを教師データとして学習させ、あるキーワードをモデルに与えたときにその周辺語 (i.e. 類似語)を生成できるようにしました。具体的な実装としては、PythonのgensimライブラリでWord2vecを扱い、モデルの学習に必要なハイパーパラメーターは以下のように設定しました。

  • ベクトルの次元数: 200

  • ウィンドウ数 (与えた単語の周辺何語までを"近い"単語とみなすかを決定するパラメーター): 8

  • Negative Sampling ("遠い"とする単語のサンプルをウィンドウ外から何語持ってくるかを指定するパラメーター。計算の高速化に必要): 5

また、その他のWord2vecについての詳しい説明は、以下のスタンフォード大学の講義動画が役に立ちました。

www.youtube.com

MeCabによる形態素解析

上記のモデルに単語の相関性を正しく学習させるには、データの前処理が必要でした。まずは散文を単語ごとに分ける必要があるのですが、日本語は英語やラテン語とは異なり、語尾が活用する膠着語であるため、ただ単純に単語で区切るだけではうまくいきません。そこで日本語の形態素解析で有名なツールであるMeCabを用いて単語分割と品詞付与を行いました。MeCabの内部ではラティスが構築され、コストが最小化されるようなパスを選ぶことで正しい形態素に分けられるようになっており、今回は目的上、名詞と形容詞のみを取り出してモデルに与えることにしました (それのみでは意味を持たない助詞などはモデルの学習の妨げになる可能性があったため除外)。また、"インスタ映え"などの最新の単語も正しく分類できるように、MeCabの辞書はNEologdを使用しました。

検索式の生成

MeCabを用いて口コミデータを形態素解析し、それを使ったモデルの学習が完了すると、次は単なる周辺単語の羅列であるモデルのアウトプットから実際の検索式を生成する必要がありました。これは、

  1. 単純なキーワードとアウトプットの組み合わせ
    e.g.) "和食"がインプット、アウトプットが"懐石料理・日本料理・寿司"とすると、和食&懐石料理 | 和食&日本料理 | 和食&寿司という検索式を生成
  2. キーワードの単純変換
    e.g.) 和食 | わしょく | ワショク | Japanese Cuisine
  3. 含めてはならないフレーズの排除
    e.g.) "中華街"がインプットとすると、"!中華街から遠い | !中華街ではなく"などの検索式を生成

などを考慮し、実装を進めました。
キーワードの変換はgoogletransというPythonライブラリを使い、禁止フレーズはテンプレートを作って与えられたキーワードをそれに当てはめる形にしました。

成果・改善点

上記の実装を経て、具体的な成果としては、例えば"ディナー"というキーワードを与えたときに、以下のような検索式を生成することができるようになりました。

f:id:rettydev:20190218151937p:plain
キーワード「ディナー」で生成される検索式

また、このツールを使うとテーマページに表示されるお店リストの順序が変動し、より検索キーワードに固有のお店のランキングが上がることも確認できました(以下は、検索結果を確認するための社内用ツールで上記の検索式を入力したところ。エリアは倉敷市で指定)。

f:id:rettydev:20190218160729p:plain
キーワード「倉敷」の検索結果

しかし、2週間という時間的制約があったということもあり、インターン期間で出来なかったことやこのツールにおける改善点は多々あります。具体的には以下のような改善点が考えられます。

  1. 作成したモデルの定量的な評価が必要
    今回はモデルのアウトプットとして生成された検索式で実際に検索してみたり、Google検索エンジンの検索レコメンドを真似てみたりと、モデルの性能を定性的にしか評価していませんでした。今後は、このモデル自体の定量的な評価 (+ 最適化)に加えて、このモデルを使って生成されたテーマページ (ちなみにこのモデルはあくまでもテーマページ内部の検索式のみを自動生成するものであり、ページの生成ロジックや見た目に関しては既存のテンプレートがある)によって、PVやクリック数などがどれだけ変化するかなどを数値化・可視化していく必要があると感じました。
  2. 検索式生成アルゴリズムの改善
    現状は、例えばNGワードの除外などはマニュアルで作成したテンプレートにキーワードを当てはめる方式をとっていますが、これは苦肉の策であり、より効率的で正確なアルゴリズムで置き換える必要があるとも感じました。具体的には、"ランチ"というキーワードに対して"ランチから遠い"などといったフレーズが生成されたりするのを防ぐ必要があります。
  3. モデルに与えるキーワードの選定
    上記の成果のサンプルでは、"ディナー"というキーワードを与えていますが、ここでどのようなキーワードを与えるべきか、というのは大きな問題です。あまり検索されないキーワードを与えるよりかは、検索されやすい単語から順に与えていった方がテーマページにとって効果的なのは明らかですが、そういったキーワードの選定までは今回は手が及びませんでした。
  4. Word2vecの代替ツールとの精度の比較
    Word2vecには、与えるデータ量が少ないと精度がイマイチ、という大きな欠点があります。今回の場合は、そこそこのデータ量があったため比較的上手くいきましたが、このツールを他の分野で応用していく際に、十分なデータ量が確保できない可能性もあります。そういった場合にWord2vecを使用するのは最善とはいえず、他の代替ツールを検討する必要が出てくるかもしれないと感じました。例えば、スタンフォードの研究グループが開発したGloVeは、SVDとWord2vecの欠点を相殺し、小さなコーパス (i.e. データ量)からでもパフォーマンスがいいといった特徴があるため、上記の条件を満たすようなツールになり得るかもしれません。

今回作成したツールの応用について

上に挙げたように現状の改善点は多々あるものの、今回作成したツールは有用であり、様々な領域での応用が可能ではないかと考えています。例を挙げると、

  • レコメンドシステムへの応用
    Airbnbなどは既にレコメンドシステムにWord2vecを活用しているようです。
    mccormickml.com

  • ターゲット層を絞ったテーマページの生成
    ユーザーログの解析と組み合わせれば、例えば、"20代女性に大人気のレストランまとめ"などのテーマページの生成も可能になり、テーマページ自体の需要も上がるのではないかと考えました。

  • 感情分析を用いたUXの向上

などがあり、Word2vecがいかに有用で革命的なものであるかがわかります。

インターンを終えて

インターンに参加するまでは、機械学習自然言語処理を実践的に扱った経験がなく、Word2vecを使用した経験もありませんでした。そんな中2週間という短期間で成果が出せるのか、という懸念はインターンが始まる前からありましたが、メンターや他のエンジニアの方々のサポートもあり、スピード感を持って業務に取り組むことができ、最終日には無事にエンジニア・プランナーを含めた30名程の社員の前で成果発表プレゼンをすることができました。

業務以外にも、毎日異なる方々とランチに行くことができ、Rettyにおける新しい取り組みや、創業当時の話、研究のアドバイスやビジネスにおけるものの考え方まで、幅広いトピックの話を伺うことができ、インターンが終わってからはよりメタ的な思考で物事を考えるようになりました。特に、Rettyのようなプロダクトベースの企業では、何よりもユーザー体験が第一であり、ユーザーに長く日常的に使ってもらえるプロダクトをつくるためのツールの核として、エンジニアリングというものがあるのだという認識が強くなりました。つまり、ユーザーにとって内部の実装や使われているツールなどは大した問題ではなく、果たしてそれが使いやすくて便利なものかということが最も重要であるということです。今回のタスクはユーザーには直接的には関係のないものでしたが、今度は逆にそういったプロダクトを作るエンジニアの作業効率を上げること、つまり人間がやらなくてもよいことを自動化する、という作る側にとってのメリットが大きいものだったのだと思います。

現在は大学に戻っており、Rettyでの経験をスタート地点として今学期から自然言語処理系の研究を大学教授の元で始めました。今の今でいうと知識やスキルのキャッチアップの要素が強いですが、今後はAuto Summarization (自動要約)や文章のバイアス検知 (例えば、Word2vecのKing - Man + Woman = Queenという式は、Kingが男でなければならないというコンテクストで捉えるとPolitically Incorrectであり、無意識のバイアスがかかっているといえます)に関する研究を進めようと考えています。現在は扱えるデータ量が指数関数的に増加していますが、実際のデータの大半は英語や日本語などの自然言語で書かれているため、機械に自然言語を処理させることの重要性は今後益々高まっていくに違いなく、それが現在の研究をするモチベーションにも繋がっています。

最後に、Rettyでのインターンを考えている方へ

Rettyは、自分でやりたいことや興味のあることが決まっている人にとっては、最高の環境であるといえます。大学の授業や研究室における理論やコンセプトが、私たちが日常的に使うプロダクトに落としこまれるその雰囲気を感じられるというだけでもインターンに行く価値はあると思います。
それに加え、冒頭でも書きましたが、4000万人の月間ユーザーを抱えるRettyが持つ価値のある密なデータ (少なくともAmazonの商品レビューに比べたらデータの密度は大きく扱いやすいといえるのではないでしょうか)を自由に扱えるという点を考えると、データサイエンティスト志向の人にとっても活用しがいのある環境だと思います。
そのような野心のある方はぜひRettyのインターンに応募してみることをオススメします!!

最後になりましたが、インターン期間中にメンターとしてサポートしてくださったアドテクチームエンジニアの堤さん、それからインターンの方向性などを一緒に考えてくださったCTOの樽石さんをはじめとしたRetty社員の皆様にはこの場を借りて御礼申しあげます。ありがとうございました。

Rettyグルメニュース入稿システムの脱 WordPress リニューアル

こんにちは。エンジニアの山本です。
(アプリチームにもエンジニアの山本がいますが、Web チームの山本です。)

本日は、Rettyグルメニュースの入稿システムの紹介をさせていただきます。

Rettyグルメニュースとは

Rettyグルメニュース(retty.news)は、Retty が運営するグルメに関する Web メディアです。 「ニュース」と冠してはいるものの、新店情報だけでなく、「福島県で自然酒を作る酒蔵に取材に行った記事」や 「美容室の中にプリン工場を作った人のこだわりをインタビューした記事」など、さまざまな観点から実際に現地に行った人がグルメ情報を紹介するメディアです。

2017年9月にリニューアルを行い、Retty から別サービスとして切り出されました。 その際に入稿システムも作り直し、そこから1年以上経ち様々な改善を行ってきました。

Rettyグルメニュース入稿システム

通称は Gohan です。 当時余っていた gohan を含むドメインを使おうか、という話があったためこのような名前になりましたが、実際にそのドメインがこの入稿システムに使われることはありませんでした。

f:id:rettydev:20190128203627p:plain
記事編集画面

機能紹介

プロフィール埋め込み機能

グルメニュースでは、システムにログインできるメールやパスワードを持った情報を User とし、記事内に登場する人間の情報を Profile としています。 User は必ず一つ Profile を持ち、記事内に自分が登場するときは即座にその情報を埋め込むことができます。 また、外部ライターさんからテキストで納品していただき、内部の編集者が入稿するときのために、記事そのものも入稿者としての User とライターとしての Profile を持ちます。 記事内では登録された Profile を検索して、食レポに行った人やインタビューに答えてくれた人、店主などの情報を埋め込むことができます。 Profile は人物紹介文の他に各種 SNS やブログへのリンクを持っており、Profile を編集することで埋め込まれたすべての記事の内容を書き換えることができます。

f:id:rettydev:20190128221110p:plain
プロフィール設定画面

店鋪リンク、口コミ埋め込み機能

紹介したお店やお店に対する口コミもポップアップ画面で URL を入力することで埋め込むことができ、店名の変更や住所の変更時にグルメニュース側で記事を編集する必要がない作りになっています。

店鋪リンク設定画面
店鋪リンク設定画面

口コミ設定画面
口コミ設定画面
(Retty エンジニアであり、焼きそばブロガーの塩崎さん)

画像など

店鋪リンクやプロフィールはマークダウンを拡張した記法でコンテンツとして保存されます。 画像やリンク、引用などもマークダウンで記述しますが、それぞれ GUI をもたせており、ポップアップに入力することで、マークダウンが現在のキャレット位置に挿入されます。 こうすることで、マークダウンで書きたい人はマークダウンで、マークダウンを知らない人は GUI で、モードを切り替えることなく記述できるようになっています。

プレビュー

プレビュー画面では、記事を保存せずともその場でプレビューを見ることができ、 UserAgent を切り替えなくてもボタン一つでスマートフォンでの見え方まで確認することができます。

プレビュー画面
プレビュー画面

(当時最新のiPhoneで作ったのですが、すでに古さを感じる…)

編集以外の機能

編集以外にも、入稿システムから

  • 内部リンクの設定
  • 申請された記事の差し戻し・公開・公開予約
  • カテゴリや連載の管理
  • Profile の管理
  • 読者・ライターさんへのお知らせ設定
  • 申請などがあったときの Slack 編集者チャンネルへの通知

などができるようになっています。

リニューアル振り返り

さて、ここからはリニューアルの振り返りをしていきます。 リニューアル前のグルメニュースは Retty の Web サービス上に WordPress を乗っけたような構成になっており、リニューアルで解決すべき主な課題は以下のようなものでした。

  1. WordPress によって DB に HTML が保存してあり、スタイルの変更などが困難
  2. カスタムした WordPressPHP の管理画面上に置かれていて入稿機能だけを担っており、その場でプレビューが見れない
  3. 記事の申請やその差戻しなど、外部ライターさんと一緒に使う機能が不十分

これを3ヶ月ほどのリニューアル期間で、配信側と入稿側合わせて作り直す必要がありました。

リニューアル手順

  • 入稿システムの要件をヒアリングし、必要そうな機能の UI を View だけ作って編集部に見せる。
  • 確認がとれたら実装
  • 実装が終わったら触ってもらって確認

の繰り返しで、エンジニアサイドから要件を掘り起こす形で行いました。 ここでのポイントが、既存の入稿画面を見慣れてる編集者に 画面の詳細までヒアリングを行わない、ということです。 「必要な"機能"をユースケースと一緒にヒアリングし、それを満たす画面構成や画面遷移を整理・提案・実装・確認」というサイクルを繰り返しました。 また、画像をドラッグ&ドロップでアップロードできる機能の UI は WordPress に似せるなど、システム移行後の編集者の学習コストを抑えるような工夫をしました。

フロントエンド

デザインは AdminLTE に頼ったものの、jQuery は排除し Vue.js を採用しました。 サーバーサイドは Laravel を利用していましたが、Laravel Mix はフロントエンドのビルドがサーバーサイドフレームワークに依存するというのが個人的に好きではなく、使っていません。webpack-dev-server でフロントエンド開発用のサーバーを起動し、フロントエンドのビルド対象物以外のリクエストを Docker で起動したサーバーサイドアプリケーションに流すことでサーバーサイドとフロントエンドの開発を同時に行ってましたが、これはプロトコルを決めて別々に開発してもよかったかなと思ってます。

DBリニューアル

サービスを切り離すついでにデータベースごとリニューアルしました。 新システムでは記事本文コンテンツをマークダウンで管理するようにしたため、HTML で保存されていた記事を変換する必要がありました。

そこで、リニューアルの開発が落ち着いた頃に移植作業を行いました。 PHPDOMDocument を用いて HTML をパースし、マークダウンに変更していきました。 ワードで作ってコピペしたような、HTML とは呼べない XML や、ツリー構造が壊れた HTML なども混入しており骨が折れましたがコンテンツの90%程はこのスクリプトで移植しました。

記事内に登場する人物のプロフィール情報や店鋪情報などは直接マークダウンで書き込まず、カスタムしたマークダウン記法に変換する必要がありましたが、コンテンツ移植時点ではプロフィール情報の登録が終わっていなかったため、プロフィールが入ることを示すマークに置換していき、登録が終わった後に編集部と確認しながら埋め込みました。

配信側の作成

入稿システムが終わったら配信側のアプリケーションを作ってリニューアル終了です。 入稿システムのプレビュー機能と配信側アプリケーションの二箇所で拡張マークダウンを HTML に変換する処理が必要でしたが、処理を一箇所にまとめ完全なプレビューができるようにしました。 また、通常時と AMP で別々に管理せずに済むよう、マークダウンパーサーにオプションを追加し AMP 用の HTML を作り、スタイルに関しても postcss-loader の小さなプラグインを作って自動で AMP が作成されるようにしました。

リニューアルまとめ

入稿システムに1ヶ月半、配信側に1ヶ月半、リニューアル前の URL からのリダイレクト処理、古いコード・データベース の削除、QA などに1週間ほどかけ、リニューアルが終了しました。 小さなチームで、編集者とエンジニアが協力しあってリニューアルしながら改善サイクルを回すことができたのが良い点でした。 一方で、リニューアルという多くのタスクが存在するプロジェクトのタスク管理が不足しており、リリース前にバタついてしまい、大きな反省となりました。

リリース後

PWA

配信側を PWA にしてキャッシュによる高速化を試みたりしましたが、配信側は SPA ではなくサーバーサイドでHTMLを生成するアプリケーションなため、キャッシュ効率が悪く、現在業務の合間にインターン生と一緒に入稿システムの GraphQL API 化と配信側の Nuxt.js による SPA 化を進めています。

textlint

グルメニュースリニューアル以前から Slack に #rss_gourmet_news というチャンネルがあり、そこに公開された記事が流れてくるのですが、誤字・脱字・表記ゆれを社員から指摘される、ということが多々ありました。 入稿システムの開発者としてなんとかできないかと、textlint などの導入を考えたところ、2018年新卒エンジニアの諏訪くんが入社し、一緒にグルメニュースの保守を担当してくれることになり、textlint の導入をかって出てくれました。

それにより以下のキャプチャのように、ルールに反した記述を機械的に判定できるようになりました。

textlink による文チェック
textlink による文チェック

ランキング機能

グルメニュースに表示されているランキングは、入稿システムのワーカーによって毎日更新されています。 この機能はリニューアル当時、とりあえず Google AnalyticsAPI を叩いて実現していましたが、読者さんが増えたため Analytics のサンプリングのしきい値を超えてしまい、 API から返ってくる値が正確ではなくなってしまいました。 弊社の DWH に PV 数を記録し、BigQuery を叩いてランキングを生成するようにする変更も諏訪くんがやってくれました。

おわりに

グルメニュースリニューアルからかなり時間が経っていますが、管理画面は社員でも限られた人しかログインできないため、振り返り記事で見てくれたらいいなという思いもあって記事になりました。 世の中にはすでに様々な Web エディターがありますし、最近では Headless CMS も盛り上がっていて、場合によっては入稿画面を自力で作らなくても良いこともあるでしょう。 そのチーム、プロダクトにあった入稿画面でライターさんが楽しく入稿でき、編集チームが楽に管理できる管理画面があることが重要だと思います。

Retty Developer Team 2018

この記事は Retty Advent Calendar 2018 25日目の記事です。
昨日は @wtnVegna さんの記事で、 クリスマス(季節性)に負けない統計的因果推論 でした。

本日はRetty VP of Engineeringのkosakoが担当します。

実はVP of Engineeringという役職になったのは二ヶ月前の10月からで、社内でもエンジニア以外からはVP...Nだっけ?といわれたりまだまだ定着していなかったります。

ちなみにこちらの記事にもあるとおり、昨年の今頃はアプリチームでiOSリニューアルをやっていました。
なんとかリリースにこぎつけた後で会社全体を見渡したときに、開発組織という観点で誰かがコミットして牽引していく必要性があると感じたため2018年は組織にコミットするということを目標に決めました。
課題感を持っていたメンバーと一緒に進めたものもあれば、ボトムアップに任せたもの、トップダウンで決めたことなど様々なものがあります。

2018年のRettyは月間利用者数が4000万人突破や、Yahooとの提携といった大きなニュースがありました。
その裏でこの一年Rettyの開発チームがどのような取り組みを行ってきたかをお届けします。

1.技術への取り組み

フロントエンド技術の刷新

2017年から今年にかけてRettyではフロントエンドの技術の刷新を行ってきました。
それまではフロントエンドを専門でやっているメンバーもおらず、jQueryを使ったかなりレガシーなコードになっていました。
Rettyの中でも新しい取り組みが少ない分野でしたが、フロントエンドエンジニア陣の頑張りによりVue.jsをメインとしたモダンな開発環境に生まれ変わりつつあります。
今では社内でも最もモダンな取り組みや、技術的挑戦がされるようになりました。

実際にどのようなことが行われているかは今年のアドベントカレンダーの記事を御覧ください。

PRごとにCIでStorybookをビルドしてデザイナーとインタラクションまで作っていく話
ESLintの力で秩序あるAtomic Designを後世に残す
SEO に強くなる構造化データマークアップ ~ Nuxt.js で JSON-LD をコンポーネント指向で管理する ~
Vuex ORM についてなにか書いてみようとしたがやめた話
GraphQL でフロントに優しい API を作ろう

テクノロジーロードマップの策定

それまでも技術に関するロードマップはあったのですが、各チームで決めていたり運用と先端技術への投資の区別がされておらず、全体として大きな方針が見えづらい状況がありました。

そこで、数ヶ月かけて様々な角度から議論を行い数年後の目指す方向性を定めたテクノロジーロードマップを作成しました。
説明会や質問会も開き、できるだけ多くの人の意見や理解の吸い上げなども行っています。

f:id:rettydev:20181225145130p:plain説明に使用したスライドから抜粋

大きな方向性としてはマイクロサービス化をしていくことを定め、そのためにどのようなノウハウや技術が必要かといったことがわかるようにしています。
また、ロードマップは一度決めたら終わりではなく状況により変化していくのが当たり前ですので定期的な見直しを行うこと、そして見直しを行った際は必ず説明をするといった運用を行っていく予定です。

テクノロジーロードマップを決めたことにより全員の目線が揃ってきており、面接時に今後の方針について一貫性がある説明ができたり、アーキテクチャについて議論する場合にもベースとなるロードマップがあることにより議論が拡散し過ぎないようになったりといった効果がありました。

技術における共通認識ができてきたことは大きな成果でした。

マイクロサービス化に向けた取り組みの開始

テクノロジーロードマップで定めたマイクロサービス化ですが、first stepとなるプロジェクトに取り組んでいるところです。
リリースは来年になるため、まだ詳細は書けませんがお話できるようになったらこのブログで取り組みや内容について掲載していく予定です。

道のりはまだ長いのですが、マイクロサービス化とそれを成立させるための体制づくりを一歩づつ進めています。

2.開発プロセスへの取り組み

スクラムの本格導入

これまでRettyではカンバンを使ったりアジャイル的な開発スタイルではありましたが、属人性が高いものが多くチーム開発としては成熟した状態ではありませんでした。
その中でアプリチームがスクラムをしっかりと導入し、属人性が低く生産性の高いチームに生まれ変わっています。

全社での導入には至っていませんが、広げていくための取り組みも始めています。

詳細は下の記事を御覧ください。

実例に学ぶスクラム導入手順 - タスク属人化を避け、チーム開発力向上のためにRettyがやったこと

分析チームの発足

今年分析チームが作られましたが、それまではチームはなくプランナーがやるかチームのエンジニアがやるかといった形であることが多く、統一した動きになっていませんでした。
ログの設計なども場当たり的な物が多く、やたら細かく取られていたり取得されていなかったりと粒度もバラバラでした。

現在はログの設計や分析の基盤づくりなども進み事業推進のための重要な役割を果たしており、チームのモチベーションも高く、ノウハウ化、自動化が最も進んでいるチームになっています。

どのような思想でチーム作りをしているのか、どのような開発・分析をしているのか気になった方は下記記事を是非ご覧ください。

Webサービスを支えるユーザログ基盤開発@Retty
ベンチャー企業におけるDWH DevOps @ Retty
Rettyの意思決定を最大化!データ分析チームの取り組みをご紹介

3.組織に対する取り組み

エンジニアFeedBack

エンジニアの評価制度についてはどの会社でも悩んでいると思いますが、Rettyでも課題を抱えています。
よくあるのがミッションの達成に対する貢献度で評価を行う方法ですが、技術負債の返済やリリース後のリファクタリング、自動化などに対する評価がされにくいというものです。
また、エンジニアの技術的成長につながる評価やFeedBackといったものがあったほうがいいのではないか?という意見もあったことから、エンジニアが自分たちで考えて作るFeedBack制度を立ち上げました。

評価への影響を限定した上で、立候補を含めたメンバーでやり方をどうするかから説明・実行までを行いました。
前回行った方法としてはGitHubを使ってpull requestベースのやり取りによる評価シートの作成という形になりました。さらに具体的な方法については、後々になると思いますが別の形でご紹介できるようにしていきたいと思っています。

結果としては納得度の高い評価を得られた人がいた一方で、工数がかかりすぎだったり評価への影響が限定的なためやるモチベーションが湧きにくいといった課題も見えてきました。
問題もありましたが、評価についてより多くの人が考える切っ掛けになったのではないかと思います。

現在は前回の課題を踏まえた上でどう変えていくか検討しています。

開発組織課題プロジェクト

今年の1月から開始したプロジェクトで、開発組織の課題を集め解決を図っていくものになります。
これまでに出てきたテクノロジーロードマップや、エンジニアFeedBackなどはこのプロジェクトから生まれてきたものになります。
このプロジェクトにはCFOも参加したりしており、エンジニアだけではない意見が出てきて本質的な課題に踏み込むことができました。

約3ヶ月かけて本質的な課題の発見とその対策を検討し、開発チーム全員に対して現状の課題がどこにあり、どう解決していかなければならないのかを説明しました。

現在は、この後にある技術戦略本部がその役割を担うようになっています。

技術戦略本部

CTOとVP of Engineeringが運営する組織になります。
発足は今年の12月から。できたてホヤホヤです。

1月から様々な取り組みを進めていく中で、複数のワーキンググループの立ち上げを行いました。
小さなものも含めれば20近い数になりこのままでは管理ができなくなること、スケールしないこといった課題がでてきました。
またワーキンググループは手軽に始めるのにはよいのですが、実行や継続することに課題が出やすく対策が必要になってきたためこのような枠組みを新たに設置しました。

この技術戦略本部には3つの目的を設定しています。

  1. 全体の技術の方向性を定め、そこに向けて技術のトップラインを伸ばす
  2. 働きやすく、個人とチームがより成果が出せる強いエンジニア組織にする
  3. 効率化や必要な共通認識の醸成を行い生産性を高めることにより、より本質的な課題に集中できるようにする

単純に技術を追求するのではなく事業とのバランスをとりながらサービスの成長を支えること、さらには事業の新たな可能性を切り開けるような組織にしていければと思っています。

まとめ

今年一年のRettyを

という軸でそれぞれ振り返ってみました。

こうしてみるとサービス的にも事業的にも大きな出来事もありましたが、組織的にも大きな変化が起きた年になったと思います。
一貫して取り組んだこととしては、チームで継続した成果を出せるような組織にしていくことです。

もちろんまだまだ十分ではない所だらけですし、取り組んできたものの中にはうまくいったものもあれば課題が残ったものもあります。
2019年は今年取り組んだことをしっかり継続させていくこと、そしてその上にさらなる挑戦を積み重ねていくことが大事だと思っています。

それでは本年もRettyをご利用くださったみなさまに感謝して、アドベントカレンダーを終わりとさせていただきます。

Rettyの意思決定を最大化!データ分析チームの取り組みをご紹介

この記事は Retty Advent Calendar 18日目の記事です。
昨日は@isaoekaさんの会社の行動規範浸透を図るため、メニューバーからいつでも確認できるアプリを作ったの話でした。

はじめまして、Rettyのデータ分析チームでマネージャーをやっている平野です。
Rettyのデータ分析チームは今年4月に立ち上げ現在9ヶ月目です。
この記事では立ち上げから9ヶ月でやってきた組織的取り組みについて中心に書きました。

アドベントカレンダーではデータ分析の技術的取り組みついてを、一緒にデータ分析チームを立ち上げた@takegueが書いてますので、そちらも合わせて読んでいただけますと幸いです。

ベンチャー企業におけるDWH DevOps @ Retty - Retty Tech Blog

Webサービスを支えるユーザログ基盤開発@Retty - Retty Tech Blog

目次

この記事で言いたいこと


非常に記事が長くなってしまったので、この記事で特別言いたいことを紹介させていただきます。これだけでも読んでいただければ幸いです。

①PM(Product Manager)の業務領域に踏み込んだデータ分析を行っている

⇒データアナリストといっても様々な形があるなか、Rettyのデータアナリストはデータ分析の領域を超えPM(Product Manager)の業務領域に踏み込むことでプロダクト/ユーザーさんへの理解にも強い集団です。
そのRettyのデータアナリストが分析を行う上で大事にしていること(=カルチャー)について理解できる内容となっています。

②少数精鋭で戦うために、エンジニアリングによる効率化を徹底している

⇒Rettyのデータアナリストはエンジニア出身が多く、生産性を向上させるためのツールや仕組み作りが好きな人材が多いです。
少数精鋭でも戦うために必要に駆られて取り組んできた内容を是非ご紹介できればと思います。

データ分析チームのミッションの概要をご紹介


では本編に入ります。 まず最初は、Rettyにおけるデータ分析チームに求められるミッションについて紹介します。

f:id:rettydev:20181218105144p:plain

意思決定最大化・基盤/仕組み作り・データの民主化の3つがRettyにおけるデータ分析チームのミッションです。

この記事では上記3つについて詳細に紹介していきます。

①意思決定最大化


立ち位置/求められるバリュー

意思決定最大化で求められるのは事業の意思決定をデータ分析によって推進していくことです。

実際どのような動き方をしているかは図にしてみました。

f:id:rettydev:20181212162023j:plain

派遣型と依頼型で分けて動いています。

理想としては全てのミッション*1にデータアナリストを派遣したいのですが、現在の体制としてデータアナリスト5名、データエンジニア1名と少数精鋭なので、このような形をとっています。

毎Qごとに、事業優先度×データ分析需要度から優先度を付け、データアナリストを派遣するミッションを決めています。

どんな分析業務をしているのか

次にRettyにおけるデータアナリストがどのような分析業務を行っているのかを紹介します。

  • 戦略構築
    • プロダクトにおける長期目標に対して何をやり・何をやらないかを決めるために、現状の数値や今後の数値シミュレーションを行う業務
  • KPI設計
    • KGIを達成するためのブレイクダウンされた指標を決める業務
    • KGIとの連動性やプロダクトの方向性と一致しているかを大事にして進める業務
  • 目標値設計
    • Q目標、月目標と設計する業務
    • 季節要因などの外部要因を考慮した設計を行う
  • 目標進捗確認ダッシュボードの作成
    • 目標値と実態との差が見れて、良い悪いがわかるダッシュボードを作る
  • 課題特定(狙い目を決める)
    • 改善するページ/ユーザー/フローなどの特定
  • 現状把握
    • 仮説を立てるための網羅的なデータ出し
  • 施策のテスト設計
    • 期間、ターゲット、指標を決める
  • 施策の効果検証
    • 施策の効果ありなしを検証する

Rettyのデータアナリストはこの業務を全て派遣先ミッションで行い、意思決定を推進する役割を担っています。

次に、これら分析業務を行う上でRettyのデータアナリストが重視していることをお伝えしたいと思います。

データを正しく読むためにプロダクトとユーザーさんの理解を重視する

ユーザーさんの課題発見やKPI設計などの大半のデータ分析において、まず正しい現状を把握することが大事だと思っています。

この現状把握を行う際に非常に大事なのが、データを正しく読むこと。

そしてデータを正しく読むためには、自社のプロダクトとユーザーさんを深く理解することが重要だと考えています。

もう少し掘り下げて説明します。

データの裏にある真実を理解することがデータ分析の本質

ここでいう、データを正しく読むとは何なのか、それはデータの裏にあるユーザーさんを正しく想像することです。

もう少し噛み砕くと、データを見たときに、プロダクトがどのように使われるのが理想で、そのプロダクトをいつ、どういう人が、どのように使っていて、何に困っているのか。をイメージするこということです。

PMの領域に踏み込むことが大事

ではユーザーさん・プロダクトを理解するためにどうするべきなのか。 一つは、データアナリストも自らの業務領域を超えてPMの業務領域に踏み込んでいくことが必要だと思っています。

Rettyでは分析業務を超えて、PMの業務領域に深く踏み込むようにしています。
その取り組みの一例を紹介させていただきます。

プロダクトの健康診断をDailyで行う

毎日派遣先ミッションのメンバーとアナリストでプロダクトの主要数値をチェックし、現状のプロダクトがどのような状態なのかをチェックしています。

実際の値はお見せすることはできませんが、大体以下のような指標郡を全てチェックしています。

f:id:rettydev:20181216174634j:plain

このダッシュボードはDailyだけではなくWeekly、Monthly版と3種類用意しています。

またミッションごとに見るべき指標はことなるので各々のミッションごとに作成しています。

3種類のダッシュボードの確認タイミングとしては、

  • 月曜日にWeeklyダッシュボードで先週の数値
  • 毎月1日にMonthly版で先月の数値
  • それ以外はDailyダッシュボードで前日比と前週同曜日比

です。

前週同曜日比を見ることがおすすめで、ダウントレンドの場合は薄ピンク色に背景を変えてトレンドを直感的に分かるように工夫しています。

f:id:rettydev:20181216175015j:plain

これをやった結果、チームの数値感度が大きく向上しました。 具体的には、以下のような効果がありました。

  • 単純に毎日見るので主要数値の数値感が付く
  • 主要数値が頭に入っているので、数値変化に気づく
  • その数値変化が異常なのか異常ではないのかも判断が付く
  • また、プロダクトとユーザーさんを一番知っているPMの解釈を目の前で見ることができるのでデータ解釈力が上がる
  • みんなで見解もぶつけることで解釈の精度が上がる

また、目標値との進捗もここでチェックすることで、目標値との乖離がどの程度あるのか、このペースで大丈夫なのか、ペースが追いついていない場合どの程度埋めていく必要があるのかを把握することが出来ています。

PMと二人三脚で分析を進める

データ分析を進める上で、仮設出しから数値結果の見解を出す上でPMと壁打ちをしながら進めています。
KPI設計を行うときには毎日必ず議論するようにしてコミュニケーションを増やしています。

プロダクトの健康診断とも被る効果になりますが、PMの仮設や見解の出し方をインプットできます。
もう一つはPMの思考理解に繋がるため、期待される動きやアウトプットのズレを限りなく減らす効果もあります。

データ分析はデータを出しては議論し、またデータを出すの繰り返しなので、毎日PMの時間を固定で抑えてしまうのがおすすめです。

一度PMやプランナーを経験する

可能なら一度プロダクトのPMやプランナーを経験することもおすすめです。

Rettyではプランナー出身者からデータアナリストに向いている人を見つけ分析チームに入ってもらった人もいます。

自身も元々バックエンドエンジニア兼プランナーからデータアナリストに転向した身です。

プロダクトのグロースにコミットすることで、プロダクト理解やユーザーさん理解が進むのはもちろんのこと、施策を打つためにもデータ分析の重要性もかなり理解できるのでとてもおすすめです。

プロダクトビジョン・歴史を理解する

もう一つは、自社のプロダクトビジョンと今までの歴史を理解することかと思います。

理解する方法は、正直業務を通じてプロダクトのビジョンや歴史を深く知っている人(POなど)とのコミュニケーションを増やすのが早いと思います。

他にも入社オンボーディング等で工夫できるかもしれませんが、Rettyでは業務を通じて理解を深めていってます。

図解するとこんな感じ(まとめ)

f:id:rettydev:20181213140810p:plain

とはいえ、簡単には身につかないので長期的にプロダクトとユーザーさんに向き合う強い覚悟が大事だと思います。

Rettyのデータアナリストはプロダクトのグロースに責任を持っているPMにも負けないくらいグロースに向き合っていきます。

②基盤/仕組み作り


ミッションの2つ目は基盤/仕組み作りです。 ここでいう基盤/仕組み作りには、

  • ログ基盤やDWHの開発/運用
  • ダッシュボード開発/運用
  • 分析の生産性を上げる仕組み作り

などがあります。 ただログ基盤やDWHの開発/運用に関しては先日公開された@takegueのアドベントカレンダーに詳しく書かれているのでそちらを読んでください。

engineer.retty.me

分析の生産性を上げる仕組み作り

少数精鋭でRetty組織全体のデータ分析を行うので生産性を上げていかないととても回りません。

各々みんな派遣先ミッションで頑張りながらも生産性を上げる取り組みを適宜とりながら進めてきました。

その取り組み内容を紹介したいと思います。

Githubに分析アウトプットとSQLを蓄積

分析のアウトプット先は、ほとんどの場合スプレッドシートでたまにJupyter notebook やGoogleスライドを使ったりします。

大体が集計データを整理してグラフ化する程度が多いのですが、その分析アウトプットとそのデータ出しに使ったSQLgithubに蓄積しています。

Pull requestを投げて、分析やデータ出しに関してレビューが欲しい場合は任意で依頼する形をとっています。

分析アウトプットもSQLも過去に似たような分析をしていた場合に役に立つのと、新人さんが入ってきたときにキャッチアップしやすいことを考えてこの取組をおこなっています。

PR(Pull request)の中身としては、以下3つです。

  1. 本文に問題設定、分析設計、結果、見解、分析後のアクションを記入したもの
  2. 分析に使ったソースコード(主にBigQueryのSQL
  3. 1.の内容をREADME.mdにコピーしたもの
    • 1.の内容をCircleCIを使ってREADME.mdの自動生成を行っています

具体的に実際に使っているテンプレートの中身をご紹介します。 もしよければ業務で使ってください。

<PRテンプレート>

問題設定
==
<!-- 分析によって何を解くのかを記載してください -->
<!-- githubのlinkを貼るだけでも大丈夫です -->

分析設計
==
<!-- どのように分析するのかを記載してください -->
<!-- githubのlinkを貼るだけでも大丈夫です -->


分析結果
==
## データ/資料
<!-- クエリ結果や分析資料が格納されているテーブルorスプレッドシートのリンクを貼ってください -->

## 結論(事実)
<!-- データから見えた事実のみを記載しましょう。独自の見解は見解項目に記載する。 -->

## 見解
### アナリストの見解
<!-- アナリストの観点からの見解を記載しましょう。 -->

### 最終的な見解
<!-- 依頼者と摺り合せて最終的にまとまった見解を記載しましょう-->

## 分析によって決まったこと(ここがバリューです)
<!-- 
分析によって、決まったことを記載しましょう
 - 目標がxxに決まった
 - xxについて深掘りをすることになった
 - xxをKPIにすることに決まった
など
 -->

ここで重要だと思っている項目が最後の項目の分析によって決まったこと(ここがバリューです)です。

意思決定最大化をミッションとしているため、行った分析のバリューを言語化することを徹底しています。

Rettyでは毎週のデータ分析チームの定例会で、先週行ったアウトプットの共有会があります。

ここではmergeされたPRの中身をベースにして共有するので、バリュー欄を埋めることが必須な仕組みとなっています。

そのためこの項目があるだけで、分析の相談が来た際に分析後のアクションイメージをすり合わせてバリュー意識を高めることができています。

<mergeされたPR一覧>

f:id:rettydev:20181213194002p:plain

PRにはラベルを付けているので、ミッション、分析者、分析の種類などでフィルタリングできます。

このようにラベル付けをすることで、過去の分析結果やSQLを探しやすくする工夫も取り入れています

使いやすいVIEWを作りデータ出しスピード向上とミスを防ぐ

Rettyでは、BigQueryをDWHとして採用し、そこにプロダクトのログやマスタテーブルを全て集約させています。

そして大半のデータ分析は、BigQueryを叩きスプレッドシートにまとめてお終いです。大体8割くらいがそのような分析案件となっています。

そのため、分析業務においてSQLを書くことが多く、素のログやマスタテーブルをJOINし、出したいデータを出す作業が多かったのです。

この中で、問題は大きく2つありました。

  • 単純にデータを出すスピードに時間がかかる
  • テーブル知識を持っていないと間違ったデータを出してしまう

スピードを求められるベンチャー企業のデータアナリストとしては、この問題はシンプルですがとても重要視すべき問題だと捉えています。

そのため、Rettyではデータアナリストが使いやすいVIEWをデータアナリスト自らが作ることでデータを出すスピードと品質を向上させることに努めはじめました。

せっかくなので、作って生産性が向上したVIEWを紹介したいと思います。

f:id:rettydev:20181216131236j:plain

f:id:rettydev:20181216131250j:plain

f:id:rettydev:20181216131301j:plain

f:id:rettydev:20181216134429j:plain

元のstatusカラムも他テーブルとJOINする際に必要になるケースが存在するためVIEWには含めたままにしています。

またrecord型を使うことで、もともとアプリケーション側に最適化されていたマスタテーブルもデータアナリストにとって分かりやすく使いやすいように情報を構造的に整理する工夫も取り入れられています。

- restaurant
    - id
    - name
    - status
        - id 
        - name
    - budget
        - dinner
        - lunch
ISSUEのテンプレート化で依頼の質を高める

横断組織のデータ分析チームは依頼の品質がチームのデータリテラシによって様々です。

なんでも屋になっても困るので、依頼の質を向上させていくための一貫として、ISSUEのテンプレートを作りました。

こちらもテンプレートをご紹介しますので、よければ使ってください。

<分析依頼用ISSUEテンプレート>

---
name: 分析依頼
about: 分析の依頼をしたいときはこちら

---


WHAT
==
### 依頼内容を記載してください




### 依頼内容にチェックしてください
<!-- 
基本一つのissueで一依頼で御願いします。 
複数依頼がある場合は、issueを複数作成してください。
-->
- [ ] 施策のテスト設計依頼
- [ ] 施策の効果検証依頼
- [ ] 現状把握のデータ出し依頼
- [ ] 課題発見(狙い目特定)の分析依頼
- [ ] KPI設計依頼
- [ ] 目標設計依頼
- [ ] ダッシュボード作成依頼
- [ ] シミュレーション

WHY
==

### 依頼の背景
<!--なぜその分析業務を依頼したいのかを記載してください-->



### 分析後のアクションがあれば記載してください
<!--
例
・施策の効果検証
 →効果があった場合は全展開MTGに出す予定
・KPI設計
 →KPIとして決まった指標を目標として追う予定
・ダッシュボード作成
 →毎日定点観測する
など
-->




HOW
==
<!-- 出してほしいデータのイメージがあれば記載してください -->


WHEN
==
<!-- 希望期日を記載してください -->

意思決定に寄与している度合いを定量

冒頭でも触れましたが、Rettyのデータ分析チームの最大のバリューは意思決定の最大化です。

そのためのデータ分析であり、日々データアナリストは意思決定をデータ分析によって推進しています。

その中でデータ分析チームとして意思決定にどの程度寄与しているのかを測定しています。

ISSUEにスクラムポイントとベネフィットポイントをラベリング

具体的にどのように測定しているかをご紹介します。

前提としてRettyでは分析案件を全てISSUE化しています。

そのISSUEごとに、スクラムポイントとベネフィットポイントのラベルを付与しています。

f:id:rettydev:20181216151431j:plain

図の

  • P = スクラムポイント
  • B = ベネフィットポイント

を表しています。

それぞれの意味としては

  • スクラムポイント:分析にかかる工数
  • ベネフィットポイント:分析によって引き起こされる意思決定の大きさ

数値ごとのものさしとしては

  • スクラムポイント

    • 1: 5分~1時間以内(瞬殺)
    • 2: 2時間以内(楽勝)
    • 3: 3時間以内(ちょっとかかるが何をやるかが明確)
    • 5以上: 5時間以上(案件の内容が抽象度高く、難易度が高い案件)
  • ベネフィットポイント

    • 0:意思決定に使われていない
    • 1:やや意思決定に使われた
    • 3:ミッション単位の意思決定に使われた
    • 10:部門単位の意思決定に使われた

くらいでまだアバウトですが、やりながらものさしを修正していく予定です。

毎週のチーム定例会でチェック

Githubのデータは全てBigQueryに蓄積される仕組みを導入しています。詳しくは、以下記事に紹介されています。

ベンチャー企業におけるDWH DevOps @ Retty - Retty Tech Blog

このデータを元にダッシュボード化し、毎週行う分析チームの定例会でチェックをしています。

主に確認する指標は3つです。

この指標をチーム、メンバー、ミッションとセグメント分けを行い、Weekly単位でチェックしています。

ベネフィットポイントの最大化をメイン指標としていますが、コスパポイントも気にしています。 工数がかかるのにもかかわらず、意思決定に繋がっていない案件を極力減らしたいからです。

このように、必ずしもこの指標だけで分析チームのバリューを図っているわけではないですが、参考指標として活用して分析チームのバリューの向上もデータドリブンで行っています。

③データの民主化


データの民主化とは何か

そもそもデータの民主化とは何か? ここでは勝手に組織全体がデータを活用するための取り組みや、その状態(文化的なもの)を表す概念とします。

Rettyでも組織全体のデータドリブンレベルを向上させるために以下を取り組んでいます。

  • 分析難易度ごとにデータとの接続方法を最適化
  • 組織全体のデータ活用風土の醸成
  • 分析チーム自体の強化

分析難易度ごとにデータとのアクセス方法を最適化する

プロダクト開発をする部門だけでもミッション数が10個程に対してデータアナリストは5名、全ての分析案件を引き受けていたらリソースが足りません。
では単純にツールを導入すればいいのかというと、そうではないと思います。
人やチームによってデータに対するリテラシも違えば、データ取得の難易度も欲しいデータや分析によって異なります。

そのためRettyでは分析の難易度によってデータへのアクセス方法の最適化を図っています。

<図:分析難易度によってデータへのアクセス方法を最適化> f:id:rettydev:20181216164924j:plain

補足:「ツールでみる」はダッシュボードなどでGUI操作さえ覚えればデータにアクセスできる方法のことです。

このように分類することで、データアナリストに簡単なデータ出し依頼が集中するようなことを無くし、データアナリストだからこそできる難易度の高い案件に集中できるような状態を作っています。

組織全体のデータ活用風土の醸成

上記の最適化は分析難易度によってデータへのアクセス方法を分類することで最適化を図っていますが、そのデータへのアクセス方法の強化も必要です。
組織全体のデータ活用風土の醸成は、分析難易度小〜中のデータアクセス方法を強化する取り組みとなっています。

良く見るデータはグーグルデータポータル化

みんなが良くみるプロダクトの主要数値に関しては、グーグルポータル化していっています。 こちらに関しての取り組み内容は、

ベンチャー企業におけるDWH DevOps @ Retty - Retty Tech Blog

に言及されているのでこちらでは割愛します。

モチベのあるPM/プランナーを育成

各ミッションに一人くらいはデータが好きでSQL等への学習モチベが高い人材がいるはずです。
先程定義した分析難易度の中くらいまでをやってくれるようになると大分負荷が減りますし、実際にデータを見たい人が出すほうが分析効率も高くなります。
そういった人材を見つけ以下のような育成を行っています。

  • SQL問題集の提供
  • 朝のSQL勉強会
  • bigquery_studyという、Slackチャンネルで質問に答える

SQL問題集の提供はSQLが書ける人でも、データアナリストの新人さんにも向いています。
問題集は実際の業務で使ったことのあるデータ出しがほとんどなのでドメイン知識のインプットにも繋がるためです。

簡単なクエリは、二度と同じクエリを書かないくらいの気持ちでVIEW化していく

難易度が低のクエリはどんどんVIEW化していってます。

例えば、単純に投稿に関するデータを出すといっただけでも

  • ユーザー
  • お店
  • 日付(Daily、Weekly、Montly)

といったセグメントや

  • 投稿数
  • 投稿UU

といった指標の単位もあります。

これらを毎回素のテーブルからクエリを作るのは地味に時間を使ってしまいます。

そのためRettyでは、こういうったデータ出しを行ったら極力VIEW化するように心が得ています。

この取り組みを行うだけで、データアナリスト自身のデータ出しの工数削減だけではなく、クエリの難易度が下がるため、データアナリスト以外の方でもデータが出せるようになります。

分析チーム自体の強化

分析難易度大のデータアナリストと分析チームを強化するための取り組みも行っています。

朝会でタスクの見える化

Rettyの分析チームでは毎日朝会を行っています。
ツールはGithubのprojectsを使っていて以下カラム構成で管理しています。

  • Want to doカラム
    • これほしいとか、やりたいを追加する場所
    • やると生産性が上がるようなものだが緊急度が低い案件が追加されるイメージ
    • いつかやりたいと思っていたことを忘れないないようにし、余裕のできたタイミングで着手するために存在している
  • New Issueカラム
    • ISSUEのprojects欄に設定されると自動的に追加される場所
    • 主に依頼型案件のISSUEが追加される
    • 優先度を適切に付けるために全てここを通るようにしている
  • ミッション名カラム
    • 派遣しているミッションごとにカラムを用意している
    • 派遣先でタスクが発生したらここに積むようにしている
  • 個人名カラム
    • 分析チームメンバーごとにカラムを用意している
    • 今現在持っている案件を見える化されるようにしている

f:id:rettydev:20181217213927p:plain

上記、Github projectsを大きいディスプレイに映しスタンドアップ形式で

  • New issue/ミッションごとのカラムを確認
    • 新しいISSUEが追加されたらここで割り振る
  • 個人のタスク共有
    • どのような分析を、なぜやるのかを話す
    • WHATとWHYの説明を行うことで、メンバーが全体の動きをキャッチアップできるようにしている
  • 連絡/共有事項
    • 個人的な勤怠連絡や勉強会に言ってきた感想などを話す

この朝会を通して、効率的なタスク割り振りとチームの親和性の醸成を図っています。

チームでの定例による分析評価会

毎週1時間でチーム定例会を行っています。
ここでは、

  • コスト/ベネフィットポイントの確認
    • BigQueryのコスト推移(コスト意識)
    • ベネフィットポイント推移(バリュー意識)
  • 派遣先のミッション目標進捗の共有(目標達成への温度感をチームで認識し助け合う)
  • 分析アウトプットの評価(データアナリストの強化)

を行っています。

データアナリスト自身の強化観点だと、分析アウトプットの評価がそれにあたります。
Githubに分析アウトプットとSQLを蓄積で紹介したPRをベースに、問題設定から分析設計〜分析結果から最終的にどのような意思決定に使われたかまでを全て説明し、それに対してみんなでフィードバックをしています。
普段はそれぞれ派遣先のミッションで業務を行っているため、アウトプットを見る機会が少なくフィードバックの機会が設けられないため、この場を作りデータアナリスト自体の強化を図っています。

最後に


ここまでが今年データ分析チームを立ち上げて行ってきたことの紹介でした。 とても長い記事になっていまいましたがここまで読んでくださった方ありがとうございます。

データ分析チームを立ち上げるベンチャー企業に少しでも役に立ちたい

プロダクトを自社で使っているベンチャー企業におけるデータ分析チーム、個人としてデータアナリストやデータエンジニアの役割って歴史がそこまでなく、定まっていないのが実際だと思います。

そのため、このような事例を発信することで新しくデータ分析チームを立ち上げようとしているベンチャー企業に少しは役に立つのではないかと思っています。

なぜそう思ったか?私自身、今年4月からデータ分析チームを立ち上げるにあたって、メルカリの樫田さんが書いた記事メルカリの分析チームとは?その全ての疑問にひとつひとつ答えます - Mercari Engineering Blog にかなり助けられたからです。(注意:樫田さんのステマではありません)

その経緯から本記事は、上記記事に記載されている内容と似ている箇所が多分にありますが、非常に参考にさせていただいたからです。

その中でもRettyならではの取り組みを紹介することで、お役に立てればと思ったのが本記事を書いた理由の一つです。

Rettyでデータ分析を行うことの魅力を伝えたい

組織全体を動かす意思決定を担える

今年の4月に立ち上げて組織全体の意思決定を最大限化するための取り組みを行ってきましたが出している成果についてもお伝えします。
詳細にはお伝えするのが難しいですが、事業インパクトの観点だと、
KPIの数値向上のために営業組織全体にアクションをしていただくような意思決定
組織力向上の観点だと、
データドリブンで目標を構造的に達成するためのデータ活用の仕組み化など、
ミッションや組織全体に対する大きな意思決定や、組織力強化に貢献することができます。

組織を動かすような意思決定はプレッシャーが掛かりますが、その分事業に貢献できる量も大きいので非常にやりがいがあります。

来年はレコメンド/機械学習を用いた課題解決に本格注力する

先日のプレスリリースの通り月間4,000万以上のユーザーさんが利用しているRettyには、アクセスログの他、全国のお店情報、1,500万件超の投稿画像、数百万件の口コミ投稿数、アプリ内のSNSデータを保有しており、飲食という誰もが課題として持ちやすい領域に対して、このデータを活用して解決できる課題に可能性を感じています。

データ活用という点で現状は意思決定という点でバリューを発揮していますが、来年はデータを活用した機能開発(レコメンドなど)によるユーザー体験の向上をテーマとして活動する予定です。

グルメ領域は自分自身もユーザーになれるのでやりがいを持ちやすいですし、Rettyにはグルメ領域の深くて種類の多いデータが大量にあるため、そのデータを使って価値を届けたいと考えている方にはとてもおすすめできる会社です。

少し先の未来の話し/Yahoo!との取り組みについて

今後Yahoo!との取り組みにおいて決済領域にも踏み込むことから、さらにユーザーさんの外食体験をよくしていける可能性を感じています。

その取り組みは様々ですがその中の一つとして決済情報を使いユーザーさんの外食体験を向上したいと考えています。
まだ何も決まってはいませんが、中国のテンセントとグルメサービスの大衆点評の決済情報を使った取り組みであるような、いつ誰がどこで何を食べたか、といったデータを活用した取り組み(例:メニューランキングの提供、注文をアプリで行える)ができる未来も全然あると個人的に思っています。

決済領域に関して取り組めるチャンスは中々ないので、そこへ取り組めるチャンスがあることは魅力かと思っています。

データ分析チームを創る側に回れる

このようなサービスやデータ的魅力だけではなく、今年の4月立ち上げということや現在6名(内定者を含めて)と少数であることから、自らがデータ分析チームを創る側に回れるフェーズであることも魅力ポイントだと思っています。

仲間募集しています

ここまで読んでくださりありがとうございました。

少しでもいいなと思った方、もっと話を聞いてみたいなと思った方お気軽に平野までご連絡ください。

データアナリスト及びデータエンジニア、MLエンジニアの採用を募集しております。

hrmos.co

*1:Rettyではプロダクトの開発を行うプロダクト部門というグループ単位があり、その下層に特定のKPIをグロースさせるためのミッションというグループ単位で構成されています。

Rettyレコメンドプロジェクト

Rettyでデータサイエンティスト兼うなぎ担当をしている岩永二郎です。
さて、今回はうなぎの話、、、ではなく、レコメンドプロジェクトのお話です。
2018年11月、オペレーションズ・リサーチ学会研究部会 最適化とその応用 (OPTA)にて講演してきた際のスライドを本ブログにて公開します。 以下にスライドを掲載し、本記事にていくつか解説をします。

発表スライド

www.slideshare.netRetty recommendation project


解説

以下にスライドのサマリを抜粋しました。

【お店レコメンドの取り組み】

2017年10月〜2018年9月の期間で開発したレコメンドモジュールのプロジェクト紹介をしました。 データサイエンス系プロジェクトはスキルだけあってもうまくいかない、というのは駆け出しのデータサイエンティストの多くが感じることです。 プロジェクトを推進するためにはスキルだけではなく、企画、設計、運営、実装、保守、運用など様々な課題をクリアしていかなければなりません。 データサイエンス系プロジェクトのケーススタディとして読者の参考になれば幸いです。

本プロジェクトは3つのフェーズを踏んで開発しました。

  1. レコメンドロジック実装
  2. デザインブラッシュアップ
  3. 配信最適化

それぞれのフェーズで何がポイントになり、どのようなプランニングをしたかについてはスライドをご覧ください。 ざっくりまとめると次のメッセージを伝えたいと思っています。

1. レコメンドロジック実装
  • レコメンドはユーザーさんの心理と理想の体験をイメージして設計する
  • レコメンドの勘所は「コンセプト」「ロジック」「デザイン」の3つ
  • DBをインターフェースにデータサイエンティストとWebエンジニアが作業分担できると開発効率がよい
  • 網羅的に実験することでユーザーさんのニーズがわかる
  • サイトの鮮度を保つためにランダム性を取り入れる
  • 「似ているお店」を数式で表現する
  • データの特性に合うアルゴリズムを選択する
  • データの質が良ければ簡単なアルゴリズムでもよいレコメンドになる
  • リリース前は定性評価、リリース後は定量評価に重みを置く
  • 保守・運用を意識した実装をする
2. デザインブラッシュアップ
  • アルゴリズムで伝わらないレコメンドのキモチをデザインで伝える
  • 情報設計の重要性と情報量のトレードオフを理解する
  • レコメンドの理由を表示しているサービスは国内には少ない
  • レコメンドのインパクトはロジックとデザインの掛け算で決まる
3. 配信最適化
  • レコメンドの質を高めて最後に量(価値)に変換する
  • バンディットアルゴリズムが効果的に適用できる条件を理解する
  • ElasticNetで過剰適合を避けたCTRの予測を行う
  • グロースを意識して適切な順序を踏み、定量的に成果を評価してプロジェクトを推進する

もし、上記の内容にご興味を持ちましたら是非ご一読いただると幸いです。

追記:プロジェクトのスピード感

本発表で話せなかったことにプロジェクトのスピード感があります。 データサイエンス系プロジェクトは時間がかかる上にリスクが高いため、適当なタイミングでプロジェクトの継続判断をする必要があります。 決められた期間で成果を出して継続判断をするためには実装すべき機能に集中し、必要ない実装を捨てる柔軟さが必要です。 例えば、本プロジェクトの場合、次のような開発期間で実装を進めました。

  • プロトタイプ実装フェーズ:1週間
  • PoC実装フェーズ:2ヶ月
  • サービス実装フェーズ:2ヶ月

プロトタイプ実装フェーズでは、インパクトの検討がつけばよいのでBigQueryから手動でデータをダウンロードし、Jupyter LabにPythonでべた書きをするという実装で済ませました。
PoC実装フェーズでは、インパクトが出るモデルを見つけることが重要なため探索的にデータ解析をする必要があります。 そのため、プログラムの自動化、および高速化、さらにはレコメンド結果の可視化の実装に集中して、実験と検証をストレスなく行える環境を優先的に実装しました。 このフェーズでは決められた期間内でどれだけ試行錯誤を繰り返せるかが重要であり、レコメンドの精度に直結してきます。 サービス実装フェーズでは、エラー処理やテストの実装に加え、柔軟にソースコードを改変できるように適度にモジュール化と関数化をしました。
また、プログラムが想定通りに動作しているかを検証する環境も必要になります。 いずれのフェーズにおいてもリファクタリングを繰り返し、そのフェーズに合った品質の実装に書き換えていきました。

時と場合によってプログラムの品質を変えることに気持ち悪さを感じるエンジニアは多いと思います。 しかし、開発期間内に目的に合わせて柔軟にプログラムの品質を変えるスキルは、 プロジェクトの推進力を上げ、最終的にプロジェクトの成功率を上げることに繋がります。 エンジニアの成長の1つの方向性として一度は意識して取り組んでみてはいかがでしょうか。

【閲覧履歴レコメンドの取り組み】

本発表の短編集として紹介した取り組みです。 ユーザーさんの閲覧履歴に含まれるアイテムに興味のスコアをつける方法の紹介になります。 一般にアイテムへの興味は「何度も閲覧する」「最近閲覧した」という事実に関連が強く、 この性質を数理最適化問題(凸二次計画問題)にモデリングすることでアイテムにスコアを付与します。

本手法は広い意味では機械学習におけるパラメータの推定を制約付きで学習するという提案になります。 また、よりサービスに近い観点ではパラメータ推定の時点ですでに知見がある場合にはその知見を制約に加えて学習することで より精度の良いパラメータ推定ができ、過学習も回避できることを示唆しています。 なお、こちらの手法は私が所属している研究チームが長く研究しているテーマなので、興味がありましたら次の参考文献をご一読いただければと思います。

参考文献

【お店口コミレコメンドの取り組み】

本発表の短編集として紹介した取り組みです。ユーザーさんがサイトから情報を取得する際の効率をテーマにしています。 CGMサイトにおいて情報(本問題では口コミ)が多すぎることでUXを損なうケースがあります。 本取り組みは文書要約技術(自然言語処理&数理最適化)を用いて情報の取得効率を改善させる提案を紹介しています。

また、PoC実施の際の検証方法も紹介しています。 本取り組みは社内でプレゼンを行うことでモデル検証をしたのですがいくつか仕込みをさせていただきました。

  • オンライン検証環境の用意:発表中に全員が検証に参加できる
  • オンラインアンケートの用意:発表中に全員から知見を集めることができる

実際の現場では個人の感性でモデリングしてしまうことが多いので、このような方法を利用することで多くの人の意見を取り込んだ定性評価を行うことができます。 自分ひとりでは気がつかない、意外なアイデアが得られるのでみなさまも一度、試してみてはいかがでしょうか。

【お店写真レコメンドの取り組み】

本発表の短編集として紹介した取り組みです。 お店ごとに魅力的な写真を選び出すというタスクの紹介です。まだまだ実験段階ですがサービスならではのポイントがあります。 一般的な魅力的な写真抽出の課題は主にピクセル情報を利用することが多いのですが、本取り組みではピクセル情報に加えて次の情報も利用しています。

  • EXIF情報(メーカーのカメラで撮ったなど)
  • 投稿情報(投稿の中で何番目に指定した写真か)
  • 投稿者の情報(フォロワーが多いユーザーさんの投稿か)

実際にRettyの投稿写真で実験してみてわかりましたが、ピクセル情報以外の情報も魅力的な写真判定に大きく寄与します。 これは画像解析がキラーコンテンツになるサービスを作る際には画像以外の情報も集めることでよりよいサービスにできるということです。 画像解析をサービスに繋げたいと思っている方にはご一読いただきたい内容です。


今後の取り組み

レコメンドプロジェクトはユーザーさんのニーズと数値的な成果を確認できた上で一旦終了となりました。 今後はRettyの内部にとどまらず、外部にレコメンド技術を提供していくことを検討しています。 具体的には、Rettyの店舗データ、CGMデータに加え、上記で開発したレコメンド技術を外部に提供していきたいと思っており、 実際に2018年10月よりRettyではデータコラボビジネスに向けた外部との取り組みを開始しました。 これはRettyのデータを全く別のサービスで利用することで新しいユーザー価値を創り出し、課題解決をしていくことを目的としています。

もし、ご興味がありましたら iwanaga@retty.me までご連絡ください。 新しいサービスについてディスカッションしましょう!

おわりに

昨今、データサイエンスの流行りもあり、様々な記事やコミュニティ、セミナー等が増えて入門の間口は広くなりました。 一方で、データサイエンスを実務に適用してインパクトを出す障壁は高く、多くのプロジェクトが頓挫し、志半ばで消えていきました。 これは今にはじまったことではなく昔からあるAIブームのたびに繰り返し起きていることです。 本ブログはデータサイエンス系プロジェクトに関わるデータサイエンティストのプロジェクト成功率を少しだけでも高められることを願って執筆しました。

謝辞

本資料は以下の発表を通して完成させました。お声をかけていただいたみなさまに感謝致します。

また、本取り組みのWebエンジニアリングまわりで貢献いただいた淡島弘吏様、久郷亮太様にも深く感謝致します。

ベンチャー企業におけるDWH DevOps @ Retty

※ Retty Advent Calendar 15日目の記事です

おしながき

はじめに

 Rettyでは施策の実行や目標設定といった様々な場面で
データを積極的に活用しながら日々の業務を回しています。

"データ活用" という言葉は今でこそよく聞く言葉ですが
その実現のためには行うべきことがたくさんあるため苦労しています。

今回は、ベンチャーとしてのデータ基盤の取り組みの一例として
その活動をご紹介できればと思います。

お送りするのはソフトウェアエンジニアをやっています @takegue です。

f:id:rettydev:20181215092108p:plain

ベンチャー企業とデータ活用

データ活用は、昨今の企業では当たり前に言われているようなことで
今さらなぜ苦労するの?とか思いの方もおられるかもしれません。

まずはそのあたりからつらづらと述べておきたいと思います。

完璧さよりも早さを重視する

"Done is better than perfect" という言葉が尊ばれるように
とりわけベンチャー企業では「完璧さ」よりも「変化の速さ」を求める傾向にあります。これは
「考えて考えて考え抜いて結論を出す」 よりも
「一旦出して反応をうかがってみよう。ダメだったら次に行こう」ということです。

データ活用の主たる用途の一つである分析という行為は、専ら前者に属する行為です。 「1ヶ月分析に時間をかけて現場にとっては当たり前の事実しかわからなかった。」ということは我々にとっては致命的で、ともすれば "分析自体は価値である" だとわかりつつも 単純に"分析という行為"に時間をかけつづけてしまうことは 避けたいコストになります。 そのため一種の矛盾を抱えてしまいやすくなります。

ベンチャー企業におけるデータ活用の難題の一つは、こういった環境のもと より短期間でより効果的な分析を行える環境を整えていくことにあります。

Rettyにおける現状

短期間で効果的な分析を行なっていくための環境としては、データの集約的な場である データウェアハウス (以下DWH)をはじめとしたデータ基盤を構築できることで活用の速度がより進むことになります。 しかしながら、この基盤開発は企業ごとのフェーズやデータ活用に対する温度感によって課題も実体も千差万別になります。

規模が小さい企業ほどデータでわからないことの方が多くDWHのROIに懐疑的になるでしょうし、成熟した企業ほど完成されたセクショナリズムが活用の大きな壁になることが必至です。

Rettyの現状は、ちょうどこのこの中間の状態で スタートアップというほど小さくないためデータもありますが、 大企業というほど障害となるセクショナリズムは確立されていない状態にあります。 だからこそですが、DWHの方向性や有用度を決める大事なフェーズで 様々なことを実験しつつ利用価値を最大化していくべきえ大切なタイミングと考えています。

DWHの開発で大切にしていること

RettyのDWH開発で大事にしているのは端的に言えば
基盤 としての側面よりも プロダクト としての側面を重視していくことです。

プロダクトとしてのUXを大事に

もっとも大事にすべきは "使われるDWH" であることです。使えないデータをため続けるDWHはゴミ集積場となんら変わりありません。そのためにDWHを一つのプロダクトとしてUXを改善していくことが必要であると考えています。

  • よく行う分析ほど手早く実行できる状態になっているか?
  • データを見る側がデータを使う効果を実感できているか?
  • 使いたい思えるデータをDWHが取りそろえられているか?

こういった観点をふまえながら、プロダクトとしての改善を行なっていきます。

DWHのUXを考えていく上で最も難しい点は、作る側/使う側にも少なくない技能を求める点にあります。 データがあれば何ができるのか、 何が分かるのか?意図したとおりの分析をするためには、どのようなデータがあれば良いのか?信頼足りうるデータを整備していくにはどのようにシステムを作れば良いのか?といったことにある程度の下地が必要となります。

データは味方にできれば強力な武器で、それこそ使う人が使えば生産性を数十倍にするほどの武器です。ですが使い手によって効果が全然変わる代物でもあります。 時には、これらを伝えるためDWHを作り運用していく側が啓蒙し活用を進めていくことも大事になります。 利用者の立場になってみて、はじめて気づく改善点も多々あります。

プロダクトとしての変化を大事に

データ活用のニーズを柔軟に捉え、変化していくためには DWHというプロダクトも変化できるという下地が必要です。

ユーザ規模の変化、プロダクトの方向性の変化、社内のニーズの変化などなど これらの変化に耐えうるように設計/開発を行なっていきます。その変化を許容するために早すぎる最適化をさけることも大切と考えています。

開発者として横断的な動きを大事に

DWHは様々なサービスでのパイプライン処理になることが多いですが

DWHのUXを追求をしていくことが大事とはいえ
ベンチャー企業のような人数規模が大きくない会社では 常に人手不足というリソースの問題がつきまといます

以前の記事 Webサービスを支えるユーザログ基盤開発@Retty において、開発中のRettyのログ基盤についてご紹介する機会がありました。 技術スタックとしてはフロントエンドに属する話でしたが この開発はDWHというプロダクト開発の一環として行っています。

DWHの開発では各工程で分担し、開発効率化を図ることの方が多いと思いますが 全体として開発を通してできるようにすることで サイロ化を防ぐことができます。

このような動きをするためには、開発者としてのフットワークの軽さだけではなく 同時に要素技術を絞るといった動きも必要になります。

RettyにおけるDWHの開発プラクティス

ここでは具体的に我々がどのようにこれらを実現しているか、 どのようなツールを使っているか紹介していきます。

DWHそのものだけではなく、DWHの利用を推進する周辺の道具は 生産性を高めるために必要な道具になります。 これらを紹介していければと思います。

BigQueryを中心としたデータ基盤

RettyにおけるDWHは現在BigQueryを中心に構築をされています。 そのため分析者の観点では、BigQueryをさわる(=SQLを書く)ことができれば あらゆる分析ができる状態になります。

BigQueryの良い点は、分析者が使うときの関心事がとても少ないことだと考えています。 SQLでスキャンするデータ量さえ気にしていれば基本的に問題はありません。 ストレージや分散ノード、それに伴うコスト計算などなど 本来であればこれらの要素を考える必要があるのですが、 BigQueryではこれらがうまくブラックボックス化されており、驚くほど簡単に使えます。

このような素晴らしいサービスであるBigQueryを中心に据えたことで 少人数でも驚くほど利用価値の高いDWHの構築/運用を行うことができます

アウトプットを最大化するためのダッシュボードツール

ダッシュボードツールは、分析に携わるものとして大きな悩みの一つです。

  • 頑張っては作ったものはいいものの、結局誰もみなかった
  • 簡素すぎると資料としての価値が低く作った人にしか理解できない

といった問題がよく起こります。

スプレッドシートによるお手軽ダッシュボード

BigQueryではスプレッドシート出力の連携を簡単に行うことができるため 単純なデータ出しや探索的調査ではスプレッドシートが活躍します。 複数の調査結果をまとめたり、小回りが効きやすいため9割ぐらいの用途で スプレッドシートで十分なことが多いです。

ただ、分析をこなしていくうちに チームごとに定期的に見たい指標だったり 集計作業を単純化するため定期的に自動実行したいことが増えてきます。

Rettyではこれを実現するために、 自由に使える簡単なSpreadsheetのバッチ処理のランナを用意しています。 中心的な機能は、「定時にBigQueryのクエリを実行してスプレッドシートに反映する」だけです。

f:id:rettydev:20181209180736p:plain
スプレッドシートによるクエリ管理

ユーザは、定期的に実行したい行を追加してSQLを貼り付けるだけで 簡単に定期実行するSQLを追加することができます。 またスプレッドシートに貼られたグラフを特定のSlackチャンネルに 貼り付ける機能もあるので、例えば移動中などの間にグラフデータを確認するなどの利便性もあります。

redashなどでも同様のことは実現できますが

  • サーバなどのメンテナンスコスト
  • グラフなどのデータ処理能力/表現能力
  • ダッシュボードの利用度の監視 とその運用

といった面でデメリットと
全てのダッシュボードツールでいえることなのですが、 ダッシュボードツールに合わせたSQLの書き方、みたいなものが必要になります。 スプレッドシートとピボットテーブルを使った手軽さがまさりつつあります。

データポータル (Datastudio)

先ほどいったようにダッシュボードはその運用がされづらい、という問題をはらみます

運用されなくなったダッシュボードは正確さ等にかけ 間違った判断をもたらすことになるため、「運用されなるぐらいなら作らない」 というのは一つの解ではあると思います。

一方で、

  • 浅い分析の回数を減らすために優れたダッシュボードを一つ用意する

も一つの解になりえます。

どちらもできる手段を用意しておくことが、大事であると考えています。

そんな時の手段として, データポータル(旧: データスタジオ)を利用したりします

データポータルが素晴らしい点は

  • パワーポイントの様なグラフィック面での柔軟さ
  • データを深掘りするインタラクティブな操作

を簡単に実現できることです。

具体的な数値等は伏せますが、 例えば以下のようなダッシュボードを簡単に構築することができます。

f:id:rettydev:20181211071013p:plain
ユーザ行動分析のためのダッシュボード例: フィルタが実装されておりインタラクティブに分析ができる

弊社のデザイナさんと共同して作ったものですが、上記の1ページで

  • 経路別での遷移率の確認
  • バイス別の遷移率の確認
  • 任意の期間での集計および前期間との変化の比較

といった操作ができるようになっています。

データソースのUX/DX

どのように情報を提供するか? 改善するか?

データソースの集約化

SQLを覚えればあらゆる分析が行える」状態を実現するために サービスに関するあらゆる情報をDWHに集約化していく必要があります。

ユーザイベントのログ、DBのマスターデータといった点はもちろんのこと サービスのパフォーマンスメトリクス情報やシステムログ等もDWHに集約していきます。

さらに一歩踏み込んでサービスに追従する開発者のアクティビティの情報も RettyではDWHに集約しています。

例えば Githubの通知データです。

  • いつissueが作成されたか?それが解決されるまでの時間は?
  • Pull Reuqestのレビューまでの時間
  • 個人に関するOrgnizationにおけるコミット量

これらの情報が現在のRettyのDWHには集約されており 必要とあれば個人の開発に関するパフォーマンス情報の集計することも可能です。

コストに関するデータをDWHに入れてしまえば、ROIも確認できますし どこがコストのボトルネックを占めているかも一目瞭然となります。

個人的には、DWHに入れるデータソースは 必要とされる前に入れておく、ことが大事だと思います。 これはデータを必要な形に加工する時間よりも有益なデータがたまるまでの時間の方が長いからです。

なぜなら、データはいれはじめてから貯まるまでに時間がかかるためです。 多少使う頻度が少なくても、あるとよそうだなとおもったものは 雑でも良いので先にDWHにいれるようにしています。

本格的につかうようになったタイミングで、安定的に稼働かつ 使いやすい形に加工します。

As-is ではなく As-was

データベースなどのテーブルの転送を行うときには その時の最新の状態ではなく、当時の状態が再現できるようにしましょう。 アプリケーションのロジック等によるデータの加工もふまえて データの投入が行えるとより良いでしょう。

分析者も巻きこみDWHの品質改善を行っていく

より効果的なDWHを作るためには、使う側の観点を持ちながら整備していくことが大事です。 そのために心がけていることは、「分析者でも」品質改善を行えるように 全体像の開示および開発の余地を広く保つことだと考えています。

技術スタックはSQLを中心とする

分析者と協調的に開発するために、おおよその部分がSQLだけで 開発等が行えるようにします。

このための動きとして

  • データのパイプラインをSQLで触れる範囲に移行する
  • SQLで開発がしやすいように環境を整えていく

動きを行う必要があります。

仮想テーブル (View) <-> 実テーブル による スキーマのPoC

DWHにおけるテーブルは スター型スキーマ と呼ばれる
正規化された状態ではなく様々なテーブルが結合された非正規化の状態が好ましいとされています。

これには

  • 分析者が必要とするテーブル構造の負荷を下げるため
  • カラムナ型DBではインデックスや外部制約などの制約が課せないため非正規化しておく必要がある

といった理由からです。

非正規化された状態というのは意外と取り扱いが難しく

  • DBのスキーマの変更など上流の影響を激しく受けやすい
  • 全て繋げてしまうと、今度は巨大なモノリステーブルができDXが悪くなる

という問題が発生します。

このために「現場のニーズに合わせた迅速な変化が可能な」スター型スキーマを用意する必要があります。

ここで活躍するのは BigQueryのview機能です。 viewはデータベースにおける仮想テーブルで、利用者にとっては実テーブルののように振る舞いますが、実体は実テーブルに対するただのSQLです。

これをどう利用するかというと、弊社ではview機能を用いて
「分析者が使いやすいテーブル 分析者 がつくります」

このために原則viewと実テーブルの区別をつけないようにSQLを書くようにします。 そしてこのview自体は分析者らが中心に洗練していき、あるタイミングにおいて実テーブルに差し替えます。

BigQueryのビュー機能を活用することで、UXにたったテーブル開発ができます。 またその開発はBigQueryで全て閉じるため敷居が低くなります。 なおかつ分析者でもDWHの機能開発を行うことができるようになります。

実テーブルに差し替えるタイミングで、バッチ処理を記述することになりますが それはviewのSQLを実行するだけなので、バッチ処理への組み込むのも簡単です。

SQLによるView/データソースのユニットテスト

SQLを中心とした開発の最大の難点は

他人が書いたSQLは読めない ことが挙げられます

コード規約や WITH句をはじめとした CTEを使うことで
ある程度見やすいようにSQLを書くことはできますが

  • 入力(元テーブル)のデータに関する知識が不足していて入力想定しているかわからない
  • 出力における制約 (どのカラムでユニークを想定しているのか ) も記述した本人しかわからない

といった、SQL自体が非常にコンテキストが高いものになりやすい性質があります。 これらがSQLが属人化するだけでなく分析の質を担保しづらいものにする最大の原因で チーム開発を妨げる最大の障壁と考えています。

そこで弊社では

SQLテスト駆動開発ができる仕組み」 を提供し 分析者がSQL自体のテストを記述できるよう にしています。

f:id:rettydev:20181211071536p:plain
SQLによるCIの様子

BigQueryのViewは利用されないviewを含むこともできるので、 特定のprefix (図中では __check ) を テストケースとして認識して CI等でテストを稼働させるようにしています。

この機能自体は、実テーブルでもViewでも同様に利用できるため様々な検証を SQLで完結することができるようになります。

例えば、以下のような確認項目をSQLで確認することができるようになります

  • ユニーク制約の確認用途: 安心して group by / joinができる
  • カーディナリチェック: 意図しない属性が増えていないか確認できる
  • 異常値: データソースの問題かSQLの問題かの切り分けに有用
  • ありえない組み合わせの確認 → データソースに対する制約の記述
  • データskewの確認: (-> Performanceに直接がでる)

おわりに

これまでの取り組みを色々振り返って整理しているうちに、思わぬ大作になってしまいました。 ここまでお付き合いいただきありがとうございした。

最後にお決まりになりますが、 Rettyではサービスのデータ基盤開発を担う人材を絶賛募集しております。 データ活用の方向性や利便性を高めてつつ、自らデータ活用していくような
カオスですが面白いフェーズにあります。 この面白い世界で一緒にやりませんか? ぜひお待ちしております。

corp.retty.me

Retty新卒エンジニアの入社半年間の振り返り〜Part.3〜

Retty新卒エンジニアの堤です。 入社して半年ほど経過して、ようやく仕事も身についてきました。 私はアドテクチーム1に所属しているので、チームの紹介と入社してからの仕事内容についてお話します。

自己紹介

好きな言葉は「ご飯おかわり」です。
しかしオフィスが麻布十番にあるため、量を食べようと思うと、ただでさえ高い食費が大変なことになってしまうのが最近の悩みです。

Rettyに入るきっかけですが、オフィスに話を聞きにいった時期にちょうどアドテクチームの立ち上げの話を聞きました。プロジェクト立ち上げ初期にJoinしたいこと、競技プログラミングをやっていた関係でアドテクに興味があったこと、さらには食べることも大好きだったことからRettyに入ることを決め、アドテクチームに加わりました。

f:id:rettydev:20181204180754j:plain ▲入社式での自己紹介の様子

チームの紹介

広告とは

アドテクチームは、Retty内のインターネット広告を運用する仕事をしています。

インターネット広告と聞くと、あまりいいイメージを持たない人もいるかもしれません。私自身、もともと広告って邪魔だな、と思う派の人間でした。ただ、広告の裏側に触れていくにつれて、広告の面白さを感じるようになってきました。

私が思う広告の面白さ、重要性は大きく3つあります。

  1. 0.1秒間で行われる広告オークションの仕組み
  2. メディアの収益源であるという点
  3. ユーザーと企業とのマッチングという考え方

本記事では広告の説明はメインではないので、1について以下で少しだけお話します。

広告オークションという仕組み

広告も出し方によって大きく2つに分けられて、

  1. 広告主とメディアが直接やりとりし、期間と金額を先に決めて広告を出す
  2. 間に広告事業者が挟まり、ユーザーのメディア訪問の際にリアルタイムに広告を出す

このうち、アドテクチームは2の広告を担当しています。本記事では、特別な記述がなければ、広告はこちらを指すこととします。

メディアで広告が出されると、広告のリクエストが広告事業者に飛びます。事業者側では、

  • メディア
  • 広告枠の過去実績(Click率など)
  • ユーザー属性(Cookieなどから識別)

を判断材料として、広告枠に出稿する広告を募集します。時間内に最も高く入札した広告が、広告枠に出稿する権利を購入します。この広告オークションが事業者ごとに秒間数百、数千万も捌かれています。もともと私自身競技プログラミングにハマっていた時期もあったため、この裏側の仕組みにはわくわくします。

ちなみにこの仕組みはReal Time Bidding(RTB)と呼ばれ、もともとは金融系で用いられていた仕組みだったらしいです。

詳しい仕組みについては「広告 仕組み」などで検索してみてください。

チームの仕事

アドテクチームでは、上記RTBによる広告の運用をしています。主には、

  1. 新規広告事業者と連携し、収益の底上げ
  2. 広告オークションに関わるパラメータの調整
  3. その他収益に繋がりそうなシステムの導入

1, 2については定常的に行っているものになりますが、大きく収益につながることが多いのは3になります。特に、最近ヘッダービディングという仕組みができて取り入れたことにより、10%〜20%の広告収益向上に繋がりました。

収益以外に、広告の質についても責任を負っているので、Rettyのメディアに相応しくない広告(暴力的なものなど)や、強制リダイレクト広告のようなユーザビリティを侵害するような広告をいかに防ぐかなども日々検討しています。

Retty入社後の仕事内容

Rettyに入社してから担当した仕事内容として、細かい仕事を上げると結構ありますが、エンジニアリングの比重が大きそうな以下の3つについてお話します。

  • 広告周りの知識を身につける
  • ヘッダービディングの導入
  • フロアプライスの調整

広告周りの知識を身につける

私は入社前、1ヶ月ほどRettyでインターンをしていました。当時の最初の仕事は広告周りの知識を身につけることでした。広告周りの主な知識として、

  1. 広告の歴史
  2. Rettyで使われている広告運用の方法
  3. 他社の取り組み

の3つが挙げられます。 広告の歴史が何の役に立つのかと最初は思っていました。しかし、広告の歴史は比較的浅いため現在の仕組みにつながるものが多く、最新の仕組みの理解や今後登場する仕組みの予測に役立つ、ということを業務に携わっていて学びました。

ネット広告の歴史はこちらに詳しく書かれています。

https://dmlab.jp/web/history.html

2について、RettyではAdManagerというGoogleの広告配信システムを利用しています。AdManagerは現在多くのメディアで用いられており、機能も豊富となっています。 ただ、機能が豊富すぎるので、最初はとっつくのにかなり苦労しました。 インターン中の半分はAdManagerの使い方を学ぶことに費やしていました。 GoogleがAdManager学習用のサイトを用意している2ので、それを利用して学習しました。

ヘッダービディングの導入

インターン中盤〜入社後にかけて、ヘッダービディングという仕組みの導入・運用を行いました。国内でも早い取り組みだったため模索しながらでしたが、収益改善にもつながったためかなり面白い仕事でした。

ヘッダービディングとは?

ヘッダービディング3の詳細は長くなるので補足ページで確認していただくとして、超ざっくり4というと、

今まで:
広告事業者に広告を要求し、広告が返ってきたらそれを出す。指定価格以上の入札が返ってこなかったら2番目の広告事業者にリクエストを行う。以下繰り返し。
広告が返ってこなかった場合のレイテンシ増大や、2番目の広告事業者の方が入札価格が高かった場合の機会損失が発生。
f:id:rettydev:20181130153808p:plain

ヘッダービディング導入後:
複数の広告事業者を並列で接続し、最も入札価格が高いものを出す。
f:id:rettydev:20181130153819p:plain

といった感じです。

上の説明だけだと、今までなんで並列で繋がなかったの?という疑問が湧きますが、SSPからメディアに入札価格をリアルタイムに送信する仕組みがなかったことが理由です。

苦労した点

ヘッダービディングを入れた当初は、国内での取り組みが少ないため知見が転がっていなかったのが辛いところでした。私が導入を担当したのが海外(Amazon)のヘッダービディング事業者だったため、英語のマニュアルと格闘しつつ、社内のシステムに合うように組み込むことに苦労しました。

特に、別事業者のヘッダービディングと並列で接続したのですが、ヘッダービディングは今までの広告配信の流れに割り込むため、少々組み込み方が複雑になります。他の事業者との並列接続方法などはマニュアルになかったため、

  • 既存の広告配信時系列の把握
  • 他のヘッダービディング組み込みの挙動把握
  • 地道なデバッグ

を繰り返してなんとか組み込むことができました。 これまで非同期通信処理の実装経験がほとんどなかったのですが、複数事業者並列のヘッダービディングの実装では複数の非同期処理が絡んだ処理が入るため、混乱しながら図を描いていたのを覚えています。

今回導入したAmazonのヘッダービディングは一旦導入するとずっと収益を底上げし続けてくれるので、長期的に大きな収益を作ってくれることが期待できます。
ヘッダービディングの組み込みでは、広告関連処理の時間軸を把握する必要があったため、社内の広告リクエストがどのように行われているかの理解が大きく高まりました。

フロアプライスの調整

フロアプライスとは

広告オークションで用いられるパラメータの一つとして、フロアプライスというものがあります。そもそも広告オークションの入札方法は、大きく2つに分類されます。

  1. 1st Price Auction
  2. 2nd Price Auction

1については、一般的なオークションと同様で、最高の入札をした人がその額を支払って購入するもの。2は、最高の入札をした人が2番目の入札額(+1円)を支払って購入するものとなります。 少し例を出すと、

入札額
A: 100円
B: 60円
C: 180円
のとき、

1st Price Auction: Cが180円で購入
2nd Price Auction: Cが101円で購入

となります。ぱっと見だと1の方法が購入される側からすると嬉しく思いますが、2の方が高い入札が行われやすくなります5。 2のとき、フロアプライスというものをメディア側が設定できて、フロアプライス以下の金額では落札されないようになります。 先程の例を用いて、フロアプライスを引いた場合を説明すると、

フロアプライスがX円のときのCの購入額
100円のとき: 101円
150円のとき: 151円
200円のとき: 購入されない

このため、適切なフロアプライスを設定することで広告収益の底上げにつなげることができます。

フロアプライス調整の取り組み

フロアプライスは、もともと調整者の経験と勘によって調整されてきたものでした。しかし、調整にかかる時間的コストや正確性を考えると機械的に行えたほうが適切です。そこで、検討中も含めて以下の3つの方法を取り入れています。

  1. A/Bテストによる調整結果の見える化
  2. 1の結果をもとにした、フロアプライス自動最適化(検討中)
  3. 他社自動最適化ソリューションの導入

現在は1と3を同時に走らせています。A/Bテスト基盤は、Rettyで用いられている既存の配信システムの機能6を用いることで簡単に導入でき、しかもフロアプライス調整以外の施策にも利用できるため効果の高いものとなりました。 このA/Bテスト基盤を用いて現在はまだ手動調整中ですが、既存のフロアプライスと比較して、広告収益の2〜3%の上昇につなげることができました。

現在は、バンディットアルゴリズムを利用して2を実現できないか模索中です。

このように、アドテクチームは直接収益につなげる仕事ができるので、自分の施策・実装が収益にどの程度貢献したかをモチベーションにしながら日々取り組んでいます。

今後について

アドテクチームでは、不適切広告の監視やルーチンワークの自動化など、まだまだやることが山積みとなっています。今後は自分からチーム貢献できる仕事を見つけていけるよう、広告やビジネスの知識もより一層吸収していこうと思います。


  1. 正確には"AdTechnology & Alliance Group"ですが、私の担当がアドテク領域のため、本記事ではアドテクチームと表記します。

  2. https://publisheruniversity.withgoogle.com/splash/ja/index.html

  3. いま話題のヘッダービディングとは何か https://magazine.fluct.jp/2016/03/15/2336

  4. 厳密には異なり、メディアによってはヘッダービディング導入前にも広告事業者の並列接続は行っている場合もある。ただ、入札価格がリアルタイムにわからないため機会損失は発生しうる。

  5. セカンドプライス・オークション https://www.ifinance.ne.jp/glossary/business/bus142.html

  6. AdManagerのKey-Value機能 https://support.google.com/admanager/answer/188092?hl=ja