こんにちは、LegalOn Technologies採用の松本です。
今回クローズアップするのは、2024年に中途入社した検索・推薦エンジニア、荒瀬。
当初リーガルテック分野に距離を感じていたという荒瀬が、なぜ当社への入社を決めたのか。
前職、大手EC企業でのtoCプロダクト開発から、LegalOnでのtoBプロダクト開発を経験して得られた気づきやそれぞれの面白さ、エンジニアとしての成長について語ってもらいました！

荒瀬　晃介（あらせ・こうすけ）　検索・推薦エンジニア
大学院修了後、在学中からインターンで働いていたメルカリに入社。エンジニアとして、機械学習モデルの作成から運用、バックエンドやインフラ、検索、USチームでの開発など幅広く経験。2024年7月～検索・推薦チームのStaff EngineerとしてLegalOnに入社。
X（旧Twitter）: https://x.com/kosukearase

リーガルテックとの心理的距離が縮まった「法務版 GitHubをつくる」に納得！

―　荒瀬さんが転職活動をはじめた当初、リーガルテック分野にはそれほど興味がなかった、と聞きました。

そうなんです。
法律は全然知らないし、「堅そう」「専門性が求められそう」など漠然としたイメージから、心理的に距離を感じていました。

前職のメルカリでは、toC向けのプロダクト開発に長く携わっていたので、単にtoBの業務内容がイメージしづらいという理由で、選択肢から外してしまっていた部分があるかもしれません。
toCに比べるとトラフィックが小さくシステムのスケーラビリティ観点で技術的にチャレンジングでないイメージや、検索経由での購入が大半を占めるECと異なり、toBでは検索の改善を売上という数値で測りにくい印象もあって、応募当初の志望度はあまり高くなかったですね。
知人が何人か入社していて技術力が高い印象があったので、まずは話だけでも聞いてみよう、という感じでした。

―　では、どうして最終的に入社を決めてくれたのでしょうか？

選考が進むうちに、徐々にイメージが変わってきました。
カジュアル面談や面接時の逆質問でさまざまなメンバーと話していくうちに、LegalOnへの志望度が高まっていきましたね。

はじめは法務の業務をわかっていなかったため、どんなプロダクトで、どんなペインを解決するのかイメージしづらかったのですが、法務の業務フローをエンジニアの業務になぞらえて、「法務版 GitHub のようなものをつくろうとしている」という説明を受けました。

例えば、法務が契約書のレビューを行う際、取引先とコミュニケーションを取りながら契約書の修正を重ねる作業が発生します。
このレビュー業務をより円滑にするために、修正前後の差分を左右で比較して表示する「条文比較」というサービスが、エンジニアのコードレビューと非常に似ていると感じました。
そうした共通点がある一方で、エンジニアにとってのGitHubにあたる仕組みが法務には存在しなかったんですね。

エンジニアの私にとってはかなりわかりやすい例えで、「なるほど、確かにそういうツールは欲しくなりそう」「それならやれることがいろいろありそう」と腑に落ちた記憶があります。

ー　ドメインとの心理的な距離が縮まったのですね！技術的な観点ではどうでしょうか？

転職にあたり抱いていたのは、機械学習、検索、バックエンド全てを駆使して賢く価値のあるシステムをつくりたいという思いです。

法務の業務では、過去に締結した契約書も含む膨大なテキストデータを取り扱うので、LegalOnのプロダクトではそのデータを整理して、ユーザーが欲しい情報を提示することが求められます。
それはまさに、機械学習や検索、バックエンドにおける高度な技術をすべて組み合わせないとできないこと。
「ここなら自分がやりたいことができそう」と感じて、入社を決めました。

ユーザー目線でとことんつくりこめる、toBならではの面白さ！
どちらも経験することで、エンジニアとして成長できる

―　入社後、toBのプロダクト開発にはじめて関わって、どんな違いを感じましたか？

まず、toBのプロダクトは、toCよりも更に具体的なユーザーを意識する必要がある点が面白いなと感じました！
toCの場合は多様なユーザーがいるので、1人ひとりのユーザージャーニーに最適化することはしばしば最適ではなく、A/Bテストなどの統計情報を介してユーザーの行動を間接的にとらえることが多いです。

一方で、LegalOnのプロダクトはユーザーが法務担当者であり、業務フローがある程度限定されているため、より具体的なペルソナを想定した分析やディスカバリを通して、業務の背景や、担当者・依頼者の思考まで細かくイメージすることが重要です。
1人のユーザーのペインに焦点を当て、過適合を恐れずに体験をつくり込めること、それによって今までにない価値を提供できるのは、toCとはまた違った面白さがありますね！

実は、私にはもともと「toBはエンジニアとプロダクトとの距離が遠い」という先入観がありました。
リーガルテックはSaaSで、自分が使ったことのないツールで、かつ馴染みの薄いドメインでもあったので、プロダクトとの距離感をより強く感じていたかもしれません。

でも実際には、よりユーザー目線で考える必要があるという意味ではむしろ「プロダクトとの距離が近い」と感じています。

 ―　リーガルテック分野に馴染みがなかった中で、ユーザー目線をどのように身につけたのでしょうか？

入社前はドメイン知識にキャッチアップできるか少し心配もあったのですが、実際に開発を進める中で、法務担当者がほしい機能をどう作るか、実務者目線でディスカッションを重ねたことが、一番キャッチアップにつながりました！

とくに、弁護士などの専門家からなるLD（法務開発）チームといつでもコミュニケーションできるのはLegalOnならでは。
エンジニアとPdM、そしてLDの3者で議論できるのは良い環境ですね。
決まった要件や仕様が降ってくるのではなく、「実務担当者はこう考えて検索している」「エンジニアからすると、今あるこれらを合わせればこんな機能が実現できそう」など、それぞれの目線で情報を整理しながらプロダクトを作り上げていくことができます。

―　以前抱いていた、「トラフィックが小さい＝チャレンジングではない」という懸念についても考えが変わったとか。

toBはtoCに比べてトラフィックが小さい分、別のベクトルでのチャレンジを行うことができると考えています。
例えばユーザーのクエリの意図推定で LLM を活用するようなことは toCの大きなサービスではレイテンシ、コスト観点で現実的ではないかもしれませんが、我々はそこにチャレンジできます。
より広い選択肢の中からユーザーに価値を届けるために必要な手段を選択できる。
そのような作り込みが可能な点が面白く、魅力だと感じています。

―　他にも、toBプロダクトならではのチャレンジはありますか？

toCと toBでは求められる頭の使い方が違うので、その点も面白いチャレンジだと思っています。
たとえば、toCの検索・推薦エンジニアにとって、データの利活用は自然なこと。
そこから機械学習モデルをつくって、より賢い判断や効率化につなげるのは1つの「正解」です。

toBの場合は必ずしもそうではなく、「顧客のデータを、他の顧客にも提供するモデルの学習に使っていいのか？」「なぜそれが推薦されているのか？」という納得感や正当性も重要。
過去のデータをより具体的に明示して、「あなたの過去の行動やデータをもとに、こういう理由でこれを推薦をしているんですよ」と示すことが好ましい場合もあります。

単に良いモデルやシステムをつくるだけでは、ユーザーのペインを解決できない可能性があるため、ユーザーが抱える問題をどう解決するか、より注意深く検討することが重要になるのです。

―　toC、toBを両方経験してきた荒瀬さんならではの気づきばかりですね！
エンジニアのキャリアとして、両方を経験する意義はなんだと思いますか？

顧客のことを数字を介して見るtoCか、顧客目線で見るtoBか。
大規模なトラフィックをさばくtoCか、技術的選択肢の幅が広くより作り込めるtoBか―。 
どちらが優れているということはなく両方楽しいですし、ソフトウェアエンジニアとしてはキャリアの中でどちらも経験すべきだと思います。
僕の場合はtoCからtoBに移りましたが、どちらも経験した方がエンジニアとしての幅や目線は広がり、自身のより大きな成長につながると思っています。

「複雑で難しい」プロダクトを、エンジニアリングドリブンでより良いものに

―　LegalOnでの業務の面白さは、どんなところにありますか？

LegalOnの仕事は「複雑で難しい」から面白いです。
ただ「ユーザーがほしいものを出す」のではなく、過去に似た契約書がないか、その契約書が締結版ではにどのような形になったか、印紙税は必要だったか……などと、法務担当者の思考と行動をトレースしていく必要があります。
とはいえシステムが無限に複雑になりすぎてもいけないので、どうしたらそれをシンプルに実現できるかチームでディスカッションを交わすのも楽しいですね。

―　検索・推薦チームの良いところを教えてください！

1つはプロダクト志向の強さですね。
プロジェクトの立ち上げ時から参画したいという熱意があって、アイデア出しにも積極的です。

また、個としてよりも、チームとして動く意識の強さも感じています。
スクラム開発を取り入れていますが、retrospective ではいつも時間が足りなくなるくらい議論が活発で、継続的に改善サイクルを回しているのは印象的です。

さらに、私たちのチームの「LegalOnのファーストペンギンになろう」という文化も好きですね。
全社で一気に導入するのは大変だけど開発体験を向上させるであろうツールや仕組みがあれば、まずはうちのチームでクイックかつスモールにPoCを行い、良ければ全社に展開する。

「私たちの仕事はここまで」と線引きせず、プロダクトと開発組織を良くするために必要なことはなんでも行おうという精神のチームで働けることは、開発者としては非常に魅力的に感じます。

―  荒瀬さんは今後、どんなことに取り組んでいきたいですか？

機械学習と検索、バックエンドの技術をすべて組み合わせて価値を提供したいという思いは変わっていません。
法務担当者の業務を日々サポートしながら、使い込むほどにナレッジが蓄積され、法務の知識・経験がない人たちでもその思考や行動を再現できるような、価値あるプロダクトを届けていきたいと思います。

―　最後に、転職を考えているエンジニアに一言お願いします！

toCでの開発に慣れたエンジニアからすると、toBは往々にして二項対立の反対側に位置するため、比較して劣っているように見えることもあるかもしれません。
しかしながら、 toCとtoB、それぞれに固有の技術的チャレンジがあり、目指すべき方向が異なるだけで双方に大きな魅力があり、エンジニアとしてはどちらも経験することでより成長できるのだと思います。
僕自身も必要以上にtoBへの心理的距離を感じていましたが、入社してみてその認識を改めました。
実際toC出身のエンジニアも多いので、ぜひLegalOnを選択肢のひとつにしてほしいと思います！

We’re Hiring!

LegalOn Technologies の開発チームでは、エンジニアを積極採用中です！

▼開発募集職種一覧はこちら

少しでも興味をもっていただけましたら、ぜひお気軽に採用チーム（recruiting@legalontech.jp）までご連絡ください！
最後まで読んでいただきありがとうございました。