製品開発と研究開発の協働 〜AI契約書レビューシステムLegalForceを作る組織設計論〜（前半） Developer eXperience Day 2021 株式会社LegalForce 最⾼技術責任者（CTO）時武 佑太

2 登壇者について 時武 佑太 株式会社LegalForce 取締役CTO େֶ࣌୅Πϯλʔϯͱͯ͠RubyͰ͍͔ͭ͘ͷWebαʔϏε։ൃΛܦݧɻ 2016೥4݄ɺDeNAʹೖࣾ͠εϚϗΞϓϦͷ։ൃʹैࣄɻ LegalForce୅දͷ֯ాɾখּݪʹڞײ͠ɺ2017೥9݄͔Βݱ৬ɻ 2019೥11݄ɺCTO of the year 2019ड৆ɻ !UPLJDIJFUP

デュアルトラックアジャイルを導⼊して地雷を踏んだ話

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

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

6 D&Dのミッション ユーザーが安⼼して使えるプロダクトをつくる Make our products safe, simple and user-friendly.

7 D&Dのプリンシプル（⾏動指針） 「1つ1つの積み重ねが最⾼をつくる」 銀の弾丸なんてない。⽬の前の1つ1つを、明確な判断基準を持ってこなしていく。その積み重ねの先に、ようやく最⾼の品質が ⼿に⼊る。 「1⼈でつくらない」 1⼈でつくらないためには何が必要か？隣の⼈に敬意を払う、情報の透明性を⾼くする。1⼈でつくれるような⼩さいプロダクト を、私たちはつくろうとはしていない。 「NO BORDER」 職種・⽴場を、ちょっとだけはみ出た仕事をしよう。⾃分の軸を保ちつつ、⼿段には囚われない。考えるべきは、One Mission の実現に必要なこと。 「誰のためのプロダクト？」 その努⼒が、ユーザーの価値に繋がるかを顧みよう。⾃⼰満⾜に陥らず、都合の良いユーザー像に⽢えず、熱意を私たちのユー ザーに届けよう。

開発フロー、どんな感じでやってますか？

9 LegalForceのロードマップ検討会でよく使われていた図 4⽉ 5⽉ 6⽉ 機能A 機能B 機能C 機能D

10 LegalForceのロードマップ検討会 4⽉ 5⽉ 6⽉ 機能A 機能B 機能C んー、それぞれ最低でも2ヶ⽉はほしいですね （正直技術調査しないとわからん…） 今季はA, B, C, Dを⼊れたいんだ けどどれくらいで開発できる？ 機能D プロダクトマネージャ 開発者

11 当時の開発フロー • 四半期に1回のペースでロードマップを棚卸し ⁃ エンジニアがその場でかなり粗々な⾒積もりを⾏う • 棚卸したロードマップに沿って開発者をアサイン → アサイン後、技術調査・影響範囲調査を始める → 想定よりずっと影響範囲が⼤きいことが分かる → ⾒積もりをやり直した結果ロードマップが崩壊

12 実際は開発したい機能は溢れるほどたくさん… 4⽉ 5⽉ 6⽉ 機能A 機能B 機能C やりたいことリスト 機能E 機能F 改善A 改善B 改善C 改善D … 機能D

13 開発フローがうまく回っていなかった原因 • エンジニアがユーザーストーリーの仮説検証段階で⼗分に関与できてい なかった • 技術調査・影響範囲調査が曖昧なまま⾒積もりを強いられ、ほとんど有 効な⾒積もりが⾏えていなかった そこで試したのが…

デュアルトラックアジャイルの導⼊

15 デュアルトラックアジャイル • 開発フローを2つのフェーズに分け、それぞれで独⽴して開発サイクルを 回していく ⁃ 仮説検証を⾏うDiscoveryフェーズ ⁃ 仕様策定等の設計から実装、リリースまでを⾏うDeliveryフェーズ 事業⽬標設 定 課題発掘 ストーリー 明確化 仮説検証 妥当性検証 仕様策定 デザイン 設計 実装 検証 リリース ユーザー認 知 Discovery Delivery

はじめはうまくいくように思えたが…

17 デュアルトラックアジャイル導⼊後の課題 • バックログを別ボードで管理したことで棚卸しが煩雑化した • エンジニアはDeliveryに追われがちで、Discoveryボードまで⾒ることが できなくなっていった Discoveryボード Deliveryボード

18 デュアルトラックアジャイル導⼊後の課題 • 結果、エンジニアがDiscoveryサイクルに⼗分⼊れなかった • プロダクトマネージャーとデザイナーがDiscoveryメイン、エンジニアが Deliveryメインという実質的な分業制になってしまった 事業⽬標設 定 課題発掘 ストーリー 明確化 仮説検証 妥当性検証 仕様策定 デザイン 設計 実装 検証 リリース ユーザー認 知 Discovery Delivery

19 LegalForceの開発組織図 開発本部 D&D Section R&D Section PdM Section PD Section LegalForce Unit Cabinet Unit LegalForce Unit Cabinet Unit • D&D、R&D、PdMの同じ製品担当者が、プロジェクト単位で集まって開 発を推進

20 LegalForceの開発組織図 開発本部 D&D Section R&D Section PdM Section PD Section LegalForce Unit Cabinet Unit LegalForce Unit Cabinet Unit • ユーザーストーリーや仕様に関する議論は、それぞれの担当部署のリー ダー間で⾏われることが多く、中央集権的だった

21 LegalForceの開発組織図 開発本部 D&D Section R&D Section PdM Section PD Section LegalForce Unit Cabinet Unit LegalForce Unit Cabinet Unit • 結果的にメンバーからは「受託開発感がある」「組織を跨いだメンバー 間コミュニケーションが薄い」という課題の声が上がっていた

そして組織の再編へ

23 feature型マトリクス組織への移⾏ LegalForce D&D Section PdM Section Feature B Feature A Cabinet R&D Section

24 DiscoveryとDeliveryの位置づけが変化 事業⽬標設定 課題発掘 仮説検証 妥当性検 証 仕様策定 デザイン 設計 実装 検証 リリース ユーザー 認知 Discovery Delivery 組織再編前 組織再編後 Discovery Delivery PdM デザイナー エンジニア PdM デザイナー エンジニア

25 組織再編による効果 • プロダクトマネージャーとエンジニアの距離が確実に近くなった ⁃ プロダクトマネージャーもデイリーミーティングに⼊れることで、より細かい情報 の同期が可能に ⁃ 以前はこれがリーダー間でしかできていなかったものを、メンバー間でも可能に • 以前よりもエンジニアがプロダクト⽬線を持ちやすくなった ⁃ 結果的にプロダクトマネージャーを経由してセールスやCSの声も届くようになった

26 組織再編による課題 • システム横断での技術的な改善がしづらくなった ⁃ 各featureチームはプロダクトの1機能に紐付いてタスクをこなすため、全体的な技 術改善を提起しづらい • レポートラインが複雑化 ⁃ 組織管理上のレポートラインと⽇々のオペレーションが紐付かないため、⼈事評価 で苦労しそう

27 まとめ • 結局何が⼀番の肝だったのか？ ⇒ 組織構造 • コンウェイの法則 ⁃ 「システムのアーキテクチャは、それを作る組織の構造を反映したものになる」 ⁃ アーキテクチャだけでなく、当然開発フローも影響を受けます