開発者のみなさん、普段どんな言語やフレームワークを使って開発していますか？Hubbleのフロントエンドチームでは、Angularを使って開発を行っています。

正直、使っている人口が少なく、古いと思われがちのAngular。なぜこのフレームワークをHubbleでは使っているのか…。このnoteではその謎を解明していきます！

Angularが好きなのには理由があった

白木：Angularって、正直使っている人口はとても少ないですよね。エージェントからも「新規の応募者がかなり少なくて紹介が難しい…。」と共有を受けています。そんな中、なぜHubbleでは数あるフレームワークから、あえてAngularを選んだのでしょうか？

齋藤：一番の理由は「好きだから」なんですよね（笑）。今日はこの「好きだから」を分解してお伝えしますね。

1つ目の理由は、オールインワンだからメンテナンスコストが低いところ。今でこそNext.jsのようなフレームワークもありますが、当時はReactだったら「Reactと●●と●●を使うとエンタープライズレベルのアプリケーションが作れます」みたいな感じで、当時はいくつも組み合わせて作る必要があった中、AngularはAngularだけで全てを完結させることができました。

組み合わせて開発すると、個々の思想が違うから絶妙に合わなかったり、バージョンの互換性を気にしたりする必要があるんですよね。

白木：その状況に対応するというのが、なんだか面倒くさそうですね。

齋藤：そうなんですよね、普通に手間なんです（笑）。メンテナンスをしないといけなくなった場合、Hubbleのような少人数で開発している会社は、開発がストップしかねません。

白木：この規模の会社において「Angular1つにまとまっている」というのは、魅力的な要素の1つだったんですね。

齋藤：もう1つはバージョンをあげるのが異常に楽なこと。Angularも含めて、システムってバージョンがどんどん上がっていくんですよね。上がることによって、新しいことができるようになったり、修正が加えられたりします。

その中で、破壊的な変更って絶対に起こってしまうんです。

白木：破壊的な変更…？

齋藤：バージョンを上げたことで「コードを書き直さないといけない」みたいなイメージです。この作業に、1週間や長いと1ヶ月くらいかけることもあるんです。

白木：ひぇぇぇ…

齋藤：バージョンをあげたりコードを書き直すことをマイグレーションというんですが、Angularだとそれをほとんど自動でやってくれるんです。Angularはこのマイグレーションのサポートが非常に充実してて。

白木：ちなみに…もしもバージョンをあげないなんてことをしたら、どうなるんでしょうか？

齋藤：脆弱性が生まれたり、不具合が発生したりと、良くないことだらけです。だからこそそういったことがなるべく起こらないように、最新のバージョンに対応していくことが求められます。そして、最新のバージョンを保ち続けられる工夫をAngular自体がしてくれているんです。会社で開発する上で、こういった要素はすごく大事だと思うし、僕がAngular好きな理由の大部分を占めています。

なのに、なぜか少ないAngular人口

白木：今までのところを聞く限り、他の会社は何故使わないんだろうって思っちゃいました。

齋藤：いや、僕も思っています（笑）。メリットを多く伝えてきましたが、デメリットを一言にまとめて伝えると「流行っていない」んです、Angularって。

白木：たしかにエンジニアの方々って、最新の技術とかを好きな人が多いイメージですね。

齋藤：みんな好きですねー。流行っていない理由はシンプルで、Angularって割と保守的で、これまでは新しくはなかったんです。本当はもっとWebの技術って進んでいるのに、そこをいきなり採用せず、少し前のところで色々やっているような。なので新しい技術を取り入れたりやってみたいと思うエンジニアからすると、「Angularだとこれができない」とか「古い」とか、そういった反応をよく聞きました。

白木：「古い」と言われてしまうレベルって、どれくらい遅れているんですか？

齋藤：例えばVueとかReactは新しいものを割と早く追ってるんですけど、Angularだとそれらから1,2年くらい遅れてるんじゃないかな。これだけ遅れると、新しいものを学習したい人からすると、Angularじゃないってなっちゃいますよね。

ただ、声を大にして言いたい。最近はAngularも最新技術を徐々に取り入れるようになってきたんです！だからこそ、「Angularは古いから」という理由だけで遠ざけていた方には、ぜひ今のAngularを使ってみてほしいですね。今後はさらに最新技術に追いついていけるような動きをしていくと思います。

白木：これまで流行っていないからこそ、Angularを使えるエンジニアも少なくて、だから進化していることも知られていなさそうですね。

齋藤：Angularを使えるエンジニアが結局少ないから、相談相手もいなかったり、検索しても記事が少なかったりと、勉強のやりにくさは一定あると思います。あとはなぜかAngularって初心者が学ぶのに難しいと思われているんですよね。

白木：実際に「思われている」だけなんですか？

齋藤：確かに習得するために覚えることはたくさんあります。冒頭で伝えたように、オールインワンなので全部覚えないといけないんです。たとえばReactを使っているときはAという部分だけ覚えれば良かったのが、Angularは最初からA＋その他全部覚えないといけない。実際は難しいわけではないんですけど、最初に覚える量は実際に多いので、難しいと思われてしまいがちなのかもしれません。

白木：「全部作る！」となれば学習コストのボリュームが同じだとしても、一部を切り抜くと学習コストが多く見えてしまう、という感じですね。

齋藤：結局はあまり変わらないんですけどね。あとは、学習コストが高いと言われていることにAngularのチームも気づいていて、確実に改善に動いています。チュートリアルもかなり豊富になりましたし、そのうち学習コストが高いという印象も薄くなっていくんじゃないかな。

エンジニアチームのオンボーディング期間は「1年」

白木：先ほどAngular経験者が少ないという話をしましたが、Angular未経験の状態でHubbleに入社するということは可能なのでしょうか。

齋藤：可能です！

白木：最初の学習コストはどうしてもかかってしまうみたいだから、オンボーディング期間というか、業務に慣れるまでは時間がかかりそうな印象です。

齋藤：どれくらいかかるというより、Hubbleのフロントエンドでは「オンボーディングは1年かけてやる」と決めています。ここにはプロダクトの理解や仕事の進め方なども含まれているので、1年後には1人で推進してもらえるようにする、というイメージです。

白木：1年は結構長いですよね。どんなことをやっているんですか？

齋藤：入社初日からAngularを使ってコードを書いて欲しいとか、そういったことはありません。「Hubbleでこういったコードの書き方をしているのは、こんなメリットがあるから」というのを理解していただきつつ、小さいものから実際に実装してもらって、実装するためにはどれくらいの工数がかかるのかの見積もりを出せるようになってもらいます。ここまでを半年くらいかけてすり合わせます。そして、実際1年後には自分で見積もったものと数字が合ってくるようなイメージです。

白木：であればAngularを使ったことがなくても、Hubbleのプロダクトや会社に共感してくれる方であればウェルカムな感じですね！

齋藤：ですです。Hubble には Values が 5 つありますが、その中でも「自律に基づくチームワーク」を体現できるようにサポートするイメージです。

白木：ちなみに、入社した後に「●●を実現するために、Angularではない別の言語/フレームワークで開発をやりたい」というのは可能なのでしょうか。

齋藤：もちろん将来的には可能性はあります。ただ、現状のHubbleだと難しいです。シリーズAでこれから成長していくフェーズの企業なので、Angularではない別のものに切り替えるコストが高いですし、会社としてそこにコストを投下するという判断は難しいです。

白木：スタートアップだからこそ、どこに工数やコストをかけるかっていうのは重要ですよね。

齋藤：そうなんです。なので経営判断として、今すぐに別の言語に切り替えることは、まずありえません。
あと、Hubbleではお客様のニーズに応えるためにプロダクトを展開していく予定ですが、プロダクトごとに言語を変えるのも壁があります。Angular同士だからデザインシステムの実装も1つで済みます。でも言語を変えれば一つずつ書き直す必要があります。なのでそこにコストをかけられるくらいの規模になるまでは、プロダクトごとに言語を変えるのも現実的ではないと思っています。

白木：将来的にHubbleがしっかり利益を出せるようになったら、開発の自由度も上がっていくイメージですかね？

齋藤：そう！まずはしっかりと『Hubble』というプロダクトをより良いものにして、会社としての成長を支えるところにフォーカスできればと思っています。

白木：Angularが好きな理由だけでなく、オンボーディングや今後の展開までお話いただきありがとうございました！