新規事業の課題探索
こんにちは、ゼロトピックです。 今回も質問について回答していこうかなと思っています。
直近、質問会が2回続いているように聞こえると思うんですが、
社内のメンバーを呼んだセッションだったりが間に挟まっているので、
実は収録自体は1回ずつに1回ぐらい、質問を取り上げるような形で撮っていますという裏側の話でした。
ちょっと早速、2つ読み上げて回答していければと思っております。
ラジオネーム、みやしゅんさん。
いつも通勤中に悲しく拝聴しています。
直近のエピソードで、データセットの重要性と新規事業の立ち上げプロセスについて触れられている部分があったかと思います。
私は今、プレイシリーズAのスタートアップで新規事業の責任者をしており、
この328回目のエピソードは特に興味深く拝聴しておりました。
関心を持った背景として、新規事業を立ち上げる上での顧客の課題を探索するところから始まると思うのですが、
仕事の複数の課題と、課題解決することで中長期へ蓄積できるであろうデータも見据えながら、
直近の5つの製品を提供エントリーする意思決定をされたのだと勝手に解釈し、関心を持ちました。
その前提を踏まえ、2点質問なのですが、足元の課題の優先順位と、
その先のどういうデータを蓄積し活用するか、また既存のプロダクトとの掛け算など、
これらのバランスは非常に難しいと感じており、どのような思考プロセスや議論があり、意思決定されたのかを伺いたいです。
2点目に、以前のエピソードでもありました。ほとんどのスタートアップは限られた市場でポイントソリューションとしてエントリーし、
その後ポイントソリューションを複合的に提供することで最終的にERPとして市場を獲得していくというお話をされていたかと思います。
最終的にはERPを目指されているのか、なぜその山の登り方を選択されたのかを可能な範囲で伺いたいです。
いつも素敵な情報を発信ありがとうございます。ということで、ご質問ありがとうございます。
データ活用と意思決定
2つあるので、それぞれ回答できればと思っていますが、
まずは、全体であった新記事を立ち上げる上で、顧客の課題探索と、市元の顕在化しているような課題と、
それを解決することで得られるデータと、そういう観点はおっしゃる通りで、
その中でも一番重要なものは明確にあって、という顧客の課題を、それも深い課題ですよね。
ペインポイントと呼ばれるような、深くて他の代替手段では完全に解決できない、
そして頭の中を閉めてしまっているような、そんな課題をちゃんと解決するような、
かつ僕らはプロダクト志向というか、プラットフォーム志向なので、
それがある種、横に広がるという前提を持った上で、プラットフォームとして解決手段を汎用化したものとして提供すると。
もう一つは、僕らの競争戦略上は、顧客の成功と自分たちの成功をアラインするという意味でいうと、
成果報酬型のプライシングモデル、この3つを組み合わせて事業を立ち上げるということが、
まず一番何より大事で、データというのは事業の観点から見ると副産物的なんですよね。
とはいえ、このAIとかデータの時代において、いかに重要なドメインデータを確保、獲得、
あるいは活用可能な状態で、自分たちの手元に置いておけるかというのは非常に重要な論点なので、
事業を立ち上げるという観点のサブアジェンダみたいな形で常にデータのことを見据えて、
事業というものを立ち上げていくと。こういった前提を自分の中では持っています。
まさにバランスが難しくて、どういう思考プロセスとか議論がありという、その意思決定の部分ですが、
やっぱりデータのほうに主軸を置いて、このドメインデータは非常に貴重だし、
これを使うとこういうことができる、ああいうことができるという、できる思考というか、
自分たちができるというものの思考から始めたものというのは基本的に全部カットしていくんですよね。
そうじゃなくて、最終的に起こしていくのは、顧客にとって本当に重要な課題を解いているのかとか、
その課題を解くことで、顧客の経営とか事業に大きいインパクトを与えられるのかというのが、
まず議論のど真ん中にドーンと鎮座しているべきで、その中心を絶対に外さない上で、
先ほどのドメインデータを取れるのかとか、それを自分たちが扱ったら次何ができるのかとか、
そういったものはサテライト的にその周辺にあるというような、そういったイメージで自分は思考とか議論しています。
やっぱりどうしてもそれちゃうことってのがあって、例えばいっぱい稼げるわみたいな話とか、
あとはこのデータ取れるからこのプロダクトもいいんじゃないとか、そういう話あるんですが、
やっぱり今大事なのは、今目の前のお客の本当に重要な問題なのかという、もう再三言いますけど、
ここに対して良いプラットフォーム、プロダクトを提供できるか、この議論だけ、そこにいかに全体の意識を集中させるか、
あるいはそれ以外のものっていうのは、大事なことは分かっているけど一番ではないよっていう、
そういう優先順位の認識をみんなに対して浸透していけるかっていうのが、自分にとっては大事なことかなというふうに思っています。
今回もう5つ製品出しますよっていうアナウンスしてるんですが、
当然プレスリリースにはある種、そこに関心を持つ見込み顧客との接点を作りたいという意図もあって、
あるいはその見込み顧客にとって本当にそれが大事な課題なのかっていうのを図るっていう、
そういった検証的な意味合いもすごくあってですね、
やっぱりそこのリアクションを見て、先ほどのプロダクトのど真ん中が本当に重要な課題なのか、
それが汎用性があって他の人たちにとっても重要な課題なのかっていうのを測っていってるっていうのが、
自分たちのやり方としてはあります。
でも最終的には商談とか導入先の議論とかを通じて解像度って深まっていくものなので、
やっぱりプロダクターリリースしてみないとわからないこともいっぱいあるなっていうのが直近も思っていることですかね。
これが1点目で、2点目についてはポイントソリューションとして入っていって、
ERPを目指すと。10Xも目指してるんですか。
なんでそういう登り方なんですかっていう話なんですが、
目指していますよと。なぜならTAM、要はアクセスできるような潜在的な市場が
圧倒的にERPの使用性が広いから。この1点にすごく集約されるなと思っています。
大きくプラットフォーム型のビジネスで成長しようと思ったときには、
プラットフォームといっても結局は仕組みの提供。
ここにいかにピカピカに磨いた本当に良いものを提供できるかっていうところが最終的には論点になっていく。
一般的な受託開発的な、委託開発的なものとプラットフォームの差分を比較すると、
プラットフォームって最初はやっぱり弱いんですよね。
何が強みになるかっていうと、始めはやっぱりアーリーアダプターの声を聞いたものづくりをしていくと。
一方で最終的にはアーリーマジョリティとか、もっといくとラガードとか、
そういうレイトマジョリティとか、後ろのレイヤーの人たち、実利でものを判断するような人たちにとって
受け入れられる状態。これっていうのは、まず品質がすごい高いっていうのも当然なんですが、
実利的にコストが低い。要は自分たちのビジネスにとって払えるような許容可能なコストで提供されているっていう
2つを満たしたときに初めてプラットフォームっていうのは広がる。
広がっていくと、要はその品質っていうのは色んな会社によって揉まれていくので、
多角的な視点で磨かれていくと。それプラス、アーリーアダプターの人たちが持っていた、
より自分たちの要求に応えてほしいというような要求を盛り込んでいるので、
最終的にはやっぱりプラットフォームっていうのは、どんな委託開発よりも高い品質、低いコストっていう、
この2点を早いデリバリーとか、ある種QCDの両面で圧倒していくっていうのが、
ERPを目指す戦略
このソフトウェア業界の常識だと思うんですけど、
圧倒するまではコストと時間がすごいかかるっていうのが、
同時に存在する方式でもあると思っています。
なのである、例えば3年とか5年の観点とかで見ると、
プラットフォームって絶対に委託開発に勝てなかったりするんですよ。
なんですが、目的にはプラットフォーム第一で起こると。
だから昔ってEコマスって大量の会社が、
その委託開発でスクラッチで作ってたものがあったと思うんですけど、
もうその人たちが自分たちでゼロから作る品質っていうのは、
ショピファイを担いだときの品質に絶対もう今勝てない。
QCDで勝てないという状態になっていると思うんですね。
なのでプラットフォームを目指すっていうのは、やっぱり一つ、
いろんなタイミングで潜るっていうのは必要だなって思っていて、
僕らはこのプラットフォームでこのソリューションを提供していきたいと思っている。
プラットフォームかけるERPってめちゃめちゃ相性が悪いというか、
そんなに相性が良くない領域だと思われがち。
これが今の市場の見解というか、いろんな人が持っている見解だと思っているんですね。
理由はほとんどの会社が何らかのカスタマイズとか、
開発を通じて自社に必要なERPっていうのを再構築して使っている。
自分たちの会社は特別だと思って、
その業務フローっていうのは基本的にはプラットフォームではまかないなっていう前提で、
すごく分散的な状態になっているっていうのが、
現状Azizのスナップショットを見て、
ERPってプラットフォームってのは難しいという風に結論付けられているのかなというのを自分は感じています。
ただ難しいってことは、やっぱり一度入るとすごくもうとにもなりますし、
逆にその受託開発の世界でものすごい大きい市場が築かれているので、
ここをちゃんと入り込む手段を得られて、
その中でシェアを伸ばしていければ間違いなく圧倒的に大きな事業サイズ会社を作れると思っているんですね。
僕らは時間かかってもいいからそれを目指したいし、
それによって大きいタムにアクセスしたいっていう、
そもそもそういったウィルというか意思を持っているので、
その山の登り方を選択しているといったところがあります。
繰り返しなんですけど、めちゃくちゃ難しい登り方で、
例えばネットスーパー向けのプラットフォーム、
これもネットスーパー向けのERPだみたいな言い方もできるんですよね。
エンタープライズリソースプランニングで、
まさに需要と供給のリソースプランニングを我々はデータの可視化等を通じて支えつつ、
その後ろでOMSとかTMSとか、
いわゆる業務に必要なすべてのパッケージアプリケーションがくっついている状態なので、
ネットスーパーのERPを提供している状態とも言えるんですが、
ちゃんとしたものになるまでは5年かかっていますから、
ネットスーパーという本当に一つのちっちゃなサテライトシステムでも、
ERP化してプラットフォーム化していくって、
この2つの不確実性を超えるのはめちゃくちゃ難しかった。
でも、超えた結果としてどういうチャンスが今目の前に映っているかというのも、
自分たちは知っているので、
そのチャンスというのはちゃんとかけていきたいなと思っています。
若干早口になりましたが、まずは1つ目の質問は以上です。
次が行政まんまんさん。
これなんかラジオネーム何回か見たことがある気がします。
とある事業の事業責任者をすることになりました。
2から30人ぐらいの組織です。
すべての事柄に改造度高く関わり続けることが難しいと感じるようになり、
また自分の実感を別のことに費やすべきと考えるようになっています。
一定の現場の改造度を高く持ちつつ、
事業運営の意思決定をするために、
大本さんはどのような取り組みをされてきましたでしょうか。
失敗談もあればお聞かせください。
いつも応援しています。
ありがとうございます。
事業運営のフレームワーク
事業って大きく、僕は2つのフレームで整理できると思っていて、
RANというものとChangeという、その2つです。
RANは何かというと、要は今のオペレーションを回していって、
オーガニックな成長を生み出すというのがRAN。
要は日々何らかの定型的なオペレーションとか、
運用とか保守とかがあって、
これを継続することで得られる成長、
あるいは一般的なスクラム開発をしっかり毎週回していくことによって得られる成長というのも、
RANの方に入っていくかなと思っています。
一方でChangeっていうのは、その事業の状況に対して、
要は外部環境の変化等により大きな変更要因が加わって、
自分たちが変化をする必要が出たとか、
自分たちの意思で次こういうステージに行きたいので、
ここで非連続なジャンプをしなきゃいけないからこういうチャレンジをするっていうのも、
Changeの一因だと思うんですけど、
何らか要は自分たちが大きく変わらなきゃいけないっていう、
そのChangeのためのサムシングというか何か。
この2つで大きく事業のオペレーションというのは構成されていると思っているんですが、
やっぱりRANの領域っていうのは、
どんどんどんどん自分の関与っていうのは薄くなっていくべきで、
解像度っていうのはそれに比例して下がっていくんですよね。
だから徐々に、例えば初めの方はWebマーケティング自分でやってました。
けど今は全然やっていません。
でなると解像度は下がっていく。
だけどたまに報告を聞いたりした時に、
こういう状態なんだなっていうのは、
薄い情報でも自分のコンテキストが豊富にあるのでキャッチアップができたりする。
逆にそんな自分がオペレーションに全然関わっていなかったら、
例えば先ほどの自社開発のスクラムの運用とか、
そういうことは自分たちのスクラムどう運用されているのか、
それは自分で運用したことがないので分かっていなくて、
何らか関わる時にはものすごいキャッチアップが必要とか、
そういうメリハリはありつつも、
とにかくRANの部分については自分の解像度っていうのはどんどん下がっていくが、
それはもう言ってしょうがないと思っています。
情報の取り扱いと変化の必要性
一方でチェンジっていうのはやっぱりこれはトップランで起こさないと絶対に起きていかないので、
このチェンジを起こすための知識っていうのは、
今ゼロであっても100であっても、
とにかく自分が最新の状態にアップデートされるような、
そういう瞬間を作り込む必要があると思っています。
その中には例えば先ほど全然自分が関わってなかったけども、
これからキャッチアップしなきゃいけないや、
ゼロからキャッチアップしなきゃいけないような情報とかも当たり前に入ってくるので、
このゼロからキャッチアップするときに、
いかに早く深くその現場に入り込んで理解ができるかっていうのは、
ものすごい大事だなと思っています。
すべての現場の解像度を高く持ちましょうみたいなのは無理なんで諦めますと。
一方でRANの最低限の情報は知りつつも、
チェンジに必要なんだが、
RAN側で今のRANの中で自分の情報解像度が弱い分っていうのは、
圧倒的なディープダイブをして、
一気にそこの専門家と同じレベルになる必要があるっていうのが、
自分の考えですと。
僕は結構これ得意というか、
チームの人たちとかからはうざいって思われるぐらい、
入り込むときの深さと速さは結構早い深いと思ってるんですよ。
人のスケジュールとかめちゃめちゃ無視して、
勝手に自分でミーティング入れて、
ものすごい情報を一気にキャッチアップして、
ドキュメントを社内のものとかも全部ガーッと書き集めてきて、
バーッとインプットしますと。
それを一度言語化して、これで合ってますかみたいなのをディスカッションして、
理解を深めていったり、時には自分で手を動かして、
ツールのことであればツール使ってみたりとか、
プログラムをちょっと見てみたりとか、
コードを読んでみたいとかも意図はずするみたいな形で、
とにかく深く早く入る。
情報が早く自分のほうに入ってくるようにして、
その上で正しいチェンジのためのジャッジをしたり、
リソースの配布のための社内の調整どうしようかなっていうのに、
体を動かせるようにすると。
失敗談と運用の重要性
そういったことをスタイルとしてはやっています。
失敗談なんですけど、
やっぱこの乱とチェンジは境目っていうのが一番難しくて、
これ任せていいのかな、チェンジなんかな、
乱なのかなみたいなのはやっぱ往々にしてあって、
ほとんどの失敗談は持ちすぎなんですよね。
その境目がきれいに割れていないような領域で、
乱からチェンジに変わって、
あるいはチェンジがもうちょっと終わりかけで乱に移行するっていうときに、
スパッとそれを誰かにお願いしたり渡すっていうのが、
意識的にやらないとできなくて、
その意識的に行うタイミングがちょっと、
例えば2回ですとか3回ですとか、
振り返るとずれてたな、早すぎたな、
あるいは遅すぎたなってことがやっぱり多くあります。
当然早すぎると受け取った側がやっぱりうまく運用できなかったり、
実務に落とせなかったり、
あるいはどこかでハレーションがある、
要は矢元だから聞いてくれてたみたいなものがどうしても起きる。
遅すぎると自分が本来別の場所でもっといい時間とか、
投資ができて、
領域があったにも関わらず、
ちょっと持ちすぎちゃってるねみたいな機械損失ですかね、
そういうものにつながってるっていうケースがあるんで、
このタイミングっていうのはすごい難しいし、
振り返るとやっぱ失敗っていうのはあるかなと思っています。
生々しいやつでいうと、
早すぎた失敗は人事制度なんですよね。
人制度、自分がうわーって深く入って、
ガーッと設計して、
作り込むみたいなのをしたんですけど、
運用はそこからHR本部みたいなところに
お任せをするみたいなことをしていきましょうと。
なんですけど、実際人事制度って運用がほぼ100パーなんで、
運用のときにどういう声が上がって、
どういうハレーションというか、
あるいは制度疲労があってとか、
あるいは想定してたものと差分があってっていうのを、
もっともっと深く入って見ておくべきだったかもしれない。
それが早すぎる手離れによって、
結構高コストな人事制度を長いこと運用してしまったり、
ハレーションもその中で生んでしまったり
っていうのはあったりしたので、
手離れのタイミングとか、
ランからしか結局得られないフィードバックとかも、
チェンジの中にあったりするんで、
そのあたりはいつも難しいなと思っています。
ランチェンジどちらもあるし、
このフレームワークすごくシンプルで使いやすいと思うので、
もしよければ参考にしてもらえればと思っています。
というところかな。
今回はそんなところですかね。
ちょっと直近とに違いですね。
少年野球でめちゃめちゃ時間が潰れていて、
日焼けがものすごい進んでて、
ポッドキャストを見ている人からもたまに日焼けについて
元気を受けるようになってきたので、
そんなところで、今回もお聞きいただきありがとうございました。
