こんにちは。エンジニアの鈴木（@yamotuki ）です。
M&A マッチングプラットフォームとしての「M&A クラウド 」が立ち上がった4年ほど前から、現在に至るまでデータをどう活用してきたのかというのをざっくりまとめた後に、今のデータ基盤構想とその背景にある考えを書こうと思います。
弊社におけるこれまでのデータ活用に関わる意識の変化
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ツリー構築が属人的
主に②の課題に関わる部分です。SQL がレビューされて、運用開始後もいつでも集計基準を参照して間違いがあれば修正できるようになっているとよさそうです。
これは直近で全てを明らかにするというより、特に長期で取り組んでいきたい課題になります。M&A の成約までは、関係者の情報の非対称性や思惑が交差することにより定式化するのが難しい「ブラックボックス 」になっている部分です。
初回面談
2回目面談
買い手による「買収意向表明」
見えている情報を前提とした買い手と売り手の「大筋合意」
買い手による売り手の「実態詳細調査」
成約
ここのデータの問題としては、どのような登録経路や、どのようなサポートをした顧客が、最終的にどのような成約につながっているかというのがデータとして"繋がっていない"という認識です。登録数もある、マッチング数、意向表明数もある程度取れている、成約数も取れている、となっているのですが、それがそれぞれ独立した集計値になってしまっているのです。流入 経路や途中でのサポートアクションを含めて整理されていれば、分析によってさらに適切なサポートを行えそうです。
データ基盤の技術選定に関する考え方
さて、データ基盤を作ろうという気持ちが高まって、目的もある程度見えてきたとします。技術チームがどのような意図で技術選定を進めているか、整理してみたいと思います。
データ基盤の構成図
弊社は、昨年大型の資金調達を完了 し、売上が伸びてきている状態です。一定のデータは集まってきており、データにより意思決定をできるフェーズになっています。ロングリストがしっかり運用できれば大きなリターンも見込めます。一方で、「データエンジニアリング」の専門家は正社員にはまだおらず、業務委託と顧問の方の知見を借りてアプリケーションエンジニアが構築を進めております。そういう背景ですので、技術選定は以下の前提でやっています。
技術的なハマりどころを減らしたい。はまっても技術情報が豊富にあるツールが良い
データエンジニア専門としている人がメインで手を動かすわけでは無いので、ETL特有の辛さをある程度吸収してくれるツールが良い。クラスタ 管理など自分たちでしたくない。
使えるようになるまでの立ち上がりを速くしたい。種々のデータソースの対応は可能な限り楽にしたい
長期に渡ってデータ活用したいので、作りっぱなしではなく改善サイクルを回しやすい方が良い
価値があるデータが整理できるなら、ある程度お金を払うのはOK
その前提を受けて、今使用しようと検討している技術要素は以下のものです（本職データエンジニアの方、ツッコミ歓迎です！）。
DWH
インスタンス 管理の必要なRedshiftではなくて、Snowflake やBigQueryが良い（今のところBigQueryが有力）。Redshift Serverlessもよさそうだが、一般で使えるようになったばかりでハマると辛い可能性。
ETL
その他ツール
dbt cloud
BigQueryでデータレイク, データウェアハウス, データマートを構築したとして、その間の更新をできるだけ楽にしたい。使われ続けるための更新大事。
最後に
前述した通り、専門性を持って正社員でデータエンジニアをやっている人はまだいません。正社員でデータエンジニアをやってくださる方を募集してます。方向性に共感してくださった方がいらっしゃればお話ししましょう！twitter で @yamotuki の方までDMを下さってもいいですし、実際にデータ活用を旗を振っているCTO荒井とのmeety もあります。
よろしくお願いします！
(図：信頼できないデータ（基盤）の例、DPRプロジェクトのキックオフ資料より引用)
(図：３つのフェーズ、DPRプロジェクトのキックオフ資料より引用)
