この記事は Hubble Advent Calendar 2025 の10日目の記事です。
はじめに
2025年7月よりHubbleでバックエンドエンジニアをしている @krakazcyrano です。
入社以来、Hubble の機能エンハンスを主なミッションとする Value Up Squad の一員として、新機能の開発をガンガン行っています。
事業活動と開発活動を直結させたい
Hubbleはプロダクトをコアとするリーガルテックスタートアップです。
プロダクトの価値を継続的に高めていくためには、事業・プロダクトが対象としている領域を深く正確に理解し、アーキテクチャやコードの設計に反映させていくこと、言わば事業活動と開発活動を直結させることが必要不可欠です。
Hubbleに入社後、顧客とプロダクトに対するものすごい熱量に日々圧倒される中で、その重要性をひしひしと感じています。
『ドメイン駆動設計をはじめよう』
では、そのためには具体的に何をすればいいのか。
そう考える中でたまたま『ドメイン駆動設計をはじめよう』という書籍を知り、読んでみたところ、まさに「事業活動と開発活動を直結させる」ための具体的なノウハウが詰まっていました。
ということで今回は、『ドメイン駆動設計をはじめよう』の知見を手がかりに、新参エンジニアとして取り組んだ事業・業務理解の取り組みについてお話しします。
事業領域・業務領域を理解する
さて『ドメイン駆動設計をはじめよう』では、まず自社の事業領域と、それを構成する業務領域を理解する必要性が語られています。
業務領域ごとの重要性や特性を分類し、それをアーキテクチャやコードの設計に写し取ることで、事業・プロダクトが解決したい課題に対してより正確にアプローチすることができます。
ドメイン駆動設計では、業務領域を3つのカテゴリーに分類します。
中核の業務領域
他社との違いを生み出し、競合優位性に貢献する領域。
複雑で難易度が高く、自社独自の作り込みが重要。
一般的な業務領域
複雑だが競合優位性に貢献しない領域。
差別化につながらないため他社と同じやり方でも問題なく、パッケージ製品やクラウドサービスが活用可能。
補完的な業務領域
単純で競合優位性に貢献しない領域。
課題は単純だが、一般と違い自社独自のものになるため、パッケージ製品などでは解決できず、開発が必要。
1
正直具体例がないとピンとこないところですが、この中で一番重要なのは言わずもがな中核の業務領域です。
今回は一旦のゴールとして、Hubbleにおける中核の業務領域を特定することを目指してみます。
まず事業領域は？
まずは事業領域を明確にしておくと、Hubbleの事業領域はリーガルテック、特に CLM (Contract Lifecycle Management) と呼ばれる領域です。
中核の業務領域を見つける
中核の業務領域を分析するために、まずは浅い理解から出発してみましょう。
HubbleはCLMであり、契約業務を「一気通貫」で支援することを特徴としています。
契約業務は以下のようないくつかのフェーズで構成されますが、その中の特定のフェーズに注力するのではなく、全てのフェーズでユーザーの課題を解決するということです。
- 依頼・受付
- 審査・交渉
- 承認・締結
- 保管・管理
これらのフェーズがそのままHubbleにおける業務領域だとすると、「一気通貫」ということはこれらすべてが重要＝中核の業務領域ということでしょうか？
しかし「一気通貫」であることは CLM(Contract Lifecycle Management) として当たり前ですし、競合他社も同様に掲げている部分でもあります。「一気通貫」であること自体がHubbleのオリジナリティであるということはできなさそうです。
中核の業務領域を本気で特定する
ではここから深掘りして、中核の業務領域を本気で特定していきましょう。
中核の業務領域を特定する方法は『ドメイン駆動設計をはじめよう』の中でもいろいろと紹介されていますが、今回はそれらを参考にしつつ、自分なりに考えたアプローチも試してみました。
サービスサイトをよく読む
中核の業務領域はとにかく競合優位性を生み出しているという点がポイントです。
そこでまず、プロダクトとして競合優位性≒顧客へのアピールポイントをどのようにとらえ、表現しているかを知るため、サービスサイトをあらためて眺めてみました。
正直サービスサイトを見るのは久しぶりだったのですが、以前よりコンテンツがかなり進化していて、マーケティングチームの気合いを感じます。
アピールポイントとしては、一気通貫の各フェーズに効くという点は前提としつつ、いくつかの特徴的なポイントを掲げていることが見えてきました。
見えてきたキーワード
- 誰でも使えて馴染みやすいUI/UX
- 柔軟かつ堅牢なアクセス制限
- 契約情報・ナレッジが自然と溜まる
- 必要な情報がすぐ見つかる高度な検索性
- 契約AIエージェント「Contract Flow Agent」
- 必要なプロセスから始められる柔軟さ
事業戦略を落とし込む
Hubbleでは毎月の全社会や半期ごとのキックオフ、また社内向けのPodcastなどで、事業戦略が常に発信、共有されています。
今回それらをあらためて紐解き、会社としてどのように競合優位性を生み出そうとしているかを自分なりに落とし込む作業をしてみました。
※さすがに社外秘な情報が多いので詳細は省きます
受注報告を分析する
HubbleではSalesの受注報告専用のSlackチャンネルがあり、そこにはお客様の課題とHubbleがそれにどう取り組むか、そしてなぜHubbleを選んでいただけたのかが詳細に記載されます。これはまさに「競合優位性を生み出している」ポイントと言えます。
そこで今回は社内の Notion AI（Slackを紐付け済み） にこのチャンネルの投稿を分析してもらい、特に競合優位性につながっていそうなポイントを整理してみました。
見えてきたキーワード
- UI/UXのわかりやすさ
- AI活用の幅広さ
- 権限制御の柔軟性
- スモールスタートで導入できる柔軟性
- 顧客対応のスピード感
note記事を分析する
Hubbleでは note の投稿も積極的に行われており、特に7月の CFA（Contract Flow Agent） 構想の発表を皮切りに、数十週にわたるnoteリレーが展開されています。
この中ではCFAという構想を核に、Hubbleの人やカルチャー、そしてプロダクトへのこだわりが様々なポジションの方から語られています。これを分析することも、競合優位性の把握につながりそうです。
note記事はもちろん全部読んでいるのですが、なにぶん数が多いので、ここは Gemini の Deep Research を使って note 記事を中心とするWeb情報からHubbleの競合優位性を分析してもらいました。
見えてきたキーワード
- 業務の滞留を防ぎ、判断の質とスピードを向上させる 「動的なワークフロー支援」
- 契約書への対応履歴（差分・コメント）データの一貫した蓄積とAIエージェント(CFA)が形成する参照ループ
コードベースを分析する
中核の業務領域の特定には、もちろんコードベースの分析も有効です。(というかエンジニアならここから攻めるべきか)
『ドメイン駆動設計をはじめよう』では例えば以下の観点が紹介されています。
中核の業務領域を特定する方法として、強力だが、ありがたくない経験則があります。それは大きな泥団子です。ソフトウェア開発者であれば見るもの触るのもいやでしょうが、システムでもっとも入り組んだ設計になっている場所は、中核の業務領域である可能性が高いでしょう。
「大きな泥団子」「もっとも入り組んだ設計になっている場所」の特定について、Railsであればモデルの行数などが一番単純な指標かと思いますが、ここもやはりAIに登場してもらいました。
Hubbleでは Cursor や Devin といったAIツールの活用を推し進めており、今回も両ツールでメインリポジトリのコードベースを参照させつつ聞いてみました。
見えてきたキーワード
- 契約書(Item) を筆頭とするいくつかの基幹モデル
- 契約書のバージョン管理の複雑さ
- ドキュメント、フォルダの柔軟な階層構造
- 外部電子契約サービスとの連携
あらためて、中核の業務領域は？
ということで、ここまでいろいろな観点で、中核の業務領域＝競合優位性を生み出している領域を探ってきました。
ここまでの成果を踏まえまとめると、Hubbleにおける中核の業務領域は、「一気通貫」の各フェーズそのものというよりは、以下のような領域であると言えそうです。
- 契約書のバージョン管理・コメント機能
- バージョン差分・コメントを中心とするナレッジの蓄積
- AIエージェント(CFA)
- 使いやすいUI/UX
- 柔軟な権限管理
さらにこれを踏まえて「一気通貫」の意味を捉え直してみると、Hubbleにおける「一気通貫」とは、
- 契約業務の各フェーズを、柔軟な権限管理と直感的なUI/UX、AIによる支援（CFA） によって安全かつなめらかに繋ぎ込み、
- 契約書への対応履歴（バージョン差分・コメント） を中心とする ナレッジを一貫したデータ基盤に蓄積し、
- それをAIが参照するというループの繰り返しによって、
- 顧客の意思決定の質とスピードを螺旋的に向上させていく
というプロダクト設計のあり方を表していると言うことができるのではないでしょうか。
おわりに
ということで今回は、書籍『ドメイン駆動設計をはじめよう』の知見を援用しつつ、Hubbleにおける中核の業務領域を分析してみました。
具体的にここからどう開発の活動に活かしていけるかは未知数なのですが、まずは何よりも自分自身の事業・プロダクトに対する解像度向上にめちゃくちゃ効果がありました。
今回まとめた内容は、たぶん社内の古株のメンバーに聞けばすぐ分かることなのですが、そうではなく、自分自身でいろいろな観点から情報を集約し、自分の言葉で語り直したことで、はじめて自分の血肉となる形で理解できたと思います。
ただ「普通に社内の人と話したほうが早くね？」というのはその通りなので、そういった機会も積極的に作っていきたいと思います。
また今回は観点を絞るためあえて触れませんでしたが、本来業務分析にあたっては、プロダクトの中だけでなく、営業やCS、コーポレート等を含めた会社としての活動全体に目を向けるべきです。
Hubbleにおいても、競合優位性の少ない部分がそれらの活動に含まれていると思います。ここも社内の人と話しながら解像度を上げていきたいと思います。
最後にですが、市場、事業のフェーズ、テクノロジーなどあらゆる状況がめまぐるしく変わっていく中で、中核の業務領域も変わっていくと思います。
その流れの中で、Hubbleとして本当に大切な部分が何かを捉えつづけ、事業活動と直結した開発活動を行っていけるよう、今後も取り組んでいきたいと思います。
ここまでお読みいただきありがとうございました。明日は同じ Value Up Squad の @tnaoki さんです！
-
中核、一般、補完はそれぞれエヴァンス本における「コアサブドメイン」、「汎用サブドメイン」、「支援サブドメイン」に対応。『ドメイン駆動設計をはじめよう』では全般的にエヴァンス本から訳語の見直しが行われています。 ↩