製品開発と研究開発の協働 〜AI契約書レビューシステムLegalForceを作る組織設計論〜（後半）

Developer eXperience Day 2021にて、LegalForceにおける組織設計論をCTO時武とCRO舟木から発表したセッションの資料です。
こちらはCRO舟木から発表した後半部分の資料となります。

Transcript

1. 製品開発と研究開発の協働 〜AI契約書レビューシステムLegalForceを作る組織設計論〜（後半） Developer eXperience Day 2021 株式会社LegalForce 最高研究開発責任者（CRO）舟木 類佳
2. ⾈⽊ 類佳 株式会社LegalForce 執行役員 兼 最高研究開発責任者（CRO: Chief R&D Officer） 経歴： 元 東京大学情報理工学系研究科 中山英樹研究室（修士） 元 株式会社リクルート 出身：広島県→島根県 技術：Web開発、スマートフォン開発、ゲーム開発、 クラウドインフラ、自然言語処理、画像認識、機械学習等 趣味：ピアノ、ドラム、作曲 !SVLB@GVOBLJ
3. 3 目次 • 研究開発組織（R&D）とは • 研究開発組織（R&D）設計について • 研究開発組織（R&D）の不確実性への対処
4. 研究開発部門（R&D）とは
5. 5 LegalForceの開発組織 • 各種サービスと連携し、ユーザーとのインターフェースを作るD&D（製品開発）部門 • 自然言語処理や機械学習等を駆使し、AIのコアロジックを作るR&D（研究開発）部門 • 弁護士が所属し、法務の専門知識をデータに落とし込むPD（法務開発）部門 • ユーザーヒアリングや数値分析を通して、製品の方向性を指し示すPdM（製品企画）部門 開発本部 D&D section R&D section PD section PdM section
6. 6 ੡඼։ൃ෦໳ ݚڀ։ൃ෦໳ 8FCΞϓϦέʔγϣϯΛ։ൃ "*ͷίΞϩδοΫΛ։ൃ 2つの技術開発部門
7. 7 LegalForceの研究開発 • 契約書言語処理を中心とした データに関わる要素技術の研究、 及び開発を実施 研究開発 Research & Development
8. 8 自然言語処理
9. 9 契約書データ
11. 11 研究開発の４要素 アノテーション データエンジニアリング データプロダクト開発 研究 ・レビュー ・抽出 ・検索 ・校閲 ・構造化 などのAPI開発 アノテーションシステムの開発 アノテーション作業の支援 ・データ基盤 ・BIツール ・機械学習基盤 ・データパイプライン構築 ・データ活用の推進 機械学習 中長期の研究投資 論文執筆
14. 14 製品開発と研究開発の関係 • 研究開発がAPI（言語処理、AIロジック等）を開発し、 製品開発側が呼び出す形式 製品開発 研究開発 ユーザー マイクロ サービス ブラウザ Webアプリ
15. 15 LegalForce R&D Zoo AIや契約書言語処理などに代表される LegalForceの研究開発技術を、 動物と紐付けて紹介
16. 16 検索 テキスト構造化 テキスト分類 レビュー データ変換 条文検索 文書構造解析 文書分類 検査 PDF変換 Word変換 条ラベリング 文分割 類似文書推薦 差分比較 OCR 言語認識 文書検索 情報抽出 権利義務抽出 LegalForce R&D Zoo（1/2） 条アラインメント 情報抽出 表情報抽出 比較 改行位置予測 編集支援 校閲 ライティング支援 ファイルクローラー クローラー
17. 17 LegalForce R&D Zoo（2/2） データ基盤 契約書アノテーション基盤 評価基盤 データ基盤 データパイプライン アプリケーション基盤 機械学習基盤 機械学習基盤 アプリケーション基盤 検索基盤 アノテーション基盤 可視化 汎用アノテーション基盤 検索基盤 契約書匿名化 契約書匿名化 オントロジー オントロジー データカタログ
18. 研究開発部門（R&D）の組織設計
19. 19 他社の研究開発エンジニアの悩みを聞く • A社：機械学習をできるのはいいけれど製品になかなか導入されない • B社：入社して機械学習ができると思ったらiOSをやっている • C社：研究開発に予算がつきにくく、GPU計算できない 研究開発組織をどのように設計するか？
20. 21 LegalForceはAIを中心とした自社サービス開発会社 • AI開発の企業は大きく分けて２パターン ⁃ 受託企業 ⁃ 自社サービス企業 • LegalForceはAI技術を中心とした自社サービスを提供している会社 • AIを製品に組み込まなければいけない AI受託企業 AI自社サービス開発企業
21. 22 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール 検索等 開発寄りなもの データ領域のAPI群 機械学習を使わないAI
22. 23 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの
23. 24 研究開発の組織設計パターン ①APIまで提供する（データプロダクト開発パターン） ②検索以外のAPIまで提供する（AIプロダクト開発限定パターン） ③機械学習のAPIまで提供する（MLプロダクト開発限定パターン） ④APIは提供せず、プロトタイピングのみ行う （プロトタイピング限定パターン） ⑤論文執筆やツール開発に専念（リサーチ専念パターン） ⑥AI開発者を製品開発に派遣する（派遣パターン） ⑦ AI開発者はコンサルのみ行う（コンサルパターン）
24. 25 研究開発の組織設計パターン ①APIまで提供する（データプロダクト開発パターン） ②検索以外のAPIまで提供する（AIプロダクト開発限定パターン） ③機械学習のAPIまで提供する（MLプロダクト開発限定パターン） ④APIは提供せず、プロトタイピングのみ行う （プロトタイピング限定パターン） ⑤論文執筆やツール開発に専念（リサーチ専念パターン） ⑥AI開発者を製品開発に派遣する（派遣パターン） ⑦ AI開発者はコンサルのみ行う（コンサルパターン） アンチパターンはない認識。 会社の状況に応じて選択する。
25. 26 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの どのように選択するか？
26. 27 研究開発部門を設計する上での８つの観点 A：デリバリー面 B：技術マネジメント面 C：機械学習エンジニアのフォーカス面 D：製品開発とのコミュニケーション面 E：精度改善面 F：精度改善面 G：ブランディング面 H：アイディア創出面
27. 28 A：デリバリー面 • 機械学習やAIのプログラムを書いただけだと製品に導入は難しい • バックエンドのエンジニアに機械学習やAIのコードを丸投げすれば 導入されるかというとそうではない • プロダクションコードまで責任を持つのか？といった 「どこまで責任を持つのか」が重要
28. 29 B：技術マネジメント面 • AI開発は通常の開発と違い、特殊な部分が多い • AI開発やデータサイエンスならではの知識・ノウハウを共有したい ⁃ AI開発における開発サイクル ⁃ 機械学習用のデータのアノテーション ⁃ 技術選定
29. 30 C：機械学習エンジニアのフォーカス面 • 機械学習エンジニアはWeb開発ができるとは限らない • 機械学習エンジニアは機械学習にフォーカスしたい • 機械学習エンジニアに特化したエンジニアを 別の仕事に駆り出すのももったいない
30. 31 D：製品開発とのコミュニケーション面 • 製品開発とAI開発者の コミュニケーションが垣根なく円滑にできるか • AIも製品に組み込まれるものではあるので情報格差が起きないように したい • ビジネス領域の知識がなければAI開発は難航する
31. 32 E：精度改善面 • 検索やAI、機械学習では精度改善が求められる • 精度改善をサポートする仕組み（モニタリング、ABテスト等）をまと めて提供できると便利
32. 33 F：予算面 • 長期研究開発のみだとお金に直結しないので、 予算を制限されてしまう • GPUによる高い機械学習計算リソースは制限される • 少ない人数に制限されてしまう
33. 34 G：ブランディング面 • 強い研究開発エンジニアの採用につなげたい • AI開発・研究開発に強い会社だと世間に知ってもらいたい • AI開発・研究開発に注力していることを強調できるか？
34. 35 H：アイディア創出面 • 製品の開発ばかりに専念していると、 斬新なアイディアが生み出されなくなってしまうかもしれない • ニーズベース、シーズベース両方からのアイディアが形にできるか？
35. 36 研究開発部門を設計する上での８つの観点 A：デリバリー面 B：技術マネジメント面 C：機械学習エンジニアのフォーカス面 D：製品開発とのコミュニケーション面 E：精度改善面 F：精度改善面 G：ブランディング面 H：アイディア創出面
36. 37 研究開発はどこまで担う？ フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ①データプロダクト開発パターン ②AIプロダクト開発限定パターン ③MLプロダクト開発限定パターン ④プロトタイピング限定パターン ⑤リサーチ専念パターン ⑥派遣パターン ⑦コンサルパターン ⑥ ⑦ 検索等 開発寄りなもの
37. 38 研究開発はどこまで担う？〜①データプロダクト開発パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI A: APIまで責任を持つことで 導入されやすい B: AIの技術マネジメントはしやすい C: 機械学習だけには専念できない D: コミュニケーション面は一部犠牲になる E: 精度改善はまとめて行いやすい ⑥ ⑦ 検索等 開発寄りなもの ◦ △ ☓ 色の意味
38. 39 研究開発はどこまで担う？〜②AIプロダクト開発パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ A: APIまで責任を持つことで 導入されやすい B: AIの技術マネジメントはしやすいが検 索等が外れる C: 機械学習だけには専念できない D: コミュニケーション面は一部犠牲になる E: 検索等が精度改善の対象から外れる 検索等 開発寄りなもの ◦ △ ☓ 色の意味
39. 40 研究開発はどこまで担う？〜③MLプロダクト開発限定パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ A: APIまで責任を持つことで 導入されやすい B: MLの技術マネジメントはしやすいがAI 全体でのサポートが難しい C: 機械学習にある程度は専念できる D: コミュニケーション面は一部犠牲になる E: MLに依存しないものが精度改善の対 象から外れる 検索等 開発寄りなもの ◦ △ ☓ 色の意味
40. 41 研究開発はどこまで担う？〜④プロトタイピング限定パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入されにくい（引き継ぎが必要） B: AI全体でのサポートが難しい C: 機械学習に専念できる D: コミュニケーション面は一部犠牲になる E: 一箇所に固まっているため精度改善は まとめてできる ◦ △ ☓ 色の意味
41. 42 研究開発はどこまで担う？〜⑤リサーチ専念パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入されにくい（論文→プロダクトにい かない） B: AI全体でのサポートが難しい C: 機械学習に専念できる D: コミュニケーション面は問題ない E: 一箇所に固まっているため精度改善は まとめてできる ◦ △ ☓ 色の意味
42. 43 研究開発はどこまで担う？〜⑥派遣パターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入はしやすい B: 組織を横断するために指示系統が複 雑化 C: 様々なコンテキスト情報が入ってくる D: コミュニケーション面は問題ない E: 一箇所に固まっているため精度改善は まとめてできる ◦ △ ☓ 色の意味
43. 44 研究開発はどこまで担う？〜⑦コンサルパターン フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① ② ③④ ⑤ データ領域のAPI群 機械学習を使わないAI ⑥ ⑦ 検索等 開発寄りなもの A: 導入までなかなか至らない B: AI全体でのサポートが難しい C: 機械学習に専念できる人もいる？ D: コミュニケーションの隔たりができる E: 一箇所に固まっているため精度改善は まとめてできる ◦ △ ☓ 色の意味
44. 45 LegalForceでは①データプロダクト開発パターンを選択 フロント エンド バック エンド 機械学習AI 論文 プロトタイピング OSS・ツール ① データ領域のAPI群 機械学習を使わないAI A: APIまで責任を持つことで 導入されやすい B: AIの技術マネジメントはしやすい C: 機械学習だけには専念できない D: コミュニケーション面は一部犠牲になる E: 精度改善はまとめて行いやすい 検索等 開発寄りなもの LegalForceでは ①を選択したが一長一短。 会社の状況に応じて 選択するのが良い。 ◦ △ ☓ 色の意味
45. 研究開発組織（R&D）の不確実性への対処
46. 49 不確実性 • 開発が進んでみないと 先はわからない • 進んでみて初めて分かる ことも多い • 特に研究開発部門での AI開発等は不確実性が 高い事が多い
47. 50 開発における不確実性の種類 「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織 のリファクタリング」広木 大地 著（技術評論社、2018/2/22発売） 不確実性 方法不確実 性 目的不確実 性 通信不確実 性
48. 51 LegalForceの研究開発部門の これまでの方針 • 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない
49. 立ち上げ（0→1）
50. 53 LegalForceの研究開発部門の これまでの方針 • 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない
51. 54 推測するな、計測せよ • 開発初期で全てを推測は困難 • 研究開発では特に不確実性が高い • まずは小さく作って、計測していく方向
52. 55 不確実性を下げるための開発 • 実際に使ってみてもらわないと受け入れられるかわからない • まずはDEMOを開発して実際に使ってもらう • 雑でもよいので画面まで作る ヒアリング 仮説構築 DEMO開発 仮説検証 ビジネス化検討 API開発 ビジネス化
53. 技術選定
54. 57 LegalForceの研究開発部門の これまでの方針 • 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない
55. 58 LegalForceの 利用技術
56. 59 技術選定の流れの例 開始 機械学習を 利用？ DBを 利用？ Yes No Ruby / Sinatra No Ruby / Rails (Hanami) Yes Python / Flask (Fast API) 低負荷？ Yes No Ruby / Lambda
57. 60 Ruby on RailsやSinatra、Flask等が 不確実性の高い研究開発に向いている理由 • 素早くプロトタイピングしたり、 素早くWebアプリ/WebAPIを立ち上げたりがしやすい • 特にRuby on Railsはrails generateコマンド等で 素早く立ち上げ可能 • 立ち上げが早ければ早期に失敗できる Sinatra
58. 改善（1→100）
59. 62 LegalForceの研究開発部門の これまでの方針 • 立ち上げ ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する • 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める • 改善 ⁃ 作り直し・大規模改修は躊躇しない
60. 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
61. 64 大規模な作り直し・大規模改修を躊躇なく実施 • 大規模な作り直し・大規模改修を躊躇なく実施 • 作り直しや大規模改修の理由は様々 • 小さく作っているので、作り直しの負荷は少なめ（大変だが・・・） • 負債解消につながったり、トレンドに合わせた技術選定がしやすい Version1 Version2 Version3 Version4 契約書レビュー 2018年5月 現在（2020年4月） Version 3.1 Version 3.2 Version 3.3 負荷対策 精度改善 負荷対策 精度改善 安定化 新規開発 作り直し 作り直し 大規模改修 作り直し スケール
62. 65 これまでの開発を通して感じていること • 先が見えない状態から先が開けた状態へ ⁃ 開発を進めて、作り上げて初めて新しい景色が見える ⁃ 大体、開発を始めたタイミングでは想像しなかった問題が現れる 進捗 先が見えない状態 先が開けた状態 次のチャレンジへ
63. 66 まとめ • 研究開発組織（R&D）とは • 研究開発組織（R&D）設計について ⁃ AIのAPIまで開発するスタイル • 研究開発流の不確実性への対処 ⁃ 立ち上げ（0→1） ⁃ マイクロサービスとして小さく作る ⁃ 初期段階から時間をかけすぎない ⁃ 見える範囲、時間をかけすぎない範囲内で工夫する ⁃ 技術選定 ⁃ ある程度の方針を立てる （「基本はRuby」「機械学習などはPython」等） ⁃ 臨機応変に状況に応じた技術選定の自由を認める ⁃ 改善（1→100） ⁃ 作り直し・大規模改修は躊躇しない
64. 67 現在エンジニア・マネージャー・ テックリード等を全力採用中！！ 是非お気軽にご連絡下さい！！ !SVLB@GVOBLJ ↓Twitterフォロー＆ DMでもお気軽にご連絡下さい エンジニアリングマネージャー プロダクトオーナー Webリードエンジニア フロントエンドエンジニア Rubyエンジニア Pythonエンジニア 検索エンジニア データアナリスト データ基盤エンジニア SRE クラウドインフラエンジニア リサーチエンジニア セキュリティエンジニア 募集職種