Undefinedの技術スタックと技術選定の際に意識したこと
こんにちは、株式会社UNDEFINED の若月 ( @yukiwakatsuki ) です。
はじめに
僕たちは、3月末にNYAGOというアプリをリリースしました。その後、1週間でクローズするという判断を下したのですが、その裏には技術的な背景もあります。
NYAGOのソースコードは、誰が見ても明らかにわかるひどいコードでした。それは、度重なる大きな仕様変更と圧倒的なリソース不足の状態でフルスピードで開発を進めることによる副作用だったと言えます。
そこで、Undefinedでは技術選定のやり直しと開発フローの見直しを徹底的に実行しました。今回はその時に意識したことをまとめたいと思います。
現在の技術スタック
まずは現在の技術スタックを公開します。
クライアントサイド
- React Native
- Redux
サーバーサイド
- Elixir
- Phoenix
- Postgre SQL
- Google Cloud Platform
- Kubernetes
サーバーサイドの技術選定について
その他
- Git
- GitHub
- Circle CI
- Bitrise
- Firebase(Auth)
このような構成です。
React NativeやElixirなど、他の会社での採用が珍しい技術を使っていることもあって、外部の方にはよくその採用プロセスを聞かれます。
技術選定の際に意識していること
実は、僕は技術選定にほとんど関与していません。社内のメンバーが、「一番これがいい！」と提案してきてくれたものに対して「それでいこう〜」と言うイメージです。
基本的には多くは伝えていないのですが、自分たちの中で意識していることが下の3つです。
- 責任を持ってその技術でやり通せること
- 他のメンバー, 新しいメンバーの学習コストが高すぎないこと
- その技術でプロダクトづくりをする上で、やりがい, 楽しさを感じられること
一つずつ説明していきたいと思います。
責任を持ってその技術でやり通せること
これはある意味当たり前なことかもしれませんが、その技術を採用した本人がその技術でやり通せない状況があってはならないと思います。ですが、それはある意味非常に難しい判断で、
- スケーラビリティ
- できること/できないこと
などを、サービスの変化をある意味予期しながら考えなければならないからです。つまり、「結局これはスケーラビリティがなかったからやめよう」とか、「この機能をこの技術で実現するのはすごくコストが高いからやめよう」みたいなことが起きる可能性を極限まで下げてほしいということです。
他のメンバー, 新しいメンバーの学習コストが高すぎないこと
先程の技術スタックを見てもらえば分かる通り、日本にはなかなか経験のあるエンジニアがいない技術が多いです。
例えば僕も書いているクライアントサイドで言えば、これまではSwiftだったものをReact Nativeにするわけなので、もはや全く違う言語なわけです。
そんなときに、学習コストが非常に高い言語を採用してしまうと、その後が非常に辛くなってしまい後継者いない問題に直面します。
そこで、学習コストが高すぎないということを意識しています。それで言うと、今回の技術選定は成功と言えると思っていて、僕をはじめとするクライアントサイドもReact Nativeの経験者は1人しかいませんでしたが、いまはプロダクトをつくれるレベルまで成長しました。
サーバーサイドも同様で、Elixirの経験があるメンバーがいなかったものの、いまでは不自由なく書いているレベルです。
そういった意味で、学習コストが高すぎないものを採用するというのは大切かなと思っています。
その技術でプロダクトづくりをする上で、やりがい, 楽しさを感じられること
実はこれが一番大切だと思っていて、その技術をつかうことによって、楽しいかどうかを非常に重視しています。いくらマネージャーサイドがとやかくいっても、コードを書くのはエンジニアメンバーなわけで、彼らが楽しいと思ってコードを書けなかったら、それは良い技術選定ではないと思います。
僕が技術を決めずに、メンバーに提案してもらうのもそれが理由です。すべてのメンバーがやりがいと楽しさを感じながら仕事ができる環境をつくっていきたいです。
まとめ
最近良く聞かれる、技術選定のプロセスをかんたんに説明してみました。今はNYAGOを最初にリリースしたときとは比べ物にならないくらいの開発レベルで進めていくことができているなと実感しています。
このチームの強さを武器に良いプロダクトをつくっていきます。
