00:00
[音楽]
こんにちは、ゼロトピックです。今回は12月13日に行われた「Beyond Source」というイベントの様子をポッドキャストで配信します。
イベント主催者である、Azitの吉兼さんから公開収録、公開相談という形で
TENXの矢本社長に学ぶエンタープライズDX事業のTENXの極意というテーマでいろんな相談を受けました。事業開発だったりプロダクト開発、あるいは組織開発、その後のQ&Aまで非常に盛りだくさんのコンテンツとなっているので、ぜひお聞きいただければと思います。それではどうぞ。
[音楽]
今日ですね、事業開発について最初にお話しさせていただきつつて、プロダクト開発だったりとか組織開発についても均等にお話し聞いていけたらと思っております。
結構アーリーステージで我々もそうですけど、エンタープライズの案件、1件目から学べることがすごくあるのかなと思ってますので、まず最初に矢本さんにお聞きしたいところでいきますと、
1社目のモデルケース、これ今やってる案件とちょっと種類も違ったりだとか色々あると思うんですけれども、最初の案件で何を重視していたのかというところと、そのモデルケースを通じて学んで、そこから先の案件でやっていく中で変えていったことをお答えしてもらえますか。
そうですね、最初の案件で大事にしていたことと、その次回以降で変えたものですよね。1個目で大事にしていたものっていうのは、そもそも事業になるものっていうことですかね。
特にB2Bの事業、B2BとB2Cのモデルですけど、我々その手前がB2Cなんで、完全なC向けの事業で、
C向けの事業って一つ、今となってはやや笑い話かもしれないですけども、なんか顧客が集まれば、要はユーザーがすごく集まってスティックニスが十分あれば、マネタリズができていなくても、それは良いものだってされる、風潮というか評価されている金融市場の環境っていうのはあったんですよね。
なんでまあそれを基本的には、我々も踏襲して事業を始めはスタートしてたんですけど、当然ですけど、そこから先に本当にマネタリズできるのかとか、そもそも事業としてスケアラビリティがあるのかとか、またもっと手前大事なのは、これを続けていった先に本当に
顧客たるユーザーとかお客様にとって、重要な問題が解けるのかっていう問いがずっとあって、それをより良い形で解消する。
良い形っていうのは、例えばエンドユーザーにとってももっと深いソリューションとか深い問題が解決できていて、
事業としては我々は、なんか全然稼げてないってとこから、当然ちゃんと稼げるっていう状態になって、イコール継続性が出て、
あるいはその稼ぎ方みたいなところについても、ある種少し顧客の体験を既存する。例えば分かりやすい例で言うと、広告のモデルって顧客の体験を既存しやすいモデルだと思うんですよね。
03:08
お客様が見ているメディアとか、箇所分時間の一部にお客様が見たくないものを入れて、それをお金に変換するっていう。
そういうことをせずに、要は事業に変換できるかとか、より良い事業が作れるかどうかっていう観点で、まず我々すごく大事にしていて、
それをやろうと思った時の手段として、特にこのネットスーパーとか、食品のECみたいな領域って、
いわゆるECとか小売のカテゴリーの中でも一番難しい領域の中で、それをどう実現するかっていうところの選択肢の中で、
我々としてはエンタープライズの、要は大きな小売さんと組む方が絶対にいいと思ってたし、
組むことによって顧客、要はパートナーっていうステークホルダーが一つ増えるんだけど、そのステークホルダーの問題も解決できるかっていうところをすごい大事にしてた。
で、これはあまり今でもそんな変わってなくて、我々にとって直接フェイシングするというか対面するお客様ってパートナーの方、
あとはそのアプリとかウェブサイト通じてエンドユーザーの方っていう、エンドユーザーの中には最終消費者であるユーザーもいれば、
スタッフ、店舗のスタッフの方とか配達のデリバリーのスタッフの方とかもいらっしゃって、そういった方の問題解決できたり、
良い体験を提供できるかっていうところを未だにずっと大事にしています。もう一方の観点でエンタープライズの方から見た時に、すごく何が大事かなって考えると、
彼らが実現したいことが今何らかの理由で実現できていなくて、それが我々がいることによって実現できますっていう、その間が埋められることがすごい、
なんかまあ当たり前ですけど大事じゃないですか。だけどそれが何なのかって初め絶対分かんないと思うんですよね。
顧客とフェイシングしてるだけとかでも、僕らはそれが分かるきっかけがあったんですよね。それは自分たちがそのB2Cの事業でやっている中で、
エンドユーザーから直接の声っていうのを、その我々が直接いただくっていうことがあったり、データを直接ファーストパーティーとして収集することで、
なんか、えっと、まあ小売の先にいるお客様が何困ってるかっていう、それをどう解決しなきゃいけないかっていうことを、
小売さんも知ってると思うんだけど、我々も知ってるって状態になれたので、
事業界できたっていうのが、なんか初め、よかったし大事にしてたことかなっていう。
何を買ってもらったかというと、TENXはユーザーについてすごくよく考えていて、そのためのソリューションを作ってくれる
っていうことに、小売の方、エンタープライズの方に約束するってことを、
なんか、初めはすごく大事にしてたし、今も基本的には変わってない部分かなと思ってます。
で、はい、どうぞ。
06:01
なんか、そんな中でこう、最初のタイミングってまだ例えば、Staylerのプロラフトも今よりもまだまだ全然プロトタイプに近いと言いますか、
やれることやれないこと制限があったりだとか、すると思うんですけど、結構絞ってスタートしていく形だったりとか、
そこからアップデート、アジャイルで改善していくみたいなところを踏まえて、最初のタイミングでどこに集中したのか、そこからどうやって変化させていったのかみたいなのをお伺いできますか?
はいはい、これなんか次で話そうと思った話なんですけど、1社目と2社目、3社目、4社目で何が変わったかというと、我々プロダクターが変わってるんですよ。
売ってるものがそもそも全然違いますって状態になっています。
で、初めの、まあ伊藤嘉洞さんなんですけど、伊藤嘉洞さんに売ったものって何かっていうと、
要は顧客体験、UXがいいアプリなんですよね。ネットスーパーってすごく複雑なサービスで決済の仕方も結構めんどくさい。
1回注文して終わりじゃなくて、注文変更というのは頻繁に入ったりとか、あるいは配達枠っていう概念があったり、すごい複雑だ、普通のECじゃないんですよね。
で、その普通じゃないECをお客様普通に使えるようになるには結構ハードルが既存のウェブサイトとかだとあって、
それをなんか上からラッピングして、めちゃくちゃいい体験で経済率が上がりますっていうテーマンクのアプリを出すのが、
なんか我々の伊藤嘉洞さんに導入してもらったサービスの一番スタートなんですよね。
それはなんかサイトコントローラーっていうものとかウェブクローラーみたいなものが後ろで動いていて、
それによって実現するという形をしてるんですけど、それ以降、伊藤嘉洞さん、
まあ以降にも同じような仕組みのものを2社ぐらいには売ってるんですけど、基本的にはもう伊藤嘉洞さん以上のものを売るってことはしていなくて、
そこから先は全く別のものを作って、全く別のものを売るってことをしているんですよね。
それはその顧客にとってネットスーパーの問題を解決するときに、我々が初めて売ったものは、繰り返しなんですけど、ネットスーパーのアプリなんですよ。
ただのアプリ、エンドユーザーが使えるアプリなんですけど、エンドユーザーが使えるアプリだけ売ってても、全く例えばネットスーパーをやってない人がやるっていうためのギャップは埋めれないし、
今ネットスーパーやってる会社が事業を国家2倍にしたいって思ったときに解かなきゃいけない問題は、
エンドユーザーのアプリだけ解ける領域って1パーとか2パーぐらいなんですよ。
残りの99パーは別の要素でできていて、別の要素のものを売らなきゃいけないっていうのは、実はもうすぐ分かっていたので、
何かその糸井岡田さんのものがリリースされた、3ヶ月だろ、5ヶ月後とかそのぐらいのタイミングには、もう会社のリソースを全部次のプロダクト作るために動かしますと。
で、次に売るのは、この次のプロダクトをメインで売りますっていうのに、結構転換してて、なんでそこが大きく変わった部分かなと。
1社目はあくまで入り口を作ったり、ネットスーパーという場所に旗を立てて事業をやっていくぞっていう、なんかのろしを上げてるみたいなところはあるんですけど、
2社目3社目以降は、実は2社目3社目、もっとその先か、それ以降については、我々はそこにおけるソリューションを当時は持っていないけど、これを作っていくんで、これ売りますよっていう、
09:12
なんかそういう形になってて、結構全然違う事業開発の仕方をしてたって感じですね。
なるほど、なるほど。それって例えば、これ他の産業でチャレンジしている企業家の方々とか、事業をやっている方々に向けてなんですけど、今振り返ったとしても、やっぱり1社目って同じように、まずはこう、のろしを上げることを大事にされますか。
それとも最初からなるべく、今と同じようなプロダクトを作れるようなチャレンジをしたいと思いますか。
いやー、わかんないですけど、再現性あんまないかなと思いつつ、なんか今あるようなものを作ろうと思ったら、
なんか正直その当時10人ぐらいだったんですけど、10人できるようなものじゃないんですよ。10人やったら、3年と4ヶ月かかりますみたいな。
そういうものになる。3年と4ヶ月で効くのかな、わかんないですけど、時間がかえないんですよ。なので、だけどその事業として成立するっていう、事業として成立するギリギリの、なんだろう、
プロダクトで、かつ顧客が欲しいと思ってくれるタイミングと、我々が提供できるタイミングが被って、それを実際に提供した時に効果が出て、
プロダクトとしても一定の品質が保てるみたいな、その本当針の穴が被ったギリギリのところを糸通すみたいなのがエントリーとか、
あの俗に言うプロダクトマーケットフィットとか、そういうものだと思っているんで、まああんま再現性はそんなないと思うんですけど、
何にせよその産業の入り口に対して、ドアを作ってエントリーしないことには、我々が何をやる会社なのかとか、
我々がその、一社じゃなくて、そのNの母体のマーケットに対して、何ができるかってことを知ってもらうことすら、入り口にさは立てないと思っているので、
そういう意味で言うと、これから何かやろうと思うのであれば、どうやったらその入り口が見つけられるかってことと、
どうやってその入り口から入った先に、こう登り方が作れるかっていうのは、すごく考えた方がいい。
考えるための実験をした方がいいだろうなというふうには思いますね。
はいはい、なんかすごく僕もアジタって中で、なんか似たように感じるところがあってですね、
あのクルーエクスペースを始めた時は、最初自前で配送をやっていたんですけれども、
まあそうすることによって各企業がこう相談をくれるようになったんですね。こういう風な配送をしたいんですけどって。
ただやっぱり自前で配送をやっていると、ただの物流会社なので、どうやってリセンスモデルをこうサステナメしていこうとか、
競合多数の違いを作っていこうというのに、課題が出てくるというところで、
我々も途中で、ある意味配送業者をアグリゲーションしていって、コントロールする側に回り、
その代わりエンターパイズ各社の人にちゃんと入っていくところにシフトしていったんですけど、
それは確かにこう、最初自前で配送をやっていたから、エンターパイズの方々からご相談いただけるようになったっていうのは、
ある意味ラスタンワイルドのDXやれそうだっていう、匂いを出せるようになったのがあるのかなと思う。
12:03
すごい今の話聞いていても、確かに直で入っていくことの難しさもあるのかなと思いました。
でもそうですね、ほとんどの成長しているサース企業って、入り口の作り方あんま変わってないと思ってて、僕は。
例えばアンドパッドって、その創業者の稲田さんが、3年間はプロダクト一切作らないで、
本当建設現場のおじちゃんの課題解決をひたすらやるっていう。それはなんかコンサルなんて綺麗なものじゃなくて、
それこそ現場に行ってホワイトボードに何か書くとか、そういうレベルのエッジウォークをしてましたみたいな。
そこでネットワークとか、あるいは何問題に困っているのかって、その真の問題に対してアプローチができましたっていう、
すごいわかりやすいストーリーがあって、あとは、なんだろう、そのCADDYとかも、もともと加藤さんが
末金税のコンサル時代に、とりあえず3年で起業しますって言ってスタートしてるけど、2年間はとりあえず末金税の売上げの大半って、
最も日本で大きい産業が製造業で、製造業の中で最も大きいコストって、
調達、減価なんですよね。その減価をどう下げるかってプロジェクトをひたすらアスタインされてて、そこで問題に気づいて、
そういう解くために作ったっていう形で、で僕らもネットスーパーって自分たちで自前で倉庫とか車持ってやってみて、
これは自分たちでこれやっても透けるせえんわとか、ネットスーパーやる上でシステム作るだけでも相当大変やみたいなもの気づいたりとか、
基本的にやっぱそのドメインに目指した時に出てくるなんか固有すぎるインサイトとか、本当のお客様の課題みたいなものをどうやってそのプロジェクトで捉えようとか、
あるいはその入り口はないで捉えて、最終的にはそのどういうプロダクトだったり事業の群によってその問題を捉えていくかってことに対する理解をその事業をやりながら深めていくっていう、
なんかその上り方みたいなのってあんまり変わってないなと思ってるんで、まあ全部針の穴、例えばね今からマッキンゼン就職して製造業のそのDXプロジェクトに
浅いされるってまあなかなか難しいと思っているみたいな再現しようと思ったら難しいんだけど、
なんかそのえっと 再現すること自体難しいんだけどどの会社も似たようなあの上り方をしてるってところは
めちゃめちゃ再現性があるっていう感じだと思うんですよね そうですね一つ一つのストーリーとしてはなかなか再現できないけれども抽象カセットにたような
進め方をするとかありそうですね。 じゃあちょっと次のご質問というところで、実際プロジェクト始まっていった後、
エンタープライズってSMEと違って結構契約を持たかったりだとか、いろいろ子社ごとの要求もされてくると思うんですが、その中で
期待値調整で契約前にこうやって話したけどやってみて、こんなことやられたら困ったなとか、そのあたりで困ったこととか、
生々しく失敗したことみたいなのってあったりされますでしょうか。 まず過去2年ぐらいは失敗しかないですみたいな感じですかね。
2020年、2021年で今年の頭ぐらいまでは、その付を返すみたいなのをひたすらプロダクトでもやってるっていう感じです。
15:04
どういう付けかっていうと基本的にやっぱりその当然契約もするし交渉もするんだけど、
我々スタートアップで交渉力が低い状態で何を我々が差し出すかっていうと
もう任せてくださいと。あなたたちのやりたいことは私たちが作るんですよ。大丈夫ですよと言うんですよね。
なんで期待調整が往々にして曖昧でオーラか。 なんで言ってる。ああなるほどそういう要求があるのかと。
その要求も例えば n=1から聞くのと n=15から聞くのって意味が全然違うんですけど、
初期であればあるほど初めの顧客って私たちにとっての100%なんですよね。そうですね。
これが3社になって、3社から同じことを言われたらみんな同じこと言ってるってなるんですよね。逆に3社のうち1社だけが言っても、1社だって言うと
33%だから、市場の33%で勘違いするんですよね。
なので、そうすると何が起きるかというと、さっきの曖昧でオーラかな期待調整によって要は過剰に我々が
期待値を提示しちゃうっていう。 それは機能的な側面もそうだし、非機能的な側面もそうで、いろんなところに対して
まあその錯覚資産じゃないですけど、だいぶ背伸びして私たちでできますってことを言ってしまう。
それが後々超巨大なプレッシャーとか不採になるんですよね。どういう不採とかプレッシャーになるかというと、僕らが一番苦しいのは
いついつまでにデリバリーしますって約束しちゃったこと。
特にさっきの一つ目の売り物、顧客だけのアプリってどこから2021年にいわゆる店舗のお客様、店舗のスタッフの方が使う
ピッキングパッキングっていう、なんかそういう店舗オペレーションのためのアプリケーションを作りました。
デリバリーの方が使う積み荷を管理してルーティングをするためのアプリケーションを作りました。
その他に商品マスターとか在庫マスター、要はどこのお店に何の商品がいつ何円で何個置いてるかっていう
在庫を推論するっていう、これはもう膨大に難しいプロジェクトがあるんですけど、これも作りましたと。
で、あとはポイントとか決済システムとインテリアションするようなこともしました。こういったプロダクトをまとめて作って、いついつまでに提供しますっていうのを約束したんですよね。
そしたら当然なんですけど、初めそのアジャイルの開発をやっていると分かると思うんですけど、見積もりって初めであればあるほど不確実なんですよね。
そうですよね。アジャイルのいいところって何かっていうと、早く開発できることじゃなくて、開発のプロセスが進みつれて見積もりの精度が上がるので、正しい期待値調整ができるというのはアジャイルの本質だというふうに僕は思ってるんですけど、
当時はそういうことも完全に頭から抜けていて、いついつまでに何々をデリバリーしますと約束しました。
18:06
で、会社の中で期日が近づいて、これどうやっても無理だろうっていうのを、いや無理だけどちょっと間に合わせようみたいな形で、なんとかデリバリーしました。
デリバリーするとQCDってあるんですよね。クオリティとコストとデリバリー。コストは自社が飲み込みますと。
デリバリーはなんとか間に合わせます。であると何が犠牲になるかというと品質が犠牲になります。
品質が犠牲になったプロダクトが顧客の元に届いて、それをもとにオペレーションがされたり、お客様の体験が作られるので、何が起きるかというとクレームとかサービス停止とか、あるいは障害みたいな、そういったものを引き起こしてしまうっていう。
まあ起こるべくして起こるんですけど、こういったものが提供直後に起きて、さらに1店舗でそれを提供した後に起きるんだったらいいんですけど、
ネットスーパーって100店舗とか200店舗とかでやるんですよ。店舗を広げていくほどトラフィック増えて障害の数もやたら増えていくっていうので、
社内なんかずっと障害対応してるみたいな、そういう形になってしまったっていうのが、プロダクト開発上は一番の問題でしたね。
今振り返るとどう対応しますか?それは。 今振り返るとですね、これは完全に期待値調整なんで事業開発の問題だったんですね。
プロダクトを作るとかのフェーズの前に、プロダクトってそういう不確実性がそもそもあって作る時には、
ちょっと待ってくださいね、子供が歌ってて。 大丈夫ですよ。
プロダクトって、そもそもそういう不確実性が始めるほど大きくてっていう、アジャイの考え方とか、
その不確実性が大きかったりする中で、どういうふうにQCDでマネジメントできるのかという、その考え方とか方法のみたいなものを、
顧客と一緒に考えるみたいな時間をちゃんと取れてなくて、ある時は我々が契約取りたいかとか、
その顧客の問題に答えたいかっていうので、どうしても背伸びしてしまうっていうのが先に来ちゃったので、そこの期待調整を
うまくはじめにマネジメントするっていうのをやるかなと思うんですけど、これ1週目は絶対無理だと
思います。 僕が生まれ変わって、じゃあもう一度同じような事業をやりますってなったとしても、
全く同じように背伸びすると思うんですよね。 そうしないと事業作れないって思っちゃう。
やっぱりバランスが足りないと成立しないですもんね、事業自体が。 そうなんですよ。
なので、これ結構難しい問題だと思ってて、事業を成立させないと、そもそも会社が成立しないっていう
トレードオフにある中、その後ろの工程で起きてくる品質とか障害とか、あるいはプロダクト開発の問題を
始めか知ってたとしても、どのぐらい何を犠牲にできるかってなると、そもそも契約取れなかったら0か1の問題なんで、
21:05
事業はそもそも始まらないんですよね。始まらなかったり成立しない。 後ろの問題は始まってさえいれば、品質が1なのか100なのかっていう問題にはできるっていうので、
これはちょっと悩ましいし、あまりこれを聞いている方で、あいつ品質犠牲にする奴なんだって思われたく全くないんですけど、
もうそんなことないんですけど、なんか本当に究極の選択として事業をやらないってことを選ぶか、それとも事業がやった時に
いろんな困難を引き受けることを選ぶかってなると、100%僕は事業をスタートすることを選ぶかなっていうふうに思いますね。
ありがとうございます。 では、最後のお質問したいなと思うんですけども、いろんなクライアントさんとプロジェクトを一緒にやっていく中で、
うまくサクセスできたなっていうクライアントさんだったりとか、うまくDXできたなっていうものと、ちょっとやっている中で今後のことはわかんないですけど、現状だと
そうでもないな、うまくいってられてないなっていうところ、各社さんによって成功の度合いってノーターあると思うんですけど、
そこってどういうクライアントさんとだったらうまくいきやすかったとか、どういう社内体制、どういうチームで望めるとうまくいった、うまくいかなかったってところのナレッジをシェアしていただけますでしょうか。
今多分キーワードの中にDXって入ったと思ってて、DXってデジタルトランスフォーメーションで、僕はデジタルどうでもいいと思ってて、トランスフォーメーションの方がずっと大事で、
日本語にすると変革とかですよね。変革って、この失われた30年間とかって、要は日本の範囲は何ですかって問われたら、産業変革ができなかったことっていう、
その一個の一周に落ちると思ってるんですよ。 じゃあ30年間変革できませんでしたっていう、中にはできている会社もいらっしゃると思うんですけど、
ほとんどの会社は変革できなかったところに、今から変革をやろうとしてるんですよねっていう。変革って何かっていうと、基本的には根本的な構造を変えることだと思っていて、
それを既存の事業とか既存のオペレーションとかに一切の痛みをない形でやるのって、僕は無理だと思って、本当バリバリのイノベーターズジレンマみたいなものなので、
その痛みだったり、例えばその痛みって何かっていうと、従業員が過去やったことないような知識とかナレッジとか
ノウハウを身につけないといけない、教育コストがかかるとか、あるいはその教育についてこれなきゃいけない、みたいな、例えばそういう痛みがあったり、あるいは
先行投資をして、ちゃんとこの事業についてのラーニングを深めるっていう、反作をするっていう痛みがあったりとか、いろんな痛みがあるんですけど、
その痛みを引き受けてもそれをやりたいと思えるかどうかってところが、単純な一つの分水型だと思っていて、
それが最後何に現れるかというと、やっぱ経営者が、例えばネットスーパーで事業を通じてどこまでこの会社をどういう風にしていきたいのかっていう絵が描けているかとか、
そのためのメッセージを社内に向けて発信できているかとか、そのようなひきるがえって我々に対してもそういう期待値を持っているかどうかってところが、
24:06
なんか一個大きい分水型だと思っていますね。ネットスーパーをやるってこと自体は、別に簡単なんですよ。
簡単なんだけど、その事業の構造、ポートフォリオを変えますとか、その中で新しいポートフォリオであるネットスーパーっていう事業を、
今後10年、20年、会社のコアにしていくんだっていう、なんかそういう意思があるかどうかっていうのは、僕らすごく必ず重要な点として確認するようにしています。
はいはいはい。
ありがとうございます。社内のチームとしてはこういう風な体制だったらうまくいったけど、こういうところだと結構厳しかったみたいなのがあったりされます。
社内の体制ですか。はい。 こちら側の体制はあんまり、例えば顧客がトランスフォームできるかどうかには、
そんなに関係ないんじゃないかなと思いつつ、社内の体制で絶えず足りないんですよ。 事業が成長する限り。
常に何かが足りないんですよ。 企業とかってそういうもんじゃないですか。何もないとから始めるので絶えず足りないっていう。
で、なんか進めば進むほど、例えば要求の質が変わったり、要求を持っている人が増えたりっていう形で、その上は広がっていって、
だけど社内ができることのケイパビリティって基本的には人員の増加によってしか上がらなくて、人員の増加って採用活動やるぞ
AOって言ってからどう頑張ったって半年間は何も出ないんですよ、結果が。 で、まあやっと回り始めて、本当毎日1人増えました。
毎月1人増えましたとか、3人増えましたとか、そういうものじゃないですか。 なんてこと絶対に事業の伸びるスピード、例えばそのPMFした後であればあるほど
事業が伸びる。事業で顧客からいただく要求のサイズよりも、我々ができることのサイズっていうのは
相対的に見るともっとちっちゃくて、ギャップは広がり続けるっていうのが基本的には起きることだと思っていて。
でも経営者とか企業家とか創業者の役割って、このギャップがあることを処理とした時に、私たちはどう振る舞うかってことを決める。
例えば何かを捨てることかもしれないし、何かをあえて、何かにすごく特化することかもしれないし、
なんらかの意思決定が必要なんですけど、そこでスタンスを取るっていうのが、我々の経営者とか創業者の仕事で、スタンスを取ったら、
ある種、捨てたものについては目をつむりがいなくて、
なんだろう、
捨てたもの、投資しなかったものっていうのは絶対成果も積み取れないんですよね。 それを会社として受け入れるみたいなことの方が、大事かなという感じはしますね。
ありがとうございます。そしたら次のテーマとして、プロダクト開発というところに移っていきたいと思います。
27:01
先ほども一部開発の話ありましたけども、Staylerはプラットフォームとして提供している中で、我々SIRじゃないので、
個社ごとのカスタマーサクセスに向け合う開発をしていく中でも、自社の資産となるような開発をしていかなきゃいけないと。
このトレードオフ、どういうふうに開発優先度をつけていっているのでしょうかというところで、お聞きしてもよろしいでしょうか。
はい、そうですね。これはなんか結構情報としても公開してたりするんですけど、根本的な考え方は、やっぱりその個社が成功しないと、我々も成功しないっていう形になっているんですよね。
売上に対して連動費で7%をいただくっていう事業モデルをすごい大事にしているので、
例えばA社とB社がいて全然違うことを言ってたとしても、全然違うことに対して対応した方がいいっていう判断も絶対あるんですよ。
なんだけど、根本的には全然違うことを1から15社が言ってたとして、これに対する対応できるコストと、その対応した時に得られるリターンっていうものの、このROIとかロイクみたいなものをどうやって当時合わせていくかみたいなのが、プロダクト開発でももうダイレクトに必要で、
どのその中小水準の要求に対してプロダクトを合わせていくかということに対して、なんかすごく気を払っています。
その中小水準というか、例えばこのA社はホゲホゲって言ってて、B社はフニャフニャって言ってて、C社はホニャラホニャラと言っているみたいな、なった時にこの3つの要求の中で、この3つの要求の全ては満たせないんだけど、
それぞれを何割かずつ満たすと、ちゃんと全員の最もクリティカルな問題というか、マストハブの問題に対して答えられるっていう、この中小水準を見つけるのが、
ワーシュプロダクトマネージャーだったり、テンクスはそのテンクスの中にドメインエキスパートが何名かいるので、ドメインエキスパートの仕事だったりしていますね。
それをさらに客観的にするために、例えばアナリストがそれによって得られる、例えばうちは流通学、GMVがどのぐらい成長する可能性があるかとか、
そういう試算をしたり、GMVって最終指標すぎるので、インプットメトリクス、アウトプットメトリクスって言われる、我々が何をしたら動かせる、動かせるメトリクスがインプットで、
その結果として最終弁議の結果出てくるのがアウトプットメトリクスで、これは動かせない。だからどのインプットメトリクスが動かせて、どのぐらい動かせるのか、
みたいなのを試算して共通言語を作って、中小水準を定めて、最終的にはそのユーザーストーリーにかけ起こして、仕様書を書いて、
あるいはそのシステムに紐づいたものであれば、ドメインサービスの設計書みたいなものを書いて、それをみんなでレビューして評価して作っていくみたいな、
そういった形で可能な限り、どのラインでものを作ればいいのかっていうのを目線を合わせるっていう、そういうプロセスを
30:00
しくることに結構命をかけているみたいなところがあります。 いやー相当複雑だし、ここを丁寧にやらないと、リセットつけられなくなってしまうし、そうですよね。
そうですね。なんかある種、すっごいバラバラだったんですけど、パートナーの数が10社超えてくるぞってなった時に、
このままだとちょっとヤバいかもセンサーみたいなのがビンビンと立って、僕その3ヶ月に1回ぐらい、めちゃめちゃ自分が集中して仕事をする領域を
コロコロ変えるんですよ。 今年の春から夏ぐらいですかね、
多分6、7月から8月、9月ぐらい、このぐらいの間はプロダクトマネジメントに思いっきり自分のリソースをバーンと投下してて、
そこでこのプラットフォームとしてどうやって複数の要求を吸い上げてくるかってとこと、吸い上げたものをどういう抽象水準で定義するか、
定義したものをどうやってロードマップに入れて、ロードマップに対してはどうやって管理していくかってものをトップダウンでバリッと定めて、一気に開発チームっていうか、
そのプロダクトマネジメントのチームの働き方みたいなのをそこに合わせて変えてもらうっていうことをしたんですよね。
そういうことしないと、やっぱりどうしてもカスタマイズとかが各現場で起きてて、それを見つけられなかったり、本当はそれカスタマイズじゃなくて吸い上げて抽象的にものを作ったら、
あの会社もこの会社も救えたのにみたいなのが発生しうる。 その前まではそういうのをどうやって防いだかっていうと、全部のスラックチャンネルとか全部のジラのチケットを読んで、
なんとか解消するみたいな感じだったんですけど、もう限界みたいな感じで、ロードマップの運用に一気に切り替えるっていうのをしました。
ありがとうございます。まさにそのあたりって、水準もプロダクトもプレッションも理解、一定の理解がある経営者が落とさないと、
社内で議論してもなかなか進まなそうだなと思うところなので、どこかのタイミングで経営人がこいつらに開けないタイミングが来るんだろうなってすごく思いました。
そうですね、結構パワーがいると思うんですよ。パワーがいるし、なんか一人のメンバーがボートマップでこういうことにやったほうがいいんじゃないかみたいなものを、
なんかもやもやと発言したとしても、多分それが会社の中に織り込まれていくのに時間がかかっちゃうと思うんですよね。
その織り込まれるまでに3か月か6か月かかったら、多分破裂するっていうタイミングがどっかで来ちゃうっていう風に思うので、
あるときは、なんかある種、創業者とか経営人とかが持ってる、特権的な勢いみたいなものはこういうところで使ったほうがいいかなっていう風には思っていて、
これを会社単位で使うときには、例えば人事とか組織とかそういうところでいいように使わせてもらってるのはありますね。
ありがとうございます。まさに創業者の仕事として、こういうところにコミットすべきだったなと思います。
開発に関して別の切り口でというところなんですけど、エンタープライズの会社さんってセキュリティの水準が各社ごとに規定されていたりだとか、
33:08
基盤の安定性に対しての要求水準が、SMBとは本当、桁が違うレベルで重視していたりだとかというところもあると思うんですけども、
このあたり、最近ヤマトさんのブログの中でもインシデントが発生したみたいな話もありましたが、
本当だったらこのタイミング、もっと手前でこういうことをやっていくべきだったなとかありますでしょうか。
前はね、難しいんですよ。
前は難しくて、でも、それこそあれですね、セキュリティチェックシート問題みたいな、
これコーポレートIT業界ではよくあるあるなんですけど、各社からいろんなセキュリティチェックシートが来て、それにいろんなフォーマット、
ワードだったり、魔改造したり、クセリだったりで来て、それに回答して、私たちは大丈夫ですみたいな。
その次に多分監査とかがあったりして、ない場合もあるんですけど、
監査の人が会社に来て、例えばそういうある情報を取り扱っている時には、別の部屋にサーバールームが
隔離された形でお金を持っているかチェックさせてください。何?サーバールームがないですって、みたいな話をするんですよね。
そういう、まさにさっきの事業の01を決めるみたいなところにセキュリティがなってくるケースってのは、やっぱりあるんですよね。
その時に、ありものでどうやって答えていくかっていうことも大事なんですけど、
セキュリティとか個人情報とか、それも一律でできるものじゃないんですよね。
結構長い時間かけて、会社の中でも醸成しなきゃいけないもの。場合によってはプロダクトのレイヤーでも、例えば個人情報を取り扱うようなデータベースについては、
このように管理されていて、監視されていて、監査ログが取れていて、みたいな、完全な説明責任が求められるっていう、
説明責任の完全性みたいなものが必要になってくるっていうことがあって、そういうものってやっぱり、人が欲しがる機能を何かを考えて作って壊してってしてる時に、
それをどうやって堅牢に守るかっていうのを並行して考えるとやっぱり無理なんですよね。
やっぱりなるべくしてなっちゃうかなと思ってて、僕はもうそれがディールブレイクする理由になってしまうのであれば、しょうがないっていうふうに、タイミングが悪かった。
ただし、ディールブレイクしたセキュリティの理由とかは、ちゃんと会社の中で解消できるようにしておくべきっていう、絶対ぶつかる壁だと思うんですけど、
初めからそれを解消できる形で作るには、相当な期間潜らなきゃいけないんじゃないかなっていう感じはしてます。
そうですよね、僕らもある意味経過例がいくつかある中で、最重要だとして取り扱い続けることはしばらくできないだろうなという中で、
ある意味、定期者としては一定の優先度と言いますか、割り切りを持ったベルトを持っていて、その代わりずっとラーニングし続ける姿勢と言いますか、
長くちゃんと改善をしていくってところをチームのカルチャーとして根付かせているってことなんですね。
36:02
そうですね、ただやっぱりそのリリースとか事業が始まった後に、そういう問題は明確に解消しなきゃいけないんで、
その中でも、この過去1年半ぐらいのうちの半分ぐらいは、前者のフォーカスみたいな、OKRのオブジェクティブみたいなのを定めてるんですけど、
そのナンバーワンがセキュリティとか品質っていう期間が、もうこの1年半ぐらいだと半分ぐらい。
今もそうなんですよ。今も前者のトップフォーカスは、セキュリティとか品質に関わるものを掲げていて、
CTOとか僕が直接レポーティングラインの上にいて、見てるみたいな形になってるんですよね。
そのぐらいすごく重要なものではあるが、それを5人の創業したてのスタートアップがやるべきかっていうと、まあ無理じゃないかなっていう。
じゃあ、初めからいい機能を探索して作りつつ、それをセキュリティで守るようなやり方をするにはどうしたらいいかっていうと、
それをシリアルアントレプレイナーが初めに40人雇ってやるみたいな、そういう開発だと思うんですよ。
自分たちみたいな、僕みたいな一周目にはなかなかできないやり方じゃないかなとか、
自分みたいな、誰の何を解いたらいいかっていう探索すらまだ終わってないような企業家とか、
創業者にはちょっと難しいやり方じゃないかなっていう気はしますね。
分かりました。ありがとうございます。 そしたら、ちょっと組織開発の話に移っていけたらよいかなと思ってるんですけれども、
TenX社もだいぶ人数が増えまして、もうそろそろ100人ぐらいですかね。
になってくる頃合いかなと思うんですけど、このエンタープライズの事業っていう中で、いわゆるスタートアップで何人の壁みたいなのを感じた瞬間だったりだとか、
それは社内の人数なのか、回しているプロジェクトの数なのかわからないんですけど、どういうところで組織拡大のとこでボトネックの解消が必要になりましたでしょうか。
人数で明確にやっぱ30人は違えなとか、50人違うなとか、100人違うなって思ったことは全然ないんですよ、実は。
なんですけど、やっぱり人数が増えたり事業のフェーズが進むと、必要になる組織とか体制とかってやっぱりまるで違って、
それに対して完全な先手を打って動くって稀なと思うんですよね。 稀なので、要は事業的に求められる組織のあり方と、
そのAzizの組織の状態にギャップが出て、ギャップが出ると、要はそれ、疲労とか不平不満とか、
なんかそういう強いフィードバックになって出てくるので、これが何とか壁かってみんな感じるっていう、なんかそういう構造なんじゃないかなと思うんですけど、
僕らはなんか壁だなって感じるっていうよりは、起きるべく問題が組織の中でも起きるべくして起きてるなって、
普通に認識するのが何回かあったっていう感じでしたね。
39:04
具体的ななんか、どういうフェーズで、どういうとか、体制変更と必要になったみたいなことはありましたか?
そうですね、なんか1個目はやっぱりプロジェクトが1つじゃなくなった時とか、
簡単に見切れる量じゃなくなった時に、
Azizの組織とのハリエーションが起きたなっていうふうに思っていて、どういうことかっていうと、パートナーの契約がポポポンって舞い込んだんですよね。
同時に、5、6社ぐらいのパートナーに対してサービス提供とリリースと、またそのサクセスをしていかなきゃいけない
ことになりました。我々の持っていた組織の形態って、非常に個人の自立性を尊重するといえば聞こえはいいですけど、
簡単に言うと、どんな仕事が来ても基本的にそのフェイシングしている人のオーナーシップで何とか解消してもらおうとか、その人が解消できないものは
クイックに隣の人に話を聞いたり、ZoomというかGoogle Meetして相談していいっていう、そういうやり方で過去、
その1、2社の時はプロジェクトずっと進行してたんですよね。そこから急にスケールしてプロジェクトの数が見切れる量じゃなくなると、何が起きるかっていうと、
リソースが取り合いになるんですよ。 すごい簡単に言うと、リソースの取り合いが起きますと。
で、みんないい人なんですよ。みんないい人なんで、ここを手伝ってくださいって言われたら、みんな手伝いますって言うんですよ。
それを放っておくと何が起きるかっていうと、1人当たりアサインされているプロジェクトは13個とかによって
全く集中できないっていう。 で、1日の中がその13個のやりとり、会議体とかコミュニケーションで全部が埋まっちゃうっていう。
そういうのが要は組織っていうものを構築する前に事業が作られていくと起きること。
プロジェクトの数が単純に膨れ上がっていくと、それに対応する組織の形がないと、規律を持ったプロジェクトの
イシューに対する対応ができなくなっていくっていう。そういうことが起きていて、
基本的にはこれが段階的にずっと起きているっていう感じだと思っています。
例えば作らなきゃいけないプロダクトが1個だったら、もう8人がそれ頑張っていればいいじゃんっていう感じですけど、
これを5つを20人でやってくださいってなったら、誰がどれやるんだよってアサインされてなかったら、
はっきり言っても何も管理もできないし、おそらくプロジェクトってうまく進まないと思うんですよ。
誰かのオーナーシップがあって、あるいは何らかの組織にオーナーシップが紐づけられていて、その組織に人が紐づけられていて、
それもとに規律を持ってプロジェクトが進むって体制があったり、あるいはそのプロジェクトとプロジェクトの間のインターフェースとして、
42:00
どういう形でやり取りを進むのかって定められていたりとか、そういう組織の構造があることによって、
その複雑なプロジェクトを組織っていう体で吸収することができるようになるっていう、その準備が追いついてないとパレーションが起きるって形なので、
2021年、2022年って2回ぐらい組織に対する手当てみたいなのは大きいことを会社の中でやってるんですけど、
それはいずれもこの事業上複雑になったり、あるいはプロジェクトの数が大きくなっていくっていうのに対応したその組織、
組織も同等の複雑性とか、あるいはその多様性みたいな組織を作らなきゃいけなくて、
そこの事業と組織が完全に連動した形になってるかどうかっていうところがすごい大事だなっていうふうに思ってますし、
連動してないと事業側のスループットって著しく起こってるっていう、そういう認識でしたね。
ありがとうございます。それに関連したところのお話なんですけども、組織の中のこの組織図的なものを考えていくときに、
TENXさんが提供しているものはホールプロラフトじゃないですか、それをプロジェクト型でやっていくのか、機能型でやっていくのか、
私たちも直近書いてられたようなマトリックス型でやっていくのかもね、というところって、おそらくお話ししていた通り、事業のページによって書いていくべきものなのかなと思ってるんですけども、
具体的にどういうページがどういう組織の形に合っているのかって、青本さんのお考えをお聞きすることできますでしょうか。
なんか組織の形って事業が決まると、事業のコアが何かってのが決まると、ほとんど自然と描写されるんじゃないかなっていうふうに思って、
何を大事にしたいのっていうので、ほとんど終了みたいな感じ。例えばTENXってStellaっていうのを15社のパートナーさんに提供しますみたいなプロジェクトで、
プロジェクトはいくらでも断片化していいと、要は各社ごとに好きなだけカスタマイズしていい代わりに、とにかく一社一社のGMEを無限に伸ばしてほしいっていう仮にそういう事業だったとしたら、
僕はどういう組織に対応するかというと、15個の事業部を作って、その15個の事業部にエンジニアもPMも事業開発の人も、いろんな人を個別の事業部にそれぞれで個別にアサインして、
それで終了だと思うんですよ。それを上の事業責任者に基本的にレポートしてもらって、事業責任者がポートフリーマネジメントする。
もうそれで以上の、すごい簡単なツリー型の構造で事業部、あるいは顧客に紐づいた部だけで完結するような組織を作って終了になると思っていて、
これSIRって基本的にこういう構造なんですよね。 プロジェクトマネージャーが立ってて、プロジェクトに必要な人が全部バコッと箱に対してアサインされていて、
だけど我々はそうじゃないと。我々はプラットフォームを作っていて、さっきの適切な中小水準でプロダクトも作るし、
45:08
プロダクトに落ちないけど、我々が提供するようなサービスっていうのもトグし、みたいな形で、
顧客とは切り離されたところで、ある一定の水準を持った、なのかサービスを形成していくってところが、事業のもう一つのコアです。
そのコアを使いながら顧客、パートナーとか、交流さんの問題だったり、その先にいるお客様だったり、スタッフさんの問題に答えていくんだっていうことを、
なんか順序を決めてるんですよね。そうすると、であると、どういった組織の形態が必要なのかっていうのが、
やっぱり、マトリックスじゃないと、どうやっても成立させられないよねとかが、ある種わかってきて、
マトリックスしかないんじゃないかなっていう、ほぼ決め打ちから、それをどうやって成立させるかとか、そういう形で考えていくっていう、
そんな流れでしたね。なので、やっぱりその事業として一番大事なコアは何なのかっていうところが、最初にあって、
捨てられるものを捨てられないものを大事に育てるためには、どういう事業の、あ、事業じゃない、組織の、
複雑性というか、機構図を作ったり、インタラクション、コミュニケーションのあり方を考えていくかっていう、そういう順序かなというふうに思います。
ありがとうございます。マトリックス組織ってやっぱり、僕目線だと難易度高そうだなというふうには見えていてですね、
ある意味、先ほどお話ししてくれたような、プロジェクトで分ける方が、何でしょう、いろんな会社がチャレンジしたことで、
組織の形としてもナレーションが変わっているのかなと思うんですけど、マトリックス組織を作っていく上で、どういった、例えば他の会社を参考にしたとか、
何から学んだみたいなことがあったりするんですかね。1個目はずっと言ってるのはトヨタなんですよね。
トヨタはその歴史的にマトリックス組織を運用してきた会社で、数少ないですけど、文献とかも出されていて、昔から言ってたんですけど、
トヨタの考え方っていうのは、個人的にはすごい良いなって思ってたんですよね。 トヨタは、例えばプリウスとか、カローラとか、そういうラインで縦の事業組織がいて、
プロダクトマネージャー、主査って言うんですけど、彼が事業責任者なんです。 事業責任者には、いわゆるトヨタの車をどうやって組み立てて開発するかっていう知識も必要だし、
マーケティングの知識、どういうCMっていう知識も必要だし、各ディーラーでどういう販売の仕方をしていって、どのエリアで何をやったらいいかっていうことも分かるっていう、
なんかそういう知識も必要なので、一通りの部を歩いて、20年経ったとか30年経った、ピカピカの超エースのベテランが主査になるっていう。
その主査のもとに事業組織と、あとは横でさっきのプラットフォーム、トヨタのプラットフォームって、車体の下のところですね、プラットフォームとか、あるいはその車体の組み立てとか、なんかそういう技能を持った横軸の機能チームがいて、
そこから派遣で人を取ってくるっていう、なんかそういうプラットフォームの形態になってて、ある種その技術とか、あるいはトヨタってそのプロセス、
48:04
トヨタ式生産方式とか、トヨタ式開発方式とかってあるんですけど、そういうプロセスをちゃんとチームを区切って研いでいくっていう、
ことをやるためにそういう組織形態になったんだっていうのが、なんか書いてあって、それを読んだ時に、それなんか10Xにすごく当てはまりそうだなっていう風に思いがかかってるのが一つなので、
一番まずトヨタですね。あとはここにも登場してもらっていた福島さんとかは、
対外的にマトリックス組織ですって公表してて、記事とかも出されてた、なんか対談かなとかもやられたと思うんですけど、
なんかその内容についてヒアリングさせてもらったりとか、また昔そのソニーの創業者のもって秘書やられてた方とかに、
ソニーの組織ってどうだったんですかみたいな話とか聞いたり、なんかマトリックス組織に限らず、こういろんな組織で事業をどうやって作っていくかみたいなのを
ヒアリングして自分の中に溜めていって、まあやっぱ結果的にじゃあマトリックスでやった方がいいなっていう風に思ったって感じですね。
最後なんか決めてみたいなのがあって、マトリックス組織って組織の好転が異常に多いんですよ。
例えば普通の会社となんかプロダクト本部みたいなのがあって、プロダクトアニメント部、エンジニアリング部、品質管理部みたいなのがあって、
あとは下にこう蚊がぶら下がってみたいな、シンプルな縦型の組織で、基本的には縦のコミュニケーションラインというか、縦の接点だけ作っておけば、
あとは横は公式な接点ではなくて、まあ仕事でプロジェクトが組織された時だけ絡むみたいな、それが普通の接点なんですけど、
マトリックスってもうマトリックスの名前の通り縦と横を交差させてるんで、いろんな職種とかいろんな組織の人が
オフィシャルに接点を持たなきゃいけないんですよね。っていうのがすごく難しいので、すごく簡単に言うと運用負荷がめちゃめちゃ高いですと。
ミーティングの設計とか、ミーティングの運用とか、なんかそういうもののレベルを上げるためにはどうやったってコーポレートの投資って必要で、
で、TENXの中で、こう内側を見た時に、TENXって、多分そのマトリックス組織で行こうかなって考えてる時にも、
多分ね15%ぐらいがコーポレートで、コーポレートがピカピカに優秀なんですよね。本当に能力が高くて、コーポレートITもそうだし、
うちらとコーポレートOPSっていう人たちもそうだし、あるいは経営企画も、今は3名いるんですけど、コーポレートスターテージって、
彼らもどうやって、例えば会議台の設計とか、会議1本あたりのコストはいくらかとか、そういう細かいところまで見積もったりするんですけど、
なんかそのコーポレートがオールコーポレートになって、その組織運用に対してめちゃめちゃいいアセットを作ったり、なんかその運用をサポートできるっていうのが多分大前提であって、
51:00
なんかそこのコーポレートの基盤が、メンバーがすごい強いっていうのが、TenXやっても大丈夫だなって思えた背景かなと思います。
ありがとうございます。そしたら、今回事業開発、プロダクト開発、機械製造、3つのテーマのお話をお伺いしてきましたが、このあたりから徐々に参加者の方々からのご質問をいただきながら、
回答に移れればなと思っております。 先に、事前に質問をいただいているところから展開できればと思うんですけれども、
これ、僕もあるあるかなと思っているのは、まずカルチャーについてのところですね。
ビジネスデブとソフトウェア開発の文化をどう融合させていますかというところなんですけれども、我々も、そいつかXコンサル賞者の方々とかと、エンターパイズ、一緒に採用し合い取りすることが増えてきている中で、
例えば、使うツールが違うじゃないかとか、ビジネス、スタブリッシュに対しての考え方が全然違うじゃないかというところで、
どういうふうに、これまでのキャリアで違うカルチャーの中で生きてきた人間を融合して一つの組織にしているのかというところをお伺いしてもよろしいでしょうか。
どうしようですかね。そもそも、そういうコーパレーションはあんまり感じたことがなくて、
元を辿ると、一人目の事業開発者って誰かと言ったら僕なんですよね。一人目のプロダクトマネージャーって誰かと言ったら僕なんですよね。
なので、すごい簡単に言うと、僕が横断しているっていう。僕と一緒に商談に出た事業開発のメンバーとかは、
顧客からの問いとかに対して、自分がどういうアングルで回答を返すのかっていうのを聞いている、見ているわけなんですよ。
それに対する対応も、ある種ドキュメンテーションをして、ちゃんと汎用的に使えるようにしてとか、
プロダクト開発が当たり前にやられるようなものを、事業開発に持ち込みながら、始め作ってきたっていうところがあって、
それとカルチャーの横断みたいなのが、始めから自然にできてて、そこに乗っかってもらっているので、比較的ハレーションなく今まで来れているのかな、
っていう感じはしてますね。なので、例えばプロダクトで機能を作る時も、そもそも経済制度どのくらいあるのとか、
経済性も計算してないのに優先度が決められないよね、みたいな。そういう議論は元からあるし、
僕は事業の経済面もすごい気にするから、なんだけど逆に、顧客との接点の中で、
例えば、何々な機能はないんですか?みたいに言われた時に、大事なのは体験ですと。我々は体験をこうやって考えてます。
体験をこうやって考えた時に、機能という側面で見ると、確かに今おっしゃったものはないかもしれないけど、
こういった形で体験として保管されてますよね、みたいな回答をするとか、
両者に大事なものが欠落しないような形で持ち込まれているっていうのは、もしかしたらあるのかもしれない。
それがそのまま分解になって、今は別に特殊な仕組みとかを敷いているわけではない気がするんですけど、
54:07
維持できているとか、また普段から事業開発のメンバーとプロダクトとかエンジニアのメンバーって一緒に仕事してるんですよね。
マトリックス組織なので、縦の中でクロスしたところで一緒に仕事してるんですよね。
その中でお互いにコミュニケーションして問題を自助的に解消するっていうのができているんじゃないかなっていうのは、今はありますかね。
ありがとうございます。確かに天気さんってすごい、ある意味ヤノンさんの思想が強く発信されてるなと思いますし、
それが言語化されて組織全体で認知されてそうなので、そういうところがすごい、ある意味価値観の吸い合わせがしやすくなっているところかなと思いました。
じゃあ、ちょっといただいている質問も見ていきたいなと思うんですけど、これどうですかね、天気さんこれどれ答えたいとかありますか。いくつか来てます。
どれでもいけると思います。全部いけるかな。全部紹介できるんじゃないかな。
僕が気になるところから全般にというところで、これ先日アマチュアの募集されたと思うんですが、天気さんの役割もどういう変化される予定なのでしょうか。
そうですね、なんかTENX組織図があって、それも公開されてると思うんですけど、事業側の責任者に一応CEOっていうのをつけて、その下に本部が2つぶら下がってますと、
あとは機能側の本部っていうのがあって、そこにプロダクトの本部長とかCTOとか、あとはワーって言ってコーポレート本部があって、なんかそういう形の中で、
基本的にその矢本の今の役割が3つあると思ってるんですよね。1つは代表取締役という、代表であるという取締役界の長ですっていうのが1つと、
もう1つが執行の長であるCEOっていう、エグゼキュートする立場のトップですっていう、この2つと、プラス最後が創業者ですっていう、
創業者がいるかいないか、会社を見た時に一番大きい違いが生まれるポイントかなと思うんですけど、創業者ですっていう、3つあったとして、
ある種初期であればあるほど、エグゼキューターであるCEOの役割って全部なんですよね。全部で、組織を作っていくっていうのはちょっとずつ切り出していくっていうことになるんですよ。
最後に切り出せるのが、僕の中ではプロダクトと事業で、事業の最終責任を切り出せるといいなっていうので、ポジションを開けてCEOを募集していたっていう形になります。
それが預けられたら何をしたいかというと、僕は創業者の役割に自分をもっと集中させたいと思っていて、何かというと、その大きい変局というか変化点を作っているのが、
やっぱ創業者にしかできない仕事で、わかりやすいのが、スマートHRにおけるNストックを立ち上げた三宅さんとかすごくわかりやすい。
57:08
スマートHRを作って育てたっていうのもあるんだけど、スマートHRの既存の事業の延長では生まれない、飛び散るんだけど、いつかは帰ってくるし、
そうすると、創業初期に生んだ事業よりも大きくなるかもしれない事業を、また裸一貫にチャレンジできるって、ああいう立ち上げ方って創業者の仕事だと思うんですよね。
創業者がいないとなかなかできない仕事だと思っていて、そういった非連続な変局点を作っているところに自分を集中させたいなと思っていたんですけど、
直近はですね、このCOOのポジションで実は閉じていて、当面はやっぱり自分が兼任した方がいいなって判断をし直して、最近は実はそこが閉じているっていう感じになっています。
なるほど、面白いですね。まさにスタートアップ、創業者がいることが一つ強みだと思うので、特に大本さんはその辺りがオリジナルな認識があると思うので、
一緒にやっていったらと思います。他のところでいくと、どれにしましょうかね。1社目の作成の話のテーマは2つあるので、どっちかいこうかなと思うんですけども、
合わせてにしましょうか。1社目事業が立ち上がる中でも、2社目、3社目と同期を増やしデイカーブを作っていく必要があると思いますということで、どのような要件を満たした段階で積極的にセールスを仕掛けられたのでしょうか。
あと関連した質問として、1社目と2社目、3社目で異なったんでしょうか。プロラフトは異なったので、背景としてあるのかなというところがあり、これを合わせてお答えいただけますでしょうか。
そうですね。2つ目の方からいくと、イシューが異なりました。イシュー自体は群として存在していて、各社によって優先度が変わると思うんですよね。
すごくわかりやすく言うと、1社目に導入した時に解いたイシューというのは、既存のネットスーパーのUXをもっとよくしたいという、
そういった、しかもそのUXも競技のUXで、デジタル上のお客様の接点に閉じたUXをよくしたいというのが、1社目で解いていたイシューですけど、
2社目以降で解いてきたイシューというのは、より広義、例えばお客様に届く、お客様が買える商品がたくさんあるとか、品質がいいとか、
欲しい時に注文ができて受け取りができるとか、そういった広義の意味でのUXのようなネットスーパーをゼロから立ち上げられる、もしくはリプレイスできる、
そういったものにリプレイスできるというイシューを解くというのが、2社目、3社目以降で解いていたイシューなので、そうなるとプロダクトが全然違う。
1社目の方は、デジタルの顧客体験のところだけ売っていればいい、それ以上の深い理解はそこまで実はそんなに必要ないんですけど、
2社目、3社目以降でやろうとすると、そもそも市場がどうなっているとか、市場の中で何が問題でとか、
1:00:05
その中でN=1のお客様は何が問題で、そういうところにちゃんと解像度を持った上で、必要な、今日の会話の中でも出てきた、
いろんなプロダクトの群を作って、導入、提供していく必要があるという形で、結構、このイシューの激しすぎるジャンプアップが、
1社目以降、2社目、3社目以降はあったなという風に言えます。
1個目の回答ですね。2つ目の、どんな要素を満たした段階積極的にセールスを仕掛けたかというところなんですけど、
これ2021年だから、去年ぐらい、去年というか今年の何月、4月ぐらいまで、僕らセールス活動というか、営業活動みたいなの一切してないんですよ。
これはなんか、10Xが素晴らしいタイミングで、一人、今だとチーフコミュニケーションズオフィサーという形で、中澤っていう人間を入れてるんですけど、
彼女が入ってくれたことで、我々結構PRによってレバレッジをかけるということができたんですよね。
1社目のリリースを出すときに、結構大きくプレスリリースを打てて、それがちゃんと業界の奥まで届いて、膨大な量のインバウンドを得るということが起きました。
基本的にインバウンドがあって、1社やってインバウンド来て、2社目出してインバウンド来て、3社目やってインバウンド来て、
あるいは2社目とか3社目からリファラルで別の顧客を紹介されてっていう形で、僕らが事業開発とか営業組織を作る前に、勝手に顧客が僕らのことを知って、
僕らのお問い合わせホームから、しかも今もそうなんですけど、めちゃめちゃちんけないLPなんですよ。
本当に3日で作りましたみたいなLPなんですけど、そこからお問い合わせをしていただいて、
Stellaどうなってるんですかとか、Stellaを入れたら私たちと何が解決できるんですかっていうのをいただいて、
それを丁寧に会話をしていったっていう形なので、実は営業活動みたいなのは全然してなくて、
僕らがこういう問題解きたいと思ってるんだとか、今後こういうことをやっていくんだっていうプレスリリースが、そのまま飛距離長く、
顧客というかパートナーまで届いたっていうのが実態でしたね。
はい、ありがとうございます。まさに顧客の深い点を解いてるからこそ、それだけのインバウンドなのかなと思うので、
素晴らしい、スタートしたお手本のような最初の立ち上がり方でありますね。
そうですね。
僕らもそれこそエンタープライズの事例をもっとPR打っていきたいなっていうのはあるんですが、
言えること言えないことも結構いろいろあったりするので、エンタープライズのPR難しいなと思うところもあったりします。
他のところでいきますと、月額の固定費プランスで売上げの連動というところでKPRを持っていることで、
1:03:04
多分、クライアント企業と10Xのインセンティブがあるというところは非常に重視されているしそうなのかなというふうに理解しているんですけれども、
例えば、ここの請求の支払いフローとかって売上金額によってかかってくるコストが変わるので、
どういうふうに予算をとっているのかとか、クライアントの契約に関してのハードルとかってありませんかという事業開発面でもおすすめです。
どういうことだろう。
固定の予算を確保できないってこと?
例えば、今月は100万円だけど来月は200万円ですみたいなそういうのが結構エンターバイス予算枠を毎月いくらとかで敷いていく会社が多そうなので、
どういうふうにその話か、あとはそれがボトルネックになったりしませんかという話かなと思います。
そうですね、これはすごく大事な点なので、僕らがどうやっているかというと、5年分の事業計画を書くんですよ。
事業計画がまず合意するんですよ。10x にかかるコストも踏まえた、例えば初年度の事業計画とか、
2年目、3年目、4年目、5年目とかの事業計画を書いて、その時に10x のコストってどこにかかってきて、トップラインはどうなって、ボトムはどうなってみたいなのを書いて、これを合意するんですよ。
なので、根本的には今月どうなって、翌月どうなってっていうのも、織り込まれた事業計画っていうのをちゃんと引いて、
そのもとに議論をしたり共通の認識をしたり、あるいはこの事業計画自体を契約書のアペンディックスにつけて契約を撒いて、向こうも倫理を問うるんですよ。
なので基本的にはその形で年額の予算っていうのをちゃんと枠として確保してもらって、
その中からお支払いしていただくっていうような形に、向こうの中としてはなってるんじゃないかなというふうに思います。
そこって、ある意味新規事業をリリース前から事業計画を引くみたいな扱いになるんですけど、
やる側としての怖さと言いますか、もちろん想像以上に伸びたら全然それはお互いハッピーであるなと思いますし、
そこに似たない時の、ある意味クレームになるんじゃないかとか、期待値どう強いってところって課題はないんでしょうか。
全然外すことはあります。やってないものはわかんないってことは全然あるんですけど、だから合意っていうのが必要だと思ってて、
事業計画ってシナリオとかどうしたいとか、なんかそういうものがあって、そのためにはどのくらいコミットしなきゃいけないっていうのがある種込められていくんですよね。
TENXはその事業計画を引いた段階で、ここまで行くための何々が必要で、そのためにTENXがこのぐらいのことをやりますっていうのをちゃんと約束して、それを果たすってことをするんですよね。
その上で事業が伸びないのって要因は2つだと思ってて、1つはパートナーさんがちゃんとコミットしてないケース。
もう1つは市場が追いついてないケースっていう、外部要因によるもの。そのどっちかと思っていて、
1:06:04
TENXがやることをやった上で、その計画に対して到達してないっていう場合については、事業計画のベースで合意をしてるけど、約束っていうのはちゃんと果たしていて、
TENXがやってくれてますって形になるので、その点で言うとそんなに怖くないというか、
急に「お前らの言ってたのと全然ちゃうやんけ」みたいにひっくり返されるようなことはないように、非常にうちの慎重なコミュニケーションとか、
契約上の文言のやりとりっていうのはしてます。 ありがとうございます。ある意味TENXがコミットするラインは、それをちゃんとアラインできている状態で進めているということですね。
そうですね。何に不確実性があるのかとか、このリスクはどっちが取ってるのかとか、そういうコミュニケーションもすごく多いので、
ミスコミュニケーションがないようにするっていうのが、事業計画を作る一番の目的であって、ある種予算がどう変わっていくかっていうのを見積もるっていうのは、
その中の一つのうち数でしかないので、大事なのは、何をどう見積もって、リスクとかリターンとか約束ごとを合意していくかってことなので、
その点については、今のところはそういったプラクティスで、割とできてるんじゃないかなっていう感じです。
ありがとうございます。僕らも配送事業の立ち上げとかスケールって結構、神経事業開発をまたぐことも多いので、
この辺は自分らがやった方が今後もめにくくなりそうだなっていうところは、しっかりと感じました。
間違いないです。
質問は最後のあたりにしていこうかなと思うんですが、パートナー開拓をして、そこからプロラフトプラットフォームを作っていくっていうところが、これまで重要なポイントだと思うんですが、
今後に関していくと、よりカスタマーアクセスあったりとか、運用、グロースみたいなところが重要だと思います。
今の現状の課題はどういったところにありますでしょうか。
そうですね、これさっきの話にすごくひも付くんですけど、自分たちだけでレバーを引き切ることができないっていうのが、この事業の一番の難しさなんですよね。
例えばなんですけど、お客様が少ないですってなった時に、わかった、じゃあユーザー獲得をするための施策を打とうってなって、
じゃあ僕らがはい、GOみたいにできないんですよね。
ある種パートナーとの合意があってとか、あるいはどういう観点をケアしながら、お客様に対して、潜在的なお客様に対してコミュニケーションしなきゃいけないかとか、
あくまで向こうの看板でネットスーパーってものをやってるがゆえに、向こうが大事にしてることとか、向こうの意向、報酬みたいなものをしっかりとコミュニケーションして、その上でそのレバーを引くっていう。
レバーの中にも、じゃあわかりましたと合意ができたので、10Xが引いときますねってできるものもあれば、10Xがここまでやるので、ここから先はパートナーさんにやってもらえないと、そもそも僕らできないですっていうものもあったりして、
そういうレバーを引き切るための、グリップを我々だけじゃなくてパートナーさんと一緒に握ってるってところがすごく難しいところだし、課題だなっていうふうに思ってます。
1:09:09
じゃあこれどう解消していくかというと、要はそこをいかにスムーズにしていけるかっていう、そこに尽きるんですよね。
パートナーとやってる事業の中でパートナーをなくすってことができないので、いかにそのパートナーさんと早く進めるような、例えば直近トライしてることとしては、契約の直後の段階から、
事業を始めた後、こういう形で推移して、この辺でもう穴がにはまると思うので、ここに対しては事前にこういった施策を打っておきましょうみたいなものを、サービスリリースする6ヶ月くらい前から合意をして、
こういう条件があったら、このレバーを我々に引かせてくださいっていうのを預けておいてもらうとか、この条件を満たしたら、我々ここまでやるので、
パートナーさんはもうここはレバー引いちゃってくださいっていうのを合意しておくとか、事前に予見、見積もり、過去の経験を生かして、それを合意しておくってことを、現状を進めよっていう形でやってます。
素晴らしい、なるほど、ここまでやれるようなものです。
そうなんですよ。なのでこれは本当事業開発っていうものの賜物だなと思っていて、
我々が自由で、自分たちの小銭と自分たちの時間を使って自由に何でもいいって言うのだったら、ここまでプレッシャーとか予見性とか計画性みたいなのって多分身につかなかったと思うんですよ。
僕らがこういう事業やってるからこそ、いかに予見したり、いかに合意したり、いかに計画したり、その中で自分たちが自由に動ける範囲をどれだけ広げていって、
それによって速さを生み出すかっていう、そういう考えとか方法論が会社の中に作られていっているのは、
本当今の事業開発のメンバーとか、本部長、部長やってる面々の創意工夫のおかげだなというふうに思います。
ありがとうございます。ちなみになんですけど、MOTさん、10Xってラストマイル配送で困っているところってあったりしませんか?
ラストマイル配送で困っていることはいくつかあって、僕は地方にネットスーパーを開設することが多いんですけど、
やっぱりベンダーさんを選ぶ、探すってところで、やっぱりそんなに候補が多くないケースがあったり、調整が難しいケースがあったりして困ることっていうのは、
今、生々しく1個あります。もう1個は、やっぱりどうやってその1配達辺りのコストを下げていくかっていうのは、
どうやったってやっぱり発生するんですよね。そこがないと、ボトムで利益を生み出すっていうのは難しい事業なので、
いかにその配達効率とか、件あたりのコストっていうのを、想像しえないレベルまで下げていけるかって、
どこへのチャレンジっていうのはやっぱりあって、それいろんなプレイヤーがいろんな形でやってると思うんですけど、
例えば、性能運輸さんもラストマイルやっているベンダーさん、子会社っていっぱい持ってて、
スパイダーデリバリーっていう、例えば、ヨドバシの荷物とネットスーパーの荷物と、
1:12:00
想像の荷物を全部一緒の車に入れて、近い省金でバーって巻くみたいな、それによって、
番あたりのコストを下げますみたいなチャレンジされてたりとか、いろんな各社が各立場でやってるんですけど、
ネットスーパーとか、我々みたいな立場になった時に、どうやってスケールメリットみたいなものを作りながら、
こいつ化していくかっていうのは1個大きいテーマなので、そのあたりですかね、
ラストマイルで困っていることはそのあたりかなと思います。
ありがとうございます。
(音楽)
