00:06
おはようございます、ゼロトピックです。
今日は採用面談とか、
あとは我々がパートナーとセッションをしているときとか、
あとは投資家とか、
いろんなステキスホルダーの方からよく聞かれる質問について、
毎回結構同じような回答を迫られるので、
ここで話してアーカイブしておきたいなと思います。
その質問は何かというと、
Stellarという我々のTenXが手掛けるプロダクトは、
パートナーモデルですと。
なのでStellarというプラットフォームの上を利用して、
各パートナーがネットスーパーという事業を立ち上げていくという、
それがパートナーがN社いるという、
そういう事業モデルなんですけど、
必ず聞かれる質問というのは、
カスタマイズはどれだけ対応するんですかとか、
カスタマイズの要件って絶対ありますよね、
それってどうするんですかというふうに聞かれます。
これはそれぞれの目線があるのかなと思っていて、
例えばプロダクトを作るエンジニアとかの目線でいうと、
カスタマイズで永遠に対応していくって、
基本的には相手の要件に引っ張られて、
振り回されるような意識を持たれるケースが多いのかなと思っていて、
そういうプロダクトの作り方って良くないんじゃないの、
というのが背景なのかなと思っています。
あるいは投資家だと、
単純にいろんなカスタマイズを受け入れていくという事は、
非常にリソースの使い方として良くないんじゃないのとか、
あとはビジネス的に見るとあらりを下げていく。
売上は出るかもしれないけど、
結局一応使ったものと使いまわしが聞きづらいものになるだろうから、
あらりが下がるよね、あらり率が下がるよね、
そういう目線があって、
非常に事業としてのパフォーマンスが悪いんじゃないの、
という目線なのかなと思っています。
採用後者、あとは投資家、あとパートナーか。
パートナーからすると、
あなたたちそんなにめちゃくちゃニーズがいる会社じゃないけど、
我々の要求を当然受け入れてくれるんですよね、
そういう雰囲気があって、
こっちが言いたいことを言うから、
それに対して受け入れる能力とか、
このリソースってあなたたちあるんですか、
という意図で聞かれるケースが多いのかなと思っています。
これに対して、どの方に対しても同じ回答をしているんですよ。
同じ回答をしていて、
その都度毎回同じ説明をしなければいけないというのは、
結構我々としてはもったいないし、
いかにもとっても1個目の不要なハードルをスキップできるので、
ポジティブだと思うので、
しっかり説明できるようにしたいなと思っています。
まずこのカスタマイズみたいなものについては、
我々まずどう考えているかというと、
大前提として、
プロダクトとかオペレーションというものは、
できる限り抽象化すべきという、
抽象化というキーワードとしてすごい使います。
抽象化の反対側の意味として、
これは言葉としては正確かどうかは別に、
特別としてプロダクトに起きることとしては、
03:02
断片化という言葉としてはよく使います。
抽象化されたプロダクトってどういうことかというと、
例えばある会社さんがレシピから商品を買えるようにしてほしい、
みたいな要求があったとして、
ある会社は商品からレシピが見れるようにしてほしい、
みたいな商品ページが、
例えばこういう要求が2つ全然バラバラのものにあったとして、
これをそれぞれ解決するんじゃなくて、
彼らの要求の背景にある達成したいこととか、
イシューを一度クリアにして、
そのイシューのレイヤーを少しずつ少しずつ掘り下げていって、
最も低いレイヤーのイシューに対して解決策を提示するという形です。
今の事例としてはあまり面白くないなとは思うんですけど、
これに対しての我々の解決策というのは、
一つは商品と、例えば果物、人参、玉ねぎみたいな、
そういう商品、各商品ページ、商品と、
あとはそれに対してこれを利用するレシピを紐づけるような
メタデータのデータベースをしっかり構築するという、
これとあとは、例えば商品からレシピを読み込むなり、
レシピから商品を読み込むなり、
というのはこのメタデータが揃ったデータベースがしっかりあって、
かつAPIがあれば、あとは機能ベースでは本当UIを提供するかしないかだけの話になってくるので、
それについては今後も同じような要件がおそらく発生し得るだろう、
もしくはこれっておそらくどのネットスーパーにも必要な機能だろうと判断した場合は、
全社に提供するという形でそのUIを作って、
各社ごとに個別のUIを作るというよりは、
どの会社が使ってもしっかりユーザーに対して価値を出せるようなUIを作って、
機能価値にアプローチできるようなUIを提供する。
そこの後ろ側にあるAPIとかデータベースは極めて中小化されたものを持っておく、
みたいなのがイメージとして近いです。
これと全然別のパターンで、
例えば断片化をするってどういうことかというと、
要求として、
この商品、ある商品Aを一番上のページを開いたらとにかく1個上に持ってきたいです、
みたいなニーズがあったとして、
これをそのまま対応する。
例えば水を、
なんとかの天然水を、
今日だけは野菜カテゴリーとかを無視して、
とにかく一番上に持っていきたいなというときに、
こちら側でハードコードを書いて実装して、
それを実現するみたいなことは、基本的にはほとんどやらないです。
これを断片化といって、
このハードコードしたものって全然使えない。
他の要求に対して使い回しが効かなかったり、
一度使って、例えば効果が悪かったら捨てるだけということで、
非常に効率が悪い。
これによってどういったユーザーさんのニーズが解決できるのかとか、
06:00
顧客がやりたい、パートナーがやりたいことが解決できているのかというのも
検証ができないというのが問題かなと思っています。
やっぱり我々のバリューの中に10Xが逆算するというので、
10Xというのは結局1人の意志を、
誰かの深い意志を解くものじゃないと10Xしないと思っている。
要求をそのまま飲み込むというよりは、
その後ろにあるイシューは何かというのを必ず噛み砕いて、
そのイシューレイヤーに対して最も中小化したプロダクトを提供する。
これによって一者を満足させるだけではなくて、
例えば他の要求を持っている人も、
類似した要求を持っているパートナーも満足させるし、
あるいは将来のパートナーに対しての付加価値も上げていく
ということにもなるかなと思います。
例えばこういう機能があるから、
新しく我々のStellarというプラットフォームを使いたいと思ってくださる
みたいな方に価値提供ができて、
Stellarの導入が決まるみたいなケースも往々にしてある状態なので、
とにかくイシューに落とし込んで、
中小化したレイヤーにプロダクトの開発を当て込むという形で対処しても。
これによってカッタマイズというよりは、
どちらかというと僕が使っている言葉としてはStellarを太らすという、
Stellarってプロダクトの持っている価値を太らす。
その上で、もしその価値が自分の事業に対して
インパクトがないパートナーさんには、
その機能を提供しないという選択が簡単にできるような
プロダクトのスイッチを作っておくというのを
実装上すごく重要視してやっています。
とはいえ、このネットスーパーという事業自体は歴史とか、
あとは僕らのStellarという事業も、
まだまだそんなに開始して5ヶ月とかそういうものなので、
正直まだまだ足りないものの方が多いなと思っています。
そういう意味では、とにかく今はいろんな要求の中で
ちゃんと意思を深掘ったら、ほとんどはその価値を
自分たちの実装に入れ込んでいくという形で対応しています。
一個具体的に言うと、スーパーってとにかく
ある商品の価格をいろんな方法を使って下げたり、
お得にして、それをフックにお客さんを呼び込んだり、
アップセルを狙うという、そういう販売の反則の仕組みが
ものすごい店舗の中で擦られて、研磨されて、
素晴らしい仕組みが作られている状態なんです。
ただそれってどうやってUI上を表現するかとか、
どういうAPIを用意するのかというのは、
正直ここにチャレンジした会社がゼロなので、
僕らが今まさに先陣を切ってやらなきゃいけないなと思っています。
そういう意味ではプライシングロジックとか、
あとそこにかかってくる予見とか、
どういうトリガーでそのロジックが発動するのかみたいなところの整理を
しっかり抽象化したレイヤーでやっていくっていうのはめちゃくちゃ大事で、
あとはUIについても、いろんな割引の方法が5パターンありますみたいなのがあったときに、
その5パターンをちゃんと吸収できるようなUIに設計する必要があるので、
実はかなりここは心を砕いて、脳を砕くっていうのかな、
09:03
脳の知恵を振り絞ってUIだったり実装を頑張っているところです。
UIについては特に石川さんが頑張っているCTOが抽象化してやっていくという部分です。
今、プロダクトで抽象化の断片化があって、
質問への回答については、とにかくプロダクトは抽象化して、
ステラー自体の価値を太らせて、
オプショナルに提供したりしなかったりすることができる状態を作っていくので、
断片的な開発はしない。
基本的にはこれによって、
我々の作ったものは資産になって、
複数のパートナーに提供できる状態になるので、
あらゆるインパクトもすごく強いですという、
そういう回答が私がいつもすることになっています。
今のはプロダクトの話なんですけど、
僕らってプロダクトだけで事業価値を出しているかというと、
もうNOなんですよね。
プロダクトだけではなくて、
カスタマーサポートについては、
我々は全部BPOという形で業務を引き受けて、
実行してあげている側面があります。
それ以外にも、ネットスーパーだと
オペレーションの中でも3つすごい肝になるのがあって、
1つは在庫管理、2つ目がピックパック、
3つ目が配送管理。
この3つのうち、
例えばピックパックについては、
我々が現場に入り込んでオペレーションをセットアップして、
それに必要なプロダクトも提供するという、
こんな形で立ち上がりをサポートしていたり、
するので、
我々自身のオペレーションの知見自体も
ものすごく抽象化していくし、
例えばパッと現場に入って、
その現場の予見をパッと見たときに、
ここの現場だったら、
こういうオペレーションメソッドをインストールすべきだし、
それに適切なシステムは、
5パターンのうちAパターンですという、
そういう形でオペレーション自体も抽象化していく
ということを捉えしています。
カスタマーサポートみたいな部分で言うと、
世の中にカスタマーサポートを外注して
BPOとして受けるという会社は5万人いるんですよ。
そういう意味では正直難易度も競争優位性も
そんなに高くないかなと思っても。
他方で、このキックバックとか、
あるいは在庫管理みたいなものって、
ネットスーパー特有のペイン、
しかもめちゃくちゃ深くて、
昨日おとといかな、
赤井君と話した80回目のゼロトピーの回があるんですけど、
その中で話していた中に、
ワークフォースにおいて、
デジタルトランスフォーメーションしていくにあたって、
2パターンあります。
1つはレベニューのボトルネックになっている、
レバレッジが低くなっているもの。
もう1つは単純にコスト効率が悪いもの。
コスト効率が悪いものは、
愛密の1社のうちの1つにしかならなくなるので、
付加価値ってそんなに出しづらいんだけど、
前者のボトルネックになっているもの、
レバレッジが低いものは、
レバレッジを上げると、
パートナーにとっては売上がバコンと伸びるような
要因になるので、すごく重要です。
この在庫管理とピックパックについては、
まさに前者にあたるんです。
後者か。
レバレッジの部分にあたるんですよね。
なので、ここの部分については、
12:00
ものすごく我々が知見をため込んだり、
中小化したオペレーションを導入できたり、
専門家である、
そしてそれをセットアップできるエネブラである。
あとは、そこに最適なプロダクトを持っている。
そのプロダクト自体も中小化していて、
パターン化されているということが
めちゃくちゃ重要なんです。
なので、冒頭話した、
プロダクトの中小化だけじゃなくて、
オペレーションの中小化。
これによって、相手のペインを受け切ることができる
というのが、
僕にとっての大きい価値だなと思っていて、
これ自体も実はアラリを底上げする要素に
すごく効くんですよね。
どういう点で効くかというと、
我々レベニューシェアのモデルなので、
オペレーションの効率があって、
売上が上がると、
同じシステムの中で、
単純に、
レベニューが上がって、
我々の取り分も増えるというので、
アップサイドは伸びる。
なので、コストは変わらないけど、
アップサイドは伸びる。
あとはもう一つは、
このBPOというか、
オペレーションをセットアップするというところ自体に、
我々が費用をいただいてやるケースもある。
今後は特に増えるかなと思っていて、
ここの部分で、
しっかりビジネスデブで、
アラリを生成できるというか、
そういう部分があるかなと思っています。
なので、
中小化したものはとにかく、
需要価値を高める、
ど真ん中のセンターアップになっているので、
我々としては会社として、
すごい注力して取り組んでいく。
それはプロダクトサイドもそうだし、
ビジネスサイドというかオペレーションだったり、
そういったところでも同じだよという話をしています。
ただ最後、
中小化できないコンポーネントが
1個だけあるんですよね。
それがビジネスデブ。
ビジネスデブと呼んでいるものは何かというと、
僕はリレーションとサクセスという2つの要素に分けています。
リレーションは、
僕たちは信頼を気付いて、
僕らが信頼として劣行している場合が多いので、
いかに信頼してもらうか。
そこでいろいろなカードを用意して、
信頼をしてもらって、
最終的には我々のStaylerというプロダクトは、
創業者か社長しか買えないプロダクトになっているので、
創業者と社長のマインドチェンジを促していったり、
そこの気持ちをしっかりグリップしたり、
そこでしっかり固いアクションを握れるようになる。
それで最後、契約に落とし込む。
契約というのは最後、
交渉ごとなので、
引いたり押したりして、
お互いの打決点を1個1個見つけていく必要があるんですけど、
そういうところをしっかりマネジメントできるというのが、
まずはリレーション。
もう1つのサクセスというのは、
相手のペイン、
パートナーのペインだったり、
パートナーの奥にいらっしゃるエンドユーザーさんのペインと、
あとは僕らが持っている提供価値、
中小化されたプロダクトだったり、
オペレーションを作り上げる価値。
これのギャップ、フィット&ギャップを見て、
フィットするものをしっかり当てて、
価価値を上げていくという、
それによってあらりに転換していくという、
その2つがあって、
このうちのサクセスは中小化できるんですよね。
なんですけど、リレーションはやっぱり
中小化できないなと思っていて、
それがやっぱりその一社一社、
しっかりコンテキストが後ろにあるんですよね。
これ前回話した内容なんですけど、
どういう位置から、
どういう創業から、
今の立ち位置になるのか、
どういった取り組みができるのか、
やっぱり一つ一つの会社が全く違ったり、
15:01
工業者のマインドセットが全く違うんですよ。
そういう意味では、
ここについては完全に、
一つ一つのパートナーの背景を、
本当に彼ら以上にリサーチをして、
彼ら以上に知っている状態になって、
その上でベストな選択肢って何ですかっていうのを、
我々が提案するような形になっています。
なので、僕らとしては、
ステーラーを使わない方がいいですとか、
ネットスーパーをやらない方がいいですという提案も
もちろんあるんですけど、
それによって、
ステーラーを使わない方がいいですとか、
ネットスーパーをやらない方がいいですという提案も
ものすごい多いんですよ。
それはやっぱり彼らのことだったり、
彼らの周囲にいらっしゃるユーザーさんのことを
考えていることなので、
それについては正解というか、
ある種正しいと思っています。
日本というか彼ら、
あるいはその周辺の事業環境に応じた策を取って、
成長しなきゃいけないので、
成長しないことを提供してもしょうがないと思っています。
それもできるのは、
僕らが初期費用モデルじゃなくて、
レベシアのモデルで、
成長する会社と無理な事業を行っても、
お互いに嬉しくないという状態を、
ビジネスアライン上作れているからだと思うんですよね。
その代わりに成長する会社にはフルベッドできるという、
そういう関係性が築けるのは、
ストレートで面白いし、
個人的にも嘘がつけない人間なんで、
正直にできて嬉しいなと思いながら、
自分にフィットしたビジネスモデルだなと思ってやっています。
ということで、
今日はよく聞かれる質問の一つですが、
日本のユーザーさんたちに、
日本のユーザーさんたちに、
いろんな反映があり言葉がはいない りーなんですけれど、
だから教えていただければなと だいたい感じに思いまして、
一部のあなたにはかなり回答が多いです。
想像するほうがなかったら、
発明がパリピーなのも中 Sicherheit な、
可能性があります。
なので、
色々とそれに基盤して学ぶということが、
皆さん勉強をしているので、
必ずこのような期間を 어ってると思うんですが、
今日は本当の動画に繋げていきたいと思うんですけれども、
・・・
