RPOの中の人が、Hubbleの採用戦略を勝手に考えてみた
はじめに — 「契約書版GitHub」という発想が、なぜ採用ページに出てこないのか
「勝手にスタートアップの採用戦略を考えてみた」シリーズ第17回です。
今回のテーマは**「"法務"という職種に縁のない人に、LegalTechはどう刺さるか」。**
「契約書のGitHubを作ればいい」
2017年、CTOの藤井氏が放ったこの一言が、Hubbleの基本思想を生み出した。この発想の転換は見事です。「法務のDX」と言えば難解に聞こえる。だが「GitHubの契約書版」と言えば、エンジニアなら一瞬で理解できる。バージョン管理、差分チェック、コラボレーション——全部知っている概念だ。
だがここに採用の逆説があります。
「GitHubの契約書版」は、エンジニアには概念として伝わる。でも「なぜ自分がそれを作る側に行くのか」という動機はまだ生まれていない。
4,000社以上が導入、継続率99%超、シリーズBで累計約23億円を調達。ユーザーの90%が法務以外の部門。最大で契約業務にかかる時間を82%削減。事業の強さは本物です。だが採用市場で「LegalTechです」と言った瞬間に、大多数の候補者は「自分には関係ない」と感じる。
※本記事は公開情報のみを基にした個人的な分析であり、Hubble様とは一切関係ありません。批判ではなく、応援提案として書いています。なお、文章の作成にはAIを活用していますが、採用戦略の分析・提案はすべて筆者自身の実務経験に基づいて構築しています。
この会社が好きな理由
Hubbleは契約書管理クラウド「Hubble」、契約AIエージェント「Contract Flow Agent」、締結済み契約書専用の「Hubble mini」、NDA標準化プラットフォーム「OneNDA」、法務メディア「Legal Ops Lab」を展開しています。継続率は一貫して99%以上を維持。シンガポール政府系VC Vertex Ventures Southeast Asia & Indiaが出資。2025年に「Contract Flow Agent」を20週連続でリリース。
僕がこの会社に注目する理由は3つあります。
1つ目は、プロダクトの設計思想のユニークさ。 「契約書の差分（diff）に着目する設計——契約内容を丸ごとAIに読み込ませるのではなく、差分に注目することで意図的な変更箇所が判別しやすい」これはGitのdiffアルゴリズムを法的文書に応用するという発想。エンジニアには「あ、それは面白い実装問題だ」と直感的に響く設計です。
2つ目は、ユーザーの90%が法務以外という事実。 Hubbleが解く問題は「法務の仕事」ではなく「会社全体のコラボレーションの問題」。これは「LegalTechの会社」という一言では収まらないプロダクトの本質を示しています。
3つ目は、20週連続リリースというスピード感。 「Contract Flow Agent元年」を宣言し、20週連続でAI機能をリリースし続けた。「動いている開発チーム」であることを数字で証明している会社です。
この会社の事業を分解する — 「課題→思想→ソリューション」の構造
課題：「最新版どれだっけ」が会社全体の問題
スタートアップのビジネス職なら「この業務委託契約のWordファイル、最新版どれだっけ」という経験は誰でもある。エンジニアでも「NDAにサインする前に内容を確認して、法務から赤ペンが帰ってきて、また送り直して」というフローを経験しているはずです。
Hubbleのアンケートでは、66%が「契約業務や契約書の保管・管理が原因で取引に支障が出た経験がある」と回答。79%が「契約について相談しづらくなった」と感じると回答。
「法務は自分と関係ない」のではなく、「自分が困ったのは法務の問題だったとは気づいていなかった」が正確な表現です。
思想：「Agreement（合意形成）という人間行動の核心をデジタル化する」
GitHubがコードのコラボレーションを変えたように、HubbleはビジネスドキュメントのうちAgreement（合意文書）という最もハイステークスな領域に特化して変える。法務の仕事ではなく「会社全体の合意形成インフラ」を作る会社です。
ソリューション：プロダクト群の全体像
Hubble： 契約書の管理・共有・コラボレーション。差分管理、バージョン管理、法務と事業部門のシームレスな連携。
Contract Flow Agent： AIが契約プロセスの進行状況を分析し、次に取るべきアクションを自動提案する契約AIエージェント。2025年に20週連続でリリース。
Hubble mini： 締結済み契約書専用の軽量版。契約管理を初めてデジタル化する企業向け。
OneNDA： NDA統一規格化を目指すコンソーシアム型プラットフォーム。
この構造がなぜ「採用の分析」に関係するのか
LegalTechには他のバーティカルSaaSと一線を画す採用課題があります。「法務は自分と関係ない」というバイアスが、最も広い候補者層に最も深く刷り込まれている。
hokanの「保険代理店」やFact Baseの「製造現場」は、候補者が直接接点を持ちにくいドメインでした。だがHubbleの「契約書・法務」はもう一段遠い。候補者は「契約書は弁護士が読むもの」「法務は専門家の仕事」という認識を持っている。
だが「ビジネス版GitHubをリリースする」というSNS告知に事前申込が200件来た。エンジニアはGitHubの文脈で語られた瞬間に関心を示す。言葉を変えるだけで、同じプロダクトへの反応が180度変わります。
フレームワークをHubbleに適用する
① EVPの明確さ — 「LegalTech」を捨てて「GitHubの契約書版」を1行目に置け
Hubbleにはすでに最強のフレーミングがある。「契約書版GitHub」——これです。エンジニアなら一瞬でイメージが掴める。バージョン管理、差分管理、コラボレーション、マージコンフリクト——全部契約書の問題として存在する。
問題は、このフレーミングが採用コンテンツの奥に埋もれていることです。
採用ページに「LegalTechのSaaS」と書いてある。その下に「契約書管理の効率化」と書いてある。エンジニアはここで「自分には関係ない」と判断して閉じる。
「契約書版GitHub」が1行目に来ていれば、全く異なる反応が生まれます。
採用ページの1行目案：「GitHubはコードのdiff管理を変えた。Hubbleは契約書のdiff管理を変える」
この1文でエンジニアは「あ、自分の知っている問題だ」と感じる。法務の専門知識は不要だと理解する。自分が使いこなしているGitHubの発想をビジネスドキュメントに応用するプロダクトを作るのだと理解する。
さらに踏み込んだフレーミングもあります。「Hubbleは『LegalTechの会社』だとは思っていません。Agreement（合意形成）という人間行動の最も核心的な部分をデジタル化している会社だと思っています」——このフレーミングは採用でもVCでも使える。
② ターゲットペルソナの解像度 — 刺さる2層を分けて語る
Hubbleの採用で最も刺さる候補者層は2つです。
層A：GitHubやLinear・Notionなどのコラボレーションツールのプロダクト設計に興味があるエンジニア・PdM。 彼らには「契約書のdiff管理という独自の問題」を語る。「法律の知識は不要。GitHubを使ったことがあれば、Hubbleが解く問題は直感的に理解できます」と明示するだけで応募ハードルが劇的に下がる。
層B：LLMやAIエージェントの実務応用に関心があるMLエンジニア。 彼らには「Contract Flow Agent——法的テキストをAIエージェントで処理するという最前線の実装問題」を語る。「丸ごとのドキュメントではなく差分で読む設計の理由」というテックブログは、このターゲットに直撃する。
どちらにも共通して使えるのが「20週連続リリース」という数字。「動いている開発チーム」であることは、技術志向の候補者が最も重視する採用基準のひとつです。
③ チャネル設計 — AGには「GitHubとNotionの間」として語れ
AGのRAが「LegalTechのスタートアップです」と言った瞬間に、候補者の頭に「弁護士が使うシステム」というイメージが浮かぶ。エンジニアの大半はここでスキップする。
AGブリーフィングスクリプト： 「HubbleはGitHubの契約書版です。バージョン管理、差分チェック、コラボレーション——エンジニアが毎日使っているGitHubの仕組みを、契約書という最もビジネスクリティカルなドキュメントに応用しています。継続率99%、4,000社以上が導入、シリーズBで累計23億円を調達。AIエージェント『Contract Flow Agent』を20週連続でリリースするスピードで開発中。法務の知識は不要で、ユーザーの90%が法務以外の部門です」
このスクリプトには「LegalTech」という言葉が一度も出てこない。「GitHub」「バージョン管理」「差分チェック」「AIエージェント」——エンジニアが使いなれた言語で説明する。
④ 競合との採用ポジショニング — 「LegalTech」枠から出て「コラボレーションツール」枠で戦う
Notion、Figma、Slack、GitHub——これらに共通するのは「コラボレーションを変えたSaaS」というカテゴリーです。Hubbleはこのカテゴリーの中で、Agreement（合意形成）という特定の領域に特化している会社として語れます。
「LegalTechの会社です」と語れば、TechやLawに興味がある人しか来ない。「Notionが文書コラボレーションを変えたように、HubbleはAgreement（契約）コラボレーションを変えます」と語れば、コラボレーションツール全般に関心があるエンジニアが来る。 潜在的な応募層が一気に広がります。
⑤ 選考体験の設計 — 「週次リリース数」をKPIとして採用ページに入れる
選考で最も効果的な施策のひとつが、「20週連続リリース」というデータを採用ページのKPI欄に入れることです。
エンジニアにとって「週次でAI機能をリリースし続けている開発チーム」は信頼材料。「動いている」「スピード感がある」「自分も同じ速度で成長できる」という印象を数字で伝える。「売上成長率」や「導入社数」ではなく「リリース頻度」というエンジニア目線のKPIを採用コンテンツに入れるだけで、応募者の質が変わります。
自分がRPOとして入るなら、最初の30日で何をするか
Week 1：採用ページ冒頭の書き直し 「LegalTech」「法務DX」を1行目から外し、「GitHubはコードのdiff管理を変えた。Hubbleは契約書のdiff管理を変える」に差し替え。「法務の知識は不要です。GitHubを使ったことがあれば理解できます」を求人票の目立つ場所に明記。
Week 2：AGブリーフィングの全面書き換え 全てのAGに「LegalTech」「法務DX」を使わないブリーフィングスクリプトを渡す。「GitHubの契約書版」「90%が法務以外のユーザー」「20週連続リリース」の3点を必ず入れるよう依頼。
Week 3：「差分（diff）設計」のテックブログ制作 「なぜHubbleのAIは契約書を丸ごとではなく差分で読むのか——LLMと法的テキストの設計論」をテーマに1本制作。MLエンジニアとプロダクトエンジニアの両方に刺さる技術的内容で書く。スカウト文面のリンク先にする。
Week 4：「コラボレーションツール」文脈の採用コンテンツ制作 「HubbleはLegalTechではない。Agreement（合意形成）というコラボレーションを変える会社だ」をテーマにしたnote記事を1本制作。GitHub→Notion→Hubbleというコラボレーションツールの系譜として語る。
まとめ — エンジニアが使いなれた概念に翻訳した瞬間に、バイアスは崩れる
Hubbleの事例から、「候補者に縁遠いドメイン」のSaaSの採用に当てはまる教訓を3つ抽出します。
第一に、「LegalTech」という言葉を採用で使うな。「GitHubの契約書版」と言え。 エンジニアが使いなれた概念に翻訳した瞬間に「法務は自分と関係ない」というバイアスが崩れる。同じプロダクトでも、言葉で印象が180度変わる。
第二に、「ユーザーの90%が法務以外」という数字を採用コンテンツに入れよ。 これはHubbleが「法務専用ツール」ではなく「会社全体のコラボレーションツール」だという最強の証拠。候補者は「自分にも使える仕事だ」と理解する。
第三に、「20週連続リリース」というリズムを採用KPIとして出せ。 エンジニアにとって「週次でAI機能をリリースし続けている開発チーム」は信頼材料。「動いている」という事実を数字で伝える。
最後に問いたい。あなたの会社のプロダクトは、エンジニアが使いなれた概念に翻訳できますか？ LegalTech、HRTech、FinTech——バーティカルSaaSはどれもドメイン固有の言語でプロダクトを語りがちです。だがエンジニアは法律も人事も金融も専門外。エンジニアが使いなれた概念——GitHub、Notion、Figma、Slack——に翻訳した瞬間に「自分には関係ない」という壁が消える。Hubbleの「GitHubの契約書版」という一言が、その翻訳の教科書になります。
次回も別のスタートアップを分析します。よかったらフォローしてお待ちください。
参考ソース
Hubble公式
コーポレートサイト：https://hubble-docs.com/
採用ページ：https://careers.hubble-docs.com/
採用媒体・情報ソース
STARTUP DB：https://startup-db.com/companies/oY1lJ73UezrJ35VB
スピーダ：https://initial.inc/companies/A-28429
筆者プロフィール：RPOコンサルタントとして常時7社以上のスタートアップの採用を支援。採用をマーケティングの視点で構造化し、「なぜうまくいかないか」のパターンを言語化する。複数社を横断的に見ているからこそ気づく「スタートアップ採用のリアル」を、このnoteで発信しています。