GREE DX Tech Blog

グリー株式会社のDX事業本部のエンジニアブログ

【イベントレポート】クリエイターツール「QUANT」とデータ分析基盤でみるGlossomの技術的挑戦

2022年10月25日、グリー株式会社およびグリーグループ各社は、「GREE TECH CONFERENCE 2022」を開催しました。グリー株式会社およびグリーグループ各社では、これまでゲーム・アニメ事業をはじめ、メタバース、コマース、DX、マンガとさまざまな事業領域でサービスを開発・運営するとともに、技術的な挑戦に数多く取り組んできました。

「GREE Tech Conference」では、グリーグループ各社から、エンジニアが集い、技術的情報を共有、発信する機会として、毎年開催。各社で取り組んでいるさまざまなチャレンジで得られた知見や、これから取り組むチャレンジを紹介しています。今年のカンファレンスは、3年ぶりのリアル会場での実施に加え、史上初めてのオンラインとのハイブリッド開催となり、リアル・オンラインともに、大いに盛り上がりました。

今回はそのなかから、DX事業を手掛けるGlossom株式会社のエンジニアが登壇した「クリエイターツール「QUANT」の開発の話 & クライアントに寄り添ったデータ分析基盤の構築」の講演についてお伝えします。

 

 

 

Glossomが提供するクリエイターツール「QUANT」の開発について

前半は、エンジニアマネージャーの菊井昭夫から、クリエイターツール「QUANT」の開発について紹介しました。

 

Glossom株式会社 プロダクト事業本部
開発チーム シニアマネージャー
菊井 昭夫

 

「QUANT」とはインフルエンサー向けのソーシャルコマース支援サービスです。インフルエンサーの仕事管理として、案件依頼や進捗、売上の管理ができるほか、QUANTの担当者が案件をマッチング。有名企業やブランドからの案件紹介を受けることができます。

 

Cloud Bigtabeを採用

QUANTでは、特色ある実装として、Cloud Bigtabeを採用しています。Cloud Bigtableとは、最大 99.999%の可用性で大規模な分析ワークロードにも運用ワークロードにも対応できる、フルマネージドでスケーラブルな NoSQLデータベースサービスです。Cloud Bigtabeを実装したことで、評価できるポイントは、大きく2つあります。1つ目は、データの書き込みです。Cloud Bigtableの方でexpireを適切に設定することで、データの削除を気にすることなく、追記更新を常に続けることができます。2つ目は、データの読み込みです。読み込み時にフィルタを利用することで、追記更新した値の最新バージョンのみを返すよう指示しており、結果的に読み込み書き込み問わず、削除を考慮せずに利用できます。全体としては、アプリケーションレイヤーでのデータ削除や、追記更新時や読み込み時に既存のキーのデータ重複を考慮せずに実装できるので、KVSとして使いやすく、性能に現在も満足して利用しているといいます。

QUANTのフロントでは、Railsを採用しており、今回は特色のあるGemについて紹介します。view_componentを採用した経緯としては、より良いサービスにするため日々機能を追加していった結果、業務ロジックが複雑化し、Viewのソースコードが肥大化。テストコストや、ロジックの可読性が落ちてしまいました。そこでview_componentを採用することで、コンポーネント化でロジックを分割することで、コンポーネント単位のテストが可能になりました。

 

view_componentの実装例

view_componentの実装例は下記の通りです。index.html.hamlで検索のUIを表示する実装になるが、上のコードを下のコードに実装を差し替えるだけで、view_componentの実装をしています。

index.html.haml
# before
= render 'search'

index.html.haml
# after
= render Campaigns::SearchComponent.new(form: form)

 

Campaigns search_componentでは、classと表示されるhamlを対にして配置する形になっています。こちらも、業務ロジックを分割した内容を書くことで、簡単に分離することが可能です。view_componentによって処理を分割することで、スペックもRSpec.configureでtype::componentを追加する必要がありますが、type::componentを指定することで、コンポーネント単位でのテスト実装ができます。

 

# search_component.rb
class Campaigns::SearchComponent < ApplicationComponent
  attribute :form
end

# search_component.html.haml
= simple_form_for form, url: campaigns_path do |f|
  = f.input :hogehoge

# search_component_spec.rb
# RSpec.configure で type: :componentを追加する必要があります
RSpec.describe Campaigns::SearchComponent, type: :component do
  describe ......
end

 

view_componentを採用して評価できる点としては、巨大なView表示するための、大量のテストデータの用意や、分割することでSpecが書きやすくなったことが挙げられます。また、リリース当初は採用していませんでしたが、こちらを採用しコンポーネント化したことにより、ロジックの整理が進んだほか、テスト品質を保つことができました。Viewが肥大化した際には、こちらのGemの使用がおすすめです。

 

 

Railsの実装例

「QUANT」のサービスは、プロフィール管理画面は pf.quant.jp、マイページ画面は quant.page、ショップ画面は shop.quant.page というように、複数のドメインで構成されています。楽に開発管理や実装共有をしたかったので、Rails Projectを分けずにsubdomain実装により実現してます。

実装例としては下記のようになっています。routesのファイルに対して、constraints subdomainで実際にサブドメインを割り当て、その先のscope moduleで、サブドメインごとの処理を記載します。これによりRailsプロジェクトを分けずに、複数のドメインに対してサービスを展開することが可能です。あえてサービスを実装上分けたくない場合に、こういった記載がおすすめです。

 

routes.rb
constraints subdomain: ENV.fetch('SUBDOMAIN', 'subdomain').to_s do
  scope module: :'subdomain' do
    resources :tops, only: [:index]
  end
end

 


クライアントに寄り添ったデータ分析基盤の構築

後半は、データエンジニアの飯山誠也から、クライアントに寄り添うデータ分析基盤構築について紹介しました。

 

Glossom株式会社 DXC事業本部
データ・エンジニアリングチーム
飯山 誠也

 

データ分析基盤はGCP環境を使用しています。そのなかで各種データはCloud Composerを介して、BigQueryに書き出しています。また、Kubernetes EngineやDateflowを使い分けることでクライアントの環境に適したデータの書き出しを実現しています。BigQueryに集約したデータは、Looker Studioで可視化しています。

 

データ分析基盤の主要ツール Airflow



Cloud Composerは、Airflowをベースとしたワークフロー管理ツールです。Airflowは、DAG形式で、Task間の依存関係を管理できます。それぞれのTaskは、データを取り込んだり、他のシステムを呼び出したりする処理を実行することが可能です。Airflowには、さまざまな処理を行う機能が標準で設けられ、標準オペレーターを使用すると手軽にデータ取り込みが可能です。データ取り込みがすべてAirflowの標準オペレーターで実現できれば、運用しやすいデータ基盤を構築することができます。

 

クライアントごとに異なるIT活用状況に寄り添う

しかし現状は、そのようにはいきません。それはクライアントによって、ITの活用状況が異なるためです。データ管理の体制が整っておらず、データの保管先が点在しているケースや、連携するファイル数を把握できていないといった状況が挙げられます。データを所定の保管先に連携できる担当者やエンジニアが社内にいないというケースも珍しくありません。さらに、データの保管先が社内政治的にすでに決まっている場合もあります。この現状を打破するためには、クライアントごとに異なるITの活用状況に寄り添った、データ取り込みが必要なのです。

 

 

データ取り込み手法の使い分け

Airflow Custom Operatorは、開発が比較的容易に行えるため、ライブラリを活用して取り込む場合に有用です。GKEのPodを活用する場合は、リソースを切り離せるほか、文字コードの変換に対応できるため、UTF-8以外の文字コードの場合や、リソースの使い分けが必要な場合に、より有用性が増します。Dataflowでは、リソースを切り離せるほか、大規模データの取り込みに対応しているため、ファイル数やファイル容量が大きい場合に採用しています。

 

今後の展望

クリエイターツールQUANTでは、今後のインフルエンサーマーケティング市場の発展に貢献できるよう、計測したデータをより活用することや、インフルエンサーを支援する機能を追加する予定です。
データ分析基盤では、機能面の充実化を図る予定です。環境構築後のワーカーCPUやメモリのオートスケーリングが可能なDataflow Prime、Dataformやdbtなどのデータリネージツールの導入を検討しています。このようにGlossomでは、今後もより良いサービスの提供を目指し、新たな機能やツールの導入や実装を進めていきます。

 

 

Social Pitt の紹介とサービス支える技術

DX事業本部の長谷川です。

今回は、DX事業本部のグリーライフスタイル株式会社で提供している「Social Pitt(ソーシャルピット)」というサービスを支える技術についてご紹介します。

Social Pittとは? = ソーシャルマーケティングSaaSです

Social Pittは、グリーライフスタイルにおけるSNSアカウント運用事業を効率化させるための内部ツールとして開発されました。

主に以下のような機能で運用チームをサポートしてきました。

  • クライアントとの投稿(クリエイティブ、テキスト)確認
  • アカウントの分析
  • キャンペーン実施時のコメント抽出
  • 競合アカウント分析
  • ハッシュタグ分析

社内の効率化をしていく一方で、業界をみると、当時まだまだExcelやLINEで企業間のコミュニケーションをとっている企業は多かっため、このツールを他の企業に利用してもらうことでマーケティングのDXにつながると判断し、SaaS化していくことにしました。

Social Pitt の構成

SNSアカウント運用のツールとしてスタートしたSocial Pittですが、今ではUGC機能やクリエイター管理機能を追加し、Eコマース事業者向けのマーケティングSaaSとして拡大しています。

コードは、以下のようにコア機能とアプリケーション機能でわけて管理されています。

Core

Coreの責務は2つです。

  1. 外部サービスと接続し、データを収集すること
  2. 各Serviceに対して、APIをインターフェイスとしてデータを提供すること

外部サービスとのI/OをCoreに集約することで、各Serviceにおいて重複実装することを防いでいます。

Service

Serviceは機能毎に独立したRailsアプリケーションになっています。

CoreのRubyクライアントを利用してデータを取得、認証もFirebase Authenticationを利用するために共通のRubyクライアントを利用しています。

Serviceを開発する人員は基本的に兼務はせず、それぞれがオーナーシップを持って担当プロダクトの開発に取り組んでいます。

Social Pittを支えるOSS

ここからはSocial Pittで利用しているOSSの紹介とその選定理由について説明します。

Ruby on Rails

Social Pittは、全てRuby on Railsで実装されています。技術スタックが統一になることで共有のgemが利用でき、実装工数の削減につながっています。

全てRails7で動いており、動的な表示にはStimulusやTurboを利用しているところもあります。Turboは画面遷移時に意図せず不具合を生み出しがちで、まだ完全には使いこなせていません。

Vue.js

アカウントの運用の分析画面はVue.jsで実装されています。期間や並び順を切り替える毎に、Highchartsで実装されたグラフを描画し直します。

Social PittはSPAでは作成されていなかったのですが、グラフに関してはUX向上を目指し、部分的にSPAにし、日本で採用事例が多いVue.jsを利用しました。

Svelte

SvelteはUGC機能のギャラリー表示の実装に利用されてます。UGC機能はECサイトのLPにウィジェットとして埋め込み、CTR/CVRを計測しながら、LPのCVRを向上させることができます。

外部サイトで読み込まれるため、なるべく軽量で高速に動作するSvelteをフレームワークとして採用しました。

Tailwind CSS

CSSのフレームワークはTailwind CSSを採用しています。今までは管理画面を作る際にはBootstrapを採用することが多かったのですが、Railsが押していること、Bootstrapよりも柔軟性があることを理由に選定しました。

コンポーネントを実装する際は、Tailwind CSSのコンポーネントを探して、一旦コピペしてきて、そこからアレンジするといったこともでき、時間の削減に貢献してくれています。

Social Pittの今後・課題

Social Pittの特徴として、外部サービスから多くのデータが溜まっていきます。今はそのデータを上手に活用できておらず、本来であれば機械学習を利用して付加価値のあるデータに転換できると考えています。

例えば、インフルエンサーをアサインする際には、インフルエンサーのフォロワー属性が重視される(女性インフルエンサーには必ずしも女性のフォロワーが多くない)ため、投稿内容を分析してフォロワー属性を推定するということも考えられます。

また、Socialリスニングで、自社商品のSNS上の反応はポジティブなのかネガティブなのか、どのような意見があるのか、をセンチメンタル分析でわかるようにするということも検討しています。

DX事業は、単なる業務の効率化に留まらず、データを活用して付加価値をつけることに価値があると考えており、今後チャレンジしていきたいと思います。