1. Zero Topic - ゼロトピック -
  2. #247 Salesforceから学ぶプラ..

Adobe, SalesforceなどでPdM, Tech PdMとしてご活躍され、現在はDCM Venture にてVenture Partnerを務めるKenさんをゲストに、プラットフォームマネジメントについてお伺いしました。

  • Kenさん自己紹介
  • キャリアの中で特に人生を変えたイベントを3つ
  • Salesforceのプロダクトが初めてエンプラを迎えた時に起きたこと
  • プラットフォームへのトランジション、意思決定後に会社や事業に何が起きるか。SIチームの切り出しやサードパーティ化に向けた準備の詳細
  • 技術的な意思決定における社内のパワーバランスやガバナンス(CEOとCTO,CPOの関係)
  • GoToMarketとプロダクトチームの関係
  • プラットフォームを扱うプロダクトマネージャーをどのように採用、育成、評価、組織組成していったか
  • グローバルと日本ローカルでの違いはあったか
  • 国内プロダクトの熟成や成長に向けてKenさんは何が必要だと感じているか
  • DCM Atlas
00:00
[音楽]
こんにちは、Zeltopicです。
Zeltopicは、10Xの代表である矢本が経営や日々の気づきを話すポッドキャストです。
今回は、DCM Venturesの若松健さんをお呼びして、
プラットフォームマネジメントについてお話を深くお伺いしました。
それではどうぞ。
[音楽]
健さんの簡単な自己紹介をまずはじめにお願いしてもいいですか?
DCMでベンチャーパートナーをしている健若松と申します。
他にもCPU協会の代表理事と、あとSANSANの技術顧問を務めております。
よろしくお願いいたします。
お願いします。ありがとうございます。
直近まず、DCMのベンチャーパートナーに健さんが移られたというのが、すごく大きいニュースで、
当然DCMは我々の主要な株主でもありますし、
ここを選択された背景みたいなのって、どういうところが背景だったんですか?
そうですね、やっぱりDCMが、私が興味を引かれた部分は、
このEarly StageとかSeed Stageの日本の会社に投資をしているというところが、
私たちはすごく興味を持っていまして、
やはり長年アメリカでプロダクト開発、ソフトウェア開発を行った中で、
できれば日本にナレージとかノウハウを共有できていければいいなと思っていたところで、
やはりちょうど日本のマーケットと私の持っているエクスパティー性がちょうどぴったりマッチするかなと思ったのが、
良かった点だと思います。DCMだった点になります。
今回、Seed Programを始めるということで、
たくさんの会社を、複数の会社を同時にサポートできるというのが、もう一つのやはり、引かれたところであります。
確かに健さんの知見とかナレッジがあれば、ナレッジが聞きやすいポジションを持って考えると、
すごくライトポジションな感じがしますもんね。
そうですね、ありがとうございます。
じゃあちょっとそのDCMに至るまでのキャリアを簡単に時系列で教えていただいてもいいですか?
大きくはエンジニア、そしてプロダクトをやって、今、VCやっているというような経緯になるんですけど、
最初はマクロメディアという会社でエンジニアとして入社しました。
今の時代の人たちはそんなに覚えてないかもしれないですけど、
もともとマクロメディアはDreamweaverとFlashとFireworksという3つのプロダクトがベースで伸びた会社で、
私はその中の、実はもっと古いプロダクトの、Directorというプロダクトの開発チームにいて、
そこから、もともと、そうですね、そこからOphotoというeコマースのサイト、後にKodakに買収されるんですけども、
今、日本でいうRuxellとかPrintbackとか、そういった写真をいろんなものに変えていくというところのeコマースをやった後に、
もう一回Adobeに戻って、Adobeで今度はモバイルの開発のFlashlightという当時の柄系のUIとかの部分とかを作ってたりして、
その後にPhotoshopのiOS版を作る新しいプロダクトとして、プロダクトマネージャーとして入って、
03:09
そこからプロダクトマネージャーを続けて、ずっとマルチメディアをやっていた中で、やはりそのハードウェアに少し憧れずっとあったので、
iPhoneがビデオ録画する機能がつく前の時代にあった、手持ちのビデオレコーダー、今のGoProに似たような感じの製品の
卒売のPMになって、その会社が2年で買収されて、2年でシスコが潰しちゃったんですね、そのプロダクト。
あらら。 で、そこで、そうなんですよ。初めてのリストラーになって、それでSaaSに行くことに決めて、で、セールスフォースに入社して、
2011年から約5年ちょっと、本社の方で働いた後に日本のセールスフォースで、日本にちょっとプロダクトを中心に広めていくっていう中で、
日本に引っ越して、で、セールスフォースをまた日本でも4年ほど勤めた後に、Metriという会社、スタートアップに行って、そこ約2年、それと同時にCPU協会を立ち上げて、
で、今、T-SEN Venturesに行く。結構、まあいい年なんで結構長いキャリアを踏んできました。
なるほど。でもこれ今を聞きすると一番長いのがもうダントツでそのセールスフォースの、US5年、JP4年、9年ぐらい、セールスフォースがすごく長いのかなと思ったんですけど、そんな感じですか?
そうですね、やっぱりセールスフォースは、私も入社した時は多分、まあSaaS、初めてのSaaSの会社だったし、
エンプラも中心の会社であったし、B2Bも初めてだったので、正直2年続くかなと思っていたんですけど、
これから話す、プラットフォームをベースにやっていたので、常にこうイノベーションが生まれるような形になっていたので、いろんなことを
最初2年で飽きるかなと思ったら、どんどんどんどん新しいことをやるチャンスもあったので、それで気づいたらもう9年になってたっていう感じになりますね。
すごい、すごいですね。なんか今日はまさにそこをメインで深掘りたいなと思ってるんですけど、
なんかあのキャリアの中でこの3つぐらいが自分にとって転機だったなっていう、この質問結構便利でいろんな人に聞いてたりするんですけど、
けんさんが振り返ると、なんか転機3つあげるとしたらどこでしたっていう。 いい質問ですね。まず最初に、
もともと実は大学の時、文系だったんですよ。文学と歴史を勉強してて、ソフトウェア開発とか、当時92年から6年ぐらいってあんまりそんなにソフトウェア
勉強してる人たちはいなかったんですよね。で、でも元々音楽が好きだったり、
アートも好きだし、なんかマルチメディアにはすごい、普段文学関係もあって好きだったのもあり、
大学卒業して、ひょんのことからソフトウェア会社に勤めるっていうのが一番大きな転機ではありましたね。
すごいジャンプだったんですね。 だから入社してからプログラミングを勉強するみたいな形だったんです。当時は本当にエンジニアとかいなくて、
06:07
当時だから天文学者とか、天文学を学んでた人たちとか、数学を学んでた人たちとか、その中でちょっとプログラムを作ったことがあるような人たちとかが、多くの場合もエンジニアに
転校している人たちの中でも、完全なる文系から入ったっていう形になったのが一つですね。
その次がやはり、5年、6年ぐらいエンジニアをやって、自分はそんなにエンジニアに向いてないなっていった時に、いろんな人と
ランチとかコーヒー飲んだりして相談させてもらった中で、 ちょうどプロダクトマネージャーのポジションが入ったんですよ。
当時だからテクニカルプロダクトマネジメントっていうロールがあって、そこにちょっとまあもしかしたら自分に合ってるかもしれないと思って
やらせていただくことになったのがやっぱり第二の天気で、それやることによって、ソフトウェア業界の中に残ることができる、エンジニアという違うじゃない別な形に残れるっていうのが大きかったですね。
その後やっぱり大きかったのが、あの やはりあの人生初めてのリストラックだった時に、
正直、やっぱりずっと僕マルチメディア系をやってたんですね。マルチメディア系って基本、まあイコモスもちょっとやってる中でもやっぱり基本、この経済の波にすごく影響されやすいんですよ。
なぜなら多くの場合が、やっぱり広告でビジネスがメインなんですよね、収入が。
その中で、こう1999年2008年とか、そういった大きな、今ももしかしたら入ってるかもしれないんですけど、まあ入ってはいるんですけど、そういった波が起きた時に、
結構会社の中で、今でもアメリカのソフトウェア業界のニュースを見ると、1000人切りましたとか1000ぐらい切ってて、僕はなんか運良くずっと切られずに住んでたんですよね。
だけど、その部署全部潰された時に思ったのが、なんかこのままだと、ちょっとまあ実は結婚も、春に結婚して、したすぐ2ヶ月後ぐらいにリストランだったんですけど、
ちょっとこう自分のキャリアを考え直さなきゃいけないなっていうのが大きな起点でしたね。その時に6ヶ月ほど当時のシスコは、
いただけたんですよ、時間を。それでちょっと自分探しっていう感じで、日本に1ヶ月ぐらいとあとヨーロッパを1ヶ月ぐらいちょっとこう
放浪の旅に出て、その時に、やっぱりこのサースっていうビジネス、要するにまあその経済の影響、もちろん受けはするんですけども、ちょっと違う形で受けるような
ビジネスの方をちょっと考えてみたいなっていうのと、私がメインとしていた使いやすい UI/UX が強いような
B2C の要素をB2B のソフトウェアもちょうど取り入れようとしてた時期ではあったんですよ。
セルスフォースも UI を変えなきゃいけないとか、もっとシンプルに使わなきゃいけないっていうのを考えた時に、ちょうどぴったり
09:04
セルスフォースがハマってセルスフォースに入ったっていうのがやっぱり自分の人生の3つのポイントかなと思います。
なんかやっぱりお聞きすると最後のがすごく特に大きそうというか、これまではコンテキストを
一定社会人として積み上げたものをバーンと捨てるみたいな。 そうですね、本当にシフト、本当にやっぱり
プロセスとして開発っていうのは基本的にB2BもB2Cも似てる要素は共通の要素がたくさんあったんですけど、やっぱり
完全に新しくビジネスを学ばなきゃいけないっていうのは結構大変なところでありましたね。
なるほど、ありがとうございます。じゃあその今日のメインのSaaSとかEmpl.とかセルスフォースのところについてちょっとお聞きしていきたいと思ったんですけど、
まずちょうど初めにセルスフォースに入社したタイミングのセルスフォースってどういう状態の会社だったか
例えば人数とか文化とかプロダクトの状態とか、なんか少しアウトラインを教えていただけますか。
はい、いい質問ですね。2011年の7月にセルスフォースに入社して当時7000人ぐらい社員がいました。
多いな。 当時多かったんですが今5万5千人とかいるんで、5万5千人から6万近くなっているんで、当時としてはすごい小さかったんですけれども、
やはりまず一つ目に感じたことが、やっぱりエンジニアがそれほど多くなかったんですよね。
ずっとB2Cの会社って基本エンジニアが多いじゃないですか。営業はどちらかというと、まあアドビの場合とかはバーティカルによって営業している場合が多くて、そんなに人数が多くなかったんですけど、セルスフォースに入社したらもう半分以上が営業さんであったり、
これからエンジニアの組織がすごく小さかったんですけれども、やっぱりすごく効率のいいエンジニアリングチームを持っていて、約10分の1ぐらいがエンジニアって感じでした。
会社の。ほとんどがサンフランシスコを中心に、いくつか、私が入社した時にもう倍出した会社があったので、
フランスとか、あとアメリカのプロリーダとか、カナダとかに数社オフィスがあるような形でした。そうですね、だから、僕が主に
大きなメインのプロダクトが、セルスフォースのプラットフォームの部分と、一番利益が当時大きかったのがセルスクラウド
っていう営業管理のソフトと、あとサービスクラウドが一番伸びていた製品でしたね。あとは社内でチャターっていうソーシャルなツールを作ったりとか、
そのすぐ後ぐらいにマーケティングの会社を買収したりとか、そういったのがちょうどそのもう社内ではもうそういった準備をしてたような感じの時でした。
なるほど。この時の、例えばトップのリーダーシップみたいなのは、その何千人の会社だとどう映ってたんですか?
そうですね、やっぱりもう、私が入社してからマーク・ベニオフがもうちょっとオフィスにあんまり来なくなったっていうような感じ。
12:08
だから、ミーティング一緒に私たちPM、平PMレベルで入ることがもうどんどんなくなってきて、その代わり副総理事長のパーク・ハリスが
当時、そうですね、CTOとCPOの両方をやっていたような時期でしたね。
その代わりやっぱりパーク・ハリスと結構色々と接することができる、すごくいい経験ができるチャンスの時でしたね。
なるほど。 じゃあ、ケンさんから見た時にパーク・ハリスってどんな人物だったんですか?
いやー、パーク・ハリスはすごいすごい方だったですね。やっぱり、もともと最初の接続の行動全部、
全部で書いたのもパーク・ハリスですし、私が入社した時にも16年くらい、99年から、創立からもう10年以上、
会社をずっと成長させてた中で、
やっぱりプラットフォームっていうものに目をつけて、それを会社の中で率先させて、率先して、
で、それをプラットフォームをベースに、実はプラットフォームをベースに買収がすごくうまくいくようになったんですね。
なので、その土台を作る、あとアプリケーション、
アップストアみたいな感じでアプリケーションインフラを作って、それを全部同時に出したんですよね。
なので、まずプラットフォームを出した時に、もちろん社内の別なアプリケーション、例えば私が作っていたSales Cloudも同じAPIを使いますし、
パートナーさんが例えば、Sales Force上でアプリを作って、アップストアで使うものもそのAPIを使いますし、
あとはISVとかGSIとかが使うような、パートナーさんがSIRが使うようなAPIも同じAPIを使いますし、
個人の開発者も同じAPIを使えるというものを、その時に2006年くらいに出して、それをずっと
会社の成長のベースとして作っていったっていうのがすごいところだなと思いましたね。
なるほど、ちょっと言葉の意味合いを正しく理解するために、例えばSales Cloudっていうのは製品、プロダクトですよね。
そうです。プラットフォームって呼んでいるものはどちらかというと、その下の低いレイヤーにある、例えばAPIとか、あるいはもしかしたらデータベースとか、その辺りも含まれる。
そうですね、ありがとうございます。まさにその通りで、Sales Forceのクラウドのデータベースと、そのアクセスをして作るAPIの部分を指しています。
2006年にはもうこれを要はサードパーティーの人も使える形で、仕様とかも含めて公開されていたっていうことですか?
そうです。2006年それが大きなSales Forceの転機だと思いますね。
それはなんかもう、異常というかめちゃくちゃすごいですよね。
15:04
すごいです。もともとの言われているのがやっぱり、当時、スティーブ・ジョブズにマークが相談したときに、やはりこのB2Bのアプリケーションとして、ちゃんと企業に、エンタープライズにちゃんと利用してもらうためには、やっぱり単体のアプリケーションじゃダメです。
APIがあることによって他のアプリケーションと連携をする。連携ができるし、他のアプリケーションがSales Forceのプラットフォームで作ることができるっていうのがやっぱりポイントとなる。
今のiPhoneのApp Storeと同じゲームなんですけれども、そのアイデアをいただいたのが実はスティーブ・ジョブズであったっていうのがベインで、それを実行して作ったのがパカリスっていう、やっぱりそこがキーなのかなと僕は思いますね。
なるほど。Sales Forceはでも元々は基本的にはセールスクラウドを開発で、それがいわゆるPMFというかマーケットに刺さって伸びてきた会社っていう理解であってますか?
そうですね。一応そうではあるんですけれども、やっぱりMarketVenueのビジョンとしてはCRMっていうか、もうそのデータベースを売りたかったんですよ。
元々オラクルでデータベースを売ってたっていう経緯もありますし、ただみんなにじゃあサーバーを買って、実際に存在するサーバーを買って運営しなくてもいい、
クラウドにデータベースが存在してて、なんでもできますよっていうふうに売りたかったんだけど、じゃあ何をすればいいのっていうのがお客さんの答えだったんですよね。
その中で一番シンプルいったらおかしいですけど、営業管理って基本的に会社がいて、人がいて、商談があれば成立するものなんですよね。
なのでその最もコアな部分を最初の製品として売ったっていうのが一番その経緯ではありますね。
なるほど。じゃあ元々会社の骨子としては、多分将来的にはそれをプラットフォームと呼んでいたかは別として?
そうですね。 そういった構想、アイデアみたいなものは元から持っていて、そのエントリーを探していったら、どうやら営業管理のためのセールスクラウドのようなアプリケーションであった方がお客様は理解しやすい、売れるぞ。
なんかそういう順番だったんですかね。 そうですね。僕が思うにはやはりセールスソフトって最初はTwitter、クラウドにある
クラウドを信用してない会社だと思うかったし、エンタープライズもそんなにすぐには利用しなかった場合が多かったんですけど、エンタープライズが利用することによって、
で、マークは元々オラクルでサーバー売ってた経験があったので、いずれそこに持っていきたい場所っていうのはやっぱりそのどのエンタープライズでも使えるクラウドっていうのはあったと思います。
その中でやっぱりやらなきゃいけないのが、エンタープライズをサポートするためにはまず大きく2つあると思っていて、1つがやっぱりそのカスタム、カスタム化したい。
項目を、この項目を、うちのビジネスのこの項目をやらせてほしいとか、このワークフロー、こういったデータモデルをちょっと変えてほしいとか、そういった個々の企業とかもしくは業界の、例えば保険だったらこういうデータの持ち方をしたいけど、製造業だったらこう。
18:11
っていうのがこういろいろあって、まずそのカスタム化をサポートしなきゃいけないのが1つと、あともう1つがやっぱりその連携とワークフローの部分ですね。
他のプロダクトと連携をさせて自動化したり、ワークフローを作ったりっていうのをやりたいっていうのがやっぱりエンタープライズをサポートするためのキーとなる部分ですね。
そこがやっぱりプラットフォームがないとサポートできないっていうのを、マーク・ルビーのやっぱりオラクルの経験上知ってたっていうのがポイントになると思います。
なるほど。セール操作、これは以前、個別にお話伺った時に聞いた話ですけども、やっぱりその1社目の超巨大企業が来たことで、そこにすごい舵を取る圧力になったっていうふうにおっしゃってた?
そうなんですよ。そうなんですよ。マーク・ペニオフが当時バンクアメリカっていう大きな銀行の契約を取ってきた時に、やはりその時はまだプラットフォームが存在してなかったんですよね。
だけど銀行のためにやっぱりデータモデルを買えなきゃいけなかったんですよね。それを
セール操作の中で変な意味やっちゃったんですよ。もう仕方なかったんですね。当時のオプションがなかったので、金融、それも大きくいわばバンクアメリカように作ったものがあって、
それがやっぱりそれをやったことによっていろんな他のお客様に障害が起きてしまったんですよね。
それをやった後にこのままじゃダメだってなって、API Firstのプラットフォームを作りましょうっていうのが大きな規定になりました。
ちなみにそのバンクアメリカのコードは今でもセール操作のコードベースの中に入ってます。
へー、なんかよくある三木谷さんの書いた楽天のコードがまだ楽天にあるみたいなのに近い話ですね。
全く一緒です。もう切り離せられないっていう。
これタイミングとしてはこれが何年くらいなんですかね?
そうですね、まあ2006年にそれが起こったので、僕は日射する前だからはっきり言うのは2ってわからないですけど、
多分おそらく上場してから2005年とか4年とかそのぐらいのタイミングなんじゃないかなと思います。
で、そこから舵を切ってプラットフォーム化に一気に移っていったってことですよね。
これプラットフォーム化をやっていくときに起きるジレンマ、これまさに僕らも今迎えているジレンマだなと思っていて、
なんかデリバリー、要は顧客の求めるもののデリバリーを一時的に速くするには、そういったものを無視してカスタマイズしてとにかくデリバリーした方が、
例えばARRに繋がるとか、NRRが上がるとか、そういうことは起きやすいんですけど、中長期で見るとものすごいプロダクトとかプラットフォームに対しては
不採用をたくさん残してしまうというジレンマがあると思っていて、この時、セールスフォースはどういう意思決定したんですかね?
そうですね、なのでまさにその
21:02
大きく、セールスフォースの場合、もう一つ脅威となったのが、やはり今セールスフォースがクラウドで営業管理を始めたことによって、
なるほど、みんなクラウドで他の類似したビジネスをやっていけば、自分たちでプラットフォームを作っていけば、そこに
そこに競合に負けてしまうというところがあるという脅威が一つあったんですね。それを阻止するために、
もうセールスフォースというプラットフォームがあるので、その中で作ってくださいというのが一つの考え方の一つでした。
もう一つはやはり、顧客の導入するのにあたって、セールスフォース、やっぱり、さっき話したカスタマイゼーションとか、そういったAPIの中で作っていくというところで、これを全部自分たちでやるとしたら、もう開発リソースがなくなってしまうというか、エンジニアが足りなくなってしまうんですよね。
で、そこでスケールできないという中で、そこで面白かったのがやっぱり、そこにビジネスチャンスを見た元セールスフォースの社員が、そういうSIの会社を作って、それを全部私たちにもつなげれば、セールスフォースの成長も早くなる。
要するに、顧客のデマンドに対して、早くプロダクト、導入を早めるということができるようになったのが、
そのためにでもちゃんとしたプラットフォームが必要になる。APIが変わらないというか、ずっとサポートされるAPIが必要であるというのが重要なところだったと思いますね。
なるほど。いやーでも、その一つのアプリケーションを作っている会社、データベースを作っている会社からプラットフォームを作る会社にするには、やっぱりプラットフォームを作るための組織も必要だし、
APIをまずは多分社内のメンバーが正しく理解して使える状態にしなきゃいけないし、さっきのサードパーティーのアプリケーションストアみたいなのを開くのであれば、
サードパーティーのベンダーもそれに沿って何かを作らなきゃいけない。でなると、結構もうプラットフォームを作るってことに、専用の人材だったり、
Kパンみたいなものを会社として新たにつけていかなきゃいけないじゃないですか。そこができているっていうのがすごい。ケンさんまさにそこで働いてたんですかね?
私はアプリケーション側の方のセースクラウド側の。
セースクラウド側からはプラットフォームチームってどう映ってて、どういう仕事のコラボレーションの仕方してたんですか?
とにかくすごい人たちです。やっぱり優秀なデータベース、データモデル、あとスケーラブルなAPIを作るっていう点では、もう本当にトップクラスの人たちがたくさんいて、
ビジネス、プロダクト観点で考えるとすごくいいのが、
今たくさんの会社がマルチプロダクトとかに行ってるじゃないですか。その中で共通した要素がもういくつかもあるんです。認証であったり、
24:03
データの呼び方の同じ、同じデータモードで同じデータを複数のところでまた作らなきゃいけない、再現しなきゃいけないっていうのをやっぱり一箇所にまとめて、それをみんな使ってくださいねっていう
ふうに作れるプラットフォームチームってあるっていうのがやっぱりセルフォースの強みでした。 なのでほぼ毎年新しいビジネスを出してる、
買収してそれが成功するっていうのはやっぱり同じAPIを、ほぼ同じAPIを使っているっていうところがやっぱり強みになるんですよね。
で、そのためにはどういう人たちが必要かというとやっぱり、すごくデータに詳しい、大量のデータに詳しい、あとはデータモデルを、
APIを構築するのに詳しいチームが必要なんですけども、逆に言えばアプリケーションのエンジニアがそこを知らなくてもいいんですよね。
なるほど。
ただAPIを、本当にiPhoneのiOSじゃないですけども、別にカメラの動かし方とか、設定の仕方とか、保存の方法とかそういうのを考えなくていいんですよね。
ただアプリケーションだけ作ればいいっていう点では、いろんなイノベーションが早く生まれる形になるんですよね。
なのでそういった意味だと、我々は営業さんとか営業組織が必要とするものだけを考えればよくて、それにもし新しい何かしらAPIが必要とやった場合には、
社内でプラットフォームチームにAPIのリクエストを出すんです。
これは必要ですと。
で、そこのプラットフォームチームに同じくPMがいて、私たちだけじゃないのでサービスクラウドとかマーケティングクラウドとかいろんなところにある中で、
じゃあ共通しているのはこのAPIですね。
で、今のセールスフォースのビジネスとして伸ばしたいのはここですよね。
だったらこの優先順位でAPIを作ってみましょう。
っていう風に決められる。さらにはでもそこだけじゃなくて、パートナーさんもいるしISBもいるし、
っていう中で、そのすべてのニーズを優先順位をつけるっていう中では非常に大変で難しい仕事ではあるんですけども、
それができているからグロースとかイノベーションができるっていうのが強みですね。
かなりプラットフォームチームはすごいセントラルな組織というか、
ここが真ん中にあって、いろんなアプリケーションを管轄しているようなプロダクトのチームっていうのが、そこに対してフィードバックをかけてくる。
そうですね、まさにそうです。
ちょうどこの間、CPU共感のイベントで、すごいPMと、私が昔エンジニアとして働いていた友達だったんですけれども、
やっぱり同じような感覚でやってらっしゃるっていうのがやっぱりやってますね。
すこりゃもうだから、もともと決済の部分とか、ペイメントの部分とかがいろいろあって、その中でもやっぱりレストランとかはまた小売と違うニーズがある。
なので、もうそこは共通して作る、一個ずつ作るよりはそっちにもう組織を作って、
27:01
ベースのプラットフォームのレイヤーがあって、同じように使えるところとそうでないところを区別して特化したアプリケーションを開発していくっていう考え方でやってますね。
なるほど。
その、ケンさんがアプリケーション側から仕事するときに、例えばお客さんと話したりとか、お客さんのニーズとして上がってきたものが、まずセールスクラウド側に来るわけじゃないですか。
例えば営業さんが話してきて、こうだったみたいな、来たときに、これを実現しようと思ったときに、そもそもプラットフォームを変えた方がいいのか、
あるいはアプリケーション側で一定のその顧客向けのカスタマイズとして受け入れた方がいいのかっていう、結構もっと手前の意思決定もある気がするんですよ。
ここの見極め、逆にそのアプリケーション側にもプラットフォームってものをすごい理解したマネジメントが必要なんじゃないかなっていうのが最近感じていることで、この辺っていかが、どうでした?
いや、それ本当にすごくいい質問で、なんか、我々もやっぱりお客さんが、セールスクラウドっていうプロダクトの中でいろんなお客さんと話すじゃないですか、そうするといろんなニーズがあるんですよ。
で、共通してみんなが必要なものと、もうこの業界に特化したものっていうのに分かれるんですよね。我々セールスクラウドも
SaaS のアプリケーションとしてそんなにガチガチにカスタマイズできないんですよ。 なので、我々もセールスクラウドの方もここは API で解決してくださいっていうところと、我々がセールスクラウドの中で
その行動数に設定できるような提供の仕方をするっていう ことをさらにもっと深いレイヤーでやってるのがプラットフォームチームなんですよね。
なので、じゃあセールスクラウドが必要としているけれども、じゃあサービスクラウドとマーケティングクラウドとかそういった他のプラットフォームのお客様は
みんなが必要としているものであればそれを提供するべきだけど、そうでなければカスタムで作ってくださいっていうそのカスタムで作れる API を提供する
っていうそのオプションをどう舵を切るかっていうのはやっぱり、その PM の力量というか、あれですよね、実力ですよね。
そうですよね。 じゃあケンさんがこう初め入ったじゃないですか、じゃあセールスクラウドの PM としてまず
ジョインしましたってなった時に、初めプラットフォーム何それっていう状態じゃないですか。 ここどうやってキャッチアップを進めていったんですか?
プラットフォーム側をどう理解していくかというか。 そこは
大きく、私のやっぱりメンタリングとして私が雇って
トレーニングしてくれたプロダクトマネージャーがいて、彼にいろいろとこういう新しいプロダクトを提案してたんですよね。
その時に、彼はもう その時も6、7年くらい PM を、セールスクラウドの PM やってたので、
これはこのとこれとこの3つはできるけど、この4つはできないです。なぜならこの API が存在しないからです。
30:00
っていうのを綺麗にわかりやすく、そのコードとあと API あのデベロッパーの API を見せてくれながら説明してくれたんですよね。
なるほどなと思って、それでじゃあこれを作るためには、そのプラットフォーム ティームの PM を説得しなきゃいけない。
これってこのビジネスニーズありますよね。 これをやれば、
セールスフォースという会社のビジネスに貢献します。だから作ってください、というふうにこう作って、
ユーザーストーリーを渡すんですよ。 依存性のある、デペンデンシーのあるユーザーストーリーを渡して、
で作ってもらうというようなところが結構 大変な作業でしたね。
この説得する時の材料って、やっぱりいわゆるビジネスインパクトというか、このぐらいの MRR がまず集めるし、
ポテンシャリーこのぐらい増える、タムの広がりみたいなものっていう、ビジネス的な側面とか、
他にこういうインテグレーションの可能性が広がるので、お客様に提供価値がこのぐらい広がるとか、
割と情報って統合的なのかなって想像するんですけど。 そうですね、例えば僕が一つやった例の中で言うと、
2015、6年ぐらいにセルスフォースは AI をメインメント出していくっていうのがビジョンに入っていたんですね。
AI をうまくお客さんに使ってもらうためには、やっぱりきれいなデータ、構造化データが必要なんですよ。
だけどセルスフォースは結構当時の大きな課題の一つが、重複したデータがたくさんあったんですよね。
例えば誰かが名刺を持ってきて、その名刺を入力して、じゃあそのデータがすでにセルスフォースに入っているっていうことを知らずに作ってしまうと、
その後に商談とか紐付けた場合には、どっちにつければいいかわかんないとか、データがバラバラになってしまう。
そうすると、AI の機械学習の精度が下がってしまうんですよね。
なので、実は僕が作ったのが、その重複をチェックする新規のプロダクトだったんですよ。
なので、入力しながらデータベースで確認して、実はこれもありますよ、マージしますかとか、
すでに3つくらい存在しているので、これ全部まとめますかとかっていうのを作ってたんですけど、それって売上げにはそんなに貢献しなかったし、
ユーザビリティーはすごく良かったんですけれども、やっぱり全然売上げには貢献しなかったなかっ、してはいなかったんだけれども、
会社のビジョンとして、必要なものだよねっていう意味では、プラットフォームのPMにとってもやっぱりすごい理解しやすい。
なるほどなっていうふうに理解していただいて作ってもらったっていう経緯がありますね。だからそうですね、目先の MRR だけではなくて会社のビジョン、
この先こういうプロダクトもやりたいんだよねっていうふうな感じで説明すると、なるほどね、じゃあこれは重要だねっていうふうに
理解していただけるっていうのが、努力したところですね。
33:00
この会社のプロダクトが、例えばAIっていう一つのセンテンスだと、いろんな受け取られ方するじゃないですか、
その時には例えば、セールスクラウドはセールスクラウドでロードマップみたいなものを持ってたりして、それがプラットフォームチームとも共有できてて、そのロードマップの一部ですみたいな感じにはなっていたんですか?
まさにすごく一層ですね。本当にそうなんですよね。最初に入社した2011年が結構、セールスクラウドはセールスクラウドとか、プラットフォームはプラットフォームで独立して開発をしてたんですよね。
もちろんすごく高いレイヤーではコミュニケーションを取ったんですけど、私が入社した時の普通の PM で入った時にはそれがあまりなかったんですよ。
だけどそれから3年、4年ぐらい経った時期に、買収が増えて、いろんなプラットフォームに依存するプロダクトがどんどん増えてきたんですよね。
あとはやっぱり、横のチームが何を作ろうとしているかっていうところが見えてなかったんですよ。
で、ある時、結構、セールスクラウドは年に3回リリースするんですけども、その1個のリリースの時に
いろんな被ってるのが出てしまったんですよね。 で、それに対してやっぱり
パーカーさんがお怒りになって、 「なんでお前らは、あんたたちは他の横にいるチームと会話してないんだ」みたいな話になったんですよね。
その時に、じゃあ変えなきゃいけない。これは私にも責任があるって言って、そこから、大体その当時の今ではセールスクラウドのやり方って、
年に3回リリースがあるので、1回パーカーに「これ作りましたよ」って言って、それをパーカーに見せて、
で、リリースする前に「パーカーにできましたよ」って言って、見てくださいって言ってリリースしたんですよ。
それを結構単体でやってたんですよ。セールスクラウドはセールスクラウドでやって、サービスクラウドはサービスクラウドでやって、プラットフォームはプラットフォームでやって。
で、このままだったらスケールしないっていうことで、パーカー自ら月に1回、全てのチームの
ロードマップと、今の経緯を見るっていうので、月に1回、約3日間、
すべてのプロダクトマネージャーがプレゼンするっていう仕組みを作ったんですよ。
はぁー、パーカーレビュー。パーカーレビュー。
で、当時の僕としてはもう死んじゃなかったんですよね。だってコーファウンダーで、CPU、当時CPUやっていて、
正直もう、
なんかもう手に入れたいものは全て手に入れてるはずなんですよね。もう金銭的な面で考えても、
セールスコースのコーバー。その人が、我々、ヒラシャインPMと、
1ヶ月の3日、
過ごして、ちゃんと向き合ってくれるっていうのは、やっぱりこれはパーカーの凄さだなっていうふうに感じましたね。
でもそれをやることによって、そのさっき話してた同じものを作ろうとしている。例えば1個のチームが
カラーピッカーを作ろうとして、このチームがカラーピッカーを作ろうとしていたら、その日のうちに、
36:01
「はい、じゃあこう会話してね」って言って、ちゃんとそこでストップをかけることができる。
で、開発がもっとスムーズに。じゃあこれってもうこれだけ必要であればもうプラットフォームの一部になるべきだよねとか、そういうのをこう、
阻止できて、生産性よく、時間はかかるけど生産性よくできるようになったのは、そのパーカーの
プロダクトへの向き合い方がすごい変わったからかなと思いますね。 なるほど。なんかロードマップも集約してセントライズしたというか、
プラットフォームだけじゃないですね。例えばそのロードマップ運用みたいな、そのナレッジ自体もすごいセントラルというか、それ自体がなんか
言うたらプラットフォームみたいなものですよね。 そうですね。なので、もうテンプレートがあって、各PMが1人3分とか8分とかって決まっていて、その間に
次のリリースに出るものと、あとそれまでの進捗を毎月アップデートしてやるって、なので、それを誰でも見れるようになっていたので、私も
じゃあ他のチームが何やってるかとか、他のプロダクトが何やってるかっていうのが見えるようになって、その人たち誰に話せばいいかっていうのも
わかるようになったし、そのデータがあることによって検索して、このこれを作っているPMとデザイナーは、あと
テックリードはこの人たちからこの人たちに話せばいいっていうのもすごくわかりやすくなりましたね。
なるほど、いやすごい勉強になるし、僕らもこれめちゃくちゃ近いことを今始めたりしているので、そのテンプレート見てみたいなって思いましたね。
ぜひもう今度再現します。 ありがとうございます。
でちょっとあのさっき聞いてて、もう一個これ絶対聞きたいなと思ったんですけど、買収したプロダクトを絶対プラットフォームに載せるっていう
なんかところがあったと思うんですけど、言うたらなんかもうデータベースからAPIから何から、もう要は買収する前のその会社って
その人たちのやり方で、その人たちに内に自由に作ってるわけじゃないですか。 これをSalesforceのプラットフォームに載せるって
どういうことなんだ、どうやるんだ。 そうですね、なので例えばなんですけど
例えばマーケティングオートメッションやってるツールがとしたら、自分たちで開発して作った
Emailっていうオブジェクトと、あと会社っていうコンセプトと、あとリードっていうか取引先とかその人っていうコンテンツがあるとしたら
もちろん自分たちのプロダクトの中ではそれをそういうデータとして持ってるんですけれども、それをSalesforceに連携するときには
そのSalesforceのオブジェクトにAPIとして情報を流し込むっていうやり方があるんですよね。
なのでデータモデル自体がSalesforceに最終的に合わせて利用してもらってるっていうところがあるからね。 なるほど。
なので買収した後に今度は何をやるかっていうと、そのメインのプロダクトの部分をこのAPIを介さずに直接データベースに入れるようにするっていうのを
できるようにするのもやっぱりそのAPIを外を通してじゃなくても中で直接つなげるっていうことをやる
39:04
作業が起こるんですよね。 なるほど。
でもデータモデルが一緒なので、特にあまりコンフリクトは起こらない場合が多いんですよね。
これプラットフォーム側に例えばこのColumnNesみたいなことって往々にしてあり得るのかなっていうふうに。
そうですね。だから簡単にできないものはやっぱりたくさんあるんです。時間がかかる部分はあるし、もうテクノロジーのスタックがあまりにも近いすぎてできないということもあります。
なるほど。 その場合は、そうですね、作り直すかそのままその古いスタックを使い続けるかっていうオプションが2つに分かれてしまうんですけども。
でもそれをつなぐことによって、プラットフォーム側が持っている機能だったり、スケーラビリティみたいなものを買収したプロダクトに対してくっつけていったり、本当の意味でのインテグレーションをちゃんと進めるっていうことができる。
さっきの認証の話とかわかりやすい例ですよね。 そうですね。
あとは、セルフソースの中のアプリケーションを入れる場合に、APIが更新されるとアプリケーションが更新しなきゃいけないんですよね。
そういうのが必要なくなってくる。 でも本当に直接話に、やっぱりスピードも速くなるし、セキュリティも高くなるし、パフォーマンスも良くなるっていうのがやっぱり買収した後の特典にはなります。
なるほど。じゃあ、スラックも何らかの形で繋がれているわけですよね。
そうですね。スラックは本当にテクノロジースラックが全く別なんで、そこら辺はやっぱり全くこれからも新しいセルフソースのトリップになるかなと思いますね。楽しみでおります。
あれ、タブローもでしたっけ? タブローもそうです。
いやだからそういう結構でかいプロダクトがいっぱいあって、CRMとはちょっと距離がありそうなものもいっぱいあるけど、これからプラットフォームとしてうまく繋いでいくってことですよね。
そうですね。だからそういった意味だと、CRMとかデータベースって基本的にデータを入れて、データをある意味見に行かなきゃいけないんですよね。
その見に行った時に、そのより理解しやすくするっていうのがやっぱりタブローの部分。 確かに。
たくさんのデータで何を見ればいいかわかんないっていうのを見やすくするっていうのと、あとはスナックの場合だと例えばデータベース上何か変わりましたよって時に、
じゃあそのレポートを見に行くか、ログインしなきゃいけないんですよ。それかセルフォース上に通知を持っていく。
セルフォースのアプリを入れてなきゃダメなんですよね。それを今度スラックっていうチャンネルがあれば常にオンで、常に簡単にレスポンスができる。
そういうのができれば、例えばじゃあ、営業のこの商談があった商談がちょっと金額安くしてほしい、それを承認してほしいんだけどいいですかって言って上司に行く時に、
42:00
そのセルフォースを開かずにスラックでオッケーですって言って承認アプローブって言って、金額を変えてアプローブを変えるっていうことができれば、できるのが
将来のスラックのビジョンになりますね。 ああ、それは強いですね。
オフィスですもんね、あそこがね。 そうですね、本当にそうなります。特にこのリモートワークの世界の中ではそうなってきますよね。
なるほど、いやーめちゃくちゃ面白いというか、ワクワクするというか、作る側大変そうだなっていう世界ですね。
これあともう少しちょっと毛並みが違うんですけど、Go to Marketというか、いわゆる営業とかマーケティングをやっている、その各プロダクトでやっている人たちと、
プロダクトマネージャーってどういうふうに責任を分解してて、で、プロダクトマネージャーは何によって評価されるのかとか、このあたりをちょっともう少しお聞きしたいなと。
そうですね、じゃあ評価の方がもうちょっと簡単かなと思うので、先にちょっと説明すると、やはりまあ特にプラットフォームとかプロダクトの方では、
どれだけそのAPIが使われているかとか、そのプロダクトが使われているかっていうのを、
常にやっぱりデータとして見て、新規に開発して、このニーズがあると思って開発して、それがデータで証明される。
で、それを、で評価の点に関しては、やっぱりそのアジャイルの中でプランニングをするじゃないですか。
この機能とかこのプロダクトは1ヶ月なのか3ヶ月なのかの間にやる。で、それをプランニングしてストーリーポイントつけて、ちゃんとそのプラン通りに
実行するっていうのがやっぱり一つのポイントで。 もう一つはやっぱり使ってもらうデータが出てくるっていうようなところがやっぱり評価の軸の大きいところになると思います。
なるほど。 ただまあもちろんその使われないからってクビになるっていうのは、昔はあったかもしれないですけど、最近はそれほどそういう文化はなくなってきましたね。
なのでプロダクトをリリースして、 あまり使われないとか失敗だからPMがクビになるってよりは、じゃあ次のちょっとリサーチをして考えていきましょうっていう風な感じになってきているので、
評価っていう意味では、そうですね、そこが一番大きいかなと思います。 プラットフォーム側だとそのAPIの呼ばれた回数とか、なんかそういうのすごくわかりやすいですよね。
でもアプリケーション側だともう少し結構事業に直結していくのかなって思ったんですけど。 まさにその通りで、そこがGoToマーケットの部分になるんですよね。
なので結局、Facebookとか普通にiPhoneとかってやっぱり使ってる中で何か変えたら、お客さんがユーザーがそれを
自分たちで学んで使っていけるようになるんですけど、やっぱりB2Bの製品ってなかなかそういかなくて、まず新しい機能が出ましたよっていうのを認知してもらって、
それを、あとは売ってもらったりとか、こういう機能が出ましたよっていうのを毎回
言わなきゃいけないっていう中で、伝えなきゃいけないっていう中で、GoToマーケットがキーとなってきます。
45:00
なので結構時間をかけている部分が、プロダクトマネージャーとセールスフォースだとまず一応はドキュメンテーションですね。
特にAPIがあるので、こういったセールスクラウドで新しいAPIが出ましたってなった時には、そのAPIが何をするかっていうドキュメンテーションと
APIのプロダクト自体どういう仕様になっているかっていうのがすごい必要になるので、実はスクラムチームの中にライターがいるんですよ、セールスフォースは。
で、リリースした時に最新のドキュメンテーションになっているように常にこう毎日じゃないんですけれども、週に何回か来てくれて、
こう仕様が変わるじゃないですか。もともとこういうふうに作りましょうっていうドキュメントを作って、でも作り出したらこう変えたりこう変えたりしているのを全部
リアルタイムで変えてくれます。その最終的に作った ヘルプっていうかドキュメントがそのまま
生となってしまうんですよね。 なるほど。 だからそういった意味だとすごく重要な役割をしています。
それをベースに今度はイネーブルメントをすごくPMが連携してやってきます。なのでプロダクトマーケティングがいればプロダクトマーケターと連携して
どういうメッセージングでみんなに伝えていくかっていうところと、 CS のイネーブルメントのテクを作って
CS の人たちも今までこういうことしかできなかったのが、こういう新しい機能ができるようになりましたよって言って全てを
CS にイネーブルして、営業さんにも同じく、営業はプロダクトマーケターがやる場合もあるんですけども、やっぱりその中でも例えば
新しい機能があった場合にはよくデモみたいなのやるんですよね。 そのデモのスクリプトを書いたりとか
実際にそのデモ環境をいじったりするのも場合によってはPMがやったりします。 なので誰でも新機能を簡単に携帯で見せられるとか
PCで見せられるようにしているのもPMが絡んでますね。 なるほど。
あとはテクサポです。テクサポにもこういう機能を出しました。で、こういう例えばこの機能はこういうバグが出やすい。こういうバグが出たらこういうふうに対処するっていいですよっていうのを
あらかじめ最初に伝えておくっていうのが結構、実はだからプロダクト作るのって仕事の半分ぐらいしかないんですよね。
その後はもうみんなに理解していくって。それを毎回新しいプロダクトが機能やった度にやらなきゃいけないんですよね。
なるほど。結構大変です。大変ですけど、なんか本当の意味でプロダクトに責任を持っている状態になってますもんね。
本当そう。最低限はそうですね。マーケターこれどんなコピーで売ったらいいかわかんねーよとか、作説の人がこれどうやって使ってもらったら顧客は成功だと言えるんですかとか。
そういう問いに答えていくわけですよね。そうですね。それがやっぱり、セールスソースで結構やっぱり力を入れているのが、元からそういういろんなチャンネルから
プロダクトのフィードバックをもらうこともPMとして日々やっているのがやっぱりいいことではあるので、例えばPMとしても僕の場合は日本語が少し喋れたので
48:00
年に数回日本に来て、日本のコミュニティの人たち、そういうセールスクラウドとかマーケティングクラウドとかそういった感じのコミュニティがあって、そこにPMとして参加して
実際どうですかって言ってユーザーの声を直接聞くっていうのもよくやってましたね。 なるほど。
この今、日本語少し喋れるから日本に来たいって話があったんですけど、セールスソースの後半の4年前に日本で、日本で活動してたっていう。
そうですね。今でいうアウトバウンドプロダクトマネジメントに近いものになります。 アウトバウンドプロダクトマネジメント。そうですね。
もともとプロダクトマネジメントって、プロダクト作りの中でいろんなお客さんの声とかを取り入れて仕様とかを、リクァイメントをどんどん
作っていくっていうのがベースになったんですけど、やっぱり 今のセールスソースの規模の会社になって、やっぱり顧客が増えて、人数が増えて、バーティカルも増えてってなると
PMがその声を拾い切ることができなくなってしまうんですよね。 それを、もちろんプロダクトマーケターからは入ってくるし、CSからも入ってくるし、営業からも入ってくるんですよ。
でもその情報ってやっぱり、ちょっとこの営業寄りだったり、 サクセス寄りだったりするんですよ。やっぱり自分の商談を苦労するためにはこれを作ってほしい。
自分が持ってるお客さんたちが成功するためにはこれを持ってほしい。でもそれを、じゃあ、自分たちのKPIじゃなくて、プロダクトっていう中で見たら、それをこう
標準化しなきゃいけないんですよね。それをやるっていうのが、当時の僕がやっていたことの一つです。
日本っていうマーケット、日本が当時3位ぐらいだったのかな、セールスソースの全世界のマーケットの中で。
それをじゃあ2位まで持っていくためには何をすればいいのかっていうのが、僕の仕事の一つでしたね。
なるほど。 だから200社ぐらい、最初の1年200社ぐらい訪問しましたね。
ある種、あれですね、さっきのパーカーさんがやっていたことを、ある種日本で近い状態、なんかその
顧客というか、この日本の市場で戦っていくためのプロダクトの姿ってどうあるべきかっていうのを、いろんな声から吸い上げて決めていくっていう
フィードバックをかけていくっていう感じですよね。 その通りですね。本当にだから営業からサポートとかサクセスとかいろんな人たちといろんな会話をしましたね。
なるほど。ちなみにどういう職種の人と一番喧嘩したんですか? 喧嘩ですか、喧嘩は、やっぱりどうしても難しいのが、あの
やっぱり大きなお客様がいて、大きなお客様、この商談を取ればすごくもちろんMRRもARRも上がるからっていうのを僕も分かってはいるんですよ。
でもやっぱり、会社として、開発組織としてはちょっと特殊すぎる。
その、1社だけのカスタマイズになってしまうっていうところを伝えなきゃいけないのが一番、まあ
難しいっていうか、そうですね。問題が起きる方にしなかったですけど、やっぱり納得してもらうというのはそこがやっぱり難しかったですね。
51:06
最後そういう時って、どういうところに落とし所をつけるところが、ことが多かったんですか? そうですね、まあ
まあ 納得はしていただけなかったんですけど、基本的にまあよく使っていたのが、当時よく使っていたのが80-20の
ルールで、約80%のお客様が必要とするものであれば、セールスフォースとして作る意義がある。
けど、20%の入っちゃうんであれば、やっぱりカスタマイズしてほしい。っていうのが、その
メッセージの一つではありましたね。 そしたらまあなんとなくちょっと納得していただけるかなっていうところがありましたけど。
80-20はすごくわかりやすいですね。 確かに。
これ要はカスタマイズだよっていう時には、当然その費用をクライアントさんからいただくっていう、そういう商談になるんで、一つこう
難しくなるってことですよね、セールスの方からすると。 そうなんですよね。
で、実はそこがセールスフォースのなんか、僕が来る前までの大きな課題がやっぱり、セールスフォースをあんまり
SaaSのプロダクトとして使うというよりは、日本の性質上 カスタマイズが多かったんですよね。
だからそのSI屋さんにほぼセールスフォースを再現してもらうとか、そういう感じだったんですよ。っていうのはやっぱりまあ、プラットフォームのライセンスが
セールスカードのライセンスが10分の1ぐらいなんですよね。 なのでプラットフォームに、例えば自分たち専用のセールスカードを作れば、
その後のマンスリーのMRRが、MRRっていうか払ってる企業が安いわけじゃないですか。
そうすると、いわゆるSaaSのプロダクトの恩恵をあまり受けないんですよね。
っていうか全然受けないんですよ。 アップデートが来ないので。
っていうところがやっぱりその中の理解がやっぱり、マインドセットを変えるのが一つと、プロダクトのその、そういった
理解を変えていくっていうのがもう一つでしたね。
特に我々も日本のエンタープライズのお客様とお話しすることが多いですけど、
そのアップデートが来ないっていうことの意味みたいなのを伝えていくのってすごい難しいなっていう。
そこなんですよね。だからそこは、うちも本当にその、じゃあそこはパートナーさんにお願いするしかないですよ。
だからできればこっちのプラットフォーム側の方のものを使ってくださいっていうふうにはお願いはしてるんですけどね。
そうですよね。本当はその方が皆さんをサクセスさせられるんですっていうのがあるんですけど、難しいジレンマがありますよね。
難しいジレンマですね。だからそうですね、だからもう本当に今すぐビジネス取って必要であれば
使っていただく、自分たちカスタマイズしていただくことが可能ですけれども、もし待てるなら
プロダクトからその使った方が将来的に良いですよ。それからもちろん最終的には
その戻すコストが出るので、それも理解した上で使っていただけるなら是非使ってくださいっていう感じが多いですね。
いやー、もうなんかめちゃくちゃ生々しくて、すごくマスコだなっていうのと、先に起きることがある種全て予言されるなって思いました。
54:08
というところで、もうだいぶ時間も経っちゃったので、最後2つぐらいあって、1つはケンさんが改めて日本の市場とか
多分今ベンチャーパートナーになって、多分いろんな企業がお話しされてるんじゃないかなと思ってるんですけど、
国内でこういったプロダクトマネジメントとか、特にB2Bのエンタープライズ向けのプラットフォーム作っていくとか、そういう概念って
やっぱ僕はまだまだ知見として全然広まってないし、自分たちも切り開いていかなきゃなと思ってるんですけど、ケンさんとしては何が必要だなって感じられてますか?
そうですね、なのでやはり今の日本のたくさんのスタートアップを見ていくと、ちょうどこうなんかまずPMFとなるプロダクトができた
ところからじゃあ今度はそれをピザッとするためにSaaSに持っていく
とかもしくは新しくSaaSのプロダクトをそこに追加をするっていうパターンが多いんですよね。そうなると初めてこっちで作ったものの一部を
SaaSのプロダクトに使うかもしれないっていうところで出てくるんですよね。そうすると、誰がどっちのコードのオーナーシップを持つのかっていうところが
多分おそらく出てくる会社が出てくると思うんですよ。で、やっぱりSaaSのビジネスを提供するってなると常にもう99.999%はサービスが提供できる
クオリティーじゃなきゃダメなんじゃないですか。なので課題が何、もし何かバグが起きたとしたらすぐに直せる。そのコードを責任持って常に保ってるチームがいるっていうのが必要になってくるんですよね。
それをやっぱりスケールするためには プラットフォームが必要ですよねっていうのが一つと、あともう一つは最近
やっぱり一つのプロダクトを作ってマルチプロダクトに行く会社がすごくたくさん増えてきていると思います。 その中でそれを1個作った、2個目作った後に
3個目4個目を作るときに、プロダクトを作るときに、それを
あらかじめ想定して何が必要になるかなっていうのを考えて作るとやっぱり どっかの段階でプラットフォーム化しなきゃいけないよねっていうのが出てきている会社が増えてきていると思います。
やはりそのスピードなんですよね。結局そのプラットフォーム作るには、じゃあもう半年かわかんないですけど、やっぱり時間がかかりますと。その間に2個目のプロダクトが出せるし、もしかしたら3個目のが出せるかもしれない。
そこを犠牲にして今プラットフォームでやるべきなのか、タイミングをいつにするべきかっていうのを皆さん悩んでいるような感じがします。
確かに。いつ潜るんだっていう。 そう、いつ潜るんだっていう。
センソースもまあなんだかんだ言ってやっぱ6年ぐらいかかったので、潜るまで、潜る決意をするまでは。
なのでそこをやっぱり各会社のビジネスとしてどのタイミングがいいのかっていうのを見計らっているところかなと思います。
確かに。でもそういう観点に対して、ケンさんみたいな人に壁打ちをできたり、タイミングを測るための、そうですね、一つの知見をもらえるみたいなのはめちゃくちゃ心強いんじゃないかなっていう風に。
57:05
個人的には、前回もお話しして、いや今やってることは多分間違いじゃないっていう勇気がすごいもらえたので、それすごい良かったんですよね。
ありがとうございます。ぜひいつでも壁打ちに。
ありがとうございます。
聞いてください。
あとは最後、これをできればすぐにこのポッドキャストを出したいと思っていて、もう締め切りが今にも迫ろうとしている
DCM Atlasの告知をしていただいて、それで締めようかなと思います。
DCMでは今、DCM Atlasというプログラムがちょうど、今回のアプリケーションが10月の31日になりますので、
それまでにシートプログラムに参加したいと思っている投資家たちには4,000万円の出資で、
今、新しい、本当PMFからの、単開からのサポートするプログラムを提供していますので、ぜひ参加いただければと思いますので、
DCM Atlasで検索していただくとすぐにヒットすると思いますので、どうぞよろしくお願いいたします。
ありがとうございます。これプログラムの中にはケンさんも関わったりするんですか?
はい、私がプロダクトスクールを今回作って、プロダクトの今話したようなPMFのところから、さらには交通マーケットの部分まで、
すべて今まで私がセールスフォースとかアドビとかいろんな会社でやったものをまとめたものを今皆さんに提供しています。
めちゃくちゃゴージャスですね。
ありがとうございます。
はい、ありがとうございます。じゃあ、ぜひこれ聞いている方は、ご関心ある企業家の方は応募してみてください。
はい、じゃあちょっと長く1時間ぐらいお時間を頂戴したんですけど、すごい勉強になりました。
またぜひ2回目3回目お話し聞かせてくれると嬉しいなと思っています。
ぜひありがとうございました。
ありがとうございました。
エンディング
58:51

コメント

スクロール