私たちはなぜ事業責任者にならないといけないのか ~Webサービスを作る茨の道~

by KEITA YANAGAWA

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2012-2024 BASE, Inc. 11 主張の理由スタートアップにおける新規事業には2つの⽴ち上がり⽅があると思います。スタートアップにおける新規事業のあり⽅と本⽇のお話経験したのは後者ですが、両者に共通点もあるのではないかと思いますいずれの場合にも当てはまるのではないかという点についてお話しします。 ● 1つ⽬のプロダクトリリース ● すでに⼀定のPMFを完了した企業の2つ⽬プロダクトリリース

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2012-2024 BASE, Inc. 15 SIerと⾃社Webサービスおける開発の違い Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 2012-2024 BASE, Inc. 18 ①作ってもお⾦がもらえるか分からない Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者

Slide 19

Slide 19 text

© 2012-2024 BASE, Inc. 19 ①作ってもお⾦がもらえるか分からない Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザーお⾦を⽀払うと約束した開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者⾃社Webサービスは頑張って開発しても使われるか分からない！

Slide 20

Slide 20 text

© 2012-2024 BASE, Inc. 20 Webサービスを作るのはなぜ難しいか作ったプロダクトが使われる約束はどこにもない先⾏投資してプロダクトを作り、使われれば対価がもらえるが、使われる約束はどこにもありません。 Webサービスは先⾏してプロダクトを作り、その機能提供の対価としてユーザーからお⾦をいただくビジネスモデルです。ポイント1：ビジネスモデルの発明からしないといけないインプットよりアウトカムが⼤きいビジネスモデルを作らないとビジネスとして成⽴しないポイント2：ビジネスモデルは陳腐化する⼀度ビジネスモデルができても、よほど優れたものでない限り他社に模倣され、陳腐化に向かっていくポイント3：決められた期間で決められた収益を出す必要がある約束の中⾝を知った上で、約束を守れる正解を⾒つける必要がある ①作ってもお⾦がもらえるか分からない

Slide 21

Slide 21 text

© 2012-2024 BASE, Inc. 21 Webサービスを作るのはなぜ難しいかポイント1：ビジネスモデルの発明からしないといけないこれはあまりにも当たり前なことですが、インプットよりアウトカムが⼤きいビジネスモデルを作らないとビジネスとして成⽴しません。いいプロダクトを作るのは⼤事だけど、かけたリソースに⾒合う成果が出たかどうかには常に向き合わないといけない。 ①作ってもお⾦がもらえるか分からないインプット：どれくらいのリソース（ヒト‧モノ‧カネ）を使うかアウトカム：どれくらいの⼈が使ってくれるか、どれくらい儲かるか

Slide 22

Slide 22 text

© 2012-2024 BASE, Inc. 22 Webサービスを作るのはなぜ難しいかポイント2：ビジネスモデルは陳腐化する⼀度ビジネスモデルを確⽴しても、状況は刻々と変化していきます。状況の変化に適応できないと、ビジネスモデルは陳腐化に向かっていきます。＜変化のパラメータ例＞ ● 維持に必要な費⽤ ● ユーザーの流⼊数 ● ユーザーの流出数 ● ユーザーの獲得コスト ● ユーザーのLTV ● ライバルの参⼊ etc… ⽇々パラメータは変動していき、気がついた時にはビジネスモデルは陳腐化していることもあるので、常に点検‧修正が必要。 ①作ってもお⾦がもらえるか分からない

Slide 23

Slide 23 text

© 2012-2024 BASE, Inc. 23 Webサービスを作るのはなぜ難しいかポイント3：決められた期間できめられた収益を出す必要がある会社の事業活動には投資⽅針がつきもの。例えば、スタートアップも上場会社も、株主との約束があります。どれくらい⾚字を掘っていいのか、どれくらいトップラインを伸ばせばいいのか、諸条件によって正解は異なります。短期で正しくても、正解が⻑期すぎても意味がありません。ジャスト正しいを探していきましょう。 ①作ってもお⾦がもらえるか分からない

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2012-2024 BASE, Inc. 26 ②ユーザーが⾒えないかつ要望が曖昧 Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者

Slide 27

Slide 27 text

© 2012-2024 BASE, Inc. 27 ②ユーザーが⾒えないかつ要望が曖昧 Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者ユーザーが誰になるか分からないから要望が明確に分からない

Slide 28

Slide 28 text

© 2012-2024 BASE, Inc. 28 Webサービスを作るのはなぜ難しいかユーザーインタビュー等を通した⾒込み顧客はいるかもしれませんが、いざサービスをリリースしてみたら、その⼈たちが契約してお⾦を払ってくれるとは限りません。 Webサービス開発は、SIの開発のようにバイネームの顧客はいません。そもそも顧客がいない可能性もあり、それを常に頭の⽚隅におかないといけません。存在するかしないか分からない顧客と需要を想像しながら、プロダクトを作らなければならないのです。 ②ユーザーが⾒えないかつ要望が曖昧

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2012-2024 BASE, Inc. 31 ③⾃分たちで開発費⽤を負担しなければならない Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者

Slide 32

Slide 32 text

© 2012-2024 BASE, Inc. 32 ③⾃分たちで開発費⽤を負担しなければならない Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者作っても使われるか分からないにも関わらず⾃分たちで開発費⽤を負担

Slide 33

Slide 33 text

© 2012-2024 BASE, Inc. 33 Webサービスを作るのはなぜ難しいか投資的な考え⽅が常に必要になります。最終的にはサービス利⽤者からお⾦をもらうつもりでいますが、短期では⾃分たちで開発費⽤の負担が必要です。では、いくら投資して、いつまでに回収できればいいのでしょうか。リリース初期は、ユーザーを集めるために戦略的に⼿数料無料などの施策を打つこともありますが、そうすると開発費⽤の回収まで時間はさらに開き、考えなければならないことは増えます。 ③⾃分たちで開発費⽤を負担しなければならない

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2012-2024 BASE, Inc. 36 ④開発費⽤とサービスの対価を⽀払う主体が異なる Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者

Slide 37

Slide 37 text

© 2012-2024 BASE, Inc. 37 ④開発費⽤とサービスの対価を⽀払う主体が異なる Webサービスを作るのはなぜ難しいか SIer Webサービスビジネスモデル顧客から対価をもらいソフトウェアを開発する先⾏投資してプロダクトを作り使われれば対価がもらえる顧客/ユーザー（お⾦を⽀払うと約束した）開発依頼企業（不特定の）サービス利⽤者ニーズの把握⽅法開発依頼企業からの提⽰提⽰されない開発費⽤のソース開発依頼企業⾃社（調達した資⾦からの捻出）（サービスが使われれば）サービス利⽤者作ったソフトウェアの対価を⽀払う⼈開発依頼企業サービス利⽤者＝ ≠ 開発費⽤を出す主体とサービスの対価を⽀払う主体が異なる

Slide 38

Slide 38 text

© 2012-2024 BASE, Inc. 38 Webサービスを作るのはなぜ難しいか開発費⽤のソースを出す主体、つまり資⾦調達元は、スタートアップであればおそらくVCなどの株主であることが多いでしょう。安定的な収益を出しているプロダクトがある会社であれば、⾃社の経営陣がある意味で資⾦調達元（新規事業の予算を承認する主体）となります。資⾦調達元を向いてプロダクトを作ったらいいか、利⽤してくれるユーザーを⾒てプロダクトを作ったらいいか混乱しがちです。もちろん利⽤してくれるユーザーを⾒るべきなのですが、かといって資⾦調達元を蔑ろにしては開発が継続できません。信頼関係を築いたり、信⽤してもらうための説明が求められたり、中間的な数字成果を出すなど⼯夫が必要になります。スクラムとかアジャイルは⼤体この問題を解決するための⼿法だという理解。 ④開発費⽤とサービスの対価を⽀払う主体が異なる

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© 2012-2024 BASE, Inc. 49 困難を乗り越えるには事業責任者になれ範囲を広げてわかったことは、どこまで範囲を広げても明確な確信を持って決断はできない、ということです。これまで世の中になかったプロダクトを作る上では、社⻑も役員もマネージャーもPdMもビジネス側もプロダクト側も、明確な答えが出せる場⾯ばかりではありません。なんとなくの⽅向性のイメージとかはあるが、やり⽅についてはどうしても朝令暮改はありえます。僕の場合、最近の⼝癖は「わからないから⼀緒に考えてほしい」「⼀緒に試⾏錯誤して試してほしい」「50%くらいの確信度で話してる」という感じです。みんなわからないでやってる

Slide 50

Slide 50 text

© 2012-2024 BASE, Inc. 50 困難を乗り越えるには事業責任者になれそもそものコアユーザー設定の部分もアジャイル的に改善していくべきです。分からないことを認めて、少しずつ改善を積み上げていくしかありません。分からないからトップダウンでウォーターフォール的に進めるのは無理事業開発そのものもアジャイル的に進めていくべきです。事業開発もプロダクト開発も、相互に影響しうるので別々にサイクルを回す必要もないのです。アジャイルの⼿法をプロダクト開発者だけに留めておく理由はありません。

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© 2012-2024 BASE, Inc. 54 環境の変化に合わせてPMFし続けるために、前提条件から⾒直す困難を乗り越えるには事業責任者になれコアユーザーを決める事業計画を作る必要なお⾦を集めるチームを作る要求定義をする要件定義をする実装するグロースする前提条件である市場はプロダクトとフィットし続けているか？この成⻑⾓度でいいのか？もっと成⻑⾓度を上げられないか？獲得する予算はこれでいいのか？チームの⼈数と構成はこれでいいのか？

Slide 55

Slide 55 text

Slide 56

Slide 56 text

© 2012-2024 BASE, Inc. 56 困難を乗り越えるには事業責任者になれ⽣き残ったスタートアップはユーザーに認められるために死に物狂いでやってきた⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、ユーザーに認められるためにできることを死に物狂いでやってきました。やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。⽣き残るために結果としてアジャイル的なことをやるしかなかったとも⾔えると思います。プロダクトを作って、それを世に解き放ち、使われなければピボットをし、やっとPMFしたプロダクト名が社名になる、そんなこともよくある話です。⽂字通り「全員でアジャイルに取り組んだ経験があること」それがWebサービスのビジネスモデルで上場できるようになったスタートアップの強みだと考えます。

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

© 2012-2024 BASE, Inc. 62 どうやって事業責任者になるのかプロダクト開発は不確実性を孕むため、短期的な成果は⽰しづらいこともあります。また、短期で良いプロダクトやチームを作るのは難しいです。経営陣に対して都度成果について説明するのではなく、まるっと信頼してもらうのが解決策の1つだと思っています。プロダクト開発を取り巻くパラメータの多さを考えると、できるだけ広い責任範囲をコントロールできる⽅が良いです。任せてもらうスコープを広げて結果を出すため

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

© 2012-2024 BASE, Inc. 65 どうやって事業責任者になるのかこれは⾔い換えると⾃分のお給料が発⽣するまでの過程を考えたことがありますか？⾃分の会社のビジネスモデルが理解できているかという意味ですビジネスモデル上どうやったら売上ができて、それを実現するには何が⾜りていなくて、そのためには⾃分は何ができるか。シンプルなんですが、ここを把握してコミットするのが給与を上げるコツです！事業が儲からないと給料は上がらないですし、事業が儲からないと事業継続ができなくなる可能性もあります。専⾨職の枠の範疇だけで考えていると案外忘れがちなポイントだったりします。

Slide 66

Slide 66 text

© 2012-2024 BASE, Inc. 66 どうやって事業責任者になるのかお給料が発⽣するためには売上が⽴つ必要があります。売上が⽴つには何がどうなればいいのでしょうか。これを⼀番理解するためには事業計画を書いてみるのが⼀番です！これができると⾃分が出すべき価値が⾒えてくるかも知れません。事業計画を書いてビジネスモデルを理解してみよう事業数字を分解して理解する実際に計画を作ってみるミクロとマクロで作った計画を⾒直す⽴てた計画に対して結果を振り返る僕はこのようなステップで事業計画を作っていますが、今回はその中でも「事業数字の分解して理解する」「実際に計画を作ってみる」の部分について話します。事業計画の作り⽅

Slide 67

Slide 67 text

© 2012-2024 BASE, Inc. 67 どうやって事業責任者になるのか事業のKPI分解には実は正解はありません！ひとつの事業でも時期だったり伸ばし⽅でKPIの切り⽅は変わります。実はKPIの分解の仕⽅はそのまま戦略です！事業数字を分解して理解するまた、試みとしてKPIを今の⾃分の役割や役職からKPIを切ってみるのもありです！エンジニアであれば、「今開発している機能がどのKPIにヒットするのか」とか、「開発速度が上がると何が変わるか」とか。重視するKPI例ユーザー数単価売上利益

Slide 68

Slide 68 text

© 2012-2024 BASE, Inc. 68 どうやって事業責任者になるのか KPIを分解したら、年単位の事業計画を⽴ててみましょう。短くても1年分、できれば3年分、5年分の計画を作ってみましょう！実際に計画を作ってみる数年後の事業あるべき姿どれくらい利益が出れば黒字化するか、その時に費⽤はどうなるか、このあたりの感覚が持てると解像度が⼀気に上がります。数年後の事業のあるべき姿を実現するために、⾃分がどうアクションできるかも思考実験してみましょう。売上/利益計画 KPI分解/計画コスト分解/計画 ● いつまでに黒字化すれば事業は継続できるのか ● どれくらい事業が伸びていれば⾚字を許容しても投資できるか ● どのKPIが伸びれば売上/利益が上がるのか ● コストは全体でどれくらいが適切で、何にどれくらい使うのか

Slide 69

Slide 69 text

© 2012-2024 BASE, Inc. 69 どうやって事業責任者になるのか事業全体を考える時にどこから取り掛かるか、選択肢は無数にありますが、リソースから考える⽅が⾃然だと感じています。この機能を作るには、この⼈数‧ケイパビリティだと、どれくらいの期間がかかりそう、という考え⽅です。出来上がりのトップラインから必要なリソースを考えるのは難易度が⾼いと感じています。これならできるという⾁体的な感覚を持つのが難しいからです。⼈⽉の神話が指し⽰すように、リソースというのは頭数のことではありません。実際にこれをやるにはどれくらいのリソースがかかるかの解像度が⾼くないと、適切な事業の計画やロードマップを引くことができません。エンジニア経験のあるプロダクトマネージャーはクオリティとコストの最適解を導き出す上で有利です。どうしたらビジネス上の要求に耐えうるものをビジネス上必要なタイミングでデリバリーできるかを解像度⾼くエンジニアと共に考えられるのは強みでしかないです。いくら考えても費⽤対効果合うか合わないかわからないというときは、とりあえず⾃分で作るところから始めるというウルトラCも。開発リソースを起点にビジネスモデルを考えられる強み

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

© 2012-2024 BASE, Inc. 72 警鐘再掲:⽣き残ったスタートアップは顧客に認められるために死に物狂いでやってきた⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、ユーザーに認められるためにできることを死に物狂いでやってきました。やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。⽣き残るために結果としてアジャイル的なことをやるしかなかったとも⾔えると思います。プロダクトを作って、それを世に解き放ち、使われなければピボットをし、やっとPMFしたプロダクト名が社名になる、そんなこともよくある話です。⽂字通り「全員でアジャイルに取り組んだ経験があること」それがWebサービスのビジネスモデルで上場できるようになったスタートアップの強みだと考えます。

Slide 73

Slide 73 text

© 2012-2024 BASE, Inc. 73 警鐘再掲:⽣き残ったスタートアップは顧客に認められるために死に物狂いでやってきた⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、ユーザーに認められるためにできることを死に物狂いでやってきました。やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。⽣き残るために結果としてアジャイル的なことをやるしかなかったとも⾔えると思います。プロダクトを作って、それを世に解き放ち、使われなければピボットをし、やっとPMFしたプロダクト名が社名になる、そんなこともよくある話です。⽂字通り「全員でアジャイルに取り組んだ経験があること」それがWebサービスのビジネスモデルで上場できるようになったスタートアップの強みだと考えます。この状態を維持し続けるのは難易度が⾼いのかも

Slide 74

Slide 74 text

© 2012-2024 BASE, Inc. 74 警鐘 ● PMFすると、1つ1つの施策の良し悪しが数字で出にくくなる（勝⼿に伸びていくから） ● PMFすると、（勝⼿に伸びていくから）決定的な失敗がしにくくなり、健全にPDCAが回らない ● PMFすると、⼈が増えてマネジメントコストが増える ● PMFすると、⼈が増えて分業体制になりがち ● 分業体制になるとわけわからなくなりがち PMFしてしまうとアジャイル的な強みを忘れてしまいがち

Slide 75

Slide 75 text

Slide 76

Slide 76 text

© 2012-2024 BASE, Inc. 76 警鐘事業責任者としては強⼒なビジネスモデルを作りたいけど難しい。辞めてから気づきましたが、SIerのビジネスモデルは偉⼤です。シンプルで再現性のあるビジネスモデルはそう作れません。次々と良いプロダクトが世の中に出てくるので、同じことをしていたらプロダクトの成⻑は鈍化します。常に競合プロダクトと違いを作り続けていく必要があります。もちろん波に乗っている事業会社を次々に転職していけば⾷っていけるだろうけどそれって虚しいかも。⽣殺与奪の権を⼈に渡さず、⾃分の⼈⽣のオールを持ちたいです。事業が作れるようになれば⾃分で環境や状況を変えられます。専⾨分野だけにコミットしたいのであれば受託開発含めた強⼒な事業モデルのある会社で働くべきだと思います。専⾨職が専⾨分野だけ考えていれば成り⽴つほど強⼒なビジネスモデルは作れない

Slide 77

Slide 77 text

© 2012-2024 BASE, Inc. 77 警鐘これはポジショントークですが、⼀つプロダクトが成功して上場した会社で次の成⻑を作るのは⾯⽩いです。上場後会社の次の成⻑を作るのとかおもしろいと思います＜上場企業で次の事業を作るメリット＞ ● 売上基盤があるので資⾦調達にかけるリソースを省⼒化できる ● すでにいる優秀な⼈材の協⼒が得られる ● 採⽤等で既存事業のブランディングに乗っかれる ● 既存顧客を活⽤した横展開も狙えてより⼤きなビジネスを作るチャンスがある ● 社内に新しい⾵を吹き込めるパラメーターは増えるものの、プロダクトを通して事業を伸ばすことに集中できます。 PMF後もアジャイルな事業の作り⽅を維持できれば、それ⾃体が競争優位になり得ると考えます。上場後会社の次の成⻑を作れるというのは、希少性の⾼いスキルだと考えます。

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

© 2012-2024 BASE, Inc. 81 まとめ⻑く続く偉⼤なプロダクトを作るために⼆律背反に挑んでいる ● ユーザーに使われてかつ儲かる ● 慈善事業にならずイビルにもならない ● 短期で成果を出し中⻑期でも成果を出す偉⼤なプロダクトを作るには時間がかかるので⻑く向き合うための⼯夫も必要 ● 投資を引き出すには期待に応え続けないといけない ● 単⼀プロダクトで投資を引き出すだけの成⻑を⻑い時間続けるのは難しい ● プロダクトの成⻑期は案外短く、どのタイミングでも投⼊したリソースだけ成⻑するとも限らない ● ⻑期の投資の蓋然性の説明できなくてもとにかく続けるために、リソースの付け替え等も必要 Webサービスを作る私たちは難易度の⾼い問いに挑んでいる

Slide 82

Slide 82 text

© 2012-2024 BASE, Inc. 82 まとめ永遠に伸びるサービスはないしそれだけで勝ち切れるサービスもありません。第⼆、第三の成⻑エンジンは必須です。より多くのメンバーが事業成⻑を⾃分事にできる組織を作りましょう。事業責任者になれ！は⾔い過ぎにしても事業への⽬線を無くしてはいけません。「経営とエンジニアの板挟みになる」みたいな⾔葉をこの世から消して⾏きたいです。事業責任者になれ！は⾔い過ぎにしても少しでも領域を広げることが有意義だと思ってもらえると嬉しいです。 Webサービスを作る事業会社は事業を作り続けないといけない

Slide 83

Slide 83 text

© 2012-2024 BASE, Inc. 83 まとめ受託開発全盛時代エンジニア35歳定年説がまことしやかに囁かれ、プログラマーキャリアからマネジメントやSEと呼ばれるものに変化することが求められた時代プロダクト開発レイヤーで付加価値がつかないとされ、プロダクトがビジネスの源泉でなかった時代エンジニアファースト時代エンジニアさえいれば全ての困難を解決してくれるという思考停⽌の時代プロダクトがビジネスの源泉になりプロダクト開発レイヤーの重要性には気が付かれるもビジネスモデルの解像度が低くエンジニア頼みの時代全員でアジャイル時代事業開発とプロダクト開発を切れ⽬なく全員で回し全員で乗り越える時代へ相互⼲渉が起こり連続的に成⻑を続けられる時代へプロダクトマネジメントが分かることが標準装備の時代へ時代を前に進めたい(時代分けは諸説あり)

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

© 2012-2024 BASE, Inc. 86 まとめ実はWebサービスの開発というのは、ビジネスモデルの確⽴に関わりやすい事業です。少⼈数で試⾏錯誤できるからのがいいところ。⼈が増えたら試⾏錯誤のコストは指数関数的に上がります。 PMFしてから呼ばれる⼈になるな！PMFを作り出せる⼈になろう！事業とプロダクトが成⻑させやすいような約束を作れる⼈になろう。私は絶対に⾔い訳をしたくない性格なので、⾃分ができるをことを拡⼤し続けてきました。この発表は私の履歴書です。 Webサービスを作り出し、維持し、拡⼤していくことの困難が付きまといます。それを理解したWebサービスを作っていきましょう。みんなビジネスモデルを作れる⼈になろうな

Slide 87

Slide 87 text

Slide 88

Slide 88 text