M&Aクラウドのデータへの取り組みを振り返る【2022年】

こんにちは。エンジニアリングチームのつざきです。月日が経つのは早いもので今年もアドベントカレンダーの季節がやってまいりました。 私は3年前に3人目Webアプリケーションエンジニアとして入社し、これまでM&Aクラウドプラットフォームの開発に主に関わってきました。今年からデータエンジニアリングの世界に入門しております。

この記事はM&Aクラウドの2022年のアドベンドカレンダーの2022/12/3の記事です。今年のアドベントカレンダーのテーマは「2022年の振り返り」です。M&Aクラウドでは今年、データ基盤の構築を行なった他、データ利活用のためにSalesforceのデータ整理などを行なってきました。本記事では、2022年のM&Aクラウドにおけるデータへの取り組みについてざっくりと振り返っていこうと思います。

データドリブンを目指した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の導入

https://www.getdbt.com/

進化的データモデリングのための内部３層構造を実現するためのデータ加工ツールとして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でツイートいただけたら嬉しいです😁

2022年M&Aクラウドアドベントカレンダーが始まりました！

この記事は2022年M&Aクラウドアドベントカレンダーの1日目の記事です。
M&Aクラウド Advent Calendar 2022 - Adventar

こんにちは、こんばんは、M&AクラウドでWebアプリケーションを作っている久保田です。
業務内容としてはM&Aクラウドや資金調達クラウドのシステム開発・保守を行っています。
Twitterやってるのでぜひフォローしてください。@kubotak_public

さて、2022年もついに最後の月となりました。
昨年に引き続き、今年も旗振り役兼トップバッターとして記事を書かせていただいております。

今年のテーマは「今年の振り返り・来年の抱負」

・・・


(；ﾟдﾟ)(つд⊂)ｺﾞｼｺﾞｼ（；ﾟДﾟ）…？！


はい、「今年の振り返り・来年の抱負」です。
ちなみに昨年のテーマは「テック」でした。今年は随分と・・・なんというか・・・ありきたり？
しかしこのテーマにも選んだ理由があります。
それはズバリ

全社一丸のアドベントカレンダーは採用候補者がチェックしている

ということです。もう少しちゃんと説明します。
昨年M&Aクラウドでは初めてアドベントカレンダーを開催しました。それも職種問わず全社横断で記事を書きました。
これにはもともと意図があり、ITの力でイノベーションを起こすスタートアップ企業のメンバーなら職種問わずに「テック」な記事を書こう！というモチベーションです。
アドベントカレンダーといえば近年ではとりわけWebエンジニア界隈がQiita等で記事を書くのが一種のムーブメントですが、それに馴染みのない人も巻き込んだ全社一丸のプロジェクトです。
社員一同テックであれ、というようなメッセージがあるとかないとか。

そんな内向きな理由がそもそものスタートでした。
しかし意外にも2022年の中途採用者から「アドベントカレンダー見てました」という声があり、「これは採用広報になるのでは？」ということでM&Aクラウドで働く中の人のリアルな振り返りをお届けしたほうが価値があるのではないか・・・というのが今年の趣旨です。
未来のメンバーに対して、「M&Aクラウドではこんな仕事しているんだ」「こんな人が働いているんだ」と認知してもらえる良い機会だと思いました。

そして今年のテーマ「今年の振り返り・来年の抱負」となったわけです。おそらく来年以降も同じテーマで開催できるので実にサスティナブル。
SDGsもニッコリです。

前置きが長くなってしまいましたがここから私の「今年の振り返り・来年の抱負」を書いていこうと思います！

2022年の振り返り

業務的な振り返りをすると上半期はAWS CDKを利用してElasticBeanstalkからECSへの移行、下半期は資金調達クラウドの新規開発が大きなトピックでした。
ECS移行に関してはこちらの記事で詳細をお伝えしています。

tech.macloud.jp

また資金調達クラウドではSvelteKitというまだメジャーバージョンがリリースされていないフレームワークを採用しています。
それについての記事はこちらです。

tech.macloud.jp

なんだかんだスタートアップらしく毎年新しいことにチャレンジしていると思います。
とはいえやはり日々成長するアプリケーションですので負債、いわゆるイケてないところも目についてきてしまいます。
新しいことにチャレンジしつつ泥臭くイケてないところも直していく、そんな両立が必要だと思いますので弊社に興味のあるWebエンジニアの方は参考にどうぞ。詳しく知りたい場合はTwitterDMとかで私を捕まえてください！

個人的な振り返りをすると今年はプライベートで特に進捗なかったなーと思います。
共同執筆で技術書を出版させていただきましたが、執筆していたのは実際には昨年だったりするので今年は勉強会登壇とかに時間を割いた時間が多いかも知れません。
ちなみに書籍はこちらです。興味のある方はどうぞ〜 books.mdn.co.jp

2023年の抱負

業務については引き続きイケてないところの改善が必要かなと思います。
あとは今年11月にリリースした資金調達クラウドの評判が良いみたいなので引き続きこちらも開発をモリモリやっていくと思われます。

個人的には何らかのアプリケーションを作ろうかなーと考えてますがモチベーションの上がるアイデアがないので来年中になにか手を動かしたいなーと思ってます。

ではでは明日のアドベントカレンダーは弊社エンジニアリングマネージャの鈴木さんです。お楽しみに！！！

株式会社M&AクラウドはVueFes Japan Online 2022のブロンズスポンサーです

株式会社M&AクラウドはVueFes Japan Online 2022のブロンズスポンサーです。
Vue Fes Japan は JavaScriptのUIライブラリであるVue.jsを扱った日本最大級のカンファレンスです。
2019年、2020年は災害や感染症リスクにより開催が延期されていましたが今年2022年10月16日（日）ついに開催となります。

vuefes.jp

弊社でもVue.jsを利用したフレームワークであるNuxt.jsを採用しております。

tech.macloud.jp

また、Nuxt.jsを扱ったオンライン勉強会「Nuxt道場」なども実施しています。

tech.macloud.jp

VueFes Japan Online 2022は無料でオンライン参加可能です。

全員インフルエンサー活動が3年経過してどうなっているかお伝えします

こんにちは、こんばんは、kubotak（@kubotak_public）です。

突然私事ですが、M&Aクラウドにジョインして丸三年が経ちます。（実際には11月ですが誤差）

tech.macloud.jp

私の入社後から弊社では社外発信を強めていこうという活動が始まりました。
これをエンジニアチームでは「全員インフルエンサー」というバリューで呼んでいます。

全員インフルエンサーについては以下を参照

tech.macloud.jp

簡単にどういう活動か説明しますと、エンジニア向けの投稿サイトで記事を書いたり、イベントに登壇していこうぜ！！！というアウトプットを推奨する活動です。
他社には見かけないなかなか尖ったバリューではないかと思います。
一応勘違いを避けるために、このバリューは強制しているわけではなく基本的には自発を促しています。

まずは結果を振り返ってみる。

2020年から始めた活動ですがどのような結果を残せたのかを紹介したいと思います。

2020

イベント	登壇	LT
PHPerKaigi2020	-	1
PHP Conference 2020	1	3

エンジニア人数: 5人
計: 5回

2021

イベント	登壇	LT
PHPerKaigi2021	3	2
PHP Conference 2021	3	2

エンジニア人数: 6人
計: 10回

2022

イベント	登壇	LT
PHPerKaigi2022	1	5
スクラムフェス大阪2022	1	-
PHPカンファレンス沖縄2022	2	-
PHP Conference 2022	1	3

エンジニア人数: 8人
計: 13回

いかがでしょうか？人数とともに登壇数も伸びていて、まさに「全員インフルエンサー」を体現できていると思います。
ちなみに、ほんとうの意味でメンバー全員が登壇しているので文字通りの全員インフルエンサーでもあります。
そして、入社後に初登壇を果たしたメンバーは8人中5人も居ます！

なぜ全員インフルエンサーが可能なのか

正直なところ全員インフルエンサーはエンジニア人数が増えれば増えるほど難しくなり、今後は達成することは難しいことだという認識は持っています。
しかし、現時点でなぜここまでできたのかと言うと、以下のような取り組みのおかげだと思っています。

まだ人数が少ないうちに全員登壇経験をさせる

これは強制ではないので「させる」という言い回しは適切ではないと思いますが登壇できるようにサポートすることが大事だと思います。
周りを見渡せば全員が登壇経験がある。ということは登壇に対しての相談もできるし、登壇前にどんなプロポーザルを出すべきか、どんな資料を用意しておけばよいかなどのお手本が、「誰を見ても」持っているという状態になります。
登壇することに対しての心理的ハードルを下げることに役立っていると思います（逆にプレッシャーになっていたら申し訳ない）

イベントのスポンサーをやる

所属している企業が技術系イベントのスポンサーをしていることでそのイベント自体に興味関心を持ってもらいます。
そもそも知らないというメンバーもいると思います。しかし、「こんなイベントあるよ〜行ってみなよ〜登壇してみようよ〜」と言われても関心持てないですよね。
なのでスポンサーをすることで弊社はイベントに関心を持っている。というアピールをしていくのは大事だと思います。

勉強会チャンネルを用意する

弊社ではSlackに勉強会用のチャンネルがあります。そこでは次に開催されるイベントやスポンサーをするイベントを告知したり、そのイベントのプロポーザルが開始した際の告知をします。
さらにプロポーザルの開始時には特定のメンバーにメンションを送って「○○さんのあのときの実装の話できるんじゃない？」などの明確にどんな内容を喋ってもらいたいかまで伝えます。
個人的にはこれが一番効果があると思っていて、私自身も「最近やってることで喋れる内容無くない・・・？」と思いがちですが、他のメンバーから「あの話良さそう！」と提案をもらえるとありがたいです。

まとめ

「全員インフルエンサー」活動が3年経過したのでまとめてみました。
いかがだったでしょうか？他社でも真似できる取り組みがあればぜひ真似してみてほしいです。
また、「全員インフルエンサー」いいな、と思ったらぜひ弊社のカジュアル面談でもどうぞ！！！！

www.wantedly.com

M&AクラウドはPHPカンファレンス2022のゴールドスポンサーです

弊社M&Aクラウドは2022年9月24・25日に開催されるPHPカンファレンス2022のゴールドスポンサーです。
phpcon.php.gr.jp PHPカンファレンスはプログラミング言語「PHP」を扱う日本最大の技術カンファレンスです。
弊社から4人のメンバーが登壇予定です。

fortee.jp

fortee.jp

fortee.jp

fortee.jp

今年はオンライン・オフラインのハイブリッド開催となり、2019年以来の大田区産業プラザPiOにて開催されます。
弊社メンバーも数人は会場にて参加予定ですので見かけた際にはぜひ声をかけてください！

【スタートアップ】会社フェーズ毎のデータ活用とデータ基盤の「これから」

こんにちは。エンジニアの鈴木（@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
  • インスタンス管理の必要なRedshiftではなくて、SnowflakeやBigQueryが良い（今のところBigQueryが有力）。Redshift Serverlessもよさそうだが、一般で使えるようになったばかりでハマると辛い可能性。
• ETL
  • trocco
    • 種々のデータソースに対応（少なくともMySQL, スプレッドシート, Salesforceなど今見えている対象に対応） => ETLの辛さの低減
    • 日本でのユースケースが多い。サポート厚そう。slackベースで聴ける。 => 専門家リソースが少なくてもカバー
• その他ツール
  • dbt cloud
    • BigQueryでデータレイク, データウェアハウス, データマートを構築したとして、その間の更新をできるだけ楽にしたい。使われ続けるための更新大事。

最後に

前述した通り、専門性を持って正社員でデータエンジニアをやっている人はまだいません。正社員でデータエンジニアをやってくださる方を募集してます。方向性に共感してくださった方がいらっしゃればお話ししましょう！
「こいつわかっていないからいっちょ教えてやるわ」という方も歓迎です。お話ししましょう。 twitter で @yamotuki の方までDMを下さってもいいですし、実際にデータ活用を旗を振っているCTO荒井とのmeetyもあります。 よろしくお願いします！

新規プロジェクトのフロントエンドにSvelteKitを採用しました

こんにちは、こんばんは、kubotakです。（@kubotak_public）

今回の記事は、M＆Aクラウドの新しいプロジェクトのフロントエンドにSvelteKitを採用したよ！という内容です。
なぜSvelteKitを採用したのか、他のフレームワークと検討してなぜ採用に至ったのかなどを紹介したいと思います。
SvelteKitってなに？SvelteKit気になってる！な方はぜひお付き合いください。

SvelteKitってなに？

数年前からReact、Vue.jsに次ぐUIフレームワークとして人気が出ているSvelteをベースにしたSSRやSSGが実現できるフレームワークです。
Svelteは日本では名前を聞いたことがある程度で詳しく知らない。という方が多いと思いますが、StateOfJSでは2019年から人気のあるフロントエンドフレームワークです。
また、SvelteKitは2021年で満足度・興味ともに最も注目されています。

kit.svelte.jp

なぜSvelteKitを採用したの？

お世辞にも現時点で日本で知名度があるとは言えないSvelteKitをなぜ採用に至ったかという経緯をお話したいと思います。
まず弊社ではNuxt.jsを採用したプロジェクトがあります。
シリーズでNuxt.jsの採用事例を紹介しています。

tech.macloud.jp

新たに新規プロジェクトのフロントエンドの技術選定をすることになり以下を念頭に検討しました。

• SSRができること
• 素早くキャッチアップできること
• 将来性のあるもの（？）

SSRできること

SEO周りでやはり未だにSSRできるという点は捨てきれず、検索流入が重要であることからこの要件は外せませんでした。
そのため、この点についてはNuxtもしくはNext.jsが真っ先に候補に上がりました。
この時点ではSvelteKitは存在こそ知っていましたが検討のステージに上ることはありませんでした。

素早くキャッチアップできること

弊社ではNuxt.js(v2+Typescript+CompositionAPI)による開発実績があるためNuxt3を採用した場合のキャッチアップについては懸念がありませんでした。
しかし、Next.jsについてはNext.js及びReactに関して深く理解できているメンバーがほぼいなかったこと、初期導入レベルを私が試した限り、useCallbackやuseMemoなどの利用の見極めやディレクトリ設計などに知識がないため開発の初動に大きく影響があるという感触を受けました。
今回の新規プロジェクトは最初期のリリースまでの速度が重要であり、開発スピードが重要視されているためこの点に不安を大きく覚えました。

将来性のあるもの（？）

昨今の流行りを鑑みると、やはりNext.jsが優位ではないかと思います。私はそう思いました。
逆にNuxtは、3年ほど前がピークでそこから人気に陰りがある印象を持っています。恐らくNuxt3のリリースがまだ正式ではないからではないかと思っていますが、エンジニア採用などを考えるとやはりReactが強いだろうなと思います。
さらにVue.jsに馴染みのあるエンジニアでも実はVue.js v2が大半で、v3構文になれている方は少ないのかな？という印象があります。

Next.jsか、Nuxt3か・・・

先程の検討をした結果、Next.jsかNuxt3か、という選択は意外にもPros/Consどちらもあり悩ましい結果となりました。
また、個人的な気持ちはNext.jsに寄ってはいたもののViteという新興のバンドルツールにも注目していて、Nuxt3はこのViteを採用していて開発体験を高めてくれそうだという期待があり、更に悩みの種となりました。
もういっそのこともっと新しいことにチャレンジしても良いのかもしれない？という気持ちになりSvelteKitを検討のステージにあげてみました。

SvelteKitを試してみて

公式ドキュメントは有志により日本語翻訳されているのでとても親切です。翻訳されていなくても公式ドキュメントは丁寧な作りで読むことに苦労することは少ないです。
SvelteKitもNext.js/Nuxtと似たようなルーティングの仕組みで違和感なく使えます。むしろSvelteKitの方が一歩進んでいる印象で、ファイル名に応じてAPIとして振る舞うエンドポイントを作れたりします。
Nuxt3のサーバールーティングをページルーティングと併せ持っているような感じです。
やはりSSRを利用するフレームワークですのでサーバー側でやりたい処理を分離できる仕組みを持っているのは好印象です。
また、バンドルツールとしてViteにもすでに対応していて起動がとても速くて快適です。
マイナスな面としてはいくつかあります。やはりまだメジャーバージョンとして正式にリリースされているものではないのでNuxt3同様の懸念があります。むしろNuxt3より開発が活発な印象があり今でもあらゆるAPIが議論を重ねて変わっています。

それぞれを比較して

これで検討にはNext.jsとNuxt3、SvelteKitがあがりました。
全てにおいてPros/Consはあり、どのフレームワークを採用しても私達が作るアプリケーションには過不足のない機能を持っています。
そこで、以下のことを満たしたフレームワークを採用することにしました。

• メンバーからの同意が得られること
• ワクワクするもの

1つ目の理由は当然として、2つ目の理由はやはりモチベーションを高く持って開発したいという意図があります。
その点でSvelteKitはまだ正式にリリースされているものではなく、いち早くプロダクションで使うことになります。
SvelteKitを使っている企業といえばM&Aクラウド、と思われるように先人を切って行くことはワクワクしませんか？

採用してみて

SvelteKitの開発はとても活発で体感としては2~3週間にはAPIの変更がある印象です。Github issueやDiscordを追ったりしていれば事前に変更を予測できますし、ルーティングの大幅な変更に関しては移行ツールも用意されています。
新しいAPIや仕様変更に伴いバグも発現してきますが迅速に修正されている印象があります。幸いにもまだプロダクションに動いているわけではないので開発を続けながら問題なく最新バージョンに追従して行けている状態です。

さいごに

SvelteKitで開発してみたいという方はぜひ弊社に声をかけてください！

www.wantedly.com

PHPカンファレンス沖縄2022に弊社エンジニアが登壇します

phpcon.okinawa.jp

PHPカンファレンス沖縄2022は2022年8月27日（土）に開催されるプログラミング言語「PHP」の利用者をターゲットとした技術カンファレンスです。

弊社M&Aクラウドから、以下のタイトルで2名のエンジニアが登壇します。

FeatureToggle戦略と運用方法

レギュラートーク 10分
KenjiroKubota

新機能のリリースはどのように行っていますか？
私が所属している会社ではFeatureToggleを利用した機能リリースを行っています。
FeatureToggleとは、新機能のコードを含んだままデプロイを行い、フラグ機能により新機能の有効化・無効化を制御する手法です。
FeatureToggleでリリースするメリットとデメリットについて、またどのように運用をしているのかを紹介できればと思います。

スクラムマスターを経験して得られた学びとエンジニアとしての成長

レギュラートーク 30分
AkitoTsukahara

みなさんはスクラムで開発されていますか？スクラムマスターを経験したことがありますか？
何となくスクラムマスターはエンジニアマネージャーやリーダー適性のある人だけがやるものだと思っていませんか？
確かに適性はあるかもしれませんが、スクラムマスターを経験することで、エンジニアとしてのパフォーマンスが上がるきっかけも手に入れられると自分は考えています。

スクラムマスター経験を通じて得られた学びが、現在エンジニアとしてどのように活かされているのか、ご紹介できればと思います。

▼エンジニアにも効くスクラムマスター経験の学び
・ユーザ価値をより意識する
・アンラーンの面白さ
・ファシリテーション能力
・チームの観察と声かけ

本トークを聞いて、迷っていたけどスクラムやってみようかな？スクラムマスターやってみようかなと思って貰える人が少しでも増えたら幸いです！

2名とも当日は現地沖縄での参加予定です。
会場でお会いしたらぜひ声をかけてください！

Dependabotを導入してライブラリのアップデートを習慣化した話

こんにちは！こんばんは！エンジニアの大石です。

突然ですが、依存ライブラリのアップデートって大変ですよね。

大きなアプリケーションになればなるほど依存するライブラリが増えがちですが、定期的にアップデートされてないか確認したり、習慣的に小さくアップデートするのって結構大変だったりします。

アップデートされてないか確認するだけでも億劫ですし、フレームワークのバージョンを上げるってタイミングで芋づる式に全部上げることになってしまって辛かったり... などなど。

今回は、Dependabotを用いてGitHub上に自動で各ライブラリをアップデートしたPRを自動的に作る仕組みを導入して実際に運用してみた知見を共有したいとおもいます！

Dependabotって何？

Dependabotとは簡単に言うとGitHub上で自動的にプロジェクトが依存しているライブラリのバージョンを上げたPRを作ってくれるボットです。

npm、Bundler、Composer、Gradleなどなど主要なパッケージマネージャーやビルドツールにしてるので大体のケースにおいては有効化するだけで使えます！

入れておくと定期的に自動でライブラリのアップデートを確認しに行ってくれます（頻度は調整可能）。便利ですね！！

有効化してしばらくすると...

DependabotがGitHubに自動で作ってくれるPRの様子

このように自動でPRを作ってくれます！

DependabotのPRの画面から各ライブラリのChangelogも確認出来る

また、このようにライブラリごとにバージョンごとの差分と変更点をまとめて出してくれるので、PRを見て内容を確認してそのままマージする、もしくは詳細に調査してから慎重にアップデートするかの判断が出来ますね。

とりあえず有効化する

単純なLaravel+JSのプロジェクトであれば、以下のファイルをGitHubのプロジェクト上に配置してあげるだけで有効化できます。

.github/dependabot.yml に設定を記述したYAMLを置いておきましょう。

(設定ファイルの詳細な記述方法についてはGitHubの公式ドキュメントが非常に分かりやすいのでそちらを参照してください！)

https://docs.github.com/ja/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

version: 2
updates:
  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    reviewers:
      - "※ レビュワーのGitHubのIDを指定"
    labels:
      - "アップデート対応"
      - "php"
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    reviewers:
      - "※ レビュワーのGitHubのIDを指定"
    labels:
      - "アップデート対応"
      - "javascript"

弊チームでは毎週火曜日に定期的にDependabotで作成されたPRを確認する運用にしているので、毎週月曜日にアップデートの確認が動くように設定して、レビュワーを指定してリマインドするようにしています。

アップデートの運用

アップデートの確認が自動化されて、PRも自動で作られるようになって大満足！！！！ってなりがちですが、ちゃんと運用しないとただPRが放置されて終わってしまうので、弊チームでは以下のような運用にしてアップデートに対処しています。

アップデートのPRが作成されたらやること

(1) 即マージできるか？

テストで動作が担保できると確信できる場合はマージする。

開発時のみに依存しているライブラリの場合はローカルで動かして問題ないと確信できる場合はマージする。

(2)即マージほどではないが開発環境にデプロイしてマージできるか？

開発環境にデプロイして動作に問題ないと確信できる場合はマージする。

デプロイのみに依存するライブラリの場合もこの対応で良い。

(3)メジャーバージョンか？

メジャーバージョンの場合は基本的にどんなライブラリであってもマージしない。

対応IssueをJira上に作成し、どんな変更があったのかを調査してから安全にアップデートする。

（JIRAのIssueを作成するときは、GitHubのコメントに /jira <コメント> を入力で自動的にIssue作成）

(4)マイナーバージョンか？

1と2で問題ない場合はマージできる。

テストが落ちている等の場合はissue化して別途対応する。

(5)パッチバージョンか？

4と同じ

備考

問題ないと確信できない場合は、懸念点・不安解消ポイントなどをあげてJIRA上にIssue化する。

例えば大きめな動作確認が必要である、などなど。

---

といった感じに運用しています。

上に書いた運用ルールは実際に社内で使用している開発のドキュメントから引用したものですが、実際にこの運用で週に5〜10個程度のライブラリをアップデートしています。

ちなみに、Jiraに作成したアップデートのIssueの優先度付けは、以前開発者ブログにて投稿した「インフラタスク優先度定量化」の仕組みで付けています！

tech.macloud.jp

こちらも併せて読んでみてください！！

JiraのIssue作成の仕組み

JiraのIssueに毎回GitHubのPRのURLを貼り付けて、タイトルを書いて... という作業は結構退屈で辛い作業なので、Zapierと組み合わせて自動化しています。

Zapier側で組んだ自動化

仕組みとしては、GitHub上に /jira と書かれたコメントを書くとZapier側で検知して対象のPRから必要な情報を抜き出して、自動的にそれを元にJiraにIssueを作成するようにしています。

さいごに

今回紹介させていただいたライブラリのアップデートの運用は取り組みを始めてばかりですが、より安全に早くバージョンアップが出来るように随時運用の方もアップデートしていきたいとおもいます！

M&Aクラウドではエンジニアを積極採用しています！

www.wantedly.com

完全に余談ですが、最近弊社の社内部活動である #アイドル部 が盛り上がっていて、私が推しているアイドル（Appare!の藍井すず）の名前が広まりつつあって嬉しさを感じています。

Dependabotを使ったライブラリのアップデートの取り組みも社内のSlackに投稿したところから始まったので、些細なことでもシェアできる文化は忘れないようにしたいですね！

祝100記事！技術ブログを継続する意義について

こんにちは、M&Aクラウドのかずへいです。2019年10月に始めたこの技術ブログも、ついに100記事目になりました🎉

大体2週間に1記事は書き続けてきた計算になります。継続できるのって本当にすごいですね！弊社のプロダクトメンバーは本当にすごいです。

今回は、この技術ブログについて振り返りながら、ブログを書く意義について考えていければと思います。

ブログの始まり

良い人が集まり、たくさんの良い仕組みを導入し、良いプロダクトを作り、それを発信して人が集まる、という好循環を作っていきたいと思い、この技術ブログは始まりました。

ブログを書き始めたときには、このブログには発信の役割を期待していました。ですが、記事が増えていく中で、ブログの役割は発信だけでは無いなと思うようになりました。

ブログは発信ではなく、良い仕組み導入のドライバー

ブログでは、過去にもいろんな良い仕組みを導入し、紹介してきました。例えば以下のようなものがあります。

tech.macloud.jp

tech.macloud.jp

tech.macloud.jp

他にも、弊社のM&Aクラウドの開発を進める上での知見を、様々な記事にしてきました。

ブログに書いた記事が増えるにつれて、次の記事では何を書こうか？これは記事に出来るような良い仕組みだったのか？等、 導入する仕組みについての振り返りや技術的な深堀りのきっかけづくりという効果が出始めました。

弊社ではブログのネタを何にするか話あったり、ブログの内容レビューをしたりといったことが日常的に行われています。 振り返りがより次の仕組みへ繋がり、結果的に新しい仕組み導入のドライバーになったなあと思っています。

ブログはオンボーディングの助けになる

また、ブログは新しいメンバーのオンボーディングの助けになりました。

新しいメンバーがつまずいた時に、これってどういう仕組ですか？と聞くと、この記事を読んでとブログの記事を共有することがよくあります。 外に出しても問題ないように、文章に気を使ったり、他のチームメンバーにレビューしてもらったりしているため、ブログの記事は分かりやすく、情報共有にもってこいです。以下の記事などは、弊社独自の仕組みを説明していて、新しく入ったメンバーに読んでもらうと有益です。

tech.macloud.jp

tech.macloud.jp

tech.macloud.jp

ブログが、チーム全体の学習を促す役割を果たし、当初の発信という目的以上の価値が出てきたなあと思っています。

ブログは文章を書く練習になる

エンジニアとして働いている方は、プログラムを書くのはもちろんのこと、PRにコメントをつけたり、社内向けにもドキュメントを作ったりと文章を書く機会が多いと思います。 社外に向けたブログを書くことは、文章を書くとても良い練習の場でになります。弊社ではブログを書いたら、プレビューをみんなに見せてレビューしてもらっているので、その点でもとても勉強になります。

ブログは発信の役に立ったのか？

そして、ブログは当初期待した発信の役割をできているのか？と言うところです。これは正直言ってまだまだだと思います。 弊社のブログがバズりまくって、弊社の名前がTwitterやはてなブックマークを駆け巡り、カジュアル面談が何件も発生するというようなことは、残念ながら起きていません。

しかし、採用のための面談で「技術ブログ読んできました！技術頑張ってますね！」と言ってもらえることは増えました。 弊社と接点を持っていただけた方に、弊社のことを理解してもらうためのツールの一つとしては十分に役立っていると思います。

目標を置かずに続けていく

これからも、この技術ブログは続けて行けたらなと思っていますが、そのために大事なことは目標を置かずに続けていくことだと思っています。

例えば、目標として採用のための申込み数やPV数を置いてしまうと、どうしてもそれらの目標に見合ったものを頑張って書こうとなってしまいます。そうなると、ブログを書くこと自体が難しくなり、ブログを書くことによる発信や副次的な効果を失ってしまうことになります。

気負いせず、日々のチャレンジをメンバーが書き込んでいく形を続けることで、振り返りの機会を提供できる。そんなブログが続いていけばよいなと思います。