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

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

Transcript

1. © 2012-2024 BASE, Inc. 1 私たちはなぜ事業責任者にならないといけないのか ~Webサービスを作る茨の道~ BASE株式会社 BASE BANK Division Manager 柳川慶太 2024年6⽉22⽇
2. © 2012-2024 BASE, Inc. 2 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ • どうやって事業責任者になるのか • 警鐘：Webサービスの会社なのに受託的になっていないか？ • まとめ：社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
3. © 2012-2024 BASE, Inc. 3 ⾃⼰紹介
4. © 2012-2024 BASE, Inc. 4 ⾃⼰紹介 名前 柳川慶太(@gimupop) 所属 BASE株式会社 BASE BANK Division 事業責任者 職歴 エンジニア → PdM → 事業責任者 SIer → Web広告 → BASE 嫌いな⾔葉 ビジネス側/プロダクト側 ミッション 誰もが⾃分のやりたいことをやれる⼒を⾝につけられる世界を実現すること 脳筋プロダクト開発者の⾃⼰紹介です
5. © 2012-2024 BASE, Inc. 5 ⾃⼰紹介 最近インスタ更新頑張ってるんでフォローください
6. © 2012-2024 BASE, Inc. 6 ⾃⼰紹介 誰でもかんたんにネットショップが開ける「BASE」を提供しています。 開設数は220万を超え、ネットショップ開設実績は6年連続No.1となっています。 Webサービスの開発運営をしています
7. © 2012-2024 BASE, Inc. 7 ⾃⼰紹介 BASEグループの新規事業として、SMB（Small and Medium Business：中⼩規模の事業者）向けの ⾦融事業の⽴ち上げ‧グロース、グループ内横展開をしています。 新規事業の事業責任者してます マーチャント向け マーチャント向け⾦融サービス マーチャント向けに ⾦融サービスを提供するチーム
8. © 2012-2024 BASE, Inc. 8 いきなりの主張 プロダクトマネージャーは事業責任者になれ！
9. © 2012-2024 BASE, Inc. 9 主張の理由 Webサービスを作るのは難しい 縛りプレイをしている場合じゃない
10. © 2012-2024 BASE, Inc. 10 主張の理由 マネージングアップの話というよりは ⾃ら構造を作れる⼈間になれ みたいな話です だから脳筋です
11. © 2012-2024 BASE, Inc. 11 主張の理由 スタートアップにおける新規事業には2つの⽴ち上がり⽅があると思います。 スタートアップにおける新規事業のあり⽅と本⽇のお話 経験したのは後者ですが、両者に共通点もあるのではないかと思います いずれの場合にも当てはまるのではないかという点についてお話しします。 • 1つ⽬のプロダクトリリース • すでに⼀定のPMFを完了した企業の2つ⽬プロダクトリリース
12. © 2012-2024 BASE, Inc. 12 Webサービスを作るのは なぜ難しいか
13. © 2012-2024 BASE, Inc. 13 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ • どうやって事業責任者になるのか • 警鐘：Webサービスの会社なのに受託的になっていないか？ • まとめ：社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
14. © 2012-2024 BASE, Inc. 14 Webサービスを運営する難しさをSIerとの⽐較で考える SIerからWebサービスを運営する会社に転職経験があります 楽しいんだけど何か⼤変だなと思いました 何が⼤変なのかをSIerとの⽐較で語ります
15. © 2012-2024 BASE, Inc. 15 SIerと⾃社Webサービスおける開発の違い Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者
16. © 2012-2024 BASE, Inc. 16 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
17. © 2012-2024 BASE, Inc. 17 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
18. © 2012-2024 BASE, Inc. 18 ①作ってもお⾦がもらえるか分からない Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者
19. © 2012-2024 BASE, Inc. 19 ①作ってもお⾦がもらえるか分からない Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー お⾦を⽀払うと約束した開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者 ⾃社Webサービスは 頑張って開発しても 使われるか分からない！
20. © 2012-2024 BASE, Inc. 20 Webサービスを作るのはなぜ難しいか 作ったプロダクトが使われる約束はどこにもない 先⾏投資してプロダクトを作り、使われれば対価がもらえるが、使われる約束はどこにもありません。 Webサービスは先⾏してプロダクトを作り、その機能提供の対価としてユーザーからお⾦をいただくビジネスモデルです。 ポイント1：ビジネスモデルの発明からしないといけない インプットよりアウトカムが⼤きいビジネスモデルを作らないとビジネスとして成⽴しない ポイント2：ビジネスモデルは陳腐化する ⼀度ビジネスモデルができても、よほど優れたものでない限り他社に模倣され、陳腐化に向かっていく ポイント3：決められた期間で決められた収益を出す必要がある 約束の中⾝を知った上で、約束を守れる正解を⾒つける必要がある ①作ってもお⾦がもらえるか分からない
21. © 2012-2024 BASE, Inc. 21 Webサービスを作るのはなぜ難しいか ポイント1：ビジネスモデルの発明からしないといけない これはあまりにも当たり前なことですが、 インプットよりアウトカムが⼤きいビジネスモデルを作らないとビジネスとして成⽴しません。 いいプロダクトを作るのは⼤事だけど、かけたリソースに⾒合う成果が出たかどうかには常に向き合わないといけない。 ①作ってもお⾦がもらえるか分からない インプット：どれくらいのリソース（ヒト‧モノ‧カネ）を使うか アウトカム：どれくらいの⼈が使ってくれるか、どれくらい儲かるか
22. © 2012-2024 BASE, Inc. 22 Webサービスを作るのはなぜ難しいか ポイント2：ビジネスモデルは陳腐化する ⼀度ビジネスモデルを確⽴しても、状況は刻々と変化していきます。 状況の変化に適応できないと、ビジネスモデルは陳腐化に向かっていきます。 ＜変化のパラメータ例＞ • 維持に必要な費⽤ • ユーザーの流⼊数 • ユーザーの流出数 • ユーザーの獲得コスト • ユーザーのLTV • ライバルの参⼊  etc… ⽇々パラメータは変動していき、気がついた時にはビジネスモデルは陳腐化していることもあるので、常に点検‧修正が必要。 ①作ってもお⾦がもらえるか分からない
23. © 2012-2024 BASE, Inc. 23 Webサービスを作るのはなぜ難しいか ポイント3：決められた期間できめられた収益を出す必要がある 会社の事業活動には投資⽅針がつきもの。 例えば、スタートアップも上場会社も、株主との約束があります。 どれくらい⾚字を掘っていいのか、どれくらいトップラインを伸ばせばいいのか、 諸条件によって正解は異なります。 短期で正しくても、正解が⻑期すぎても意味がありません。 ジャスト正しいを探していきましょう。 ①作ってもお⾦がもらえるか分からない
24. © 2012-2024 BASE, Inc. 24 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
25. © 2012-2024 BASE, Inc. 25 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
26. © 2012-2024 BASE, Inc. 26 ②ユーザーが⾒えない かつ 要望が曖昧 Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者
27. © 2012-2024 BASE, Inc. 27 ②ユーザーが⾒えない かつ 要望が曖昧 Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者 ユーザーが誰になるか分からないから 要望が明確に分からない
28. © 2012-2024 BASE, Inc. 28 Webサービスを作るのはなぜ難しいか ユーザーインタビュー等を通した⾒込み顧客はいるかもしれませんが、 いざサービスをリリースしてみたら、その⼈たちが契約してお⾦を払ってくれるとは限りません。 Webサービス開発は、SIの開発のようにバイネームの顧客はいません。 そもそも顧客がいない可能性もあり、それを常に頭の⽚隅におかないといけません。 存在するかしないか分からない顧客と需要を想像しながら、プロダクトを作らなければならないのです。 ②ユーザーが⾒えない かつ 要望が曖昧
29. © 2012-2024 BASE, Inc. 29 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
30. © 2012-2024 BASE, Inc. 30 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
31. © 2012-2024 BASE, Inc. 31 ③⾃分たちで開発費⽤を負担しなければならない Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者
32. © 2012-2024 BASE, Inc. 32 ③⾃分たちで開発費⽤を負担しなければならない Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者 作っても使われるか 分からないにも関わらず ⾃分たちで 開発費⽤を負担
33. © 2012-2024 BASE, Inc. 33 Webサービスを作るのはなぜ難しいか 投資的な考え⽅が常に必要になります。 最終的にはサービス利⽤者からお⾦をもらうつもりでいますが、短期では⾃分たちで開発費⽤の負担が必要です。 では、いくら投資して、いつまでに回収できればいいのでしょうか。 リリース初期は、ユーザーを集めるために戦略的に⼿数料無料などの施策を打つこともありますが、 そうすると開発費⽤の回収まで時間はさらに開き、考えなければならないことは増えます。 ③⾃分たちで開発費⽤を負担しなければならない
34. © 2012-2024 BASE, Inc. 34 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
35. © 2012-2024 BASE, Inc. 35 Webサービスを作るのはなぜ難しいか ①作ってもお⾦がもらえるか分からない ②ユーザーが⾒えない かつ 要望が曖昧 ③⾃分たちで開発費⽤を負担しなければならない ④開発費⽤とサービスの対価を⽀払う主体が異なる 特に⼤変な違いピックアップ
36. © 2012-2024 BASE, Inc. 36 ④開発費⽤とサービスの対価を⽀払う主体が異なる Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者
37. © 2012-2024 BASE, Inc. 37 ④開発費⽤とサービスの対価を⽀払う主体が異なる Webサービスを作るのはなぜ難しいか SIer Webサービス ビジネスモデル 顧客から対価をもらい ソフトウェアを開発する 先⾏投資してプロダクトを作り 使われれば対価がもらえる 顧客/ユーザー （お⾦を⽀払うと約束した）開発依頼企業 （不特定の）サービス利⽤者 ニーズの把握⽅法 開発依頼企業からの提⽰ 提⽰されない 開発費⽤のソース 開発依頼企業 ⾃社（調達した資⾦からの捻出） （サービスが使われれば）サービス利⽤者 作ったソフトウェアの 対価を⽀払う⼈ 開発依頼企業 サービス利⽤者 ＝ ≠ 開発費⽤を出す主体と サービスの対価を ⽀払う主体が異なる
38. © 2012-2024 BASE, Inc. 38 Webサービスを作るのはなぜ難しいか 開発費⽤のソースを出す主体、つまり資⾦調達元は、 スタートアップであればおそらくVCなどの株主であることが多いでしょう。 安定的な収益を出しているプロダクトがある会社であれば、 ⾃社の経営陣がある意味で資⾦調達元（新規事業の予算を承認する主体）となります。 資⾦調達元を向いてプロダクトを作ったらいいか、 利⽤してくれるユーザーを⾒てプロダクトを作ったらいいか混乱しがちです。 もちろん利⽤してくれるユーザーを⾒るべきなのですが、かといって資⾦調達元を蔑ろにしては開発が継続できません。 信頼関係を築いたり、信⽤してもらうための説明が求められたり、中間的な数字成果を出すなど⼯夫が必要になります。 スクラムとかアジャイルは⼤体この問題を解決するための⼿法だという理解。 ④開発費⽤とサービスの対価を⽀払う主体が異なる
39. © 2012-2024 BASE, Inc. 39 Webサービスを作るのはなぜ難しいか Webサービス開発は全体的に成功の不確実性が⾼い！
40. © 2012-2024 BASE, Inc. 40 困難を乗り越えるには 事業責任者になれ
41. © 2012-2024 BASE, Inc. 41 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ • どうやって事業責任者になるのか • 警鐘：Webサービスの会社なのに受託的になっていないか？ • まとめ：社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
42. © 2012-2024 BASE, Inc. 42 困難を乗り越えるには事業責任者になれ ビジネスの前提条件とプロダクト開発の難しさ それぞれに不確実性がありそれぞれが⼲渉しうる ビジネスの前提条件が不確実 プロダクトとビジネスモデルが不可分 前章を受けてWebサービスが⽴ち向かう困難は何か
43. © 2012-2024 BASE, Inc. 43 困難を乗り越えるには事業責任者になれ ⾔われたものをそのまま作り上げるのがプロではない 「使われる かつ 儲かるプロダクトを作るプロ」 になる必要がある
44. © 2012-2024 BASE, Inc. 44 困難を乗り越えるには事業責任者になれ ユーザーに⾔われたものができても 商売として続かないと意味がない
45. © 2012-2024 BASE, Inc. 45 困難を乗り越えるには事業責任者になれ ここで 事業責任者になるまでの⾃分のキャリアパスと プロダクトに関わる範囲の変遷を紹介します
46. © 2012-2024 BASE, Inc. 46 エンジニア時代の関わる範囲 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 主担当として実務を担う範囲 主担当は別だが関わる範囲
47. © 2012-2024 BASE, Inc. 47 プロダクトマネージャー時代の関わる範囲 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 主担当として実務を担う範囲 主担当は別だが関わる範囲
48. © 2012-2024 BASE, Inc. 48 事業責任者として現在関わる範囲 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 主担当として実務を担う範囲 主担当は別だが関わる範囲
49. © 2012-2024 BASE, Inc. 49 困難を乗り越えるには事業責任者になれ 範囲を広げてわかったことは、どこまで範囲を広げても明確な確信を持って決断はできない、ということです。 これまで世の中になかったプロダクトを作る上では、 社⻑も役員もマネージャーもPdMもビジネス側もプロダクト側も、明確な答えが出せる場⾯ばかりではありません。 なんとなくの⽅向性のイメージとかはあるが、やり⽅についてはどうしても朝令暮改はありえます。 僕の場合、最近の⼝癖は 「わからないから⼀緒に考えてほしい」 「⼀緒に試⾏錯誤して試してほしい」 「50%くらいの確信度で話してる」 という感じです。 みんなわからないでやってる
50. © 2012-2024 BASE, Inc. 50 困難を乗り越えるには事業責任者になれ そもそものコアユーザー設定の部分もアジャイル的に改善していくべきです。 分からないことを認めて、少しずつ改善を積み上げていくしかありません。 分からないからトップダウンでウォーターフォール的に進めるのは無理 事業開発そのものもアジャイル的に進めていくべきです。 事業開発もプロダクト開発も、相互に影響しうるので別々にサイクルを回す必要もないのです。 アジャイルの⼿法をプロダクト開発者だけに留めておく理由はありません。
51. © 2012-2024 BASE, Inc. 51 狭義のプロダクト開発だけでPDCAを回さない 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする
52. © 2012-2024 BASE, Inc. 52 狭義のプロダクト開発だけでPDCAを回さない 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 狭義のプロダクト開発で PDCAを回す “縛りプレイ”をしない
53. © 2012-2024 BASE, Inc. 53 事業作りの全てでPDCAを回す 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする
54. © 2012-2024 BASE, Inc. 54 環境の変化に合わせてPMFし続けるために、前提条件から⾒直す 困難を乗り越えるには事業責任者になれ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 前提条件である市場は プロダクトと フィットし続けて いるか？ この成⻑⾓度で いいのか？ もっと成⻑⾓度を 上げられないか？ 獲得する予算は これでいいのか？ チームの ⼈数と構成は これでいいのか？
55. © 2012-2024 BASE, Inc. 55 困難を乗り越えるには事業責任者になれ 不確実性が⾼すぎる故に全てをアジャイルにやらざるを得ない 引⽤：アジャイルソフトウェア開発宣⾔
56. © 2012-2024 BASE, Inc. 56 困難を乗り越えるには事業責任者になれ ⽣き残ったスタートアップはユーザーに認められるために死に物狂いでやってきた ⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、 ユーザーに認められるためにできることを死に物狂いでやってきました。 やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。 ⽣き残るために結果としてアジャイル的なことをやるしかなかったとも⾔えると思います。 プロダクトを作って、それを世に解き放ち、使われなければピボットをし、 やっとPMFしたプロダクト名が社名になる、そんなこともよくある話です。 ⽂字通り 「全員でアジャイルに取り組んだ経験があること」 それがWebサービスのビジネスモデルで上場できるようになったスタートアップの強みだと考えます。
57. © 2012-2024 BASE, Inc. 57 困難を乗り越えるには事業責任者になれ アジャイルをプロダクト開発組織だけの 特別なものにしない
58. © 2012-2024 BASE, Inc. 58 どうやって 事業責任者になるのか
59. © 2012-2024 BASE, Inc. 59 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ • どうやって事業責任者になるのか • 警鐘：Webサービスの会社なのに受託的になっていないか？ • まとめ：社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
60. © 2012-2024 BASE, Inc. 60 どうやって事業責任者になるのか ここでは最初のプロダクト⽴ち上げというよりは ２つ⽬以降のプロダクト⽴ち上げの話を 想定して話します
61. © 2012-2024 BASE, Inc. 61 どうやって事業責任者になるのか そもそも事業責任者になるメリットは何
62. © 2012-2024 BASE, Inc. 62 どうやって事業責任者になるのか プロダクト開発は不確実性を孕むため、短期的な成果は⽰しづらいこともあります。 また、短期で良いプロダクトやチームを作るのは難しいです。 経営陣に対して都度成果について説明するのではなく、まるっと信頼してもらうのが解決策の1つだと思っています。 プロダクト開発を取り巻くパラメータの多さを考えると、できるだけ広い責任範囲をコントロールできる⽅が良いです。 任せてもらうスコープを広げて結果を出すため
63. © 2012-2024 BASE, Inc. 63 どうやって事業責任者になるのか どうやって事業責任者になるのか コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 前提を決める⽅向に範囲を広げていきます。個⼈的には、事業計画を書くことがターニングポイントになりました。
64. © 2012-2024 BASE, Inc. 64 どうやって事業責任者になるのか どうやって事業責任者になるのか コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする 前提を決める⽅向に範囲を広げていきます。個⼈的には、事業計画を書くことがターニングポイントになりました。 役割を広げていく
65. © 2012-2024 BASE, Inc. 65 どうやって事業責任者になるのか これは⾔い換えると ⾃分のお給料が発⽣するまでの過程を考えたことがありますか？ ⾃分の会社のビジネスモデルが理解できているか という意味です ビジネスモデル上どうやったら売上ができて、それを実現するには何が⾜りていなくて、そのためには⾃分は何ができるか。 シンプルなんですが、ここを把握してコミットするのが給与を上げるコツです！ 事業が儲からないと給料は上がらないですし、事業が儲からないと事業継続ができなくなる可能性もあります。 専⾨職の枠の範疇だけで考えていると案外忘れがちなポイントだったりします。
66. © 2012-2024 BASE, Inc. 66 どうやって事業責任者になるのか お給料が発⽣するためには売上が⽴つ必要があります。売上が⽴つには何がどうなればいいのでしょうか。 これを⼀番理解するためには事業計画を書いてみるのが⼀番です！ これができると⾃分が出すべき価値が⾒えてくるかも知れません。 事業計画を書いてビジネスモデルを理解してみよう 事業数字を分解して 理解する 実際に計画を 作ってみる ミクロとマクロで 作った計画を⾒直す ⽴てた計画に対して 結果を振り返る 僕はこのようなステップで事業計画を作っていますが、 今回はその中でも「事業数字の分解して理解する」「実際に計画を作ってみる」の部分について話します。 事業計画の作り⽅
67. © 2012-2024 BASE, Inc. 67 どうやって事業責任者になるのか 事業のKPI分解には実は正解はありません！ ひとつの事業でも時期だったり伸ばし⽅でKPIの切り⽅は変わります。実はKPIの分解の仕⽅はそのまま戦略です！ 事業数字を分解して理解する また、試みとしてKPIを今の⾃分の役割や役職からKPIを切ってみるのもありです！ エンジニアであれば、「今開発している機能がどのKPIにヒットするのか」とか、「開発速度が上がると何が変わるか」とか。 重視するKPI例 ユーザー数 単価 売上 利益
68. © 2012-2024 BASE, Inc. 68 どうやって事業責任者になるのか KPIを分解したら、年単位の事業計画を⽴ててみましょう。短くても1年分、できれば3年分、5年分の計画を作ってみましょう！ 実際に計画を作ってみる 数年後の事業あるべき姿 どれくらい利益が出れば黒字化するか、その時に費⽤はどうなるか、このあたりの感覚が持てると解像度が⼀気に上がります。 数年後の事業のあるべき姿を実現するために、⾃分がどうアクションできるかも思考実験してみましょう。 売上/利益計画 KPI分解/計画 コスト分解/計画 • いつまでに黒字化すれば事業は継続できるのか • どれくらい事業が伸びていれば⾚字を許容しても投資できるか • どのKPIが伸びれば売上/利益が上がるのか • コストは全体でどれくらいが適切で、何にどれくらい使うのか
69. © 2012-2024 BASE, Inc. 69 どうやって事業責任者になるのか 事業全体を考える時にどこから取り掛かるか、選択肢は無数にありますが、リソースから考える⽅が⾃然だと感じています。 この機能を作るには、この⼈数‧ケイパビリティだと、どれくらいの期間がかかりそう、という考え⽅です。 出来上がりのトップラインから必要なリソースを考えるのは難易度が⾼いと感じています。 これならできるという⾁体的な感覚を持つのが難しいからです。 ⼈⽉の神話が指し⽰すように、リソースというのは頭数のことではありません。 実際にこれをやるにはどれくらいのリソースがかかるかの解像度が⾼くないと、 適切な事業の計画やロードマップを引くことができません。 エンジニア経験のあるプロダクトマネージャーはクオリティとコストの最適解を導き出す上で有利です。 どうしたらビジネス上の要求に耐えうるものをビジネス上必要なタイミングでデリバリーできるかを解像度⾼くエンジニアと共 に考えられるのは強みでしかないです。 いくら考えても費⽤対効果合うか合わないかわからないというときは、 とりあえず⾃分で作るところから始めるというウルトラCも。 開発リソースを起点にビジネスモデルを考えられる強み
70. © 2012-2024 BASE, Inc. 70 警鐘
71. © 2012-2024 BASE, Inc. 71 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ • どうやって事業責任者になるのか • 警鐘：Webサービスの会社なのに受託的になっていないか？ • まとめ：社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
72. © 2012-2024 BASE, Inc. 72 警鐘 再掲:⽣き残ったスタートアップは顧客に認められるために死に物狂いでやってきた ⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、 ユーザーに認められるためにできることを死に物狂いでやってきました。 やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。 ⽣き残るために結果としてアジャイル的なことをやるしかなかったとも⾔えると思います。 プロダクトを作って、それを世に解き放ち、使われなければピボットをし、 やっとPMFしたプロダクト名が社名になる、そんなこともよくある話です。 ⽂字通り 「全員でアジャイルに取り組んだ経験があること」 それがWebサービスのビジネスモデルで上場できるようになったスタートアップの強みだと考えます。
73. © 2012-2024 BASE, Inc. 73 警鐘 再掲:⽣き残ったスタートアップは顧客に認められるために死に物狂いでやってきた ⽣き残ったWebサービスを運営すスタートアップはポジションや役職に関係なく、 ユーザーに認められるためにできることを死に物狂いでやってきました。 やりきったからこそ、BASEはPMFしたし、上場もできたということだと思います。 ⽣き残るために結果としてアジャイル的なことをやるしかなかったとも⾔えると思います。 プロダクトを作って、それを世に解き放ち、使われなければピボットをし、 やっとPMFしたプロダクト名が社名になる、そんなこともよくある話です。 ⽂字通り 「全員でアジャイルに取り組んだ経験があること」 それがWebサービスのビジネスモデルで上場できるようになったスタートアップの強みだと考えます。 この状態を維持し続けるのは 難易度が⾼いのかも
74. © 2012-2024 BASE, Inc. 74 警鐘 • PMFすると、1つ1つの施策の良し悪しが数字で出にくくなる（勝⼿に伸びていくから） • PMFすると、（勝⼿に伸びていくから）決定的な失敗がしにくくなり、健全にPDCAが回らない • PMFすると、⼈が増えてマネジメントコストが増える • PMFすると、⼈が増えて分業体制になりがち • 分業体制になるとわけわからなくなりがち PMFしてしまうとアジャイル的な強みを忘れてしまいがち
75. © 2012-2024 BASE, Inc. 75 警鐘 事業を倍々で⼤きくしていくには、⼩さいPMFの積み重ねをするしかありません。 プロダクトには賞味期限があるので、1つのプロダクトの成功で偉⼤な会社になるのは難易度が⾼いと考えています。 僕たちも道半ばですが、様々な切り⼝からの事業⽴ち上げを試しています。 ⼀つのプロダクトの成功で満⾜すると並の会社で終わる
76. © 2012-2024 BASE, Inc. 76 警鐘 事業責任者としては強⼒なビジネスモデルを作りたいけど難しい。 辞めてから気づきましたが、SIerのビジネスモデルは偉⼤です。 シンプルで再現性のあるビジネスモデルはそう作れません。 次々と良いプロダクトが世の中に出てくるので、同じことをしていたらプロダクトの成⻑は鈍化します。 常に競合プロダクトと違いを作り続けていく必要があります。 もちろん波に乗っている事業会社を次々に転職していけば⾷っていけるだろうけどそれって虚しいかも。 ⽣殺与奪の権を⼈に渡さず、⾃分の⼈⽣のオールを持ちたいです。 事業が作れるようになれば⾃分で環境や状況を変えられます。 専⾨分野だけにコミットしたいのであれば受託開発含めた強⼒な事業モデルのある会社で働くべきだと思います。 専⾨職が専⾨分野だけ考えていれば成り⽴つほど強⼒なビジネスモデルは作れない
77. © 2012-2024 BASE, Inc. 77 警鐘 これはポジショントークですが、⼀つプロダクトが成功して上場した会社で次の成⻑を作るのは⾯⽩いです。 上場後会社の次の成⻑を作るのとかおもしろいと思います ＜上場企業で次の事業を作るメリット＞ • 売上基盤があるので資⾦調達にかけるリソースを省⼒化できる • すでにいる優秀な⼈材の協⼒が得られる • 採⽤等で既存事業のブランディングに乗っかれる • 既存顧客を活⽤した横展開も狙えてより⼤きなビジネスを作るチャンスがある • 社内に新しい⾵を吹き込める パラメーターは増えるものの、プロダクトを通して事業を伸ばすことに集中できます。 PMF後もアジャイルな事業の作り⽅を維持できれば、それ⾃体が競争優位になり得ると考えます。 上場後会社の次の成⻑を作れるというのは、希少性の⾼いスキルだと考えます。
78. © 2012-2024 BASE, Inc. 78 まとめ
79. © 2012-2024 BASE, Inc. 79 ⽬次 • Webサービスを作るのは難しい • 困難を乗り越えるには事業責任者になれ • どうやって事業責任者になるのか • 警鐘：Webサービスの会社なのに受託的になっていないか？ • まとめ：社内受託にならないためにも     プロダクト開発者が事業責任者になるべき
80. © 2012-2024 BASE, Inc. 80 まとめ 受託開発が悪いわけではない ビジネスに合わせたプロダクト開発をしようという話
81. © 2012-2024 BASE, Inc. 81 まとめ ⻑く続く偉⼤なプロダクトを作るために⼆律背反に挑んでいる • ユーザーに使われてかつ儲かる • 慈善事業にならずイビルにもならない • 短期で成果を出し中⻑期でも成果を出す 偉⼤なプロダクトを作るには時間がかかるので⻑く向き合うための⼯夫も必要 • 投資を引き出すには期待に応え続けないといけない • 単⼀プロダクトで投資を引き出すだけの成⻑を⻑い時間続けるのは難しい • プロダクトの成⻑期は案外短く、どのタイミングでも投⼊したリソースだけ成⻑するとも限らない • ⻑期の投資の蓋然性の説明できなくてもとにかく続けるために、リソースの付け替え等も必要 Webサービスを作る私たちは難易度の⾼い問いに挑んでいる
82. © 2012-2024 BASE, Inc. 82 まとめ 永遠に伸びるサービスはないしそれだけで勝ち切れるサービスもありません。 第⼆、第三の成⻑エンジンは必須です。 より多くのメンバーが事業成⻑を⾃分事にできる組織を作りましょう。 事業責任者になれ！は⾔い過ぎにしても事業への⽬線を無くしてはいけません。 「経営とエンジニアの板挟みになる」みたいな⾔葉をこの世から消して⾏きたいです。 事業責任者になれ！は⾔い過ぎにしても少しでも領域を広げることが有意義だと思ってもらえると嬉しいです。 Webサービスを作る事業会社は事業を作り続けないといけない
83. © 2012-2024 BASE, Inc. 83 まとめ 受託開発全盛時代 エンジニア35歳定年説がまことしやかに囁かれ、 プログラマーキャリアからマネジメントやSEと呼ばれるものに変化することが求められた時代 プロダクト開発レイヤーで付加価値がつかないとされ、プロダクトがビジネスの源泉でなかった時代 エンジニアファースト時代 エンジニアさえいれば全ての困難を解決してくれるという思考停⽌の時代 プロダクトがビジネスの源泉になりプロダクト開発レイヤーの重要性には気が付かれるも ビジネスモデルの解像度が低くエンジニア頼みの時代 全員でアジャイル時代 事業開発とプロダクト開発を切れ⽬なく全員で回し全員で乗り越える時代へ 相互⼲渉が起こり連続的に成⻑を続けられる時代へ プロダクトマネジメントが分かることが標準装備の時代へ 時代を前に進めたい(時代分けは諸説あり)
84. © 2012-2024 BASE, Inc. 84 ビジネスとプロダクトはどこまで⾏っても密結合 まとめ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 要件定義をする 実装する グロースする
85. © 2012-2024 BASE, Inc. 85 縛りプレイして舐めプはもうやめよう まとめ コアユーザーを 決める 事業計画を作る 必要なお⾦を 集める チームを作る 要求定義をする 実装する グロースする グロースする 全てで PDCAを回す
86. © 2012-2024 BASE, Inc. 86 まとめ 実はWebサービスの開発というのは、ビジネスモデルの確⽴に関わりやすい事業です。 少⼈数で試⾏錯誤できるからのがいいところ。 ⼈が増えたら試⾏錯誤のコストは指数関数的に上がります。 PMFしてから呼ばれる⼈になるな！PMFを作り出せる⼈になろう！ 事業とプロダクトが成⻑させやすいような約束を作れる⼈になろう。 私は絶対に⾔い訳をしたくない性格なので、⾃分ができるをことを拡⼤し続けてきました。 この発表は私の履歴書です。 Webサービスを作り出し、維持し、拡⼤していくことの困難が付きまといます。 それを理解したWebサービスを作っていきましょう。 みんなビジネスモデルを作れる⼈になろうな
87. © 2012-2024 BASE, Inc. 87 まとめ あなたの置かれている環境が プロダクトがビジネスの源泉な環境であるならば プロダクトマネージャーがポジションを取りに⾏こう ビジネスモデルは切っても切り離せないのだから 事業責任者になっちゃおう
88. © 2012-2024 BASE, Inc. 88