技術選定等反省点メモ
概要
入社して２年経過したので、技術選定などでの現時点での経緯や感想をメモする。
技術選定
フロントエンド
Nuxtを選んだ。Reactと比較したが、SSRしたくて、その時Nuxtの事例が結構あったからVue & Nuxtにした。
現在では社内向けを除くWEBのフロントエンドはほぼNuxtに移行してる。（1個だけまだだけど、Nuxtを選びそう）
NuxtでSPAもSSRも統一することで、複数のアプリケーションを新規学習コストを押さえて、修正できるようになった。
また、RailsのSlimとかと比べて、hot reloadingは便利だし、どんな動きでもJSでばっちり解決できるし、CSSやJSのスコープがその中で閉じてくれるしで、とても楽。
なので、今考えても、ある程度正しい技術選定ができたとは思う。
ただ、もし今の知識を持ったまま戻るのであれば、今後TypeScript化は避けられそうにないので、あの時からTSが利用しやすかったReact & Next を選ぶ可能性確かそう。（Nuxtを選定時にTSで書いてみたけど、当時はサポートが弱くて、辛すぎてやめた）
テストに関しては、先輩が作ってくれた puppepper でのE2Eテストのみしかやってないけど、今の所は結構十分な感じがする。
storybook とか atomic design とか試したけど、基本一人で開発するし、コンポーネント作っても微妙に使うところでデザイン違う時多いし、アプリケーション毎で流用しようとしても、結構デザインや機能違うので、特にメリットを感じなかった。
まとめると、反省点としては、Next & TypeScript を選んだ方が結局開発工数を削減できたのではないかぐらいかな。（それはそれで苦労はありそうだけど...）
サーバーサイド
WEBサイトにおいては、SSRのNuxtから、Railsで作ったAPIを呼ぶようにしている。そして、そのRailsから、一部機能はsinatraで作ったマイクロサービスっぽいものを呼び出している。
ここに関しては開発はめっちゃしてるけど（先輩とかは基盤設計とか事業企画とかあるから自分が一番開発してると思う）、自分が技術選定の中心ではない。
ただ、今思えば、WEBから呼ばれるAPI（自分担当部分）と、ネイティブアプリから呼ばれるAPIをまとめて開発すべきだっと思う。
自分が入社前までは、一つのPHPでViewも含めたWEBサイトと、APIを運用していたので、WEBとAPIで必要なデータが大きく違うという問題があったらしいので、分けて開発することはCTOからの依頼ではあった。
ただ、事業の成長予測的に既存事業よりも新規事業に人が割り当てられるようになった結果、ネイティブアプリ側のAPIを保守する人がいなくなり、CTOが片手間でやってる感じになっている。このAPIが昔からのコードかつ、様々なアプリケーションが同じソースで動いているので、修正時の影響範囲が分からず、修正が辛い。
技術的に正しいかっていうのも大事だけど、今回の場合はNuxt化したことで、WEBとAPIのフロントである程度共通化は可能だったので、将来の売上予測的なものはあの頃から考慮できてたから、将来的にどこにどれだけの人員が当たるかを踏まえて、設計を考えるべきだったなと思う。あんまり二つの方法に差がないなら、チーム構成を予想して設計するべきだと学んだ。
Railsや sinatra での開発については、別にLaravelやGoとかでもよかったとは思うけど、大きく問題となってはない。（Goは試してみたけど、まだ速度とか型とかがチーム的に求められてなかったから、実運用ちょっとだけして、すぐRubyに戻した。）
むしろ、Rails というかActiveRecordで、ほとんどのアプリケーションが動いているので、開発効率は良いと感じる。JSかRubyのどちらかしか基本使ってないので、業務委託の方が参画してすぐ開発始めやすいというメリットを日々感じている。
WEBとかのテストに関しては、Rails側はNuxtとまとめてE2Eテストをしていて（単体テスト書いてるところもあるけど結局DBやAPIとの連携部分ばかりだからあんまりない）、Sinatraで作ってるマイクロサービスっぽいものは、単体も結合もちゃんとかいてる。今のところは、これぐらいがちょうどいいかなって感じがしてる。
やっと自分とかがネイティブアプリ側のAPIに力を入れられる環境になってきたので、他のアプリケーションと同じくらいの保守はしていきたい。
他には、API間での通信部分がGraphQLとか grpcとか使えてなくて、規格がない。jBuilderとかgemでとりあえずは困ってはないけど、人が増えてきたら考えないといけないなー...（ネイティブアプリとアプリAPI間は独自の規格で運用してるのでそっちは安心）
ネイティブアプリ
最近ようやく触り始めた！
今までWebViewでいいじゃんと思ってたけど、ARKitとか調べてたら触ってみたいなーと。
来年には仕事で使えるレベルまでかけるようになれればいいなー。
クラウド
自分がみてるものは、ECSを主に使ってる。
B向けのユーザー数がそんな多くないサービスとしては、fargate spot でお金的にも安くなったし、とてもやりやすい。
が、C向けのWEBサイトに関しては、予期せぬ大量のアクセスがきた場合に対応が難しいので、Lambda化を提案されている。
この時に、Nextだと海外にLambdaの知見が多いし、RailsじゃなくてGoだったらよかったのかなと思うことがある。
ここは反省というより、いかにLambdaの知見を今後蓄えて、数年後はどういうサーバー構成が主流になるかを楽しみに待っていたい。
ベンダーに関しては、GCPよりAWSの方がBigQuery以外は人気ある気がするので、AWSで正解だったなとは思ってる。（Azureは使ったことない）
k8sは触っただけで、全然使ってないので、試してはみたい。けど、Lambda or ECS で不満がない（困ったらAppMeshとかX-rayとか使えば良いかなと思ってる）ので、後回しになってる...
データ基盤
ここに関しては、自分はほぼ関与できてなかった。（最近はちょっと関与したけど）
現在はBigQueryに揃えようとしてるけど、とあるデータはRedshift、あるデータはBigQuery、あるデータはS3とかで、結構散ってる。
先輩方が最適なものを都度選んでるので、自分が関与しても結果は変わってはないと思うけど、今の流れ的には、早めにBigQueryを中心に使う方法でデータ基盤を構築するのが正しかったのかなと思う。
今後他の会社に入ってもここは大事になってくるところだと思うので、しっかり意識していきたい。
コミュニケーション
他チームとの接点
コミュ力鍛えるとかあんまり好きじゃないけど、やっぱり関係性を持っていた方が仕事は進むし、相談がくるし、結果は出しやすいよなと感じている。
2年たって、仕事で関わる人も増えて、いろんな人と仕事しやすくなった。最初のうちはチーム内の人と仲良くなれればいいやって感じでやってたけど、もっと意識して他チームの人ともコミュニケーションとるべきだったんだなって思う。
前職は、むしろ他チームの人から話しかけてくれてたから流れるままでよかったけど、それに慣れちゃダメだと思った。
マネジメント
最近、二人の業務委託の方の進捗管理的なことをしてる。
今でもマネジメントというのは偉そうで好きじゃないけど、二人とも良い方（というか出会った業務委託の人みんな良い方）だし、一人で仕事してるより圧倒的に早く他チームとか自チームの仕事をこなすことができてるし、食わず嫌いしなければよかったと思ってる。
というかマネジメントって、指示するというよりは結果を出すサポートをするみたいなのが、今の主流というのを早めに知るべきだった。
今の所、お互いの情報を積極的に共有することと、困ってることをすぐ相談しあえるようにしっかりお願いすることで、自分に負担が全くなく、ある程度うまく回ってる気がする。朝会をdiscordですることで、他のチームメンバーが聞いてくれてるから、自動で他メンバーへの進捗共有ができてめっちゃ楽。
けど、もっと人が増えてきて、目標設定とか、評価が仕事に入ってくるのは辛いなと思う。そう思うと今まで嫌いだったけど、画一的な評価制度って、評価する人のメンタル的に楽そう。
リモートワーク
これに関しては反省点0で、スムーズにコロナによるリモートに移行できた。
会社の人とは、関係性がある程度できている状態だったから、もはやリモートの方が効率がいい。
今まで情報共有するための会議が無駄だと思ってて、廃止してもらってきたけど、今は移動もせずにラジオ的に聞けるから何のストレスもない。
むしろ仕事しながら、今まで出られなかった他チームのMTGを聞けるから、今までみたいに議事録を漁るとかしなくて良くてすごく楽。
懸念点としては、新しく入社されたかたと関係性0だから、お互い相談するのに心理的な障壁あるよねって思う。慣れてくるのかな？
終わり
この2年で考え方いろいろ変わったけど、来年とか再来年はどう考えてるんだろうか
