Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Ad2155c75c67c0100dd008ad10858de5?s=128

LegalForce, Inc
PRO

April 10, 2021
Tweet

Transcript

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

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

    of the year 2019ड৆ɻ !UPLJDIJFUP
  3. デュアルトラックアジャイルを導⼊して地雷を踏んだ話

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

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

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

  7. 7 D&Dのプリンシプル(⾏動指針) 「1つ1つの積み重ねが最⾼をつくる」 銀の弾丸なんてない。⽬の前の1つ1つを、明確な判断基準を持ってこなしていく。その積み重ねの先に、ようやく最⾼の品質が ⼿に⼊る。 「1⼈でつくらない」 1⼈でつくらないためには何が必要か?隣の⼈に敬意を払う、情報の透明性を⾼くする。1⼈でつくれるような⼩さいプロダクト を、私たちはつくろうとはしていない。 「NO BORDER」

    職種・⽴場を、ちょっとだけはみ出た仕事をしよう。⾃分の軸を保ちつつ、⼿段には囚われない。考えるべきは、One Mission の実現に必要なこと。 「誰のためのプロダクト?」 その努⼒が、ユーザーの価値に繋がるかを顧みよう。⾃⼰満⾜に陥らず、都合の良いユーザー像に⽢えず、熱意を私たちのユー ザーに届けよう。
  8. 開発フロー、どんな感じでやってますか?

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

  10. 10 LegalForceのロードマップ検討会 4⽉ 5⽉ 6⽉ 機能A 機能B 機能C んー、それぞれ最低でも2ヶ⽉はほしいですね (正直技術調査しないとわからん…)

    今季はA, B, C, Dを⼊れたいんだ けどどれくらいで開発できる? 機能D プロダクトマネージャ 開発者
  11. 11 当時の開発フロー • 四半期に1回のペースでロードマップを棚卸し ⁃ エンジニアがその場でかなり粗々な⾒積もりを⾏う • 棚卸したロードマップに沿って開発者をアサイン → アサイン後、技術調査・影響範囲調査を始める

    → 想定よりずっと影響範囲が⼤きいことが分かる → ⾒積もりをやり直した結果ロードマップが崩壊
  12. 12 実際は開発したい機能は溢れるほどたくさん… 4⽉ 5⽉ 6⽉ 機能A 機能B 機能C やりたいことリスト 機能E

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

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

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

    定 課題発掘 ストーリー 明確化 仮説検証 妥当性検証 仕様策定 デザイン 設計 実装 検証 リリース ユーザー認 知 Discovery Delivery
  16. はじめはうまくいくように思えたが…

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

  18. 18 デュアルトラックアジャイル導⼊後の課題 • 結果、エンジニアがDiscoveryサイクルに⼗分⼊れなかった • プロダクトマネージャーとデザイナーがDiscoveryメイン、エンジニアが Deliveryメインという実質的な分業制になってしまった 事業⽬標設 定 課題発掘

    ストーリー 明確化 仮説検証 妥当性検証 仕様策定 デザイン 設計 実装 検証 リリース ユーザー認 知 Discovery Delivery
  19. 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. 20 LegalForceの開発組織図 開発本部 D&D Section R&D Section PdM Section PD

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

    Section LegalForce Unit Cabinet Unit LegalForce Unit Cabinet Unit • 結果的にメンバーからは「受託開発感がある」「組織を跨いだメンバー 間コミュニケーションが薄い」という課題の声が上がっていた
  22. そして組織の再編へ

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

    A Cabinet R&D Section
  24. 24 DiscoveryとDeliveryの位置づけが変化 事業⽬標設定 課題発掘 仮説検証 妥当性検 証 仕様策定 デザイン 設計

    実装 検証 リリース ユーザー 認知 Discovery Delivery 組織再編前 組織再編後 Discovery Delivery PdM デザイナー エンジニア PdM デザイナー エンジニア
  25. 25 組織再編による効果 • プロダクトマネージャーとエンジニアの距離が確実に近くなった ⁃ プロダクトマネージャーもデイリーミーティングに⼊れることで、より細かい情報 の同期が可能に ⁃ 以前はこれがリーダー間でしかできていなかったものを、メンバー間でも可能に •

    以前よりもエンジニアがプロダクト⽬線を持ちやすくなった ⁃ 結果的にプロダクトマネージャーを経由してセールスやCSの声も届くようになった
  26. 26 組織再編による課題 • システム横断での技術的な改善がしづらくなった ⁃ 各featureチームはプロダクトの1機能に紐付いてタスクをこなすため、全体的な技 術改善を提起しづらい • レポートラインが複雑化 ⁃

    組織管理上のレポートラインと⽇々のオペレーションが紐付かないため、⼈事評価 で苦労しそう
  27. 27 まとめ • 結局何が⼀番の肝だったのか? ⇒ 組織構造 • コンウェイの法則 ⁃ 「システムのアーキテクチャは、それを作る組織の構造を反映したものになる」

    ⁃ アーキテクチャだけでなく、当然開発フローも影響を受けます