こんにちは。エンジニアリングチームのつざきです。月日が経つのは早いもので今年もアドベントカレンダーの季節がやってまいりました。 私は3年前に3人目Webアプリケーションエンジニアとして入社し、これまでM&Aクラウドプラットフォームの開発に主に関わってきました。今年からデータエンジニアリングの世界に入門しております。
この記事はM&Aクラウドの2022年のアドベンドカレンダーの2022/12/3の記事です。今年のアドベントカレンダーのテーマは「2022年の振り返り」です。M&Aクラウドでは今年、データ基盤の構築を行なった他、データ利活用のためにSalesforceのデータ整理などを行なってきました。本記事では、2022年のM&Aクラウドにおけるデータへの取り組みについてざっくりと振り返っていこうと思います。
- データドリブンを目指したRedash時代 (2020年~)
- データ利用の浸透（2022年）
- データ利用の課題
- データプロセス・リエンジニアリング プロジェクト (2022年6月~)
- データ基盤の構築プロジェクト(2022年9月~)
- 1人目データエンジニア入社(2022年11月)
- データへの取り組みのこれから
- おわりに
データドリブンを目指したRedash時代 (2020年~)
M&Aクラウドではデータドリブンな意思決定をしていこうという方針の元、Redashが導入されました。 Redashが導入されてからGoogleAnalyticsやプラットフォームのデータベースにあるデータが、KPIの計測、プロダクト開発のファクトや効果検証に使われ始めました。
データ利用の浸透（2022年）
ここからが2022年の話になります。 データ利用を全社レベルで浸透させる試みとして、2022年4月に「データソン」を開催しました。聞きなじみのない言葉かもしれませんが、簡単に言えばハッカソンのデータ分析版です。学習コンテンツを提供し、後半は、チームごとにデータ分析をしてプレゼンしてもらう。という内容で実施しました。
(図：データソンのスライドの一例)
(データソンについての詳細はこちらの記事の「2022年 データソン実施」をご参照ください。https://tech.macloud.jp/entry/2022/09/06/144901 )
データ利用の課題
Redashは素晴らしいツールですが、データ利用を進める中で以下のような課題が発生していました。
- 複数のデータソースを横断的にクエリするのが難しい
- データが信頼できない
- クエリの再利用性が悪く、各自が自由にクエリを書いている
- データ取得・加工の流れに透明性がない（どこからどのようにデータ取得して加工しているのか追うのが難しい（複合クエリ）
また、Redashの課題とデータ蓄積の課題から次のようなビジネス面での課題が発生していました。
- M&Aのマッチング支援がスケールしない
- マッチング支援をデータによってサポートする仕組みがないため
- 全社に関わるKPIツリー構築が属人的
- 各自RedashでSQLを書いてるため
- M&A成約までがブラックボックスになっている
- データ蓄積できてないため
データに関するビジネス視点で課題については、EMの鈴木さんが詳細を書いてくれていますので気になる方はご参照ください。この記事ではデータ周りの具体的な話を中心に進めていきます。 https://tech.macloud.jp/entry/2022/09/06/144901
データプロセス・リエンジニアリング プロジェクト (2022年6月~)
データプロセス・リエンジニアリング(造語、以下DPR)プロジェクトとは「データに関するプロセスを全社的に見直し、現状の局所最適された状態から全体最適を目指す」プロジェクトです。このプロジェクトでは、「テクノロジーを駆使したフローの構築」のために、「信頼できるデータの構築」と「データにアクセスする手段の構築」の2つのサブプロジェクトに分かれて並行的に走り出しました。
社内での利用状況のヒアリング
各部署とミーティングを行い、部署ごとに業務プロセスとデータの関係を図で整理しました。
(図：ある部署の業務プロセスとデータの関係)
信頼できるデータの構築
弊社でSFAとして利用しているSalesforceには、記事掲載の営業業務、記事のライティング業務、M&Aアドバイザーのアドバイザリー業務などさまざまな利用者がおり、全体像を把握できていない状況でした。また、各部署で自由にオブジェクトや項目のカスタマイズを行なっていたため、弊社にとって重要な情報である、M&Aや資金調達のニーズの情報が散らばって保存されていたり、企業が重複して登録されてしまっているなど、「信頼できるデータ」になっていませんでした。
なお、このプロジェクトでは「信頼できるデータ」を以下のように定義しました。
- 一意性：唯一つだけ存在していること
- 正確性：正しく入力がされていること
- 網羅性：全てが入っていること
(図：信頼できないデータ（基盤）の例、DPRプロジェクトのキックオフ資料より引用)
Salesforceの見直しについては、3つのフェーズに分けて取り組んでいくこととしました。
(図：３つのフェーズ、DPRプロジェクトのキックオフ資料より引用)
変更のルール整備や不要な項目の削除といった地道な地慣らしから始まり、現在は、フェーズ1の顧客データの整備を終え、フェーズ2のOperationデータの整備に着手したところです。フェーズ2では「誰が、いつ、どのように何を紹介（営業）したか」といった情報を「信頼できるデータ」として蓄積する準備を進めています。
データにアクセスする手段の構築
上記の信頼できるデータの構築（主にSalesforce)と並行して、データにアクセスする手段の構築を進めました。前述の通り、Redashではデータ分析できる状況ではありましたが、今後のデータ活用のため、きちんとしたデータ基盤を構築することとなりました。次の章で詳細を記載します。
データ基盤の構築プロジェクト(2022年9月~)
データ基盤の構築プロジェクトでは、データエンジニアの山﨑さんに業務委託で参画していただき、知見をお借りしながら、CTO荒井、山﨑さん、私の3名で進めました。技術調査・技術選定においては山﨑さんがメインで進めてくださいました。
DWH(BigQuery)の導入
DHWはBigQueryを選定しました。他の候補としてRedShift, RedShift Serverless, Snowflakeがありました。 技術選定では、インフラのメンテコストが少ないこと、利用事例が多いこと、情報収集がしやすいこと、がポイントになりました。（専属データエンジニアが1名もいないスタートアップだったので）
進化的データモデリングのためのDWHのアーキテクチャ設計の採用
データ基盤では、データの加工・整理レベルに応じて３層構造でデータを分けるのがベストプラクティスとされています。通常ではこれらの層を別のサービスで実現しますが、ゆずたそさんの記事を参考に、これらの加工処理を一元管理するため、BigQuery内の3つの層を持つ設計を採用しました。
（図：ゆずたそさんの記事より引用）
BigqQueryでの個人情報の取り扱い方針を決定
基本的に「BigQueryには個人情報をいれない」という方針で進めました。しかし、顧客情報と連結してリストを作りたいというビジネス側の要望があり、「個人情報を入れないBigQueryプロジェクト」と「個人方法を含むBigQueryプロジェクト」を分離し、プロジェクト単位でアクセス制御を行うことにしました。 BigQueryにはカラムベースやテーブルベースでのアクセス制御ができるので、将来的にはそういった形になる未来もあるかもしれませんが、初期としては細かい制御は行わずガッツリ分けるという判断にしました。
dbtの導入
進化的データモデリングのための内部３層構造を実現するためのデータ加工ツールとしてdbtを採用しました。
この界隈ではdbt一強という感じだったので採用したという形です。また、dbtはOSSのCLIツールなのですが、有料でSaaS版があります。弊社ではdbt導入にかかる時間的コストを下げるためにSaaS版を利用することにしました。なお、1開発者につき50USD/月で結構高いので、そのうちSaaS版からは離れるかもしれません。
ちなみに、３層構造の話をしましたが、dbtのベストプラクティスに従って実は4層構造になっています。
ETL(Trocco)の導入
https://trocco.io/lp/index.html
様々なデータソースからデータをBigQueryに転送するためのツールとしてTroccoを採用しました。 技術選定のポイントは、インフラ・転送設定のメンテナンスコストが低いこと、国内での事例が多くサポートが手厚いことでした。めっちゃ最高なのでこちらも別途記事にしたいと思ってます。 他の選択肢としては、appflow、Aws workflow for airflow、Cloud Compose・Data Transfer Serviceがありました。
BIツール（Looker Studio）の導入
https://cloud.google.com/looker-studio?hl=ja
BIツールとしてLooker Studioを採用しました。採用した当時はData Studioでしたが、名前が変わりましたね。 技術選定のポイントは、BigQueryとの相性の良さと、値段（無料）なことでした。現状まだガツガツ使っているわけではないですが、今のところは機能不足といった問題は起こっていないです。
社内展開
各種ツールの導入が終わり、一旦データベースのほぼ全てのテーブルと、一部Salesforceのオブジェクトについて利用可能になりました。一部の社内ユーザーは早速BigQueryを使って分析するように移行を始めてくれています。今のところRedashでできていたことと変わらないので（むしろBigQueryの方がデータが少ない）、データソースの追加、便利なデータウェアハウステーブルの提供などを進めていきたいと考えてます。
1人目データエンジニア入社(2022年11月)
11月中旬に、1人目データエンジニアの尾村さんが入社されました。元々データエンジニアの経験のある方で、早速データチームを牽引してくれています。まもなく「入社記事」が出ると思いますのでお楽しみに！
データへの取り組みのこれから
BigQueryの社内利用が開始され、新しいデータ基盤としてようやく動き始めました。しかし、ビジネス価値の創出するためには、やらなければいけないことはたくさんあります。ひとつは、社内のデータ利活用を便利にしてくこと。まだ利用できるデータソースが少ないですし、staging層の提供や、ビジネスデータカタログの提供、分析ニーズごとにデータマートの提供していくことを考えています。次に、現状のデータ分析（KPIの確認）などをデータマートから提供できるようにリプレイスすること。それから、まだデータ化されていない部分のデータ化です。現状ではM&Aのマッチングに関する情報、成約に関する情報などの重要な情報が「信頼できるデータ」として整備されてない状況です。業務オペレーションにも大きく関わってくる部分なので、各部署と力を合わせて実現できたらなと思っております。 個人的には、「データの力でM&Aに流通革命を起こす」ためにやっていくぞ！という気持ちです。
おわりに
最後まで読んでいただきありがとうございます。各種ツールの選定理由や設計、導入してみた結果などの詳細については、別途記事にしていこうと思っております。 「これ気になるよ〜」というのがあればTwitterでツイートいただけたら嬉しいです😁
