僕らの世界観がリーガルテックのスタンダードに――今Hubbleの開発にジョインする面白さ
今回は2019年に創業者で取締役CTO（Chief Technology Officer）藤井にインタビューした内容を、大幅にアップデートしてご紹介！なぜリーガルテック領域だったのか・Hubbleで開発するのは何が面白いのかを話してもらいました。
Hubble 取締役 CTO 藤井克也
2016年 Hubble創業＆CTO就任
Twitter：@katsuya0515
プロダクトで、「困っている人」を助けたい
－－これまでのキャリアについて教えてください！
Hubble創業以前はアメリカで研究職として働いていて、プロトタイプを作って検証し、論文を書くといった仕事をしていました。当時から「ITスキルを使って、困っている人を助けたい」という思いを抱いていたので、帰国後にまずコンサル会社を創業し、上場企業やスタートアップへの技術アドバイスなどを行っていました。
とはいえコンサル事業は、自分の技術や能力を人のために使う点が魅力ではあるものの、自分の成長という意味では限界があると感じていました。そのため、自分自身でプロダクトを立ち上げて、ゼロからスタートしたいという気持ちが強くなっていきました。
そんな気持ちを持ち始めた頃、コンサルのクライアントとして当時東京で起業したばかりの早川（Hubble CEO）と出会いました。当初は今のHubbleとは全く違うプロダクトでしたが、「一緒に事業をやりたいね」という話になって、早川との共同事業が始まりました。
――なぜ「Hubble」というリーガルテックのプロダクトにたどり着いたのですか？
冒頭で触れた通り、「ITを活かして、困っている人を助けたい」という気持ちがありました。率直に言えば、「法務業界に貢献したい！」との強い思いはなかったのですが、CLO酒井との出会いをきっかけに、法務業界への可能性を感じるようになりました。
契約書が基本的にWordでやり取りするものであるということに対して、エンジニアは皆、不可解だと感じていると思います（笑）。エンジニアとしては、PDFならまだしも、昨今はクラウドサービス経由でURLを共有し、オンラインでの編集を行うというのが当たり前、という感覚です。そこで、プロトタイプとして契約書に特化したオンライン編集ツールを作成しました。
当時、Hubbleの顧問弁護士だった酒井にオフィスに来てもらい、この編集ツールの可能性を聞いたところ、はっきりと「絶対に使わない。」と言われました（笑）。
気を取り直して、改めて酒井に普段の業務についてヒアリングをしたところ、出社後、相手方から受け取ったメールに添付されたWordファイルをダウンロードして、ダウンロードしたファイルを編集して、相手方にメールで送り返す…といった作業を繰り返している、という回答を得ました。「なぜこんなに面倒臭い作業を繰り返しているのだろう」というのが正直な感想でした。ただ、この時、酒井がWordを操作している姿にハッとさせられる部分がありました。弁護士は僕らが知らないようなWordの機能も使いこなしていて、「契約書は、やはりWordで作られるものなんだ。」という確信が生まれたんです。
エンジニアの業務では、ソースコードの管理は基本的にGithubというサービスを使うため、普段ダウンロードは行いません（専門的な話をすれば、「pull」という作業は行います）。ファイル名やバージョンの管理がスムーズに行えるだけでなく、共同作業者とのファイル共有も簡単です。「この思想をWordでの契約書作成に応用すれば、便利にファイル管理ができるようになるのではないか？」と考え、再度プロトタイプ作成に没頭しました。
1週間後、酒井にプロトタイプを作って見てもらうと、前回とは違って反応も良かったんです。そこで、「リーガルテック領域でやっていこう」と、今のHubbleが始まりました。
・・・
Valuesに紐づく開発体制と開発プロセス
－－現在の職務内容を教えてください。
現在は、大きく3つの役割を担っています。
一つ目はスタートアップのCTOならではとしての役割です。バックエンドやインフラ周りの作業は、僕も実際に手を動かしています。同時に、今後の成長による組織の拡大に備え、エンジニア一人一人が働きやすい環境を作ることにも注力しています。先立っての技術調査、困っているエンジニアへのアドバイスのみならず、新しく入ってくるエンジニアの方が、スムーズにオンボーディングできるような環境づくりも担っています。エンジニアが働く姿を想像しながら、「これがあったらもっと良いな」ということを想像し、実践や準備をしています。
二つ目は採用です。プロダクトを成長させるためには、エンジニアは必要不可欠です。そのため、人事と連携して採用活動を行っています。候補者へのスカウトの送付や面接も積極的に僕が行うようにしています。
Hubbleの採用では、Purpose & Valuesに共感していただけることを非常に重視しています。
しかし、エンジニアとしてのスキルや、Hubbleの開発プロセスにマッチしているかどうかという観点から、開発者の視点も不可欠です。そのため、会社の視点と開発者の視点の両方がマッチしているかを確認しています。
三つ目は経営です。経営会議では、技術的な視点や開発者の視点からの方向性を伝え、意思決定に携わっています。また、開発チームを代表してビジネス部門の情報のインプットを行い、経営会議での内容を開発部門が把握できるようにチームへ情報を共有しています。
Hubbleは、エンジニアに限らず可能な限り全社員に情報を共有しているので、一人一人がオーナーシップを持ち、動きや意思決定ができる組織になっています。そのような環境づくりの土台として、経営部門・ビジネス部門・開発部門の意思疎通をしっかり図れるようにすることが非常に大切なんです。
－－Hubbleの開発視点で、現在はどんなフェーズにあると捉えていますか？
昨年シリーズAの資金調達を行いましたが、継続率99.9%を実現し、開発チームが手掛けてきた施策がお客様にも評価され、PMF（Product Market Fit）ができたと実感しています。
PMF達成までは、新機能を作り、改善し磨き上げていくことの繰り返しでした。ここからは指数関数的に顧客を増やしていくステップであり、そのために以前よりも中長期的な目線で開発することが重要になってきます。
具体的な例を挙げると
高負荷に耐えうるように、既存コードのリファクタ
複数サービス開発を見越した、サービス間連携の設計見直し
メンバーが増えてもすぐに活躍できるような、オンボーディング内容の拡充
これまでの実践に基づいた、安全性・効率化を意識した開発
などです。もちろんこれだけではありません。
－－これらは全て藤井さんが担われるのでしょうか？
いいえ、そんなことはありません。もちろん僕が担当することもありますが、基本的には、土台や基礎を僕が作り、現場の意見を取り入れながら進めています。そして、会社としてやるべきこと＝メンバー個人のやりたいこと、と一致する場合は、積極的に任せていきたいと思っています。
その背景には、エンジニアとして開発をするだけでなく、スタートアップにいるからこそできることをやってもらいたいという思いがあります。ビジネスや組織として「もっとこうした方が良いよね」という課題を自ら見つけて解決していけるような、そんなエンジニアになってもらいたいです。これは会社としてのValuesにも紐づいています。
――開発の体制とプロセスも、Valuesを意識されているのでしょうか。
そうですね。Valuesの中でも『自律に基づくチームワーク』を特に意識しています。
「誰の何の課題を解決しようとしているのか？」
「組織や事業にどのような好影響を与えたいのか？」
全ての仕事はこれらを理解した上で進めていきます。
実際に、開発体制は「新規顧客にフォーカスするチーム」と「既存顧客にフォーカスするチーム」に分かれており、意思決定も全てチーム内で行うようにしています。
チームの意思決定に、僕は必要以上に干渉しません。もちろん困ったことがあれば相談に乗りますし、意思決定ができるように壁打ち相手になることはあります。ただし、あくまでも自分たちで考えて、自分たちで意思決定をするということを大切にしています。
――ビジネス部門との連携も行って開発をしているのですね。
はい。CS（カスタマーサクセスチーム）がHubbleを使ってくれているお客様の声を開発チームにしっかりと共有してくれるので、Churn Rate 0.1%という実績に繋がっていると思います。
しかし、お客様の声を反映するだけの開発は良くないと思っています。その理由は、お客様の想像の範囲内でのプロダクトになってしまうから。
僕たちは受託会社のエンジニアではなく、Hubbleの世界観を実現するためのエンジニアです。そのため、「プロダクトの世界観を実現するには、こういった機能があるべきだよね」、「お客様の使っているデータをみると、こんな機能を提供するべきなのではないか」といった、エンジニアだからこそわかる議論や情報発信、提案が不可欠です。
昨年までは、PMFのためにまずはお客様の声を大切にしてきました。今年は、お客様の声も引き続き大切にしつつ、エンジニアからの発信・提案にも注力していきたいと思っています。
これができると、ビジネス的感覚を持つ、強いエンジニアになれると信じています。
・・・
“リスペクト”から生まれるフラットな関係性が強み
－－ビジネス部門とコミュニケーションをとる上で、実際の距離感はいかがですか？
ビジネス部門との距離は近いですね。実際、商談の情報も開発チームに共有されています。その際に、受注した理由も受注できなかった理由もしっかり共有されるので、自分たちが作った機能がどのように評価されているのかを自然と知ることになります。他にも、既存のお客様の声もCSチームから常に共有してもらっています。このようにビジネス的観点を意識しながら開発するのは、特徴的かもしれません。
――藤井さん自身がCTOの立場で意識されていることはありますか？
CTOとして技術的な側面での回答が期待されるかもしれないですが、僕が一番意識しているのは開発チームのカルチャーです。Purpose&Valuesに『人間性の好循環』というものがあるのですが、これを実現するためには、互いにリスペクトを持って、気兼ねなくコミュニケーションを取れる必要があると考えています。他者の意思決定が自分とは違う意見であっても、懐疑的になるのではなく、意思決定の裏側を理解しようとする姿勢を尊重しています。
例えばエンジニアですと、ソースコードをレビューする際に、自分だったら違う書き方をするな、と思うことが多々あります。この時に、それを押し付けるのではなく「●●さんの書き方はおそらくこういう意図があると思う一方で、メンテ性を考えるとこう変えた方が良いと思うのですが、どうでしょう？」と言ったような提案ベースでお互いにコンセンサスをとるレビューを依頼しています。「相手を助ける」という意味でのレビュー体制にしたいと思っているので、このようなカルチャー作りはかなり重視しています。
物事を謙虚に受け止め、相手の発言を否定ではなくアドバイスとして傾聴できる関係性が作れれば、より成長につながっていくと思っています。
――そういったフラットに意見が交わせるカルチャーは、プロダクトづくりにどんな良い影響をもたらしているのでしょうか？
意見がぶつかったからこそ、ある機能が実装完了に至らなかったケースも多々あります。その時は盛んに議論が行われ、僕としてもスピード感のある実装が出来ないもどかしさがありました。しかし、後で振り返ってみると、その機能を実装しなかったからこそプロダクトの軸がぶれなかった、と気付きました。
議論が生まれるということは、様々な角度からの意見が入るということです。もちろんトップダウンで押しこんだりはしません。アイデアに対して、時には否定も含めて議論が交わされることは、強みだと思います。
――最後に、今後のHubbleの展望と、これからHubbleの仲間に加わることの魅力について、改めて教えてください。
Hubbleは、PMFを達成したことで、自分たちが正しい方向に進んでいることを確信し、市場にプロダクトのニーズがあることも証明しました。今後は、増え続ける顧客に安定したプロダクトを提供すると同時に、新しいサービスや機能を提供することに挑戦します。
先に述べたように、ビジネス部門と連携して、自分たちでプロダクトを開発し、顧客の声を直接聞くことができる環境は非常に貴重だと思います。この環境で開発したい方にとって、チャレンジングな環境であることをお約束します。
また、僕らはメンバー個人のキャリア、成長に通じる環境を提供したいと思っているので、そういった部分に魅力を感じる方の応募を待っています。現在社内のエンジニアは少数精鋭ですが、テックリードやマネージャーといったポジションも絶賛募集中ですし、責任あるポジションでキャリアを形成していきたい方にとっては、本当に今がチャンスだと思います。
さらに言えば、開発メンバーには、Hubbleが成功していくにつれてリーガルテックやSaaSの界隈で著名人になってほしいという思いもあります。例えば、「Hubbleのテックリード」という肩書で世の中を渡っていけるようなエンジニアになってほしいので、対外的なアピールでも全力でサポートしていきたいです。そういった方にも魅力的に感じてもらえるよう頑張っていきたいですね。
リライト・撮影
しらき なお：@naxano__