トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

Next.jsとGoを使っていきます

こんにちは、VPoEの北川です。

今回はトレタで現在使用している技術スタックについて紹介します。

創業時から稼働している予約・顧客台帳サービス「トレタ」から現在の注力事業のモバイルオーダーサービス「トレタO/X」までをあらためて振り返ってみると、まるで異なる技術スタックになっているので歴史的な背景などを辿りながら紹介していきます。

技術スタックの変遷

予約・顧客台帳「トレタ」

会社名にもなっている予約・顧客台帳の「トレタ」は創業当時から稼働している築11年ほどのシステムです。

サーバーサイドにはRubyとRubyOnRailsで作られた巨大なコードベースのAPIサーバーがあり、予約台帳のiOSアプリやウェブ予約などのWebアプリケーションなどが利用しています。 長年このモノリシックなシステムを成長させてきたので、以前からトレタを知ってくださっている人にはトレタはRubyの会社と認知されていたと思います。

インフラは主にAWSを使用しており、EKSでのAPIサーバー群を管理を行い、膨大な予約データをMySQLに保管しています。

超直前予約「トレタNow」

上記の図にはないですが、技術スタックの転機となったのが超直前予約サービスアプリ「トレタNow」です。

これからすぐに行きたいお店が予約できるをコンセプトに超直前予約サービスとして2019年にリリースされましたが、残念ながらリリースのすぐ後にコロナの流行により飲食店予約の需要がなくなり、現在もサービスは縮小中です。

トレタNowでは意欲的に新しい技術要素を取り入れており、gRPCの導入やそれにあわせバックエンドにGoを採用しました。 フロントエンドはtoC向けのモバイルアプリとWeb版を提供し、SwiftやAngularの他にAndroid版としてトレタでは初めてKotlinを使用しました。

モノリスからマイクロサービスへ

モバイルオーダー「トレタO/X」

モバイルオーダー「トレタO/X」の開発は2021年ごろからプロトタイプ開発が行われ、2023年に正式リリースを行いました。

トレタO/Xではマイクロサービスを取り入れたことで、バックエンドの構成は多様になりました。

多くはトレタNowからの流れでGoを使用していますが、比較的薄いAPI層はフロントエンドのメンバーも実装がしやすいNode.jsを使用したり、注文データを扱うサービスにはイミュータブル・データベースのDatomicやClojureを使用しています。

インフラもトレタO/XではGCPを主に使うようになりました。予約台帳「トレタ」の様なモノリシックなサーバーの時はKubernatesを使った管理を行っていましたが、マイクロサービスになったことで一つのサービスはなるべく小さく管理コストの低いフルマネージド型であるCloud RunやCloud SQLを選択するようになりました。

フロントエンドでは、この時期からAngularからReact/Next.jsを採用するようになりました。 それまではAngular日本ユーザー会に参加したりとAngularを支持していましたが、トレンドとしてReactとVue.jsの勢いが増してきたことでAngularのエンジニアの採用に苦戦しはじめたのがきっかけでReactを使用するようになっていきました。 そこからReactやNext.jsのめまぐるしい進化もあり、現在ではフロントエンドにReact/Next.jsを使うことが多くなっています。

また、トレタNowで複数デバイス向けにフロントエンドを開発していた苦労から、クロスプラットフォームであるFlutterを採用しました。 ただ、アプリのマーケット申請の省略などの理由で「Flutter on the Web」のみで開発を開始し、ハードウェア連携などネイティブアプリにする必要性も出なかったため現在もWeb版のみで利用しています。

さいごに

やっとタイトル回収に入りますが、トレタO/Xの開発がそれなりに時間が経ちプロダクト方針や市場状況などが変わってきたところでシステムに求められる構成も変わってきました。

新しいマイクロサービスが必要になったり、逆に不要になってきたシステムのクローズや統合、リプレイスなどを行っていくことになります。

その中で選定する技術の基本軸はフロントエンドならReact/Next.js、バックエンドはGo言語に当面の間はなっていきます。

ということで、React/Next.jsを使って新規開発やシステムリプレイスなどをTypeScriptエンジニアやGoエンジニアの採用を行っているので、興味のある方はぜひ話を聞きにきてみてください。 hrmos.co

業務委託との長く続く良い関係性

こんにちは。トレタでVPoEをしている北川です。

この度、クレスウェア株式会社の奥野賢太郎氏がトレタの技術顧問に就任しました。

corp.toreta.in

トレタに在籍している人にとっては奥野さんが技術顧問になったという話は「今更!?」と感じる人もいるかもしれません。

それだけ奥野さんはトレタで業務委託として長く携わってもらっていますし、実務以上に技術面の啓発や開発カルチャー作りに今までも貢献していただいていました。

今回のことで奥野さんとの関わりが大きく変わることもありませんが、これからトレタの開発組織を強化し、発信を活発にしてく上で、奥野さんとの協力をより一層強くするために今回の発表をさせていただきました。


自分と奥野さんとの関わりも5年以上経つので積もる話もたくさんありますが、あまり内輪話を記事にしても仕方がないので、もう少し一般化して「長く活躍いただいている業務委託の特徴」について、自分なりに思う事をこの記事に書こうと思います。

Noを言ってくれる

業務委託と社員の間にはどうしても委託先と委託元という関係性が発生するので、意識しないようにしても接し方に影響がでてしまいます。社員の中でも上司と部下であれば起きますが、業務委託の場合はより色濃い気がします。

その中でも対等の立場で議論が行えて、場合によっては指摘したりNoと言ってくれる方はとても貴重な存在です。 年をとると怒ってくれる人がいなくなる、という話に近い感じがします。

例えば、複雑な設計をしすぎた仕様を提示すると「それYAGNIじゃないですか?」とよく言われます。 将来的な事を詰め込んだり欲張った設計を自分はしがちですが、「パフォーマンス悪くなりますよ」「QAに負担かかりすぎますよ」だったりと論理的、多角的な視点で現実的な指摘をいただけます。

総じて言うと、強い「オピニオン」を持っているという特徴があると思います。それは経験に裏づけされたものかと思いますが、確固たる思想をもち思想が合わない場合には率直に意見をしてくれます。

細かいことでいうと、先日もコードベース上でシングルクオートにするかダブルクオートにするかでプチ議論になりました。 些細なことに見えますがこれは意外と大事な事で、一般会話においても質問に対して「なんでもいいよ」と答える人とは議論が成り立たないわけです(夫婦間でよく怒られるやつ)。 細かいことでも一貫して自らの意見を持ちぶつけてくれる、というのがプロの特徴の一つなのかと思います。

創造性と情熱

対等な議論ができる、というのは関係性がしっかり構築されていないと実際のところ難しいです。 そのため関係性が浅い業務委託の方の場合は、どうしても依頼したことのみを動く人になってしまいがちです。

「世界最高のチーム」 *1 という本の中に、仕事において人に求められる能力の段階として「能力のピラミッド」*2が紹介されており、レベル4の主体性より上に引き上げるためには「心理的安全性」が必要と書かれています。

社内で活躍しているメンバーは社員や業務委託であるか問わず、主体性(課題を見つけすぐに行動する)や創造性(より良いアーキテクチャー、ライブラリへの意識を常に持ち取り入れる)を持ち合わせています。情熱を持ちあわせた強強の人までいくと、経営視点でのサービスの発展性やプロダクト成長の方向性についていっしょに議論ができます。

直近でも今後やりたいプロダクト成長を踏まてNext.jsでPagesRouterからAppRouterへ切り替えたり、デザインシステムの導入を見越してTailwindCSSの導入を行いました。どちらも最初にメンバーから提案をいただき、迅速に対応いただきました。

新しく入るメンバー含め全員が同じような主体性や創造力をもって仕事するために「心理的安全性」を作れるかは、開発文化の醸成を行なっていくVPoEになった自分のこれからの任務だと考えています。そしてそれをサポートいただく強力なパートナーとして、今回の技術顧問の発表を行なったという背景です。

さいごに

トレタではエンジニア採用を積極的に行なっています。

奥野さんとガッツリとモブプロしたり、手厳しいレビューを受けて揉まれたいエンジニアはぜひ応募してみてください! hrmos.co

*1:「世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法」 ピョートル・フェリークス・グジバ (著)

*2:「経営は何をすべきか」ゲイリー・ハメル(著)

開発組織の新しいコアバリューを定めました

こんにちは、トレタ VPoEの北川です。

先日VPoEに就任したご報告をしましたが、あわせて開発組織内のコアバリューを新しくしました。 この記事ではその新しいコアバリューについて書こうと思います。

tech.toreta.in

新しいコアバリュー

「短く速く作り出そう。遠いゴールを目指して飛び込もう。(Dash & Dive)」

トレタの会社全体のビジョンやミッション、行動指針などはありますが、その中でも現時点での開発組織としての重心としたい要素をこの言葉にまとめました。 盛り込みたい要素はいろいろとありましたが、なるべく短い言葉にしたかったのでそこに込めた背景を説明していきます。

短距離走ではなく長距離走でもなく、短距離走の連続

トレタはベンチャー企業である以上、短期間での開発&リリースが求められるプロジェクトは少なくないです。 新規プロダクトを2ヶ月で作り上げてリリースする等、ユーザーに早く価値を届けることを目標にスピードを重視した短距離走的な進め方をする場面はよくあります。

一度プロダクトをローンチした後は、運用面も意識する必要があるため長期的な視点が必要になってきます。 ただし、初回リリースのスコープから外した機能のエンハンスや、手が回らなかった部分はリリース後にゆっくりやっていくか、といったらそうはいきません。 そこからエンハンスの新しい短距離走が始まるからです。

短距離を走り切ったらまたすぐ次の短距離を走る、それが今の開発現場の状況です。

最優先される価値は「スピード」

荒ぶる四天王があらわれた!*1

そんな限られた期間内での開発状況においてどうリリースまでもっていくか。プロジェクトを調整する要素は「時間」「予算」「品質」「スコープ」の4つがある、と「アジャイルサムライ」の本にはあります。

時間」については、定められた短い期間でやるのが前提でありリリース日を延期するのは最終手段です。

予算」について、「人月の神話」にもある通り人を2倍の数にしても開発速度が2倍になることはありません。人が増えることで発生するコミュニケーションコストは開発工数の中でも大きく占める要因の一つと考えています。最速で行うには少人数の方が向いています。

品質」については@t_wadaさんの「質とスピード」*2の話が社内ではよく挙げられます。質(保守性)とスピードはトレードオフの関係ではなく、高速なデリバリーをし続けるためには高い品質を保ち続けることが必要と考えています。

最後の「スコープ」が「アジャイルサムライ」の本にもある通り調整が一番しやすい部分です。スコープをいかに小さくし、その中で最速で開発を行うか、という重要性をコアバリューの「短く速く作り出そう」という言葉をに入れました。

常に全速力を続けるために、コンディション(質)を保ち続ける

上記の通り「品質」は常に高く保ち続ける必要がありますが、じっくりとリファクタリングする余裕もありません。

そこで必要なのは開発をしながら品質も同時に保つ、というやり方を意識することです。それは負債になりづらい設計や実装に心がけたり、TDDの様に実装とテストコードを対で実装していくやり方かもしれません。

ただし、高い品質を求め過ぎて開発速度が下がってもいけません。盲目的にテストコードのカバレッジを80%以上に保つというルールを設けるのではなく、テストコードで得られる安全性とそこにかける時間のバランスを常に意識することを心がけます。

場合によって、納期を優先して一時的に負債を許容する場面もあるかもしれません。ただし、それは解消する目処がある場合にのみ良しとします。 次のフェーズで同じところを触るからその時に改善する、そのうち使われなくなるから今は見逃すなど、負債が残り続けないかという観点も意識します。


次に「遠いゴールを目指して飛び込もう(Dive)」の部分について、「短く速く作り出そう。(Dash)」の部分が短期の目線を表しているのに対し、こちらは長期の目線を表すために入れました。

始める前には必ず一歩立ち止まる

走り始める前にゴールまでのルートを計画してから飛び込む必要があります。重要なのは短期のゴール長期のゴールの2つを意識することです。

よく行うアプローチとして、小さく絞った「スコープ」を積み上げていくのではなく、先に最後のゴール像を設計しきってからそこまでの登り方を分解していきます。 特にデータ設計など後付けしづらい部分などは、最初に詳細まで詰めきっておきます。 ゴールまでの道筋を描き切ったら、一旦頭の中から放念して今度は直近のゴールへの道筋を設計します。

この様な短いスパンの視野長いスパンの視野を行き来することが重要です。

近道はない。あるのはトレードオフのみ。

設計を進める上で、どちらの設計を選択すべきか迷う場面は往々にしてあります。肝に銘じないといけないのは、近道や銀の弾丸はないということです。 すべてはトレードオフがあるのみです。

一見簡単そうな道があったとしても、何がトレードオフになっているかを考えることが重要です。 どの道を選ぶべきかの判断軸は、前述のとおりどちらが速くゴールに辿り着けるか、です。 険しい道だとしても結果的に最後にゴールするのが早い道を選ぶための勇気を持つために「Dive」という言葉を入れました。

長く潜り過ぎてはいけない

遠いゴールを目指す時の注意点として、そのゴールを過信しすぎてはいけません。 常に状況は変わります。 当初のゴールは途中で目指していたものから変わっている場合があります。

たとえば、システムリプレイスなど期間が長く大きいプロジェクトがリリース直前になって頓挫することは今までトレタの歴史でも多々ありました。 一年かけて開発していた間にユーザーが求めていたものが変わっていたり、外部環境が変わっていたりします(パンデミックなんて予想できない!)。 ビッグバンリリースはなるべく避けなければならず、最初の言葉にもある短く細かくリリースしていくことが重要です。

常に状況を見て現在地を確認していれば軌道修正は可能です。 途中で意思決定や設計を間違えることがあれば、その時も軌道修正すればよいのです。 失敗を恐れずに「Dive」です。

さいごに

いかがだったでしょうか。 このような開発文化でトレタでは日々の開発を行なっていきます。 エンジニア採用を積極的に行なっていますので、興味がある方がいればぜひ声をかけてみてください。

hrmos.co

© Toreta, Inc.

Powered by Hatena Blog