$30 off During Our Annual Pro Sale. View Details »

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

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

Webサービスを作る難しさを受託開発との比較で浮き彫りにし、その上でWebサービスをうまく作る方法としてプロダクト開発者が事業責任者になることを推奨する発表です。

KEITA YANAGAWA

June 22, 2024
Tweet

More Decks by KEITA YANAGAWA

Other Decks in Technology

Transcript

  1. © 2012-2024 BASE, Inc. 2 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ

    • どうやって事業責任者になるのか • 警鐘:Webサービスの会社なのに受託的になっていないか? • まとめ:社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
  2. © 2012-2024 BASE, Inc. 4 ⾃⼰紹介 名前 柳川慶太(@gimupop) 所属 BASE株式会社

    BASE BANK Division 事業責任者 職歴 エンジニア → PdM → 事業責任者 SIer → Web広告 → BASE 嫌いな⾔葉 ビジネス側/プロダクト側 ミッション 誰もが⾃分のやりたいことをやれる⼒を⾝につけられる世界を実現すること 脳筋プロダクト開発者の⾃⼰紹介です
  3. © 2012-2024 BASE, Inc. 7 ⾃⼰紹介 BASEグループの新規事業として、SMB(Small and Medium Business:中⼩規模の事業者)向けの

    ⾦融事業の⽴ち上げ‧グロース、グループ内横展開をしています。 新規事業の事業責任者してます マーチャント向け マーチャント向け⾦融サービス マーチャント向けに ⾦融サービスを提供するチーム
  4. © 2012-2024 BASE, Inc. 13 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ

    • どうやって事業責任者になるのか • 警鐘:Webサービスの会社なのに受託的になっていないか? • まとめ:社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
  5. © 2012-2024 BASE, Inc. 15 SIerと⾃社Webサービスおける開発の違い Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル

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

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  7. © 2012-2024 BASE, Inc. 17 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  8. © 2012-2024 BASE, Inc. 18 ①作ってもお⾦がもらえるか分からない Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル

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

    顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー お⾦を⽀払うと約束した開発依頼企業 (不特定の)サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社(調達した資⾦からの捻出) (サービスが使われれば)サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者 ⾃社Webサービスは 頑張って開発しても 使われるか分からない!
  10. © 2012-2024 BASE, Inc. 20 Webサービスを作るのはなぜ難しいか 作ったプロダクトが使われる約束はどこにもない 先⾏投資してプロダクトを作り、使われれば対価がもらえるが、使われる約束はどこにもありません。 Webサービスは先⾏してプロダクトを作り、その機能提供の対価としてユーザーからお⾦をいただくビジネスモデルです。 ポイント1:ビジネスモデルの発明からしないといけない

    インプットよりアウトカムが⼤きいビジネスモデルを作らないとビジネスとして成⽴しない ポイント2:ビジネスモデルは陳腐化する ⼀度ビジネスモデルができても、よほど優れたものでない限り他社に模倣され、陳腐化に向かっていく ポイント3:決められた期間で決められた収益を出す必要がある 約束の中⾝を知った上で、約束を守れる正解を⾒つける必要がある ①作ってもお⾦がもらえるか分からない
  11. © 2012-2024 BASE, Inc. 22 Webサービスを作るのはなぜ難しいか ポイント2:ビジネスモデルは陳腐化する ⼀度ビジネスモデルを確⽴しても、状況は刻々と変化していきます。 状況の変化に適応できないと、ビジネスモデルは陳腐化に向かっていきます。 <変化のパラメータ例>

    • 維持に必要な費⽤ • ユーザーの流⼊数 • ユーザーの流出数 • ユーザーの獲得コスト • ユーザーのLTV • ライバルの参⼊  etc… ⽇々パラメータは変動していき、気がついた時にはビジネスモデルは陳腐化していることもあるので、常に点検‧修正が必要。 ①作ってもお⾦がもらえるか分からない
  12. © 2012-2024 BASE, Inc. 24 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  13. © 2012-2024 BASE, Inc. 25 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  14. © 2012-2024 BASE, Inc. 26 ②ユーザーが⾒えない かつ 要望が曖昧 Webサービスを作るのはなぜ難しいか SIer

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

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

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  17. © 2012-2024 BASE, Inc. 30 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  18. © 2012-2024 BASE, Inc. 31 ③⾃分たちで開発費⽤を負担しなければならない Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル

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

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

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  21. © 2012-2024 BASE, Inc. 35 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧

    ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
  22. © 2012-2024 BASE, Inc. 36 ④開発費⽤とサービスの対価を⽀払う主体が異なる Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル

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

    顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー (お⾦を⽀払うと約束した)開発依頼企業 (不特定の)サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社(調達した資⾦からの捻出) (サービスが使われれば)サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者 = ≠ 開発費⽤を出す主体と サービスの対価を ⽀払う主体が異なる
  24. © 2012-2024 BASE, Inc. 38 Webサービスを作るのはなぜ難しいか 開発費⽤のソースを出す主体、つまり資⾦調達元は、 スタートアップであればおそらくVCなどの株主であることが多いでしょう。 安定的な収益を出しているプロダクトがある会社であれば、 ⾃社の経営陣がある意味で資⾦調達元(新規事業の予算を承認する主体)となります。

    資⾦調達元を向いてプロダクトを作ったらいいか、 利⽤してくれるユーザーを⾒てプロダクトを作ったらいいか混乱しがちです。 もちろん利⽤してくれるユーザーを⾒るべきなのですが、かといって資⾦調達元を蔑ろにしては開発が継続できません。 信頼関係を築いたり、信⽤してもらうための説明が求められたり、中間的な数字成果を出すなど⼯夫が必要になります。 スクラムとかアジャイルは⼤体この問題を解決するための⼿法だという理解。 ④開発費⽤とサービスの対価を⽀払う主体が異なる
  25. © 2012-2024 BASE, Inc. 41 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ

    • どうやって事業責任者になるのか • 警鐘:Webサービスの会社なのに受託的になっていないか? • まとめ:社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
  26. © 2012-2024 BASE, Inc. 46 エンジニア時代の関わる範囲 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 主担当として実務を担う範囲 主担当は別だが関わる範囲
  27. © 2012-2024 BASE, Inc. 47 プロダクトマネージャー時代の関わる範囲 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 主担当として実務を担う範囲 主担当は別だが関わる範囲
  28. © 2012-2024 BASE, Inc. 48 事業責任者として現在関わる範囲 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 主担当として実務を担う範囲 主担当は別だが関わる範囲
  29. © 2012-2024 BASE, Inc. 52 狭義のプロダクト開発だけでPDCAを回さない 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 狭義のプロダクト開発で PDCAを回す “縛りプレイ”をしない
  30. © 2012-2024 BASE, Inc. 53 事業作りの全てでPDCAを回す 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする
  31. © 2012-2024 BASE, Inc. 54 環境の変化に合わせてPMFし続けるために、前提条件から⾒直す 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 前提条件である市場は プロダクトと フィットし続けて いるか? この成⻑⾓度で いいのか? もっと成⻑⾓度を 上げられないか? 獲得する予算は これでいいのか? チームの ⼈数と構成は これでいいのか?
  32. © 2012-2024 BASE, Inc. 56 困難を乗り越えるには事業責任者になれ ⽣き残ったスタートアップはユーザーに認められるために死に物狂いでやってきた ⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、 ユーザーに認められるためにできることを死に物狂いでやってきました。 やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。

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

    • どうやって事業責任者になるのか • 警鐘:Webサービスの会社なのに受託的になっていないか? • まとめ:社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
  34. © 2012-2024 BASE, Inc. 63 どうやって事業責任者になるのか どうやって事業責任者になるのか コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 前提を決める⽅向に範囲を広げていきます。個⼈的には、事業計画を書くことがターニングポイントになりました。
  35. © 2012-2024 BASE, Inc. 64 どうやって事業責任者になるのか どうやって事業責任者になるのか コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 前提を決める⽅向に範囲を広げていきます。個⼈的には、事業計画を書くことがターニングポイントになりました。 役割を広げていく
  36. © 2012-2024 BASE, Inc. 65 どうやって事業責任者になるのか これは⾔い換えると ⾃分のお給料が発⽣するまでの過程を考えたことがありますか? ⾃分の会社のビジネスモデルが理解できているか という意味です

    ビジネスモデル上どうやったら売上ができて、それを実現するには何が⾜りていなくて、そのためには⾃分は何ができるか。 シンプルなんですが、ここを把握してコミットするのが給与を上げるコツです! 事業が儲からないと給料は上がらないですし、事業が儲からないと事業継続ができなくなる可能性もあります。 専⾨職の枠の範疇だけで考えていると案外忘れがちなポイントだったりします。
  37. © 2012-2024 BASE, Inc. 66 どうやって事業責任者になるのか お給料が発⽣するためには売上が⽴つ必要があります。売上が⽴つには何がどうなればいいのでしょうか。 これを⼀番理解するためには事業計画を書いてみるのが⼀番です! これができると⾃分が出すべき価値が⾒えてくるかも知れません。 事業計画を書いてビジネスモデルを理解してみよう

    事業数字を分解して 理解する 実際に計画を 作ってみる ミクロとマクロで 作った計画を⾒直す ⽴てた計画に対して 結果を振り返る 僕はこのようなステップで事業計画を作っていますが、 今回はその中でも「事業数字の分解して理解する」「実際に計画を作ってみる」の部分について話します。 事業計画の作り⽅
  38. © 2012-2024 BASE, Inc. 68 どうやって事業責任者になるのか KPIを分解したら、年単位の事業計画を⽴ててみましょう。短くても1年分、できれば3年分、5年分の計画を作ってみましょう! 実際に計画を作ってみる 数年後の事業あるべき姿 どれくらい利益が出れば黒字化するか、その時に費⽤はどうなるか、このあたりの感覚が持てると解像度が⼀気に上がります。

    数年後の事業のあるべき姿を実現するために、⾃分がどうアクションできるかも思考実験してみましょう。 売上/利益計画 KPI分解/計画 コスト分解/計画 • いつまでに黒字化すれば事業は継続できるのか • どれくらい事業が伸びていれば⾚字を許容しても投資できるか • どのKPIが伸びれば売上/利益が上がるのか • コストは全体でどれくらいが適切で、何にどれくらい使うのか
  39. © 2012-2024 BASE, Inc. 69 どうやって事業責任者になるのか 事業全体を考える時にどこから取り掛かるか、選択肢は無数にありますが、リソースから考える⽅が⾃然だと感じています。 この機能を作るには、この⼈数‧ケイパビリティだと、どれくらいの期間がかかりそう、という考え⽅です。 出来上がりのトップラインから必要なリソースを考えるのは難易度が⾼いと感じています。 これならできるという⾁体的な感覚を持つのが難しいからです。

    ⼈⽉の神話が指し⽰すように、リソースというのは頭数のことではありません。 実際にこれをやるにはどれくらいのリソースがかかるかの解像度が⾼くないと、 適切な事業の計画やロードマップを引くことができません。 エンジニア経験のあるプロダクトマネージャーはクオリティとコストの最適解を導き出す上で有利です。 どうしたらビジネス上の要求に耐えうるものをビジネス上必要なタイミングでデリバリーできるかを解像度⾼くエンジニアと共 に考えられるのは強みでしかないです。 いくら考えても費⽤対効果合うか合わないかわからないというときは、 とりあえず⾃分で作るところから始めるというウルトラCも。 開発リソースを起点にビジネスモデルを考えられる強み
  40. © 2012-2024 BASE, Inc. 71 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ

    • どうやって事業責任者になるのか • 警鐘:Webサービスの会社なのに受託的になっていないか? • まとめ:社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
  41. © 2012-2024 BASE, Inc. 72 警鐘 再掲:⽣き残ったスタートアップは顧客に認められるために死に物狂いでやってきた ⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、 ユーザーに認められるためにできることを死に物狂いでやってきました。 やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。

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

    ⽣き残るために結果としてアジャイル的なことをやるしかなかったとも⾔えると思います。 プロダクトを作って、それを世に解き放ち、使われなければピボットをし、 やっとPMFしたプロダクト名が社名になる、そんなこともよくある話です。 ⽂字通り 「全員でアジャイルに取り組んだ経験があること」 それがWebサービスのビジネスモデルで上場できるようになったスタートアップの強みだと考えます。 この状態を維持し続けるのは 難易度が⾼いのかも
  43. © 2012-2024 BASE, Inc. 74 警鐘 • PMFすると、1つ1つの施策の良し悪しが数字で出にくくなる(勝⼿に伸びていくから) • PMFすると、(勝⼿に伸びていくから)決定的な失敗がしにくくなり、健全にPDCAが回らない

    • PMFすると、⼈が増えてマネジメントコストが増える • PMFすると、⼈が増えて分業体制になりがち • 分業体制になるとわけわからなくなりがち PMFしてしまうとアジャイル的な強みを忘れてしまいがち
  44. © 2012-2024 BASE, Inc. 76 警鐘 事業責任者としては強⼒なビジネスモデルを作りたいけど難しい。 辞めてから気づきましたが、SIerのビジネスモデルは偉⼤です。 シンプルで再現性のあるビジネスモデルはそう作れません。 次々と良いプロダクトが世の中に出てくるので、同じことをしていたらプロダクトの成⻑は鈍化します。

    常に競合プロダクトと違いを作り続けていく必要があります。 もちろん波に乗っている事業会社を次々に転職していけば⾷っていけるだろうけどそれって虚しいかも。 ⽣殺与奪の権を⼈に渡さず、⾃分の⼈⽣のオールを持ちたいです。 事業が作れるようになれば⾃分で環境や状況を変えられます。 専⾨分野だけにコミットしたいのであれば受託開発含めた強⼒な事業モデルのある会社で働くべきだと思います。 専⾨職が専⾨分野だけ考えていれば成り⽴つほど強⼒なビジネスモデルは作れない
  45. © 2012-2024 BASE, Inc. 77 警鐘 これはポジショントークですが、⼀つプロダクトが成功して上場した会社で次の成⻑を作るのは⾯⽩いです。 上場後会社の次の成⻑を作るのとかおもしろいと思います <上場企業で次の事業を作るメリット> •

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

    • どうやって事業責任者になるのか • 警鐘:Webサービスの会社なのに受託的になっていないか? • まとめ:社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
  47. © 2012-2024 BASE, Inc. 81 まとめ ⻑く続く偉⼤なプロダクトを作るために⼆律背反に挑んでいる • ユーザーに使われてかつ儲かる •

    慈善事業にならずイビルにもならない • 短期で成果を出し中⻑期でも成果を出す 偉⼤なプロダクトを作るには時間がかかるので⻑く向き合うための⼯夫も必要 • 投資を引き出すには期待に応え続けないといけない • 単⼀プロダクトで投資を引き出すだけの成⻑を⻑い時間続けるのは難しい • プロダクトの成⻑期は案外短く、どのタイミングでも投⼊したリソースだけ成⻑するとも限らない • ⻑期の投資の蓋然性の説明できなくてもとにかく続けるために、リソースの付け替え等も必要 Webサービスを作る私たちは難易度の⾼い問いに挑んでいる
  48. © 2012-2024 BASE, Inc. 82 まとめ 永遠に伸びるサービスはないしそれだけで勝ち切れるサービスもありません。 第⼆、第三の成⻑エンジンは必須です。 より多くのメンバーが事業成⻑を⾃分事にできる組織を作りましょう。 事業責任者になれ!は⾔い過ぎにしても事業への⽬線を無くしてはいけません。

    「経営とエンジニアの板挟みになる」みたいな⾔葉をこの世から消して⾏きたいです。 事業責任者になれ!は⾔い過ぎにしても少しでも領域を広げることが有意義だと思ってもらえると嬉しいです。 Webサービスを作る事業会社は事業を作り続けないといけない
  49. © 2012-2024 BASE, Inc. 83 まとめ 受託開発全盛時代 エンジニア35歳定年説がまことしやかに囁かれ、 プログラマーキャリアからマネジメントやSEと呼ばれるものに変化することが求められた時代 プロダクト開発レイヤーで付加価値がつかないとされ、プロダクトがビジネスの源泉でなかった時代

    エンジニアファースト時代 エンジニアさえいれば全ての困難を解決してくれるという思考停⽌の時代 プロダクトがビジネスの源泉になりプロダクト開発レイヤーの重要性には気が付かれるも ビジネスモデルの解像度が低くエンジニア頼みの時代 全員でアジャイル時代 事業開発とプロダクト開発を切れ⽬なく全員で回し全員で乗り越える時代へ 相互⼲渉が起こり連続的に成⻑を続けられる時代へ プロダクトマネジメントが分かることが標準装備の時代へ 時代を前に進めたい(時代分けは諸説あり)
  50. © 2012-2024 BASE, Inc. 84 ビジネスとプロダクトはどこまで⾏っても密結合 まとめ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする
  51. © 2012-2024 BASE, Inc. 85 縛りプレイして舐めプはもうやめよう まとめ コアユーザーを 決める 事業計画を作る

    必要なお⾦を 集める チームを作る 要求定義をする 実装する グロースする グロースする 全てで PDCAを回す
  52. © 2012-2024 BASE, Inc. 86 まとめ 実はWebサービスの開発というのは、ビジネスモデルの確⽴に関わりやすい事業です。 少⼈数で試⾏錯誤できるからのがいいところ。 ⼈が増えたら試⾏錯誤のコストは指数関数的に上がります。 PMFしてから呼ばれる⼈になるな!PMFを作り出せる⼈になろう!

    事業とプロダクトが成⻑させやすいような約束を作れる⼈になろう。 私は絶対に⾔い訳をしたくない性格なので、⾃分ができるをことを拡⼤し続けてきました。 この発表は私の履歴書です。 Webサービスを作り出し、維持し、拡⼤していくことの困難が付きまといます。 それを理解したWebサービスを作っていきましょう。 みんなビジネスモデルを作れる⼈になろうな