💯スタートアップの1人目エンジニアとして選定した技術を振り返って点数づけしてみる

自己紹介

2022年の3月にスタートアップに1人目エンジニアとして入社して、1年半近く経ちました。
新規のメンバーも増えてなんでココはこの技術・設計になってるんだ？と聞かれることも増えてきたので、改めて当時の気持ちを振り返りつつ、点数付けをしてみようと思います。

経歴などはブログにまとめているのでよかったら見てください。ありがとうございます。
https://ebijun.jp/

どんなプロダクトを作っているか

今は主に2つのプロダクトを作っています。

1. 業界特化SaaS
2. 業界特化求人メディア

1つ目のSaaSは入社直後に0から立ち上げたもの。2つ目の求人メディアは入社前から運用されているものを内製化したもの。

ではそれぞれ使用技術の選定理由や、1年半経ってみての感想です。
点数が低いものは技術力が足りてなくて使いこなせてないだけだろ、っていう側面もありますがご容赦ください。

業界特化SaaS

Ruby on Rails 6系

点数: 💯
選定理由: Railsエンジニアは市場に多い想定で、採用にうまく効いてくるだろうという判断。
振り返り：案外世の中にRailsエンジニアは少なく、めちゃくちゃ採用で苦労している。一方でネット上にリソースが多く、学習コストも比較的低いのでRails未経験でも戦力化が早い。Rails()と言われることが多いが、やはり立ち上げ直後はRailsに勝るものはないと思う。

React

点数: 60点
選定理由: こちらも採用にうまく効いてくるだろうという判断。
振り返り：こちらも採用で苦労している。2022年当時はVueエンジニアばかりで本当に後悔した。とはいえ最近はNext.jsの台頭やVue3系の破壊的変更によりReact1強になってきた感じがするので結果的にはよかった。反省として、Reactの設計に全く詳しくない状態で開発を始めてしまい、コーディング規約が定まってないので若干にカオスになりつつある。

サーバー構成: モノリスアーキテクチャ

点数: 💯
選定理由: とにかく早くリリースしたかったため。
振り返り： RailsのWebpackerを使ってReactを配信するモノリスな構成を選択。インフラ構成がシンプルになったり、リリース作業が少なく済んだりと今のところメリットが大きい。また、Railsのテンプレートエンジンを使わずにcreate-react-appで独立したアプリケーションにしたが、エディタの補助機能をフルに使えるのでこちらも正解だったと思う。しいて欠点を挙げるとしたら、諸々のバージョンアップの影響範囲が広くなってしまうところ。

テナント実装 activerecord-multi-tenantを使用

点数: 70点
選定理由: めちゃくちゃ悩んだ末にGeppoさんのnoteを読んで決定。
振り返り： このgemのせいではないが、当初の要件外のこと（ホールディングスの対応など）が発生して結構苦しんだ。忙しいフェーズを乗り切れたので決して悪くはない選択だったと思うが、AWSの資料とかを読みながらもっと根本の理解を深めてから選定した方がより良い選択ができたと思う。

業界特化求人メディア

Next.js

点数: 80点
選定理由: 採用アピール
振り返り: 書いてて楽しいのでエンジニアとしては選んでよかった。一方で本体・エコシステムともに変化が激しいので追従が難しい。最近はtRPCを入れてフルTypeScriptの恩恵を最大化しようとしています。

AWS CDK

点数: 40点
選定理由: マイクロサービス、サーバレスというキーワードで採用アピール
振り返り: バックエンドはロジック含め全てCDKで管理していた。こちらはかなり選択肢としてミスった感じがしている。というのも、ローカルにバックエンド環境を用意するのがめんどくさい。CDK自体は書きっぷりなどかなり良いが、あくまでリソース管理にとどめて、バックエンドはちゃんとサーバーを用意する構成にするべきだった。現在はバックエンドのロジックはNext.jsに引っ越しし、、AWSリソースの管理をするためのIaCに縮小中

AWS DynamoDB + ElasticSearch

点数: 20点
選定理由： 要件が決まりきっておらず、求人情報を柔軟に管理したいという理由でスキーマレスDBにした
振り返り： 次のAmplifyと1,2位を争う失敗だった。DynamoDBの検索周りの弱さをGSI Overloadingで乗り切ろうと考えていたが、「これ誰が引き継げんねん」となって断念してElasticSearchに検索基盤を移譲した。結果として、RDBと比較して高額なElasticSearchの費用と、スキーマと同等なマッピング管理が発生してしまった。バッチ処理も辛い。RDBを使いつつ、検索項目になり得ないようなものやデータ補正が不要なものはJSON型に突っ込むなどで柔軟性を確保するのがよかった気がする。

AWS Amplify

点数: 10点
選定理由： ホスティングできてCI/CDもついてくるので導入
振り返り： 元々エックスサーバーで運用していたPHP製ソフトをリプレイスしたという背景で、一部のパスの向き先をエックスサーバーにしたりワードプレスに向けたりする必要があったが、Ampligyそのものや内部のCloudFrontの仕様にめちゃくちゃ苦しめられた。あとシンプルに高い。Amplify自体は良いサービスだと思うが、本番サービスでの運用は辛い部分の方が多そう。Next使ってるならVercel使うのが一番平和だと思う。最近だとCloudflareも良さそう。

結論

立ち上げ期のRailsは最高💯