M&Aクラウドにおける Four Keys の意義

こんにちは。エンジニアの濱田 (@hamakou108) です。

先日、弊社主催の「PHPerKaigi2023(勝手に)リジェクトカンファレンス」というイベント1 で登壇させていただき、弊社の開発フロー改善の軌跡について Four Keys や継続的デプロイと絡めて紹介しました。元々のプロポーザルで20分想定だった内容を5分で発表したため、泣く泣く削った内容が多々ありました。今回の記事はその補完という形で、弊社における Four Keys の位置付けと取り組んでいる施策について触れたいと思います。

弊社での Four Keys の位置付け

まず弊社での Four Keys の位置付けについて紹介したいと思いますが、その前にそもそも Four Keys の定義について振り返りたいと思います。

Google Cloud による Four Keys Project の紹介では、 Four Keys はソフトウェア開発チームのパフォーマンスを示す指標であるとした上で、次のように定義しています。

  • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
  • 変更のリードタイム - commit から本番環境稼働までの所要時間
  • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合(%)
  • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

Google Cloud の DORA チームは Four Keys を使って計測したチームのパフォーマンスが組織のパフォーマンスの予測指標になることを突き止めており、ほぼ毎年 State of DevOps Report という形で調査結果を発表しています。

弊社では MVV を体現するための中長期的な投資として Four Keys を位置付けています。私たちの開発チームが 2021年の DORA レポート2 においてどのクラスターに分類されるか検証したところ、「デプロイ頻度」と「変更障害率」に関しては Elite に、「リードタイム」と「サービス復旧時間」に関しては High に分類されることが分かりました。2つのメトリクスが Elite に分類されていない状況には私たちのチームがM&Aクラウドの MVV を体現するためのヒントが隠れていると解釈しています。

例えば「変更のリードタイム」が Elite でない点について、長期的にはシステムの変更容易性が低下することを示唆していると仮説を立てることができます。具体的には次のようなシナリオです。

  • システム全体に自動テストが網羅されていないので修正箇所によっては障害のリスクが高い。このリスクを下げるためには念入りな手動確認を行う必要があり、変更のリードタイムが長くなる。このような箇所が広がっていくにつれてこの影響が拡大し、長期的には変更容易性が低下する
  • メンバー同士の情報のやり取りが、結果(プルリクエスト)を主として行われており、そのプロセスや思想に対して行われていない。この結果コミュニケーションコストが増大し、変更のリードタイムが長くなる。チーム数が増えるにつれてこの影響が拡大し、長期的には変更容易性が低下する

長期的な変更容易性の向上は弊社の Vision である「時代が求める課題を解決し時価総額10兆円企業へ」を実現するために必須であると考えています。また「サービス復旧時間」については直接的にユーザーが不利益を被ってしまう時間に関係しており、弊社の Value の1つである「2nd Priority 3」の体現を阻害するものと捉えています。

上述した問題に対してどのように対処すれば良いでしょうか。書籍「LeanとDevOpsの科学」では、ソフトウェアデリバリーのパフォーマンスを統計的に有意な形で改善できるケイパビリティ24個が特定されており、適切なケイパビリティに焦点を当てることで成果を上げることができると記述されています。弊社ではこれを意識した最初の取り組みとして継続的デプロイの導入を行っています。詳しくは冒頭で紹介したカンファレンスの資料をご覧ください。

このように適切なケイパビリティを獲得していくことで、開発チームは MVV の実現に近づき、定量的な結果指標として Four Keys を活用することができると考えています。

Four Keys のモニタリング基盤の構築

Four Keys の活用を進めるにあたって目下取り組んでいる課題が Four Keys のモニタリング基盤の構築です。

前述したクラスター分類に使った Four Keys の数値は、実は手作業で算出されています。手作業だとスポットの数値しか算出できず、今後取り組んでいく施策によってデリバリーのパフォーマンスに改善効果があったのか検証するのも困難です。この問題を解決するために Four Keys のモニタリング基盤の構築に取り組み始めました。昨年からM&Aクラウドではデータ基盤の構築プロジェクトが進行中で、それらのアセットが活用できることも追い風となっています。

実際に基盤構築を進めるにあたって、1点難しい課題がありました。「変更のリードタイム」の計測です。「変更のリードタイム」を算出するためには起点となる commit の時刻、そしてそのリビジョンのデプロイの完了時刻のデータを集計する必要があります。自分が調査した範囲ではこれを実現できる OSS などのツールを見つけることができませんでした。

そこで開発したのが depwatch です。

github.com

このツールによって「変更のリードタイム」の算出するために必要な時刻のデータを GitHub や CircleCI から取得することができます。開発の詳細に関しては自分の個人ブログをご覧ください。

www.hamakou108.com

このツールで収集したデータおよび障害の発生・復旧に関するデータを組み合わせ、 BigQuery 上で加工し、 Four Keys を週次や月次で表示できる基盤を着々と構築しています。今後はモニタリングされる Four Keys の数値から仮説を立て、施策を立案し、検証するサイクルを回していきたいと考えています。

まとめ

弊社での Four Keys の位置付けとモニタリング基盤の構築について紹介しました。 depwatch は OSS として公開しており、今後も機能の拡充を進めていく予定ですので、ニーズにマッチする方がいらっしゃればぜひご活用ください!


  1. PHPerKaigi 2023及び、PHPerKaigi 2023 実行委員会とは無関係のイベントです。
  2. 最新の DORA レポートは 2022年に発表されていますが、クラスターの数が4つから3つに減るなど従来のレポートと比較して大きな変化があったことから、2021年のレポートの定義を採用しています。
  3. 次のような内容のバリューです。「顧客第一になろう。それ以外の都合は2番目に置いておいて、まずはなによりユーザーを大事にすること。ユーザーが求めることの本質に応えること。長期の視点ではユーザーにもっとも価値を提供できる会社が、必ず流通革命を起こす。自分たちの作ったサービスで、ユーザーが喜ぶ瞬間は最高の時間だ。とにかく迷ったら自分達のことより、ユーザーのことを考えよう。」

M&AクラウドはPHPerKaigi2023のプラチナスポンサーです

株式会社M&AクラウドはPHPerKaigi 2023のプラチナスポンサーです。

PHPerKaigiとは

PHPerKaigi(ペチパーカイギ)は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 今年の開催はオフライン会場を軸としたオフライン・オンラインハイブリッド開催です。みなさんのご都合に合う参加方法をお選び頂けます。

2023年3月23日(木)〜 3月25日(土)はPHPerたちのお祭りです! 歴戦の勇者みたいな方はもちろん、初心者の方にも、全てのPHPerが楽しめるイベントです。スケジュール、空けておいて下さい!

※公式サイトより

phperkaigi.jp

登壇情報

弊社からは前夜祭の3/23(木)18:50〜久保田が登壇します。

fortee.jp

ノベルティ

M&Aクラウドからはドリップコーヒーとカロリーメイトを提供しています!
カンファレンスセッション中に小腹が空いたらセットでどうぞ!

ドリップコーヒーとカロリーメイト

※事前にノベルティー付きチケットをお買い元の方のみの配布となります。
カロリーメイト大塚製薬株式会社の商標登録です。

ドラッカーエクササイズでチームビルディングをしてみました

こんにちはみなさん
niisan-tokyoです

先日の3/1にドラッカーエクササイズという手法を用いてチームビルディング会を開催しました。
元々チームビルディングの需要は高まっていたのですが、EMとの 1 on 1 で話題になって、流れで、

「チームビルディングといえば、ドラッカーエクササイズっていうのがありますね」
「そうなんですね。niisan-tokyoやってみます?」
「え?いいんすか?」
「じゃあ、お願いしますね」

みたいな感じですすっと私が開催する運びで決まりました。
今回はそのエクササイズと、チームで実践してみた結果を紹介していきます。

背景

私の入社は2月だったのですが、前年の12月に組織改変があったようで、チームの成立もその時でまだまだ若いチームでした。
しかも、このチームには1月入社の方と私の2人の新顔がいるという状況でした。
そんなわけで、チームとしてはいくつか課題を抱えていたという状況です。

  • 新規メンバーの性質がよくわからない
  • 既存メンバーのことを、新規メンバーはよくわからない
  • そもそもチーム結成も新しいので、お互いの働き方を探っている

こんな感じの状況だったので、チームビルディングを実施してみようという考えがメンバーの中に醸成されていきました。
そんな中、前職でもドラッカーエクササイズをやっているチームがあったので、うちでもやってみようよっていう流れになったわけです。

ドラッカーエクササイズ

前置きはこの辺にして、早速ドラッカーエクササイズの紹介とその目的を見ていきましょう。
私の解釈が入ってしまっているので、もし本物を参照したい場合は、以下のリンクから原典に飛んでください。

The Drucker Exercise | The Agile Warrior

ドラッカーエクササイズとは、アジャイルサムライの筆者が提唱したチームビルディング手法で、以下のような質問に答えてチームメンバーに自分のことを知ってもらい、お互いの特性やロールを認識し、チームとしての成果を最大化することを目的とするものです。

  • 自分の強みは何か
    • 原典では「世界レベルのもの」とか「誰よりもイケてる」ものとして書いてねとある
  • 自分はどのように成果を出すか
    • 仕事のやり方、環境など
    • 「これはやめて」みたいなパフォーマンスを低下させるようなものも含む
  • 自分は何に価値を置いているか
  • 自分はどのような貢献を期待されるか

エクササイズの実践

それではエクササイズをどのように実践したかを述べていきましょう。
エクササイズの内容自体は簡単なので、これをMTGで決められた時間で終わらせるように設計してみました。 また、今回はmiroで実施しました。

ドラッカーエクササイズ実践後の成果物

どのようにしてこの結果が出てきたかを見ていきましょう。

タイムボックス

全体の時間を1時間で設定し、各エクササイズとその表明に各々タイムボックスを設定しました。
具体的にはチーム人数6人で、以下のような段取りを組みました。

  • ドラッカーエクササイズ
    • 説明: 5min
    • 自分の強みを書き出す: 1min(説明)+3min
    • 自分の仕事の流儀を書き出す: 1min(説明)+3min
    • 自分の価値観を書き出す: 1min(説明)+3min
    • 自分に何を期待して欲しいかを書き出す: 1min(説明)+3min
  • 結果の表明・共有・コメント
    • エクササイズの結果を見ながら、各メンバーが自己紹介: 4min
    • 自己紹介を聞きながら他のメンバーがコメントを書き出し: 4min(上と同時)
  • 振り返り: 5min

まず全体の説明を少ししてから、前半で各エクササイズごとに説明を入れつつ書き出しをします。
後半は各メンバーからエクササイズの結果をもとに自己紹介をしつつ、その話を聞きながらエクササイズの結果を見つつ、他のメンバーがコメントを書き出していきます。
最後に振り返りをして、全部で50分くらいです。
各々の実時間としてはほぼ1時間ぴったりと言ったところです。
次に、各エクササイズの中を詳しく見ていきましょう。

エクササイズ

各エクササイズに対し、まず説明と簡単な例を挙げた上で、それぞれがmiroの付箋に書き出しました。
それぞれどのように問いかけ、どのような結果が出たかを簡単に見ていきます。

自分の強みを出す

以下のような質問に対して、原典に倣い、少々大袈裟に書き出してもらいました。

「自分が世界に通づる、もしくは誰よりもできると思うことを3つ捻り出してみよう (自分の強みを表現してみよう)」

説明の時に例を出しますが、

  • 優れた聞き手
  • 混沌に秩序をもたらす
  • 自然な外交官

のような感じで、パワーを感じるものを例示しました。

結果としては

  • 向上心
  • コミュニケーション
  • 手作業を面倒くさいと感じる気持ち

などが上がってきました。
これだけでもかなり個性が出ますね。

自分の仕事の流儀

これは各メンバーが最もパフォーマンスを発揮するためにどうするのかを書き出すものですが、以下のように問いかけました。

「あなたはどんなふうに仕事をするのが好きですか?」

これも初めの説明で例を出すのですが、

  • リストを作りたい
  • ミニマリストだよ
  • マイクロマネージメントされるのは嫌だ
  • 早起き or 朝型

こんな感じです。
パフォーマンスを上げるための手順ややり方とともに、パフォーマンスを下げる要因についても挙げてもらっています。

結果としては以下のようになりました。

  • 持続可能なペースで
  • 大雑把に作ってから細かいの詰める
  • 人を巻き込む
  • 自由な時間に仕事できるのがいい

一月一緒に仕事してきたのですが、「確かに」と思えるところもあり、納得感が出ました。

自分の価値観

価値観というのが結構難しく、スクラムマスターをしている知り合いから事前にアドバイスを聞いていました。
より書き出しやすくするために以下のような表現で問いかけを作りました。

「あなたの好きな言葉・単語・ことわざ・価値観をあげてみてください」

例としては以下のものを挙げました

  • 質の高い仕事
  • 他者への敬意
  • 信頼される
  • 改善し続ける

これに対し、メンバーが挙げくれたのが以下のようなものです。

  • 多元論
  • 将来への投資
  • とりあえず寝る
  • Money Power Respect
  • 一日半歩
  • Whyからはじめよ

なかなか個性的なものが揃ったように思います。

自分に何を期待して欲しいか

これはそのままですね。ここまで強み・仕事の流儀・価値観を出してきたので、これらを参考にして書くこともできます。
問いかけは以下のようにしました。

「あなたはどうのようにチームに貢献しますか?あるいは、チームはあなたに何を期待できますか?」

例示したのは以下のようなものです。

  • 素晴らしいユーザー体験
  • 必要な時に必要な分だけ分析を行う
  • 現実的な計画

これに対して出てきた結果はこんな感じです

  • リーン思考
  • 決定打に欠くことを決める
  • センス

これに関してはかなりばらけたように思います。
チームメンバー各々が多様な方向から貢献していけることがわかります。

自己紹介とコメント

エクササイズが終わったら、その結果を参照しながら各メンバーごとに自己紹介をしてもらいます。
発表者以外のメンバーは、発表者の自己紹介を聞きつつ、エクササイズの出力を見ながらコメントを書き出します。

自己紹介に関しては、エクササイズ結果があるため、その内容を使いながら、各メンバー結構スムーズにできていたように思います。
また、コメントは各メンバーごとに一人一つずつくらいかと思っていたのですが、2つ3つ出てきたりして、用意した領域が足りなくなりました。
もしドラッカーエクササイズをこのやり方を参考にして実践する方がいれば、コメントの領域は大きめに取ったほうがいいです。
コメントの付け方にも個性があって、キャッチコピーみたいな感じでコメントを残す方もいました。

キャッチコピー

とりあえず私にこのキャッチコピーをつけた方には「キャッチコピー大臣」の称号を与えましょう。

ふりかえり

こういう会に関しては、基本的にふりかえりをするのが私の流儀です。
今回はFun-Done-Learnを使ってふりかえりを行いました。

Fun-Done-Learn
全体を出すと画像が荒くなってしまうので、中心付近を持ってきました。
価値観に関してはなかなか学びが深かった印象です。

カメレオン??なんだったかな...

振り返りとまとめ

こんな感じで、ドラッカーエクササイズを使ってチームビルディングをやってみました。
私も知識では知っていましたが、いざ実践となるとうまくできるか不安でした。
やってみれば、メンバーはみんな協力してくれましたし、楽しんでくれたようで開催した意義は十分出せたかなと思います。

改善するとしたら、以下の点は考えてもいいかなと思います。

  • 各メンバーのキャッチコピーを作るのは面白そう(時間があれば)
  • 書き出しスペースはあと1.5倍くらい広くするといい(コメントと価値観の部分がはみ出しました)

というわけで、今回はこんなところです。

宣伝

M&Aクラウドはまだまだ積極的な採用を続けています。
興味のある方は応募してみてください。

macloud.notion.site

niisan-tokyoから紹介してくれよって方は、私のtwitterにDM送ってもらってもオッケーです。

twitter.com

それではまた

【入社エントリ】2月に入社しました

こんにちはみなさん

2023年の2月にM&Aクラウドに入社しましたniisanです。
私も例によって入社エントリーなるものを書いてみようと思って書いた次第。

入社の経緯

前職も非常に成長速度の速い会社でしたし、メンバーの活気もあるいい会社でした。
しかしながら、その中において自身が発揮したいバリューが、その成長にあまり寄与しないのではないかと考えるようになりました。
そんな中で @kubotak からDMをもらい、M&Aクラウドの世界へと誘われたという形です。

まあ、当時はコロナにかかっていて、返信がなかなかできなかったりしたのですが、ゆっくりとカジュアル面談や面接を続けていき、その中でM&Aが単なる会社の売買ではなく、事業のより効率的な成長や規模の拡大によるトータルの管理コストの削減など、さまざまな戦略に根ざしていることがわかっていき、ありきたりな言葉ですが、とても面白そうだなと感じたわけです。

しかも、このM&Aの世界に対し、テクノロジーの力で革命を起こすとしており、自分のやりたいこと・発揮したいバリューに合致しているなと思い至り、入社を決意しました。

やりたいこと・発揮したいバリュー

ちなみに、自分のやりたいことは何かということですが、一言で言うと、「ユーザーの自発的な行動を促し、業界を活発化させられるプロダクトを作る」と言うことになります。
発揮したいバリューは、そのプロダクトの成長に貢献することであります。

M&Aクラウドにおいては、ユーザーがM&Aクラウドというプロダクトを通して、積極的にM&Aに挑み、成功を掴み取ることができるようにしたいですね。

入ってみて思うこと

スプリント中に見積もりやリファインメントがちょいちょい入る

前職ではプランニングやレビューに結構な時間を費やしていましたが、M&Aクラウドではかなりスリムになっています。
これは、事前にこまめにリファインメントや見積もりをし、ステークホルダーと事前に前提や開発内容の共有をしているからです。

スプリント中にリファインメントや見積もりを入れるとスイッチングコストが高くならないかと思ったのですが、各々の時間は短く区切られているためか、実際にはたいして気にならなかったし、なんならちょっとした気分転換になっていい感じでもあります。

リリースサイクルが早い

github flow を採用していて、mainにマージしたらそのままリリースされるようになっていて、これが日に数回のペースで発生するため、リリースのペースが非常に早いです。
長期間続く開発ブランチがあると、そこで行われたリファクタリングがなかなか反映されなかったり、mainとの差分が拡大することで発生するコンフリクトの修正に余分な時間が取られたりする事態を防ぐためですが、それでも目まぐるしくリリースされていきます。
実際にはfeature flagをつけることで、ユーザー影響を制御しているので、ユーザーがそのリリース速度を体感することはないとは思いますが、思い切りのいいチームだぜ!って思いますね。

おわりに

というわけで、M&Aクラウドの入社エントリーを書いてみました。
最近はあまり活動してませんでしたが、QiitaやZennにちょいちょい記事をあげたりしていましたので、よろしければそちらもみていただけるとありがたいです。

qiita.com

zenn.dev

また、最近は半ば私の運動履歴を書き連ねるだけのアカウントになっていましたが、twitterもやっていますので、DMとかするともしかしたら反応するかもしれません。

twitter.com

それでは今後ともよろしくお願いします。

SvelteKit with Sentry

こんにちは、こんばんは、久保田です。

この記事ではSvelteKitにSentryを導入する方法を紹介します。

Sentryってなに?

詳細は割愛します。ざっくりいうとアプリケーションのエラーを集約するSaaSです。
詳しくはサイトなり別途解説された記事を参照ください。

Application Performance Monitoring & Error Tracking Software | Sentry

SvelteKitにSentryを導入する

まず、SvelteKitでSentryを導入する際に気をつける点があります。
それは、「SSR時のエラーか、CSR時のエラーか」ということです。
SvelteKitはSSR(サーバーサイドレンダリング)できるフレームワークですので、サーバーでNode.jsによって実行されるランタイムがあります。
また、SSRされた後配信されたHTMLとJSによってブラウザで実行されるCSR(クライアントサイドレンダリング)のランタイムがあります。
ですので以下の状況のエラーを捕捉する必要があります。

  • サーバーでエラーが発生した場合
  • クライアントブラウザでエラーが発生した場合

それではそれぞれのエラーをSentryで捕捉できるようにしていきます。

導入

まずはSentryのライブラリを導入します。 導入するのは次の6つです

  • @sentry/browser
  • @sentry/integrations
  • @sentry/node
  • @sentry/svelte
  • @sentry/tracing
  • vite-plugin-sentry

npmの場合は以下のようにインストールしてください。

npm install -S @sentry/browser @sentry/integrations @sentry/node @sentry/svelte @sentry/tracing vite-plugin-sentry

ビルド時にSentryへmapファイルを送るためのViteプラグインが用意されているので設定します。

vite.config.(js|ts)

import viteSentry from 'vite-plugin-sentry'

// 略

plugins: [
    sveltekit(),
    viteSentry({
      url: 'https://sentry.io',
      authToken: process.env.SENTRY_AUTH_TOKEN,
      org: 'ma-cloud',
      project: 'yell-front',
      release: process.env.VITE_SENTRY_RELEASE,
      deploy: {
        env: env.mode
      },
      setCommits: {
        auto: true
      },
      sourceMaps: {
        include: ['./build/client/', './build/server/'],
        ignore: ['node_modules']
      }
    }),
],
// 略

サーバーエラーの捕捉

SvelteKitはサーバーで処理される際のミドルウェアのようにリクエスト処理とレスポンス処理を挟み込んだ処理を書くことができます。 それがhooksです。

Hooks • Docs • SvelteKit

hooks.server.(js|ts)を作成し、エラーハンドラでSentryのライブラリが起動されるように設定します。

import type { HandleServerError } from '@sveltejs/kit'
import * as Sentry from '@sentry/node'
import { RewriteFrames } from '@sentry/integrations'

if (import.meta.env.VITE_SENTRY_DSN) {
  Sentry.init({
    dsn: import.meta.env.VITE_SENTRY_DSN,
    tracesSampleRate: 0.01,
    environment: import.meta.env.VITE_ENVIRONMENT,
    release: import.meta.env.VITE_SENTRY_RELEASE,
    integrations: [new RewriteFrames({ root: '/var/www/yell-front/build/server/' })]
  })
}

export const handleError: HandleServerError = ({ error, event }) => {
  if (!(error instanceof Error)) {
    return
  }
  Sentry.captureException(error, {
    extra: { event: event },
    tags: { ssr: true, ip: event.getClientAddress(), errorId }
  })
  return {
    message: 'Whoops!' // 適宜変えてください
  }
}

クライアントエラーの捕捉

こちらもhooksが利用できます。 hooks.client.(js|ts)を利用することでクライアントブラウザでのエラーハンドラを利用することができます。

import type { HandleClientError } from '@sveltejs/kit'
import * as Sentry from '@sentry/svelte'
import { BrowserTracing } from '@sentry/tracing'

if (import.meta.env.VITE_SENTRY_DSN) {
  Sentry.init({
    dsn: import.meta.env.VITE_SENTRY_DSN,
    tracesSampleRate: 0.01,
    environment: import.meta.env.VITE_ENVIRONMENT,
    release: import.meta.env.VITE_SENTRY_RELEASE,
    integrations: [new BrowserTracing()]
  })
}

export const handleError: HandleClientError = ({ error, event }) => {
  Sentry.captureException(error, {
    extra: { event: event }
  })
  return {
    message: 'Whoops!' // 適宜変えてください
  }
}

サーバーもクライアントも共通してhandleErrorでエラーを捕捉することができるので同じような記述で対応することができます。
SvelteKitではどちらのエラーもhooksに集約できるので見通しよく管理ができて良いですね。

【入社エントリ】中途入社しました

みなさん。初めまして! 先月からM&Aクラウドにジョインしました。栄山です。(えいやまと読みます)

ツイッターこちら です。よろしくお願いします

入社まで

前職はIT技術者派遣会社でWEBエンジニアをしていました。

認証系アプリの開発、ゴルフ関連アプリの開発、ポイントサイトの開発保守と様々な案件に携わりました。 業務にあたる中で、ユーザーのフィードバックを受けてプロダクトを改善するの楽しいということに気づきました。

そんなある日、ひょんなことからM&Aクラウドのカジュアル面談を受けることになりました。 その中スクラム開発について議論する機会があり、自分が理想としている考え方に近いことを話していたので面白そうと思い、入社に至ります。

入社してみて感じたこと

入社して1ヶ月ほど経ちましたが、スクラム開発がきちんと機能しておりとても働きやすいです。下記の点が個人的に良いなと思います。

ソースコードが適切な粒度で書かれていて読みやすい

アーキテクチャに沿って意味のある粒度でソースコードが書かれているので、入社して間もない私でも意外に読めてしまいます。 エンジニアはソースコード書く時間より読む時間の方が長いと言われているので、読むのが楽しいソースコードなのがとても良いです。

リリースサイクルがはやい

Feature toggleという機能を使うことで、リリースサイクルを高速化しています。 リリースサイクルが高速化されると、バグにすぐ気づけますし、余計な手戻りも防げるのでとても良いです。

業務改善しやすい

弊社はスクラム開発手法を取り入れており、1週間に1度必ず振り返りの機会があります。良いところやうまくいかなかったところを振り返りチーム内で認識を合わせられます。 仕事中に効率化できるかもと思ったアイデアを相談でき、場合によっては業務改善につながるのでやる気がでます。

これから

前職ではバックエンド中心だったのですが、M&Aクラウドではフロントエンドも触れる機会があるので技術の幅を広げていきたいです。 ユーザーファーストなアプリケーション開発を心がけたいと思います。

Amazon Pollyを使ってAIに音声を読み上げしてもらおう!

こんにちは、こんばんは、エンジニアの久保田(@kubotak_public)です。

先日から弊社では社内勉強会の技術書籍感想会をポッドキャストとして配信をはじめました。 まずはLeanとDevOpsの科学の感想会をしていますので興味ある方ぜひご聴取ください。

open.spotify.com

さて、このポッドキャストのオープニングでナレーションを努めていただいたのはなんとAWSのAIでした。 それが「Amazon Polly」です。

コンソールにアクセスすると以下のような画面からテキストを読み上げてくれます。

話者は「ミズキ(女性)」と「タクミ(男性)」の2種類が用意されていますが、残念ながらニューラル(可能な限り自然で人間に似た音声を生成します。)が利用できるのは「タクミ(男性)」のみでした。 ※2023年1月現在

テキストの入力はSSML(Speech Synthesis Markup Language)に対応していて、例えばポッドキャストのオープニングは以下のようなSSMLを書いています。

<speak>
<p>このポッドキャストは<phoneme alphabet="x-amazon-pron-kana" ph="エムアンドエークラウ'ド">エムアンドエークラウド</phoneme>の<phoneme alphabet="x-amazon-pron-kana" ph="ウェブ">Web</phoneme>エンジニアが、<phoneme alphabet="x-amazon-pron-kana" ph="ウェブ">Web</phoneme>系の技術書籍の感想を語り合うプログラムです。</p>
<p>お題の書籍を各章毎に事前に読んで、その章毎の感想を語り合います。</p>
<p><phoneme alphabet="x-amazon-pron-kana" ph="ツンドク">積ん読</phoneme>している本が紹介されていたら、これを機会に読んでいただいたり、すでに読んだことのある本であれば、思い出していただく機会になれば幸いです。</p>
<p>それでは、本日の感想会が始まります</p>
</speak>

ここだとエムアンドエークラウドはそのままだとエムアンドークラウド↑みたいに読まれてしまうので<phoneme alphabet="x-amazon-pron-kana" ph="エムアンドエークラウ'ド">エムアンドエークラウド</phoneme>とすることでエムアンドークラウド↓と読ませることができます。

読み上げデータはMP3でダウンロードできるので、それを利用してポッドキャストに組み込んでいます。

昨今読み上げAIのソフトウェアやサイトが数多くありますが、権利関係が大変で気軽に使いたいなーと困っていたところAWSに読み上げAIがあり驚きました。 気軽に使えて、なおかつ自然に発声してくれるので興味のある方は使ってみてください!

【入社エントリ】M&Aクラウドにジョインしました。

こんにちは(おはようございます、こんばんは)、この度、M&Aクラウドに1.5人目データエンジニア(これまでは工数的に0.5人分津崎さんが進めてくれていました)としてジョインしたhomura99と申します。よろしくお願いします。入社したのは11月中旬なのですが、文を書くのが得意ではなく、執筆し終えるのに、一ヶ月以上かかってしまいました。

これまでの経歴

一社目

大学院卒業後、それまで、化学畑を歩んできたこともあり、ゴム会社のタイヤ用ゴム材料の開発者として働き始めました。選考自体は化学工学といって化学のようで化学でない学問なのですが、研究者や開発者というものに憧れがあったこと、toC向けの製品の方が実際に使われているところが見えてモチベーションになるかなと思い進みました。研究室の同期も大手消費財やエンジニアリング会社等、いわゆる一流企業と呼ばれる会社に就職していきました。そんな会社で2年近く働いていたのですが、開発者という仕事が私にあっていないことが徐々にわかってきました。仕事内容自体もそうなのですが、特に大きかったのが、1年目の途中で怪我をしてしまったことです。完全に自分の不注意なのですが、私にこの職業は難しいと悟り、再度やらかしてしまわないうちに(ために)転職しました。

二社目

キャリアチェンジということでデータ分析系の仕事を受託をしているベンチャー企業に完全業界未経験ながら、データアナリストとして入社しました。ここでは、研修一ヶ月と自習期間一ヶ月を過ごした後で、前任者が少し燃やしていた後のPJにほぼ一人の状態で客先常駐しました。最初の三ヶ月ぐらいはお客さんと関係を築くのに苦労しましたが、その後は順調にPJを大きくしていくことができ、最終的に4人ほどがその会社からジョインしたPJにまで成長することができました。テーマは自然言語処理とそれまで、全く関わりのなかったものだったのですが、なんとかキャッチアップしながら食らいついていくことができました。

三社目

二社目の会社も1年半ほど勤めた後に転職することにしました。理由は明確で、給料が安かったんです。キャリアチェンジということで一社目から転職するときに下がってしまったので、それを取り戻すプラスアルファぐらいの気持ちで転職活動をしていたら、石油元売り大手の会社さんのDX関連部室にお誘いいただき、データサイエンティストという肩書きで転職しました。入社半年ぐらいは大きくすることもなく、過ごしていましたが、半年すぎたあたりからデータ基盤を構築するPJを主導しました。これまた、ほぼほぼ経験のない分野ではあったのですが、ある程度、順調にPJを進めることができたかなと思います。PJの予算はかなり潤沢にあり、普通ならとても検討の対象に入らないような高額なソフトウェアを使うことも出来ましたし、外部の人的なリソースを追加してもらうのも、難しくなかったため、仕事自体は忙しいといったこともなく、そこそこに楽しかったです。ただ、自分のカバーする範囲がすごいピンポイントになっていることに気づき、ないものねだりで転職することに決めました。

M&Aクラウドに入社した理由

これまでの経歴を見てもらえればわかると思うのですが、M&Aや金融については明るいわけではなく、特にそちらを希望していたわけでもありませんでした。もっと自分の手を動かして進めていきたいと思ったこと、データを主軸にキャリアを築いていきたいと考えていたため、あまり規模の大きくなく、データエンジニアやデータサイエンティストといった職業を募集している会社さんを中心に見ておりました。(スタートアップだと、シリーズB~Cぐらいの会社さんでそのような応募が増える印象あります。)決め手となったのは、CTOの荒井さんの人柄やしっかり考えた上で最新の技術を取り入れていく会社としての姿勢に共感したこと、M&Aという馴染みのない領域だからこそ、面白い発見がデータを使ってできるのではないかと考えたことがあります。

M&Aクラウドでやっていきたいこと

これに関しては、オリジナリティはありませんが、「データを活用して」、弊社のミッションである「M&A流通革命を」起こせたらと思っています。そのためにまずは、まだ生まれたばかりのデータ基盤をもっともっと価値のあるものにしていく必要があると思っています。一口にデータ基盤といっても機械学習や深層学習といった昨今、華々しい成果を挙げている領域から、データ収集やDWH、BIといったわかりやすい領域だけでなく、メタデータやデータの品質管理といった領域、果てはそのデータが生み出される部分までデータエンジニア(データ何でも屋)として広く携わっていければと思っています。

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

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

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

データドリブンを目指したRedash時代 (2020年~)

image.png (12.8 kB)

M&Aクラウドではデータドリブンな意思決定をしていこうという方針の元、Redashが導入されました。 Redashが導入されてからGoogleAnalyticsやプラットフォームのデータベースにあるデータが、KPIの計測、プロダクト開発のファクトや効果検証に使われ始めました。

データ利用の浸透(2022年)

ここからが2022年の話になります。 データ利用を全社レベルで浸透させる試みとして、2022年4月に「データソン」を開催しました。聞きなじみのない言葉かもしれませんが、簡単に言えばハッカソンのデータ分析版です。学習コンテンツを提供し、後半は、チームごとにデータ分析をしてプレゼンしてもらう。という内容で実施しました。

image.png (289.6 kB)

(図:データソンのスライドの一例)

(データソンについての詳細はこちらの記事の「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つのサブプロジェクトに分かれて並行的に走り出しました。

スクリーンショット 2022-12-01 19.37.35.png (263.1 kB)

社内での利用状況のヒアリング

各部署とミーティングを行い、部署ごとに業務プロセスとデータの関係を図で整理しました。

(図:ある部署の業務プロセスとデータの関係)

信頼できるデータの構築

弊社でSFAとして利用しているSalesforceには、記事掲載の営業業務、記事のライティング業務、M&Aアドバイザーのアドバイザリー業務などさまざまな利用者がおり、全体像を把握できていない状況でした。また、各部署で自由にオブジェクトや項目のカスタマイズを行なっていたため、弊社にとって重要な情報である、M&Aや資金調達のニーズの情報が散らばって保存されていたり、企業が重複して登録されてしまっているなど、「信頼できるデータ」になっていませんでした。

なお、このプロジェクトでは「信頼できるデータ」を以下のように定義しました。

  • 一意性:唯一つだけ存在していること
  • 正確性:正しく入力がされていること
  • 網羅性:全てが入っていること

スクリーンショット 2022-12-01 23.03.07.png (244.4 kB) (図:信頼できないデータ(基盤)の例、DPRプロジェクトのキックオフ資料より引用)

Salesforceの見直しについては、3つのフェーズに分けて取り組んでいくこととしました。 スクリーンショット 2022-12-01 23.29.54.png (289.1 kB) (図:3つのフェーズ、DPRプロジェクトのキックオフ資料より引用)

変更のルール整備や不要な項目の削除といった地道な地慣らしから始まり、現在は、フェーズ1の顧客データの整備を終え、フェーズ2のOperationデータの整備に着手したところです。フェーズ2では「誰が、いつ、どのように何を紹介(営業)したか」といった情報を「信頼できるデータ」として蓄積する準備を進めています。

データにアクセスする手段の構築

上記の信頼できるデータの構築(主にSalesforce)と並行して、データにアクセスする手段の構築を進めました。前述の通り、Redashではデータ分析できる状況ではありましたが、今後のデータ活用のため、きちんとしたデータ基盤を構築することとなりました。次の章で詳細を記載します。

データ基盤の構築プロジェクト(2022年9月~)

データ基盤の構築プロジェクトでは、データエンジニアの山﨑さんに業務委託で参画していただき、知見をお借りしながら、CTO荒井、山﨑さん、私の3名で進めました。技術調査・技術選定においては山﨑さんがメインで進めてくださいました。

image.png (279.3 kB)

DWH(BigQuery)の導入

DHWはBigQueryを選定しました。他の候補としてRedShift, RedShift Serverless, Snowflakeがありました。 技術選定では、インフラのメンテコストが少ないこと、利用事例が多いこと、情報収集がしやすいこと、がポイントになりました。(専属データエンジニアが1名もいないスタートアップだったので)

進化的データモデリングのためのDWHのアーキテクチャ設計の採用

データ基盤では、データの加工・整理レベルに応じて3層構造でデータを分けるのがベストプラクティスとされています。通常ではこれらの層を別のサービスで実現しますが、ゆずたそさんの記事を参考に、これらの加工処理を一元管理するため、BigQuery内の3つの層を持つ設計を採用しました。

スクリーンショット 2022-12-01 20.30.52.png (290.5 kB)

(図:ゆずたそさんの記事より引用)

BigqQueryでの個人情報の取り扱い方針を決定

基本的に「BigQueryには個人情報をいれない」という方針で進めました。しかし、顧客情報と連結してリストを作りたいというビジネス側の要望があり、「個人情報を入れないBigQueryプロジェクト」と「個人方法を含むBigQueryプロジェクト」を分離し、プロジェクト単位でアクセス制御を行うことにしました。 BigQueryにはカラムベースやテーブルベースでのアクセス制御ができるので、将来的にはそういった形になる未来もあるかもしれませんが、初期としては細かい制御は行わずガッツリ分けるという判断にしました。

dbtの導入

スクリーンショット 2022-12-01 23.07.28.png (31.4 kB)

https://www.getdbt.com/

進化的データモデリングのための内部3層構造を実現するためのデータ加工ツールとしてdbtを採用しました。 この界隈ではdbt一強という感じだったので採用したという形です。また、dbtはOSSCLIツールなのですが、有料でSaaS版があります。弊社ではdbt導入にかかる時間的コストを下げるためにSaaS版を利用することにしました。なお、1開発者につき50USD/月で結構高いので、そのうちSaaS版からは離れるかもしれません。 ちなみに、3層構造の話をしましたが、dbtのベストプラクティスに従って実は4層構造になっています。 スクリーンショット 2022-12-01 22.36.37.png (111.8 kB)

ETL(Trocco)の導入

https://trocco.io/lp/index.html

様々なデータソースからデータをBigQueryに転送するためのツールとしてTroccoを採用しました。 技術選定のポイントは、インフラ・転送設定のメンテナンスコストが低いこと、国内での事例が多くサポートが手厚いことでした。めっちゃ最高なのでこちらも別途記事にしたいと思ってます。 他の選択肢としては、appflow、Aws workflow for airflow、Cloud Compose・Data Transfer Serviceがありました。

BIツール(Looker Studio)の導入

スクリーンショット 2022-12-01 23.08.23.png (13.3 kB)

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月にリリースした資金調達クラウドの評判が良いみたいなので引き続きこちらも開発をモリモリやっていくと思われます。

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

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