00:04
こんにちは、ゼロトピック第21回目です。
今回もお掛けする株式会社TENXの共同創業者の石川と、
技術的な話をしたくて、僕だけだと深掘るのが難しいので、
最近、うちに入社してくれた元メルカリでテックリードをやってきた
北雄介さんに来てもらっています。こんにちは。
こんにちは。
今回のテーマは、TENXの創業初期の技術宣伝について、
CTOの石川に北さんから質問をしてもらって、
回答するというような形で撮っていきたいと思いますので、
あとは北さん、お願いします。
まず、僕が入社する前にできていたプロダクト、
タベリーの一つ目のプロダクトについての技術スタッフに
聞いていきたいと思います。
まず、基本的にはGCPを使っていると思うので、
GCPの選定理を教えてほしいなと思います。
GCPを使ったのは、僕自身が慣れているというのも
もちろんあったんですけど、そもそも選択肢として考えられるので、
大きく分けると、AWSかGCPがこの業種だと
二大選択肢になるかなと思いますけど、
その中でもGCPを選んだのは、まず一つが僕が慣れているというので、
もう一つは、ファイアベースがちょうどいろんな機能を
当時提供し始めていて、これを利用すると
スタートアップとして必要なWebアプリケーションの機能を
複雑な機能の大部分をこのファイアベースが提供してくれるということがあって、
これを利用しないといけないなと思って、
なおかつファイアベースとしてGCPを選んだというのがありますね。
ファイアベースは、僕も石川さんももともとクライアントエンジニアの歴が長いので
馴染みがあって分かりやすいですね。
そうですね。
ファイアベースにファイアベースオーセンティケーションという機能があって、
ユーザー認証をする機能なんですけど、ユーザー認証ってめちゃくちゃ大事で、
しかも実装するのがそこそこ大変で、
他をすると個人情報が漏れるみたいな、結構クリティカルなやつなんですけど、
いまいで実装するのは全然不可能ではないんですけど、
そこそこリスクがあるし、コストもかかるというので、
これはファイアベースに任せたいというのがあって、
もう一つ、ファイアベース、GCPを使っていると、
ファイアベースの認証情報をそのままロードバランサーに渡せるというのがあって、
03:04
バックエンド側でその認証の仕組みをほぼ取り扱わずに、
単純なデータとして扱えるというのがあって、
そういうのもあってGCPを使っています。
その辺の構成は全部一人で考えたんですか?
そうですね、最初は自分一人で考えていて、
ただGCPの中でもいろんなプロダクターがあって、
例えばApp Engineみたいな感じで、
アプリケーションのコードだけプッシュすればサーバーができちゃうというものもあるんですけど、
それは採用しなくて、
あとコンピュートエンジンという普通のサーバーみたいなのもあるんですけど、
それも採用しなくて、
当時だとちょっとエッジだったGoogle Kubernetes Engineというのがあって、
それを使いました。
なんでそれを採用したかというと、
結局サーバーでやらなきゃいけないことってある程度定期化はしていて、
その時にKubernetesがそれの、
全てとは言わないけど、
よくあるところに関してはやってくれるというのが分かっていたし、
その拡張性が十分にあるのが分かっていたので、
自分はそこまではインフラに強くないんですけど、
もし自分よりインフラに強い人が来た時に、
彼らの拡張したい分だけ自由にできるように、
拡張性のある選択肢を選択したというのはあります。
素晴らしい。僕もちょっとだけバックエンドエンジニアやっていて、
Kubernetesまで軽く触ったけど、
なかなか一人で全部テックタックを考えるのが難しいので、
そういう当初からやっていたのはすごいなと思います。
ありがとうございます。
あとタブリの構成的には、
ここまでデータのやり取りは多くないですか?
データベース周りは何か気をつけたことはありますか?
データベース周りはそうですね、
基本的にマネージドサービスを使おうと思っていて、
なぜかというと、自分がデータベースのスケールをさせる経験がなかったので、
そこでスタックしないように意識していて、
前職でGCPのクラウドデータスタッフを使っていて、
特にケアでスケールしている業務を見たので、
それを対応したというか、
そこはちょっと安全に倒したというか、
逃げの選択をしたような感じです。
わかります。
さっき2個、自分たちがやりたいことを早くやるということと、
もう1個、自分たちがコントロールをしたいとか、
より深い機能というか、コントロールを深めたいとなった時に、
それが選択肢だし、取れるみたいな、
06:02
こういう軸で技術選定するのって、
フェーズが変わってもそんなに変わらず、
今もやっていることなのか、
それとも今って別の思考が入っているのかというと、どうなりますか?
それでいうと、その2つのことのバランスは常に取らなきゃいけなくて、
ただどっちに基準を置くかというのは徐々に変わってくるかなというのもありますね。
自分たちがやりたいことをすぐできるようにするというのは、
ある意味、整形化したものを自由度を縛るからこそ、
簡単にできるというような仕組みになっていて、
緩めれば緩めるほど、制約を緩めれば緩めるほど、
自分たちがやらなきゃいけないことが増えるという状態になっていて、
最初は僕1人しかいなかったので、
その制限を受け入れてでも少ないコストでやらなきゃいけない。
だから徐々に仲間が増えていく中で、
労力が払えるようになってくるので、
その制約を外せるようになるんですね。
そのバランスは常にいるという意味では、今でも変わらないという感じですかね。
それは今は、キタさんとかもそうだし、石谷さんとかもそうだけど、
思うのが割とそこの選定に対しても意思決定に関与しているのか、
それともそこは石川さんが一定になっているのかというわけで。
僕は常に見てはいて、ただ1から10まで見ているわけじゃなくて、
何かいいやつを見つけようとしてきて、
決めてもらうことも結構あって、
ただどういう決定をしたよというのに対して、
後に聞けるようにというか、見るようにはしていますね。
観点の漏れがないかとか。
これを使うことになって大丈夫なのかどうかというのは見ています。
ぱっと見、僕も全部まだGCP周りのサービスは触っていないけど、
あと何人かと言っても、かなり柔軟に対応できるようなテクスチャーにはなっている気がしますね。
基本的にはメンバーが何人いるかとか、
どういう強みのあるメンバーがいるかで、
ゲージ選択も変わってくるんですけど、
基本的にはそういうのは全部吸収できるようになっているそうです。
つまり今後チームがスケールして、
今7人だけど、例えば来年14人ぐらいになっていますみたいな状態には、
それに合わせて選定をし直していくというのが、
プロダクトにおいてずっと発生し続けるというイメージです。
確かにそれが気づかぬうちというか、
気づかぬうちというのは嘘だけど、
プロダクトの進みを止めないように、
09:02
普通にスプリントの中に差し込まれて、
4スプリントぐらいで終わっているみたいなのが、
結構うちの開発チームの特徴かもしれない。
R&Dもスプリントの中で終わっていて、
組み替えも終わっていて。
入社して思うのは、みんな相当早いなって思います。
やっぱりそうなんですか。
ちゃんとリュウドも分かって、
自分かもしくは石川さんに設定して決めてますけど、
当然そのリュウドもちっちゃいんで、
悪いスピードもありってのはあります。
ただ、やっぱり僕含めて触ったことのないエリアを触ることも多々あるので、
そういうエリアに関しても自分で発展しやがって、
パッと終わっている人が多いので、やばいですね。
あとはスプリント単位でやっている選択っていうのもあるんですけど、
やっぱりプロダクト単位でもあるかなと思ってて、
今新しいやつ開発してるじゃないですか。
タペリーの方では、当時僕しかいなかったので、
僕の手が早いOSネイティブ、
それと後でAndroidネイティブ、
その2本で開発したじゃないですか。
基本的にそのプラットフォームのデザインに乗っかって、
そこに抱っこしてもらいながら進んできたという感じなんですけど、
今回はプラットフォームで開発した。
そこではデザイン的には、
どっちかに完全に乗るっていうことはしてなくて、
ただコンポーネントを実装するリソースは十分にあるし、
そこに対して完全にコントロールするっていうだけの
開発力が今のチームにあると思ったんで、
それもフラッターをセンターにできたっていう、
一つの一員だったかなっていうふうに思いますね。
今、ワンソースで2つのプラットフォームでサポートできるので、
フラッターを採用するところが増えていると思うんですけど、
やっぱり無難に倒すのであれば、
マテリアルデザインに乗せるっていうほうがいいと思うんですけど、
うちの場合、クライアントが得意な人が多いんで、
そこに対して、あえてってわけじゃないですけど、
マテリアルデザインに乗らないっていう選択肢ができたっていうのが、
面白いところかなと思います。
確かに。
そこはコストが払って拡張性を取るっていう選択肢が、
今のチームだから取れるようになったっていう話ですね。
やっぱり考えることとしては、
手早くできるようにするっていうのと、
自由度を広く取るっていう、
12:00
その二律背反になってるんですけど、
その中で今のチームで一番いいところを取るっていうのが、
今というか常に考えてる。
そうですね、もうタブリーとスケーラーで全く違いますね。
完全に問題解決の解決をするために、
適した技術を選んでるっていう印象は、
外から見てても、話聞いたときはちょっとおもったし、
中入って特にそうなんですね。
それはもうちょっと中規模、大規模の企業にいると、
なかなかそんな技術スタックは変わらないんで、
すごい新鮮で面白いですね。
それは今後もそうなのかな?
おそらくそうじゃないですかね。
やっぱりチームが大きくなっても、
ずっと考え続けることになるでしょうね。
もしかしたらこういう意識決定をする人が、
もっと増えて、チームも増えてっていう風になるかもしれないです。
それをしやすくするためのアーキテクチャを取っていくのかもしれないし、
セットで組織の話がついてくる。
あとプロダクトの性質にもよるんでね、
それでもだいぶ変わるのでね。
あれは?
Goを捨てた話を。
僕もそれ知らないから、実は知りたかった。
タベリーの方だとはじめからGoをどこか捨ててきて。
そうですね。
まずタベリーでなんでGoを使ったかというと、
もともと僕はメルカリにいたんでGoにはちょっと馴染みがあったっていうのと、
あとGCP使う上でSDKが充実してるっていうのが、
あってGoを使ってました。
変えていく上で、
僕ら高いレイヤーのアプリケーションにおいては、
ちょっと表現できる幅が狭いなっていうのと、
単純なタスクを書くコードにおいて、
量が長くなりがちだとか、
一つ一つにかかるコストがちょっと大きいなと思ってて、
普通の言語って言ったらJavaみたいな言語であれば、
2行で済むこともGoで書くと5行とかかかる。
それが許容できる場所とできない場所があると思っていて、
Goで5行かかるっていうのも無駄に5行書いてるわけではなくて、
そういうGoが適した環境においては、
それは許容できるかもしれないですけど、
WebアプリケーションのAPIとかにおいては、
それはそのコストを払ってでも得るべきものではないかなと考えて、
Goをやめるときにまず決めたのは、
Go以外の言語を選ぼうっていう風に考えてました。
ちなみに選択肢はGo以外は何だったんですか?
Go以外はTypeScriptとかManastとか、
あとSwiftとかも考えたんですけど、
15:02
僕はSwiftが一番好きな言語だって考えたんですけど、
やっぱりいろんなエンジニアを迎え入れる中で、
今のSwiftの状況は開発環境的に厳しいものがあるなと。
言語の将来にも思いを持てなきゃいけない。
どっちかというとさっき石川さんが言ってた、
例えばGoだとGCPの関連のSDKをコープしてたり、
コープだったりとかっていうのは相当なアドバンテージなんで、
そこがやっぱり弱い現状が多いですね。
でも逆に言うと、表現力を捨ててまでそういうSDKに頼るところも
結構いい面はあって、
例えばスケアビリティもそうだし、
今のダートでやってるパイロットのSDKはちょっと苦労したりすると思うので、
そういう細かいところは結構ネットを見てくるのが楽なところなので難しいですね。
そうですね。
たぶんやった当初はやっぱり僕一人しかいなかったんで、
SDKを使わない手は絶対ないというか、
SDKを使わない手は絶対ないというか、
SDKみたいなものを自分で書いてる暇があったら、
それ使って実装しろよみたいな感じなんですけど、
今はもうちょっと人数もいて、
タブレットを通じてそもそもGCPのSDKがどういう仕事をしてるのか見えるようになったので、
あえて違う選択肢を取ることもできるようになったっていうのがあります。
ちなみにGoからダウトにスイッチして、
当初GCP、SDK周りで元々できてたんで、できたらなって困ったこととかあるんですか?
困ったことは基本SDKがないから困るんですけど、
そうですね。でも最初に払うコストだけですかね。
基本的にGCPのサービスはGRPCでAPIを提供してるんで、
ファイヤーストアに関してもそれを呼ぶだけなんで、
後はラップしてアプリケーションを使いやすいようにするっていうだけなんで、
自分的には1週間ちょっとぐらいかかりましたけど、
大した仕事じゃないので、
ダウトはGoと比べてどう思いますか?
ダウトはそうですね、すごいダウトかなっていう感じがしますね。
いわゆるJavaScriptとかSuitとかKotlinとか、
それぐらいの表現の幅は持っていて、
もちろんGCPのサービスに関しては、
それぐらいの表現の幅は持っていて、
SuitとかKotlinとかほどではないけど、
18:01
ちょっとそれをオシャレじゃなくしたみたいな、
オシャレな具合で。
ただGoでもいいなと思ってたことなんですけど、
コンパイルが速いとか、ツール自演がすごいしっかりしてるとか、
エリダのパッポートがちゃんとしてるとか、
ダウトはかなりちゃんとしてるんで、
その点においては良かったです。
そういうのも結構大事ですね。
ダウトでまだバックエンド描いてるところはあまり聞いたことないんで、
面白いですよね。
僕も初めて聞きました。
なるほど。
こんなところですね。
そうですね。
これで石川さんの思想の裏側がみんな見つけるようになったのかなと。
大体見えた。
会話見えたところで。
チーム作りの話とかも行こうと思ったんですけど、
20分くらい撮っちゃったので、
一旦これで締めようかなと思います。
ありがとうございました。
ありがとうございました。
ご視聴頂いた方はぜひハッシュタグをつけて、
Twitterなどでフィードバック頂けると嬉しいです。
またAppleとかSpotifyでフォロー頂けると嬉しいです。
それではまた。
