Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)

Transcript

1. 株式会社LegalOn Technologies 浅野 卓也 プロダクトの価値を高めるためにコーディング以外にできること ～共通言語でつくる異職種コミュニケーション～
2. 自己紹介 2 株式会社LegalOn Technologies LegalOn Cloud リードエンジニア（検索・推薦） 浅野 卓也 2011年3月 古河電工関連会社（システムエンジニア） 2015年4月 はてな（Webアプリケーションエンジニア） 2019年8月 メルカリ（Software Engineer, Search） 2023年2月 LegalOn Technologies（Staff Software Engineer） 日本の検索技術コミュニティ search-tech-jp を運営
3. 3 法とテクノロジーの力で、安心して前進できる社会を創る。 最新のテクノロジーと法務の知見を組み合わせた製品を開発・提供 グローバルで 従業員数600名※1 グローバルでの サービス導入社数 6500社以上※2 開発専任の 弁護士が在籍 シリーズD 累計調達額 179億円 株式会社LegalOn Technologiesについて Purpose ※1 2025年1月時点 ※2 2024年12月時点
4. 4 LegalOn Technologies のプロダクト 法務・契約支援 経営・コーポレート支援
5. 5 今回は「LegalOn Cloud」の開発過程にフォーカス 法務・契約支援 経営・コーポレート支援
6. 6 「LegalOn Cloud」でサポートしている領域
7. 「LegalOn Cloud」の主な検索・推薦機能 • 法務相談（案件）を探す 7 案件の検索 契約書・条文の検索 類似案件の推薦 類似契約書の推薦 • 契約書を探す
8. こんな課題ありませんか？
9. こんな課題ありませんか？ チーム外とのコミュニケーションがうまくいかない… 9 エンジニア「技術的な内容をわかってもらえない…」 非エンジニア「相手が何を話しているかわからない…」 複数チームが関わるプロジェクトがうまく進まない…
10. プロダクト開発 と コミュニケーション
11. 11 エンジニアと非エンジニアが協力して 1つのプロダクトをつくる 異なる職種間の コミュニケーションは必要不可欠
12. 12 エンジニア 他職種 自チーム 他チーム 職種・組織を超えてコミュニケーションをとる
13. 13 自分 他職種 自チーム 他チーム コンテキストが異なるため 思考や情報を正しく伝えるのが難しい
14. コミュニケーションが失敗すると 情報の非対称性がますます拡大 14
15. 組織のサイロ化 生産性の低下 プロジェクトの失敗 につながる 15
16. コミュニケーションが 失敗する要因
17. ミスコミュニケーション と ディスコミュニケーション
18. 2種類あるコミュニケーションの失敗 18 認識・情報量の違いによって伝達がうまくいかない ミスコミュニケーション そもそも伝達が行われていない・伝達の機会がない ディスコミュニケーション
19. 19 ミスコミュニケーションの例 検索エンジニア PdM ？？？ 検索結果は基本BM25でスコアリングして いますがNDCGを向上させるためにベクト ル埋め込みをANNしてからRRFしてリラン キングしますね
20. 20 ミスコミュニケーションの例 エンジニア ？？？ このアジェンダにコミットするためには、スコープをクリア にしつつ、イシューの本質をデコンストラクトし、ステーク ホルダー間でシナジーを最大化するオポチュニティをエンパ ワーメントしながら、パラダイムシフトをドライブするナレ ッジトランスファーが不可欠であり、そのためにはリーンか つアジャイルなアプローチでエビデンスベースのクイックウ ィンを積み上げることが、ゲームチェンジャーとなるキーサ クセスファクターだと考えています ？？？
21. 21 ディスコミュニケーションの例 他チーム 「何をしているのかわからない」 「どう話しかけていいかわからない」 「忙しそうだし話しかけるのをやめておこう」
22. コミュニケーションとは何か
23. 23 複雑なものはモデル化すると理解しやすい 計算機のモデル チューリングマシン 神経回路網のモデル ニューラルネットワーク 証券市場のモデル ブラックショールズ方程式 流体のモデル ナビエストークス方程式 モデルとは、現実を抽象化・簡略化したフレームワーク
24. 24 70年以上前に理論化され、 現代でも生き続けている コミュニケーション（通信）のモデルがある
25. 25 情報源 送信機 ノイズ 受信機 受信者 通信路 シャノン・ウィーバーモデル (1948) Shannon and Weaver Model of Communication： https://www.communicationtheory.org/shannon- and-weaver-model-of-communication/ メッセージ ≡
26. 26 情報源 送信機 ノイズ 受信機 受信者 通信路 シャノン・ウィーバーモデル (1948) Shannon and Weaver Model of Communication： https://www.communicationtheory.org/shannon- and-weaver-model-of-communication/ メッセージ ≡ シャノン・ウィーバーモデルでは コミュニケーションの双方向性を 表現できない
27. シャノン・ウィーバーモデルを 対話型に拡張 27
28. シュラムモデル (1954) 28 メッセージ フィードバック エンコーダー ↑ インタープリター ↑ デコーダー デコーダー ↓ インタープリター ↓ エンコーダー 発信者 受信者 ノイズ ノイズ
29. 「フィードバック」の要素が追加され 対話型・双方向のモデルに 29 メッセージ フィードバック エンコーダー ↑ インタープリター ↑ デコーダー デコーダー ↓ インタープリター ↓ エンコーダー 発信者 受信者 ノイズ ノイズ
30. エンコーダー ・通信には、メッセージという形式に変換（言語化）する必要がある ・情報をメッセージに符号化（エンコード）する デコーダー ・メッセージを復号化（デコード）し、情報を取り出す ・インタープリターに情報を渡す インタープリター ・情報を解釈 (interpret) し、意味を抽出する ・受け取った内容をもとに、相手に伝えたいことを考える ・エンコーダーを通して情報を送信する 30
31. シュラムモデル (1954) 31 メッセージ フィードバック エンコーダー ↑ インタープリター ↑ デコーダー デコーダー ↓ インタープリター ↓ エンコーダー 発信者 受信者 ノイズ ノイズ
32. シュラムモデル (1954) 32 メッセージ フィードバック エンコーダー ↑ インタープリター ↑ デコーダー デコーダー ↓ インタープリター ↓ エンコーダー 発信者 受信者 シュラムモデルをもとに ミスコミュニケーションの原因 を考えてみる
33. ミスコミュニケーションが起こる原因 33 メッセージ フィードバック エンコーダー ↑ インタープリター ↑ デコーダー デコーダー ↓ インタープリター ↓ エンコーダー 発信者 受信者 エンコードの失敗 ノイズ ノイズ 伝えたいことを適切なメッセージ にできていない
34. ミスコミュニケーションが起こる原因 34 メッセージ フィードバック エンコーダー ↑ インタープリター ↑ デコーダー デコーダー ↓ インタープリター ↓ エンコーダー 発信者 受信者 通信路上のノイズ ノイズ ノイズ 送信したメッセージが欠損する
35. ミスコミュニケーションが起こる原因 35 メッセージ フィードバック エンコーダー ↑ インタープリター ↑ デコーダー デコーダー ↓ インタープリター ↓ エンコーダー 発信者 受信者 デコード・解釈の失敗 ノイズ ノイズ 本来の意図が復元できていない
36. ちなみに、ディスコミュニケーションは そもそも送信者が情報を送っていない状態 36
37. コミュニケーションを どう改善するか
38. お互いのコンテキストの違いによって ミスコミュニケーションが起こる 38
39. 受信者のコンテキストを意識してエンコードする 39 エンコードの改善 デコードの改善 発信者のコンテキストを理解してもらう
40. 当社のプロダクト開発での コミュニケーションの課題
41. 課題 開発に関わる職種・チームが多い 41 特殊なドメイン知識が必要
42. 課題① 開発に関わる職種・チームが多い
43. 43 PdM EM デザイナー QA 弁護士 エンジニア 複数の製品開発チーム 多職種・多チームとの コミュニケーション
44. 44 PdM EM デザイナー QA 弁護士 エンジニア 複数の製品開発チーム 多職種・多チームとの コミュニケーション 多くの職種・チームが関わるため コンテキストの共有が困難
45. 課題② 特殊なドメイン知識が必要
46. リーガルテック＝馴染みがなく深いドメイン 46
47. リーガルテック＝馴染みがなく深いドメイン 47 より良い検索・推薦の体験を生み出すために 法務エキスパートの知見をプロダクトに 注入しなければならない
48. 実践したこと
49. 相手の役割・責任を理解する 49 他職種との会話を増やした ドメイン知識の学習 1 2 3 4 社内勉強会の開催
50. 相手の役割・責任を理解する 50 他職種との会話を増やした ドメイン知識の学習 1 2 3 4 社内勉強会の開催
51. 他職種とのコミュニケーションでは 相手のことを理解するのが最も重要 51
52. 参考にした書籍（一部） ・エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 James Stanier 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、竹葉 美沙 訳、 オライリー・ジャパン ・HIGH OUTPUT MANAGEMENT 人を育て、成果を最大にするマネジメント アンドリュー・S・グローブ (著) 小林 薫（訳）ベン・ホロウィッツ 序文 発行元：日経BP 52 プロダクトマネージャー（PdM） エンジニアリングマネージャー ・INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント マーティ・ケーガン (著)、日本能率協会マネジメントセンター ・プロダクトマネジメントのすべて 及川 卓也 (著), 曽根原 春樹 (著), 小城 久美子 (著)、株式会社翔泳社
53. 参考にした書籍（一部） ・エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 James Stanier 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、竹葉 美沙 訳、 オライリー・ジャパン ・HIGH OUTPUT MANAGEMENT 人を育て、成果を最大にするマネジメント アンドリュー・S・グローブ (著) 小林 薫（訳）ベン・ホロウィッツ 序文 発行元：日経BP 53 プロダクトマネージャー（PdM） エンジニアリングマネージャー ・INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント マーティ・ケーガン (著)、日本能率協会マネジメントセンター ・プロダクトマネジメントのすべて 及川 卓也 (著), 曽根原 春樹 (著), 小城 久美子 (著)、株式会社翔泳社 異なる職種の人たちの 行動原理・モチベーションが掴めてくる
54. 相手を理解することで、コミュニケーションを チューニング できる 「同じ視点」に立って考える 「同じ言葉」で会話する 54 発信のエンコード効率を高める
55. 相手の役割・責任を理解する 55 他職種との会話を増やした ドメイン知識の学習 1 2 3 4 社内勉強会の開催
56. リーガルテックでは 法律の知識や法務業務の理解が必要不可欠 56
57. 法令XMLデータのパーサー（解析器）を開発 法務には、法令やガイドラインを調べて 法務リスクを調査する「リサーチ業務」というものがある 57
58. 法令の基礎知識を学ぶ 58 1 『リーガル・リサーチ［第５版］』 (指宿 信、齊藤 正彰 監修 いしかわ まりこ、藤井 康子、村井 のり子 著) 株式会社 日本評論社
59. 59 法令のデータ構造について理解する ２ ブログにして公開：法律のデータ構造と検索 https://www.takuya-a.net/blog/data-structure-and-retrieval-of-law/
60. 60 法令データのパーサーを書いてOSSにして公開 ３ https://github.com/takuyaa/ja-law-parser
61. さらに、自社のプロダクトでも法務の基礎を学習 ユーザーに提供しているサービスを活用し、法務業務の基礎から学習 61 例： ・契約とは ・契約業務の全体像 ・法令の基本
62. さらに、自社のプロダクトでも法務の基礎を学習 ユーザーに提供しているサービスを活用し、法務業務の基礎から学習 62 例： ・契約とは ・契約業務の全体像 ・法令の基本 発信のエンコード効率を高める
63. 相手の役割・責任を理解する 63 他職種との会話を増やした ドメイン知識の学習 1 2 3 4 社内勉強会の開催
64. 自分の専門分野も知ってもらう ドメインを横断するチームであり、 専門性の高さもあるからこそ、知識の 共有が重要 社内勉強会のスライド・録画は社内で も広く共有 64 株式会社LegalOn Technologies テックブログ： https://tech.legalforce.co.jp/entry/introduction-to-search-and- recommender-systems-for-pdm
65. 技術を理解してもらうことでも コンテキストを揃える ことができる 65 受信のデコード効率を高められる 相手に合わせて情報を「あえて落とす」必要がなくなる 解像度の高い言葉で話しかけることができるように
66. 相手の役割・責任を理解する 66 他職種との会話を増やした ドメイン知識の学習 1 2 3 4 社内勉強会の開催
67. PdM やドメインエキスパートとの 会話を増やした 施策ごとに適宜会話し、曖昧なところを無くす 定例ミーティングで足並みをそろえる 67 通信の頻度を上げられる
68. 取り組みの結果
69. 取り組みの結果 69 １年で新製品「LegalOn Cloud」を開発・リリース さまざまなモジュールの検索・推薦の基本機能をカバーした 開発した検索・推薦基盤は、この製品のコアの１つとなっている
70. 70 検索・推薦の最適化のためのデータセット作成 「この検索・推薦結果が良いかどうか」を法務エキスパートが採点 作業のための仕組みを一緒に考え、エンジニアも伴走 ドメインエキスパートとの協働による 検索・推薦精度の改善①
71. 71 ドメイン知識をロジックに落とし込む データを一緒に見ながら対話的にヒアリング エンジニアがビジネスロジックに落とし込んでいく ドメインエキスパートとの協働による 検索・推薦精度の改善②
72. 72 リリース後も続々と新機能や改善をリリースしている ６つの職種・８つのチームと連携しながら開発を進められている 検索・推薦の精度改善にも一緒に取り組んでいる
73. まとめ
74. コミュニケーション改善のためにやったこと 74 情報のエンコード効率を上げる ・他職種を理解する努力 ・ドメイン知識を学び続ける 情報のデコード効率を上げる ・社内勉強会を開催し、知識を共有した 通信の頻度を上げる ・他職種・他チームと会話する機会を増やした
75. 共通の言語 で会話する 75 通信効率（ビットレート）を上げられる お互いに理解しあうことで、解像度の高い共通の言語での 会話が可能に（エンコード効率＆デコード効率アップ） ハイコンテキストで高密度の会話ができるようになる
76. 明日からできること 76
77. 明日からできること 他職種に関する本を読んでみる 77 非エンジニアや他チームと会話する機会をつくる プロダクトのドメイン知識を学んでみる
78. 株式会社LegalOn Technologies https://legalontech.jp/