見出し画像

Chompy創業3年間の、技術選定の成功と失敗を振り返る

yagitatsu

こんにちは、多様な食を多様に届け、「まいにちの食事」を、おいしく笑顔にしたい @yagitatsu です。

(ちょっと長い？w)

息を吸うように仕事のことを発信できるようになりたいな、ということで仕事でも、noteを再開しようと企んでおります。

会社の近く。秋の目黒川も良きですね🍂

本日はCTOらしく、今まで行ってきた技術的な意思決定について、成功と失敗について自分の言葉で語ってみようと思います。

注意点なのですが、前提として、環境やチームによって何を成功とするかは違うと思うので、「へー、こういう考え方なんだね〜」という感じで、軽い気持ちで読んでもらえればうれしいです 😃

技術選定の成功/失敗とはどういう状態か

そもそも、技術選定について、成功とはどういう状態で、失敗とはどういう状態か、言語化してみようと思います。

まず、技術選定の成功とは、「この技術を選んでよかった。今後も続けていきたい」という状態とします。

また、技術選定の失敗とは、「上記のように思えてない」状態とします。

(書いてみたら結構シンプルでした笑

Chompyを支える技術

「そもそも御社ってどういう技術使ってるんですか？」については、以下を参照ください。直近でReact使ってるところ以外はほぼ変わってません。

また、技術選定をした当時の状況を補足しておきます。

  • 創業は2019年夏で、フードデリバリーアプリ立ち上げのために2019年9月までにエンジニアを6人 (自分とオフィスデリバリーを担当してたエンジニアは除く)、正社員採用してスタート

    • バックエンド経験者5人、モバイル経験者2名、Frontend経験者3名 (重複あり)

    • 基本的に1人でまるっとBackend/Client(Frontend)作ってもらう開発スタイル

  • 創業初期は特に会議体にて議論などせず、自分の独断と偏見で意思決定

    • (最低限、実行時のネガティブチェックは随時実施)

成功と捉えている技術選定

まず1つ目は、アプリ開発においてFlutterを選定したことでした。
たまたま、Chompyの提供するサービスには、以下のような性質がありました。

  • フードデリバリー、飲食店向けSaaSのどちらも初期からマルチプロダクトが必要だった

    • フードデリバリーの場合は、注文者向け、配達員向け、店舗向けの3アプリが最低でも必要だった

    • 飲食店向けSaaSの場合は、注文者向け、店舗向けの2アプリが最低でも必要だった

      • 今後も、店舗向けの業務アプリなどで増える可能性が出てきている

  • ネイティブ固有の機能要件が少ないアプリばかりだった

2019年時点ではチャレンジングだった可能性もあるので、やってみて厳しければ引き返すことも考えていましたが、上記の結果ワークしていて、2022年現在も快適に運用できています。
別々で作っていたら複数アプリの両OSの運用は相当苦戦していただろうと感じています。

以下に、Flutterの採用経緯や詳細な振り返りをまとめているのでよければご覧ください。
「なんでReact Nativeじゃないんだっけ？」などもまとめてあります。(最近広告多くて読みづらかったらすみません

次に2つ目は、Backend開発においてGoを選定したことです。
自分にとっては前職から慣れていたのと、前々職で書いたことのあるPerl/Rubyとの相対感で、特に以下の点が気に入っていました。

  • 静的型付け言語の安全性

  • 言語仕様のシンプルさによる学習コストの低さ

  • 標準ライブラリや開発支援ツールが充実している

特に他の選択肢も検討してないですし、筆者は慣れているせいもあるかもしれませんが、開発面で苦労することもなく、今でもよかったと思っているので、少なくともあと5年はGoでやっていきたい気持ちです。

最後に3つ目は、インフラにGCPを使っていることです。
これも、たまたま前職で慣れていたというのが強いのでAWSに慣れていたらそれはそれでよかったかも、と思うのですが、ゼロベースでキャッチアップして比較検討する余裕もなかったですし、便利な機能の恩恵を受けてできているので後悔などは全くないです。
DBにCloud Firestoreを選んだ結果、データ更新をトリガーにBigQuery syncしたりCloud Functionsで自由に処理できたり、サクッとWebSocketを使ってリアルタイム更新できたり、幸せで良きです。

逆に、失敗と捉えている技術選定

1つだけあり、社内向け、飲食店向け管理画面など初期のWebアプリケーションをNuxt.js(Vue)で作ったことです。
※これはChompyの環境や私の考え方には合わなかった、と捉えているだけなので、悪しからず。

私は大学時代(2008-2009)にWeb制作の仕事をするところからWeb系の仕事を始めた、ということがあり、VueとReactで比較したときに、個人的にはVueの方がWebっぽく学習コスト低く作れそうだな、という感覚を持っていました。

一方で、採用を通じて採用候補者に「Reactの仕事をやりたい」とカジュアル面談すら断られたり、メンバーとの1on1の中で「どっちでもいいけど、選べるならReactの方がいいですね」と言われたりした中で、自分もReactの勉強してみて、Flutterと書き味が似ていて一定良さがあるなと思ったので、Reactで作るように切り替えていこう、という意思決定をしました。新しいWebアプリケーションではNext.jsを使っています。

その結果、Nuxt.jsとNext.jsのリポジトリをどっちもメンテすることになり、乗り越えるべき危機が訪れています。

すでにマルチプロダクトを少人数で運営している中なので、書き換えもなかなか厳しい状況ではあります。一方で、KPTなどでメンバーからも「つらい」と複数回言われている状況なので、なんとかせねば、と思っています。言われているうちが華ですよね、ということで。

正直、まだよくわからん技術選定

どちらでもないと思っていて、まだ判断できないものもあります。
gRPC vs GraphQLがその例です。現状は9割ほどgRPCでAPIが作られていて最近GraphQLが流行っているので、そろそろ始めやすいかな、ということで導入してみたのですが、今のところはgRPCでもいいな、と感じることもあり、一度チームで議論してみたいなと思っています。

個人的には、モバイルアプリだと審査のリードタイムがあるので、バックエンドにUIの表記部分も寄せたりしたくなると思うんですが、それをやるということはバックエンドがモバイルのUIを知っている、ということになるので、protoファイルを事前にレビューしてgRPCでつくるのと何が大きく違うのかな、となる気がしているんですよね。一方、Frontendだと何か不具合があってもFrontend側ですぐ修正できるので、GraphQLで直接Frontendから好きなデータをfetchしてくる、という考え方で良い気がしていて、状況によるのかな、と🤔

【番外編】失敗しそうで引き返した技術選定

番外編で、一瞬失敗しそうになって引き返したのは、飲食店アプリのセットアップ周りの自動化をDartで書くかGoで書くか、というところで、Dartに寄せようとしていたことでした。

最初はDartでAppstore Connect APIのclientを書いたりしていたのですが、FrontendやClientのユースケースを想定して作られた言語なので、周辺ライブラリのインターフェースもFrontendで使うことを想定したようなものが多く、書き味に違和感を感じることがありました。

Dartで書くのはそれはそれで楽しさもあったのですが、書き味への違和感が抜けず、スクリプトを書く時に、強い意思がなければGoを推奨することにしています。

振り返ってみた学び

技術選定するとき、私は自分のオーナーシップを一番大事にして選択していて、それ自体は悪くない考え方と思っているのですが、他にも、改めて以下の観点を整理して判断すると良いなと思いました。

  • 売り手市場な採用環境の中で、採用しやすい技術を利用できているか

  • 開発者体験の良い技術を利用できているか

  • 選択した技術間の開発者体験に一貫性があるか

おわりに

以上となります。楽しく読んでいただけましたでしょうか。何かの参考になれば幸いです。また、Chompyではもちろんエンジニアを募集しております。(この記事は読んでなさそうですが、デザイナーも熱烈に募集しております！w) 興味をもっていただけましたら、ぜひ以下からカジュアル面談もできるのでご覧ください。

https://chompy-inc.com/recruit/

本記事を読んで何か気になったことあれば、TwitterのリプやDMなどでカジュアルに声かけてくれるとうれしいです。

https://twitter.com/yagitatsu3

それでは少し早いですが、年末なので、良いお年を🐇



この記事が気に入ったらサポートをしてみませんか？