LegalOn Technologiesが提供する「LegalOn: World Leading Legal AI」は、契約書ドラフト・レビューや案件の管理、法務相談まで、法務業務をワンストップで支援する革新的なサービスです。リリースから1年半、企画開始から約2年半が経った今、プロジェクト立ち上げの背景、開発の進め方、これまでの振り返りや今後の展望、さらには技術面での学びまでを、全9回にわたるブログシリーズとしてお届けしていきます。
第6回となる本記事では、「LegalOn」のフロントエンドアーキテクチャと技術選定に焦点を当て、当時の意思決定の背景や、これまでの成果・課題について、CTOオフィスリーダーの時武がリードエンジニアの安部に話を聞きました。
- 安部亨佑：Lead of Frontend Engineer
シンプルな垂直分割アーキテクチャの採用
時武 安部さんは、先日公開された「第4回「LegalOn」誕生の裏側：全体アーキテクチャ設計と技術選定編」でもお話いただきましたが、今日はフロントエンドに特化していろいろ聞ければと思ってます！よろしくお願いします。
安部 よろしくお願いします！
時武 まず、「LegalOn」の開発開始当初、どんなフロントエンドアーキテクチャを検討されたのか、背景とあわせて教えてください。
安部 開発が始まったのは2023年頃で、Webフロントエンドにおけるアーキテクチャ関連だと、ちょうどマイクロフロントエンドという概念があらためて注目され始めた時期だと思ってます。和訳された書籍も出始めて、チーム内でも関心が高まっていたんですよね。
ただ、そういった具体的なHowは後回しで考えていました。そうではなくて、複数の開発チームが一つのプロダクトを作るという前提でいかに開発をスムーズに進めるかということをまず考えました。例えばナイーブな設計の結果「コンフリクト地獄」で開発が止まってしまい、各チームがしょっちゅうお互いを気にしながら開発するのは避けたいな、とか、かといって各チームのコードベースが完全に独立しているのもちょっと違うかな、とか。
マイクロフロントエンドはこういった問題に対するアプローチとして有効だろうなーとは考えていましたが、実際に運用するとなるといろいろ課題がでてくるだろうなという懸念がありました。
時武 実際、どんなアプローチを試されました？
安部 最初は著名なライブラリの採用を検討しました。実際POCも書いてみたんですけど、モジュール間の状態管理の手順や実際のDOM構造を読んだ結論としてトラブルの多さを予測し、早めに断念しました。
最終的には、シンプルな垂直分割型のマイクロフロントエンドアーキテクチャに。 認証情報を共有して、各チームが作成したアプリケーションを同じドメイン下の異なるディレクトリに配置するという、かなり愚直なアプローチです。 正直なところ、当時はこれを「マイクロフロントエンド」と呼ぶ意識すらなくて、「認証情報を共有して、同じドメインから配信すればいいでしょ」くらいの感覚だったのですが、後でSREのメンバーがマイクロフロントエンドの垂直分割と認識していると言われて、「ああ、そうだったのか」と（笑）。
結果として、各チームの独立性やデプロイパイプラインの分離がうまく機能して、よい塩梅だったと思っています。
Next.jsの不採用理由とAegisの効果
時武 Next.jsを採用しなかった理由は、読者も結構気になると思うんですが、どういった背景があったんですか？
安部 主に実装・運用の重さですねー。 当時はSPA（Single Page Application）で十分要件を満たせていたので、Next.jsが提供するサーバーサイドレンダリングなどの機能はそこまで必要ないと考えていました。起動時間やパフォーマンス面でも、優先度はそこまで高くなかったです。
それに、Microsoft Word アドインのような、一般的なWebアプリケーションからはやや異なる要求が将来的に発生しうることを見据えたときに、特定のフレームワークに強く依存するのは避けたかったんですよね。特にBtoBや、エンタープライズ向けのシステム開発では、通常のWeb開発とは違って柔軟な設計が求められるので、将来的な選択肢に影響を与える重たい技術選定は避けられるなら避けようかなと。
学習コストの問題もありましたね。「LegalOn」を開発することになるチームが過去作っていたプロダクトはいずれもNext.jsを採用していなかったので、もしNext.jsを採用すると絶対に学習コストが乗ってきます。個人としては知らない技術は学んで使ってほしいという気持ちはありますし、そもそも今回他に新たに採択したライブラリもいろいろあるんですが、Next.jsについては必要性が絶対的ではないので話が異なるかなと。
あとは当社の組織はフロントエンドとバックエンドが明確に分かれていることもあり、Next.jsで無理に一本化するメリットはあまり感じませんでした。今の組織フェーズや開発体制に合う選択を無難に行った、という感じです。
時武 なるほどー。逆に、「これは導入して正解だった」と思えるものってありましたか？
安部 正解かどうかというものではないんですが、デザインシステム「Aegis」の本格的導入はとても大きかったです。これまでも各プロダクトで部分的に使ってきたんですが、徹底して使うようになったのはこのプロジェクトが初でした。 AI時代になっても一貫性のあるUIをしっかり提供できる土台として、すごく価値のある仕組みになってると思います。
共有コードの管理とBFFの必要性
時武 では今後は運用フェーズでの話を聞きたいんですが、運用していく中で見えてきた課題は何かありました？
安部 特に苦労したのは、各フロントエンドモジュール間のリンクの管理と、共通ユーティリティや基底コンポーネントなど共有コードの管理です。前者については、各フロントエンドのコードを解析しリンク情報を集約し、遷移可能なURLに対応した型安全なコンポーネントを提供する「ルーティングライブラリ」を自前で開発することで対応しました。
ただ一方で、共有コードの管理に関しては、もう少し考えるべきだったかなと思っています。GitHub Packagesを用いて内部パッケージ化は行ったものの、その後のリリースプロセスが想定以上に煩雑でした。リリースについてもっと深く検討してから設計する必要があったなと思っています。
ただ時期的にやむを得なかった事情もあるので仕方ない部分もあります。例えばModule Federationを利用して共有コードを動的に読むこむようなアプローチを検討することもいまならば可能ですが、当時ビルドツールとして採用したVite向けのModule Federationの技術がまだ成熟しておらず、導入を見送らざるを得なかったという背景もありました。このあたりはどうしてもめぐり合わせというのがあるので悩ましいですね。今後はより成熟した技術を活用してリリースプロセスの最適化をどんどん進めていきたいと思っています。
時武 他に「ここはもっとこうすべきだった」と思う点はありますか？
安部 今思えば、BFF（Backend for Frontend）は導入しておくべきだったと思ってます。基本的にはリソース志向でスキーマを設計しているんですが、やはりどうしてもフロントエンドの都合が混じってしまっています。その点BFFがあれば、フロントエンドの関心をバックエンドからきれいに分離できた可能性が高いと思いますね。スキーマ設計やコードレビューだけでこの問題を解消するのも限界がありました。
例えばですけど…最近はAI技術がすごいスピードで進化しているので、より様々な用途でのプロダクトへの導入も当然検討しているのですが、APIからフロントエンド側の関心をしっかり切り離しておけば、より高速かつクリーンにAI対応ができ、ユーザーへの価値提供がより迅速にできたと思っています。当時はこれほどまでにAIが急速に進化するとは思ってなかったんですが、今振り返るとBFFみたいな仕組みを入れておいたほうが長期的に見ても柔軟だったなと。とはいえ、BFFを入れるというのはアーキテクチャ上のレイヤーが一枚増えるので、簡単な判断ではありませんが。
技術力だけではない、組織と人の重要性
時武 アーキテクチャ設計において、技術的な側面以外で重要だと感じたことはありますか？
安部 アーキテクチャの裏には人やチームの連携が絶対に発生してくるので、その点についてはきちんと考えておく必要があると思っています。ソフトウェアエンジニアリングとして正解に近いであろうアーキテクチャを組むということと、それを運用することは別、というか。例えばモジュールどうしの連携が必要な場面で、適切なタイミングで開発チーム間で連携をする仕込みがなんらかの形でなされているか、みたいな話です。それが技術的な仕組みなのかSyncするための会議なのかまたがって動く人なのかはいろいろだと思いますが、例えば組織間の窓口役になっている人が正しく機能しているのか、とか、ひょっとして仲が悪いんじゃないか、とかまで考えておけるといいかなと。結局、理屈だけではどうしても人は動かないので。だからといって技術過ぎるアーキテクチャを許容するのもやむなし、という話ではなく、こういうことを考えておくと最終的なアーキテクチャにもよい形で影響があるんじゃないかという話です。
時武 たしかにそうですね。理論通りに人って動かないですもんね。
安部 そうなんですよね。 自分はよく、サッカーのドイツ代表のナーゲルスマン監督が「戦術30％、マネジメント70％」って言っているのを例に出すんですけど、これはアーキテクトにもすごく当てはまると思っていて。どれだけ技術的に完璧なアーキテクチャを考えても、結局それを使うのは人間だし、実際に手を動かすのも人間なんですよね。だからこそ、どうすればチームが気持ちよく動けるかとか、どうすればモチベーション高く保てるかをちゃんと考えることが、結果的によいアーキテクチャにつながるんだと思ってます。
持続可能な開発組織と揺るぎないユーザー第一主義
時武 最後に、今後の展望についても教えてください。
安部 大きく二つの柱があるかなと思っていて。
一つは、開発組織の持続可能性と開発者体験の向上です。 「リリース最優先」「ユーザー最優先」とよく言いますが、それで開発者の楽しさや成長が犠牲になりすぎてしまうのは違うなと思っていて。大前提として優先順位は必要ですが、やっぱり開発者が気持ちよく、楽しく開発できることが、結果的によいプロダクトにつながると信じてます。そのためにもトレンドを睨みつつ、ユーザーや会社、開発チームそれぞれのバランスを見ながら様々な改善を進めていければなと。
もう一つは、あらためて「ユーザー第一主義」の徹底です。 自分たちが作っているのは、あくまでユーザーの課題を解決するための「道具」なんですよね。その道具が使いやすいものであることは絶対にぶれてはいけない。だからこそ、パフォーマンスやマイクロインタラクションといった細かい部分まで、しっかり気を配って徹底的にユーザー体験を追求する必要がある。ビジネスニーズももちろん重要ですが、それに振り回され過ぎて、目的が曖昧な「キメラみたいなプロダクト」になってしまっては本末転倒。常に、「誰のどんな課題を解くためのプロダクトなのか」という軸を見失わないようにしたいです。これはプロダクト開発者は皆肝に命じるべき事柄だと思いますが、開発者の中でもユーザーが直接触る部分を作るフロントエンドエンジニアがやれることや気づけることはやっぱり多いのかなと。
時武 たとえAIが進化して低コストでプロダクトが作れるようになっても、それを使うのは人間ですもんね。「安心して使えるプロダクト」を作り続けるっていうのは、変わらないんですね。
安部 はい。AIがどれだけ進化しても、触ってみて「なんか重いな」とか「気持ちよくないな」と思われたら、やっぱり使ってもらえないんですよね。その「よい感じ」って、結局、人間の感性でしかわからないと思ってます。だからこそ、ちゃんと「使える道具かどうか」にこだわり続けたいなと思っています。
LegalOn Technologies では、「Product Centric（全員がプロダクトの価値向上のために活動する）」 を大切にし、学ぶことに前向きで、挑戦を楽しめるエンジニアを募集しています。今回の記事で触れたような技術的な挑戦や、チームで課題を解決していくプロセスに興味を持たれた方は、ぜひ以下の採用サイトをご覧ください。皆さんのご応募をお待ちしております！
次回は、「第7回「LegalOn」誕生の裏側：バックエンド編」をお届けいたします。
コメント