00:01
皆さん、こんにちは。株式会社10Xソフトウェアエンジニアのふたどです。
この10Xfmは、10Xを作るというクレートと小売業の未来を開くミッションに、
Quality MKCプラットフォームStaylerや小売業の構造的な課題解決を推進するDXプロダクトを複数開発している株式会社10Xのメンバーが
キャリアや日々の出来事、学び、プロダクトに対する思いを包み隠さずリアルにお届けしていくPodcast番組です。
今回は10Xfm内の企画の一つであるエンジニアの部屋の第8弾として、
鈴木さんにお越しいただいています。
鈴木さん、よろしくお願いします。
よろしくお願いします。
最初に簡単に自己紹介をお願いしてよろしいでしょうか。
お届けチームの紹介
はい、私は鈴木です。お届けチームというチームに所属しています。
私の前にまずお届けチームとは何ぞやという話ですけど、
お届けチームはECサイト、小売様がECサイトをやる上で必要になってくる店舗で使うアプリ、スタッフアプリと10Xで呼んでいるんですけど、
スタッフアプリを中心に機能開発や運用を募集しているチームです。
具体的にはお客様から来た注文を元に、
実際のスーパーマーケットの売り場から商品を取ってくるだったり、
箱詰めした商品たちを配達するための機能が重なっているものがスタッフアプリと呼んでいるものですね。
こんなチームで働いていて、僕は比較的サーバーサイドエンジニアとして強めがあるので、
アプリというよりはアプリの裏側を主に作っていることが多いです。よろしくお願いします。
よろしくお願いします。スタッフアプリの運用保守がメインという感じなので、
一般的なB2Cの話でいうと、2B向けのものをメインで作っているチームという感じになるんですかね。
そうですね。利用される方は基本的に小売業でスーパーで働いている方だったりするので、2B向けと言っても間違いないと思います。
機能開発の経緯
ありがとうございます。さっそくチームのお話とか、鈴木さんこれまでやられてきたこととか聞いていきたいなと思うんですけども、
最初にお届けチームのこれまでみたいなところを聞いてみたいなと思ってまして、
チームができてからもう大体どれぐらいになるんですかね。
大体3年ぐらいはそろそろ経つかなっていう気がします。
結構長いですよね。3年。
そうですね。僕が入社して半年ぐらい働いたらお届けチームでやっていくぞみたいな感じだった覚えがあります。
具体的にその3年間の中でどんなことをやってきたのかっていうのを聞いてもいいですか。
そうですね。チームの営みとしては、まず機能開発に関して言うと、
Staylerでは以前からピックパック、商品を売り場から選んでくる機能ですね。
それで送料ピックと呼んでる、いっぱい商品を集めてきて、バックヤードにいっぱい商品を集めてきて、
バックヤードで注文ごとにパックしていくっていう手法をサポートしてたんですけど、
そうではなくて売り場から商品を選んでくるときに普段に注文ごとにカゴに入れている状態を作る、
バスケットピックっていう新しい機能を実装するのがお届けチームの初仕事かつ大きな機能開発だったなという覚えがあります。
その後は比較的、普通の機能改善だったり、それまで積んできた不細を返しましょうで地道な改善をしたりとかが多かったかなと思います。
ありがとうございます。全然わかんないで聞いちゃうんですけど、送料ピック、商品集めてきてバックヤードでっていうところと
注文ごとに商品を集めていくみたいなのって、業務のやり方とか変わっちゃうと思うんですけど、
それはどういった背景で開発していかなきゃいけない、作らなきゃいけないってなったんですかね。
まず送料ピックをやるには結構店舗が大きくないといけないんですね。店舗というよりバックヤードですね。
スタッフの方が作業できる場所が結構広くないと作業できないですね。いっぱい持ってきて、いっぱいバラしてみたいな感じなので。
一方バスケットピックに関しては、カゴをそのまま持ってってそのまま集めてみたいなことができるんで、比較的ショースペースで始められるっていうのがバスケットピックの魅力なんですけど、
当時バスケットピックじゃあやろうって言った時にちょうどそのショースペースで始めたいみたいな店舗だったりが多かったので着手し始めたのかなっていう覚えがあります。
そっか、前提として倉庫みたいなところがあって、そこから注文を各家庭に届けるというのではなくて、
基本的にその店舗、リアルの店舗があるところから届けているっていうのがあるので、ショースペースでやれた方が嬉しいみたいなのがあるって感じなんですかね。
そうですね。ステイラー、大前提だったんですけど、ステイラー導入してる小売業さんの各リアル店舗ですね、
実際に僕ら日常生活してて足を運んでる店舗を配送拠点かつ倉庫のように扱ってるみたいな感じなので、
おっしゃる通り、実際の店舗で商品を集めて送ってみたいな。
なるほど。ありがとうございます。
その送料ピックからバスケットピックに変えるとか開発するみたいなところで大変だったこととか難しかったこととかであったりしますか。
そうですね。当時大変だったのが、当然ちゃ当然なんですけど、送料ピックとバスケットピックという手法があって、
将来バスケットピックをやるぞっていうのを前提にした構造にはなってなかったんですね。
なので、いろいろばらしてというか、改めて考え直しながら作るみたいなのはちょっと大変だったかなっていう気がします。
いきなり機能作るっていう感じじゃなくて、リファクタリングするところからやっていくみたいな感じですかね。
そうですね。そのタイミングで送料ピックを実現してきた高度の群の中には潜在的なリスクとかがいっぱいあったので、
ちゃんと直しながら構造もバスケットピックにも対応できる構造を目指そうというのをしてましたね。
ありがとうございます。その辺がもしかしたらこの後聞こうかなと思っていたところにつながるのかなと思ったんですけど、
非同期処理の最適化と未来
非同期処理の最適化みたいなところとかをお届けチームでやられていて、
ブログの記事とかも書かれてたような記憶があるんですけど、実際に何やってきたかとか聞いてもいいですか。
そうですね。非同期処理の最適化をですね、当時送料ピックを実現するにあたって書かれていた構造が非同期処理ほとんどなかったんですね。
そうすると結構集計周りとかが、一つ商品をピッとした時のシーケンスの中にデータ集計のロジックも入ってたんですね。
そうなるとデータベースがすごいパワフルだったり、パワフルだったら気にならないかもしれないんですけど、
ピッピするタイミングってすごい多いんですね、当然なんですけど。1秒間に早い方だと何商品もピッピするので、ピッピしているタイミングで集計が起きるとかなり負荷が高かったんですね。
かつ集計っていう名指しをしているように、一つの商品じゃなくていろんな商品とか、もっと広く言うと1日分のデータを横断して集計しなきゃいけないので、ピッてした瞬間にすごい量のデータ読み込まなきゃとか、
読み込みがなくても方針の競合とかをすごい考慮しないといけないとか、複雑になってたんですね。それが非同期処理になると、最終的に数字が合えばいいみたいな風にかじ切りした。
その結果、ピッてした時のロジックの中には集計が入ってこなくなるので、ピッてしたらすぐピックしました。一旦完了ですっていうリクエストレスポンスの形式をとっているとすぐレスポンスを返せるっていう風になって、最適。本当にすぐ返せたらいいものなので最適化できたのかなっていうところですかね。
なるほど。例えばですけど、今までだったら10個の商品を1個のチームの中で集めなきゃいけないってなったときに、スタッフアプリで商品集めましたっていうのを記録するために商品のバーコードを読んでいくんだと思うんですけど、バーコード読みますぐるぐるが表示されて、2個目の商品読みたいのに読み終わるのを待って、それがピックされましたって1秒とか後になったらまたもう1個商品を読んでっていうのをやらなきゃいけなくて。
10秒とかかかったのがもう1個1個の商品を待たなくてよくて、2、3秒で10商品読み終わるようになるみたいな感じのイメージですかね。
サーバーからの視点だと、そういう形で大丈夫で、その10秒待たなきゃいけないみたいのを、実際本番環境でそうなっていると仕事にならないので、そういうのをごまかすためにクライアントサイドで結構リスキーな画面の見せ方とかしてたので、それをしなくて。
完全にしなくてよくなっただけじゃないんですけど、かなりリスクを減らせる形にはなったというところですかね。
ありがとうございます。動機的にやってた処理を非動機にすると、それによる別の問題というか考慮しなきゃいけないことみたいなのが出てくるかなと思うんですけど、そういうのってあったりするんですかね。
そうですね。やっぱり初めて非動機処理。いわゆるThinkAwaitとかみたいなプログラミングレベルの非動機処理じゃなくて、PubSubとか使ったシステムレベルの非動機処理をやっぱり初めてやろうとすると、いろんなところでつまずいたり、運用してみてこれつらいねっていうのがやっぱりあると思うんですけど、
僕は比較的全職とかで非動機処理システム使ってたので、最初に抑えられるところは抑えられたかなと思って。
例えばですけど、非動機処理がピタゴラスイッチみたいに走るわけですけど、ピタゴラスイッチ、どこからピタゴラしてきたんだみたいな。
そういうのがわかるようにログを仕込むとか、仕込むっていうのも、いわゆるバータイ的じゃなくて、仕組み的にログがつながるようにしておくみたいなのができたので、難しいところだってわかってるところをあらかじめ覚悟して挑めたかなっていうところはあります。
社内で他の人が同じように、これまで同期的にやってたけど、非動機にした方が良さそうみたいなところがあったら、今回作ったものとかを真似しながらやったら、一定動くもの、ログとかもちゃんと入れられたものが作れたりするんですかね。
僕バカみたいな質問しちゃうんですけど。
そうですね。それは実績があって、Tempoチームっていう届けチームとは別のチームがあるんですけど、そこのチームが比較的大きいデータを扱うようなところ、そここそ非動機処理が光る場所でもあったので、使ってみますか、使ってみましょうかみたいな話で同じ仕組みで機能を実現して、
運用も今ちゃんとできてる認識なので。
素晴らしいですね。その時の導入とかは結構鈴木さんがサポートしてたりするんですかね。というよりかは勝手にキャッチアップしてて、適宜質問が来るみたいな感じだったんですかね。
結構能動的にキャッチアップしていただけた気がするので、行って進めてもらって、これってどうなってるんでしたっけっていうところだけサポートしてあげてとか、あとは非動機処理だからこういうことあるかもねみたいな観点でレビューとかは入ってましたね。
ありがとうございます。この非動機のところの話だけでも30分とかこの時間を使い切れるぐらいの深さとかがありそうだなって思ってるんですけど、ちょっと別のことも聞いてみたいなって思ってまして。
今お届けチームでスタッフアプリの運用保証みたいなのがメインという感じだと思うんですけど、今後チームとしてどうなっていくかみたいなところをちょっと聞いてみてもいいですか。
そうですね。ここを今から2、3ヶ月とか半年とかかけて、お会計チームというチームとチームの合体が予定されているというか、本当に最近キックオフしたぐらいで進んでますと。
チーム統合と業務知識の向上
お会計チームと合体するってことはお届けチームの人がそのお会計チームでやってた領域、ちゃんと運用保守できないといけなくなるので、ちゃんとキャッチアップ頑張ろうね。
特にその会計チームがやってるところって取引的なところが多くて、注文、あと注文が最終的に売上としてどう計上されるかみたいなところだったり、
頭の切り替えが必要な業務知識がどんどん増えていくんで、一生懸命やるぞ、お届けチーム頑張らないとねっていうところ。
プラス、逆にお会計チームの方々はお届けチームでやってる領域に一生懸命適応してもらわないといけないところなので、お互い頑張ってキャッチアップしようみたいなのは今始まってるっていうところですかね。
キャッチアップの仕方とかって話したりするんですか?
とりあえずここにあるから見てねみたいなのが一番話しがりというかハードモードだとして、反対側、例えばペアプロするとかモブプロするとか、
同期的にちゃんとキャッチアップの時間をとってやるみたいなのがあるかなと思うんですけど、会計とお届けだとどんなふうに進めようかっていう話になってるんですかね。
今だと一番ちょっとずつ進められるっていうところで、お届けチーム、会計チームでそれぞれ小粒の機能改善とか、なかなか手つけられなかったことっていうのを用意しておいて、
じゃあちょっとこれやってみてくださいね。困ったらペアプロなり集まったりしましょうみたいなものをやってますね。
めっちゃいいですね。ちょうど僕のいる売り場チームも4月に商品データチームっていうところと合体していて、
だいたい3ヶ月ぐらい合体した後のチーム運営みたいなのをやってきてるんですけど、
小さめのタスクをとりあえずやってみてよって言ってやってもらうみたいなのは僕らもやってて、それは結構良かったですね。
関連するところとかを見ながらわかんないことは聞いて、徐々にできる範囲広がっていくみたいなのがあったりとかして、
あとすごい良かったなっていうのは、分かってる人、僕らの場合だと売り場チームのメンバーに対して商品データチームの人が、
商品パイプラインと言われているDBTの処理系があるんですけど、それが全体像のアーキテクチャってこうなっていて、
そこでデータがどう流れてとか、わりと細かいところは全体感をとりあえず1時間で説明しきるみたいなことをやってもらうことで、
頭の中にどの辺を見ればいいかみたいな地図が出来上がった印象はあって、そういうのはすごい良かったなって思ったりしますね。
人材採用とチームの魅力
お届けチームで言うと、さっきも話題に出た非同期処理周りっていうのは、同じように全体感がつかめるように説明できるといいかなと思いますね。
ちなみに、これは話せたら大丈夫なんですけど、チームの合体みたいなところが出てきた背景とかって何かありますか?
そうですね。一番大きいのはチームの人数がそれぞれ少ないっていうところですかね。
お届けチームで今運用を募集しているのはソフトウェアエンジン2人でアプリ側の人、僕がバックエンドの方みたいな編成になっているので、
今、オンコール対応とか2人で回してて、大変だねみたいな。
お会計チームも同じような人数編成なんで、大変だねみたいな感じなので、大変同士集まって何とかしようみたいなのは一つ大きいことかなと思います。
ありがとうございます。合体することで人数が増えるっていうのはある一方で、それぞれが今持っていた持ち物っていうのが集まってくると思うんで、守備範囲も広がるみたいなところあるかなと思うんですけど、
今って採用とかってしていきたいなみたいな感じなんでしたっけ?
そうですね。積極的に採用もしてますね。
どんな人が来てもらえると嬉しいなとかってあったりしますか?
そうですね。お届けプラスお会計チームって結構固いところというか、UI、UXでお客様に良い買い物体験をというよりは、それを支える裏側のデータとか、
それを支えるスタッフの方々の業務を支えるみたいな、円の下の力持ち的な役割が求められるので、それを楽しめる人かなっていうのと、
非同期処理、結構難しいことやったりしてるし、そういう難しいことをやり出さないとシステムが良くならないところが多々あるので、
大きく振りかぶって改善するのも楽しいっていう人が来てくれると一緒に楽しめるかなとは。
ありがとうございます。このポッドキャストを聞いた方で、もし興味を持った方がいたら、ぜひポッドキャストのコメントとかでもいいですし、
Twitterとかでもいいですし、書いてくれたら声をかけにいくかもしれないです。
ありがとうございます。鈴木さんの方からこれは話しておきたかったなとか、僕に対して売り場チームのこととかでもいいんですけど、話し足りないこととかってあったりしますか?
そうですね。お届けチームの魅力を一つ言っておくと、改善するものが多いとか、チャレンジの後押しを頑張っているチーム。
やっていき乗っていきチームだっていう言い方をしてるんですけど、実際にそれが実を結んでというか、
Flutterのアーキテクチャ系の勉強会にチームメンバーが登壇したり、僕もイベント駆動みたいな文脈で勉強会に登壇したり、
結構難しいことをやってるからこそ、外に出る機会っていうのも作り出そうと思えば作れると思うんで、
今ちょっとTenX的に僕が露出をできているかどうかって言ったらちょっと微妙なんですけど、
外部発信とかにできるぐらい何かを得られるはずのチームだと思ってます。
ありがとうございます。自分は技術候補を兼任している身として、
ぜひ鈴木さんにいろんなところに露出していけるようにサポートもしていきたいなと思いました。
ありがとうございます。
ありがとうございます。いい感じの時間なので、今日はこの辺で終わりにしたいかなと思います。
すごいお届けチームのこといろいろ聞けたりとか技術的な挑戦聞けたりとか、
どんな人次来てくれたら嬉しいよみたいなことが聞けたかなと思います。
TenX FMではリスナーの方からのお便りを募集しています。
エピソードの感想やTenXのメンバーに聞いてみたい質問など、どんなことでも構いません。
番組概要欄にあるお便りフォームからの投稿、またはXでハッシュタグTenX FMでツイートをお願いいたします。
またTenXでは現在様々な職種のメンバーを募集しています。
このTenX FMを聞いてTenXに興味を持ったカジュアルに話を聞いてみたいと思われましたら、
こちらの番組概要欄にある採用情報、またはTenXのホームページのリクルートから応募をお待ちしております。
最後にSpotify、Apple Podcastsなどお聞きのPodcastアプリで番組のフォローを忘れなく、
最新エピソード配信時にお知らせが届いたり、また過去エピソードの再生済み、未再生が一目でわかるようになり大変便利です。
今日のお相手はフタブーと鈴木さんでした。
鈴木さんありがとうございました。
ありがとうございました。
それではまた次回。
