サムネイル画像
インタビュー

“規律ある自律”が、20週連続リリースの原動力になる―Hubble開発組織が貫く、Valuesを成果に変える仕組みづくり

企業ロゴ
株式会社Hubble

契約AIエージェント「Contract Flow Agent(以下CFA)」の新機能を20週連続でリリースする──。

契約業務・管理クラウドサービス「Hubble(ハブル)」を展開する株式会社Hubbleが、この驚異的なスピードを実現し、その後も高頻度でアップデートを重ねているのは、単にエンジニア個人の開発スキルの高さだけが理由ではありません。

その秘訣はHubbleが掲げるValues、そのなかでも“自律に基づくチームワーク”をいかに開発現場の仕組みとして実装し、各メンバーのオーナーシップを最大化させているかにあるといいます。

今回、HubbleのSenior Engineering Managerを務める井上さんに、Valuesを単なる理想にとどめず、いかに“開発組織のOS”として制度やフローへ落とし込み、成果につなげているのか。現場の力を最大化させるための組織設計について伺いました。

プロフィール

井上 祥行さん(いのうえ よしゆき)

Senior Engineering Manager

フロントエンドエンジニアとしてキャリアをスタートし、バックエンドエンジニア、チームリーダーを経てEM、前職ではVPoEを経験。2024年11月にHubble初のEMとして入社し、2025年4月よりSenior Engineering Managerに着任。採用、組織設計、評価制度の構築など開発組織全体のピープルマネジメントを担う。石川県在住、フルリモート勤務。

“手触りのある課題”だから、プロダクト開発に熱が入る

画像2

―― まず、Hubbleがどのようなプロダクトなのかを教えてください

井上:Hubbleは、契約書の起案・レビュー・承認・締結から管理まで、契約業務を一気通貫で支援するクラウドサービスです。普段使い慣れたWordでの編集プロセスをそのままに、やり取りや修正経緯をすべて蓄積し、「誰が、いつ、何を、なぜ変えたのか」という契約の文脈がすべて追える状態をつくっています。

この一元化されたデータがあるからこそ、契約AIエージェント「CFA」が迅速かつ正確なビジネスの意思決定をサポートできるんです。エンジニアの方にイメージしやすく言えば、"法務版のCursor"のような存在ですね。契約書は法務だけのツールではなく、本来はビジネスをドライブするためのものです。

Hubbleでは発行されているアカウントの90%以上が法務以外のユーザーです。継続率99%という数字も「これがないとビジネスの意思決定が止まってしまう」という本質的なニーズに応えられているからこそだと思っています。

画像3

―― その世界観は、HubbleのPurposeである“手触りのある課題”ともつながっていると伺っています

井上:まさにそうですね。弊社のPurposeは“手触りのある課題をテクノロジーによって解決し、働く人の個性や創造力が発揮される未来を創出する”です。

画像4

私は立場上、日々の業務で業務委託契約等を確認する機会が多く、「過去の経緯がわからず、確認作業だけで業務が停滞する」といった課題を自分ごととして感じます。だからこそ、現場の課題解決に向けたプロダクト開発にも熱が入る。「課題の本質を理解し、自分ごと化することが、精度の高いエンジニアリングにおいて不可欠である」という考え方が、代表の早川を起点に組織全体に浸透しています。

―― フロントエンドからバックエンド、EM、VPoEと多彩なキャリアを歩んできた井上さんが、次の挑戦の場にHubbleを選んだ理由を教えてください

井上:正直にお話しすると、最初は契約書管理という領域自体にピンときていませんでした。しかし、選考プロセスを通じて、Valuesである“自律に基づくチームワーク”と“人間性の好循環”を、単なるスローガンではなく、強い組織をつくるための合理的な土台として大切にしている姿勢に強く惹かれたんです。

画像5

最初の面接でCTOの藤井と話した際、「開発組織の現状と、これからEMと共に整えていきたい課題」を率直に共有してくれました。着飾ることなく、プロダクトと組織の成長に対して誠実に向き合っている姿勢を見て、ここならValuesを仕組みとして実装し、高い成果を出す組織づくりが実現できると確信したのが決め手でした。

Valuesで評価する。目線を合わせるための組織設計

画像6

―― EMとして入社後、最初に取り組んだのが“評価制度の整備”だったそうですね。なぜ技術課題ではなく、制度から着手したのですか

井上:私が入社するまでは、CTOの藤井が全チームのマネジメントを一人で担っている状態でした。メンバーと1on1を重ねる中で見えてきたのは、“会社が目指す戦略”と“個人のアクション”の目線が、仕組みとして揃いきっていないことだったんです。

個別に指示を出すよりも、まずは組織として“どのような行動に価値を置き、どう評価するのか”を明示する方が、メンバーの自律性を引き出し、モチベーションの向上につながると考えました。評価制度と採用基準を整えることは、“Hubbleが求めるプロフェッショナル像”を定義し、組織の密度を高めるための最短ルートだったんです。

―― 具体的にはどのような仕組みを構築されたのでしょうか

井上:もともとあった評価制度を、私が入社してからよりわかりやすく整えました。6段階の評価段階を設けて、途中からエキスパートとマネジメントに分岐する形にしています。

さらに特徴的なのが、各段階ごとにValuesの評価軸を定めていることです。単なる技術スキルだけでなく、「その行動は“自律に基づくチームワーク”を体現しているか」「“人間性の好循環”を生み出しているか」という視点を評価に含めることで、Valuesを単なる理想ではなく、日々の業務で追求すべき具体的な規律へと落とし込みました。これにより、「Valuesを体現することが、お客様への価値提供に直結する」という納得感を組織に醸成しています。

20週連続リリースを支えた“速さの正体”

画像7

―― 2025年には20週連続で新機能をリリースされたと伺っています。この開発スピードの要因はどこにあるのですか

井上:まず前提として、20週連続リリースの対象は契約AIエージェント「Contract Flow Agent(CFA)」の機能群です。対話型レビュー支援機能やバージョン差分解説機能など、契約業務の“迷い”や“詰まり”を解消する機能を毎週出していきました。

(参考:「Contract Flow Agent」20週連続機能リリースの軌跡

このスピードを実現できたのは、“Squad(スクワッド)”という職能横断型のチームが、個々の専門性を発揮しながらオーナーシップを持って動ける体制が整っていたからです。以前はPdMがプロジェクトマネジメントを兼務していたことで、どうしても意思決定のボトルネックが発生していましたが、その役割を分離・整理し、各Squadが現場で即断即決できる環境を構築しました。

マネジメント層が指示を出すのではなく、現場に近いチームが独立して高速に意思決定を繰り返せる仕組みを作ったことが、このリリースの原動力になっています。

ただ20週連続といっても、無理な長時間労働で押し通したわけではありません。むしろ私たちが徹底したのは開発フローという規律を守りきること。1週間という短い期間でお客様に届ける価値の整合性をどう担保するか。メンバー、一人ひとりがオーナーシップを持ち、自律的に価値を定義し続けた結果、気づけば20週が経過していたというのが実態です。ちなみに20週以降も高頻度なアップデートは現在まで継続しています。

画像8
AIチーム、Coreチーム、Value UpチームなどのSquad体制で、意思決定のスピードを高めます(体制図は2026年3月末時点)

―― Hubbleの開発組織が速い理由は何だと思いますか

井上:Valuesが単なる理想ではなく、具体的な仕組みとして現場で機能し、メンバーが自律的に動ける状態になっているからこそだと思います。物事が停滞する最大の要因は“誰も決めない”、“責任の所在が不明確”という状態ですが、Hubbleでは評価制度や開発フローといった土台が明確な規律として機能しています。

ここでいう自律は、自由にやっていいということではありません。行動を縛るルールはないけれど、チームとして成果を出すための規律はある。一人ひとりがオーナーシップを持って動くからこそ、開発フローのような規律が意味を持つんです。

私が入社した当時、メンバーの皆さんはかなり自由に仕事をされていました。しかし組織が拡大する中では、自由さが逆に迷いを生むリスクもあります。そこで評価制度やフローといった仕組みの軸を一つひとつ整えていったことで、本来の自律性を損なわずに組織としての機動力を劇的に向上させることができたと感じています。

お客様に本質的に必要とされるものをつくろうという意識がチーム全体にあるので、速さのために品質を落とすという発想にはなりません。本質的な価値が届いていなければプロダクトは使われ続けない。継続率99%って、バケツに穴が空いた状態では絶対に維持できない数字ですから。

“コミュ力採用”の真意と、Hubbleが定義する“良い人”

画像9

―― “コミュ力採用”という言葉を聞くと、いわゆる“陽キャ”しか採用されないのかなと誤解する人もいそうですが、実際に採用では何を見ているのですか

井上:コミュ力採用と言っていますが、私自身も別に“陽気で誰とでも仲良くなれる”ようなタイプではありません(笑)。

私たちが面接で見ているのは、過去の経験を深掘りしていった時に現れる“課題への向き合い方”という人間性です。課題に直面した時に自分一人で解決しようとするのか、あるいは目的達成のために周囲を巻き込んで最速で動こうとするのか。それは単なるエピソードの中身だけではなく、話している時の表情や言葉の選び方にも表れます。

技術力があることは大前提ですが、それ以上にValuesである“人間性の好循環”を技術やチームのために体現できるかどうかを極めて重視しています。

―― Hubbleがいう“良い人”とは、具体的にどんな人ですか

井上:採用ページでは“前向きに鼓舞する人、コミュニケーションが気持ちのいい人、思いやりがあり、おせっかいな人、等身大の自分でいられる人”と表現しています。ただ大前提として、必要なのは“自律したプロフェッショナル”であることです。

相手の気持ちを気にするあまり、本来言うべきことが言えないという優しさは、Hubbleでは求めていません。仲間の成長とプロダクトの価値最大化を願い、その時々で最善の判断を伝えて仕事を前に進められる人。それこそが、Hubbleが定義する真の“良い人”です。

代表の早川がよく使うのは“等身大の人”という言葉ですが、私が一番しっくりきているのは“誠実さ”です。誠実さには、自分自身に対してと他者に対しての二種類があると思っていて、その両立が等身大につながります。面接で自分を着飾って入社したとしても、無理な状態を維持し続けるのはご本人にとっても不幸なことです。

だからこそ、私たちも候補者の方に対して徹底して誠実に向き合うようにしています。その採用プロセスへのこだわりが、結果として内定承諾率100%や極めて低い離職率という結果に結びついているのだと思っています。

自律的な組織だからこそ、エンジニアの裁量が大きい

画像10

―― ここまでお聞きしてきた自律やコミュニケーションの文化は、技術や開発での動き方にも影響していますか

井上:大きく影響していると思います。技術領域においてトップダウンの強制は一切なく、Will(やりたいこと)とCan(できること)、そして“ビジネスへの貢献(価値)”のバランスを見ながら、現場主導で調整しています。

実際、バックエンドにGoを導入したのもメンバーからの提案がきっかけで、技術選定の背景や合理性をCTOと直接議論し、納得感を持って進めるプロセスが確立されています。AIツールの導入についても同様です。Cursor、Devin、Claude Code、GitHub Copilotなど、現場が「価値提供を加速させるために必要だ」と判断したものは積極的に導入します。この判断の速さは一人ひとりが規律ある自律を前提に動いている組織だからこそ可能なんです。

―― お客様や他の職種とのコミュニケーションにおいても、そのカルチャーは活きていますか

井上:Hubbleではエンジニアもユーザー会に参加し、お客様の抱える課題に直接触れる機会を大切にしています。

単にビジネスサイドの要求を実装するのではなく、お客様の声を直接聞き、PdMやビジネスサイドと対等な立場でディスカッションしながらプロダクトの方向性を考えていく。エンジニアも営業もCSも一緒になって、このプロダクトをもっと良くするためにはどうすればいいかを本気で考えています。

技術を追求するだけでなく、ドメイン知識を深く理解し、ビジネスのニーズを技術で鮮やかに解決するという探求ができる環境は、エンジニアにとって非常に面白い挑戦だと思います。

―― 今後の組織をどのように成長させていくお考えですか

井上:単純に人を増やせばスピードが上がるかというと、そうではありません。まず組織の密度を高めることが先だと思っています。Valuesとの合致を採用の段階で徹底的に見ているからこそ離職率を低く保てているので、その基準を緩めてまで拡大するつもりはありません。

CTO室がチーム横断の課題解決を担ってくれていますし、マネジメント体制としては正社員のメンバーであればEM1人あたり5〜6名程度で見ることを意識しつつ、必要に応じて計画的にEM層を厚くしていきます。どれほど規模が拡大したとしても、“人間性の好循環”をベースにした採用プロセスの根幹は、私が責任を持って守り抜きます。

お客様の意思決定を“大正解”にするために

画像11

―― Hubbleにはどんな方に来てほしいですか

井上:Valuesに共感できるかどうか、これに尽きます。5つすべてをレベル高く実現するのは相当ハードルが高いので、開発では特に“自律に基づくチームワーク”と“人間性の好循環”を重視しています。

圧倒的なハイパフォーマーが一人いるよりも、しっかり基本的なことができる方が複数人いた方がいいものがつくれると思っています。もし、そのハイパフォーマーが“人間性の好循環”を体現できていなければ、周囲のメンバーが辞めてしまい、チームとしてのアウトカムにはつながりませんからね。

―― 最後に、エンジニアとして今のHubbleに入る面白さを教えてください

井上:Hubbleには、「契約を、ビジネスの意思決定を支えるインフラへと進化させる」という強い意志が根付いています。

お客様自身がまだ気づいていない課題にまで先回りして、プロダクトとして鮮やかに解決していく。それを本気でやりきろうとしている組織はなかなかないと感じています。

すべてはプロダクトが良いことが大前提です。無理やり数字を追うのではなく、圧倒的な顧客体験を追求した結果としてお客様に選ばれ続けている。プロダクトとお客様にまっすぐ向き合える組織だと思います。

整った組織に入るのではなく、Valuesを実装しながら組織をつくる側に回れるのは今のタイミングならではの面白さです。Valuesに共感してもらえる方なら、きっと等身大の自分のままで最大限能力を発揮できると思うので、ぜひ一度お話したいです。