勢いあるスタートアップの3社（アンドパッド、キャディ、Finatext）とイタンジ合同で、豪華な顔ぶれでエンジニア向けのトークイベントを実施しました！
登壇した田渕より、当日のレポートをお届けします！

はじめに

イタンジのエンジニアリングマネージャーの田渕です。
先日、『日々変わりゆく技術トレンドの中でスタートアップ4社が技術選定について語ります』に登壇したので、そのレポート記事として私がお話ししたことを書きたいと思います。主にイタンジの技術選定の話について、イベントの流れに沿って書いていきます。

イベントの詳細URLはこちらです。イベント自体のスライドや動画等は公開できませんが、ご了承ください。

イベントの流れ

まず各社から会社紹介と技術スタックの紹介がありました。
その後、パネルディスカッションで、インフラ・バックエンド・フロントエンド・マイクロサービスアーキテクチャ・運用等・まとめ、というテーマで順番にディスカッションをしていきました。

ここからはイベントの流れに沿って、私が話した内容を簡単にまとめていきます。

会社紹介

ただの会社紹介ではなく、技術スタックに関わる形で会社紹介を行いました。

イタンジでは、各サービスで集めたデータを他のサービスでも活用していくことで、サービスの価値を高めていくという事業戦略になっています。
そのため、データがビジネスの中心になっており、その結果として物件データベース周りがアーキテクチャの中心にもなっています。

インフラ

パブリッククラウドについて

イタンジではAWSを使っています。少なくとも7年ほど前からAWSを使っていて、当時のIaaSの選択肢はほとんどAWSしかなかったようです。

その後、メインのパブリッククラウドを変えるような話は特になかったですが、音声認識などのGCPの一部の機能は積極的に取り入れて、サービス品質を高めています。

サーバレスアーキテクチャについて

メインのAPIをサーバレスで開発していたりはしませんが、一部の処理、特に画像の変換等をAWS Lambdaに逃がすことで、パフォーマンスとスケーラビリティの最適化を行っています。割と小さいモジュールの話だと、メリットがありそうであれば新しいものも積極的に試してみるという文化もあります。

コンテナによる仮想化について

殆どのサービスが、ローカル環境から本番環境までDocker上で動いています。開発も進めやすいですし、サーバの台数を増やしたり減らしたりするのも手軽ですし、ローカルと本番の差異を減らして安全に開発もできます。

しかし、Scalaプロダクトのローカル環境だけは、かなり色々試行錯誤しましたがDocker化できていません。コンパイルが重くなりすぎるためです。

バックエンド

プログラミング言語やフレームワークについて

メインではRuby on Railsを使っていて、一部はNode.jsやScalaを使っています。

言語としての固さや柔らかさの傾向というのはあると思うのですが、Railsを使ったからといって品質が下がるといったことは決してありません。適切な設計を行い、質と量を兼ね備えたテストを書いていれば、Railsの開発速度を活かしたまま、安全に堅牢なソフトウェアが開発できます。

一方で、Scalaのような固い言語のメリットも感じているため、基盤システム等ではScalaも採用しています。また、Ruby3の静的型検査を取り入れているプロダクトもあり、Rubyを使いつつも更に安全性を高めたりもしています。

フロントエンド

フロントエンドのフレームワークについて

基本的にReactとTypeScriptで統一されています。TypeScriptの型のメリットが大きい場合が多く、TypeScriptを使う場合はReactのほうが相性が良いと感じているからです。

Vueも一時期使われていたのですが、私がReactへの統一を図りました。社内の知見を貯めたり、社内ライブラリの活用によって開発効率を向上させる狙いがあります。

特別な理由がなければ、ReactまたはVueに統一しておくメリットも十分にあると判断しています。

マイクロサービスアーキテクチャ

ビジネス的な背景から、物件データの部分は単一のサービスに切り出してはいます。

今のところは、データベースを持つようなサービスを積極的にマイクロサービス化していく方針ではありません。サービスをまたいだデータの整合性の担保が非常に難しいため、今の組織規模ではメリットがデメリットを上回らないと感じています。

データベースを持たないような単一の処理をAWS Lambda等に切り出すこともマイクロサービスに含めるのであれば、積極的に行っています。データの整合性における課題がなければ、メリットが上回る場合もたくさんあります。

運用等

IaC(Infrastructure as Code)について

ほぼ全てをTerraformで管理しています。昔はコード化されていないリソースがあり、それをコード化していくためには、importを行う必要がありました。数年前の時点でimportの機能があり、十分に運用実績のあるツールはTerraformくらいしかなかったため、必然的にTerraformになりました。

まとめ

まず、組織のフェーズとサイズ変化で意思決定時に見る視点が変わってきています。 今は組織も大きくなってきていて、組織でのアウトプットが重視され、全体的には平準化に向かっています。

ただし、技術スタックを固定化したいとは全く思っていません。合理的に、メリットがあるものであれば最先端のものを使っていきたいです。また、部分的な置き換えやフルリプレイス等を恐れず、メリットが上回ると判断したならば果敢に取り組むことができる文化もあります。

技術選定にはっきりとした正解はないですし、様々なコンテキストにも大いに依存するので、毎回しっかりと考えて選定していくのが大事です。

また、選定という言葉を使ってはいますが、選定して終わりではないという意識を強く持っています。継続的に進化させ、最終的に少しでも正しい形に近づけるように日々努力しています。

終わりに

登壇レポートといいつつ、イタンジの技術選定の記事っぽくもなってしまいました。この記事から、イベントの内容と、イタンジの技術選定についての雰囲気を掴んでいただけると幸いです。

またイベント等もあると思いますので、そちらにも是非参加いただけると嬉しいです。今後ともよろしくお願いします。