法務とシステム開発の意外な共通点？エンジニアが語るリーガルテックの可能性

こんにちは、LegalOn Technologies人事採用担当の松本です！弊社オープン社内報「LegalOn Now」にて、エンジニアの対談記事を公開しました！ぜひご覧ください！

法務領域でサービスを展開するLegalOn Technologiesですが、社内アンケートによって開発メンバーのうち約半分が「入社当時はリーガルテックに興味がなかった」という事実が判明！ それでも日々新たなメンバーがジョインし、開発に打ち込んでいるのはなぜなのか？ 法務とシステム開発の意外な共通点やリーガルテックの可能性などについて、開発本部の2人に語ってもらいました。

深川 真一郎（ふかがわ しんいちろう）　開発本部 副本部長 兼 エンジニアリング推進部 部長
大学卒業後、SIer、大手スマホゲーム会社を経て、2019年5月より現職。LegalForceのインフラ・バックエンド開発に従事したのち、開発責任者を経て、エンジニアリング推進部部長に就任。開発チームの文化浸透、組織の最適化に向けて取り組んでいる。

米屋 孝貢（よねや たかつぐ）　LegalForce開発部 バックエンドエンジニア
大学在学中にゲームソフト開発受託会社にアルバイトとして参画、卒業後入社。勤怠管理アプリや大手IPのソーシャルゲーム、Webアプリの開発に従事したのち、2022年9月より現職。LegalForceのバックエンドエンジニアとして保守運用を担当。

エンジニアはリーガルテックにあまり興味がない？

以下は開発メンバーにとったアンケート結果。
なんと約半数がリーガルテック分野に「興味が無かった」という回答でした。
その理由として、91%が「これまでに業務上法務や契約書業務に関わる機会が無く、イメージがわかなかった」ことを挙げています。

―　入社前はリーガルテックにどんなイメージをもっていましたか？

米屋　リーガルという言葉から、裁判とか訴訟とか、そういうイメージでした。説明を受けて初めて「あ、法務のことなんだ」と知ったくらいです。

深川　ドラマなんかのイメージが強いですよね。

米屋　そうですね。法務に関しても前職で開発の際に規約をチェックしてもらうなどのやりとりはありましたが、その程度でした。
実際にプロダクトの説明を聞いて、やっと「なるほど業務の自動化か」と理解できましたね。

―　深川さんは採用にも関わっていますが、そういう候補者は多いですか？

深川　多いですね……。ほとんどの方がリーガルテックのことを知らなくて、「興味がないから」と辞退されるケースもありました。
そもそも、リーガルテックに限らず、特定のテックに興味があるエンジニアって業界内にもほとんどいないんじゃないかと思うんですよ。
金融領域に課題感をもっていたとしても、「フィンテックがやりたいです！」なんて人はあまり見たことがありませんし。
「●●テック」という言葉は、エンジニアに対しては使わないほうがいいのかもしれないですね（笑）。

米屋　リーガルテックは特に興味をもたれづらい気がします（笑）。

―　なるほど。そんななかで米屋さんが当社に興味をもったきっかけは？

米屋　深川さんからいただいたスカウトメッセージです。
「法務はシステム開発と似ている」という内容で、確かに、扱うドキュメントの構造なんかは近いものがあるなと感じました。

深川　そう、実はシステム開発、特にITセキュリティの世界と法務の世界って似ているんですよ。
実際やってることは本質的にはかなり近くて親和性があるのに、イメージしづらいという理由でそれを知らないまま選考を辞退されるのは非常にもったいないなと。

目指しているのは、法務にとってのIDE、GitHubを作ること

―　法務とシステム開発に親和性があるとは、具体的にどういうところですか？

深川　例えば、法務で扱う契約書は、文章が構造化されていて文章解釈の幅が通常の会話などと比べると少ない点などがプログラムと似ています。
基本契約・個別契約という契約書の体系はプログラムでいう「基底クラスと派生クラス」と同じ考え方ですし、契約書に出てくる用語を定義する「定義条項」はプログラミングの定数定義そのままです。
他にも契約書や法務業務に関連する共通項って結構多いんですよ。

～システム開発と法務業務の似ているところ～
・契約のしくみがプログラムと似ている
　- 共通部分を基本契約、個別部分は個別契約として契約する
・契約書の文書構造がプログラムと似ている
　- 語句の定義 -> 変数・定数の定義
・契約書の作成フローがエンジニアのコーディングと似ている
　- 一般的な契約ベストプラクティス -> linter
　- 表記ゆれ、インデント、校正 -> formatter
　- 定義の参照 -> コードジャンプ
・契約書の版管理がエンジニアのバージョン管理と似ている
　- 版管理 -> SVN, Git
・契約書の更新差分管理がエンジニアのコードレビューと似ている
　- 新旧比較表 -> diff
・レビュー業務がシステムの脆弱性診断と似ている
　- 法務が指摘したリスクを事業部が許容できるかを考慮して判断 -> 脆弱性診断で指摘したリスクを事業部が実際に攻撃を受けるリスクなどを考慮して判断
・各部署からの依頼受け付け・管理がサポート業務に似ている
　- タスク管理 -> JiraやBacklogを利用したタスク管理
・法務部員のパフォーマンス測定がエンジニアのパフォーマンス測定と似ている
　- 案件の難易度とチケット消化数 -> タスクのストーリーポイントとベロシティ

米屋　契約書っていう切り口から説明されると、エンジニアとしてはスッとイメージできる気がしますね。

―　実際の業務の中で、親和性を感じることもありますか？

米屋　はい。入社後にオンラインエディタ機能のオープンベータ版開発に関わり、コメント機能の実装を行いました。
これは契約書に対して文字単位、行単位でコメントを入れられる機能なのですが、コメントに対して返信したり解決したりという挙動が、まさにGitHubのPull Requestのようでした。
このようにエンジニア的に理解しやすい部分が多く、開発のしやすさを感じましたね。

深川 「法務にとってのIDE、GitHubを作ることを目標にしよう」ということを、採用でもチームに対しても日頃から伝えるようにしています。
エンジニアにとって法務がイメージしやすくなるような説明を、というねらいです。

米屋　確かに、この話は入社前にも聞いていて、個人的にはすごく響きました。
「契約書の作成をWordではなくIDEでできたら、確かに法務担当の方は便利でびっくりしてしまうんじゃないか」「GitHub Copilotのコードレコメンドみたいにtabキーをおせば自動でサジェストされた条文が入力されたりする未来は楽しそうだな」とか考えると、ワクワクしますね。

エンジニアが使っているツールの法務版を作る、というイメージはわかりやすいですし、問題を自分ごと化しやすかったです。

開発の延長でプロダクトをとらえ、社会課題の解決に貢献できる

―　リーガルテックのおもしろさ、魅力はなんでしょうか？

米屋　普段の業務の延長でプロダクトを考えられ、それが社会課題の解決につながる経験は初めてで、すごいな、かっこいいなと感じます。

深川　法務とシステム開発には違うところもあって、それが難しさであり魅力でもあるのかなと。
契約には2者が存在し、その同意のもとに締結するものなので、プログラムのように常に正解があるわけではないですし。

―　それがどんな魅力につながるのでしょうか？

米屋　コミュニケーションありきの設計を意識しないといけないところは、難しさや魅力なんじゃないかなと思います。
業務の効率性よりも、シームレスでワンタッチ入力できるなど「いかにコミュニケーションをとりやすくするか」という切り口でUIを設計する必要がありました。
お客様のユースケースもバラバラなので、「LegalForce上で実際にどのレベルでコミュニケーションするのか？」を想定しながらいい塩梅で設計するのは苦しみでもありながら、おもしろみでもありますね。

―　リーガルテックに可能性は感じますか？

深川　間違いなく可能性はありますね。法務はまだまだアナログな部分が残る領域です。
ITで解決できる課題が多いからこそ、改善しがいがあるな、と感じています。
これが例えばゲーム業界などだと、目立ったところはあらかた効率化されつくしていて「あとどこやろうかな」ということになってしまう。

米屋　確かに、エンジニア的な発想で、いくらでも業務の隙間を埋めるようないいアイディアが生まれそうですよね。
オンボーディングで法務の業務フローについて動画を見ましたが、エンジニアがこれやっていたら絶対匙を投げるな、という感じのレガシーな匂いがプンプンしました（笑）。
その分、もっとこんな事ができるんじゃないかという創作意欲はすごく湧きましたね。

法務領域はエンジニアにとって「強くてニューゲーム」？

―　LegalOn Technologiesに興味をもった方にメッセージをお願いします。

深川　法務領域は、IT化による改善の余地がまだ残っており、「強くてニューゲーム」ではないですが、エンジニアとしてのノウハウを活かせるフィールドです。そう考えるとワクワクしませんか？
それに、エンジニアの中には「世の中の非効率を撲滅したい！」と考える方が結構いると思います。プログラマーの三大美徳*でいうと、怠慢にあたる部分ですね。
そういう方には、「リーガルテックに興味がなくていい。だけど、その気質を満足させられる環境はある」と伝えたいですね。
*プログラマーの三大美徳：Perlの開発者Larry Wallが提唱した考え方で、エンジニアの本質は怠慢、短気、傲慢の3つであると定義したもの。

米屋 「自分のエンジニア力でプロダクト開発を行いたい」という方にぜひ来ていただきたいと思います！

LegalOn Technologiesではエンジニアを募集しています！
Software Engineer, Backend
SRE / Site Reliability Engineer
Software Engineer, Frontend
Product Engineering Manager