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

をミッションに掲げ、法務関連のドキュメント管理を効率化する新しいクラウドサービスを提供する「Hubble（ハブル）」。これを提供する株式会社Hubbleの開発に創業初期から携わってきた齋藤は、Hubble開発の魅力を、技術への「フットワークの軽さ」にあると話す。開発現場で大事にしている技術への考え方や、Hubbleならではの技術的な面白さとは。

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

――齋藤様の現在のHubbleでのお立場も含めて、簡単に自己紹介いただければと思います。

肩書はDeveloperで、業務としてはフロントエンドの開発や環境整備に取り組んでいます。エンジニアは正社員が4名と少ないこともあり、仕様策定や設計など、必要なところのフォローにも入っています。

エンジニアとしてのキャリアのスタートは、アメリカに住んでいた頃に知り合った友人が起業する際に誘われたことでした。そこには現在HubbleのCTOである藤井がいました。その後、藤井はすぐに離脱してしまったのですが、私はフロントエンドをやることに。藤井の提案でAngularJSを採用していたので、そこからフロントエンドエンジニアとしてのキャリアが始まった形です。

その会社でプロダクトをなんとか作りきった後、Angularで開発できるところを探してSESの会社に転職しました。

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

「またそのうち一緒にやろう」と言って去った藤井から久々に連絡があり、最初はフロントエンド周りの相談を少し受けていました。その後、藤井が早川とともに起業するという話になり、「フロントエンドやらない？」と誘われ軽い気持ちでジョインしましたね。最初は業務委託として数か月やり、その後正社員になりました。もう一人のエンジニアの長濵と同時で従業員第一号です。

当時はまだHubbleとは何なのか曖昧な段階でした。なので会社やプロダクトに共感したというより、以前から“できる人”という印象だった藤井と一緒に働いたら面白そうだという想いが大きかったです。Angularをやっていた前職で得るものがなくなって、そろそろゼロからプロダクトを作りたいなと転職を考えていたのもあります。

実際、プロトタイプすらない、「ビジネス版GitHubを作りたい」というアイデアの段階から、どういった形にすれば法務の方に使ってもらえるのか、みんなで仕様を考えましたね。

ちなみに、CEOの早川の印象としては、いい意味で社長感はなくて。モチベーションや熱意がすごくあって、サポートしたくなる。社長だけど憎めない後輩みたいなタイプだなと(笑)。それが意外と面白かったです。

＊前のオフィス近くで撮った写真。左が長濵。右がCTO藤井。

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

――現在のHubbleの開発について教えてください。齋藤さん自身が感じている面白さは何でしょうか？

はっきり言ってしまうと僕はプロダクト自体にはあまり興味がありません。というのも、法務やリーガルってエンジニアにとっては遠い領域なので、最初から「法務の業務を改善したい！」という動機のエンジニアは少ないと思っていて、僕も同様です。

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

例えば、プロダクト開発では、ユーザーからの要望に応えて仕様が徐々に変更された結果、今まで考えていたプロダクトのビジョンからずれておかしくなってしまうことってあると思うんです。でもHubbleでは、「その要望に応えるためにはこういうアプローチしたらいいんじゃない？」と提案、検討し、実装してみてよしあしを判断します。「とりあえずやってみて、ダメならまた新しいことをやろう」といった、フットワーク軽く動くマインドがあるんです。

新しい技術を入れるにも、良さそうだったら即採用します。新しく出たばかりのライブラリでも、コントリビューターがいてメンテナンスもされているちゃんとしたものだったら、事例が少なくても入れてみようと判断します。実際、NgRxというライブラリのComponent Storeが新しく登場した際にすぐ採用しました。

ただし、モダンなツールを使っている＝モダンな開発ではなく、どう使うかが鍵です。「この技術を入れることによって、この問題が解決されそう」という仮説があれば、フットワークは軽いです。こういった点がHubbleの開発における技術的な面白さだと思います。

スタートアップの中でも、Hubbleは特に技術のアップデートをさくっとやる文化が初期から根づいていると思います。一般的なスタートアップでは開発スピードを上げることに注力し、技術的負債を返済する暇がなくレポジトリがメンテナンスしきれていない場合もしばしばではないでしょうか。技術の変更も、シリーズがある程度上がって開発メンバーが潤沢になってから、というケースが多いかもしれません。

もちろん、今この瞬間の瞬発力というのはスタートアップに必要で大事ですが、それでも長く続けていくためにはどんどん適切な技術に変えて、正しい方向にハンドルを切っていくことが重要です。「その分スピードが落ちないか？」と突っ込まれそうな気がしますが、技術負債が溜まるにつれ開発スピードはだんだん遅くなっていきますよね。それに、組織やプロダクトが拡大するほど大きくテコ入れするのは難しい。Hubbleは現在シリーズＡの段階ですが、今からやっていくことが大事だと考えています。

やり方としては、機能開発の見積もりの際に取っておいたマージンが余ったら、その時間を将来のコードの健全化に当てています。

＊初期の頃の開発風景。後ろはCEO早川(右)とCTO藤井(左)。

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

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

僕が主にやってきたことは、組織作りというより交通整理でしょうか。例えば、開発のリリースまでの流れをAsanaで整理するなど、業務を円滑にするために誰かが旗を振らなければいけない部分です。また、プロダクトマネージャーやデザイナーなど足りない部分に足してこうという提案はしていますね。

しかし、上下の組織はありません。CTOも含めて忖度なく楽にやっています。これからも、リーダー的な存在は必要になれば立てると思いますが、フラットにお互いに口を出し合える関係性は続けていきたいですね。

＊CTO藤井とのディスカッションの一コマ。一切忖度なく進めています笑。

――少人数ということもあり、お互いに足りない部分を補い合いながらながら開発する文化なのでしょうか？

イイ感じに言うとそうですね(笑)。実際は「ここが遅れそうだな」と気付いたら「じゃあこっちで巻き取ります！」みたいな。お互いの顔色をうかがいながらサポートするのではなくて、もっと積極的に、メンバーそれぞれが主体的に判断して仕事を取りに行く、と言うと分かりやすいでしょうか。みんな自立しているので、「これ、どうしましょう？」となった時点で、個々人が判断して動き出します。

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

みんな自立駆動型であることと、興味をもったら実際に「触る」というのは大きいと思います。僕が一緒に働きたいと思う人も、自分で興味を持ったものを実際に「触る」人。そういう方は、教えてもらう前提ではないので、自然と自立した人になるのではないでしょうか。

ただ調べて技術ブログを読むだけではなく、「実際に触る」というのが重要です。そうすると、何か提案やアドバイスするにも言葉に重みが出るんですよね。だからこそ、相手の意見にもきちんと耳を傾けるし、自分も実際に触って考えて、意見を言おうとなります。

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

――実際に手を動かして経験するからこそ、相手にリスペクトをもってアドバイスし合えるんですね。 となると、色々な技術に興味を持てる方を求めているのでしょうか？

そういうわけではなく、これからジョインする方は、フロントエンドエンジニアだったらAngularに専念してもらえればよいと考えています。その上で、色々やりたい気持ちがあればもちろん尊重します。

さっきの話と若干矛盾するように感じるかもしれませんが、専門以外ができないから微妙だとは全く思いません。専門領域を深く伸ばしてもらえれば十分です。能力があれば「こういうこともやってみない？」といった打診はあるかもしれませんが、それもつまらなそうだったら断ってもらってよいです。

というのも、必ずしも多彩な人が補い合える人じゃないんですよね。一つの領域に特化していても、そのスキルがない他のメンバーにとっては強力な補いになります。なので、重要なのはやはり事柄に対して興味を持っていて、ちゃんと調べて触っているか。それが広く浅くても、一点に特化して深くてもいいんです。今いる3人のエンジニアが比較的広く浅いタイプなので、得意な人が得意なところをやればいいという考え方です。そういう意味では、今後いろんな性質の方が入ってほしいですね。

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

現在、僕含め開発メンバーはほぼリモートワークで、2020年2月以降ほとんど出社していません。フレックスなので働く時間帯も自由で、僕の場合は午前中は子どもと遊んでいることが多いですね。ただ、Slackを常にチェックしてコミュニケーションが遅れないようにしています。

基本的にパフォーマンスが出ていれば問題ないという考え方です。例えば開発であれば、積まれたタスク以外にもやるべきことはたくさんあるので、それも含めて本質的に必要な仕事が達成できるように、自由に働く。これがHubbleらしい働き方ですね。また、家族やプライベートを優先する文化があるので助かっています。

＊プライベートでは2児のパパ。優しい一面も持ち合わせているエンジニア。

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

個人的には、「飽きたらすぐ辞められる人」と働きたいと思っています。どういうことかというと、ポジティブな辞め方をできる人は、興味を持っている間はモチベーション高く、色々なことに協力的だと思うんです。僕自身もそういう考え方で、仕事しながらプログラミングで遊んでいるような感覚。楽しくて面白いからやるというモチベーションで、まるで趣味のように取り組むのが強いと思います。

Hubbleは、今持っているスキルよりも、新しいものへの興味と行動力がある人と一緒にやっていきたいと考えています。興味があるものには足を突っ込んで、常に勉強しながら一緒に成長していきましょう！