ゲスト紹介と10Xの目指すもの
皆さん、こんにちは。株式会社10X執行役員の 江波です。この10Xfmは、高売りチェーン向け
ECプラットフォームStaylerを中心とした プロダクトを手掛ける10Xのメンバーが、
キャリアや事業への思いなどを包み隠さず リアルにお届けしていくPodcast番組です。
橋原江波の小声ラジオ第5弾となる 今回は、ゲストとして10Xプロダクト本部
副本部長のKazuさんにお越しいただき、 10XやStaylerの魅力など様々なトピックについて
ザック・バランにお話ししたいと思います。 橋原さん、第5弾ですけれども、早くもゲスト会となりました。
そうですね。エピソードがだんだん 枯れてきたので、ゲストを呼ぶっていう手段を選択し始めた。
一応、ネタはまだあったんですけども、 ずっと2人で話し続けるよりは、たまにはゲストを迎えて、
普段とは異なる切り口で話ができた方が 面白いかもねっていう話になって、
初回のゲストとしてKazuさんにお越しいただきました。 Kazuさん、よろしくお願いします。
はい、よろしくお願いします。
多分Kazuさん、他のポッドキャストとかでも 色々登場していただいていると思うんですけども、
改めて簡単に自己紹介をお願いできますでしょうか。
Kazuと申します。10Xではプロダクト本部、 副本部長、エンジニアリングマネージャーを担当しています。
今は開発組織の全体のエンジニアリングマネージャーとして、
どうやったらより開発組織が成果を出せるようになるかみたいなところで、
手を動かしたり、頭を動かしたりみたいなことをしています。 今日はよろしくお願いします。
よろしくお願いします。
自分はプロダクト本部長という立場で、 まさにKazuさんと一緒にプロダクト本部を運営しているので、
結構密に日々コミュニケーションを取っているかなと思いますし、
多分お互いの頭の中っていうのも結構それなりに シンクできているんじゃないかなと思っているんですけども、
Kazuさんと橋原さんっていう組み合わせって、
そこまで日々密にコミュニケーションを取ったりしているわけでもないと思うんですが、
多分立場上、事業とプロダクト、エンジニアリングっていうところで、
関連自体はすごくしていると思うので、
この組み合わせで話せると面白いかなと思って、 お呼びをさせていただきました。
前回第4弾の回では、事業とプロダクトとか、
ビジネス本部とプロダクト本部の関係性っていうトピックで収録をしたんですけども、
今回その派生と言いますか、エンジニアリングと事業っていう観点とか、
もしくはソフトワーエンジニアとビジネスデブっていう切り口で、
いろいろ話していければなというふうに思っています。
自分は基本的にファシリテーションに徹するので、
お二人たくさんしゃべっていただければなと思います。
まず最初に、ちょっと抽象的なところから入りたいんですけども、
エンジニアリングと事業とか、もしくはソフトワーエンジニアとビジネスデブメンバーの関わり方っていうところを、
ちょっとカズさんからどう見えているかっていうところを簡単にお話いただけますでしょうか。
そうですね。まずなんかプロダクト本部の話と被るところもあるかもしれないんですけど、
やっぱりStaylerっていうプラットフォームが成長するために、
どういうものを作るべきか、どういう要求があるのかみたいなインプットとして、
このビジネスデブからの声っていうのが一番重要なものになると思っています。
それを受けた上で、この前、えなみ様の強調と建設って話をされてたと思うんですけど、
プラットフォームとしてそれを飲むべきか、飲むならどう飲むべきかみたいなのを、
エンジニアの観点で考えて作る必要があるっていうところが、
この一番大きい接点とか関わり方のところなのかなと思っています。
その中で、偽装はこういうふうに作ったほうがいいみたいなのがあって、
ただ、このVisLemonメンバーを現実として落としたいみたいなのがあって、
そこを一緒にどこが一番いい落としどころなのかみたいなのを話し合いながら作っていくみたいな、
この関係なのかなと思っています。
ありがとうございます。
カズさんは10X歴でいうとかなり長いですよね。
はい。2020年から今5年半ぐらい10Xで働いています。
多分我々の中で一番長く10Xステイラーと接していると思うんですけども、
この5、6年の間でのエンジニアリングと事業とか、
ソフトウェアエンジニアとVisLemonメンバーの関わり方の変化、変遷みたいなのって、
何か感じられたりする部分ってありますか。
そうですね。一番大きいところで言うと、
組織体制を実は2021年か2022年に大きく変えたことがあって、
ドメインベースの開発体制の変化っていうのは、
もともとはパートナーごとにチームを切るみたいな切り方をしていたところから、
機能とかドメインによってチームを切るみたいな構造に変えたことがあって、
そこが一番この開発組織とVisDevの関わり方とか、
在り方みたいなのも変わったタイミングだったなっていうのは思うイラストはありますね。
多分、22年の9月から大きく変わっていて、
自分は22年7月の入社で、たしあわさもその後なので、
結構変化の後を我々は知ってるんですけど、
変化の前のところっていうのはあんまり知らないっていうのが実態で、
そういうふうに変わったことでの大きい変化ってどんなものがあったんですか。
そうですね。一番大きいところで言うと、
まず今よりも開発チームとVisDevのメンバーの距離ってのは、
実はもっと近い状態だったんですね。
なので、こういうものを作りたいとか、
パートナーがこういうものに困っているみたいなのが、
エンジニアにダイレクトに来るみたいな組織の構造になっていました。
困りごとを助けてあげられるっていうのは、
一見すごいいいことに見えるんですけど、
ただやっぱりVisDevもそうだし、僕ら開発チームも、
困っていると言われるとどうしてもみんな早くそれを助けてあげたくなるので、
早く何かしらの機能を作るみたいなことをしていて、
でもそれを繰り返すと、どうやら困っているって言ったときに、
解決してあげづらくなる構造になるぞっていうのが見えてきたんですね。
っていうのは、いい作り方をしないと、
結局それを保守し続けるコストみたいなところに跳ねてくるみたいなのが、
経験として分かって、
この形がいいわけじゃないのかもな、
みたいな気づきがあったみたいなのがありましたね。
これだけ長く話せそうなトピックですね。なるほど。ありがとうございます。
ちょっとまた後ほど深掘りもしていければと思うんですけども、
そういう変遷もある5.xにおいて、
とはいえ、今距離が以前と比べると近くないというか、
多分適切な距離になったとはいえ、
結構ソフトウェアエンジニアとビジネスデブが
共同する場面っていうのも結構あるんじゃないかなと思ってるんですけども、
これ、過去と比較するのはあれかもしれないですけども、
カズさんの目から見て、
協力するための情報整理
例えばこれまで所属してきた組織とかと比較したときに、
ソフトウェアエンジニアとビジネスデブの共同における特徴的な点とか、
良い点、良くない点とか、もしあれば聞ければと思うんですけども、
いかがでしょうか。
そうですね。やっぱり過去の比較、
ある比較ではないかもしれないんですけど、
このステーラってやっぱり、
すごい難しいビジネスをしているなと思っていて、
それは、いろんなパートナーさんの声に応える、
パートナーが複数いるっていう難しさと、
機能がたくさんあるみたいな難しさ、
機能の一つ一つが複雑っていうのが、
全部掛け算になっている難しさがあると思っています。
だからこそ、安直な作り方をしていると、
その掛け算の難しさがシェアリスになって、
押し寄せてくるみたいな構造になっていると思うんですね。
だからこそ、適切に開発者とビジネスのメンバーが
牽制しちゃうってことが重要だなと思っていて、
構造としてもそうなるようになっているし、
実際それが機能している組織だなと思っています。
仲良くだけできたらいいかもしれないですけど、
いや、良くないかな。
仲良く後ろに越したことはないんですけど、
ただ、例えば良くない作り方をした結果、
首が回らなくなるようなことって、
一般的なプロダクト開発でもあるし、
これまで僕は見てきたんですけど、
それってビジネスのメンバーからすると分からないんですよね。
なので、こうやっていると首が回らなくなりますよって言って
ストップをかけるのは、エンジニアは
それはある意味プロの責任として持っていると思うし、
ビジネスのメンバーから見ると、
エンジニアからしたら、これをやらなかったら
チャーンになるのか、そうですかって言われるのかって分からないので、
お互いに完全な情報は持っていない。
お互いプロとして情報を持ち寄って
意思決定をする必要があると思っていて、
それをちゃんとそれぞれが持ち寄った上で
テーブルに乗せて議論するっていうのができていると思っていて、
だからこそ、この授業のためにどうするかみたいな
意思決定が回っているんじゃないかなと思っています。
そういうふうに、お互いが完全に情報一致していない中で
適切に情報を持ち寄ってテーブルに乗せて議論をするとか、
意思決定していくって、
言葉にすると簡単ですけど、
実際にやるとなると難しさもたくさんあると思うんですけど、
今TenXって割とそれがうまくできているって言ったのって、
何がそううまくいかせているんですかね。
それをやらなかったらどうなるかっていう痛みを知っているっていうのはあると思っていて、
正直さっき偉そうなことを言ったけど、
やっぱり僕らも短期的にこれやらなきゃダメだからやるかみたいなのをやってた時期が、
結構このステーラーの序盤もあったと思っていて、
それが巡り巡って、3年後も5年後も苦しめられるんだっていうのを
未然に起きて学んでいるからみたいなところは結構あるんじゃないかなって気はします。
古くから在籍しているがゆえ、
カズさんは特にその未然に起きた痛みみたいなところを強く実感されているかもしれないですね。
そうかもしれないですね。
今ソフトウェアエンジニアの側から見た話聞きましたけど、
逆にVisDev側から見た時の視点で、
橋原さんから見てソフトウェアエンジニアとVisDevの共同のところでの特徴的な部分だったり、
橋原さんからの立場だとやりやすさを感じる部分だったりとか、
それが何からもたらされているかとか、
その辺り聞ければと思うんですが、橋原さんどうでしょう。
そうですね。
VisDevの役割って言ったら、
目の前にそれを開発してくれるエンジニアと、
それを要求してくる合理のパートナー様っていうこの2人がいて、
その間に入っていろいろ決めなきゃいけないことを決めていくっていうのが、
VisDevの主とした役割だと思うんですけれども、
まずその前提として、
ステイラーネットスーパーの話でいくと、
基本的には我々って売上連動費をもらってビジネスをしているっていうのが主になっているので、
基本的にはパートナーの事業が成長することと、
会社の事業が成長することっていうのは非常にアラインしている状態で、
それ自体はビジネスサイドもプロダクトサイドも同じ共通認識を持って、
方向は向けてるかなって思いますと。
一方で現状の例えばプロダクト側、
エンジニア側のコンディションと、
要求を上げてくれるパートナーの要求の度合いだったりっていう、
その2つのバランスがあって、
その中でとはいえこの事業をより良くしていくためには、
ビジネスとしてどういう判断をするとベストなのかっていうことを意思決定するために、
それぞれの情報を持ち寄った上で意思決定すると。
ちょっと繰り返しになっちゃうんですけれども、
結局もし仮にパートナーと社内がアラインしてない状況であったとすると、
TenXの組織構造
どっちかの立場に立たなきゃいけないっていうシーンが結構増えたんだろうなっていうふうには思っているんですけど、
とはいえちゃんと経済的にもアラインしているっていう状態があるがゆえに、
そこの調整は他のSaaSのビジネスに比べると、
比較的スムーズにやりやすいんじゃないかなっていうのが、
TenXにおけるビジネス本部とプロダクト本部、
プロダクト本部の中のエンジニアとの会話の中ではあるかなっていうふうには思っています。
実際自分が何かしらのプロジェクト的に開発のところに入っていって話をする際にも、
基本エンジニアの皆さんもパートナーの事業にとってこれがどうあればいいんだっけっていう、
同じ向きのベクトルで会話できてるなっていうのが、
根底にあるのはやっぱり仕事のしやすさとしてはあるなっていうふうに思っていて、
それが我々の社内のっていうかビジネス側とプロダクト側の、
これ前回も話したような気がするんですけど、大きな特徴かなっていうふうには思います。
まさに前回話した内容ですし、やっぱりあらためてそこをすごく
TenXの特徴の一つなのかなっていうふうには思う部分ですかね。
エンジニアとビジネスの関係
清水和さんこれ自分もTenXのソフトエンジニアって、
パートナーにとってとか事業にとってっていうことを、
すごく当たり前のように考えてくれる存在かなっていうふうに思ってるんですが、
それって普通に考えると別に世間一般的に当たり前のことでもない気がしていて、
一方で例えばソフトエンジニアの専攻過程の中で、
パートナーのために頭を働かせられますかっていう質問とかをして、
そこを見抜いてるわけではないと思うんですけど、
何がパートナーとか事業にとって必要なことっていうふうに
頭を向ける要因になっているんですかね。
やっぱりエンジニアリングだけを目的としてるっていうよりは、
手段としてうまく活用できる人が集まってるっていうのはあるのかなと思っていて、
技術的な魅力っていうよりは、
エンジニアリングってこの現実の問題を解くことに面白さがあると思っているので、
そこに魅力を感じた上で、
トレードオフがあったときに、
エンジニアリングのトレードオフってエンジニアリングだけで完結はしなくて、
事業も踏まえた上でどんなトレードオフを考えるかとか、
落としどころを見つけるっていうのが技術力なんじゃないかなと思っていて、
そういうところも含めてエンジニアリングに関心があって、
力を持った人が集まってるみたいなところはあるのかもしれないなと。
いい話だ。
あとお二人の話を聞いててちょっと気になったところ、
ちょっとそれぞれお聞きしたいんですけど、
さっきカズさんからかつての組織体制だと、
ソフトエンジニアとビジネスデブの距離が近すぎたっていう話があったじゃないですか。
今って結構ビジネス的な要求っていうのが直接エンジニアとか開発チームに入るっていう形じゃなく、
例えば間でプロダクト本部っていうところで一つ建設を聞かせていたりとか、
もしくは基本的に開発ってプロダクトマネージャーもタッチすることが多いので、
ソフトエンジニアとビジネスデブの間にはプロダクトマネージャーがいるっていう構造も結構よく見るかなというふうに思うんですけど、
一方ですごく距離が遠いとか、
ソフトエンジニアとビジネスデブは直接コミュニケーションを取れない、
必ずPDMを介してコミュニケーションを取っていますみたいな形かっていうと、
決してそんなことはないように見えていて、
結構ソフトエンジニアとビジネスデブが直接コミュニケーションを取ったりとか、
一緒に物事を前に進めていってるっていうシーンも社内ではかなり多く見かけるなっていうふうに思ってるんですけど、
この辺の距離の近すぎないとか適切な距離を保つっていう話と、
一方で一緒に物事を前に進めていくって、
ともすると相反するようにも聞こえますが、
結構自分から見ているとその辺すごくうまく取り組めてるなっていう感覚があって、
この辺りの距離感とかコミュニケーションみたいなところってどうですか?
カズさんに質問しました。
そうですね。
距離が近すぎる遠すぎるっていう表現はもしかしたら語弊があるかもなと思って、
本質的には何にオーナーシップを持ってるかみたいなところかもしれないなと思い直しました。
もともとってパートナーの単位でチームが切られていて、
開発チームもVizDevのメンバーもパートナーに対してオーナーシップを持っているっていうのが元の状態だと思ってます。
そこから変化して開発チームは機能に対してオーナーシップを持っている。
VizDevはパートナーに対してオーナーシップを持っている。
どちらもこの事業をどう成功させるかってためにそれぞれオーナーシップを持っているところの中で議論を行うみたいな感じに今はなっていると思ってます。
なのでこのディスカッションしたりとか話す中でも、
自分がオーナーを持っている機能のところでどうよくできるかとか、
あるいは何をやらないべきかみたいなのを考えることができるようになったっていうのが変化としてあるなと思っていて、
オーナーシップが明確になっているからこそより近く話しながら一緒に議論したりしても、
事業のためにいいところにたどり着けるみたいな構造になったのかもしれないなと思います。
柱田さんから見るといかがですか?
柱田さんも結構直接ソフトエンジニアとコミュニケーションを取っているシーンもあるかなというふうに思っていて、
必ずしもプロダクト本部を経由しないとアクセスできないみたいな形ではないと思うんですけど、
その辺のコミュニケーションの取りやすさとかその辺りいかがでしょうか?
会社として有限なリソースをどこに振り向けていくのかってなったときには、
ある程度全体を見てマネージしなきゃいけないっていう組織的な機能が必要だと思っていて、
エナビさんだったりプロダクトマネージャーがプロダクト全体を見据えた上で、
何に通していくのかっていう配分を意思決定してくれているっていうのは自分の理解ですと。
一方で結局解かれるべき課題と解く人っていうのを距離が長ければ長いほど、
そこってやっぱり情報のロスがあると思っていて、
究極はエンジニアが例えばパートナーの氷のバックヤードに行って、
ピッキングの課題を見に行くみたいなのができれば一番課題と技術の距離が短くなって、
いい解き方がもしかしたら思いつくかもしれないっていうのはあるなと思っています。
でもとはいえある程度お互い専門性があって、
より組織として会社としてパフォーマンスしていくためには、
ニーズを探索して持って帰ってくるというか、
課題を見つける人と実際それを解く人っていうのが独立しながら、
とはいえコミュニケーションのロスがないように、
具体的なニーズに関しては、
伝言ゲームがない方がもちろん温度感だったり、
正確な情報っていうのは伝えられると思うので、
そういう時にはある程度ダイレクトにコミュニケーションする必要はした方がいいんだろうなというふうには思っています。
とはいえそれが無限のパスがあると、
結局会社のリソースを適切に配分するっていう意思決定、
全体最低がやっぱり難しいと思うので、
最終プロダクトの全体のリソースをコントロールしながら、
良いものを作っていくときには、
プロダクトマネージャーだったりしかるべき会議で、
配分を決めるっていう形だと思っているので、
より現場のニーズをより鮮度高く伝えるためのコミュニケーションは、
あればあった方がいいんだろうなっていう理解。
コミュニケーションの効率
時々会話することがあるみたいな感じですね。
ありがとうございます。
ここまで結構うまくいっている側というか、
今話をしてきましたけども、
逆にエンジニアリングと事業の関わりだったり、
ソフトワークエンジニアとビジネスメンバーの関わり方っていうところで、
この辺りに課題感を感じるだったりとか、
もっとこういうふうに変えていきたいみたいな、
そういったことがあればぜひ聞いてみたいなと思いますし、
直接じゃなくても間に入る立場の、
PDMに対してのリクエストっていう形でもどちらでも良いので、
その辺りそれぞれ聞ければなと思うんですけど、
まず最初はかずさんからいかがでしょうか。
そうですね。
やっぱりエンジニアからすると、
結構それは今作らない方がいいとか、
こういうことをしたくないみたいに、
ある意味本能的に倒れやすいみたいな側面はあるなと思っていて、
一方で実はそれを飲むことが事業に必要なこともあるみたいなのが、
結構難しいなとは思っています。
個人的に思っているのは、
ビジネスのトレードオフがないのが最高だなと思っていて、
当たり前のことを言うんですけど、
理想の甲斐、トレードオフがない理想の甲斐があるっていうのを思った方が、
ある前提でまず考えて、
そこにごめん、たどり着けないっていう姿勢がいいんじゃないかなと思っていて、
だいたい理想の甲斐はないんですけど、
ただそれはあるはずだと。
しかし自分のエンジニアリング力とか、
今の組織ではそれにたどり着けなかったんで、
ごめん、トレードオフが生じてしまいましたみたいな考え方がいいんじゃないかなと思っていて、
ちょっとまとまらないんですけど、
トレードオフが起きないぐらいいいプロダクトとか、
エンジニアリングをしたいと思っているというモチベーションを持つことと、
それにたどり着けなかったごめんっていう気持ちを持ちながらコミュニケーションすると、
もっといい感じにならないかなみたいなことを思ったりしました。
なるほど。ありがとうございます。
逆にビジネス部からソフトエンジニアっていう側だと橋上さんいかがですか?
そうですね。元々のさっき加藤さんが教えてくれた組織の変更が、
エンジニアも含めて事業にアラインというかレポートラインができていた状態から、
機能と事業という形で持つようなオーナーシップが変わるっていう形の組織に変わっていて、
なおかつ今開発チームって機能ごとに分かれている中で、
開発チームの中で結構閉じて開発できるものっていうのは比較的進みやすいなっていうふうには思っていて、
それが結構当たり前なんですけど、複数の開発チームが束になってかからないと、
物が作ることが難しいみたいなものについては、
結構会社としてジャッジしないと進むことが難しいなっていうふうには思っていて、
例えば今年やったネットスーパーの価格を最適化しますみたいな機能は、
結構複数の開発チームと、あとビジネス部もデータアナリストだったりメンバーが入って、
一つのプロタクトの機能を作るみたいなのをやって、
結構いい成果を今出せてるっていうのは思ってるんですけど、
あれをやるっていう意思決定、もう一つの開発チームに閉じない話なので、
機能ごとに開発チームが分かれて生産性を出していくっていう、
僕は方向性自体は全然いいとは思ってるんですけど、
またがる際のコミュニケーションは当然ながら高いというか、
やっぱり意思決定する際に結構しっかりやらないといけないっていうのはあるので、
そこを自分もこれいろんなチームにまたがるから、
大変そうだから後回しって考えてるとなかなか進まないっていうところがあるので、
どう戦略との中で、会社の戦略の中で重要性を見出してやることを意思決定するか、
みたいなのを日々自分の中で悩みとして持っているので、
それは複数またがるってことは規模大きいんだから、
大変なのは分かってんじゃんって話なんですけど、
そこが課題感としてはあるかなっていう感じですね。
なるほど。ありがとうございます。
多分今すごい良いリクエストをもらったなっていう気がしていて、
まさに我々も今って結構数多くあったチームっていうのを少しずつ統合して、
分担っていうのが起こりにくいというか、
小さい単位で同じく持ってもらって保守性を高めるという営みをやったことで、
組織とチームの変化
そこをもう少しまとめて扱うっていうことがしやすくは以前よりはなってきている。
この辺半年に1回くらいですかね、チームどこに線を引くかとか、
どういう組織構造、チーム体制でこのステーラーという事業に向き合っていけばよいかっていうのを
結構アップデートしていっている中に、
当然今出たような課題に対してどう答えていくかっていう問いも含まれてはいるので、
当然明日から変わりますって話じゃないんですが、
半年、1年、2年って見ていったときに、
必ずしも今と同じ組織体制、チーム体制で、
要は領域の横断というのが発生し得る体制で向き合って生き続けるというわけではないかもしれないというところがあるので、
保守性みたいなところっていうのを保ちながら、
より広い領域にまたがるものとかっていうのをうまく扱えるような体制、
プロダクトチームになっていけるというようになっているのは、
気持ちは同じところにあります。
おそらくカズさんも同じようなことを考えているんじゃないかなと思います。
ありがとうございます。
じゃあ今日はせっかくカズさんに来ていただいているってこともありますし、
もしかするとこの橋原えなみの小声ラジオを楽しみに聞いてくださっているソフトウェアエンジニアの方もいらっしゃるかもしれないので、
カズさんからソフトウェアエンジニアとして10Xで働くことの魅力とか推しポイントっていうのを、
できれば技術的な観点というよりは事業的な観点とか、
事業との関わり方という観点から少しアピールしていただければなと思います。
小売業の魅力と発見
2つ話そうかなと思って、
まず1個は以前橋原さんが話されていた10年の話ともつながるんですけど、
ステーラって事業自体、長い時間がかかるし長く続けることが決まっている事業だと思っています。
エンジニアから見たときに、
半年動くものを作るとか1年2年動くものを作るんじゃなくて、
5年とか10年耐えられるものを作るのってかなりチャレンジングだし面白い機会だなと思っています。
エンジニアって結構設計とかアーキテクチャみたいなことを学習しているんですけど、
それが本当に生きるのって長いスパンに耐えられるプロダクトだと思っていて、
その機会があるっていうのはエンジニアとして面白いところだなと思っているっていうのが1個。
もう1つはやってみて思うんですけど、
小売って身近なドメインだけど案外知らなかったり発見があるなみたいなところがあって、
例えば不定感、いわゆるグラム売りの商品を売るみたいな機能を作ったときに、
グラムで売るって言葉で言うのは簡単だけど、
それをECにしようとしたときに決済とか含めて考えるとこんなに難しいことがたくさんあるのかって気づいたり、
バーコードの企画の種類とかめちゃくちゃ種類があって、
その種類によってどう浮き出るかみたいなのを考えるみたいなことがあるんですけど、
そういうドメイン知識を得てみるとスーパーを歩くときにちょっと景色が違って見えてきて、
ただお肉を見たときにもこれは不定感だってなったり、
バーコードをつらつら眺めながら、いろんなバーコードがあるなみたいになるっていうので、
身近だけど発見があるドメインみたいな面白さはあるかなと。
ありがとうございます。
特に2点目の話とか本当にその通りだなっていうふうに思いますね。
多分橋原さん先ほど価格最適化の話してくださいましたけど、
多分普段買い物しているスーパーの価格っていうものに着目すると、
多分橋原さんは普段の買い物の中でも価格にすごい着目して、
あれこれ考えながらお買い物されてるんだろうなと思いますし、
価格にちょっと近いですけど、
自分は以前バンドルミックスマッチっていわゆるまとめ割引、
3点買ったらいくらで買えますみたいなそういうまとめ割引の機能っていうのを作ったんですけども、
その時もその奥深さというか、
普通に3点買ったらいくらみたいな割引って一般的かと思いきや、
その実現の仕方って実は何通りもあったりとか、
この小売とこの小売はまるっきり違う考え方でそれを実現してるのとか、
そういうのが見えてきたりするので、
小売自体はすごく身近ではあるが、
実はものすごく奥深いとか新しい発見がある。
特にそれって結構複雑だったりするので、
解く課題としてもものすごく面白いっていうのは、
まさにその通りかなっていうのを思いました。
ありがとうございます。
ぶっつけ本番のような数行のネタ帳の中から、
30分以上ひねり出して話をしていただきましたけど、
橋田さん今日はこんなところで大丈夫そうですか。
そうですね。
カズさんの言語化能力や、
普段一緒に仕事してても高いので、
小売ラジオには頻繁にお呼びしたいなっていう気持ちになりましたね。
いつでも呼んでください。
カズさんもまあまあ穏やかで小売なので、
小売ラジオのレギュラーになる資格は十分にあります。
ありますね。全然ありますね。
今日は結構エンジニアリングと事業みたいな、
ちょっと固い抽象度が入りましたけど、
さっき言ったような小売っていうものの面白さとか、
スーパーマーケットの面白さみたいなところって、
深掘りしていけばまだまだ出せるものかなっていうふうに思うんで、
機会があればそういう観点で話すっていう回とかも
収録できるというかなというふうに思いました。
あとはカズさんも10年理論の仲間というか、
長い目で見てくれている仲間と一緒に働けるっていうのは
非常に心強いなと思ったんで、
10年間小売で一緒にやっていきましょう。
よろしくお願いします。
今回はカズさんをゲストに迎え、
TenXの事業や魅力についてお話ししてきました。
TenX FMではリスナーさんからのお便りを募集しています。
エピソードの感想やTenXのメンバーに聞いてみたい質問など、
どんなことでも構いません。
番組概要欄にあるお便りフォームからの投稿、
またはXでハッシュタグTenX FMでツイートをお願いいたします。
またTenXでは現在様々な職種のメンバーを募集しています。
このTenX FMを聞いてTenXに興味を持った、
カジュアルに話を聞いてみたいと思われましたら、
こちらも番組概要欄にある採用情報、
またはTenXホームページのリクルートから応募をお待ちしております。
今回はTenX執行役員の橋原とえなみ、
プロダクト本部副本部長の和さんでお送りしました。
それではまた次回。
