mikanにデータ分析担当として入社して半年が経ったので振り返り🍊

はじめに

これはmikan advent calendar2022の11日目の記事です。

昨日は@zukkeyより、ExoPlayerとComposeでオーディオプレーヤーを作った際のTipsでした。今年リリースした目玉機能の1つである、オーディオプレイヤーの実装についてです。mikanだと教材の音声再生に利用していますが、音楽や動画の再生ということで他のアプリでも参考にしていただけると思いますので、ぜひ読んでみてください！

そして、本日13日目は主に分析業務を担当している伊東から、入社してからの取り組みをお話しつつ、小規模な組織でのデータ周りの悩みはどんなものかといったものをご紹介できればと思います。

自己紹介

内容に入っていく前にmikanと筆者について少しだけ。

弊社は主に英語アプリmikanを2014年から運営していて、累計DL数がついに650万人に到達しました。アプリを利用するのは学生の方から社会人の方まで、幅広い世代の方の英語学習に使っていただけています。

僕は2022年2月より入社し分析やPMが最近の役割です。入社してからは正社員として1人目の分析担当となったことで、分析基盤やデータにまつわる領域での業務を進めています。これまで基盤を作って運用するといった経験をしてこなかったことから、同規模の会社がどのような運営をしているのかは気になっていました。最近はテックブログなどでそうした情報を発信して出さっている企業も多く、せっかくなら自分たちも困りごとなど共有できればと思い、今回はmikanでの分析環境や取り組みについてを選びました。

mikanのデータ分析環境

mikanの分析環境は少しずつ変化してきましたが、現在はAthena経由でS3に保存しているアプリの行動ログや決済ログなどを参照しています。可視化にはRedashを利用しており、最近はRedashから接続するデータソースがBigQueryやMySQLなどいくつか以前より増えてきました。

これまでの経緯やそれぞれで起きていたことは、前任のメンバーがまとめたmikanのデータ分析基盤の歴史があるので、ぜひ気になる方は見てみてください。

Athenaを利用してみてですが、弊社のデータ量であればだいたいの集計は問題なく実行できますし、それまでの運用コストを下げる形で使えているという認識です。

直近の取り組み

mikanでは主にプロダクトの数値分析をPMを含めた3名がそれぞれで実施していて、自分が入社するまでは分析やデータ基盤を担当してくださる副業メンバーの方がいる状況でした。正社員としては自分が1人目ですが、副業メンバーやエンジニアチームに助けてもらいつつ基盤の話をしています。

そして、入社してからは主に以下3つを進めてきました。

• ドキュメント化
• 中間テーブルの模索（CTAS, Glue）
• ログの実装管理用DB

ドキュメント化

先程記載したように、mikanではAthena経由でS3に保存されているデータを直接読み込む形で集計しています。自分はこれまでGoogle AnalyticsやAdobe Analyticsといったアクセス解析ツールを主に利用しつつ、必要なところでクエリを書いている状態だったので、mikanに入社した当初はデータ理解にかなり苦戦しました。各画面からどういったデータが取得されるのか、データの仕様はどういったものかというキャッチアップに時間を要しました。

mikanの他メンバーはエンジニアとして実装もしていたことで、ログ自体に対する理解度が高く課題とはなってなかったのですが、自分はそうした前情報がなかったことが大きな要因です。今後はより多くのメンバーが分析に関わることも想定していたので、足元のドキュメント整備から取り組みを始めています。

ドキュメントにした項目

• 分析で参照するテーブル一覧とメタデータ
• ログごとの集計方法や特性
• 頻出クエリ
• ログ実装における変更点と経緯
• 注意点
• ログ設計における命名規則

メタデータ管理としてツールを使うといったことも可能ですが、小さく始めたいことからNotionのページに利用頻度の高いものを順に記載していきつつ、全体を整えてアップデートをしています。分析に関連する人には最初に読んでもらうドキュメントとして作っているので、オンボーディングで活用する想定です。

中間テーブル作成と基盤の模索

Athenaを活用することでクエリの実行時間が短縮される一方で、mikanでも少しずつ探索的な分析や時系列を踏まえた分析が増えてきました。S3には日時でパーティションを区切る形でデータを保存していますが、どうしても多量のデータスキャンに伴う実行時間が気になってきたり、頻繁に参照するデータについてはある程度の粒度でまとめてすぐ取り出せるようにしたいといった需要が生まれています。

そこで、まずは現環境で始められることからということで副業メンバーに助けてもらいつつ、2つのことをお試しで進めることに。

• クエリ結果からのテーブル作成（CTAS）
• AWS Glueを活用した中間テーブル作成

CTASについては以下のようにクエリの実行結果から作成できることから、Redash上で実行可能かつお手軽にできることでトライしました。

CREATE TABLE AS SELECT(CTAS) クエリは、別のクエリからの SELECTステートメントの結果から、Athena で新しいテーブルを作成します。Athena は、CTAS ステートメントによって作成されたデータファイルを Amazon S3 の指定された場所に保存します。

参考リンク

とはいえ、上記でredash上で好き放題中間テーブルを生成するのもメンテナンスにかかる工数があるため、別でAWS Glueを活用してフローを作ろうとしました。Glueを利用することでエンジニアでなくとも、GUI上からETLワークフローを作成できることなどをメリットが利点です。

ただ、こちらについてはS3に保存しているデータをGlueで読み取るために加工する必要があるなど、それ以外にもいくつか課題がでて苦戦しました。現在はこれらとは別軸でDWHを改めて整備する話も挙がってきたことで、基盤自体の見直しを進めています。

ログの実装管理用DB

これは主にエンジニアの@satoshin21が進めてくれたことですが、めちゃくちゃ便利なので紹介します。アプリでの行動ログを取得するにあたって、mikanでも様々な種類のログ定義がされており、入社当初はそれらの情報が仕様書に点在している状況でした。また、エンジニア側としても不要になったログの管理や設計者とのコミュニケーションが大変などいくつか課題を抱えていました。

これらに対して、Notion上でログを定義したデータベースを作成し、iOS側ではNotion + Stencil + Swiftという構成でログを自動生成しています。分析する側からすると、ログ管理が共通で参照できるようになったことで、認識の齟齬がなくなることやログ情報をより早く見つけられるようになり、ものすごく楽になりました。

エンジニア目線での利点や実装についてはこちらで軽く触れていますので、ぜひ見てみてください。

課題とこれから

チームのおかげで少しずつ改善が進んできているmikanのデータ事情ですが、次は以下のような内容への取り組みを検討しています。

• 集計にかかる時間の短縮
• Redashにおけるquery resultを代替する
• 複数のデータを誰でも横断で利用できるようにする
• 他のメンバーも分析できる環境を作る

mikanでは、遅ればせながらアプリの行動ログから実際の売上や解約と言ったデータも両OSで揃えて、それらをつなぎ合わせられる状態になりました。事業やサービスを改善するにあたって、これらのデータが一気通貫で見れることや、誰でも簡単に分析できるようにすることは早く実現せねばと考えています。このあたりだけでまた1つ記事が書けそうなテーマになってきますので、それはまた次の機会に。

まとめ

入社後mikanで進めてきたデータ分析にまつわる取り組みについて簡単に振り返ってみました。細かな取り組みを進めつつも、実際にこれから基盤をどうしていくのかといった大きな話も絶賛悩んでおります。小規模な組織がどのようなデータ基盤を作っているのかなど、ぜひ興味がある方は一緒にお話しましょう！
また、弊社では特にデザイナーを募集中です。少しでも話しを聞いてみたい、興味がでたという方はtwitterでもかまいませんし、以下からご応募いただけると嬉しいです。
求人 デザイナー

mikanアドベントカレンダー12日目はデザイナーの@ayatakiが担当です。お楽しみに！