Hubbleのバックエンドエンジニアはこれまで、主にRubyを使用し、時折JavaやPythonでの開発も行ってきました。

そして昨年からはGoを使用した開発も始まりました。この変更はあるメンバーの提案によるものだそうです。今回はGoの導入を提案した中島と、バックエンドを現場から支えるCTOの藤井による対談をお届けします！

Hubbleのバックエンドは、Rubyがメイン

白木：まずはお互いの紹介をお願いします！ 

藤井：他己紹介にしようか！中島くんはリードエンジニアとしてバリバリコードを書いてくれるエンジニアでありながら、コードオーナーとしてもバックエンドのソースコード全体に責任を持って活躍しています。彼が入社して2年半くらい経つので、バックエンドチーム内で僕の次くらいにHubbleについてよく知っている人だと思います。

中島：克也さん（藤井の社内での呼び名）は、初期にはバックエンドエンジニアとして積極的に開発に携わっていました。組織が成長し、最近ではCTOとしての役割や業務が増えています。技術的な観点から事業のディスカッションに参加することが多く、経営の意思決定にも関与する場面が増えている印象です。

白木：採用に関しても、スカウト活動に一緒に取り組んでもらうなど、創業当初には手がけていなかったエンジニアリング以外の業務をお願いすることが増えていますね。それでは、続いてHubbleのバックエンドチームについての紹介をお願いします。

藤井：Hubbleのバックエンドチームは、主にRuby on Railsを使用して開発を行ってきました。創業時にこの選択をした理由は、日本でバックエンドの開発にRubyを使用するエンジニアが比較的多いと思っていたから。メンバーを集める観点でも、Rubyを選択することにしました。

中島：当時はAirbnbやGitHubもRailsを使っていましたね。

藤井：僕たちと同じ理由でRailsを採用している企業も多いと思いますが、そのために競合が多く、結果として採用が難しいということに後から気づきました（笑）。

白木：バックエンドのチームメンバーはどうでしょうか。

藤井：現在、バックエンドは正社員が4名、業務委託が5名です。業務委託のメンバーはほぼフルタイムで働いており、経験も豊富です。そのため、実際の役割においては、雇用形態が異なるだけで正社員と大きな違いはありません。あとは先月（2024年1月現在）から、初めてSREのメンバーもジョインしました。

Goを採用した2つの理由

白木：創業以来Railsをメインに使ってきた中、今回どのような背景でGoを採用することにしたのでしょうか。

藤井：Goを採用する理由は大きく分けて2つ。まず1つ目は対外的な理由で、人材採用の幅を広げたいという点です。先ほども触れましたが、Railsを採用している企業が多く、エンジニアなら「誰でもGoにはちょっとは興味がある」という傾向があると思います。これが対外的な理由の1つです。

白木：いつ頃から考えていたのでしょうか。

藤井：実は、結構前から「Railsだけでいいのだろうか」と悩んでいたんです。ただ、新しい技術を何でも受け入れてしまうと、その分リスクもあるわけで。それが少し怖かったんですよね。Goだったら大丈夫かな、どうやって進めていこうかなと考えていたところで、中島くんが「やりたい」と言ってくれたこと。これがもう1つの大きな理由でした。

中島：克也さんからは常に「自分のやりたいことに挑戦してほしい」というメッセージをもらっていました。僕自身も、そして会社としても、共通して挑戦したいと思っていたものがGoでした。

藤井：実際、中島くんの実力を考えると、ゼロからでもある程度のレベルまで開発を進められるだろうと考えていました。そのため、HubbleでGoを採用する第一歩は、中島くんに踏み出してもらうことにしました。

白木：新しい領域に挑戦するにあたり、中島さん個人としてGoを選択したのは、どのような観点からの決定だったのでしょうか？

中島：トレンドとして来ているので、エンジニアとして挑戦してみたかったんです。これまでの自分の経験とは違う領域だったので、新しいことに取り組むのが魅力的に感じました。

藤井：中島くんって、（経験しているのは）PythonとPHPだっけ？

中島：そうです。その上で、Hubbleでは主にRubyを使っていますが、Rubyを含めてこれまで僕が扱ってきたのは動的型付け言語です。一方で、Goは静的型付け言語で、コンパイルが必要など開発の進め方が異なります。だから、このような環境でのWeb開発がどうなるのか、非常に興味がありました。

藤井：多分これはエンジニアなら誰もが共感すると思います。「静的型付け言語を使ってみたい」、「Goのようなトレンドを追いかけてみたい」という考えは、一度は持ったことがあるんじゃないかな。実際、採用の面談でも「Railsは経験しましたが、次の言語にも挑戦してみたい」と話す方にはよくにお会いします。だからこそ、今回の会社としてのGoへの挑戦は、僕たちにとっても大いに歓迎するものでした。

白木：バックエンドだとRails経験者はなぜ多いのでしょうか。

藤井：Railsが比較的初心者にも扱いやすい言語だから、というのは1つの理由だと思います。プログラミングスクールでもRailsを学べる所は多いですし。プログラミングスキルが向上するにつれて、多くの人が他の言語に挑戦し始める傾向があります。特に現在は、Goを選択する人が増えているんじゃないかな。

Goでの開発に取り組んでみて

白木：社内で「Goやります！」というのは、どのようなプロセスや流れで決まったのでしょうか。

藤井：プロセスはないんだよね…（笑）。ただ、日々バックエンドチームと話す中で、Goを使ってみたいという話を持ちかければ、誰かが『やりたいです』と言ってくれるだろうとは思っていました。

中島：Goを採用したいという最初の発信は克也さんからでしたが、その後のプロセスはチームメンバーが自主的に手を挙げて進めていきました。克也さんは、技術選定に関しても、RubyかGoかはメンバーに任せると言ってくれていました。僕たちとしてもまずは小規模から始めたかったので、審査依頼フォームの機能追加時に初めてGoを使ってみたんです。

藤井：Hubbleの一機能であるものの、独立したアプリケーションだったため、もし何か問題が起きてもHubble本体に影響が少ない、というのも新しい言語に挑戦してもらうには良かったかなと思います。

白木：実際にGoで開発してみてどうでしたか？

中島：成果としては、Rubyで開発した時に比べて、バグが少ないように感じます。Hubbleでは、カスタマーサクセスチームがお客様からのお問い合わせを受ける際にIntercomを利用しています。

中島：Intercomからのお問い合わせはSlackにも流れるように設定しているので、僕らもそれを見ています。審査依頼フォームに関しては、バグやエラーに関する問い合わせがほとんどなかったんじゃないかなと思います。

藤井：確かに、「本当に使われているのかな？」ってくらいバグ報告はないね（笑）。

白木：言語が違うだけで、そんなにバグが出にくい等影響があるんですか？

中島：言語自体の違いというよりは、さっきも触れた動的型付け言語と静的型付け言語の違いが大きいですね。静的型付け言語では、コンパイル時に型エラーなどが厳密にチェックされるので、バグが起きにくいんです。一方、動的型付け言語では、実行時まで型エラーが明らかにならないことが多く、その結果としてバグが発生しやすくなることがあります。これは一般的によく言われることです。

言語選定は適材適所、必要な技術を選定できるように

藤井：実際にRailsで開発していると、「さぁ本番いくぞ！」と本番環境でプログラムを動かすときに「ここが間違っています」というエラーが出るんですよね。しかし、Goのような静的型付け言語では、開発途中で「この部分が間違っています」と指摘してくれるんですよね。だから、実際の運用時にバグが起きにくい。

白木：ここだけ聞くと、静的型付け言語の方がメリットが多く感じますね。

藤井：そうですよね。でも開発スピードに関しては、動的型付け言語の方が速いんです。開発スピードと安定性のトレードオフかな？Hubble社内の問題点としては、 Goで開発を始めたは良いものの、Goのレビューできる人が少なかったんです。最近ではGoの経験者を迎え入れて解決しましたが、それまでは中島くんが実質セルフマージ、という状況になっていた気がする。

中島：確かにそうでした（笑）。もしかすると近い将来、コードのリファクタリングや一部の巻き戻しが必要になるかもしれませんね。 

白木：じゃあ今のHubbleのバックエンドにおいては、RailsもGoもできるって人は歓迎ということですね。

藤井：そうですね。ただ、あくまでRails、あわよくば両方という感じですかね。

中島：現在の段階で「Goしかできません」という方は、今のHubbleの環境ではバリューを発揮しにくいかもしれません。まだGoでの開発が主流ではないので。しかし、Goが得意な方で、Railsにもチャレンジしてみたいと思っている方がいれば、一緒に仕事ができるととても嬉しいですね。

白木：CTOとしての視点で、今後のバックエンドチームの方向性についてどのように発展させていきたいと考えていますか？

藤井：これまでは社内勉強会やバグ修正の分散アサインなどを通じて、属人化をできる限り避けながら、社内全体のスキル向上を目指してきました。今後はユーザー拡大に伴い、スケーラビリティを考慮した、アーキテクチャに関する再議論が社内で盛んに行われています。複数の言語、フレームワーク、サービスがどうコミュニケーションするべきか、その中での開発体験をいかに効率化していくか、こんなことが直近の議題ですね。

白木：中島さんはどうでしょうか。

中島：モダンな言語には一通り触れることができたと思っています。そしてこれからはその経験を活かして、サービスや機能開発に必要な技術を選択できるようになりたいですね。例えば、「このサービスは素早く構築する必要があるからRubyを使うべきだ」とか、「このサービスは規模が小さいからGoで効率的に作り、バグを最小限に抑えるべきだ」というような判断ができるようになりたいと思います。そういったもう一レイヤー上の視点を持って開発に臨めるようになることを目指しています。 

藤井：今回僕が特に学んだことは、冒頭でRailsとGoを比較したように、一見するとRailsは中学生、Goは高校生のようなイメージを持ちがちですが、実際にはそれぞれが適材適所であるということ。

逆に、Railsの可能性や良い点に目を向けると、基本的なルールに従えば、誰でも迅速に機能を開発できる。一方で、Goは速度面でも効率面でもRailsより優れているとされています。しかし、ただ単に『モダンだからGoを使うべきだ』というような、何も考えずに行う意思決定は、あまり良くないと感じています。

中島：言語選定は適材適所、これがすごく大事ですね。使い手側の力量が試されている気がします。特に今回言語周りのエコシステムが充実しているかなど、使うまでは考えていなかった所で、開発で詰まったりしたのでこれらはとても良い経験になりました。

白木：最後に、お二人は一緒のチームで働くメンバーにはどのような方にジョインしてもらいたいですか？

藤井：Hubbleの魅力の一つは、挑戦を奨励するカルチャーがあること。ここでは誰もが一定の権限を持ち、独創的なことに取り組める環境があります。だからこそ新しい挑戦に興味がある人にとっては理想的な環境だと感じています。それと同時に重要なのがコミュニケーション能力です。HubbleのValuesの1つである「自律に基づくチームワーク」沿って、周囲との連携がしっかりとれる人が求められます。

今後はビジネスサイドや他のエンジニアとのコミュニケーションが非常に大切だと思っているので、このような環境に興味を持ってくれる方とご一緒できると嬉しいですね。

中島：僕もほとんど同じです。新しいことに挑戦したい人や、技術にすごく興味があるなど向上心の高い人と一緒に働きたいですね。Hubbleでは本当に技術的にやりたいことは何でも挑戦されてもらえるので、そういう人は楽しめると思います。あとは目的を持っているのが理想的です。働く目的は人それぞれなので、お金を稼ぎたい、自由に働きたいでもなんでも良いです！（笑）どんな目的でも達成するために頑張れる人は魅力的なので、そのような人と一緒に働きたいですね。

白木：ありがとうございました！