こんにちは。エンジニアの鈴木（@yamotuki）です。
データの活用とデータ基盤の構築に関する考えを整理したいと思い、この記事を書いています。
M&Aマッチングプラットフォームとしての「M&Aクラウド」が立ち上がった4年ほど前から、現在に至るまでデータをどう活用してきたのかというのをざっくりまとめた後に、今のデータ基盤構想とその背景にある考えを書こうと思います。
弊社におけるこれまでのデータ活用に関わる意識の変化
2018年~ M&Aクラウドリリースからしばらく
M&Aクラウドプラットフォームのリリースは2018年4月です。データ分析に対して深い知見のある人は社内にもちろんゼロ。しかし、google analytics は入れてあり、mouseflow などユーザ行動が見れるサービスも入っていました。mouseflow は登録フォームのファネルでの離脱点がどこかといった分析もできます。これらを活用して、PdMとエンジニアは以下のような分析をしてサービス改善をしようとしていました。
- アクセスの多いページはどこだろう。全てのページが最低限の機能しかない。analyticsを見てユーザ数が多いところから改善していこう。
- 登録フォームの離脱が多い項目はどこだろう。mouseflowを見てフォームの項目を整理したりステップ分離したりしよう。
- 迷いを生む機能はどこだろう。mouseflowのレコーディングを見て、特にユーザがストレスを抱えているところはどこだろう。
弊社の主な顧客は経営者であり、母数としては多くないのでデータ量としてはあまり多くありません。多くの改善は定性的な情報に基づき「えいや！」で改善をしていました。また、KPIなど指標に関わるデータはエンジニアが依頼を受けて都度出力する運用になっていました。
2020年~ Redashの導入
Redash を導入しました。Redash はデータソースとなるAmazon RDSやSalesforce、スプレッドシートなどに直接繋がっている状態でした。プラットフォームにおける主要な指標を、まずはPdM（マーケ担当兼任）が中心となって測定して改善に繋げようという目的です。
会員登録数やアクション数などがオンデマンドで情報が取れて、ダッシュボードで一覧として見れるようになりました。これにより、重要な指標になる数値がチーム朝会などで確認できるようになり、エンジニア側でもプラットフォームの数値への関心が高まってきました。
その後、Redashは顧客サポートをするメンバーをはじめ、社内全体にも解放されました。このRedash解放により、非エンジニアでも当たり前のようにSQLを使ってデータベースを参照する人が現れました。目的は、顧客サポートのための情報整理や、データ分析をしてサービスの改善提案をすることです。
2022年 データソン実施
弊社では定期的に（本当に定期なのか怪しいですが半年または1年ごとに）全社員が参加するハッカソンが開催されています。第3回ハッカソンは「データの活用」をテーマにしたいわゆる「データソン」です。
データソンを行う背景には以下のような意図がありました。（当時の資料から引用）
データソン。空・雨・傘で表現すると
- 空: データ活用の度合いが人によって偏っている
- e.g. Redash のクエリ作成者が社内の特定のメンバーに偏っている
- e.g. 部署に少なくとも1人ずつ詳しいメンバーが理想的だが、（多分）そうなってない
- 雨: 社内にどのようなデータが存在するのか、データをどのように扱えば良いのか、分析すると何が分かるのかイメージできてないのでは（仮説）
- e.g. データの構造やフラグ値の意味などをエンジニアしか知らない
- 傘: ハッカソンで実際にデータ活用の流れを体験してもらう
全社にデータ活用の意識を持ってもらい、データドリブンの意思決定をすることで会社成長を加速させていこう、ということですね。今回は「データに親しむ」を重視して分析対象は絞り、対象データはプラットフォームのデータベースにあるもののみとしました。
データソンは前半と後半の二部構成でした。
- 前半: 学習の時間です。全社員がそれぞれ何人かのチームに別れて「神父」と呼ばれるSQLが既に書ける人に導かれてSQLを学んで書きました。なぜ「神父」かについては、以下の実際に出された問題のスクショを見てもらうとピンと来る人も多いのではないでしょうか。
- 後半: 応用の時間です。「与えられた仮説からデータベースから事実を集め、何かの提案をする」というお題でした。仮説はたとえば「承諾されやすい打診には何か特徴や条件があるのではないか？」のようなものです。
各チーム奮闘し、結果の発表ではそのまま実務に使えそうな分析もありました。データソンにより、データとSQLに対する苦手意識はかなり減り、（おそらくCTOの筋書き通りに）会社としてデータ活用をしていくぞ！という機運が高まりました。
これからのデータ利活用
このセクションはとても”文字文字しい"です。ちょっと読むのが大変かもしれませんがお付き合いください。
解決したい課題の全体観
さて、データソンで全社のデータ活用の機運は高まったのですが、まだまだ課題は残っています。大まかな課題は以下のものだと思っています。
- ①プラットフォームのみのデータだけを見ていては、会社を効率よく成長させられない
- プラットフォームには、会員登録をしてくれて、その上でマッチングした企業の情報しか載っていません。弊社はプラットフォーム外でのマッチングサポートも一部していますので、プラットフォームDBのような一つのデータソースをもとに分析した結果は、会社全体の成長という面だと片手落ちです。（※「プラットフォーム外」というのは、売り手や買い手またはその両方がプラットフォームに情報を登録していないケース。メールや電話での連絡など。）
- ② 全社員がバラバラに似たようなクエリを書いていては、効率よく正確な意思決定ができない
- エンジニアでもちょっとした情報が無いだけで集計を間違ってしまいます。たとえば deleted_at がついているものが論理削除されており「全数を count() で取得するときには deleted_at が null のものを外しましょう」という情報を全社員が持てるでしょうか（ここまでは分かっても、もっと複雑な条件は沢山あります）。部署ごとにちょっとした理解の違いで似たようなクエリを書いています。これでは信じられる結果にならず、全社の目線を合わせてコミュニケーションできません。
これらの課題の解決方法の一つの答えは、データ基盤を構築して、よく使う指標の元になるデータをデータウェアハウス（以下DWH）やデータレイクに整理して格納しておくことだと考えています。①については、データレイクにはそれぞれ格納した後に、DWHで集約し、プラットフォーム情報もそれ以外の情報も同列な情報として触れるようにすればよさそうです。②についてはデータ取得元としてデータウェアハウスに集約して、例えばdeleted_at問題であれば削除済みユーザはそこに居ないなど整理すればある程度解決しそうです。
データにまつわる具体的な課題
マッチング支援がスケールしない
主に①の課題に関わる部分です。
売り手と買い手のマッチングは弊社社員が頭を捻って紹介するのですが、人間の頭の中の情報だと限界があります。また、レコメンドとして推奨するマッチング先をシステムとして提供する場合も、参照できるデータがなければいけません。M&Aのマッチングは転職のマッチングとある程度類似性があるのでそれで想像してもらえると分かりやすいかもしれません。いくら「いい人」（M&Aだと「いい会社」）であっても、それにマッチする会社（M&Aだと買い手）に会えなければ良い転職はできません。転職エージェントは、転職希望者には沢山のマッチする会社を教えてあげる必要があります。
このマッチング問題に対しての解決策は、データとして「現状の買収戦略や予算」「M&A経験があるか」など各種データがリストで見ることができて、簡単に検索できるようになることが一つ考えられます。そこには世間に一般に公開されている情報以外にも、弊社のメンバーが力を使って集めた鮮度と確度の高い情報が載っているべきです。M&Aの業界だといわゆる"ロングリスト"と呼ばれるものですが、これが簡単に精度高く作れれば、マッチングの質が一定改善されるのではないかということです。
現時点では、そういった集められた情報は社内のスプレッドシートや各部署が管理しているSalesforce, プラットフォームのDBなどに散らばっており、全社横断で見れる形になっていません。
これの解決策としてデータ基盤として情報がデータレイクに集められ、クレンジングされた上でDWH・データマートに乗っかってすぐ取り出せる形が良さそうです。初期的にはSalesforceに情報を集約して暫定のロングリストとして提供することになりそうですが、その次のステップとしてSalesforceを一つのデータソースとしてその他のソースの統合をしていく可能性は高そうです（※構想段階なので2022/09/05時点では社内でも諸説ありです）。
全社に関わるKPIツリー構築が属人的
主に②の課題に関わる部分です。
弊社ではKPIツリーを作ることで、KGIとそれにたどり着くためのKPIの関係を明らかにして、事業のモニタリングと戦略決定に役立てています。KPI個別については戦略に関わるのでここには詳しくは書けないのですが、このKPIツリー作りが属人的になってしまっている問題があります。KPIツリー作りは社内の各所から人力とエクセル力により収集されて実現されています。人力だと転記ミスなども起こり得ますし、部署ごとにKPIの数値集計基準が揃っていないと信頼に足るデータではなくなってしまいます。例えば（※弊社KPIがどうであるかはぼかしつつ、あくまで例えば）プラットフォームの登録数ひとつとっても、「登録延べ人数」をとるのか「削除など考慮した月末時点での登録数」を取るのかで情報が変わってきます。こういった情報が「どのデータソースから」「どういう基準で整形して取られているのか」がコードレビューするようにレビューして整理できたら、より強固な情報をもとに意思決定をすることができるようになります。技術的な大枠の話だと、データレイクからDWHとデータマートを構築するときのSQLがレビューされて、運用開始後もいつでも集計基準を参照して間違いがあれば修正できるようになっているとよさそうです。
成約までがブラックボックスになっている
これは直近で全てを明らかにするというより、特に長期で取り組んでいきたい課題になります。
マッチング後のM&Aの成約までは、関係者の情報の非対称性や思惑が交差することにより定式化するのが難しい「ブラックボックス」になっている部分です。
マッチング後から成約までのフェーズには以下のようなものがあります。
- 初回面談
- 2回目面談
- 買い手による「買収意向表明」
- 見えている情報を前提とした買い手と売り手の「大筋合意」
- 買い手による売り手の「実態詳細調査」
- 成約
ここのデータの問題としては、どのような登録経路や、どのようなサポートをした顧客が、最終的にどのような成約につながっているかというのがデータとして"繋がっていない"という認識です。登録数もある、マッチング数、意向表明数もある程度取れている、成約数も取れている、となっているのですが、それがそれぞれ独立した集計値になってしまっているのです。
理想状態としては、成約に関わる情報が一元管理されており、その成約はどこから入ってきた売り手買い手のマッチングで、間のフェーズで何が起こったから成約したのだろう、というのが分かる形です。各フェーズでうまく行ったケースとうまくいかなかったケースの情報が、流入経路や途中でのサポートアクションを含めて整理されていれば、分析によってさらに適切なサポートを行えそうです。
データ基盤の技術選定に関する考え方
さて、データ基盤を作ろうという気持ちが高まって、目的もある程度見えてきたとします。技術チームがどのような意図で技術選定を進めているか、整理してみたいと思います。
構想段階での構成図は以下のような形です。
弊社は、昨年大型の資金調達を完了し、売上が伸びてきている状態です。一定のデータは集まってきており、データにより意思決定をできるフェーズになっています。ロングリストがしっかり運用できれば大きなリターンも見込めます。一方で、「データエンジニアリング」の専門家は正社員にはまだおらず、業務委託と顧問の方の知見を借りてアプリケーションエンジニアが構築を進めております。そういう背景ですので、技術選定は以下の前提でやっています。
- 技術的なハマりどころを減らしたい。はまっても技術情報が豊富にあるツールが良い
- データエンジニア専門としている人がメインで手を動かすわけでは無いので、ETL特有の辛さをある程度吸収してくれるツールが良い。クラスタ管理など自分たちでしたくない。
- 使えるようになるまでの立ち上がりを速くしたい。種々のデータソースの対応は可能な限り楽にしたい
- 長期に渡ってデータ活用したいので、作りっぱなしではなく改善サイクルを回しやすい方が良い
- 価値があるデータが整理できるなら、ある程度お金を払うのはOK
その前提を受けて、今使用しようと検討している技術要素は以下のものです（本職データエンジニアの方、ツッコミ歓迎です！）。
- DWH
- ETL
- trocco
- 種々のデータソースに対応（少なくともMySQL, スプレッドシート, Salesforceなど今見えている対象に対応） => ETLの辛さの低減
- 日本でのユースケースが多い。サポート厚そう。slackベースで聴ける。 => 専門家リソースが少なくてもカバー
- trocco
- その他ツール
- dbt cloud
- BigQueryでデータレイク, データウェアハウス, データマートを構築したとして、その間の更新をできるだけ楽にしたい。使われ続けるための更新大事。
- dbt cloud
最後に
前述した通り、専門性を持って正社員でデータエンジニアをやっている人はまだいません。正社員でデータエンジニアをやってくださる方を募集してます。方向性に共感してくださった方がいらっしゃればお話ししましょう！
「こいつわかっていないからいっちょ教えてやるわ」という方も歓迎です。お話ししましょう。
twitter で @yamotuki の方までDMを下さってもいいですし、実際にデータ活用を旗を振っているCTO荒井とのmeetyもあります。
よろしくお願いします！
