Tweet
Tweet

Slide 1

Slide 1 text

製品開発と研究開発の協働 〜AI契約書レビューシステムLegalForceを作る組織設計論〜（後半） Developer eXperience Day 2021 株式会社LegalForce 最高研究開発責任者（CRO）舟木 類佳

Slide 2

Slide 2 text

⾈⽊ 類佳 株式会社LegalForce 執行役員 兼 最高研究開発責任者（CRO: Chief R&D Officer） 経歴： 元 東京大学情報理工学系研究科 中山英樹研究室（修士） 元 株式会社リクルート 出身：広島県→島根県 技術：Web開発、スマートフォン開発、ゲーム開発、 クラウドインフラ、自然言語処理、画像認識、機械学習等 趣味：ピアノ、ドラム、作曲 !SVLB@GVOBLJ

Slide 3

Slide 3 text

3 目次 • 研究開発組織（R&D）とは • 研究開発組織（R&D）設計について • 研究開発組織（R&D）の不確実性への対処

Slide 4

Slide 4 text

研究開発部門（R&D）とは

Slide 5

Slide 5 text

5 LegalForceの開発組織 • 各種サービスと連携し、ユーザーとのインターフェースを作るD&D（製品開発）部門 • 自然言語処理や機械学習等を駆使し、AIのコアロジックを作るR&D（研究開発）部門 • 弁護士が所属し、法務の専門知識をデータに落とし込むPD（法務開発）部門 • ユーザーヒアリングや数値分析を通して、製品の方向性を指し示すPdM（製品企画）部門 開発本部 D&D section R&D section PD section PdM section

Slide 6

Slide 6 text

6 ੡඼։ൃ෦໳ ݚڀ։ൃ෦໳ 8FCΞϓϦέʔγϣϯΛ։ൃ "*ͷίΞϩδοΫΛ։ൃ 2つの技術開発部門

Slide 7

Slide 7 text

7 LegalForceの研究開発 • 契約書言語処理を中心とした データに関わる要素技術の研究、 及び開発を実施 研究開発 Research & Development

Slide 8

Slide 8 text

8 自然言語処理

Slide 9

Slide 9 text

9 契約書データ

Slide 10

Slide 10 text

10

Slide 11

Slide 11 text

11 研究開発の４要素 アノテーション データエンジニアリング データプロダクト開発 研究 ・レビュー ・抽出 ・検索 ・校閲 ・構造化 などのAPI開発 アノテーションシステムの開発 アノテーション作業の支援 ・データ基盤 ・BIツール ・機械学習基盤 ・データパイプライン構築 ・データ活用の推進 機械学習 中長期の研究投資 論文執筆

Slide 12

Slide 12 text

12

Slide 13

Slide 13 text

13

Slide 14

Slide 14 text

14 製品開発と研究開発の関係 • 研究開発がAPI（言語処理、AIロジック等）を開発し、 製品開発側が呼び出す形式 製品開発 研究開発 ユーザー マイクロ サービス ブラウザ Webアプリ

Slide 15

Slide 15 text

15 LegalForce R&D Zoo AIや契約書言語処理などに代表される LegalForceの研究開発技術を、 動物と紐付けて紹介

Slide 16

Slide 16 text

16 検索 テキスト構造化 テキスト分類 レビュー データ変換 条文検索 文書構造解析 文書分類 検査 PDF変換 Word変換 条ラベリング 文分割 類似文書推薦 差分比較 OCR 言語認識 文書検索 情報抽出 権利義務抽出 LegalForce R&D Zoo（1/2） 条アラインメント 情報抽出 表情報抽出 比較 改行位置予測 編集支援 校閲 ライティング支援 ファイルクローラー クローラー

Slide 17

Slide 17 text

17 LegalForce R&D Zoo（2/2） データ基盤 契約書アノテーション基盤 評価基盤 データ基盤 データパイプライン アプリケーション基盤 機械学習基盤 機械学習基盤 アプリケーション基盤 検索基盤 アノテーション基盤 可視化 汎用アノテーション基盤 検索基盤 契約書匿名化 契約書匿名化 オントロジー オントロジー データカタログ

Slide 18

Slide 18 text

研究開発部門（R&D）の組織設計

Slide 19

Slide 19 text

19 他社の研究開発エンジニアの悩みを聞く • A社：機械学習をできるのはいいけれど製品になかなか導入されない • B社：入社して機械学習ができると思ったらiOSをやっている • C社：研究開発に予算がつきにくく、GPU計算できない 研究開発組織をどのように設計するか？

Slide 20

Slide 20 text

21 LegalForceはAIを中心とした自社サービス開発会社 • AI開発の企業は大きく分けて２パターン ⁃ 受託企業 ⁃ 自社サービス企業 • LegalForceはAI技術を中心とした自社サービスを提供している会社 • AIを製品に組み込まなければいけない AI受託企業 AI自社サービス開発企業

Slide 21

Slide 21 text

22 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール 検索等 開発寄りなもの データ領域のAPI群 機械学習を使わないAI

Slide 22

Slide 22 text

23 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの

Slide 23

Slide 23 text

24 研究開発の組織設計パターン ①APIまで提供する（データプロダクト開発パターン） ②検索以外のAPIまで提供する（AIプロダクト開発限定パターン） ③機械学習のAPIまで提供する（MLプロダクト開発限定パターン） ④APIは提供せず、プロトタイピングのみ行う （プロトタイピング限定パターン） ⑤論文執筆やツール開発に専念（リサーチ専念パターン） ⑥AI開発者を製品開発に派遣する（派遣パターン） ⑦ AI開発者はコンサルのみ行う（コンサルパターン）

Slide 24

Slide 24 text

25 研究開発の組織設計パターン ①APIまで提供する（データプロダクト開発パターン） ②検索以外のAPIまで提供する（AIプロダクト開発限定パターン） ③機械学習のAPIまで提供する（MLプロダクト開発限定パターン） ④APIは提供せず、プロトタイピングのみ行う （プロトタイピング限定パターン） ⑤論文執筆やツール開発に専念（リサーチ専念パターン） ⑥AI開発者を製品開発に派遣する（派遣パターン） ⑦ AI開発者はコンサルのみ行う（コンサルパターン） アンチパターンはない認識。 会社の状況に応じて選択する。

Slide 25

Slide 25 text

26 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの どのように選択するか？

Slide 26

Slide 26 text

27 研究開発部門を設計する上での８つの観点 A：デリバリー面 B：技術マネジメント面 C：機械学習エンジニアのフォーカス面 D：製品開発とのコミュニケーション面 E：精度改善面 F：精度改善面 G：ブランディング面 H：アイディア創出面

Slide 27

Slide 27 text

28 A：デリバリー面 • 機械学習やAIのプログラムを書いただけだと製品に導入は難しい • バックエンドのエンジニアに機械学習やAIのコードを丸投げすれば 導入されるかというとそうではない • プロダクションコードまで責任を持つのか？といった 「どこまで責任を持つのか」が重要

Slide 28

Slide 28 text

29 B：技術マネジメント面 • AI開発は通常の開発と違い、特殊な部分が多い • AI開発やデータサイエンスならではの知識・ノウハウを共有したい ⁃ AI開発における開発サイクル ⁃ 機械学習用のデータのアノテーション ⁃ 技術選定

Slide 29

Slide 29 text

30 C：機械学習エンジニアのフォーカス面 • 機械学習エンジニアはWeb開発ができるとは限らない • 機械学習エンジニアは機械学習にフォーカスしたい • 機械学習エンジニアに特化したエンジニアを 別の仕事に駆り出すのももったいない

Slide 30

Slide 30 text

31 D：製品開発とのコミュニケーション面 • 製品開発とAI開発者の コミュニケーションが垣根なく円滑にできるか • AIも製品に組み込まれるものではあるので情報格差が起きないように したい • ビジネス領域の知識がなければAI開発は難航する

Slide 31

Slide 31 text

32 E：精度改善面 • 検索やAI、機械学習では精度改善が求められる • 精度改善をサポートする仕組み（モニタリング、ABテスト等）をまと めて提供できると便利

Slide 32

Slide 32 text

33 F：予算面 • 長期研究開発のみだとお金に直結しないので、 予算を制限されてしまう • GPUによる高い機械学習計算リソースは制限される • 少ない人数に制限されてしまう

Slide 33

Slide 33 text

34 G：ブランディング面 • 強い研究開発エンジニアの採用につなげたい • AI開発・研究開発に強い会社だと世間に知ってもらいたい • AI開発・研究開発に注力していることを強調できるか？

Slide 34

Slide 34 text

35 H：アイディア創出面 • 製品の開発ばかりに専念していると、 斬新なアイディアが生み出されなくなってしまうかもしれない • ニーズベース、シーズベース両方からのアイディアが形にできるか？

Slide 35

Slide 35 text

36 研究開発部門を設計する上での８つの観点 A：デリバリー面 B：技術マネジメント面 C：機械学習エンジニアのフォーカス面 D：製品開発とのコミュニケーション面 E：精度改善面 F：精度改善面 G：ブランディング面 H：アイディア創出面

Slide 36

Slide 36 text

37 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ①データプロダクト開発パターン ②AIプロダクト開発限定パターン ③MLプロダクト開発限定パターン ④プロトタイピング限定パターン ⑤リサーチ専念パターン ⑥派遣パターン ⑦コンサルパターン ⑥ ⑦ 検索等 開発寄りなもの

Slide 37

Slide 37 text

38 研究開発はどこまで担う？〜①データプロダクト開発パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI A: APIまで責任を持つことで 導入されやすい B: AIの技術マネジメントはしやすい C: 機械学習だけには専念できない D: コミュニケーション面は一部犠牲になる E: 精度改善はまとめて行いやすい ⑥ ⑦ 検索等 開発寄りなもの ○ △ ☓ 色の意味

Slide 38

Slide 38 text

39 研究開発はどこまで担う？〜②AIプロダクト開発パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ A: APIまで責任を持つことで 導入されやすい B: AIの技術マネジメントはしやすいが検 索等が外れる C: 機械学習だけには専念できない D: コミュニケーション面は一部犠牲になる E: 検索等が精度改善の対象から外れる 検索等 開発寄りなもの ○ △ ☓ 色の意味

Slide 39

Slide 39 text

40 研究開発はどこまで担う？〜③MLプロダクト開発限定パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ A: APIまで責任を持つことで 導入されやすい B: MLの技術マネジメントはしやすいがAI 全体でのサポートが難しい C: 機械学習にある程度は専念できる D: コミュニケーション面は一部犠牲になる E: MLに依存しないものが精度改善の対 象から外れる 検索等 開発寄りなもの ○ △ ☓ 色の意味

Slide 40

Slide 40 text

41 研究開発はどこまで担う？〜④プロトタイピング限定パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入されにくい（引き継ぎが必要） B: AI全体でのサポートが難しい C: 機械学習に専念できる D: コミュニケーション面は一部犠牲になる E: 一箇所に固まっているため精度改善は まとめてできる ○ △ ☓ 色の意味

Slide 41

Slide 41 text

42 研究開発はどこまで担う？〜⑤リサーチ専念パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入されにくい（論文→プロダクトにい かない） B: AI全体でのサポートが難しい C: 機械学習に専念できる D: コミュニケーション面は問題ない E: 一箇所に固まっているため精度改善は まとめてできる ○ △ ☓ 色の意味

Slide 42

Slide 42 text

43 研究開発はどこまで担う？〜⑥派遣パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入はしやすい B: 組織を横断するために指示系統が複 雑化 C: 様々なコンテキスト情報が入ってくる D: コミュニケーション面は問題ない E: 一箇所に固まっているため精度改善は まとめてできる ○ △ ☓ 色の意味

Slide 43

Slide 43 text

44 研究開発はどこまで担う？〜⑦コンサルパターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入までなかなか至らない B: AI全体でのサポートが難しい C: 機械学習に専念できる人もいる？ D: コミュニケーションの隔たりができる E: 一箇所に固まっているため精度改善は まとめてできる ○ △ ☓ 色の意味

Slide 44

Slide 44 text

45 LegalForceでは①データプロダクト開発パターンを選択 フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① データ領域のAPI群 機械学習を使わないAI A: APIまで責任を持つことで 導入されやすい B: AIの技術マネジメントはしやすい C: 機械学習だけには専念できない D: コミュニケーション面は一部犠牲になる E: 精度改善はまとめて行いやすい 検索等 開発寄りなもの LegalForceでは ①を選択したが一長一短。 会社の状況に応じて 選択するのが良い。 ○ △ ☓ 色の意味

Slide 45

Slide 45 text

研究開発組織（R&D）の不確実性への対処

Slide 46

Slide 46 text

49 不確実性 • 開発が進んでみないと 先はわからない • 進んでみて初めて分かる ことも多い • 特に研究開発部門での AI開発等は不確実性が 高い事が多い

Slide 47

Slide 47 text

50 開発における不確実性の種類 「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織 のリファクタリング」広木 大地 著（技術評論社、2018/2/22発売） 不確実性 方法不確実 性 目的不確実 性 通信不確実 性

Slide 48

Slide 48 text

51 LegalForceの研究開発部門の これまでの方針 • 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない

Slide 49

Slide 49 text

立ち上げ（0→1）

Slide 50

Slide 50 text

53 LegalForceの研究開発部門の これまでの方針 • 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない

Slide 51

Slide 51 text

54 推測するな、計測せよ • 開発初期で全てを推測は困難 • 研究開発では特に不確実性が高い • まずは小さく作って、計測していく方向

Slide 52

Slide 52 text

55 不確実性を下げるための開発 • 実際に使ってみてもらわないと受け入れられるかわからない • まずはDEMOを開発して実際に使ってもらう • 雑でもよいので画面まで作る ヒアリング 仮説構築 DEMO開発 仮説検証 ビジネス化検討 API開発 ビジネス化

Slide 53

Slide 53 text

技術選定

Slide 54

Slide 54 text

57 LegalForceの研究開発部門の これまでの方針 • 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない

Slide 55

Slide 55 text

58 LegalForceの 利用技術

Slide 56

Slide 56 text

59 技術選定の流れの例 開始 機械学習を 利用？ DBを 利用？ Yes No Ruby / Sinatra No Ruby / Rails (Hanami) Yes Python / Flask (Fast API) 低負荷？ Yes No Ruby / Lambda

Slide 57

Slide 57 text

60 Ruby on RailsやSinatra、Flask等が 不確実性の高い研究開発に向いている理由 • 素早くプロトタイピングしたり、 素早くWebアプリ/WebAPIを立ち上げたりがしやすい • 特にRuby on Railsはrails generateコマンド等で 素早く立ち上げ可能 • 立ち上げが早ければ早期に失敗できる Sinatra

Slide 58

Slide 58 text

改善（1→100）

Slide 59

Slide 59 text

62 LegalForceの研究開発部門の これまでの方針 • 立ち上げ ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善 ⁃ 作り直し・大規模改修は躊躇しない

Slide 60

Slide 60 text

63 LegalForceの変遷 • たくさんのバージョンが存在する Version1 Version2 Version3 Version4 Version1 Version2 Version3 Version4 Version1 Version2 Version3 契約書レビュー 契約書構造解析 精度評価システム 2018年5月 NOW（2020年4月） Version 3.1 Version 3.2 Version 3.3 Version 2.1 アノテーション システム Version1 Version2

Slide 61

Slide 61 text

64 大規模な作り直し・大規模改修を躊躇なく実施 • 大規模な作り直し・大規模改修を躊躇なく実施 • 作り直しや大規模改修の理由は様々 • 小さく作っているので、作り直しの負荷は少なめ（大変だが・・・） • 負債解消につながったり、トレンドに合わせた技術選定がしやすい Version1 Version2 Version3 Version4 契約書レビュー 2018年5月 現在（2020年4月） Version 3.1 Version 3.2 Version 3.3 負荷対策 精度改善 負荷対策 精度改善 安定化 新規開発 作り直し 作り直し 大規模改修 作り直し スケール

Slide 62

Slide 62 text

65 これまでの開発を通して感じていること • 先が見えない状態から先が開けた状態へ ⁃ 開発を進めて、作り上げて初めて新しい景色が見える ⁃ 大体、開発を始めたタイミングでは想像しなかった問題が現れる 進捗 先が見えない状態 先が開けた状態 次のチャレンジへ

Slide 63

Slide 63 text

66 まとめ • 研究開発組織（R&D）とは • 研究開発組織（R&D）設計について ⁃ AIのAPIまで開発するスタイル • 研究開発流の不確実性への対処 ⁃ 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する ⁃ 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める ⁃ 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない

Slide 64

Slide 64 text

67 現在エンジニア・マネージャー・ テックリード等を全力採用中！！ 是非お気軽にご連絡下さい！！ !SVLB@GVOBLJ ↓Twitterフォロー＆ DMでもお気軽にご連絡下さい エンジニアリングマネージャー プロダクトオーナー Webリードエンジニア フロントエンドエンジニア Rubyエンジニア Pythonエンジニア 検索エンジニア データアナリスト データ基盤エンジニア SRE クラウドインフラエンジニア リサーチエンジニア セキュリティエンジニア 募集職種