出会っていたのはファインディ - 入社エントリ -

こんにちは、あるいはこんばんは。 @gessy0129 です。

このたび、ファインディに入社しましたので、入社エントリーをさせていただきます。

お時間のあるときにご覧いただければと思います。

ファインディに対する想いと気持ち

改めて、この度、ファインディ株式会社に正式に参加することとなりました。

パチパチパチパチ

昨年からいくつかのnote記事を執筆させていただいたところでございますが、それに絡めつつ、今回の気持ちを綴りたいと思います。

参考記事:

ANDPADを退任しました|げっしー

2024年目標と決意と挑戦と|げっしー

相変わらず、自身の掲げるミッションは、 半径数メートルから幸せの連鎖を生み出す という事だと思っています。

過去の在籍企業で、VPoEや開発本部長として長い間勤務をしてきました。 その中で、ものづくりに集中しているエンジニアたちを支えていく事というのは相当なやりがいでした。 エンジニアたちが幸せに業務出来る環境を整え、それが連鎖していくようにすること。 これはとても楽しかったです。 ※ もちろんVPoE としての業務はこれだけではないです。

この領域を更に深め、挑戦するエンジニアを応援していきたいという思いが強まりました。

そして、その想いが高まった時、多くの選択肢の中からファインディと出会いました。

ファインディのミッション、ビジョン、バリューに共感し、これは非常に大きな出会いであると感じております。

エンジニアの可能性を拡げ、スタートアップのエコシステムに貢献できることを願っています。

やろうとしてること

ファインディは色んな事業を展開してます。

  • エンジニアの転職を支える転職事業
  • フリーランスエンジニアを支えるフリーランス事業
  • 国内外のエンジニアと企業をつなげるグローバル事業
  • 活躍するエンジニアを支えるTeam+事業
  • 技術選定や意思決定をサポートするTools事業

などなどがあります。

これらの事業がすべて、挑戦するエンジニアのプラットフォームを作り上げ、エンジニアの可能性を広げることにつながると考えております。

そして、CEOの山田さんやCTOの佐藤さんが、この領域で挑戦しようとしていることに感銘を受けております。

ここで、素晴らしいメンバーと共に、挑戦するエンジニアが必要とするサービスを積極的に提供していきたいと思っております。

しかし、まだまだファインディ自体が、挑戦するエンジニア、挑戦したいエンジニアに積極的に選ばれる状況にあるとは言えないのではないかと考えております。

これは、ファインディにとっても僕にとってもさらなる伸び代だと思っております。

「ファインディに相談すればなんとかなる」という状況を作り上げることができればと考えております。

最後に

ファインディの対外活動にも積極的に参加していく予定でございます。

その際は、皆様、よろしくお願いいたします!

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

TestProfでワースト5のspec実行時間を8割削減していった話

Findyでエンジニアをしている松村(@shakemurasan)です。

以前、弊社の栁沢が「RailsのCIのテスト実行時間を10分から5分に高速化した話」という記事を投稿しました。

tech.findy.co.jp

本記事ではその少し前のお話、そもそもRSpecの実行時間自体にまだまだあった伸びしろ、特にFactory周りの問題をTestProfというgemを活用して解消していった話となります。

続きを読む

【エンジニアの日常】エンジニア達の自慢の作業環境を大公開 Part1

こんにちは。

Findy で Tech Lead をやらせてもらってる戸田です。

Findy 社の Tech Blog を開設して 1 ヶ月程度が経とうとしています。

このブログを通して弊社の技術情報だけでなく社内のエンジニアのことをもっと知ってほしいと考えた結果、今回から 自慢の作業環境を大公開 と題して、社内のエンジニアの作業環境と、そこに対する考え方、思いなどを発信していく事になりました。

弊社のオフィスは東京にありますが、北は北海道、南は福岡まで遠隔地からのフルリモートで JOIN しているエンジニアが多数在籍しております。

エンジニアの多くが各自の自宅から作業しており、きっと自分にとっての最高の環境を整えているはずです!

それでは、弊社エンジニア達の自慢の作業環境を見ていきましょう!

作業環境を大公開

戸田

というわけで初回は福岡から JOIN している Tech Lead の戸田の作業環境から紹介させてもらいます。

作業スペースの全体像はこんな感じです

戸田の作業スペースの全体像

基本的には DELLの32 インチの 4K モニタを使い、クラムシェルモードで作業をしています。

スピーカー はモニタのアーム部分に接続しており、イヤホンを繋げてボタン一個で出力切り替えが可能なので、普段はスピーカーを使い静かにしたい時はイヤホンを使う。ということが簡単に切替可能です。

Web カメラマイク は別途購入して外付けで利用しています。リモートでの作業がメインとなるため、映像、音声環境は最低限のマナーと思い投資しました。

デスクは bauhutte というメーカーの 昇降デスク を使っています。

この昇降デスクは電動でボタン一つで高さを自由に変更でき、横幅も奥行きも大きいので色々な作業シーンに合わせて利用することが出来るので非常におすすめです。

そして安心と信頼のバグ退散お守り。CI を通すときや重要なリリースの前に祈りを捧げます。

バグ退散お守り

手元周りはこんな感じ

戸田の作業スペースの手元周り

キーボードは HHKB Professional HYBRID Type-S を使っています。

今まで色々なキーボードを試しました。その結果、個人的に作業終了後の手元の疲れを一番小さく感じたのはこのキーボードでした。

特殊なキー配列ですが、慣れたらコードを書いたりコマンドラインを叩いたりしやすいキーボードだと思います。

マウスは Apple の Magic Trackpad を使っています。マウスに対する拘りはなくて、正直 Mac のショートカットアクションが使えれば何でもいいです。早くマルチペアリングに対応して欲しいです。

また、変わり種としては指の筋トレ用具を手元に置いてます。

事の発端は格ゲーをしてた時に思っていたより指が動かなくて、「人類は薬指と小指を思ってるより使ってないな?」と感じ、この二本の指を鍛えるために買いました。

リモート会議中とか、コードを考えてる時とかずっとこれで指を鍛えてます。これで鍛えだしてから薬指と小指がスムーズに動くようになり、キーボードのタイピングが今までよりもスムーズになった気がします。

作業用 BGM は HomePod mini と Apple Music の合わせ技を使っています。

iPad を HomePod mini とペアリングさせて、サブスクには新曲やサントラがどんどん追加されます。

作業スペースの横には趣味のプラモ作成スペースを、後ろには本棚とプラモケースと積みプラ。

プラモ作成スペース 本棚と積みプラ

自分の好きなものに囲まれているというのは、毎日1人で黙々と作業する環境としては想像以上に重要だと思います。

毎日部屋に籠もって1人で作業しているので、五感に入るもので飽きが来ない環境を作ることが大事だと思います。

熊野

青森からフルリモートの熊野(@shoota)です。 フルリモートは 2017 年夏からで 7 年目になります。

まずはメインのデスクから。

自宅に備え付けのデスク
自宅に備え付けのデスク

MacBook Pro 16” をノート用スタンドに載せ、デュアルディスプレイで作業をしています。 MacBook ディスプレイは基本的には Slack 専用で、ほぼすべての作業は 外部ディスプレイ + 仮想デスクトップでこなしています。

外部ディスプレイは DELL の 4K ハブモニターに仕事用の MBP と個人用の Mac mini を繋いでいて、画面を切り替えると接続しているキーボードも自動で切り替わるのが気に入っています。

デスクライトを Amazon Alexa に接続し、デスク左側の Amazon Echo から音声操作できるようにしています。デスクから離れたあとにライトの消し忘れに気づくので、遠くからでも声でライトのオンオフができるのが便利です。 Echo は Spotify などの音楽再生をしたり、他の家電の操作にも使っています。

デスク右側は Anker の無接地タイプの充電器 で iPhone のスタンバイ表示をしています。 その隣には iPad mini をおいていて、ちょっとしたメモをしたり、作業をしながらオンラインイベントを見たりするときに使っています。

全体的に黒で統一するのが好きで、トラックパッド だけが白なのでそろそろ黒の方に買い替えちゃおうかなと思っています。

キーボードは Keychron の分離式キーボード Keychron Q11 QMK Custom Mechanical Keyboard、ポイントデバイスは Magic Trackpad2 です。

分離式キーボード
分離式キーボード
肩こりがひどくなりやすいので分離式キーボードをずっと使っていますが、Q11 はキースイッチごと交換したりキーマップのカスタマイズが簡単で、多機能なのでかなり気に入っているキーボードです。 いまは赤軸スイッチと標準仕様のキーキャップなので、そろそろキーキャップを変えたいな〜と思っているところです。

またフルリモートとしてはビデオ通話の品質を大事にしたい&自宅では子どもたちの声などの環境音が混ざりやすいので、自分も音響はしっかりと用意しています。

マイクは指向性の Yeti Nanoで自分の声だけが入るようにスタンド設置しています。 Yeti 以前はヘッドセットを使っていましたが、いずれも「物理スイッチでミュートできる」ことがこだわりです。

急にくしゃみしたいときにソフトウェアミュートは間に合わないので

逆に出力側は周りの音が聞こえないと不便なので、オープンイヤータイプを愛用していて、いまは shokz の OPENFITを使っています。

指向性マイク
指向性マイク

最後にデスクの後ろに DIY で作ったコミック棚があるので、自慢がてらに紹介したいと思います。

自分が好きなものや集めたものに囲まれて仕事をするのが好きなので、コミック(たぶん 800 冊くらいあります。もう数え切れません。)やゲームグッズ、お気に入りのウイスキーをおいています。

安全率を含めた荷重計算をして設計図をつくり、部材の切り出しから組立て、取り付けまでひとりでやりました。 だいたい 2 万円強くらいですべて揃い、先日の震度 5 以上の地震でも コミックは 1 冊も落ちませんでした。

2023 年下半期の総会、Fine-day で MVP を受賞したときのトロフィーも飾っています。

DIYしたコミック本棚MVPトロフィー
DIY本棚とMVPトロフィー

仕事場でありながら自分らしさを出しつつ、仕事における自分なりの「快適性 / 合理性」を求めたデスクに仕上がっていると思っています。

主計(かずえ)

福岡からリモートでフロントエンドの開発をしている主計(@nesskazu)です。

デスクの全体像はこのような感じです。

デスク全体
デスク全体

4k ディスプレイを 2 枚配置しコーディングしながらデバッグできるようにしています。 ミーティング時にドキュメント等を参照できるのも便利です。

サブモニターはデバッグしやすく、web等の閲覧性が良いため縦配置にしています。

コーディングとデバッグの画面配置
コーディングとデバッグの画面配置

Thunderbolt ケーブルで会社支給 PC と私用 PC で全ての機器の接続が切り替わるようにしています。

ドッキングステーションには CalDigit TS3 Plus Dock を使用しています。

Thunderboltケーブル1本でPC切替
Thunderboltケーブル1本でPC切替
ドッキングステーション
ドッキングステーション

キーボードは静電容量無接点方式やメカニカルなどいろいろ試してきましたが、 自分はキーストロークの深いキーボードは苦手(疲れる&タイプミス多い)なことがわかったのでキーストロークが浅いキーボードを使っています。

MX Keys mini がお気に入りでしたが、途中からチャタリングが発生したり Touch ID が欲しかったので現在は Apple Magic Keyboard を愛用しています。

また、切り替えや充電の手間をなくすため有線で接続しています。

Apple Magic Keyboard
Apple Magic Keyboard

リモートワークということもありミーティングが相手と自分双方にとって快適なものになるように構築しています。

マイクは周囲の音を拾いにくいダイナミックマイク(SHURE MV7)を採用しています。

カメラはなるべく目線の高さに合うようにディスプレイ間のスピーカーの上に設置しています。

マイクとカメラ
マイクとカメラ

ミーティングや BGM の音は OWNDAYS の HUAWEI Eyewear で聞いています。

普段メガネ付けている人であればメガネが変えるだけでスピーカーが着いてくるので便利です。 ミーティングのたびにイヤホンを装着したりする必要がなくなります。最近電池持ちが悪く昼休みに充電する必要があるため Eyewear2 の購入検討中です。

Eyewear を使い初めてから休みの日にしかコンタクトを使わなくなりました。

Eyewear
Eyewear

我が家でもバグ退散のお守りが後ろから見守ってくれています!

バグ退散お守り
バグ退散お守り

このように仕事をするうえで不便な点を排除し、快適に作業等ができるように意識してデスクを構築しています。

まとめ

いかがでしたでしょうか?

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

どのようにして Findy Team+フロントエンドチームは高速な開発をしているか 〜開発フロー編〜

こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ のフロントエンド リードをしている @shoota です。

Findy Team+はエンジニア組織の開発生産性を可視化し、開発チームやエンジニアリングメンバーのパフォーマンスを最大化するための支援をしています。 そして(当然のことながら)Findy Team+ を作っている自分たちも、チームや個人でドッグフーディングをして、チームや自分自身の働き方やエンジニアリング組織の健康チェックをしています。

今回はそんな Findy Team+の開発チームのうち、フロントエンドチームがどのような開発環境・開発インフラで働いているかの概要をご紹介したいと思います。

フロントエンド技術スタックとCI高速化

技術スタック

まずはじめにフロントエンドの技術スタックを簡単に紹介します。一般的なSPA構築の技術スタックを採用しており、それほど特別なものではないことをご理解いただけると思います。

ここまではいわゆる一般的なSPAの構成ですが、Findy のフロントエンドはモノレポ管理ツールである Nx を利用することで高速化を図っています。 Nxの機能詳細についての説明はここでは省略しますが、トップページに「Smart Monorepos・Fast CI」とある通り、CIの高速化が簡単に管理できるところが最大の特徴と恩恵だと思っています。

NxでCIを高速化する

Nxは内部に複数のプロジェクトを持つことができ、且つ、それらの依存関係を自動で解析します。 この「プロジェクトの依存関係」をもとに、プルリクエストでの「変更されたプロジェクト」と、その「変更部分が依存しているプロジェクト」のみのテストを実行する手段を提供しています。

これによって開発者が開発しているものに関係のない部分は省略されるためCIが高速化します。 それ以外の変更についてもNx Cloudにキャッシュが残っていればその結果を採用してテスト等をパスさせ、CIが高速に完了します。

CIの実行結果を載せてみました。

GitHub Actions capture
GitHub Actionsの様子
共通のhooksを修正してる3段目のプルリクエストではほぼ全てのテストを実行(そして新たにキャッシュ)しているため、20分以上のテスト時間がかかっています。 一方でその他をみてみると、新しい画面などの通常開発の場合は変更内容がプロジェクト内で完結しているので、CIの実行時間は数分で終わっています。

また単にCIが高速化される以外にも、Nxは開発生産性の向上に寄与してくれます。 それは「プルリクエストはできるだけ小さく作ろう」という開発文化を「CI時間」という数値で可視化してくれることです。

前述の通りプルリクエストの変更の依存関係が小さいほどCIは早く終わりますので、逆にプルリクエストが広範な範囲で大きくなってしまうほどCI時間が長くなります。 プルリクエストの粒度が大きいと、1) CIが遅くなり、2) レビュー依頼するまでの時間が空いて忘れがちになり、3) レビュー量も多くて時間がかかるという悪循環に陥ります。

そこでプルリクエストを作る側はどうにかこれを避けようとする力学が働き、CIが高速であれば作業内容に集中し、レビュー指摘の反応や修正も楽になっていくのです。

プルリクエスト / レビューに反応する

前述の通りNxの依存管理を基盤としてCIを高速化していますが、Findy ではレビュー依頼やレビューコメントなどGitHubでのやり取りをSlackに移植してコミュニケーションのトリガーを通知しています。 実際のSlackの画面はお見せできませんが、以下のようなタイミングでSlackに状況が実況され、レビュー依頼が来た場合は通知もされます。

  • プルリクエストを作った時
  • プルリクエストにコメントされた時
  • プルリクエストがApproveされた時
  • プルリクエストをマージ(クローズ)した時

またGitHub標準のSlackアラート機能も併用していて、レビュワーにアサインされたままのプルリクエストがあれば1時間ごとに通知されます。 これによって「レビュー依頼に気づかなかった」状況を減らし、レビューが放置ぎみのときには「なにか事情があるのかな?作業に入れない状況かな?」と察したり、レビュワーを変更するなどの対処もできます。

このSlack Appは弊社テックリードのgithub-to-slack-notification をベースに構築されています。

Findy謹製のSlack通知App

プルリクエストを分類する

Findy Team+ は、開発メンバー、開発チーム、リポジトリ、プルリクエストのラベル、日時やカレンダー情報などの複数の条件をディメンションとして、個人やチームのリードタイムやアクション数などのパフォーマンスを計測できます。 プルリクエストは機能開発やリファクタリング、バグ修正、ドキュメンテーションなど内容が様々になってしまうため、パフォーマンスがどのような部分で発揮されているかを分類するのは非常に困難ですが、Team+ではプルリクエストのラベルを利用して一定の分類ができるようにしています。

しかし一方で、「プルリクエストにラベルをつけておく」という作業を定常的に、すべてのエンジニアが、漏れなく、間違いなく、実施していくのはプルリクエストの分類以上に困難なことでしょう。 Slackを見返すと入社3日目の自分がいきなり本質をついています。

ラベル運用について気づくshoota
そう思っていたときが私にもありました。

Findy Team+のフロントエンドのプルリクエストは自動でラベルをつけています。

そもそもgit上の全てのコミットは Conventional Commits に則るよう、commit lint で制約を設けています。 そしてプルリクエストのタイトルもConventional Commitsの形式にするようにルール化しているので、プルリクエストのタイトルにはこれらの接頭句が必ずあり、これを検知してGitHub Actionsで分類、対応するものにラベルをつけるようにしてます。

プルリクエストの種類は、タイトルから自動で分類させておく

デプロイする

小さなプルリクエストが無事にマージされたら、デプロイしていきます。Team+ フロントエンドは、GitHub Actionsの schedule cronを利用して一日に2回定期デプロイをしています。 gitはgit-flowをベースにした運用をしつつ、プルリクエストテンプレートにリリース時に必要な確認項目を入力する欄を設け、リリース時にはこの確認項目を自動生成するようになっています。 まずはgitの運用フローを簡単に図式化してみました。

ブランチ運用
※ の部分はリリース用プルリクエストのcommit hashをmasterからdevelopへ移動するための操作で、基本的には差分は発生しないものです

developブランチを定時間でリリース用ブランチに派生して、ステージングにデプロイします。 このときの主なチェック項目として、

  • バックエンドで先行するプルリクエストがないか(ある場合はそのプルリクエストのリンク)
  • APIレスポンスの変化やエラーハンドリング、後方互換性など、開発者のみが確認できる確認項目がないか
  • 実装機能と想定仕様の合致など、機能リリースのためのQAが必要でないか

をプルリクエストテンプレートで記載するようにしており、リリースプルリクエストにはこれらすべてを列挙して簡易的なリリース判定を行っています。

まとめ

今回は Findy Team+ の開発フローに焦点をあてていくつかの要素をご紹介しました。 これ以外にもさまざまなツールやサービスを利用して品質とスピードを両立させるための開発基盤を持っていますが、ひとことではお伝えしにくいものもあるので、それぞれより詳細な記事でご紹介して行ければと思います。

スピードを意識したフロントエンド領域の開発環境として高いレベルで整備し、可視化して改善するように心がけています。 自分の開発能力、スピードをフルに発揮したいという方は、ぜひ下の採用情報もごらんください。

herp.careers

会社として初めてNLP2024に参加してみた話

こんにちは、ファインディ株式会社で機械学習エンジニアをしていますsasanoshouta(@Edyyyyon)です。この記事は、言語処理学会第30回年次大会(NLP2024)に社で初めてプラチナスポンサーとして参加してきましたので、その参加報告になります。

NLP2024とは?

言語処理学会第30回年次大会(NLP2024)は,2024年3月11~15日の期間,5日間の日程で開催いたします.チュートリアルは3月11日午後1時に開始,本会議は3月11日午後4時半から14日午後7時までの4日間です.現在,現地とオンラインのハイブリッド開催の形態で準備を進めています.現地とオンラインの両方から参加し,発表・聴講・議論をすることができます. *1

大会概要は引用文の通りで、今年は神戸ポートアイランドの神戸国際会議場で開催されました。

参加の背景

今回初参加となりますが、スポンサーするに至った背景は以下の通りです。

  • 機械学習、データサイエンスを初めとするデータ系職種・界隈への認知拡大や打ち手が足りておらず、その足がかりとしてのスポンサード

  • ファインディでもデータ系職種を絶賛募集しているが、そもそも機械学習やデータサイエンスにも取り組んでいる会社であるとの認知が広げきれていないので、「何を?なぜ?どのように取り組んでいるのか?」を知って頂きたい

「エンジニア開発を支援する企業」であることをアピールできている一方で、実は内部でデータ活用・機械学習を使っている事の認知を広げられていない背景があり、まずは知って頂きたいと言う事で、今回スポンサーとして参加してきました。

会場の雰囲気

前述の通り、弊社ではNLP2024を含む学会への参加経験が全くなかったので、過去のNLP202X年度の雰囲気や、他社さんの過去参加記事を参考に準備を進めていました。また、私自身や今回同行したメンバーの中にも学会参加経験者が数名いた事もあり、普段弊社が参加するカンファレンスイベントなどよりも少しかっちりとした準備を進めていました。いざ当日会場に着いてみると想像していたよりもラフに参加できそうな雰囲気でした。(筆者が最後に参加していた頃の学会がX年前で、真面目な雰囲気の印象があった為か、時が流れて参加しやすい雰囲気になっているのは驚きました。)

ポスターセッションの雰囲気

弊社スポンサーブース

こちらの画像の、掲示スペースが少しもの寂しげなブースがファインディのスポンサーブースになります。ポスターの用意が間に合わなかった為、苦肉の策として弊社のデータ系職種採用資料を印刷して掲示していました。

弊社スポンサーブースの雰囲気

どうしてこんなに寂しくなってしまったのかと言うと、もともと筆者がポスター準備担当だったんですが、直前の体調不良により作業を進める事ができず、敢えなく準備期間が過ぎ去ってしまった為でした。しかたない側面はありますが、沢山の方とお話できたので伸びしろと捉えて次回参加時こそは掲示物を作って参加したいと思います。

スポンサーブースでお話したこと

今回は、弊社データソリューションチームの採用資料から、機械学習による取り組み事例をいくつか持参し、モニターに投影しながらこられた方に弊社のデータ活用先とその実現方法について紹介をさせていただきました。また、言語処理学会と言う事もあり、実際に社内でも検討しているNLPも取り入れた今後の方向性も反映したものになっています。採用資料から2つ抜粋して簡単に紹介します。

1つ目は「LLMを用いたキャリアサマリの作成」です。👇

LLMを用いたキャリアサマリの作成

1年ほど前の取り組みになりますが、OpenAI API公開後に活用施策第1弾と言う事で、1週間でのリリースを目標に作成した機能になります。 職務経歴書などの情報を入力すると、それを要約して二つ名をつけてくれると言った機能でした。 私の場合は、「AIの魔術師」「AIのキラーコンサルタント」と言う名前をつけてくれました。

2つ目は「行動ログを活用した転職意欲や志向の検知」です。👇

行動ログを活用した転職意欲や志向の検知

こちらの機械学習モデルは、転職意欲が高いにも関わらず、プロフィール上転職意欲が低いままになってしまっている方向けの機能としても使うことができますが、どちらかといえば転職活動の意欲がないのにスカウトが送られてくる事での煩わしさを軽減する防御の役割を持った機能として運用しているものになります。 プロフィールのステータスは転職意欲が高いままになっているが、実際には転職活動が完了したままステータスを変更するのを忘れてしまっているというケースがあったりします。 そうした方に、スカウトを追撃してしまうと転職サービスとしての不信感に繋がりかねないので、事前に予防できるものは出来る限り予防するようにしています。

ブースに立ってみて

当初想定していたよりも多くの方がブースに来てくださり、筆者もブースに立って意見交換をさせて頂きました。ブースに聞きに来て頂いた皆様ありがとうございました。

ファインディ自体が「エンジニアに特化した中途転職サービスを中心に事業を展開している」事と、学会に参加されている方々の属性が、

  • 機械学習・データサイエンスを生業とされている社会人参加の方
  • 大学・大学院大学から学生参加の方

の2属性の方々がメインであった事と相まって、「ファインディ株式会社」と「何をしている会社か?」の知名度にはかなりの伸び代を感じました。一方で、完全アウェーだった訳でもなく、「スキル偏差値の会社」として認知いただいている方が多かったです。データ界隈での機能とサービス・会社名の繋ぎ込みにまだまだ課題を残しつつも、機械学習・データサイエンスの界隈にも一定取り組みが届けられている事を感じられました。

個人的な聴講セッションの感想

スポンサーとしてブースに立つ傍ら、いち聴講者としてセッションをいくつか聞いたり他社スポンサーさんの企業ブースにお邪魔してお話を伺わせていただいたりしたので、メモベースにはなりますが個人的な感想を書き連ねておきます👇

  • オーラル・ポスターセッションそれぞれに共通して言えたのは、大前提LLMに関する研究発表である事がほとんどでした。

  • だからと言って、OpenAI API をそのまま使って研究をしていたり、サービス実装してコア機能としている企業さんや研究もほとんどないような印象でした。

    • リクルートさん、サイバーエージェントさんなどのテキストデータを潤沢に持ち合わせており計算資源も豊富な企業でも、一部プロセスに取り入れられているとお聞きしました。
  • 社内向けに、全社の業務効率化を目的としてRAGや文章埋め込み(embedding)を使い、LLMの弱点であるhallucinationを低減した仕組みを取り入れたお問い合わせbotを実装・運用している。

    • 様々お話を伺った所、現在のLLM界隈のトレンドでは、お問い合わせbotのような活用がトレンドとなっていそうで(個人の見解)、このような流れはしばらく続きそうな雰囲気を感じた。
  • 一方で、勢いが若干失速した感はありましたが、自社専用のLLMをスクラッチで開発するという企業さんのお話もいくつか伺えました。

  • 「ChatGPTとかClaude3とか低価格で高性能なAIが出てるし、今後もその流れは変わらないはずなのになぜ?」 と思い、お話を聞きいてみました。

    • 自社でLLMを作っておく事で、GAFAMOが提供するLLMの規約が変わった時のリスクヘッジになるとの方針で、研究をやめていないとの事。

    • どの企業さんにも共通していたのは、1つ自社のLLMを作れておくと用途に合わせて柔軟にカスタマイズができる点も、内製化のメリットの1つとの事でした。

為になったセッション

全てのセッションが興味深く考えさせられたり、明日使えるものたちが多数でしたが、個人的に1番勉強になったセッションを共有します。全体の発表スケジュールはこちらから。

  • 文章のチャンクに基づく知識グラフを活用したRAG(産総研さん)

RAGを使ってLLMの回答精度を高める為の取り組みはいくつもありますが、LLMに与えられるクエリにcontextを付与する為に知識グラフをDBとして構築しておき、知識グラフからの情報検索プロセスをRAGに組み込む、と言うものでした。弊社でもRAGを用いた質問回答botを作って運用したりしており、オーソドックスに類似度計算した上位N件から回答を作成すると言うシンプルな構成を取ったりしています。こちらの研究にある通り「クエリの文脈はすべて類似度で測れるとは限らない」と言う事を痛感しているので、こちらの研究を参考にしてみたいと思いました。

参加してみての感想

初めて言語処理学会にスポンサーとして参加してみて、やはりデータ系職種・界隈での認知拡大の伸び代がある事を強く実感しました。 その理由はいくつかあると思いますが、これまで今回のようにデータ系職種の方が集まる学会やカンファレンスに積極的に参加していけてなかった所が大きいと感じました。 もちろんこれだけではなく、社内でもデータを活用した取り組みは沢山動いたりこれから始まったりしている最中なので、そうした取り組みをもっと積極的に発信する事で、より多くの方にファインディを知って頂きたいなと思います。

いち参加者としても、短い期間でまとまった数のNLPに関する研究発表を自分の五感で感じる機会は中々なかったですし、多種多様な取り組みや企業さんとお話できてとても良い刺激になりました。すぐに試せそうなノウハウを沢山得ることもできましたし、忘れないうちに現在の取り組みの参考にさせていただこうと思いました。

今後は、言語処理学会をはじめ学会へのスポンサー、ポスター発表などにも力を入れていきますので、どこかで見かけた際は何卒よろしくお願いいたします。

さいごに

ファインディでは、機械学習エンジニア・データサイエンティスト・データアナリストを絶賛採用中です。以下のページから応募頂けますので、興味のある方は是非カジュアル面談などでお話しましょう。

findy-code.io

findy-code.io

*1:NLP2024公式ページより抜粋

Findyデータ基盤のアーキテクチャと技術スタック

1. はじめに

Findyでデータエンジニアとして働いている ひらき(hiracky16)です。 この記事ではFindyで取り組んでいるデータ基盤について紹介します。

Findyでは2023年からデータエンジニアを採用し本格的にデータ基盤構築に着手しています。 これまではBigQuery(Google Cloud)を中心としたデータ蓄積・利活用をしていました。 今後もっとデータ分析、機械学習などのデータ利用を加速するためにデータマネジメントが不可欠だと考えており、データエンジニアを採用しています。 まだ1人目のデータエンジニアがジョインしてから半年間くらいの取り組みですが、現時点のアーキテクチャや技術スタック、伸びしろや展望などを記します。

2. これまでのデータ基盤の伸びしろ

僕が入社する前のアーキテクチャがこんな感じです。

プロダクトのRDSからEmbulkを使って1日1回必要なデータをBigQueryへ転送していました。 プロダクトのデータだけでなくGAイベントデータを蓄積していました。 昨年からTransformのツールにdbtを導入しており定期的に実行されるクエリを徐々にdbtへ移行している状態でした。

データ利用で言うと定期的に見るべき数値はLooker Studioで可視化したり、GASからBigQueryへクエリ発行してスプレッドシートで表示しています。 また別Google Cloudプロジェクトにある機械学習用のデータセットにコピーもされていました。

上記を踏まえて現場の課題感やアーキテクチャ図を見ての客観的な伸びしろをまとめてみました。

  • Embulkなどデータロード系のジョブが失敗した場合のリカバリに負荷がかかっている
  • dbtを使ったクエリが増えない
  • スプレッドシートとGASで実行しているクエリの正確性が担保できていない
  • データソースの変更に対する影響範囲が見積もれない(データリネージが追えない)
  • データ基盤と機械学習用の検証環境がないため新規開発やアップデートにハードルがある
  • 機械学習のプロジェクトとデータ基盤のプロジェクトが別になっておりデータ鮮度が異なる

3. 現状のデータ基盤アーキテクチャ

3.1. 本番環境のIaC化と開発環境の準備

まず取り掛かったのが本番環境のIaC化でした。 上記に示したアーキテクチャ図を書く前に本番環境の主要なリソースをTerraformにインポートしてコード管理できるようにしました。 その過程で不要なリソースを整理でき、本当に必要なものだけを見極めることができます。 おまけにコスト削減にも繋がります。 一通りTerraformへの書き起こしが完了したら、あとは開発環境のGoogle Cloudプロジェクトを作りTerraformを適用するだけです。

データに関しては1日1回、Data Transferでデータセットごとコピーしています。

開発環境に本番環境相当のデータとGoogle Cloudリソースが揃ったので、後に紹介するDataformを使った定期実行クエリの開発を増やしています。 これによって本番環境にて検証用テーブルができたり、間違えてテーブルを消してしまうなどの問題を減らせたと思います。

3.2. データロード系のツール刷新

データを取り込むツールとしてtroccoDatastreamを採用しました。

troccoはもともと別チームで管理しているものに相乗りさせてもらう形で使っています。 MAツールや他のクラウドサービスといった様々なデータソースに対応可能なため重宝しています。 またロードだけでなくReverse ETLにも役立っており、作ったデータマートを別サービスに読み込んで活用しています。

DatastreamはCDCのサービスでサーバレスなので運用に手間がかからない点でEmbulkの代わりに採用しました。 一方でリアルタイムにソースが変わるため集計のたびに数値が変化するため、問題発生時の原因調査が困難になりました。 現状運用上でカバーできていますが、再現性と説明の容易さを向上させるべく集計に使ったデータを別で持つべきか悩んでいるところです。

またスプレッドシート上で管理しているマスタデータにも対応すべくBigQueryの外部テーブルとして扱っています。

3.3dbtからDataformへの変更

データ変換のためのツールをdbtからDataformへ変更しました。

dbtはDataformに比べて開発が活発で、ライブラリが充実しているため採用しました。 この前提でdbtにクエリや知識を集約させるべくBigQueryのユーザーを巻き込み利用を促していましたが、なかなかモデル(テーブル)の数が増えませんでした。

理由として2つのハードルがありました。 1つ目がBigQueryでクエリを記述後エディタを開き、dbt 用に書き足す一手間かかってしまうことが大きなハードルになっていること。 2つ目はdbt側の制約(主にモデル名の一意制約)やデータ基盤側の設計から定めたルールが気軽にコミットしづらい状況を作ってしまいました。

これらのハードルをクリアすべくDataformの利用を検討しました。 Dataformはブラウザで完結しBigQueryのメニューにあるため多少ツール間の移動コスト軽減されます。 かつDataformにはモデル名の一意制約がなくBigQueryと同様にデータセット間で被らなければ同名のモデルがプロジェクトに複数存在しても問題ありません。 導入した結果、モデル数はdbtプロジェクトに比べて3倍ほどできており、実際に使いやすいという声もあるので一定成功だったのかなと思っています。

Dataformからdbtへ乗り換えた話は見聞きしたことがありますが、dbtからDataformへのケースは見たことないので一定期間経ったらまた振り返りの記事を書こうと思います。

3.4. データを4層で管理

参考にしたのはdbtのベスプラの1つである「How we structure our dbt projects」です。 dbtをツールとしては不採用にしましたが、考え方は利用させてもらっています。 🙏

docs.getdbt.com

当初3層(lake/warehouse/mart)で作ろうとしていましたが、データソースに対して直接クエリしようとするとBigQuery上で不都合なことがありました。 例えばDatastreamで転送してきた日時のデータがすべてDATETIME型になってしまい、TimeZone を考慮した計算ができませんでした。 毎回TIMESTAMP型に変換する処理をwarehouse層に書かせるのも厳しいのでstaging層を設けて型変換などの簡単な変換をすることにしました。

4. 今後やりたいこと

4.1. 全体を統括するオーケストレーションツールの導入

現在、データ抽出と読み込みはtroccoやDatastreamで行われますが、Dataformによる変換はその読み込みが終わった頃を見計らって実行しています。 もしtroccoによるデータロードが失敗した際にDataformによる変換が実行されてしまうので、データを閲覧する方が古いデータを見てしまう可能性があります。

また現状troccoやDataformそれぞれでエラー検知の仕組みを備えており、日常業務の監視に一定コストがかかっています。 データの抽出から提供までの流れを効率的に管理・監視し、運用コストをかけずに行うためにもオーケストレーションツールの導入が今後必要です。

4.2. データ基盤の利用者拡大に向けたルールと権限

せっかく作ったのでもっと新しいデータ基盤を使ってもらいたいのですが、ルールがないとせっかくの設計が腐敗してしまいます。 例えばGASから直接クエリを発行することはSQLの内容がGASに閉じてしまいメンテができなくなってしまうので新環境では禁止していきたいと考えています。 4層のアーキテクチャも開発上意識しなくてはならないルールなので、なぜ必要なのか理由とともに作るつもりです。

また、適切な権限や公開範囲の設定も必要です。 どのチームがどの範囲のデータセットを扱うことができるか整理しないと予期せぬ変更をしてしまうなどの事故につながってしまいます。 皆が安心して使えるデータ基盤にするためにも適切な権限設定やルール作りが急務だと考えています。

4.3. 複数部門またいだデータ基盤の設計、構築

最後に壮大な話をして終わりたいですが、複数部門でのデータ基盤運用を今後やってみたいと考えています。 実は今まで説明してきたのは弊社の一事業部内での話で弊チームでは他事業部とはあまりまだ関われていない状況です。

エンジニア領域の事業をやっており事業部間のドメインは近いのでデータ文脈でコラボレートできることはあると考えています。 また事業部別で使われるマスタも数々存在しており共通化すると横断してデータ利用できる土壌が整うと考えています。

そのためには複数事業部のデータ基盤を管理するための設計、ルールと開発・運用を担当するデータエンジニアが圧倒的に足りていません。

5. 終わりに

以上がここ半年間で整いつつあるファインディのデータ基盤アーキテクチャと技術スタックの紹介でした。 やりたいことにも挙げましたが、データの攻守においてエンジニアが足りていない状況です。 エンジニアのためのデータプラットフォームを作るためにも、少しでも興味が湧いた方はカジュアル面談お待ちしております。🙏

herp.careers

herp.careers

Findy Team+のフロントエンドの設計刷新 ~決断から効果検証まで~

こんにちは。

FindyでTech Leadをやらせてもらってる戸田です。

昨年(2023年)、Findy Team+ にて、4名で3ヶ月ほどかけて大規模なフロントエンドの設計刷新を行いました。

Findy Team+はエンジニア組織のパフォーマンス向上を支援するSaaSサービスで、2020年から開発がスタートしました。

3年以上の間、機能開発を行ってサービスを伸ばしてきましたが、同時に様々な課題も生じていました。

今回はそこに至るまでの経緯と、実際に行ったことを紹介します。

なぜフロントエンドの設計刷新を決断したのか

当時、自分は他のプロダクトの開発チームでコードを書いていたのですが、ある日Findy Team+の開発チームへ異動することになりました。

異動後に2週間ほどFindy Team+のフロントエンドの開発をしたのですが、あることに気づきます。

コード設計が思ったより複雑かもしれない

異動前後で理解のしやすさやプルリクを上げるまでの時間に差があるように感じたので、Findy Team+での自分の生産性の数値を比較してみることにしました。

すると、異動前と比べて自分のアウトプットの量が半分以下まで下がっていることが明らかになりました。

異動前後の生産性の比較

感覚値と実際の生産性の数値が一致したため、どこかしらに何か問題があるのでは?という仮説を立てました。

異動前後での変化を洗い出してみた結果、コードの設計に問題がある高いことを突き止めました。

しかし、コードの設計を刷新しようにも、そこには大きなコストと時間が掛かります。

その大きなコストを、異動前後の生産性低下の感覚値だけで周りの人間を納得させることは不可能です。

そこで、今のコードの設計の問題点を洗い出して、何がどう問題で生産性が低いのか具体的な洗い出しに着手しました。

問題点の洗い出し

過度な共通化

まず全体的に過度な共通化が行われていました。

例を上げると、グラフやテーブルに数値を表示する際に表示するcomponent内で、データ取得も同時に行っていました。

こうなってしまった場合、グラフやテーブルの見た目は同じだけど表示するデータが異なる場合に対応できなくなります。

このような複数責任を持ったコンポーネントが幾つも存在していたため、コードリーディングやデータの流れを追うことが非常に困難になっていました。

データの取得と描画は責務が異なる処理なので分けて実装するべきでした。

処理に一貫性がない

APIの呼び出しに関するルールが存在しておらず、複数個所から色々なタイミングで呼び出されており、データの流れを追うことが非常に困難になっていました。

前述した過度な共通化がこの問題を引き起こしており、1つのcomponent内で全てのことを処理しようとしていました。

データ取得と描画が密結合で実装されているので、この部分は共通化してるのでcomponent内でデータ取得して描画してるけど、この部分は共通化してないからデータをprops経由で貰ってきてる。といったような状況が多発していました。

これにより、どこからデータを取ってきているのか探しに行く作業が多発し、コードリーディングに必要以上の時間を取られているような状況でした。

テストコードを書きにくい

過度な共通化によりデータの取得と描画が同時に行われていたため、責務の分担がほとんどできていない状況でした。

そのため、テストコードを書きにくい状況にも陥っていました。

描画に専任するべきcomponentの中でデータ取得もしているせいで、データ取得部分のモックを用意しなければテストができず、テストコードが必要以上に肥大化していました。

設計刷新に対する認識合わせと合意形成

メンバーとの認識合わせ

Tech LeadやCTOが「やってほしい」と言って作業してもらうことは比較的簡単ですが、自分たちで「やる」と決意してやることは価値が大きく違います。

ある程度の問題点を洗い出すことが出来たので、これを元にメンバーと意見交換をすることにしました。

この時メンバー全員を一同に集めて話すのではなく、メンバー1人ずつ時間を取って話をすることを決めました。

メンバー全員を一同に介してこの手の話をすると、声が大きいメンバーの意見が反映されがちだと考えたからです。

真に自分たちで「やる」と決意して貰いたかったので、1人ずつ時間を取って本音を聞くことにしました。

フロントエンドのメンバー全員と1on1で話を聞いてみた結果、現行の設計に対する意見と感覚値がほぼ一致していました。

  • ずっとリファクタを入れたかったけど、この規模まで来るとリファクタ自体に時間が掛かりすぎてしまう
  • 機能追加に時間を取れなくなってしまうので、リファクタをやりたくても言い出せなかった
  • 今の設計の状態のまま、更に開発スピードを上げていくのは難しい

これから先の開発スピードを更に加速するためにも、フロントエンドの設計刷新は必要不可欠であるとチーム全体で結論が出ました。

経営陣との合意形成

そこで経営陣やPdMのメンバーと、設計刷新に対する合意形成を作りに行きました。

全体的に作り直す必要があるため、新規開発を可能な限りストップして、一定期間を作り直しに集中する必要があります。

これに関しては大きな反対意見が出ることもなく、比較的スムーズに了承を得ることが可能でした。

議論したのは、どのくらいの期間を新規開発ストップするかどうかくらいです。

なぜ大きな反対意見が出なかったかと言うと、以前にも同様のシステムの設計刷新 を行ったことがあり、それに対する成功体験が大きかったためです。

確かに大きなコストは掛かりますが、比較的早い段階でそのコストを回収できたという成功体験があり、リファクタや設計刷新に対する抵抗感が比較的低い点は弊社の良い点です。

過去の成功体験と現在の状況を比較し、掛かるコストと回収期間を提示できたため、比較的スムーズに了承を得ることが可能になりました。

着手前の準備

新設計の方針を固める

新設計の基本方針として、多少冗長となっても構わないので共通化を最小限に留めることとしました。

最初から共通化して実装するのではなく、実装後に共通化するべきかどうかを議論し、その議論が通ったものだけ後から共通化対応することにしました。

また、コードの責務を明確にし、必要以上のことを1つのファイル内で実行しないことを徹底しました。

更にcomponentとロジックを分離することを基本とし、依存関係を単方向にさせました。

コンポーネントの依存関係図

データ取得と描画の処理を明確に分け、描画に必要なデータは全てpropsリレーで受け取ることを義務付けました。

propsリレーが長くなるとツラくなる可能性もありますが、責務が混在してテストコードを書きづらくなることと比べたらマシという判断です。

小さな画面を新設計で1つだけ作り直してみる

新設計の方針がある程度見えてきたタイミングで、簡単な画面を1つだけ作り直して、メンバーに方針を展開することにしました。

方針を文字や口頭で説明するよりも、実際のコードを見てコメントベースで説明する方が理解しやすいからです。

そこから新設計に対する意見をメンバーから貰い、1ヶ月程度で方針が固まりました。

実際の作り直しの流れを決める

実際に本番環境が動いており、多数のクライアントが利用している状況だったので、次の3つを大原則に掲げました。

  • 現状の機能を維持する
  • 現状のスタイルを維持する
  • 安全に移行する

ページ単位で作り直しを進め、APIは既に利用しているものを使い回すことを決定しました。

作り直しの流れ

基本的な作り直しの流れは次の通りになります。

  • 同じ画面を別URLで実装
    • 既存画面のコードに手を加えるのは基本NG
    • 一時的に同じ画面が異なるURLで公開される
    • 既存画面と異なるコードで実装しているので、Pullrequestをガンガンmergeできる
  • 新設計での実装が完了後、本番環境で動作確認を行う
    • 動作確認がOKであれば旧設計のURLのルーティングを新設計の画面に向ける
      • 新画面で何かしら不具合が発生した場合は、ルーティングを戻すことですぐに切り戻しが可能
  • 一定期間様子を見て、問題なさそうなら旧実装のコードを全削除

この流れにより、旧実装の画面のことを気にすることなく新設計のPullrequestをmergeすることが可能になり、問題が発生しても切り戻しが容易になります。

振り返り

結果として新設計のコードへの移行完了後のチーム全体の生産性が、前年比で2.5倍程度まで上がりました。

設計刷新後の生産性の比較

作り直しやリファクタ、設計刷新を提案する前に、まず感覚値と実際の数値を見比べ、メンバーと認識合わせをすることが重要です。

また、経営陣を始めとした決裁権がある人間を納得させるために数字は必要不可欠です。

成功体験があれば次の提案は思った以上にスムーズに進みますが、一番最初の成功体験を作ることは非常に難しいものです。

小さくてもいいので数字を出し、小さな成功体験を多く詰むことが重要です。

まとめ

いかがでしたでしょうか?

リファクタや作り直し、設計刷新を検討している方の参考になれば幸いです。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから↓ herp.careers