こんにちは。開発発注プラットフォーム「ISSUE」を開発・運用している寒河江と申します。
今回は「ISSUE」が提供している企業向けのエンジニアスカウト機能にElasticsearchを導入しましたので、その経緯と感想をお伝えします。

今、Elasticsearchの導入に悩んでる人や導入してないけど自社サービスのデータベースにたくさんデータがあるという方にとって役立つ情報になるのではないかと思います。

なぜやったか

導入経緯

スカウト機能は企業登録のために重要だった

「ISSUE」では、企業にサービスを提案するときにスカウト機能を伝えます。まずはエンジニアを探してみてくださいと伝え新規会員登録をしていただくためです。エンタープライズ向けには登録前にデータベースをまずチェックしてもらうことがあります。ダイレクトリクルーティング系のサービスに登録したはいいものの実際データベースにマッチする人材は存在しなくて、申請のために法務を介する手間だけが発生してまうという事情を考慮しています。

より豊富な検索条件ニーズがあり投資対効果も期待できた

企業に使ってもらった時に「希望稼働時間」や「希望契約形態」、「経験年数」で絞り込みたいというニーズがあることがわかりました。
今のFirestoreの検索でもできますが、今よりもっと検索性が高くなればマッチング精度が高まるので結果的にサービスの新規登録企業数、売上の増加につながるので投資する理由としては十分でした。

後述している導入コストでもわかりますが、
検索性を高めればCACを下げ、LTVで十分回収できると判断しました。

スカウトした時の返答率が20%を超えていた

エンジニアの返答率は20%を超えていて、
スカウトすれば必ずOKの返事が返ってきてマッチングするので、
まずはスカウト機能を使ってもらうことがISSUEにとって重要でした。

技術投資がこの業界では競合優位性につながると思ったから

弊社が取引をしているエンタープライズがなぜうちを選んでくれたのかと理由を考えると、
経営陣がモダンなプロダクトを開発することができるかつエンジニアのデータベースを持っていることが決め手になっているとわかります。そこで、会社の方針としては技術投資を積極的に行っていくようにしています。

また、人材業界・プラットフォームサービスでは営業すればするほど、
売上が上がるのでプロダクト開発や投資が後回しにされがちですが、
営業を抑えつつプロダクトの開発・自動化をコツコツ進めることが最終的な事業の伸びにつながると思っています。

(以前は、事業は最終的にプロダクトの優位性はなくなりマンパワー勝負になると思っていましたが、
最近はそうでもないんじゃないかと考えが変わってきました)

導入してよかったこと

検索条件を増やせた

なるべくFirestoreではドキュメント内のフィールドをネストさせないようにしていますが、
ユーザーのスキルに関しては事情がありネストさせていました。

ネストすると、Firestoreの検索とは相性が悪く検索性が落ちるので、
Elasticsearchの検索はとても役立ちます。

ちなみに、Firebaseの拡張機能にElasticAppSearchがあり、
データの同期を自動で行なってくれて便利なのですが、ネストされたフィールドの検索に対応していなかったので採用しませんでした。(ネスト検索できる方法あれば教えていただきたいです)

ページネーションがかんたん・正確になった

Firestoreでページネーションを実現するためには、今のページの先頭や最後のデータの作成日時をもとに次のデータを引っ張ってきます。ソート機能を組み合わせたりすると簡単に複雑になりページが違うのにさっき表示されたデータがまた表示されてしまう問題が起こっていました。ページの管理は実装しない方がいいと思うので、Elasticsearchに任せられるのは嬉しいです。

AND検索できるようになった

Firebaseのクエリは複数条件をいくつも組み合わせるのが難しいです。
Elasticsearchならかんたんに条件を組み合わせられます。
クライアントの条件追加要望にすぐに対応できるようになるのも便利です。

導入コスト概算

実装期間: 3日
人件費(4,000円~5,000円/時間として): 96,000 ~ 120,000円
データ量: 1,700

何が大変だったか

Elasticsearchの学習コスト

Elasticsearchだけならそこまで時間はかからないのですが、
Elastic Cloudで複数のサービスのデプロイとNext.jsでClient使えるか使えないのかわからないまま実装を続けデプロイの時にできないとわかり書き換えを行い時間がかかってしまいました。

既存のデータベースからどうやってスムーズに切り替えるか

こちらに関しては以前のスカウト機能はそのまま利用できる状態にし、
別のスカウトページを /v1/ のように用意することで対応しました。

ElasticsearchはデータベースがFirebaseと別なので、
移行の手間がかからないのでよかったです。
(同期の手間はかかります)

どうやったか

Elasticsearchをどのサーバに用意するかを決める

Elastic Cloudの利用しました。
自前でサーバを用意するかどうか迷いましたが、
ElasticCloudが自動で環境のセットアップをやってくれて料金もそこまでかからなさそうでしたので、
ElasticCloudを採用しました。

データ移行する

Firestoreの全データを取得し、
ElasticSearchにbulk関数でデータを移行しました。

つまづいたところ

frontendではelasticsearchのclientは使えない

Next.jsのapi機能をつかえば、nodejs環境でelasticsearchを動かせると思いました。
実際動いたもののデプロイの時にelasticsearchが使えないというエラーに遭遇し、断念しました。
最終的には、frontendからaxiosを使ってelasticsearchにアクセスしています。

Elastic Cloudを初期設定でデプロイすると高額になる

デプロイ時にSize per zoneとAvailabiluty zonesを調整しないと、開発時に必要なスペックの2倍以上高く設定されているので、請求も高額になります。

初月は 23,201.71 円請求されています。

何ができたか

最終的には「年齢」、「稼働時間」、「経験年数」を条件に追加して検索機能を作成しました。

総括

前々からElasticsearchを導入しようと思っていましたが、
なかなか時間を取れず導入できていませんでした。

今回導入の決め手になったのは、
スカウトの検索条件を追加してほしいという要望が顧客から入ったこと、
技術投資してることがエンタープライズとの契約取れているからでした。

みなさんもぜひElasticsearchを導入して検索制度を高めてみてください。
特にマッチング事業との相性はとてもいいツールだと思います。

さいごに

「ISSUE」では1,700人のエンジニアを無料で検索・スカウトすることができます。
ご利用されたい企業様はご登録いただき利用申請を行なってみてください！

企業様向けページ