フロントエンド・バックエンドの技術スタックは？選定の背景を深堀り！ - 見えてきた”会社のカルチャー”との関連性

※この記事に掲載した写真は全て、撮影時のみマスクを外しています

こんにちは！EventHubでエンジニアをしている岡本（写真右）です。技術責任者・井関（写真左）にインタビューをしながらEventHubの開発体制について知っていただくこの企画、前回に引き続き私がお送りします✍️

前回の記事では、開発フローや組織の特徴、今後の課題など、EventHubのエンジニア組織についてその概要をご紹介しました。2回目のインタビューとなった今回は、技術選定の部分に焦点を当て、使っているプログラミング言語やフレームワークについてご紹介します。創業者CTOとして技術選定を行ってきた井関本人に、技術選定の背景を聞いてきました。

＜プロフィール＞井関 正也（いせき まさや）　　東京工業大学大学院修士卒業。2013年にFirefox(Gecko)のOSS開発に参加しコミッターとなり、その後、Google Chrome(Blink)の開発にも関わりコミッターとなる。その後、大学院にて暗号通信の研究に従事。研究成果を認められ2015年に産業技術総合研究所のリサーチ・アシスタントして暗号理論の研究に従事する。2015年に日本応用数理学会主催の研究会で特別講演として登壇。2016年に国内最大規模のセキュリティカンファレンスであるSCISにてイノベーション論文賞受賞。大学院在学中にEventHubを創業。

＜プロフィール＞岡本 正輝（おかもと まさき）　　アジャイル開発のトレーニングを提供していたテクノロジックアートに新卒入社。TDDやXPの講師を務める先輩方から熱い指導を受けながら新人エンジニア時代を過ごす。いくつかの受託開発プロジェクトを経て、ポーターズ・and factoryにてリードエンジニア業務を経験したのち、2021年EventHubに入社。テスタビリティが高いフロント&バックエンド設計を突き詰めることが好き

プロダクトチームにPdMがジョイン！開発組織は今後も拡大予定

岡本：
前回のインタビューでは、開発フローの説明や優先順位の決め方、技術スタックの選択背景、エンジニア組織の特徴や目指していく組織像について、たっぷりとお話を伺いました。ところで、前回のインタビュー（2021年4月）以降、開発組織の変動などはありましたか？

井関：
PdM候補だった方に内定を承諾していただきました。6月入社予定で、これまでエンジニアが大部分を占めていたプロダクトチームが、さらに拡大することになります。

岡本：
改めて、今の開発組織の構成を教えてください。

井関：
（6月入社の方を含めると）エンジニアが9名、PdMが1名、デザイナーが3名です。デザイナーについては前回触れませんでしたが、プロダクト本体のデザインをするメンバーが2名、サービスサイトやLPのデザインを担当しているメンバーが1名います。

フロントエンドの技術選定｜キャッチアップのしやすさ、体系化できる開発パターンに注目してReactを採用

岡本：
前回のインタビューでは、フロントエンド・バックエンドの技術選定について軽くお話しを伺いました。会社や商品のフェーズを考慮して、最も開発効率が良くフルサイクルモデルにマッチするという理由から、フロントエンド・バックエンドの開発には統一してTypeScriptを使っているんですよね。

今回は技術選定の背景をさらに深堀していこうと思います。こちらがEventHub社で使っている言語・フレームワークです👇

岡本：
はじめに、フロントエンドのフレームワークにReactを採用した理由を教えてください。

井関：
Reactを採用したのは、5年ほど前になります。当時はjQueryを使うケースもまだ多く、Angular.js、Vue.js、Backbone.jsと選択肢は他にもたくさんありました。

岡本：
その中で、最終的にReactを採用した背景は…？

井関：
Reactであれば、ある程度規模が大きくなっても管理できるような仕組みがあったからです。フロントエンドの開発はどんどん複雑になってきていて、MVVCといったアーキテクチャに沿って開発しても一定規模を超えると管理が煩雑になっていました。

Reactであればすべて解決するということではもちろんないですが、FluxパターンやComponent単位で分離しやすいインターフェースなどに可能性を感じて選定しました。

また、個人的な意見ではありますがライフサイクルがAndroid、iOSと似ておりネイティブアプリを開発しているエンジニアでもキャッチアップしやすいのではと考えたことも理由の一つです。

岡本：
確かに、ネイティブエンジニアにもわかりやすいというのはありますね。私はこれまでAndroidアプリの開発に従事した経験がありますが、確かに、Reactはソースコードを見て「Androidアプリのフレームワークだったらこうかな」などと考えることができます。これまでの開発経験を元に、メタファーを使いながら理解できる。この点、様々なバックグラウンドのエンジニアがジョインしてくる会社のフェーズでは魅力ですね。

井関：
それから、Reactを用いた開発パターンが体系化されていたことも、採用に至った理由です。公式ドキュメントも充実していて、実装における「王道パターン」を認識しながら進んでいける安心感がありました。ウェブアプリケーションは複雑になるにつれて、他のネイティブアプリと同じような要件を求められるようになっていきます。この背景を踏まえ、全く新しく開発を進めるというよりは、今あるパターンを上手く組み合わせていくことで、複雑な機能要望も実現できる開発フローを作れると考えました。

バックエンドの技術選定｜フロントエンドとの親和性、フレームワークの「型」を重視

岡本：
続いてバックエンド開発の技術選定について伺います。技術スタックの選定を行った5年前、バックエンドにTypeScriptとNode.jsを使う企業は珍しくなかったんですか…？

井関：
この2つをメインで使っている企業はそれほど多くなかった気がします。TypeScriptについても、名は知られつつありましたが、まだ「新しい言語」という認識は少なからずあったと思います。

岡本：
その中でTypeScript並びにNode.jsを採用した理由を教えていただけますか？

井関：
前回もお話ししましたが、選定における一番のポイントは「開発言語の統一」でした。なので、バックエンド開発での最適解を選んだというよりは、フロントエンド・バックエンドの親和性を重視しました。

TypeScriptを選ぶ以上は当時はNode.js以外の選択肢はないですが、世の中に一定数の知見も存在しますし、そんなにチューニングせずとも比較的動かせると考えていました。弊社サービスは、ゲームアプリのように数千万のリクエストが殺到するようなサービスではないので、それであればある程度は大丈夫かと。それに、JavaScriptエンジンを書いていた経験があったので、多少はNode.jsの仕組みも理解していました。

岡本：
井関さんは、2013年にFirefoxのOSS開発に参加しコミッターになられたんですよね。話は逸れますが、自分はEventHubの選考を受けていた時に、井関さんがFirefoxのような有名ブラウザのコミッターであることを知りました。そんな井関さんともっと深い話をしてみたい、と思ったことが入社に至るポイントの一つでもありました。

さて、NestJSとTypeORMについても、技術資料は少なく先鋭的だったのではないでしょうか？5年前というと、バックエンド開発にはjavaやPHP、Goを使っている企業が多かった印象です。

井関：Node.jsで利用できるフレームワークの選択肢って少なくて、ほぼExpress一択だったんです。しかしExpressは薄いフレームワークなので独自に組み上げないといけないことが多くて、最初の段階で要件に合わない設計をしてしまうとそれが負債となって後々の開発に影響する、というのが懸念点でした。それに、Expressで独自に作る部分はコアになってくるので、大掛かりな移行をする必要が出てくる。今後の開発・改善のことを考えるとそういうデメリットは回避したかった、というのが主流であるExpressを採用しなかった背景です。

岡本：
その上でNestJSを選んだ理由は…？

井関：
NestJSは、Expressであれば独自に作成する必要がある箇所が用意されているフレームワークだったからです。「こういうプログラムを書けばウェブアプリケーションとしてこういう機能を満たせる」というパターンが、上から下まで書かれている。フレームワークとしてのこの特徴が、採用に至った理由の一つでした。

あとは、 NestJSはExpressをラップしているので、例えばミドルウェアを差し込みたいなど一部特殊な処理させたい場合、部分的にExpressで書けるというメリットがあります。つまり、 NestJSを採用しておけば後々Expressと共存する方法が残せるというわけです。世の中にExpessの知見は一定量溜まっているし、連携させるための仕組みもあるので、Expressを全く使えなくするのはもったいない、と考えました。NestJSからExpressに、引き継げる道を残しておきたかったというのがあります。

岡本：
フロントエンドでReactを、バックエンドで NestJSを採用した理由を伺うと、開発パターンが体系化されていたり王道パターンが明確になっていたりすることを重視して、技術選定をされたように感じました。

井関：
EventHubのカルチャーとして、仕組み化を重視したり属人化を排除したりする傾向が強いことと共通しているのかもしれません。5年前に技術選定をした私自身、「このパターンに則ればこれが出来上がる」みたいな型を好んでいるように思います。

今後については、ここまで使ってきた技術スタックに囚われ過ぎず、会社やプロダクトの成長フェーズに合わせて柔軟に対応していくつもりです。

最後までお読みいただき、ありがとうございました🙇‍♂️
第1回のインタビュー記事もぜひご覧ください👇

少しでも弊社に興味をもって下さった方は、こちらからお気軽にお問い合わせください！