「契約をデザインし、合理化する」

をミッションに掲げ、法務関連のドキュメント管理を効率化する新しいクラウドサービスを提供する「Hubble（ハブル）」。これを開発提供する株式会社Hubbleの最年少社員で、バックエンドエンジニアの中島は、「Hubbleの開発現場ならではの面白さがある」と生き生きと語る。新しい技術になんでも挑戦できる文化や、実際の開発チームの様子などを詳しく伺った。

◆チャレンジングなプロダクトと開発現場に惹かれた

――中島さんのこれまでのキャリアを含めて、自己紹介をお願いします。

バックエンドエンジニアの中島です。2021年の7月に入社して、主に新機能のAPIの開発・修正などをやっています。カスタマーサクセスチームを通して報告される不具合に対応したり、障害が起きた際のインフラの保守をしたりと、多様な業務に携わっています。

中学生のころに電子ドラムにハマり、DTMなどが技術に触れる入口でした。「パソコンってなんでもできるな」と魅了されたところから、情報系の大学に進んで、エンジニアになりました。

＊趣味のドラム。プライベートでは音楽好きでライブにも行くほか、料理も得意とのこと。

学生時代にはハッカソンにも参加し、卒業後、Web系の受託開発の会社で働いていましたが、自社プロダクトの開発をしたいともどかしさを感じていたんです。そんな時、Wantedlyで人事の山岸さんから声をかけていただいたのがきっかけでHubbleに入社しました。

――リーガルテックというニッチとも言える世界に飛び込もうと思ったきっかけは何だったのでしょうか。

リーガルテックを意識していたわけではありませんでした。どちらかというと、「Wordのバージョン管理」という誰でも抱えそうな課題を一つのプロダクトで解決する点に魅力を感じましたね。

技術的には、言語でいうと以前は主にPHPでしたが、HubbleではRubyやPython、Javaなど幅広く触れています。キャッチアップは必要でしたが、面白さもあったのでそれほど苦ではありませんでした。むしろ、メンバーの提案をどんどん取り入れる文化があるので、自分の意思でチャレンジできる技術が多い。Hubbleの開発現場の魅力だと感じています。

◆プロダクトの意思決定にも関わる

――Hubbleはどのようなチーム体制で開発されているのでしょうか。

社員が計5名、業務委託も含めると計10名の開発メンバーが在籍しています。役割としては、CTOをトップに、バックエンドエンジニア、フロントエンドエンジニアに分かれています。

日々何かしらのプロジェクトにアサインされて、開発していく中で、「技術的にこうした方がいいのではないか」と気になることがあったら、自らCTOに提案して取り組むこともあります。

加えて最近は、ちょっと面白い試みを行っていて。2022年1月から、「新規顧客の受注率向上を追うチーム」と「既存顧客のチャーンレート減少とNPS向上を目指すチーム」に分かれた部門横断型プロジェクトに取り組んでいるんです。これは、プロダクトマネージャーとカスタマーサクセスのメンバーとともに行うプロジェクトで、私は新規顧客向けの方に携わっています。

週に1回ミーティングを行い、プロダクトマネージャーが「こういうものを作りたい」というビジョンを持ってきて、カスタマーサクセス、エンジニアはそれぞれの立場から意見を出して、最終的に作るもののゴールを皆で決めていきます。

このプロジェクトの目的は、意思決定の流れをスムーズにして、目標を追いやすくすることです。従来一つのチームで開発していると、新規顧客向けの機能と既存顧客向けの機能のどちらを先に開発するべきか、優先順位を付ける必要が出てきて、その度に意思決定の工数がかかっていました。最初から2つのチームに分けてそれぞれの目標を追うようにすることで、少しずつ改善がみられています。

――なかなか「何を作るか」から、プロダクトマネージャー以外のメンバーが深く関わって議論する企業は少ないのではないかと思います。

今の少数精鋭の体制だからできているとは思いますが、実際に自分が意思決定にかかわった機能がお客さまからポジティブなフィードバックをもらえると、やりがいを感じます。Hubbleの開発現場ならではの体験だと思います。

――他にも「Hubbleの開発現場ならでは」と感じることはありますか。

技術的な面で言うと「これをやりたい」と提案すると断られることがほぼなく、自分の意思でどんどん進んでいけるので、すごくスピード感のある組織だと思いますね。

例えば、僕はデータベースの技術の移行を提案して、そのまま任せてもらいました。もともとAWSのRDSを使用していたのを、より可用性の高いAuroraに移行したんです。この経験で、自分にもいろんな知見が溜まったと思います。

移行の効果も出ていて、データベースがオートスケールして負荷分散させるのでレスポンスが速くなったり、どんなアクセスがデータベースに負荷を与えてるかが目視しやすくなったので、パフォーマンス改善に役立てられています。

大口のお客さまがいても、本当になんでもやらせてくれるのは、他にはない環境だと感じています。

◆「なんでも挑戦できる」文化を支えるコミュニケーション

――そのようにメンバーが自分から提案できるCTOとの関係性は素敵ですね。Hubbleの組織・文化的な魅力はどんなところだと感じていますか。

Hubbleの人たちはとにかくフラットです。役職はあっても、関係性はすごくフラット。自分が言いたいことが言えない雰囲気は一切なく、困ったことがあれば聞ける環境なので、ストレスがありません。経営陣とも距離が近いというか、いつでもすぐに話せる距離感が当たり前になっているところがすごくいいなと思いますね。

先述の、技術的なチャレンジを歓迎する文化も、CTOが相手の意見を否定せず、なんでも「やってみよう」とプラスに捉える方なので成り立っていると思います。否定されないから率直に意見も言えますし、受け入れることもできます。

そして、そのコミュニケーションは、部門横断のプロジェクトでも同様です。例えばですが、プロダクトマネージャーが「この機能を作りたい」と持ってきたものに対して、エンジニア視点で難しいと思ったとしても、否定はしないですね。その機能によって解決したい本質的な課題は何か、その課題に対して他に方法がないかを考えて、代替案を伝えるようにします。

＊CTO藤井には、積極的に提案をしています。

――円滑なコミュニケーションの文化が醸成されているんですね。一方で、Hubbleのエンジニリングにおける課題と、今後の挑戦は何でしょうか。

抽象度の高い課題でいうと、いわゆる大規模サービスの開発・保守したような所謂メガベンチャー出身メンバーはいないので、「この課題に対してはこの技術」という最適解を持っていない。ネットの情報を集めて「これなんじゃないか」と思う技術を愚直に試してみるとか、手探りで課題に立ち向かっているのが現状です。今後は知見を蓄積して、同じ壁にぶつかったときに参照できるようにしていかなければいけないなと思っています。

抽象度低くコードレベルで言うと、バグを減らして改修をしやすくするためにも、可読性の高いコードにしていく取り組みを、僕を中心に徹底しています。

――中島さん個人は、バックエンドエンジニアとしての目標やビジョンなどありますか。

以前はバックエンドもフロントエンドも全部できるエンジニアになりたいと思っていましたが、いろいろな技術に触れてきて、今はバックエンド一本で技術を磨いていきたいと思っています。新規機能を作るときにどうやってテーブル定義をするか、可読性の高いロジックを組むか、無駄のないSQLクエリを書くか...などパフォーマンス面を含めて、可能な限り完璧なコードを書くことに面白みを感じているためです。今はRubyやPythonを書いていますが、今後はGoも書けるようになりたい。これは開発チームとしての目標でもあります。

キャリアについてはCTOとも話していて、僕はマネジメントより技術のプロフェッショナルとして進んでいくことが、チームとしても個人としてもよいのかなと思っています。なので、技術で引っ張っていけるエンジニアになりたいですね。

CTOからも「Ruby Kaigiなどに出てみたら？」と言われていて、そういったカンファレンスに登壇することが今の目標です。