1. LayerX NOW!
  2. #77 社内1on1を大公開!CEO fu..

CEO fukkyyと社内のマネージャーがナナメで1on1を実施する「ななメンター」企画がスタートです。限りなくZoom音源を生々しくお届けします。1回目の今回は、事業開発マネージャー諏訪との1on1をお聴きいただきます。社内の様子が伝われば嬉しいです。

※音声の中で登場する「BOX」という単語は、企業の電子・スキャン書類の電帳法対応や書類管理をラクにするサービス「バクラク電子帳簿保存」のことを指す社内用語です。

▼LayerX Now!とは・・・ LayerXの日常を伝えるPodcast。 CTOの松本とHRのmaasaが(ほぼ)交代でホストを務め、社員がLayerXで働く様子を赤裸々にお伝えします

▼ メディア情報

LayerX採用情報:https://jobs.layerx.co.jp/ LayerX エンジニアブログ:https://tech.layerx.co.jp/ LayerX 公式note:https://note.layerx.co.jp/ CEO福島のnote:https://note.com/fukkyy

00:01
今回のLayerX NOW!は、特別編として、CEO Fukushimaと社内のマネージャーが
ナナメで1on1を実施する企画、ナナメンターの様子をお届けします。
限りなく、Zoom音源を生々しくお届けできればと思っております。
LayerXのCEOと事業開発マネージャー、SUWANO1on1を聞いていただくことで、
社内の様子が伝われば嬉しいです。では、スタートです。
お疲れさまでーす。
すいません、遅れました。
いいえ。
今日ちょっと話したかったことが、メインは1個目かなと思ってます。
はいはい。
ちょうど今、LayerX NOW!自体で、事業開発部の中での事業開発グループっていうのを
組織化していこうっていう形で、今まで1人2人だったんですけど、
ちょうど今月から4人とかになったんですね。
はいはい。
改めて組織のミッションだったりとか、位置付けっていうのを
しっかり考えていきたいなっていうページになっていて、
今回ちょっとお題として挙げさせてもらったのが、
コンポーネントスタートアップの事業開発がプロジェクトを伸ばす上で
意識すべきポイントみたいなところをテーマとして。
難しいな。
難しいなって思ってますと。
事業開発って結構フワッとしてるじゃないですか。
要は新しいPMFを。
そうですそうです。
今やってることをこの26日を書いているんですけど、
新規プロダクトでもある程度領域とかMVPが確定した新規プロダクトを
立ち上げましょうっていうプロジェクト。
今の発行みたいな感じですかね。
はいはいはい。
プロダクトのMVPができてそれを伸ばしていくみたいなのを、
もちろんお客さんを増やすっていう事業サイドの話と、
プロダクトを作っていくっていう話、
フィードバックを回すって話と、
あと各セクション、マーケットとかISとか、
そういったところからいわゆるうちでいうGTMチームって呼んでたものですね。
そんな感じで組成して引いていくみたいなこと。
これBOXも同じような感じだったんですけど、
BOXだったりとか発行でこういうことをやってるっていうのが
一番メインの仕事。
はいはいはい。
一方で今今後から始めようとしているのが、
既存のプロダクト、いわゆる一度GTMしましたみたいなプロダクトが
次の領域を広げていくため。
例で挙げているのが、
BOXとかも次の領域みたいな感じで今やってるんですけど、
経費生産とか、
例えば多店舗系の告知生産をなくしていこうみたいな話とか、
その辺りにいかにGTMできるかみたいなものを
既存プロダクトでも今プロジェクトを立ち上げてやろうとしてたりしてますと。
そもそもの新規プロダクトと既存プロダクトのGTMみたいな。
こうやってますと。
一方で稲沢さんみたいな動き方。
横断的にインボイス生産GTMみたいな感じで、
前者的に事業的にインパクトがあるようなものを
03:02
GTMという形で組織を組んで浸透させていって、
間接的に全プロダクトにいい影響を与えるとか。
トレンドとしてPRとしてもワードを取っていくとか、
そういった動き方もしているという感じになっておりますので、
この3つが今やっている事業開発グループのメンバーがやっている、
オーナーがやっている仕事みたいな感じですと。
今後については今新規プロダクト、
どんどんいろいろ別領域とかも立ち上げるみたいな話が出てますけど、
そういったところのリサーチのところから、
プロダクト部と連携してやっていく。
いわゆる1個目の新規プロダクトのMVPができた状態から渡されるというよりも、
それを作りに行くとこからチームとして入っていくという事を、
バイネメントの沼津さんが今やっているんですけど、
沼津さんと一緒にタッグ組んで、
同然引きを出すので事業開発に。
ちなみに経営会議で大激論しました。
それを今は本当に沼津さんがやっているという感じなんですけど、
そこに事業開発もしっかりと最初から入って、
やっていこうという動きをやっていこうという感じになります。
そうですね。
こんな仕事がうちの事業開発の仕事でしたという感じになったりはするんですけど、
こういう仕事をしていく上で、
とはいえ課題感というか感じているところでいうと、
やっぱり担当領域とか、担当プロダクトを伸ばすみたいな意識はすごい強いかなと思っているんですけど、
コンパウンドとしてとかっていうのが、
結果的にコンパウンドみたいな感じでホールプロダクトで売れるようになったとか、
セルが生まれたとかっていうのはあるんですけど、
あとは営業戦略の中でそれをやっていくっていうのはあるんですけど、
意図的に。
意図的にというか考え方として、
うちみたいな会社の事業開発って、
もうちょっと意識すべき点があるんじゃないかなみたいな感じで、
このお題を見させていただいたという。
はいはい。
そうですね。何から話そうかな。
何か大前提としてこの整理でそんなに違和感はなくて、
これ以外に考えているところみたいな。
何かコンパウンドスタンダップなんていう議論はあるんですけど、
僕は何かシンプルにレゴのブロックみたいなものだと思っていて、
相性がいいプロダクトを組み合わせていくと、
統合的な良い体験ができて、
それがビジネス的にもインパクトがあるよっていうのは、
ビジネス的インパクトのところを紐解くと、
何か結構シンプルで複数プロダクトが売れることで、
何かCPAが下がります、ないしはCBRが上がりますみたいな、
取り漏れがなくなることと、
あと強力なクロスセルというか、
1回入ってしまえば、
ちゃんと良さを分かってもらえれば、
ちゃんと体験価値を広げていくことができるみたいな、
ところが何か結局は全てなのか、
マルチプロダクトと違うところはそういうところなのかなって、
06:01
マルチプロダクトって多分コンパウンドスタートアップよりも
ちょっと広い概念で、
要は何でもいいから、
1回ディストリビューションチャンネルを押さえちゃって、
そしたら売れるじゃんみたいな、
よりももうちょっとパズルを組み立てていくようなところが違くて、
例えばボックスだと製造業とか、
今まで取れてなかったじゃないですか、
だからCPAが下がったというかCVRが上がったというか、
そもそも取れてないものが取れるようになったのかって
言い方はいろいろあるんですけど、
請求書とか形成書とかカードでぶつかっていっても、
多分撃沈してた場所がそもそも取れるようになったし、
しかもクロステルがそこから生まれ始めているっていうのは、
事業開発チームとしてすごい考えるべきことというか、
結局僕らの今、成長がどっちかというとクロステル、
クロステルからも大きいけど、
基本的に僕らってある程度のサイズ感いくまでは、
新規売上げみたいなところが成長のほとんどを作る。
前提で考えるとやっぱり新しいユーザー設定でどう取れるんだろうとか、
今まで取り漏れてたんだけどこの切り口だったら入り込めるみたいな、
それを探し続けるっていうのは一つ大きなミッションなのかなっていう。
基本的にやってることって、今やっているところって切り口は違えど、
今まで入れなかったところにどうやったら入り込むのみたいな、
既存プロダクトを生かすの、それとも新しいプロダクトで入り込むの、
それとも新しい軸?
法改正とかトレンドチェンジを使って入っていくのみたいなことを考えているんで、
複数プロダクトがあることによる軸の広さとか、
作れる軸の広さとか、対応できるユースケースの広さとか、
もしくは単品プロダクトで見たときでも、
実はこの領域って今まで入れなかったけど、
これあると入れるぜみたいな。
それは、それを意図して新規プロダクトの意思決定をするっていう話なのか、
プロダクトに対して、もちろん新しいマーケットを狙っていくみたいな考え方も、
どちらもあるじゃないですか。
両方ですよね。結局、でも何を狙うかは決めといた方が良くて、
例えばカード管理プロダクトみたいなので新規ユーザーは絶対連れてこれない。
けど、あれがあることによって、
例えばエンタープライズの会社に経費生産が売りやすくなるとかあるんで、
あれはレゴブロックの中でも何かを連れてくる終着点のブロックというよりは、
中間のブロックなんだけど大事みたいなものもあれば、
09:03
ボックスとかは最初はどっちかというと爆落請求書の機能の一部ですみたいなものが、
いや、そもそもこれ切り出したらこれだけでユーザーを連れてくれるプロダクトになるんじゃないみたいな
発想のものもあるし、狙いはいくつあっていいんだけど、
少なくとも最初作るときにこれって何狙いなんだっけっていうのと、
新規プロダクトチームとか事業開発チームで持っている試作のポートフォリオの中で、
新規の試作少ないねとか、
例えばインボイス制度終わったときに新規流入をどうするみたいな課題とかってあるじゃないですか。
今そこに対して重点的に新規流入向けの試作を増やしていくみたいな感じで
ポートフォリオを動かしているかどうか観察した方がいいんじゃないかなっていう。
全体として晴れてるかみたいな、全体としていい加減になっているかみたいな。
チーム一個一個とかプロジェクト一個一個は狙いが明確な方がいいんだけど、
全体として会社のリスクを潰す方に狙ってるかみたいな。
少なくとも誰か一人は見張っておくべき。
何かクロスセル寄りすぎてないとか、既存ユーザー向けのプロダクト増えすぎてないとか、
逆に新規に寄りすぎてない、既存の体験大丈夫なみたいな。
これとか見張っておく方がいいかなっていう。
なるほどなるほど。
確かに今仕立てたポートフォリオを見た時に、しっかりとその中での意味があるのかっていう話。
だから尖ってないのはやらない方がいいと思うんだよね。
何かいずれにせよ、これ目的何なの?みたいな。
なんとなく予防あるんでみたいな。
ものだったらそれって何か意図せず、既存向けのMRRを上げるための狙いなのねみたいなものだったら、
むしろそれよりいいものあるんじゃない?みたいな議論ができるんですけど、
何か狙いがないものって。
けど何かいっぱい要望あるし、何となくいいですよねみたいなものは何かやめた方がいいかなって思います。
逆にMRRとかで一切評価しない。
あれはぶっちゃけ、新規ユーザーに刺さるか分からないし、
分からないけどビジョンで進めるんだみたいな。
こう体験あるべきなんだみたいなのは、むしろ絶対ポートフォリオとして一個持っておいた方がいいしとか。
非論理的なんだけど、絶対この体験あるべきじゃんみたいなものがなさすぎる会社も結構やばいかなと思ってて。
ある種事業的な観点で見るとチャレンジ枠みたいな。
チャレンジ枠みたいな。
こいつが10回やって跳ねたらすごいことになるみたいな。
12:06
複数の位置づけで、ユーザー取ってくるんだっけとか、既存ユーザー向けなんだっけとか、
固いものというか、顧客の要望とかニーズから上がってくる確実に外さないものなんだっけなのか。
ちょっと無視してるんだけど、
でも自分たちが持っているプロフェッショナリズムのビジョンから出てくるあるべき体験で、
顧客にも刺さりうるみたいな、そこのリスクを取りに行ってるのかとか。
狙いを。
大事なんて、要望とか可視化されやすい。
この機能あったら売れるんですとか、この機能があったらこのターゲットに入り込めるんですみたいなの、
ほっといても出てくるんで。
チームとしてはビジョンドリブンなもの、ちゃんと一部の上から貼れてるんだっけとか、
逆に短期的なMRRには繋がらないんだけど、新しい顧客を送り起こしてくれるような、
ルールチェンジするようなプロダクトとか設定とかGTMのプロジェクトとか、
ちゃんと動いてるんだっけみたいなところは見とかないと、
だいたい先ボソリする会社になるなっていう。
事業開発のミッションってそこなんじゃないかなって、
両極端なものをちゃんとやるみたいな。
ある意味すごい成果も測りづらいし、選んだものによっては空振っちゃうんだけど、
チームとして成果が出せていれば。
VOXとかもそうじゃないですか、
太陽のタイミングみたいなのだったけど、結構苦しい期間が長くて。
でも今、正直辛かったと思うんですよ。
けどそこで頑張り続けた結果、今ナビが来ててみたいな。
でも1年前の段階の数字だけで判断しちゃったら、
リソース減らそっかとか、何なら撤退しようかみたいな議論でもなりかねなかったと思うんですけど、
そこを多分、もさとかぬわしとかで意図的に止めてたけど、
ここは絶対1人張り続けようとか、エンジニア1人張り続けようみたいに意思決定をしたから今があるみたいな。
そういうのをちゃんとチームでできるようになる。
ほかのスタートアップって、意思決定ゲームにおける何の意思決定が求められるかって、
結局1つのプロダクトだと、そのプロダクトの中の一種だけを考えてればOKみたいな。
けど複数やるってことは当たり前だけど、戦力分散化させるんで、
既存プロダクトまだ怪しいんだけど、ちょっともう2人だけ残って、
あと全員こっちに突っ込むの、あんまり理論はないけどみたいな、そこが一番むずいと思うんですよね。
15:01
バウンドスタートアップにおける事業開発みたいな話でいくと、
それやるみたいな。
けどそれやるべきなのか、いやもうちょっとバランスとってやらないべきかみたいなところを判断していく。
なるほど、確かにそうですね。
僕の視点というか考え方では、やっぱり既存のプロダクトにどう良い影響を与えるかの考えがやっぱり強かったですよね。
それもめちゃくちゃ大事だったけど、考えすぎるとね。
タムを広げるというか、新しい顧客層を広げるとか、シリーズとして広げるとかっていう観点と、
既存のプロダクトにもクロスセルできるとか、既存のお客さんにも価値提供できるとかっていう、
結構極端な軸かなところを持ってて、
これを両方考えるんですけど、
どうしてもクロスセル側とか既存プロダクトに価値、ホールプロダクト、ホールプロダクトっていう方が強いんで、
そっちに寄りがちなプロダクトを出すとか、進め方をするとかに寄っちゃうなっていうところはあったんで、
今ちょっとお話聞いて、それも大事だけどっていう話ですね。
なんか議論として覚えてるね、ボックスやるぞみたいになった時に、
ボックスを果たして打った時にクロスセル繋がるんだっけみたいなところでブレーキがかかったっていうのを覚えていて、
それよりも形成さんとかの方がクロスセルも、
要は実証されてるし、そっちの方が優先度高いんじゃないのみたいな話もあったけど、
結果今クロスセルできてるじゃないですか。
そうですね、できてます。
だからコンパウンドスタートアップなるものの定義の良さって、
クロスセルなんかできるからと、言い方は悪いけど、それだけ相性のいいものを選んでる。
できるから、だからそこは考えずに、むしろなんかよりタムを広げるというか、
より新しい層にさせるプロダクトって何だろうっていうのを研ぎ澄まして考えても、
結果後からついてくるみたいなのが、
いい話なのか、逆にこれが単なるマルチプロダクトですみたいな、
コラボレーションツールみたいなのを売ってれば、
こういうの売ってるし、BPOも売ってるし、
みたいなものってなんか、それぞれ売れたかもしれないけど、
それ結局全体的に何につながるのみたいなところって多分保証されないのが多分難しさで、
マルチプロダクトのコンパウンドの場合は多分、
そんな円みたいな飛び散りのものは減っていくんだけど、
その代わりそれぞれが頑張ったときに、
頑張ったなりの高い成果が保証されてるっていうのが突破さえできれば、
18:03
その後はそんなに考えてなくても実はいけるんじゃないみたいなところが良さだろうかなと。
これがなんちゃってコンパウンドのただのマルチプロダクトだと、
全然クロステリできないから、
あれ、結局別の会社が5個、6個できてるみたいな感じだぞみたいになっちゃう。
だけど、
って感じなのかなと。
1機能を新規プロダクトと呼ぶみたいな考え方になっちゃいますよね。
アンチパターンですけど。
それコンパウンドでもなんでもないぞみたいな。
プロダクトとしては独立、
領域としては独立してるんだけど、プロダクトは繋がってるっていうのかな、
みたいなものじゃないですか。
今までやってきてるものって全部。
それより多分今プロダクトロードマップに乗ってるものも変わらなくて、
だから多分そこを頑張ればなんとかなるよねみたいなところは、
逆にそんなに心配しなくていいのかな。
逆に、すごいそれって新しいユーザーとか、
新しい体験を作れてるのみたいなところが問われ続けるのかなっていう。
そうですね。
VOXのときもまさにそうでしたね。
結局、クロスセルは違う領域に行ってるからこそ、
クロスセルの可能性はほぼないだろうみたいな。
空気があったんですよ、GTMチームの中で。
実際言ってたよね。
それがブレーキ要素にもなってたけど、
僕はそんなことあると思ってたけど、やっぱり嘘だったよね。
それはでも、例えばGTMチームとかのクローターのキックオフとかでは、
VOXでもちょうど伸び切るっていう先には、
コールプロダクトの価値が提供できるってことは常に言い続けてたんですよ。
わかんないけどというか、確証はなかったんですけど。
でも結局やっぱりちゃんと価値が提供できるプロダクトができると、
その体験がいいなと思ってもらえて広がっていくみたいな。
ある種業務的につながっていなくても、
お客さんの別の課題を、例えばVOXやってるけど、
ただの書類保管みたいな感じで使ってもらって、
法対応っていう感じで使ってもらったんですけど、
実は経費生産的なところに課題があって、経費生産が最近売れてるとか、
そういうのが直接的に業務フロー的にも、
プロダクト的にもあまりつながっていなくても、
いい体験が提供できれば普通に売れていって、
結局つながっていくみたいな。
みたいな現象が今起きてる。
今回証明できたのが大きいですね。
だからある意味、もっと狙ってやれるというか、
確かに僕もこの主張を支持はしてたけど、
確信はなくて、本当に売れるのかなと思いながら、
でも多分大丈夫だろうみたいな感じだったのが、
21:01
今回で多分みんなそれを認識したと思うんで、
今後はもっと狙ってやれると思うんですよ。
もうちょっと、
いわゆるこれからもうちょっと外れたところをやって、
やっぱクロスセルできなかったねとか出てくると思うんですけど、
そういうのを繰り返すことで事業開発チームとして、
コンパウンドとして外しすぎちゃいけないのはここで、
逆にここまでは実は外しちゃってもよくて、
それよりも新しいお客様に刺さるかとか、
新しい新規の層に刺さるかみたいなところを優先した方がいいとか、
そこら辺の線引きができるようになると。
それはもう事業開発チームのリーダーたちの感覚でもいいから、
数字化されてなくてもいいから。
まあ、それが信じて推進できるメンバーがいるので、
確証がなくても。
推進した先には多分そうなりますよっていうのが、
今回そういうのも結構大きいかなっていうところ。
インボイス制度とかも早くできたのも、
延長法で知ってたんで、
延長法の対応のときって直前まで全然ニーズなくなって、
直前にニーズ爆発したじゃんみたいなのを知ってたんで、
今回も絶対同じこと起こるだろうっていうので、
それでやっぱりやれたんで、
知ってるって大事だなっていう。
なるほど。
要望の数だけ満ちたら延長法のインボイス制度もやらないほうがいいし、
boxもクロスセルできないかもしれないからやらないほうがいいってなってたかもしれないけど、
それって全部間違ってたというか。
そういう知見を雑でもいいから、
ためていけるといいのかもしれないですね。
忘れるとか、
言われてもわからない系の話、
本当?みたいな感じになっちゃうんで。
各プロジェクトが伸びた理由を、
しっかり時系列でトピックでまとめておくとか、
結果的にこうだったよねとか、
そういう資産をためていくと成功確率は上がりそうな感じがします。
改めて重要開発で本当に価値があるのは、
その資産がある中で、
新しい顧客接点とか、新しい顧客のワークフローに入れて価値を出すことみたいなことは、
結局事業開発部に期待していることだし、
その中で手段は問わずよみたいな感じで、
この3つと今後やっていくのがこの4つか。
難しいよね。
大激論しまして。激論って喧嘩したわけじゃない。
24:02
前向きな話として、
本当に何をやるのが正しいのかみたいな、
結構本質的な議論を。
ちょっと話変わっちゃうんですけど、
ビジネスモデルとしての課長って、
どう捉えますかっていう話があって、
例えば、バクラクシリーズって、
カード以外ほぼサースモデルで伸ばして生きてますと。
カードは全く違うモデルなので、
別のビジネスモデルですという感じなんですけど、
サースはもうある程度生み出せる会社になっているのかな、
という感覚を僕は持っていて、
ただ一方でこのサースだけのモデルを課長していくと、
やっぱり限界はあるかな、伸ばし方にも限界があるし、
もちろん人材という意味でも単調になってくるし、
みたいな話があると思っていますと。
そこに対して別のビジネスモデルで、
スキャンとかも一部ありましたけど、
ああいうところをしっかりベッドしていくみたいな、
ビジネスモデル視点でベッドしていく必要があるか、
みたいなところって、
ありますか、考えとかって。
これはあるけど難しいっていうのが多いので、
カードとかまさにそれを狙ってるんですけど、
なかなか結構ハレーションとかもあるじゃないですか。
だから見方が違うとか、
どういう営業指標を作ればいいとか、
そこでやっぱり苦戦はしてるっていう。
あがきたいなとは思います。
ここはもう割とトップがリーダーシップを取るしかないのかなとは思っている。
考えていることはみんなそんな変わらないと思うんですよ。
SR設定のシステム費用で、
SRっていうのはトランザクション費用でとか、
もうちょっと拡張していくと、
BPO的な人の費用なのかとか、
もうちょっと購買側に入っていて、
マーケットプレイス的な、
コスト削減のところで価値を出すとか、
考えていることは変わらないんだけど、
果たしてそれが組織として実行可能かっていうと、
怪しい状態が今かなっていう。
そこも何か視点としては必要な部署なのかなと思っていたりしていて。
はいはい。
もちろんさっきの話、
ポートフォリオで狙いを持って新規プロジェクトを作っていくというのは、
もちろんそうなんですけど、
それってある種、
伸ばし方としては型になっちゃうんですよね。
だから補修的な意思決定の側面もあるかなと思っていたところもあって、
いろんなビジネスモデルをしっかりと立ち上げられるとかっていう観点も、
組織的には、伝社的にも。
そういう役割のチームが一つあってもいい気がしますね。
みんながみんなそれを意識すると何もできなくなっちゃうんで、
新しいGTMを考えながら、
27:00
新しいプロダクト設定も考えながら、
ビジネスモデルを変えようってなると、
変えるものが増えすぎて、
全く別のビジネスになっちゃうじゃんみたいな感じで、
あんまり強みがいきないとか、
なんか1個変数変えて、
こことこが一緒なんだけど、
お金の取り方だけは変えるんですみたいなチーム、
あなたですよみたいな。
お金の取り方もGTMの方法も変わんないんだけど、
プロダクトとか、
ユーザーにとっての体験する時間とか場所を変えるみたいな、
それだったらボックスとかなんですけど、
じゃああなたの役割ですとか、
それも目的の1つに入れれるといいなっていう。
大きく言ったら狙いの1つって感じですもんね。
難しいのは多分、
GTMチームとかも最終的には、
うちのフィールド整理とかの組織に肩を落とすみたいな感じの、
ビジネスモデルを変えるっていうのは、
あんまり難しいと思うんだけど、
あんまり難しいと思うんだけど、
あんまり難しいと思うんだけど、
ビジネスモデルを変えるっていうのは、
本当に新しい組織を作るぐらいの必要なんで、
本当に新しい組織を作るぐらいの必要なんで、
そこぐらいかな、違いはっていう。
そこが一番大変なんだかっていう感じですからね。
ただ確かに、
事業開発部として持ってほしいミッションでありますね。
たぶん、
もうちょいトップと連携してやる話なのかなっていう。
そうですね、ちょっと、
ミッションだけで意思決定できる話でもない。
カードってたぶん、
僕が言わなきゃ進まなかったと思いますよ。
でもそれってリーダーの役割というか、
パレーションがあるけど、
未来必要なことをやるために。
今その代償を背負ってると思うんですけど、組織は。
ただ同じようなことを、
トップと連携してやるみたいなのは確かに、
あってもいいかもしれないですね。
そうですね、だから今のカードがまず、
もちろん今調子はいいと思うんですけど、
事業数字的に。
どうドカンと伸ばす、
定識をつけられるかというか。
組織的なパレーションとか目標の打ち方とか、
チームの考え方の違いをどう組織として吸収するかみたいな、
課題の方が大きいですよね。
事業自体はっていうと。
そうですね。
それこそボックスも経費生産もそうでしたけど、
やっぱりそのプロダクトが伸びる、
イコールもちろん事業も伸びるというか、
お客さんにも使ってもらうという観点の、
一番の起爆剤って既存のFSメンバーとかが、
30:02
しっかりと販売してくれてる状態で、
それが別のビジネスモデルになってくると、
またちょっと話が変わってくるというのが、
今多分直面してる。
カードはずっとその問題ありますよね。
売れてる人は売れてるけど、
提案できてない人は全然提案できてない。
提案できてない人は悪いとかそういう話じゃなくて、
会社として構造的にそういう問題を抱えてしまって、
それもフラストレーションになってるなっていう。
で、もうやってきた。
難しいですよね。
だからそういうのをゼロイチで作ったとしても、
次にその課題が絶対来るっていうのが、
新しいモデルがあるんだろうなっていうのは、
相手に想像できない。
そういうミッションを持つチームが、
あってもいいとは思いますね。
試したいですね、いろいろ。
本当にある意味CSとかでやってることも、
延長戦ではあるけど近いかなと思うんで、
違うお金の取り方をしてみようみたいな。
それは結果的に全体的にハッピーになってるというか、
そういうのもありそう。
そうですね。
事業開発としては何を意識していくかっていうところと、
どう新しいDTMとかプロダクトを作っていくかみたいなところ。
多分今お話しいただいた部分は、
今今の意識できてますね。
本当としてはっていう。
何でもそうだみたいな話かもしれないですね。
これが大事じゃない組織があるのかと思うんですけど。
悩む変数を減らせてますよね。
その代わり多分マルチプロダクトと違って、
要は出せるサービスに上限があるというか、
決めてるじゃないですか、この領域みたいな感じで。
だからその中でインパクトを出せるサービスって、
そんな数あるわけじゃないぞっていうのがあるんで、
だからビジネスモデル変えてもっと縦に入っていくと、
もっと前工程に入っていくとかが必要で、
そうなると一沢瀬組織としての運営じゃなくなるところの
難しさと、ある意味そこを超えた時の面白さみたいな話なのかなっていう。
その代わりクロスセルとかで悩まなくていいよみたいな。
確かにそうですね。
トレードオフじゃないですけど変数は何かは消せてるはずなんで。
もう一点聞いていいですか。
33:02
ボックスとかでも今起きてるんですけど、
既存プロダクトとの領域被り、領域というか、
プロダクトの価値が被り、
例えばボックス内でワークフロー作っちゃうかとか、
なんで連携できるかみたいなのが、
結構今発行とかでも、発行は多分連携するのかな。
連携するもさえ、独自でも作るみたいな話があったりする。
これは僕の考えだけで言うと、
別に独自で作ってもいいのかなと思ってたりはします。
それはお客様によってやっぱり、
ワークフローだったらワークフローという価値が必要なんですけど、
うちの爆落申請ほどのスペックはいらないと。
もっと簡易的にやりたいんだけど、
承認というところはしっかりと抑えていきたいみたいな。
やっぱりあったりする業種とかもあるんで、
そういった意味ではもちろん連携もするし、
独自でも作るみたいな、
選んでもらえるパターンになるみたいな話があるのかなって
ちょっと思ってたりはするんですね。
そこを、うちで別のプロダクトにその価値があるんだったら、
それをちゃんとつねり込もうよっていうところを重視すべき。
だったら別にそっちに重視することもできるっちゃできるんですよね。
はいはいはい。
いやー、際どいな。
ケースバイケース。
ケースバイケース。
一般論的には同じ機能を別のプロダクトに持ちたくはないですよね。
一般論的にはですけど。
ただ、うん、確かに。
なるほどなー。
そこら辺ってなんか重さとか議論するんですか?
どうあるべきみたいな。
まあでもそこに対してピンポイントで議論はあんまりしないですかね。
まずそれをした方がいいかもしれない。
そもそも論。
もうちょっとテックのことはそこまでも把握できてないんであるんですけど、
一般論は気持ち悪いなと思うけど、
気持ち悪さでユーザーの使いやすさとかをそこに入れるとそれはポイントじゃない。
なんか結構際どい仕決定な気がする。
なんかボックスだけだったらいいんだけど、
すべてのプロダクトでそうなっちゃうと、
それこそなんだっけみたいな。
なんか別の解決策もありそうだなとか、
そこら辺は確かに本質的な議論ができそうです。
分からんけど。
そうなんですよ。ちょっとそれはなんかずっと、
まあボックスで一番なんかそこは、
しやすいというかシンプルだから。
まあ確かに。
お客さんも違うからこそみたいなところで。
でも用語としては理解できるな。
36:00
なるほどね。
もうちょっと中長期で考えたときにとか。
っていうのは気になりますね。
今この瞬間は合理的なんだけど、
本当にみたいなのはちょっと、
数年先思うと怪しい気はするが、
そんなこと言ってても、
結局シェアを抑えないとその先がないんで、
やるべきことをやるがやっぱ正しい気はするなけど、
どうなんだろうちょっと、
いずれにせよ結構根幹に関わる話だから、
ちゃんとディスカッションした方がいい。
なんかそういう話があんまり上がってきた記憶がないんで、
その経会議とかでも。
経会議であんまりディスカッションできる
理由度の話じゃないかもしれないけど。
少なくとも結構重要な話な割には議論されてない気が。
また発行団体とかだともう、
申請と連携するって話になってるんで今。
一時期どっちにしようかみたいな話あったんですけど。
そっちの方が自然ではありますよね。
ただ個別でも作る必要あるよねみたいな議論は残ってるんですよね。
簡易ワークフロー的な。
簡易ワークフロー的なやつ。
VOXも同じ辿りそうだなみたいなイメージがありますね。
たびたびありましたよその議論が。
イメージ。
そもそも去年ぐらいから。
企業企業によるんでしょうね。
2列体会社の。
そこを絞るのか。
いや、絞らないのであれば、
簡易版でも作るべきっていう議論になるんだろうし。
結局VOXも言うたらかぶってるんですよ。
請求書を受けてるとか。
そうですよね。
かぶってるプロダクトだったりするんで。
どこに強みを置いて伸ばしにいったからだいぶ変わったっていうだけ。
確かに。
そう考えるとどっちもありっていうのが。
簡易ワークフローだったら。
今のワークフローって結構すごいワークフローなんだようちの。
これはもちろん軸になると思うんですけど。
本質的には。
ただ本当に簡易でつけたいぐらいだったら、
延長方面と同じようなイメージですかね。
経験者受けてる延長方面と同じようなイメージで、
あるみたいな。
そういったお客さんも勝ち取りできるみたいな。
になるんじゃないかなって今のところは想像してます。
面白いゲームですね。
こういうのはだいたいね、
ゼンカリするほうがいいんだよな。
過去の経験値は。
あんま綺麗汚いみたいなの関係なく。
今ちょうどあのボックスも検証開発みたいな位置づけ。
LLMの話で前回ちょっとしたと思うんですけど。
はい、汎用CRの。
39:00
あれはまだそれこそリリースはするとは決まってないんですけど、
動くものを作ったって感じなんですけど、
これと同じ文脈で簡易ワークフローの動くものをちょっと作ってみようかみたいな。
なるほど。
電池も今年で終わるんで、
ペーパーレスに今寄せてるんですけど、ボックスとしては。
その中で大きい波を作んなきゃいけないので、
その一つの武器としてワークフローみたいなものを
当ててみようかみたいなお客様に。
なるほど。
簡易ワークフローをちょっと動くものを作ってみようみたいな。
ロードマップの20%ぐらいが検証開発に当てていて。
なるほど。
みたいなことをやろうとしてたりしてますね。
検証ぐらいまでは問題ないけど、
その後本当にどうするか、
そのうちに決めといたほうがいい気がする。
別にどっちが正解とかじゃなく、
決めたことをやり切るというか、それに合わせ切るが正解な気がして、
中途半端を取り入れないほうがいいかなと思いましたね。
どっちなんだろうっていう。
両方やり切るみたいなインタクションもちなみにあって、
それも意外と正解であることが多いっていう。
気厚いですよね。
それがある種決まっていれば、
その前提で進めようっていう話。
そうですよね。
これだけ作っていけるんで。
決めたほうがいい系の話ですよね。
と思いましたね。
まあまあ上の意思決定なんで、
ちゃんと決めたほうがいい気は。
そうですね。
多分ボックスがここに一番最初に直面すると思うんで、
光るべきタイミングでちょっとその辺は
プロダクトチームでも話すっていう感じですかね、
全体の。
うん。
ございます。
うん。
これがアートコース。
事業開発してますね。
はい。
組織が4名になったんで、
今後から事業開発グループが。
という感じです。
ほい。
で、これは一応今回3回目なんですけど、
なんかあれですよね、クォーターで一旦やってみて、
なんか。
そうですよね。
なんか、
これとまた別で横田さんと話してる
なんか7メンタープラスみたいな。
始めるかみたいな感じ。
これはもうなんか今までみたいな
42:01
名前じゃないですけど、
結構お互いちゃんと準備してきて、
はい。
ガチの幹部規制プログラム作ろうみたいな。
うんうんうんうん。
感じでまあ、
これを終えるととりあえず
なんか経営、経営会議には参加して、
バコバコ意見を言えますみたいな状態を作るやつを
やろうみたいなのがあるんで。
なるほど。
横田さんがものすごくそこに手を挙げて、
はい。
承認されたら、
なんかまあ役員陣と、
多分メイン僕になるんですけども。
はい。
2ヶ月間カバン持ちをしてもらうみたいな。
カバン持ちではしないですけど、
まあこういう感じで。
ずっとキャンプできない。
ずっとキャンプで。
本当にテーマ決めてディスカッションするみたいな。
なんか本当に、
まあ例えばなんか、
何でもいいけど、
自分が一番凶暴と思う会社で、
上司の企業の会社を
例えば指定して、
それの決算書を読んでディスカッションしようよとか。
うんうんうんうん。
普段経営陣がやってること、
日常的にやってることを、
一度こうやるんよみたいな。
採用で一緒に水利市見て、
リクルーティングリストを作って、
実際採用しに行こうよみたいな。
一人採用できたら、
この試練はクリアですみたいな。
とかやろうかなと思ってます。
なるほど。
本当に、
まあ究極のOJTみたいな感じ。
うん。
多分本当にみんな普段やってること。
で、多分やり方を、
松浦さんクラスとか何て言うんですかね。
こう自立心あって、
学習能力もあって、
一定のビジネス実績を出してる人であれば、
やり方さえ知れば、
とか考え方の方さえ知ればできるだろう、
みたいなことがうまく、
伝えられてないんじゃないかみたいな。
うんうんうん。
のが今の、
幹部育成の課題感であるんで、
まあそれを、
ちょっと始めようかみたいな。
うんうんうん。
しかし斜めったら多分、
今回で、
残念ながら。
どうですかね。
検索する場合もあるので、
その時は声を上げてください。
わかりました。
はい、ありがとうございます。
逆にこの人と話してみたいとか、
松浦さんとやりたいとか、
松浦さん僕もリソース限られてるんで、
うんうんうん。
もうそんな持たないように、
みたいな感じにはする方針なんですけど、
一人二人はやろうと思ってるんで。
うんうんうん。
ダメになりました。
斜めったら。
なりました。
いや、なんかあんまりこう、
なんだろう。
そういう、
特に僕はなんかこう、
新しいプロダクトを立ち上げるとか、
なんかこう、
同じようなことやってる人がいないというか、
確かに。
ようもやってるんで、
そういった意味だとなんか、
別に壁打ち相手がいるわけでもない気が、
はいはいはい。
あったんで、
そういう観点ですごく、
しさを得ましたっていうか。
確かに、
一番プロダクト立ち上げやってきたの、
僕ですから。
まあ、
あの経験っていう意味では。
はいはいはい。
だからです。
確かにここら辺の意思決定って、
45:02
あんま落ちてないっすよね。
落ちてないというか、
なんか、
まあ、そりゃそうっしょみたいな話があっても、
なんか、
その通りに決めたらとんでもない結果になるよみたいな
類の話が多いなと。
うん。
本当の意味だと、
新しい、
不確実なものに対する、
正しい意思決定の仕方って、
まあ、
別に僕ができてるかどうかさておき、
なんか、
実務、
実務経験以外で、
詰めるものがないっすよね。
うーん。
あんまり、
あんまりここを理解してる人は、
いない気がする。
えー、
なんか、
うん、
まあ、
これってある種なんですけど、
まあケースバイケースなんで、
多分結構、
うん。
プロダクトとか組織の状況とかによって、
そうなんですよね。
そうなんですよね。
何より組織の状態よく、
なんでね、
多少もっちゃやっても許されるし、
なんか、
資金が全然ないんだったらもう、
いや、
もうそんなプロダクトとか作ったり暇ないから、
紙でリーに試してこいってなるし、
うーん。
なんかもう、
最初の奥役に、
あの、
しっかり、
あの、
自分たちが手を動かして、
プロダクトになってなくてもいいから、
価値提供してお金をいただくことで、
そっからプロダクト作ってこうって手法も当然あるし、
うん。
とか、
なんか、
いろんなパターンありますよね。
うーん。
まず、
LPだけ作って需要調査したらみたいなパターンもあれば、
うーん。
どれも正解だし、
どれも間違いというか、
マジでケースバイケースで。
あと、
SaaSに偏っている組織の中で、
カードを、
というか、
金融事業をやるとか、
金融に偏っている組織の中で、
金融事業をやるのはまたちょっと違うよね、
とか、
うーん。
それが当たり前の組織と、
当たり前じゃない組織で、
重心のかけ方が違ったりとか。
うん。
そうっすね。
だから、
型化されているのはあるかもしれないですけど、
型が、
型がいけない、
一番いけないかもしれないですね。
どれかを選ばなきゃいけない。
型のパターン結構無限にある。
そんな印象だったんで、
非常に、
いいお時間でした。
本当に。
多い。
まあでも、
要はユーザーを取ってくるか、
ユーザーを定着させるか、
どっちかしかないはずなんで、
そのプロダクトのタイプって。
で、
往々にして大事なのは、
ユーザーを取ってくるプロダクトなんで。
うんうん。
あんま難しく考えずに、
そこだけをフォーカスしてやりきるみたいな、
考え方もあるかなと思いました。
うん。
まあ、
あんまりそういうとき、
快適に聞こえちゃうけど、
ユーザーを取ってくれるってことは、
ユーザーが定着しやすいっていう話でもあるんで。
はい。
価値を感じやすい、
型体験を感じやすい、
やっぱ分かりやすいプロダクト。
価値提供がはっきりしてるプロダクトみたいなものが、
やっぱりユーザーも取ってくれるし、
定着もさせられるなっていう。
極めてシンプルな。
うん。
まあなんで、
狙いを結構シャープにすべきだなっていうのは、
すごい感じですね。
うん。
広く考えてるんですけど、
狙いはシャープにするというか。
48:00
そうですね。
いろんな視点の中で、
ここでこういう目的でしっかりと、
意思持って立ち上げようみたいな。
それがしっかりとポートフォリオで、
まあなんか、
うん。
ちゃんと経路が、
いろんな経路があってとか。
うん。
簡単に出してるみたいな。
やっぱり営業とかのマネージメントとちょっと違うと思うんですよね。
なんかそれ、
どっちが良い悪いじゃなくて、
うんうんうん。
まあ、
なんていうんですかね、
チーム全体で勝ちは良いみたいなのが、
事業開発で。
だからなんか、
チーム全体で平均的な成果を出そうなんじゃなくて、
一人だけハズレ値のフォームランを売ってれば、
他全員空振ってても、
うん。
事業開発チームとしては勝ちみたいな。
うんうんうん。
けど営業それだと困るじゃないですか。
うんうんうん。
もっと肩貸してよみたいな。
全員、
チームとして勝ちはまた、
まあ確かに一緒なのか、
一緒なんだけど、
勝ち方が違うって感じだから。
うんうんうん。
営業とかやっぱり、
全員がちゃんと点取らないと勝てない。
はいはい。
代わりになんか、
一人が100万点取る必要もないみたいな。
うんうんうん。
なんじゃけど、
事業開発チームはやっぱ、
やっぱ、
どこまで行ってもやっぱその、
大きな目標の中のシャープな狙いを持って、
一人一人はやってるから、
空振ることも当然あるし、
むしろ空振りの方が多いんだけど、
うんうんうん。
でもなんか、
誰か一人が満塁フォームラン売ってれば、
なんかチームとしてOKみたいな。
うんうんうん。
っていう違いが、
より大きい気がする。
もちろんね、
ぜひフォームラン売ってほしいんですけどね。
うんうんうん。
いやでもそうですね。
いや、
それが、
まあそれがでも、
売てないと、
ある一定期間で1個は売てないと、
逆に、
あれなんで、
何やってんだって感じの組織になる、
っていう側面まで、
結果が見えにくいんだよね。
なるほどね。
ここはプロセスを信じるしかないですけど、
自分は正しい、
シャープな狙いで、
この仮説にかけて、
その仮説が仮に正解だったとしたら、
自分は最大限の成果を出してるみたいな。
でも仮説が間違ってたら、
正しいことやっても、
ダメなものはダメなんで、
みたいな、
正しいことをやれてるかみたいな、
狙いに対して的確なこと、
やれたかみたいなところが、
評価対象になるのかなって。
それを10回空振ってたら、
それをお前は見る目がないね、
っていう話になるんですけど、
10回やれば、
絶対1回フォームラン売ってるんで、
はい。
正しいプロセスさえ、
やってればっていう、
っていう仕事ですね。
大変ですが、
一番経営者に近い仕事なんじゃないですかね。
あり意味でね。
はい。
ありがとうございました。
ではでは。
はい。
またお願いします。
はーい。
ありがとうございます。
失礼します。
50:42

コメント

スクロール