こんにちは！エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでアナリティクスエンジニア兼データアナリストをしている星野（@mochigenmai）です。
年初に公開したブログでお伝えさせていただきましたが、Gaudiyは今年から「プロダクト主導型の組織づくり」を進めています。
プロダクト主導型の組織には、データドリブンな意思決定が欠かせません。そこでGaudiyでは、データを元にしたプロダクト改善を行い、ユーザへの適切な価値提供をしていくために、1月にデータ分析チームを立ち上げました。
今回のブログでは、データ分析チームを立ち上げた背景や、立ち上げ時の課題や取り組み、データアナリストの役割などについてお伝えします！
スタートアップで同じようにデータ分析チームの立ち上げを担っている方や、データ分析チームの役割に興味のある方にご参考になれば嬉しいです。
1. データ分析チーム立ち上げの背景
GaudiyではIP（知的財産コンテンツ）を有するエンタメ企業（以下、IPホルダー）に対して、IP公式のファンコミュニティサービスを提供しています。
ビジネスモデルとしてはBtoBtoCであるため、プロダクト開発においては「IPホルダーが他のIPホルダーに」「IPのファンが他のファンに」オススメしたくなるような、toB、toC双方の視点での磨き込みや仕掛けが必要です。
Gaudiyでは今まで、メンタルモデルを深掘るなどの定性リサーチを活かしたプロダクトづくりに取り組んできました。
こうした定性分析の強みはありつつも、プロダクト主導型の組織に移行するにあたって、より定量的なプロダクトの評価・改善が必要なフェーズになってきました。
また、データ分析は社内の意思決定だけでなく、IPホルダーとファンからのプロダクト評価にも直結します。そこに組織として注力していきたいという背景から、データ分析チームを立ち上げることになりました。
2. Gaudiyがデータを重視する理由
Gaudiyのプロダクト開発において、なぜデータが重要なのかについて、ファンとIPホルダーそれぞれの視点から少し説明したいと思います。
2-1. ファンにとって居心地のよいコミュニティづくり
ひとつは、ファンにとって居心地のよいコミュニティをつくるためのデータ分析です。
ファンコミュニティの分析において、参考にさせていただいたのが@kengoiwt さんのnoteです。
コミュニティに参加しているユーザーを、Leader・Follower・Active Audience・Non-active Audienceという4つのセグメントに分けます。
- Leader
- リーダーシップがある
- 何らかのイベントを企画してくれる
- クラスタをリードしてくれる
- Follower
- リーダーの企画に賛同している
- クラスタのメンバーと共に活動を行う
- Active Audience
- クラスタには所属していない
- クラスターの活動を見守っている
- Non-active Audience
- 全く活動していない
このうち、LeaderとFollowerで構成される「クラスタ」と呼ばれる小さなグループが複数存在しますが、所属するクラスタが複数あるファンの方が、コミュニティでの活動意義を感じてくれるといいます。
各セグメントではコミュニティに参加している目的が違ってくるので、データ分析を通じてそれぞれのセグメントに適切な価値を提供することで、LeaderやFollowerとして活動してくれるファンが多くなり、居心地のよいコミュニティがつくられると考えています。
2-2. IPホルダーにとってのコミュニティ開設の意義
もうひとつは、IPホルダー（クライアント企業）に、コミュニティ開設による意義を感じていただくためのデータ分析です。
Gaudiyでは、ファンのコミュニティ内の活動と、外部サービスの活動を紐付けることができるDID（分散型ID）という技術を利用して、コミュニティ外のマーケティング支援も実施しています。
IPホルダーにコミュニティを開設してよかったと感じてもらうには、コミュニティの特性を理解していただいたり、各セグメントごとのユーザ数やクラスタ数、コミュニティ外での活動の傾向といった数値を確認していただくことが大切です。
IPホルダーがそういった情報にアクセスしやすく、見やすいダッシュボードなどを作成する必要があります。
3. データ分析チームの立ち上げで生じた問題と対応
Gaudiyでは、拡張性とスピード感のある開発を行うために、データベースにFirestoreを利用していますが、データアナリストからすると大きな問題が2つありました。
ひとつは、APIを利用してBigQueryにエクスポートを行う時、マスターデータとトランザクションデータでコレクション名が同一の場合、同じテーブルに登録されてしまうという問題です。プロダクト開発上はコレクション名が重複しても問題がないので、この問題が起きてしまっていました。
もうひとつはFirestoreが非構造化データなので、分析をするときの整形処理が複雑になってしまうという問題です。
どちらもデータの整形時にミスをしてしまうと、間違ったデータを利用して分析をしてしまい、意思決定のミスリードを誘発しかねません。
これらの問題を解決するために採用したのが、dbtです。
Ubie ( @sotaron ) さんの datalake, interface, component, datawarehouse, datamart の5層構造を参考にして、各層の役割を以下のように明確化させることによって、スピード感のあるデータ分析基盤の開発と意思決定を実現しています。
- datalake層
- firestoreからエクスポートされるデータそのもの
- interface層
- NULLの除去
- 日付を日本時間に変換
- component層
- マスターデータとトランザクションデータが一緒になっているテーブルを分解
- 同じテーブル内のデータを別テーブルで切り分けたいものを切り分け
- カラムのテスト
- datawarehouse層
- マスターデータとトランザクションデータの結合
- datamart層
- 利用用途に合わせたデータを作成
今後はプロダクトの開発速度を落とさずデータクオリティの担保をより加速させていくためにも、エンジニアの方とNoSQLとRDBの使い分けを進めていきたいと考えています。
4. データ分析チームの役割と今後について
現在、Gaudiyのデータ分析チームは、データアナリストとBizDevを兼務する藤原さん（@rfuj1wara234）と僕の2名体制になっています。
データ基盤の開発に加え、Gaudiyには専任のPdMがいないので、意思決定のサポートだけでなくデータアナリスト自身が意思決定を行うこともあります。
そのため、以下の4つがデータ分析チームが担う役割になっています。
- データクオリティ担保のためのデータ分析基盤の開発
- ユーザー（ファン）が求める価値の提供
- IPホルダーのマーケティング支援
- 社内での意思決定のサポート
ユーザーが求める価値の提供やIPホルダーのマーケティング支援については、他チームとこまめにコラボレーションを行いながら業務をしています。ここでは、ユーザセグメントの定義やダッシュボードの整備などをするほか、データドリブンな意思決定を行うのでPdMのような立ち回りもします。
また、社内での意思決定のサポートに関しては、上記以外の内容で社内メンバーが必要と判断したデータ分析を行います。ここでは、ただの集計依頼にならないように、データが必要な背景や期日感をヒアリングした上でサポートしています。
現時点では分析依頼を受けていますが、分析基盤を整えて「データの民主化」を行えば、どんな職種の方でもすぐにほしいデータが手に入る状態を作ることができると思います。
なので今後は、SQL勉強会などを開いて、データ分析チームのメンバーがいなくてもデータドリブンな意思決定を行える状態をめざしていきたいと考えています。
5. おわりに
今回は、データ分析チームの立ち上げをテーマに、ご紹介させていただきました。
まだ走り出しのチームで、手探りで進めている部分もありますが、効率的に分析が行えるように立ち上げ初期の段階から分析基盤の開発を行っています。
これからも工夫をしながらデータへの意識を社内に根付かせていきたいと思っています。そして、プロダクト主導の組織の"羅針盤"になるようなチームにしていきます。
この記事を読んで、少しでもGaudiyのデータ分析チームに興味をもってくれた方はぜひお話ししましょう！
Gaudiyの技術スタックや思想については、以下のブログをご参考ください。
