この記事は 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におけるデータ分析チームに求められるミッションについて紹介します。
意思決定最大化・基盤/仕組み作り・データの民主化の3つがRettyにおけるデータ分析チームのミッションです。
この記事では上記3つについて詳細に紹介していきます。
①意思決定最大化
立ち位置/求められるバリュー
意思決定最大化で求められるのは事業の意思決定をデータ分析によって推進していくことです。
実際どのような動き方をしているかは図にしてみました。
派遣型と依頼型で分けて動いています。
理想としては全てのミッション*1にデータアナリストを派遣したいのですが、現在の体制としてデータアナリスト5名、データエンジニア1名と少数精鋭なので、このような形をとっています。
毎Qごとに、事業優先度×データ分析需要度から優先度を付け、データアナリストを派遣するミッションを決めています。
どんな分析業務をしているのか
次にRettyにおけるデータアナリストがどのような分析業務を行っているのかを紹介します。
- 戦略構築
- プロダクトにおける長期目標に対して何をやり・何をやらないかを決めるために、現状の数値や今後の数値シミュレーションを行う業務
- KPI設計
- KGIを達成するためのブレイクダウンされた指標を決める業務
- KGIとの連動性やプロダクトの方向性と一致しているかを大事にして進める業務
- 目標値設計
- Q目標、月目標と設計する業務
- 季節要因などの外部要因を考慮した設計を行う
- 目標進捗確認ダッシュボードの作成
- 目標値と実態との差が見れて、良い悪いがわかるダッシュボードを作る
- 課題特定（狙い目を決める）
- 改善するページ/ユーザー/フローなどの特定
- 現状把握
- 仮説を立てるための網羅的なデータ出し
- 施策のテスト設計
- 期間、ターゲット、指標を決める
- 施策の効果検証
- 施策の効果ありなしを検証する
Rettyのデータアナリストはこの業務を全て派遣先ミッションで行い、意思決定を推進する役割を担っています。
次に、これら分析業務を行う上でRettyのデータアナリストが重視していることをお伝えしたいと思います。
データを正しく読むためにプロダクトとユーザーさんの理解を重視する
ユーザーさんの課題発見やKPI設計などの大半のデータ分析において、まず正しい現状を把握することが大事だと思っています。
この現状把握を行う際に非常に大事なのが、データを正しく読むこと。
そしてデータを正しく読むためには、自社のプロダクトとユーザーさんを深く理解することが重要だと考えています。
もう少し掘り下げて説明します。
データの裏にある真実を理解することがデータ分析の本質
ここでいう、データを正しく読むとは何なのか、それはデータの裏にあるユーザーさんを正しく想像することです。
もう少し噛み砕くと、データを見たときに、プロダクトがどのように使われるのが理想で、そのプロダクトをいつ、どういう人が、どのように使っていて、何に困っているのか。をイメージするこということです。
PMの領域に踏み込むことが大事
ではユーザーさん・プロダクトを理解するためにどうするべきなのか。 一つは、データアナリストも自らの業務領域を超えてPMの業務領域に踏み込んでいくことが必要だと思っています。
Rettyでは分析業務を超えて、PMの業務領域に深く踏み込むようにしています。
その取り組みの一例を紹介させていただきます。
プロダクトの健康診断をDailyで行う
毎日派遣先ミッションのメンバーとアナリストでプロダクトの主要数値をチェックし、現状のプロダクトがどのような状態なのかをチェックしています。
実際の値はお見せすることはできませんが、大体以下のような指標郡を全てチェックしています。
このダッシュボードはDailyだけではなくWeekly、Monthly版と3種類用意しています。
またミッションごとに見るべき指標はことなるので各々のミッションごとに作成しています。
3種類のダッシュボードの確認タイミングとしては、
です。
前週同曜日比を見ることがおすすめで、ダウントレンドの場合は薄ピンク色に背景を変えてトレンドを直感的に分かるように工夫しています。
これをやった結果、チームの数値感度が大きく向上しました。 具体的には、以下のような効果がありました。
- 単純に毎日見るので主要数値の数値感が付く
- 主要数値が頭に入っているので、数値変化に気づく
- その数値変化が異常なのか異常ではないのかも判断が付く
- また、プロダクトとユーザーさんを一番知っているPMの解釈を目の前で見ることができるのでデータ解釈力が上がる
- みんなで見解もぶつけることで解釈の精度が上がる
また、目標値との進捗もここでチェックすることで、目標値との乖離がどの程度あるのか、このペースで大丈夫なのか、ペースが追いついていない場合どの程度埋めていく必要があるのかを把握することが出来ています。
PMと二人三脚で分析を進める
データ分析を進める上で、仮設出しから数値結果の見解を出す上でPMと壁打ちをしながら進めています。
KPI設計を行うときには毎日必ず議論するようにしてコミュニケーションを増やしています。
プロダクトの健康診断とも被る効果になりますが、PMの仮設や見解の出し方をインプットできます。
もう一つはPMの思考理解に繋がるため、期待される動きやアウトプットのズレを限りなく減らす効果もあります。
データ分析はデータを出しては議論し、またデータを出すの繰り返しなので、毎日PMの時間を固定で抑えてしまうのがおすすめです。
一度PMやプランナーを経験する
可能なら一度プロダクトのPMやプランナーを経験することもおすすめです。
Rettyではプランナー出身者からデータアナリストに向いている人を見つけ分析チームに入ってもらった人もいます。
自身も元々バックエンドエンジニア兼プランナーからデータアナリストに転向した身です。
プロダクトのグロースにコミットすることで、プロダクト理解やユーザーさん理解が進むのはもちろんのこと、施策を打つためにもデータ分析の重要性もかなり理解できるのでとてもおすすめです。
プロダクトビジョン・歴史を理解する
もう一つは、自社のプロダクトビジョンと今までの歴史を理解することかと思います。
理解する方法は、正直業務を通じてプロダクトのビジョンや歴史を深く知っている人（POなど）とのコミュニケーションを増やすのが早いと思います。
他にも入社オンボーディング等で工夫できるかもしれませんが、Rettyでは業務を通じて理解を深めていってます。
図解するとこんな感じ（まとめ）
とはいえ、簡単には身につかないので長期的にプロダクトとユーザーさんに向き合う強い覚悟が大事だと思います。
Rettyのデータアナリストはプロダクトのグロースに責任を持っているPMにも負けないくらいグロースに向き合っていきます。
②基盤/仕組み作り
ミッションの2つ目は基盤/仕組み作りです。 ここでいう基盤/仕組み作りには、
- ログ基盤やDWHの開発/運用
- ダッシュボード開発/運用
- 分析の生産性を上げる仕組み作り
などがあります。 ただログ基盤やDWHの開発/運用に関しては先日公開された@takegueのアドベントカレンダーに詳しく書かれているのでそちらを読んでください。
分析の生産性を上げる仕組み作り
少数精鋭でRetty組織全体のデータ分析を行うので生産性を上げていかないととても回りません。
各々みんな派遣先ミッションで頑張りながらも生産性を上げる取り組みを適宜とりながら進めてきました。
その取り組み内容を紹介したいと思います。
Githubに分析アウトプットとSQLを蓄積
分析のアウトプット先は、ほとんどの場合スプレッドシートでたまにJupyter notebook やGoogleスライドを使ったりします。
大体が集計データを整理してグラフ化する程度が多いのですが、その分析アウトプットとそのデータ出しに使ったSQLをgithubに蓄積しています。
Pull requestを投げて、分析やデータ出しに関してレビューが欲しい場合は任意で依頼する形をとっています。
分析アウトプットもSQLも過去に似たような分析をしていた場合に役に立つのと、新人さんが入ってきたときにキャッチアップしやすいことを考えてこの取組をおこなっています。
PR（Pull request）の中身としては、以下3つです。
- 本文に問題設定、分析設計、結果、見解、分析後のアクションを記入したもの
- 分析に使ったソースコード(主にBigQueryのSQL）
- 1.の内容をREADME.mdにコピーしたもの
- 1.の内容をCircleCIを使ってREADME.mdの自動生成を行っています
具体的に実際に使っているテンプレートの中身をご紹介します。 もしよければ業務で使ってください。
＜PRテンプレート＞
問題設定 == <!-- 分析によって何を解くのかを記載してください --> <!-- githubのlinkを貼るだけでも大丈夫です --> 分析設計 == <!-- どのように分析するのかを記載してください --> <!-- githubのlinkを貼るだけでも大丈夫です --> 分析結果 == ## データ/資料 <!-- クエリ結果や分析資料が格納されているテーブルorスプレッドシートのリンクを貼ってください --> ## 結論(事実) <!-- データから見えた事実のみを記載しましょう。独自の見解は見解項目に記載する。 --> ## 見解 ### アナリストの見解 <!-- アナリストの観点からの見解を記載しましょう。 --> ### 最終的な見解 <!-- 依頼者と摺り合せて最終的にまとまった見解を記載しましょう--> ## 分析によって決まったこと(ここがバリューです) <!-- 分析によって、決まったことを記載しましょう - 目標がxxに決まった - xxについて深掘りをすることになった - xxをKPIにすることに決まった など -->
ここで重要だと思っている項目が最後の項目の分析によって決まったこと(ここがバリューです)です。
意思決定最大化をミッションとしているため、行った分析のバリューを言語化することを徹底しています。
Rettyでは毎週のデータ分析チームの定例会で、先週行ったアウトプットの共有会があります。
ここではmergeされたPRの中身をベースにして共有するので、バリュー欄を埋めることが必須な仕組みとなっています。
そのためこの項目があるだけで、分析の相談が来た際に分析後のアクションイメージをすり合わせてバリュー意識を高めることができています。
＜mergeされたPR一覧＞
PRにはラベルを付けているので、ミッション、分析者、分析の種類などでフィルタリングできます。
このようにラベル付けをすることで、過去の分析結果やSQLを探しやすくする工夫も取り入れています
使いやすいVIEWを作りデータ出しスピード向上とミスを防ぐ
Rettyでは、BigQueryをDWHとして採用し、そこにプロダクトのログやマスタテーブルを全て集約させています。
そして大半のデータ分析は、BigQueryを叩きスプレッドシートにまとめてお終いです。大体8割くらいがそのような分析案件となっています。
そのため、分析業務においてSQLを書くことが多く、素のログやマスタテーブルをJOINし、出したいデータを出す作業が多かったのです。
この中で、問題は大きく２つありました。
- 単純にデータを出すスピードに時間がかかる
- テーブル知識を持っていないと間違ったデータを出してしまう
スピードを求められるベンチャー企業のデータアナリストとしては、この問題はシンプルですがとても重要視すべき問題だと捉えています。
そのため、Rettyではデータアナリストが使いやすいVIEWをデータアナリスト自らが作ることでデータを出すスピードと品質を向上させることに努めはじめました。
せっかくなので、作って生産性が向上したVIEWを紹介したいと思います。
元の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ごとに、スクラムポイントとベネフィットポイントのラベルを付与しています。
図の
- 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では分析の難易度によってデータへのアクセス方法の最適化を図っています。
＜図：分析難易度によってデータへのアクセス方法を最適化＞
補足：「ツールでみる」はダッシュボードなどでGUI操作さえ覚えればデータにアクセスできる方法のことです。
このように分類することで、データアナリストに簡単なデータ出し依頼が集中するようなことを無くし、データアナリストだからこそできる難易度の高い案件に集中できるような状態を作っています。
組織全体のデータ活用風土の醸成
上記の最適化は分析難易度によってデータへのアクセス方法を分類することで最適化を図っていますが、そのデータへのアクセス方法の強化も必要です。
組織全体のデータ活用風土の醸成は、分析難易度小〜中のデータアクセス方法を強化する取り組みとなっています。
良く見るデータはグーグルデータポータル化
みんなが良くみるプロダクトの主要数値に関しては、グーグルポータル化していっています。 こちらに関しての取り組み内容は、
ベンチャー企業におけるDWH DevOps @ Retty - Retty Tech Blog
に言及されているのでこちらでは割愛します。
モチベのあるPM/プランナーを育成
各ミッションに一人くらいはデータが好きでSQL等への学習モチベが高い人材がいるはずです。
先程定義した分析難易度の中くらいまでをやってくれるようになると大分負荷が減りますし、実際にデータを見たい人が出すほうが分析効率も高くなります。
そういった人材を見つけ以下のような育成を行っています。
SQL問題集の提供はSQLが書ける人でも、データアナリストの新人さんにも向いています。
問題集は実際の業務で使ったことのあるデータ出しがほとんどなのでドメイン知識のインプットにも繋がるためです。
簡単なクエリは、二度と同じクエリを書かないくらいの気持ちでVIEW化していく
難易度が低のクエリはどんどんVIEW化していってます。
例えば、単純に投稿に関するデータを出すといっただけでも
- ユーザー
- お店
- 日付(Daily、Weekly、Montly）
といったセグメントや
- 投稿数
- 投稿UU
といった指標の単位もあります。
これらを毎回素のテーブルからクエリを作るのは地味に時間を使ってしまいます。
そのためRettyでは、こういうったデータ出しを行ったら極力VIEW化するように心が得ています。
この取り組みを行うだけで、データアナリスト自身のデータ出しの工数削減だけではなく、クエリの難易度が下がるため、データアナリスト以外の方でもデータが出せるようになります。
分析チーム自体の強化
分析難易度大のデータアナリストと分析チームを強化するための取り組みも行っています。
朝会でタスクの見える化
Rettyの分析チームでは毎日朝会を行っています。
ツールはGithubのprojectsを使っていて以下カラム構成で管理しています。
- Want to doカラム
- これほしいとか、やりたいを追加する場所
- やると生産性が上がるようなものだが緊急度が低い案件が追加されるイメージ
- いつかやりたいと思っていたことを忘れないないようにし、余裕のできたタイミングで着手するために存在している
- New Issueカラム
- ISSUEのprojects欄に設定されると自動的に追加される場所
- 主に依頼型案件のISSUEが追加される
- 優先度を適切に付けるために全てここを通るようにしている
- ミッション名カラム
- 派遣しているミッションごとにカラムを用意している
- 派遣先でタスクが発生したらここに積むようにしている
- 個人名カラム
- 分析チームメンバーごとにカラムを用意している
- 今現在持っている案件を見える化されるようにしている
上記、Github projectsを大きいディスプレイに映しスタンドアップ形式で
- New issue/ミッションごとのカラムを確認
- 新しいISSUEが追加されたらここで割り振る
- 個人のタスク共有
- どのような分析を、なぜやるのかを話す
- WHATとWHYの説明を行うことで、メンバーが全体の動きをキャッチアップできるようにしている
- 連絡/共有事項
- 個人的な勤怠連絡や勉強会に言ってきた感想などを話す
この朝会を通して、効率的なタスク割り振りとチームの親和性の醸成を図っています。
チームでの定例による分析評価会
毎週1時間でチーム定例会を行っています。
ここでは、
- コスト/ベネフィットポイントの確認
- BigQueryのコスト推移（コスト意識）
- ベネフィットポイント推移（バリュー意識）
- 派遣先のミッション目標進捗の共有（目標達成への温度感をチームで認識し助け合う）
- 分析アウトプットの評価（データアナリストの強化）
を行っています。
データアナリスト自身の強化観点だと、分析アウトプットの評価がそれにあたります。
Githubに分析アウトプットとSQLを蓄積で紹介したPRをベースに、問題設定から分析設計〜分析結果から最終的にどのような意思決定に使われたかまでを全て説明し、それに対してみんなでフィードバックをしています。
普段はそれぞれ派遣先のミッションで業務を行っているため、アウトプットを見る機会が少なくフィードバックの機会が設けられないため、この場を作りデータアナリスト自体の強化を図っています。
最後に
ここまでが今年データ分析チームを立ち上げて行ってきたことの紹介でした。 とても長い記事になっていまいましたがここまで読んでくださった方ありがとうございます。
データ分析チームを立ち上げるベンチャー企業に少しでも役に立ちたい
プロダクトを自社で使っているベンチャー企業におけるデータ分析チーム、個人としてデータアナリストやデータエンジニアの役割って歴史がそこまでなく、定まっていないのが実際だと思います。
そのため、このような事例を発信することで新しくデータ分析チームを立ち上げようとしているベンチャー企業に少しは役に立つのではないかと思っています。
なぜそう思ったか？私自身、今年4月からデータ分析チームを立ち上げるにあたって、メルカリの樫田さんが書いた記事メルカリの分析チームとは？その全ての疑問にひとつひとつ答えます | メルカリエンジニアリング にかなり助けられたからです。（注意：樫田さんのステマではありません）
その経緯から本記事は、上記記事に記載されている内容と似ている箇所が多分にありますが、非常に参考にさせていただいたからです。
その中でもRettyならではの取り組みを紹介することで、お役に立てればと思ったのが本記事を書いた理由の一つです。
Rettyでデータ分析を行うことの魅力を伝えたい
組織全体を動かす意思決定を担える
今年の4月に立ち上げて組織全体の意思決定を最大限化するための取り組みを行ってきましたが出している成果についてもお伝えします。
詳細にはお伝えするのが難しいですが、事業インパクトの観点だと、
KPIの数値向上のために営業組織全体にアクションをしていただくような意思決定
組織力向上の観点だと、
データドリブンで目標を構造的に達成するためのデータ活用の仕組み化など、
ミッションや組織全体に対する大きな意思決定や、組織力強化に貢献することができます。
組織を動かすような意思決定はプレッシャーが掛かりますが、その分事業に貢献できる量も大きいので非常にやりがいがあります。
来年はレコメンド/機械学習を用いた課題解決に本格注力する
先日のプレスリリースの通り月間4,000万以上のユーザーさんが利用しているRettyには、アクセスログの他、全国のお店情報、1,500万件超の投稿画像、数百万件の口コミ投稿数、アプリ内のSNSデータを保有しており、飲食という誰もが課題として持ちやすい領域に対して、このデータを活用して解決できる課題に可能性を感じています。
データ活用という点で現状は意思決定という点でバリューを発揮していますが、来年はデータを活用した機能開発（レコメンドなど）によるユーザー体験の向上をテーマとして活動する予定です。
グルメ領域は自分自身もユーザーになれるのでやりがいを持ちやすいですし、Rettyにはグルメ領域の深くて種類の多いデータが大量にあるため、そのデータを使って価値を届けたいと考えている方にはとてもおすすめできる会社です。
少し先の未来の話し/Yahoo!との取り組みについて
今後Yahoo!との取り組みにおいて決済領域にも踏み込むことから、さらにユーザーさんの外食体験をよくしていける可能性を感じています。
その取り組みは様々ですがその中の一つとして決済情報を使いユーザーさんの外食体験を向上したいと考えています。
まだ何も決まってはいませんが、中国のテンセントとグルメサービスの大衆点評の決済情報を使った取り組みであるような、いつ誰がどこで何を食べたか、といったデータを活用した取り組み（例：メニューランキングの提供、注文をアプリで行える）ができる未来も全然あると個人的に思っています。
決済領域に関して取り組めるチャンスは中々ないので、そこへ取り組めるチャンスがあることは魅力かと思っています。
データ分析チームを創る側に回れる
このようなサービスやデータ的魅力だけではなく、今年の4月立ち上げということや現在6名（内定者を含めて）と少数であることから、自らがデータ分析チームを創る側に回れるフェーズであることも魅力ポイントだと思っています。
仲間募集しています
ここまで読んでくださりありがとうございました。
少しでもいいなと思った方、もっと話を聞いてみたいなと思った方お気軽に平野までご連絡ください。
データアナリスト及びデータエンジニア、MLエンジニアの採用を募集しております。
*1:Rettyではプロダクトの開発を行うプロダクト部門というグループ単位があり、その下層に特定のKPIをグロースさせるためのミッションというグループ単位で構成されています。
