【事例】ランサーズ株式会社様
当社監訳書籍『アジャイルデータモデリング - 組織にデータ分析を広めるためのテーブル設計ガイド』の寄稿事例をWEB掲載しています。
- 本書における寄稿事例の位置づけについては寄稿事例について を参照してください。
- 本ページに掲載している画像および図表については、いずれも同書籍からの引用となります。
ランサーズ株式会社
寄稿者：データ分析チーム リーダー 横山翔（ゆずたそ）
ランサーズ株式会社は、フリーランスに仕事を依頼できるマッチングプラットフォーム「ランサーズ」を中心に、複数のサービスを運営しています。風音屋は5年以上にわたってランサーズのデータ活用を支援してきました。一部メンバーが出向・兼務し、社員と同等の責任と権限のもとでデータ基盤構築やデータ分析を推進しています。
本稿では、ランサーズのデータ分析チームの活動事例を取り上げつつ、本書の内容を実践に繋げるための5つのノウハウを解説します。
【1】データ分析のプロセスにディメンショナルモデリングを組み込む
【2】異なるファクトを束ねたファクトを定義する
【3】複数のデータを統合して部署横断のディメンションを整備する
【4】複数サービスのデータを統合してグループ会社横断のディメンションを整備する
【5】データ加工ツールを導入してデータモデリングを加速させる
ランサーズは「個のエンパワーメント」をミッションに掲げ、「仕事を依頼したい企業」と「仕事を受けたい個人」をオンライン上でマッチングする、日本初・日本最大級のクラウドソーシングサービスです。フリーランス人材（ランサー）と企業（クライアント）のデータを集約・蓄積し、両者への提供価値を最適化すべく、試行錯誤しています。
【1】データ分析のプロセスにディメンショナルモデリングを組み込む
ランサーズのデータ分析では、分析対象となる「ファクト」と「ディメンション」を事前に明らかにしています。データウェアハウスにテーブルを作らなかったとしても、ディメンショナルモデリングを意識することで、データ分析の手戻りを減らすことが可能です。
例えば、「パッケージ」という機能を 2021 年 11 月にリニューアルしました。ランサーが得意な業務を商品として出品し、商品が購入されたら成果物を納品する仕組みです。図1のように、成果物、納品期間、金額を事前にランサーが指定することで、要件定義や見積もりのステップを短縮します。
図1 パッケージ機能のサンプルイメージ
リニューアル後にサービスの利用状況をモニタリングし、改善サイクルを回すにあたって、次のステップでデータ分析の要件を明らかにしました。
ステップ①：ビジネス構造を整理し、図2のように、事業成長の流れ（グロースサイクル）を図示します。
図2 パッケージ機能のグロースサイクル
ステップ②：データ分析によって確認したいこと（分析テーマ）を特定します。今回の問いは「リニューアルによってパッケージ機能の利用が増えたか？」です。
ステップ③：データ分析の結果に応じてどのように対応するか、図3の形式で、アクションの方針案を事前に決めておきます。
図3 分析結果に応じたアクション方針
ステップ④：図4のようにビジネスイベント（ファクト）を、図4のように比較軸（ディメンション）を洗い出し、分析対象を特定します。今回の分析では、パッケージ機能の「成約」に注目しました。
図4 分析対象となるビジネスイベント（ファクト）と比較軸（ディメンション）の列挙
ステップ⑤：分析に必要なデータを確認します。まだデータを取得・保存できていない場合、要件を定義して、担当部署やデータ保有者にリクエストしましょう。例えば、モバイルアプリの開発チームに相談して、新たにログを取得するといったことが考えられます。データ取得の方法論については、拙著『実践的データ基盤への処方箋』の1章を参照してください。
ステップ⑥：図5のようにデータ可視化（ビジュアライズ）の手法・項目要件を決めます。
図5 データ可視化の項目要件
ステップ⑦：データ可視化（ビジュアライズ）のプロトタイプを作成します。ホワイトボードに図6のようなラフスケッチを手書きします。
図6 データ可視化のスケッチ
この分析によって「リニューアル前後で本機能での流通総額が32%増加したこと」「機能リニューアルだけでは新規ユーザー登録を促進できていないこと」が分かりました。2022年3月期第3四半期決算説明会や年次セレモニー「Lancer of the Year 2022」にてその旨を発表。システム開発者が中心となって機能改善を進めていましたが、データ分析の結果を踏まえて、マーケティング担当者の関与を増やすことになりました。その後も成長を続け、2024年4月にはパッケージ出品数が10万件を突破しています。
担当者の思いつきでデータ集計・グラフ作成するのではなく、事前に検討要素を洗い出し、ステークホルダーと認識を揃えてから分析を行うことがポイントです。成果物のイメージをすり合わせることで、後から「欲しいものと違った」「知りたいことはこれではない」といった手戻りが起きるのを防ぎます。
上記のステップを何回も繰り返すうちに「これが重要なビジネスイベントだ」「いつも同じディメンションで比較している」と気付き、「データ利用者が本当に求めていたテーブル」を構築できるようになります。データエンジニアが考える理想のテーブルを押し付けるのではなく、データ分析者の実践的なノウハウやニーズを踏まえてテーブルを設計することで「使われるデータ基盤」となります。
【2】異なるファクトを束ねたファクトを定義する
ランサーズの「依頼」ファクトテーブルを紹介します。異なるビジネスイベントを横断して分析できるように「複数のファクトを束ねたファクト」を定めています。
ランサーズで仕事を受発注するときには、前述の「パッケージ方式」だけではなく、「プロジェクト方式」「コンペ方式」など、複数の方式から選ぶことができます。方式ごとに仕事のステップは異なるのですが、方式を横断して指標を比較したい、という分析ニーズがありました。
例えば「デザインの仕事はこの方式での受発注が多い」と分かれば、フリーランスのデザイナーにはその方式をおすすめできます。また、パッケージのリニューアル後には、「どのカテゴリでパッケージ利用が増えたのか」「パッケージの影響で利用が減ってしまった方式はないか」といった疑問が生じました。
図7 方式別のステップと横断指標
そこで、横断でデータを比較できるように、図7の形式で、共通のステップを定義しました。ランサーズ社内では、クライアント企業のニーズが顕在化するステップを「依頼」として定めています。依頼の件数、UU（ユニークユーザー数）、金額を比較することで、マーケティング活動やプロダクト改善に活かすことができます。この「依頼」という概念は、あくまで社内のデータ分析で使うための非公式のキーワードであり、ウェブサイトで社外向けに掲載している言葉の使い方とは必ずしも一致していません。
データウェアハウス上で、各方式のデータを結合して「依頼」というファクトテーブルを作成しました。データ分析者はBIツール経由でこのテーブルにアクセスします。図8が構成図です。
図8 依頼ファクトテーブルの構成図
方式ごとに表示画面や扱う項目が異なるため、プロダクトのデータベース（OLTP）ではテーブルを分けています。一方で、データ分析の観点ではテーブルを横断して分析できるように、データウェアハウス（OLAP）に専用のファクトテーブルを作成しています。
業務システムやプロダクトの仕様に依存せず、ビジネスとして計測したい単位に合わせてテーブルを作っていくことが、データ分析を加速させるためのポイントとなります。このようなデータ分析用のテーブルが増えて、横断での集計が容易になると、データウェアハウスやデータモデリングの恩恵を実感できることでしょう。
【3】複数のデータを統合して部署横断のディメンションを整備する
先ほどの「依頼」ファクトテーブルの取り組みでは、1つのデータベースに含まれる3つのテーブルを統合しました。一方で、「ユーザー」ディメンションでは、図9のように、2つの異なるシステムのデータを統合し、ユーザー行動を複眼的に分析できるようにしています。
図9 MySQLとGoogleアナリティクスを統合した「ユーザー」ディメンション
1つはウェブサイトのデータベース（MySQL）に含まれている「ユーザー登録情報」です。デザイナーやライターといった「職種」情報や「「2024年2月に◯◯円の報酬を得た」といったデータが保存されています。
もう1つは、アクセス解析ツール（Googleアナリティクス）に含まれている「ユーザー行動ログ」です。「2024年1月に https://www.lancers.jp/work/search/design ページにアクセスした」といった情報が保存されています。
これらのデータを組み合わせることで「このウェブページを訪問したユーザー」が「どのような職種」で「どのくらい報酬を得ているのか」といった分析が可能になります。
さらに、まだ取り組みの途中ではありますが、営業チームが使っている営業管理ツール「Salesforce」や、マーケティングチームが使っている問い合わせ対応ツール「Zendesk」「Channel Talk」のデータを統合すれば、さらに多面的なユーザー像を把握できるようになります。全員が同じデータ基盤上で「ユーザー」の利用状況を確認し、部署横断で一致団結してユーザー体験向上を追求できるようになると期待しています。
【4】複数サービスのデータを統合してグループ会社横断のディメンションを整備する
「依頼」ファクトや「ユーザー」ディメンションは、ランサーズという1つのウェブサービス内でのデータ統合でした。さらに広げて、複数サービスのデータを統合した「グループ会社の横断ユーザー」テーブルの事例を紹介します。
ランサーズグループでは、これまで紹介してきた「ランサーズ」とは別に、専任エージェントがマッチングを仲介する「ランサーズエージェント」や、現役のエンジニアやデザイナーと学びたい人をオンラインでマッチングする「MENTA」など、複数のサービスを運営しています。この3つのサービスの「ユーザー」テーブルを図10のように統合し、グループ会社横断での「ユーザー」ディメンションを作成しました。
図10 グループ会社横断の「ユーザー」ディメンション
データ統合により、グループ会社横断でLTVを計測できるようになります。LTVとはLife Time Value（顧客1人が生涯にわたって企業にもたらす価値）の略で、ランサーズグループのビジネスモデルだと「ユーザーごとの報酬総額」が該当します。ランサーズ単体では稼ぎが減っているように見えても、エージェント経由の仕事をメインで扱うように切り替えたり、MENTAで弟子を育てて仕事を任せたりしているのかもしれません。事業部単体のデータだけを見ると「ユーザーの利用が減った」とネガティブな評価になりますが、横断で見ると「ランサーズグループのサービスを利用し続けている」とポジティブな評価になります。事業部横断での集計が容易になると、データ基盤の恩恵を実感できます。
また、2020年にランサーズグループがMENTAを買収した際には、ランサーズとMENTAの利用状況の重なりを集計し、M&Aの成果（シナジー効果）をモニタリングすることにも役立ちました。サービス間でのシナジー効果を確認できると、データ分析によってM&Aや新規事業の立ち上げといった経営施策を後押しできます。データエンジニアが本書の意義を経営陣にアピールするときの好例と言えるでしょう。
最近では「ランサーDB（データベース）」という社内ダッシュボードで上記のテーブルを参照しています。ランサーDBのダッシュボード画面は、社長室のモニターに投影しており、常にコーポレートミッションを意識しながら経営がなされるようになっています。「1人のランサーがサービス横断でどのくらい報酬を得ているのか」「カンパニー全体でどのくらい仕事の機会を提供できているのか」「ランサーズの仕事だけで生活できる水準の報酬を何人に提供できているのか」を確認できます。
図11 複数サービスのユーザーテーブルの統合
本書はディメンショナルモデリングがメインですが、データの前処理についても本稿で補足説明します。サービス横断でのデータ統合は、必ずしも100%の精度ではなく、「ユーザーIDが紐づくケースではユーザーIDで判定する」「そうでない場合はメールアドレスをハッシュ化した値で判定する」など、利用可能なデータを組み合わせて「分かる範囲で統合する」というアプローチを取ることになるでしょう。
そのため、各テーブルに紐づく「ユーザーID」や「メールアドレスのハッシュ値」のようなキーとは別に、複数のデータを統合した後のサロゲートキーが必要となります。ランサーズの横断分析では、サロゲートキーとして「crm_id」という分析用IDを独自に発行し、「1人のユーザー＝1つののcrm_id」となるようにデータを整備しました。各テーブルのキーからサロゲートキーを取得できるように、図11のような変換用の「Hub」（ハブ）テーブルを用意しています。
このような前処理を得意とするデータモデリング手法として、ディメンショナルモデリングとは別に、近年「Data Vault 2.0」という手法が注目されています。Data Vault 2.0は、データの役割に応じて Hub、Link、Satellite、PIT（Point In Time）、Bridge、Referenceといったテーブルに分ける設計手法です。
複数のデータを統合するときに、データ構造の変化を吸収し、柔軟性を持ちやすい特性があります。今回紹介したHubテーブルは、Data Vault 2.0で紹介されている同名のテーブル設計手法を参考にして、独自に解釈・拡張した実装となります。
また、Data Vault 2.0やディメンショナルモデリングと並んで紹介されることが多いのが「OBT：One Big Table」というテーブル設計手法で、大福帳やワイドテーブルと呼ぶこともあります。OBTでは、ファクトとディメンションを事前に結合して、列の多い（横長の）1つの大きなテーブルをデータ分析者に提供します。OBTの実践例については、NE株式会社の寄稿で紹介できればと思います。
図12のように、Data Vault 2.0で前処理を行い、業務知識をディメンショナルモデル（スタースキーマまたはスノーフレークスキーマ）として表現した後、OBTの形式でデータ利用者に提供するといった構成が考えられます。いずれにせよ設計の中心となるのはディメンショナルモデリングですので、まずは本書の内容を押さえることをおすすめします。
図12 データウェアハウスにおける代表的なモデリング手法
【5】データ加工ツールを導入してデータモデリングを加速させる
最後に、ランサーズのデータ活用を支えるテクノロジーについてご紹介します。主なシステム構成は図13のとおりです。
図13 ランサーズにおけるデータ基盤のシステム構成
プロダクトユーザーがウェブアプリにアクセスすると、ユーザー登録や成約といった情報がデータベース「Amazon Aurora MySQL」に保存されます。データ転送ツール（ETLツール）「Embulk」でデータベースからデータを抽出し、データウェアハウス「BigQuery」にコピーします。BigQueryに保存したローデータを、データ加工ツール（ELTツール）「Dataform」で、分析用のテーブルへと加工します。EmbulkやDataformの処理は、ワークフロー管理ツール「Digdag」を経由して起動します。最後に、データ分析者はBIツール「Redash」を使ってBigQueryのデータを参照します。ソフトウェアの動作環境は、コンテナ管理ツール「AWS Fargate」で構築しています。
データモデリングの推進には、Google Cloudの提供するデータ加工ツール「Dataform」が欠かせません。DataformではSQLでデータ加工処理を管理・実行します。SQLを書くだけで図14のように処理の依存関係が可視化され、どのデータが先に処理されるか、どのデータが他のデータに影響を与えるかが一目でわかります。データ処理の全体像を把握しやすくなり、データモデリングが容易になります。
図14 Dataformの画面サンプル*1
Dataformではバージョン管理システム「Git」を用いることで、SQLファイルの変更履歴を保存し、過去の集計ロジックを復元できます。Gitをホスティングするサービス「GitHub」でSQLファイルの変更内容を表示し、プルリクエストという機能で他メンバーへのレビュー依頼も可能です。
ランサーズでは、GitHubでプルリクエストが承認されると、SQLの変更内容が自動で本番環境に反映されるようになっています。レビュー、変更、復元が容易だと「データ加工処理を間違って削除してしまったらどうしよう」といった不安を軽減し、安心してデータモデリングを推進できます。
また、Dataformには、データの品質と正確性を保証するための「アサーション」というテスト機能が備わっています。「値が0以上であること」や「NULLではないこと」など、データが満たすべき条件を定義すると、データが更新されるたびに自動チェックが行われます。問題が検出された場合はメールやチャットに通知を送り、迅速にデータ品質問題を検知・修正することが可能です。テストが充実すると品質の担保されたテーブルをデータ分析者に提供できるようになります。
Google Cloudが外部からDataformを買収した後、公式機能として一般提供を再開したのは2023年6月でした。ランサーズではそれまで、3つの異なるシステムでデータ加工処理を作成・管理していました。
- データウェアハウス「BigQuery」のコンソール画面でビューを作成・管理
- ワークフローエンジン「Digdag」の設定ファイルで加工テーブルを作成・管理
- BIツール「Redash」で集計クエリを作成・管理
1つディメンションを追加しようと思っても、3つのシステムで影響範囲を調べ、個別に変更していかないといけません。Dataformで一元管理するとSQLファイルの影響反映を検索・一括置換するだけで完了できるようになります。従来のシステムを5年以上運用してきたこともあり、まだ完全に移行・統合しきれてはいないのですが、Dataformの活用が広がるに連れて、徐々に運用保守が容易になっています。
なお、Dataformと同様の機能を持つOSS（オープンソースソフトウェア）として「dbt」（data build tool）があり、NE株式会社と株式会社クラシコムの寄稿で事例を紹介しています。
【関連記事】
*1 Google Cloud 公式記事 https://medium.com/google-cloud/
modern-data-pipeline-building-with-bigquery-dataform-a5dff05
65d3 から引用