今回は創業期メンバーの1人・フロントエンドエンジニアの齋藤の社員インタビューです！2021年のインタビューを、現代版にリライトした内容でお届けしています。

「この人と働いたら面白そう」から始まったHubbleのエンジニア第一号

――これまでのご経験と、今Hubbleで担当されていることについて教えてください。

フロントエンドエンジニアとして、2018年7月に入社し、Hubbleのエンジニア1号として、プロダクトローンチ前からチームに参加しています。

現在は、フロントエンドの開発と環境整備に焦点を当てて取り組んでおり、正社員のエンジニアは8名と多くはないため、仕様策定や設計などの必要な分野でサポートしています。

エンジニアとしてのキャリアは、アメリカ在住時に出会った友人の起業への誘いから始まります。その時にHubbleのCTOである藤井もいました。藤井はすぐに離脱してしまいましたが、私はフロントエンドの仕事を引き受け、藤井の提案によりAngularJSを採用し、そこからフロントエンドエンジニアとしての道を歩むことになりました。

そこでプロダクトを作り切った後、帰国してSESの企業へ転職します。

――その後Hubbleで藤井さんと再会となりますが、ジョインのきっかけを教えて下さい。どういった想いでHubbleに入られたのでしょうか。

「またいつか一緒にしよう」と言って去った藤井から久しぶりに連絡が来たのがきっかけです。初めはフロントエンドに関する相談を少しだけ受けていたんです。その後、藤井がCEOの早川と起業することになり、「フロントエンド、やらない？」と誘われ、参加することにしました。

最初は業務委託としてジョインしていたのですが、後に正社員になります。当時いたもう一人のエンジニアと一緒に、従業員第一号となりました。

ーーどういった想いでHubbleに入られたのか教えてください。

当時は、Hubbleについてまだはっきりしない段階でした。そのため、会社やプロダクトに共感したというよりは、前から「できる人」という印象があった藤井と一緒に働くのが面白そうだと思ったのが大きかったです。あとはAngularを使っていた前職ではもう学ぶことがなく、新たにプロダクトを一から作りたいと転職を考えていた時期でもありました。

実際、プロトタイプもない状態で、「ビジネス版GitHubを作りたい」というアイデアからスタートし、法務関係者が使いやすい形をどう作るか、みんなで仕様を練りました。

CEOの早川については、典型的な社長らしさはないけれど、モチベーションと熱意が強く、サポートしたくなる人です。社長というよりは、嫌いになれない後輩のような感じで（笑）、それも入社した決め手の1つです。

課題を解決できるなら、新しい技術もすぐに採用する文化

――齋藤さん自身が感じている、Hubbleでの開発の面白さは何でしょうか？

正直に言うと、僕はリーガルテック自体にはそれほど興味がありません。その理由は、法務やリーガルの分野がエンジニアにとってはかなり遠い領域にあるから。だから、最初から「法務の業務を改善したい」と考えるエンジニアは少ないと思いますし、僕自身もそうです。

ではなぜHubbleの開発を続けているかというと、Hubbleは僕の「遊び場」なんです。

たとえば一般的なプロダクト開発では、ユーザーの要望に応えることで仕様が徐々に変わり、元のプロダクトビジョンから外れることがあります。しかし、Hubbleでは「この要望に応えるにはこの方法が良いのでは？」と提案し、検討してから実装し、その結果を評価します。私たちは「まずはやってみて、うまくいかなければ新しいことに挑戦しよう」という、フットワークが軽く柔軟に動けるマインドセットがあるんです。

新しい技術の採用は、その良さが見えれば迅速に行います。実際にNgRxのComponentStoreは、情報が少ない中でも試行錯誤しながらも早期導入をしました。また、AngularのSignalなども少しづつですが、利用を始めています。

「モダンなツールを使っている＝モダンな開発」とは限りません。重要なのは、そのツールをどのように使うかです。「この技術を導入することで、この問題が解決できるだろう」という仮説が立てば、対応は迅速になります。これがHubbleの開発における技術的な面白さの一つだと考えています。

――Hubbleの開発組織としての文化を教えてください。

スタートアップの中でも、Hubbleは特に技術の更新を素早く行う文化が初期から根付いていると思います。一般的なスタートアップでは、開発速度を優先し、技術的な負債の返済に時間を割けないことが多いです。結果として、レポジトリのメンテナンスが行き届かないこともあります。技術の変更は、シリーズが進んで開発チームが充実してから行われることが多いかもしれません。

もちろん、今この瞬間の瞬発力はスタートアップにとって不可欠ですが、長期にわたる成功のためには、適切な技術への切り替えと正しい方向への舵取りが重要です。

「その過程でスピードが落ちるのでは？」という疑問もあるでしょうが、技術負債が蓄積されるほど、開発速度は次第に鈍化します。さらに、組織やプロダクトが成長するにつれて、大規模な調整を加えることは困難になります。Hubbleは現在シリーズAの段階ですが、今から取り組むことが大切だと考えています。

興味こそ最強。そこから生まれるフラットなチームワーク

――現在の開発のチーム体制はどうでしょうか。創業初期から携わってきて、組織や文化が作られていく過程にも関わってこられたのではと思います。

僕が主に取り組んできたのは、組織作りというよりは、むしろ交通整理のような役割ですね。たとえば、開発のリリースプロセスをAsanaで整理するなど、業務をスムーズに進めるために、誰かが指揮を取る必要がある部分です。また、プロダクトマネージャーやデザイナーなど、足りない部分を補うための提案も行ってきました。

ただ、僕たちの組織には、役割上のマネージャーや責任者はいても、上下の階層は存在しません。CTOを含め、皆が気兼ねなく、リラックスして仕事をしています。今後も、リーダーが必要になれば任命すると思いますが、互いに意見を自由に交わせるフラットな関係性を維持していきたいと思います。

――少人数ということもあり、お互いに足りない部分を補い合いながらながら開発するということですね！

「イイ感じ」に言えば、そうですね（笑）。実際には、「この部分が遅れそうだ」と気づいたら、「では、こちらで巻き取ります！」という感じです。お互いに様子を伺い合いながら支援するのではなく、もっと積極的に、各メンバーが自主的に判断してタスクを引き受けるということですね。チームメンバーは皆、自律していますので、「これ、どうしよう？」という状況になると、それぞれが判断して行動を始めます。

――その関係性の秘訣はなんでしょう。大事にしている考え方などはありますか？

Hubbleには「自律に基づくチームワーク」というValuesがあります。

「誰の何の課題を解決しようとしているのか？」「組織や事業にどのような好影響を与えたいのか？」を一人ひとりが考えて動いているため、自然とこの関係性が生まれたんだと思います。

あと、僕が働きたいと思う人は、自分で興味を持ったものに実際に「触れる」人です。そのような人は、教わることを前提としないため、自然と自律するようになるでしょう。

ただ技術ブログを読むだけでなく、「実際に触れる」ことが大切です。そうすることで、提案やアドバイスがより重みを持ちます。それにより、相手の意見をきちんと聞き、自分も実際に触れて考え、意見を言うようになります。

その結果、他のメンバーの仕事の大変さをそれぞれの経験から理解し、自分の手が空いていればサポートする判断ができます。結果として、先に述べたような積極的な「補い合い」が可能になります。

――働き方の面での特徴はありますか？

現在、僕含め開発チームは大半のメンバーがリモートで働いており、ほとんど出社していません。勤務時間もフルフレックスを採用しているので、勤務時間は自由です。僕の場合、午前中はよく子どもと遊んでいます。ただし、Slackを常にチェックし、コミュニケーションの遅れがないように心がけています。

基本的には、パフォーマンスが良ければ問題ないというのが僕たちの方針です。開発においては、割り当てられたタスクだけでなく、他にもやるべきことは多くあります。これらを含めて、本質的に必要な仕事が達成できるように、自由に働いています。

これがHubbleらしい働き方だと思っています。また、Hubbleでは家族やプライベートを優先する文化があるのも、非常に助かりますね。

――最後に、これからHubbleにジョインされる方に向けて、メッセージを頂ければと思います。

僕個人としては「飽きたらすぐに辞めることができる人」と一緒に仕事をしたいと思っています。これは、ポジティブに辞めることができる人は、興味がある間はモチベーションが高く、様々なことに積極的だと思っているから。僕自身も、仕事をしながらプログラミングを楽しんでいるような感覚なんですよね。楽しみながら面白いと感じることに取り組むことが重要だと思っています。

Hubbleでは、現在持っているスキルよりも、新しいことへの興味と積極性を重視しています。興味のある分野に積極的に関わり、常に学びながら一緒に成長していきましょう！