【Product Story #4】自分に合った求人情報がLINEで届く「LINEキャリア」開発チームに聞く、サービスリリースまでと今後の取り組み

LINE上から求人情報を閲覧したり、応募ができる転職情報サービス「LINEキャリア」。サービス開始から8ヶ月経って登録ユーザー数が300万人を突破しています。今回は「LINEキャリア」プロジェクトメンバーたちに、その開発舞台裏について語り合ってもらいました。

「LINEキャリア」開発プロジェクトでの役割は?

── 今回はLINEキャリアの開発に携わっている皆さんにお集まりいただきました。まずは皆さんのご担当と、いつからプロジェクトに関わっているのか教えてください。

小澤:LINEバイト、LINEキャリア、LINE採用コネクトなどの開発を行っているHRサービス開発チームの小澤です。LINEキャリアには開発当初から関わっていて、今はDevelopリードという立場で、サーバーサイドの開発を担当しています。開発設計やミドルウェア選定などのアーキテクト的なこともやりますし、実際に手を動かしてコードも書きます。

黒澤:僕は入社2年目で、小澤さんのもとでサーバーサイド開発を担当しています。去年5月に、LINEキャリアの開発が始まって2~3カ月くらいのタイミングで配属されました。「engage」という採用支援ツールとの連携開発と「LINE採用コネクト」というサービスにジョインしています。

:Webのフロンドエンドを実装しているチームに所属しています。黒澤君と一緒で去年の新卒入社です。入社してからは社内のツールシステムやLINE STORE、おみくじキャンペーンなどのフロンドエンドの実装をやってました。今年の1月半ばからはLINEキャリアの開発に参加しています。

石塚:テクニカルPMチームの石塚です。去年の5月に入社し、LINEキャリアでテクニカルプロダクトマネージャーを担当しています。プロジェクトの進捗管理や、案件が企画・立案から開発、リリースされるまでを滞りなく進むように交通整理しています。中長期的な戦略を企画チームと一緒に考えたり、企画チームからの技術的な相談に乗ったりもしています。

テクニカルPMの最初の仕事はスケジュールを固めること

── LINEキャリアの開発プロジェクトはいつからスタートしたんですか?

小澤:おととしの年末頃から、技術的に開発可能かどうかの判断から始めて、どんなAPIが必要かなどを議論しながら進めてきました。開発人員も不足していて、黒澤君がサーバーサイド担当として配属されるまでは、インターンの学生と内定者バイトに1~2カ月間手伝ってもらっていました。

黒澤:はい、僕がアサインされたときは、まだ実装はほとんどされてない状況でしたね。パートナーであるエン・ジャパンさんが運営する「エン転職」からデータをとってくる部分と、そのつなぎ込みの部分はある程度できてましたが、フロント側はまったくできていない状況でした。

小澤:フロントに向けたコードやAPIをこれから作ろうというタイミングで、黒澤君と社員2名がヘルプに来てくれたので、サーバーサイドは社員4名、業務委託2名の6人体制で4~10月にかけて作っていました。

石塚:私がプロジェクトに入ったタイミングは黒澤君とほぼ一緒です。サーバーサイドの開発は少し進んでいるけど、フロントは全然手つかずで、いつリリースできるかという計画がほぼできていない状態でした。
いつ出せるのか、まずはリリーススケジュールを固めることが私の最初の仕事でした。ヒアリングしながらスケジュールを組んで、ここなら出せそうだという日程をエン・ジャパンさんとも握って、そこに向けて邁進しようとしていました。

小澤:LINEはLINE CONFERENCEなどイベントでの発表ドリブンでスケジュールが決まるほかは、基本的にはできあがったときに出して、改善を重ねるということが多く、LINEキャリアもそうするつもりだったんですが、石塚さんが来てからは計画的に進んでいきました。
4月には夏にリリース予定とプレスリリース出していたんですが、開発にアサインできる人数も開発スコープも決まってなかったので見積もりは出さずにやってました。時期を優先して出すか、作るものを決めてそれができる時期に出すか、夏と言ったからにはさすがに10月くらいには出すかと、石塚さんが入ったあたりで決めて進めました。

開発当初からのDevelopリード小澤さん

── ローンチまでに大変だったことは?

石塚:最初は正直年内に間に合うかどうかくらいの状況だったので、要件自体は応募歓迎やウィザードなどの機能がいろいろあったんですが、大きい機能は削ってもらいました。それから、開発メンバーに4名追加されたのは大きかったですね。

小澤:新卒社員を配属してもらえたのも、採用時点で決まってたわけではなかったのでラッキーでした。もう2人に来てもらえたのも、それまでもってた案件が空いたからジョインしてもらえることになったからなんです。ただ引き継ぎ業務もあったので、1~2カ月くらい予定より遅れてはしまいましたが。

石塚:結局本格的に稼働できたのは、7月くらいからでしたね。

黒澤:7~9月くらいが一番人が多かったですね。

小澤:期日を決めてリリースしようと思ったら、作るものを決めて、それを何人で作るか確定しないことには見積もりも人月計算もあったものじゃないですよね。作るものが決まるから工数としての人月が決まる。人数が決まるから人月を人数で割ってどれぐらいの時間がかかるかが決まるんですが、作るものも決まらないし、人数も確定しない。とはいえ、こういった新規サービスで、それらをまだ何も動いてない段階でウォーターフォール的にあらかじめ決めて進めるのがよいというものでもない。なので、スケジュールは作ってもあまり意味がないと、スケジュールはできる限り約束せず出さずに進める方針でやっていたらさすがに各方面から怒られました。石塚さんが来てそのあたりをやってもらいリリースにたどりつきました。

テクニカルPMとして計画的なプロジェクト進行を担った石塚さん

── 技術的に苦労したことや工夫したことを教えて下さい。

小澤:新規案件は新しい技術が導入しやすいので、各種フレームワークやライブラリにはは新しめのバージョンを採用することができました。また、ビューの部分について、フロントエンドチームの主導でNode.jsによるサーバーサイドレンダリングを導入しました。フロントエンドのチームがサーバーも見ることはこれまでなかったため、夜間休日に障害があったら誰がどう対応するかなどあたりから、フロントエンドチームと検討しました。

これまでの案件はサーバーサイドのコードの一部としてテンプレートが置かれ、そのテンプレートをフロントの人たちでいじってもらう。ブラウザで動くフロントエンドは、フロントチームが別途JavaScriptのコードを開発する。それらをこれまでは別々にデプロイしてたんですけど、フロントはすべてJavaScriptで書くことができ、サーバーサイドはAPIだけを作ればよくなった。おかげで線引きがはっきりして単体テストも書きやすくなりました。フロントは結構大変だったみたいですけど、サーバーサイドはすんなり進めることができるようになりました。

:サーバーサイドレンダリングはサーバー側のレンダリングとクライアント側が同じコードで動いているので、デバッグがめちゃくちゃしづらいんです。バグが出たときに、クライアントが原因で起こっているのか、サーバー側が原因で起こっているのか、それから認証チェックの切り分けが大変でしたね。

黒澤:認証はたしかにしんどかったところですね。LINEキャリアの流入元が色々あってそれぞれ認証のためにもつキー場所やフォーマットが異なっていたのでそこの調査が大変でした。クライアント側もサーバサイドレンダリングのためか認証のタイミングの問題で、動かないバグが発生したりと、かなり苦労していた印象があります。

新卒入社後、最初のプロジェクトだったサーバサイドの黒澤さん

配信の高速化、ビルド時間の短縮、ウィザード改修などローンチ後に解決した様々な課題

── ローンチ後はどのようなアップデートを行っていったのですか?

石塚:スケジュール優先で一旦ファーストリリースから除外した機能がいくつかあったのでそれらをファーストリリース後に順次対応していきました。それがだいたい昨年の年末から今年のはじめくらいですね。その後内部CMS対応や画面周りの改善などを進めています。

小澤:サーバーサイドで技術的に解決した課題としては、MAU8,000万を誇るLINE上でユーザーに対して、個別にいい求人がありますよという情報を配信しているんですが、大量に配信するとかなりの時間を要しています。
そこをどうにかするためにアルゴリズム面でのコードの最適化や、LINEのメッセージ配信で使っているKafkaというメッセージングキューのミドルウェアがあるんですけど、それをリリース後に、それまでの方式から切り替える形で導入するなど、配信の高速化がかなり大変でした。

また、直接それを解決するためにやったわけではないんですが、Javaで開発を始めたのですが、ローンチ前のある時期から段階的にKotlinを導入しました。現在はJavaとKotlinを併用してます。いくつか落とし穴も踏みましたが、プログラマとして触ってて楽しい言語で、結果としては導入してよかったと思っています。もっとKotlinに寄せていきたいですね。最初からやればよかったなとは思います。

黒澤:Kotlinの話でいうと、社内向けCMSの基盤は僕が作ったんですが、そこはサーバーサイドも全てKotlinで書いていました。楽しかったです(笑)。

小澤:社内向けCMSに関しては、フロントエンドのUITチームが人手不足だったので、サーバーサイドだけで作れるようにしようという方針を決めました。フロントの画面も黒澤君たちに作ってもらっています。

黒澤:技術的に難しいかは置いといて、社内向けCMSはサーバーサイドの担当者がフロントのコードも書くんですけど、ここはVue.jsで実装しました。

小澤:本格的にビルドシステムを構築することは、フロントではもちろんやっているんですが、そこまでやると結局手がかかってしまいます。そこでさくっとできる範囲で、にわかフロントエンジニアぽく動いてもらっていました(笑)。

黒澤:あとは開発が進むにつれて、ビルド時間が長くなってしまい、20~30分待たないと結果が返ってこなくなることがあったりしましたね。

小澤:それは単体テストを走らせているからなんですけど。

黒澤:それで開発の効率が下がった時期があり、その効率を上げるためにDockerベースのDroneというCIツールがあるんですが、それを導入して最終的に1~2分くらいまでに落としたことがありました。

小澤:プロジェクトによって使っているツールは違いますが、最近のサーバーサイドではSpringBootを使っていて、LINEキャリアもそうです。CI周りは自動化が進んでいるチームと、そうでなくて手動でやっているチームもありばらつきがあります。そういう意味で人がシャッフルされるようなかたちで始まったチームなので、いいとこどりができたのはよかったなと思います。最終的なビルドは現在もJenkinsでやっているんですが、そういった自動化も手作業が減って楽になりました。

── 一番印象に残っている・大変だったアップデートを教えて下さい。

:僕は年明けからジョインして4~5カ月担当しているんですけど、ジョインして少し経ったくらいのタイミングで、ユーザーが応募するときに履歴書(住所・氏名・年齢・職歴など)を入れるためのウィザードに結構大きな改修があったんです。まだ全体構造を把握してなくて、大きい改修をするとすぐバグが生まれてしまい、作っては直して作っては直してを繰り返していました。一応これで動きそうだとなるんですけど、どこかでちょっと良くないなというところが出てきてかなり苦労しました。

今年からLINEキャリアに携わるフロントエンドの原さん

小澤:QAでもかなり指摘されていましたね。

:普通に動かなくなってしまうんですよね(苦笑)。それは遷移の履歴だったり、いじるだけで壊れることがあった。画面や条件分岐が増えたりした影響で、ウィザードを全体的に作り直さなければいけないという話になってしまい…。そこから作り直していたので、結構時間がかかってしまいました。

小澤:ここの使い勝手が悪いと、ユーザーの離脱率が高くなってしまい、応募につながらなくなってしまう。
企画的に試行錯誤を繰り返しながらやらざるを得なかったし、開発陣もできるだけ柔軟にできるように作ろうとしていました。とはいえ、遷移パターンや画面が増えてくるとかなり大変でしたね。


ウィザードの住所入力画面。住所をキーボードで入力する
 →ボタンをタップするだけで住所を入力できるように

: 今まではプロフィールの各項目毎に1ページが割り当てられていて、遷移の度にAPIを叩いて保存するという形でした。つまり、画面の分割が細かくなった関係で、例えば生年月日の入力なら年、月、日で別々の画面になり、日付の入力が完了してサーバーに生年月日のデータを保存するまで、入力中のデータを保存しておく必要が出てきていました。これに関してはsessionStorageに一時的にデータを保存することで対応しました。
他にも今まではウィザードに流入した際に、入力済みのプロフィールから入力が必要な項目の配列を生成し、その配列に沿って画面遷移していたのですが、条件分岐が複雑になった影響で、配列での表現が難しくなってしまって。こちらは各入力項目のコンポーネント内部で別に条件分岐する為のロジックを用意して対応したのですが、こういった対応が当初の想定以上に多かった為に、結果的に大部分に手を入れるような形になってしまいましたね。

── 他社とのデータ連携が多いプロジェクトならではの苦労することはありますか?

黒澤:動作確認がすごくやりにくかったですね。メッセージ周りのAPIを作ってたんですけど、その時にエン転職側のCMSから確認しなければいけなかったりとか。

石塚:本番環境だと、カジュアルに応募することができないんですよね。テスト用の求人も出せないし。掲載されると本物の求人になってしまうので、リアル環境のテストがしづらいという問題もありました。
そこで、LINEで出しているリアル求人広告に、人事にかけあってテスト応募できるようにしてしてもらいました。とはいえ、本物の求人広告なので、テスト用だとわかるようにしてこちらから応募を入れても人事は反応しないでねって根回しをしたということなんですが(笑)。

小澤:接続という意味では、黒澤君たちがジョインする前の、開発着手の手前での調整が大変でした。パートナーありきでこういうサービスを立ち上げようとしているので、例えば履歴書のデータ構造などは変にオリジナリティを出さないで、そちらの履歴書のフォーマットに合わせましょうとか、そういう方針は決めていました。
事業側の都合としては簡単に応募できるように、必須の入力項目などはどんどん減らしていきたいのですが、真面目に履歴書の項目を入力していない応募が来ても困るというデメリット面もあるので、現状は減らせなかったりします。

20万社以上の求人データに対応中、大規模サービスとの新たな連携開発

── 現在進行中のアップデートはありますか?

小澤:LINEキャリアは、エン転職に出稿されている求人広告のデータをLINE上にも掲載されるという仕組みです。それに応募するとエン転職に応募データが送られる。
出稿している企業は現状エン転職から応募が来たのか、LINEキャリアから応募が来たのか、あまり意識する必要もなく、エン転職と同じ求人がLINEキャリアにも出ているという感覚です。

それに対してもう一つ、エン・ジャパンさんが運営する「engage(エンゲージ)」というサービスからも求人をもらえるようにしようとしています。それをLINEキャリアの上では混ぜて順序つけをし、同じように扱おうとしている。もちろんプログラム的にも難易度が上がります。
なぜ、そういう対応をしているかというと、エン転職とengageはサービスのモデルがかなり違っていて、エン転職の方は求人広告は掲載料をいただいて掲載しています。求人数としては5000件前後くらいです。

それに対して、engageの方は、無料で始められる求人・採用ページを手軽に作れるASPといったサービスで、無料で自社サイトの中に組み込める求人ページを作るシステム。エン・ジャパンさんもかなり営業をかけていて、20万社以上の企業が利用しています。それらの企業が数件ずつの求人を出しているので、かなりの数の求人があるのです。それらを秋頃に出したいと考えています。

黒澤:ただ同じ求人とは言え、求人データの構造が全然違っているので、内部で扱うためには一からテーブルを作り直さなければいけないという課題があります。

小澤:そうした問題は、連携サービスをやっていると結構あるんですが、今まで使ってたテーブルを拡張して、列を増やして両方のデータが入れるようにするか、テーブルを分けて別々で作るかのどちらかが多いんです。
その別のテーブルを同じく検索できるようにするのは技術的にも大変なので、1~2カ月くらいフィジビリティスタディをやってました。スタート時から、RDBMSとしてMySQL、ORMとしてSpring Data JPAを使っていたのですが、JPAに備わっている仕組みで上手くいくかを試し、今は目途がついて実装に入っています。また、このタイミングで全文検索エンジンとしてElasticsearchも導入するので、そこのつなぎ込みもどうにかやってます。

最初のリリースのときも検索はElasticsearchエンジンを使おうという話はあったんですが、5000件だったら素直にMySQLに入れてLIKE検索でいけるんじゃないという話になりました。実際、それでうまくいったのでElasticsearch対応を落としたという経緯がありました。そういう意味では積み残し課題の解消でもあります。engageによる求人数増加をきっかけに、これまでやっていたMySQLにSQLやJPAのクエリ言語であるJPQLで書いたクエリを投げてデータをとってきていた検索処理のいくつかを、Elasticsearch用のクエリを書き直して、Elasticsearchから取ってくるように置き換える感じです。

黒澤:そうですね。engage対応によって求人数がかなり増加するので、以下を目的に検索エンジンを導入することになり、そのベース部分を黒澤が対応しました。

● 求人数の増加に対して検索パフォーマンスを高める
● 企画要件に合わせた検索結果の柔軟なランク付け
● en転職求人、engage求人の横断的な検索

もともとSQLベースで検索ロジックを構築していた分、同じインターフェースで同様の結果が帰るように中身を変えるのは苦労しました。社内でElasticsearch運用の定石があまり確立していなかったたため、ダウンタイムゼロでインデックスを更新したり、検索ロジックや検索スキーマの変更時の最適なリリース法を考えるなど手探りな部分も多かったですね。

小澤:実装が出来上がり、データを恐る恐る投入している段階です。データを投入するとまたバグが出たりしてうまく動かないところが出てくるのですが。

LINEキャリアを今後どうしていきたい?

──最後に、今後LINEキャリアで取り組んでいきたいことは?

石塚:これまで転職サイトに応募して転職しているユーザー層は、パソコンに対するリテラシーが高く、転職意欲が高い人が中心でした。LINEユーザーはデジタルネイティブな若年層が多く、転職潜在層でもまずは気軽に応募してみることができる世界観を目指しています。

小澤:今後の企画としては、潜在層に向けた仕事がつらいときに励ますコンテンツや、キャリアアップに役立つコンテンツ配信なども行っていく予定と聞いています。コンテンツを読んで転職したくなったらそのまま応募できるようなサービスになるかもしれません。

:engageの求人情報は、タイトルや見出しが決められるのですが、それをどう実装するかを検討しています。今後エン転職と同じように求人情報として並ぶ際に、形式の違うデータを一覧でどう表示するかなど、頑張って作ってるところです。

石塚:さらにその求人情報がLINEアプリやブラウザなどいろいろな環境で動く状態にしなくてはいけないので、そこらへんが難しいですね。それからなるべくLINEのトークルーム上で使っている感覚を維持できるようなUIを考えていて、ウィザードで入れている登録項目をトークで対話している感覚で入力できるような機能を先日リリースしました。
いろんな層のユーザーが誰でも好きな仕事が探せて、いろんな企業が参入してあらゆる求人広告が掲載されるような世界観が目指すところ。企業が採用のための人を集めるハードルを低くしていきたいですね。

黒澤:トーク画面から直結応募できる機能を実装したいです。今作っている採用コネクトは、企業と直接LINEでやり取りできる仕組みで作っているんです。それがうまくいったらLINEキャリアにも実装していきたいですね。

LINEキャリアの開発に携わる募集ポジションはこちら