新年の挨拶とPodcastへようこそ
皆さん 明けましておめでとうございます 株式会社TenX代表のyamottyです
そして Zero Topicを今年もお聞きいただき ありがとうございます 昨年の10月
ぐらいから 更新する余裕がなくて 更新していなかったんですが 今年
できるだけ時間を見つけて 頑張って 更新をできたらなと思っています
新年早々 CTOの石川さんをゲスト にお招きして ちょっと会社の中で
技術的には大きい仕決手があった ので その内容を少し深掘った話
を取っていますので どうぞお聞きください そして 宣伝で恐縮なんですが
TenXではTenX FMっていう 社内を切り取ったPodcast こちら
も運営をして 最近すごく頑張って ますので ぜひこちらもお聞きいただ
ければなと思っております それでは 本編どうぞ CTOの石川さん
をゲストに迎えて ゲスト まあ いいや 石川さんが書いたブログ
を深掘りするという会をしたい と思ってます
石川です よろしくお願いします
お願いします 石川さんが年始の 1月5日にフルスタックだとかラスト
バックエンドへという記事を書き まして ちょっとこの裏話をできれば
と思ってるんだけど 初めにどういう 内容の記事を書いたのかっていう
のを3行で説明してもらっていい
3行 そうですね これまでTenXが バックエンドとかモバイルアプリ
とか含めて あと後で書いてきた っていうので 5年ぐらいサービス
やってきたんですけども ちょっと いろいろ課題もあって それを
すぐリプレイスするという話では なくて 今後 バックエンドに関して
は 違う言語を採用しようという 動きをしていまして 今 その候補
として有力なのがラストという 状態になってて その背景だったり
とか なぜラストなのかみたいな ところをブログに簡単にまとめ
たという内容になってます
おだしょー ちゃんなみに ブログ を公開して 反響ってありました
しばやん そうですね いろいろ 反応も見てまして そもそもラスト
でバックエンドって実在したんだ っていうところから ラストじゃない
か ダートでバックエンドって 存在したんだっていう反応から
そういう選択をしたらそうなる よねっていう話であったりとか
また 一番変えがたいところが 採用とかだったんですけども 採用
を課題だと感じてラストを選ぶ って それって問題解決するのっていう
反応だったりとか 結構 さまざま ありましたね
おだしょー その反応ってどういう 形で石川さんに届いてる
しばやん でも どれもそうだな と思ってはいて やっぱり選択という
のは状況によって決められるもの だとは思っていて 状況が違えば
当然選択が変わるっていうのは 当たり前だと思っていて その中
でも その状況というものをみんなが みんな同じ解像度で持ってるわけ
ではないので そこが伝わりきら ない限りは 同じ視点になることは
ないので いろんな意見が出るのは それはそうだなっていうのはある
と思います 社内で同じ状況を見て いたとしても その状況に対して
どうしたいっていうのは 人によって 違うみたいなところもあるとは
思うんですけど そういう 徹底の 別れ目っていろいろあると思うん
ですけど そういうものを改めて 感じたかなっていうところですかね
確かに 意外とじゃあ大きいアナウンス 意思決定アナウンスみたいな形
で その外部にも 内部的にもそうだけど 受け止められてる感覚があるん
かな
そうですね 自分としても そのしたい と思ってまして 結局 このフル
スタックダートでやってきて それを 変えるつもりがあるのかない
のかっていうところをはっきり したほうがよいだろうなと思って
て それは社内に対してもそうですし 社外に対しても フルスタック
ダートでキャリアを作りたいですよ っていう人は必ずしも多くはない
ので そういう人たちにも向けて メッセージはしたかったっていう
のはありますかね
Dartからの移行の背景と課題
いいですね このStaylerのサービス の開発 2019年の末ぐらいから 基本
的にはフロントエンドがフラッター で ダートで バックエンドもダート
でっていう ダートで統一するっていう 意思決定をして だから 丸5年ちょい
かぐらい 開発と運用してきたわけ だけど 正解不正解っていうより
は 評価としては改めて どういう ふうに今 評価しているか
そうですね やっぱり良かった点も 悪かった点もあるなとは思って
て ちょっと言い訳っぽくなっちゃ いますけど やっぱり当時の状況
と今の状況って結構違っていて Stayler始めたときというのは エンジニア
10人もいないっていう状況で そういう 少ない人員の中で 結構一丸っていう
今も会社一丸なんですけど 誰が 何やってもおかしくない状態なんで
チームで分担してとか責務を分けて みたいな感じっていうよりは 一刻
も早くサービスを出すために 今 一番早くやらなきゃいけないこと
に一番早くやれるやつを当てる みたいな そういう感じになって
いたので そういう状況の中で みんなでこのタスクを共有できる
っていう意味では良かったかな とは思ってはいて 一方でプロダクト
成熟していくとか 組織の規模 も大きくなるってなると 席も適切な
サイズに分けていくっていうのは 当然起こることだと思っていて
そういうことまで見据えてやれて いたかっていうふうに考えると
それはできていないところだった かなと思っていますと 5年って
経ってみて 最初からそういうこと を想定しとけよって言われたら
それはそのとおりだと思うんですけど 意外と5年間普通にやれてきちゃ
ったなみたいなところもあって そういう評価っていう感じですかね
おだしょー 確かに 言語選択みたいな ものって 正解不正解があるっていう
よりは その状況の中で意思決定 して 実装して しかも当時って
事業的にも別に売り上げもなければ 売り上げを生むための資産もない
けど その資産を一気に短い期間 で作り切らなきゃいけない うち
が持ってるカードはフロントエンド もバックエンドも両方書くぜみたいな
エンジニアが8人ぐらいいるみたいな そういうカードの中で選んだ意思決定
としては その短期的な要求には 十分応えてたんだと思うし 逆
にしかたさんが言ってた チーム がここまで広がって 責任が割れた
チームがいくつかあるみたいな 状態になってきた中では ある
種 当時の言語選択の意思決定と チーム構造で果たしたいことを
一致させるのに 若干返りが出て きたみたいな そういうものなので
そこである種 是正じゃないけど 改めて今から少し先を見たときに
どういう意思決定をすべきかっていう のが 今回書かれたことっていう
感じなんですかね
そうですね
この5年でダートを選んだから得 られた一番大きい成果って何だった
かという問いはどうですか
立ち上げのときが一番効いたん じゃないかなと思ってはいて それ
こそフラッターというか モバイル 担当 主にモバイルの経験しかない
人がバックエンド担当したりとか はたまたまバックエンドやって
きた人がフロントエンドやったり とかっていう 機動的に担当する
ことを移せる それに応じてプロダクト 開発もたぶん無理にできたみたいな
ところは初期においてはすごく よかったところかなとは思います
逆に言うと メリットが強くでき たっていうのは 結構 最初だけ
だったかもなとは思います
なるほど メリットよりも ちょっと デメリットのほうが大きいなみたい
に感じ始めたのって どのぐらい のタイミングなんですか
そうですね 2 3年ぐらい前から そういう側面はあったかなとは
思ってて ブログにも書いてたん ですけど どれもあんまり地面性
にはならなかったっていうのも あって もちろんエコシステムない
から SDKとかないですよみたいな のがあるんですけど SDKってもう
一歩先行けば 公開インターフェース があって それを読めばいいじゃん
みたいなとか 技術的に何とかでき ちゃうみたいなものもあって 割
と何とかできちゃうところは何とか してきちゃったので あんまり地名
的にもならなかったし 最初に来 たメンバーも やっぱりマルチスキュー
のエンジニアが結構多かったっていう ところもあって それがあんまり
なんていうんですかね 行き詰まる という感じにはやっぱりなって
なかったっていうのがあります ね
おだしょー 既存のメンバーの現場 みたいな中でも ある種 バックエンド
がダートで書かれているから これは 作れませんとか これはこれ以上
進化させられませんみたいな そこまで の強いボトルネックというか ハードル
にはなってこなかったっていう ところも実態としてあるんですか
おだしょー そうですね もちろん 辛いことはありつつなんですけど
技術的要素が完全な引き金には ならなかったっていう感じですか
おだしょー なるほど 塞い自体は 何とかできたとしても ある種 記事
にも書かれてた 採用市場とのアンマッチ がきっかけみたいな ここはやっぱり
大きかったっていうのが トリガー ポイントではある
おだしょー そうですね それが やっぱりトリガーポイントで いざ
トリガーが発生したときに 頭を 違うもので切り替えようっていう
ふうに書いていったときに 今まで 致命傷になってはいなかったが
時々考えていったときに これを やり続けるべきなのかっていう
のも 改めて見直すことになって そういうことも考えた上で やっぱり
変えるべき 単純に採用できない ただそれだけで変えるっていう
よりは 採用がきっかけになった けど そのほかの面もいろいろ
見ていっても 自分たちとして今後 5年 10年とかって考えていった
ときに 変えていくべきかなっていう 判断という感じですかね
おだしょー 石川さん的には この意思決定をいきなりポンとする
というよりは 検討期間が助走も 含めてあるわけじゃないですか
石川 そうですね
おだしょー どんぐらいからちょっと 着替えて助走するかみたいになった
石川 そうですね でも この間 2025年の夏ぐらい 半年前ぐらいですかね
というか 5月か6月ぐらいに 会社 というか開発チームの中で技術
スタック確認会みたいな 今後も これをやり続けるのかどうかっていう
のを話していたときに いくつか 論点があって それこそバックエンド
の言語もそうだし あとバックエンド のデータベースで引き続きファイヤー
ストア使っていくのか そのほか ウェブフロントエンドで使い続ける
のかどうかとか そういったところ が 今 選択がどうなっていて そこ
に何の懸念があって そのに対して どういうアクションを取るべき
なんだっけっていうのを メンバー 何か集まって話してたんですよね
その中で 特に今から手を入れなきゃ いけないものとして動き始めた
のがバックエンドの言語で その ときは候補がいくつか挙がって
バックエンド言語の選定理由
いて その候補は今でも生きてはい るんですけど RustとGoとKotlinとTypeScript
の四つの候補として 小さいコンポーネント から検証を始めようっていうところ
までは 夏ごろに決めていたという 感じですね
おだしょー あれ このさっき挙が っていたバックエンドの言語以外
に さっきのウェブのフロントエンド フラッターをやめるとか いくつか
の要はイシューがある中で なんで このときに取り組むべき優先順位
の一番上にバックエンドの言語 っていうのが挙がったんですか
松本 みんなこのままでいいのか どうかっていうのは疑問に思って
いたっていうのもありますし 僕と エンジニアリングマネージャー
のカズさんとしても 採用の中で 結構 壁にぶつかっているところ
があったっていうのもあって なんで 開発しているメンバーの問題意識
とマネジメント層の課題意識が もう結構バーンときたみたいな
ところがあって これは今やるべき だし 変えるといっていったところ
で じゃあ移行するのに3年かけて それ以外何もやりませんとかって
会社として許されないことじゃない ですか なんで 新しく作っていく
ものとか 必要性が高いものから 順次っていう形になると思うん
ですけど それにすごく時間がかかる ので それは早く進めるべきだし
少なくとも 移行先が何かはさて おき 次の選択肢を模索するということ
だけは早く決めたっていう感じ ですね
実践的な検証の重要性
おだしょー なるほど その5 6月に いわゆる技術的課題を議論する
会みたいなものが まず場として 設定して 会話して じゃあバックエンド
の言語の問題を優先順位高く取り 組みましょうってなってから これ
に対して石川さんはなのか 他の メンバーも含めてなのか どういう
ふうに助走のプロセスっていう か 検証なり意思決定をどうする
かっていうのを組み立てていった のかな
石川 自分に関しては しばらく そこから何もしてなかったんですよ
そこに関しては っていうか 別の ことを 別のことをやってたんですけ
ど その別のことがある程度見通し 型っていったときに 次 何をやる
べきかっていうのを考えたときに ある領域を触り始めていって その
領域をやり方変えていくのであれば これがバックエンドの新しい言語
を検証する機会にもなるという ふうに考えて そこから結構真面目
に始めた感じですね
おだしょー それ11月ぐらいですよ ね 11月
三沢 もうちょい
おだしょー 9月ぐらいとかじゃない か 9月か10月ぐらいじゃないですか
三沢 なるほど ある種 事業上 必要なリファクターって言って
いいのかな みたいな いわゆる 実談の課題に対して 検証の機会
もぶつけて一緒にやっていった っていう感じか
三沢 そうですね
おだしょー 実談で検証することに 結構 価値があるんですかね
三沢 何ですかね 実談かどうか はさておき 結局 事業としてソフトウェア
を作ってるわけなので 事業が求める 特性を得なきゃいけない 事業が
求めてる特性で何だって考えた ときに ある程度 実談は必要じゃない
ですか われわれが持ってるシステム がどういう種類の要求がヘビー
にあって そこを守んないとどういう ことになってっていうのは 結構
事前に浅く見るだけでは分からなくて 経験をしているからこそ 知ってる
ことっていうのはたくさんある なので 実談とセットで考える
のが今回においては良かったかな と思います
おだしょー 確かに 事業特性に対する 改造度とか理解があるから ある種
その言語を選定するっていう重たい 仕事を石川さんができるっていう
のは 結構つながってる話だと思 うんですけど 今回のバックエンド
の言語を選定するにあたって 結局 なんでラストなのっていうところ
Rustの特性と他社事例
が 割といろんな人から目を向け られているポイントでもあるかな
と思ってて どういう特性とラスト の持ってる特性 ここにいいマッチ
があるっていう そこの説明もらえ ますか
山本 そうですね 僕らがそもそも 経営として掲げてることとして
資産性の高いソフトウェア つまり 僕らが運用に人用とか稼働をさ
かなかったとしても ソフトウェア が価値を生んでいるという状態
を目指したり それはどこの会社 でもそうではあると思うんですけ
ど 僕らって業務のシステムを扱 っていて その業務フロー自体が
そもそも複雑な流れを扱います し その過程ではいろんなシステム
と連携しますし 中には業務として 作業結果が反映されるみたいな
ことも結構あって いろんなデータ の流れを使って業務を回していく
それをあんまり関わること 運用 を軽くできるっていうのは簡単な
ことではないというか 単に良く するっていうよりは 意図してその
状態を作らないと 黙ってても その特性は得られないというもの
だと思っていて そこを狙って 繋げるものが 今 アラストが適して
るんじゃないかと思ったという 感じですね 今 急に最後の一段ラグ
みたいなところで飛んだ感じが するんですけど
おだしょー 事業特性上 よく弊社 の中で運営自立性という言葉が
出ている 運営を自立できる それは ステーラーを使ってもらっている
パートナーもそうだし あるいは パートナーのエラーケースに出
くわしたときに 10x側がそれを処理 するっていう運営も必ず発生して
いて そのどちらにもかかっている 言葉として 運営自立性っていう
のは われわれの中で一個重要な 品質特性を掲げてると思うんですけ
ど これとラストがどうくっつく のみたいなのが 素人には分かり
づらく もう少しちょっとかじった ぐらいの素人に説明すると どういう
説明になるんですか
そうですね いろんなパターンの 結果が起きたとしても それをシステム
とかプロダクトとか利用者側で 完結して閉じてるっていうのが
運営自立性があるっていう状態 だと思うんですけど 運営自立性
を実現すること自体は どんな言語 でもできることだとは思っていて
できるということと それがしやすい ということには すごい圧倒的な
差があると思ってて 僕らのドメイン だと さっき言った 業務フロー
が複雑とか 途中で関わってくる 外部システムとか 作業結果の入力
であったりとか そういうのが複雑 ってなったときに できるっていうこと
と やりやすいっていうことには すごい大きい差があって それが
一回こう雪だるまみたいに すごい でかくなるんですよね
おだしょー ふくりか
りなたむ そうですね ふくりかな そのときに 1個の観点として その
途中で発生する失敗というもの を網羅的に扱うということができる
のかどうかとか 失敗というもの をドメイン上の意味のあるもの
として取り扱えるのかどうか っていう2つが結構重要なところ
だと思っていて それを自然にできる のが 1つはプログラミング上 例外
という概念があるんですけど スローン するものなんですけど 例外がない
言語かつ 網羅的に扱うという 観点だと エラー語 片付きで扱う
という言語が適していると思って いて 例外がない言語の時点で メジャー
な言語だと 語とか ラストぐらい の2択に絞られちゃって エラー
片付きってなると ラスト 語は エラーは片付きじゃない形でやる
ので なので ラストが その観点 だけでも絞られちゃうっていう
のはありますかね
おだしょー なるほど
しばやん もちろん 違う言語でも 同じような実践はできると思う
し 別に語でもエラーではなくて 純正条件として結果を常に扱う
という形であれば 同じようなことは 実現はできるんですけど それが
言語プラクティスとして普通なのか どうかっていうのが もう一個大事
なことだと思う もちろん言語があって 周辺にライブラリーがいろいろ
あって その全てでそういうやり方 がされてるのかどうかっていう
のも結構大事なポイントではある かなと思います
おだしょー 確かに 言語とかツール とかって 別にこれで何かをして
くださいって言われたら ソフトウエア の世界だとできなきゃないって
ことがほとんどだと思うんですよ ね
しばやん そうですね
おだしょー 別にStaylerをRuby on Railsで作ってくださいって言われて
ても いや 作れますっていうのが 答えだと思うんだけど そこで問題
になるのが 多分チームが割れて くるとか 大きくなってくるとか
責任がそれぞれ違うとか そういう ものが起きたときに 会社として
大事にしたいことを統制しやすい かとか あるいは それを守りやすい
状態を作れるかっていうのによって 結局 ソースコードで本当に達成
したかったことが実現できるかとか 実現しやすいかとか リーズナブル
がコストでできるかとか そこに 差分が出てくるっていう話なの
かなと聞いてて思ったんだが どう でしょう
しばやん そんなとおりでございます
おだしょー 解像度 あとはラスト って ちょっとオフィスとかでも
会話してたけど 決してめちゃくちゃ バックエンドでメジャーな言語っていう
わけではまだないんですよね
しばやん そうですね もちろん いろんな実績はある言語ではあるんですけど
例えば 今スタートアップ立ち上げて 第一早期で来るかって言われると
来ないかなとは思いますね ただ 結構 熱量というか コミュニティの
熱量がある言語でもあって やっぱり ラストで一通り その概念とか文化
を理解していった人っていうのは やっぱりラストを使い続けたい
っていう 粘着性というかはあって 今 結構 上り長州の言語ではある
っていう感じですかね
おだしょー なるほど 上りのエスカレーターに乗ってるんですね 言語としては
しばやん そこだけ聞くと 流行り に乗った人みたいな感じですけど
おだしょー ちなみに他社とかで 他にラストで事例があるというか
分かんないけど さっきの片付け エラーみたいなところに対して
メリットを見出して ラストを採用 してますみたいな事例を持ってる
社名なのかサービス名とかも世 中にいたりするんですか
しばやん 例えば 一休さんとかは 全部ではないんですけど 1個のサービス
は確かラストで書いてたはずで あとはキャリーさんとか 何社か
そういった形でラストを使ってる という事例はありますね
おだしょー なるほど それは事業課題 が結構 近しいところにぶつかったり
したときに各社選ばれてるんですかね
しばやん それはちょっとどうなん ですかね 自分も後でもう一回
置いたいなと思うんですけど 結構 ラストの見方って人というか
持ってる課題意識によって違う ところはあって バックエンド
アプリケーションに広く使ってる っていうのは意外とそんなに多くない
Rustの特徴とエンジニアリングの価値
さっき挙げた二社とかは使ってる と思うんですけど 例えばLINE Yahoo
さんで画像配信サーバーとかだ とかな 結構 基盤的なパフォーマンス
が求められるところに採用する とか そういうちっちゃいコンポーネント
に使ってるみたいなケースはちょくちょく ありますね
おだしょー なるほどね あと もともとは採用の課題みたいな
ところにぶつかったのも一つの 意思決定のきっかけだったと思うん
だけど ラストっていう言語を活用 することで 当然 ダートオンリー
じゃないよっていう部分のアナウンス になるっていうのはイエスだと思
うんだけど どういうことを期待 するような人に刺さるといいな
みたいな願いがあるんですか
そうですね やっぱりラスト人口 はまだ多くはないと思ってはい
るんですけど ラストって結構 固い言語というか 制約が多い言語
なんですよね 例えば関数に値を 渡すにしても その値に
対する操作の制限とか 他の言語 より結構厳しいみたいなものが
あって それって結局はプログラミング をパッと書いてパッと動くっていう
よりは どちらかというと いかに 誤りなく組み上げていくかっていう
ところから そういう仕様が来て いて それを良いと思うのか
どうかみたいなところはあるの かなと思ってて それをやること
に対して 自分はすごく価値を感じ てるんですけど そうじゃないっていう
立場も当然あると思ってて どちら がいいかって言われたら どちら
かというと そこら辺に価値がある と感じてるバックエンドのエンジニア
の人に来てもらいたいかなと思います ね
おだしょー なるほど 石川さんが そこに価値があるって感じる背景
はどこから来てるんだろう
石川 それはやっぱり元の話に戻 るんですけど 結局 業務複雑で
そこそこ長い業務フローをミス なく組み込むっていうのは 結構
難しいというか 神経質に整頓して いきたいんですよね 端から端
で それをやっていくためとか 自分の脳みそに入りきらないぐらい
それが長いんですけど それでも 安心してとか そこそこ目を腫ら
してもソフトウェアが稼働して 価値を生んでるっていう状態に
するには そういう性質を得るしかない と思っていて そのためにはコンパイラー
にうるさいことを言われてても それを保ってるっていうことの
ほうが大事だと思ってて なんで 自分としては 結局は経営として
得たいことを得るための適した 集団だと思うから だからそこに
価値があると思ってるというところ ですかね
採用と事業の展望
おだしょー 間違いない 複雑な 業務みたいなものもそうだけど
この業務がパッと明日なくなって 変わりますみたいなものでも
やっぱないものは使ってるなと思 ってて なんか小売業の現場だし
ネットスーパーの現場で人がやってる ことって相応に難しいし 一例
だと このお客さんから注文が入って この商品をどの順でピッキング
したら効率がいいかみたいなものは もしかしたらちゃんとデータが
あれば 別に誰でも設計できるもの だと思うんですけど われわれの
場合って それ 人が実際に手で 掴んで カゴに入れてみたいな
業務を通じて じゃあカゴの中に どういう商品が入ってるかっていう
データが作られてとか 本当になかなか 置き換えにくいし すごいエッセンシャル
だし あとは食っていうものは 使ってるから すごい長期的に
そこまで不要にならないというか 長期的にちゃんと持続可能である
ことが重要な業務を扱ってる みたいな そういうところから
われわれの作ろうと思ってる資産 というか プロダクトにも同じ性質
を帯びさせる必要があるっていう ところが おそらく石川さんが
言った 経営的に欲しい性質みたいな ところなんだろうなと 翻訳しました
石川 ありがとうございます
おだしょー そんなずれてないだろう と思いながら
石川 そうですね
おだしょー 最後に採用宣伝をして 締めたいと思うので 一言いただいて
いいですか
石川 そうですね 自分としては ラストに限らずなんですけど そういう
スタンスでエンジニアリングとか ソフトウェア作りをやるっていう
人にぜひ来てもらいたいなと思 ってて 結局 事業としてより良い
状態で存続し続けるには良いソフトウェア が必要なので それに見合った
ものを作りたいであったりとか それに合ったソフトウェアを作る
のが得意っていう人にはぜひ来て もらいたいなと思ってまして われわれ
この5年かけて いろんな機会も 掴んできてはいるとは思っておいて
なので 面白い機会もありますし 社会に貢献できる機会も結構あって
個人的にはソフトウェアエンジニア として固いものを作るだけです
げえ価値があるってレアな状況 だとは思うんで そういう機会に
チャレンジしたい人にはぜひ来て もらいたいなと思います よろしくお願いします
三沢 確かに 何を作っていいか分からない
フェーズがあって とりあえず作った ものを動かしたらいろいろごめんなさい
が発生したフェーズもあり なんだ けど そこにトラフィックという
かなりの規模の流通学を扱いながら 365日現場のオペレーションを
日本の各地で支えてる状態があり みたいな っていう中で獲得してきた
特性に対する知見とか あと こういう 事業なんだみたいなことも
初めて5年かけて分かってきて 作る もの資産があって 自分が書いた
作りの構造みたいなのがちゃんと 回るようなビジネスの機械とモデル
があって あと そこに応えていく 必要があって 言語的に大きい
試決定があって チャレンジがある っていう この流れがちゃんと
つながってる会社だと思うので ぜひ 採用には困ってるともう
既に書いたとおりなので ご関心 があればお声掛けいただきたい
ですね
よろしくお願いします
はい では こんなところで終わり ましょうか 石川さん ありがとうございました
ありがとうございました
