こんにちは。LegalForce COO 川戸（@kawato_takashi）です。
今回は、LegalForceの開発組織での直近の組織変更について、その意図と背景をお伝えします。読者としては下記の二通りを想定しています。
- 弊社をご検討いただいている候補者に正しい最新の情報をご共有すること。
- 複数製品を開発・運営する上での組織課題に関心があるエンジニアリングマネジャーやプロダクトマネジャーに、弊社の経験をご共有すること。
LegalForceでは、タイトルにもある通り、「新製品を作り、育て続ける」ということを開発における大きい課題と捉えています。売り上げの大きい既存製品を優先する力学は、組織の様々なレベルで働きます。組織は放っておけば新規のアイデアを押しつぶしてしまうのです。この罠を避け、新製品の開発・成長や探索にしっかり投資をするには、それができるように組織を設計する必要があります。本稿では製品別組織、カンパニーベット、VPoEの設置、イノベーション推進グループの設置といった各施策が、どのようにこの目的に貢献するのかを説明します。
はじめに
かつてのLegalForceの開発組織は下図の通りでした。2020年9月のCTO時武のエントリでもこの画像が参照されています。
現在LegalForceの開発組織は上記の形を取っていません。2021年5月から断続的な組織改革を行い、VPoE和賀の参画や、先日発表したCRO舟木の「イノベーション推進」への異動によって一応の完成を見ました。現在の組織は下記の通りです。
「研究開発」「製品開発」という機能別の枠組みを取り払い、顧客または社内向けの製品*1ごとのグループをCTOの下に一本化しました。またVPoEを責任者とする「人事・管理ライン」が、予算やガバナンスを司り、かつ各開発グループを支援する組織として新設されています。
旧体制は「LegalForce」という単一の製品を磨き上げることに焦点を置いた体制でした。しかし第二製品「LegalForceキャビネ」の立ち上げと成長、また第三、第四の製品の継続的な立ち上げを見据えると限界が大きくなってきました。
以下では旧体制の何が強みであり、何が課題であり、新体制はそれをどのように解消しようとしているか、をお伝えします。
旧体制の設計思想: ドメイン知識とエンジニアリングの結合
旧体制は2019年10月頃に完成しました。目的は「AI開発（R&D）」と「製品開発（D&D）」、「法務開発（Practice Development; PD）」を疎結合にし、開発速度を向上することでした。PDは契約に関するドメイン知識の体系化とコンテンツ制作を担うチームです。弁護士や、元法務担当者などから構成されています。
この当時、製品は「LegalForce」のみでした。旧体制は「LegalForce」の開発に必要な機能を依存が少ない形で切り出した形態です。PDが契約書ひな形の追加をD&Dの負担なく実施できる、R&DのアルゴリズムをD&Dの工数なくアップデートできるなどの恩恵があり、「LegalForce」のリリース数は体制確立後、飛躍的に伸長しました。
「LegalForce」は現在、契約書レビュー領域で国内では機能面で充実した製品になっています。疎結合化された開発組織はこの成長に大きく貢献しました。
旧体制の課題
第二製品の位置づけの難しさ
旧体制は「LegalForceを作る」という目標の下に最適化された、機能別組織でした。
開発組織であれ、営業組織であれ、すべての組織の原型は「製品別組織（事業部制組織）」と、「機能別組織」のいずれかにたどり着きます*2。
製品が「LegalForce」一つなら機能別組織で問題はありません。しかし第二製品「LegalForceキャビネ」を2021年1月にリリースしたことで「機能別組織を続けるのか？」が、課題になりました。時を同じくして研究開発を中心に分析基盤、アノテーションシステムなどの「社内向け製品」も増え、それらの位置づけも時を同じくして課題となってきました。
（ちなみにLegalForceの開発組織（旧体制）は純粋な機能別組織とは異なる部分も多いです*3。詳細が気になった方はぜひMeety等でお話しさせてください。）
機能別組織が複数製品を開発する場合、下記の2つの課題が発生します。
- 機能別組織は、製品が増えるとコミュニケーションラインが増える。
- 機能別組織は、小さい製品にリソースを割り当てづらい。
機能別組織は、製品数に応じてコミュニケーションラインが増える。
製品が増えると、各機能別組織は、製品ごとの担当者を設置します。この担当者は、製品に関する方針を、部署間で合意したうえで、更に自分のラインの上長とも相談することになります。指揮系統が二重になってしまうわけです。
立ち上げ段階で機能別組織の上長の助言が有効になる場面は少なく、新製品開発は事実上の製品別組織になっていきました。公式の指揮系統と実際の指揮系統が食い違うと、混乱が生じます。
機能別組織は、小さい製品にリソースを割り当てづらい。
別の問題もあります。今度は担当者ではなく、各機能組織のマネジャーの観点に立ってみましょう。この組織では、下記の2つの製品に関与しているとします。
- 製品A: 顧客数 1,000社
- 製品B: 顧客数 20社
製品Aと製品Bとでそれぞれ「顧客数が5%増える」インパクトがあるアイデアがあり、どちらか一方のみを実施できるとします。この場合、全体売上を最大化する観点からは製品Aのアイデアを実施することが合理的です。製品Bは数字が小さく、成長が少々加速しても、短期での収益貢献は見込めません。
会社としても中長期の戦略的な見地からは製品Bに注力したい一方、今期の業績達成は製品Aに依存しています。この状況で機能別組織に思い切った製品Bへの投資を期待することは困難です。
以上は二つの製品が既に存在する中での問題点です。ただ、機能別か、製品別か、という組織形態とは別に、ドメイン特化した開発組織が継続的に新製品を探索し続けるには別の課題もあります。
ドメイン特化した開発組織は、近視眼に陥りがちである。
LegalForceは契約に関する製品と技術を日々開発しており、このために「契約」に関するドメイン知識を収集しています。
- 契約のパターンやリスクに関する体系化された知識（法務開発）
- 契約業務フローや法務担当者のキャリアに関する知識（UXリサーチ）
- 電子契約など隣接領域の技術的な知識（製品開発）
結果としてLegalForceが生み出す製品や機能のアイデアも、「契約」に関するものに収束します。既に「LegalForce」と「LegalForceキャビネ」が存在するため、アイデアは実装段階で既存製品の「新機能」に落ち着きがちです。
たとえばLegalForceで今度提供を開始する機能に「案件管理」があります。
ソース: AI契約審査プラットフォーム「LegalForce」「案件管理」機能をオプションサービスとして今秋より提供開始
この機能は当初「新製品」として企画を始めました（実際、2020年秋ごろの投資家向け資料には「新製品をやります！」と書いてあります。）。しかし検討の中で、むしろLegalForceの一機能にした方が良いという結論に落ち着きました。
もちろんそれはそれで必要です。しかし契約領域の契約ワークフローに閉じた機能以外が出てこず、市場を「広げる」新製品が登場しないことに、経営チームは危機感も抱いていました。
LegalForceのミッションは「全ての契約リスクを制御可能にする。」ことです。したがって契約領域へのフォーカスは重要です。しかし契約リスクはそれ以外の法務の業務領域とも重層しています。このため隣接領域も含めた価値提供は、契約リスクを制御する上でも不可欠です。下図は契約とその関連領域というドメインを横軸に、縦軸に価値提供のアプローチを並べたものです。
現在のカバー範囲は極めて狭いです。ドメインを設定し、尖らせた結果、組織全体がある種の「近視眼」に陥っている、これが経営チームが抱いていた課題です。
新体制への移行
上記の3つの課題を解決するため、下記の施策を実行してきました。
- 開発グループ制の導入: 製品別組織への移行。
- カンパニーベットの設定: 全社優先順位の製品横断での合意。現在の事業規模だけではなく、将来性による資源配分を可能に。
- VPoEとEMの設置: 重責を担う開発グループリーダーを支援する体制の整備。
- イノベーション推進グループの設立: 継続的な新製品シーズの探索を制度化。
以下では、それぞれを説明していきます。
開発グループ制の導入
アノテーションの現業を抱えるPDは維持しつつ、D&DとR&Dという組織境界を廃止しました。代わって開発する製品に応じた「開発グループ」という概念を導入しました。
機能別組織から製品別組織に移行したという形になります。「社内製品」であるアノテーションシステムや、内部APIも含まれます。各組織の責務が明確になりました。
カンパニーベットの設定
カンパニーベットは『ユニコーン企業のひみつ』を参考に導入しました。
製品が複数になり、製品別組織になると、単に各組織の自律性に任せるだけでは協調行動を取りづらくなります。各製品のレイヤーでは「絶対に必要なこと（MUST HAVE）」と、「あるとよいこと（NICE TO HAVE）」の区別が難しくなります。
そこで全社として達成するべき事項と、その優先順位をつけることで、NICE TO HAVEな部分へのリソース投下を抑えることができます。
また、ある開発グループで人員が不足した場合に「これはカンパニーベットだから」ということで、増援を依頼しやすくなるという利点もあります。
VPoEとEMの設置
この話はそれだけで別のブログが書ける話で、それはVPoEの和賀とEMの荒木に譲りたいのですが、ここでは一つだけ。LegalForceには多くの企業の「バリュー」に相当するものとして「プリンシパル」があり、その中に「正気を保つ」というものがあります。
LegalForceのプリンシパル
-
One Mission: ミッションに照らして、常に社のあるべき姿を考え、より高みを目指していく。このために互いを巻き込み、力を合せよう。各々が自らの役割を最大限まで広げ、全力を尽くそう。
-
プロフェッショナルに驚きと感動を: 自らの知見を更新し続けること、プロフェッショナルと向き合い続けることで、テクノロジーと弁護士の専門知見を組み合わせた期待を超える価値を届け続ける。
-
Super Big Pictureを描く: 自分だけの大きな未来図を描こう。高みを信じ、実現へ向けて行動することで、10年後の理想を現実に変えていく。
-
正気を保つ: バイアスにとらわれていないか。場の空気に流されていないか。周囲の声に耳をかたむけているか。いつも事実を冷静に捉え、論理的に考えて意思決定しよう。
「正気を失う」例として、開発ではインパクトが出ない開発にずるずるとリソースを投下してしまう、顧客不在のユーザーストーリーを作ってしまう、などが挙げられます。
個々人の意識も重要ですが、制度として正気を担保することが重要です。LegalForceにおけるVPoE / EMのミッションはこの点にあります。
複数に製品や担当領域が分かれ、それぞれ事に向かう中では、気づいたら正気を失っていた、ということが発生しがちです。特に製品別組織では機能別組織に比べてリーダーの責任は重くなり、ストレスも増えます。役割と結果との関係性が明らかだからです。
スクラムの運営から、ユーザーストーリーの発掘、営業連携まで、些細なことから組織の健全性は損なわれていきます。バックログが乱雑になる、振り返りがマンネリ化する、顧客接点が減る、など。
VPoE、EMは各グループの状況を見守り、必要に応じて助言を行い、場合によってはうまくいくまでハンズオンで支援を提供しています。また、大きいレベルでは財務、人事などと連携しながら開発組織全体のガバナンス確保、人材育成なども見守っています。
イノベーション推進グループの設立
以上のように「正気を保つ」ことをLegalForceは非常に重視していますが、一方で「正気を保って」合理的な意思決定をし続けるだけの組織は、当初に計画された以上のイシューを解くことはありません。
製品グループを正しく分割し、正しく開発しても「今カバーしている範囲」が広がることはありません。基本的にはこの組織は「深掘り」をすることに特化した組織です。開発グループ制と、カンパニーベットの導入の要点は「複数の鉱脈を並列で掘れるようにした」ことです。「新しい鉱脈を探す」ことは、別の形で担保する必要があります。
freee, MoneyForward, UZABASEなど成功しているSaaS企業は常に新しい製品を展開し続けています。今回、舟木が着任した「イノベーション推進」は、まさにこの「新しい鉱脈の探索」をミッションとしています。
イノベーション推進グループからは2022年度中に新たな製品をお届けすることを目標にしております。ご期待いただけますと幸いです。
まとめ
組織改革は、実施から1-2年経ってその結果が表れます。このため現時点でその評価を行うのは難しいです。一方で組織改革は多くの人にとって懸かるものが大きく、その意図を後々検証できる形で残すことは重要です。
今回の組織改革の意図は、LegalForceが持続的に複数の製品を育て、また新たな製品を送り出し続けるようにすること、格好のいい言い方をすれば再現性をもってイノベーションを起こし続ける組織であることを目的にしています。
LegalForceは、プロダクトを重んじる開発組織ですが、同時に「今の、このプロダクト」だけに閉じることなく、常に新しいチャレンジにもオープンでありたいと考えています。また、そのようなアイデアを常に歓迎しています。
ちなみに社内の開発組織を製品別にしたことにより、現在この製品グループリーダー（またそのサブリーダー）を担う人材に不足が生じております。腕に覚えのあるエンジニアの皆様、ぜひ一度、カジュアルにお話しさせていただけますと幸いです。またエンジニアリングマネジャーのポジションも絶賛募集中です。組織の話題が好きなエンジニアの方もぜひ一度お話しさせてください！
どうぞよろしくお願いいたします。
