プロダクトと​事業、​その​境界線は​どこに​あるのか 登壇資料

Transcript

1. 色々考えたんだけど 質問に答えていく ことにしました 手抜きじゃないよ 2026.6.18 プロダクトと​ 事業、 その 境界線は どこに あるのか 柳川慶太
2. 自己紹介 義務と権利 プロダクトで稼いでるならプロダクトがわかる人が偉くなるのが道理 名前 肩書き 職歴 会社歴 趣味 サブプロジェクト その他活動 スタンス 柳川慶太 BASE株式会社 金融事業責任者 エンジニア→PdM→事業責任者 SIer→広告配信→現職 note書く/Gem作る お悩み相談を中心に軸足を作っていきたい プロダクトぶれんじゃねぇラジオ/ノッカリアドカレ とにかく繋げる、ジェネラリスト万歳 | | | | | | | | 質問に答えていくことにしました
3. 自己紹介 狂ったようにnote書いてます 質問に答えていくことにしました
4. 登壇内容色々考えたんだけど せっかくみんな質問くれてるので 質問に答えていくことにしました 手抜きじゃないよ 質問に答えていくことにしました
5. 登壇内容色々考えたんだけど いただいた情報だけだとわからないことも多いので できれば全員と1時間ずつ1on1したいです 背景情報によって回答変わるし精度も上がるので 質問に答えていくことにしました
6. Q1 プロダクトを良くするには総合力が求められると思いま すが、成長する過程での苦悩のうち、耐えるべきものと 耐えるべきでないものとがあれば伺ってみたいです。 質問に答えていくことにしました
7. A1 記事書いときました 質問に答えていくことにしました
8. 書き下ろしだよ！ 質問に答えていくことにしました
9. Q2 共通言語を定義するhowがききたい 質問に答えていくことにしました
10. A2 何のために共通言語を定義する必要があるのか わからないので何とも言えない ただ僕の経験では共通言語を定義することが 一番効果的なソリューションではないことが多かった AIのおかげもあり 人間の間で共通言語を保持する必要性は減りそうですよね 質問に答えていくことにしました
11. Q3 ビジネスの数値(収益等)が先行してしまい、 数値化が難しい、デザインが分かりづらくなったや 体験の低下とのバランスが難しく感じます。 どうバランスとっているか気になります。 質問に答えていくことにしました
12. A3 あんまりずれなくないかな？ ビジネス数値と体験の良さというのは 基本的に連動するのでは？ もちろんビジネスモデルによるけど 体験の良さにこだわるなら体験と数字が連動する プロダクトを担当するのがいいよね 質問に答えていくことにしました
13. A3 数字につながらない体験の良さなら不要だよね と言うとちょっと乱暴だけど 時間軸の差の話はあれど 絶対に数字には繋がるでしょと思う 質問に答えていくことにしました
14. この辺かなー 質問に答えていくことにしました
15. Q4 現在の会社に事業開発部門で入社したが、実際は社長が 構想したプロダクトをまず作ってそこに事業性を持たせ るやり方で進めています。プロダクトを作れるスピード が上がっているのでそういうやり方もあるかと思います が、私としてはまず土台やコアの部分を確かなものにし てからものを作り始めるやり方が、無駄なもの作りに時 間を割かない点で合理的だと考えています。プロダクト が決まった状態で事業性を担保する進め方の妥当性と、 その時の最善の進め方についてお伺いしたいです。 質問に答えていくことにしました
16. A4 むずいなー 正解の進め方が存在するという派閥ではないので、 土台やコアの部分を確かなものにしながら 進められる気がしない 結局のところリーンにユーザーの反応みながら 進めていく他ない でもセンスねーなと思うなら「センスねー」と言うといい 質問に答えていくことにしました
17. A4 あとは質問いただいたパターンの場合 その社長がどこまで腹くくってどこまで 実務コミットしているか次第かな 結局正解はわからんから責任取る人が コミットして推進するなら文句は言えない うまくいかなかった時に自分ごととして反省して 変われる人ならいいと思う 「適当に決めてあとよろしく」なら無視するべし 実行するラストワンマイル握ってる人が結局強いから 質問に答えていくことにしました
18. A4 やり方の正しい正しくないで争っても 何も生まれないんだよね あとうまくいかないものを 無理してうまくいかせるのは良くない 質問に答えていくことにしました
19. この辺かなー 質問に答えていくことにしました
20. Q5 PdMが事業責任者も兼ねようとすると 個人の業務量が多くなりすぎるため、 事業責任者とプロダクト開発責任者 という形で役割を分けようとしていますが、 なにをどう分担するかの定義づくりに苦労しています。 質問に答えていくことにしました
21. A5 定義ってそんなに大事なんだろうか。 手が足りないのにそんなこと考えている余裕なくない？ 手が足りないから分けるのになぜ苦労するのか？ 何で定義が必要なのか考えてみると良さそう。 質問に答えていくことにしました
22. この辺かなー 質問に答えていくことにしました
23. Q6 事業企画の担当だが、どこからどこまでを自分で指し示 せばいいかわからない（自分は非エンジニアです） 質問に答えていくことにしました
24. A6 エンジニアの力量やスタイルによりますね 相手のスタイルを聞いて相手が答えられないようであれば リードしてしまった方が楽 (後から文句言われるパターンもあるけど) 結局のところ人間の組み合わせによるんですよね それぞれどこまでやれるのかは この職能だからここまでやれるとかはない 質問に答えていくことにしました
25. A6 元も子もない話をすれば どの職種だろうが 仕事できない奴はできないし、仕事できる奴はできる なのでどんな組み合わせでもワークできるように 自分のカバレッジを広げていくのが建設的 質問に答えていくことにしました
26. Q7 規模や領域にもよると思いますが、特にtoC領域における 判断の違いを聞きたいと思っております 数字の責任やプロダクトの方針は事業責任者なのかPdMな のか。事業責任者がPdMを兼任しているからそのような問 題は起きないのか？などリアルな事情を知りたい。 質問に答えていくことにしました
27. A7 事業責任者とPdMは兼任が理想だとは思います 数字とプロダクトはセットでしょう プロダクトの稼ぎで食っているのであれば というか分ける必然性が出るまではわけない 分ける必然性があれば定義とか困らない 困ってるなら分けなくてもいいんだと思う 実際溢れてくるとやれる奴がやるしかなくなる 質問に答えていくことにしました
28. この辺かなー 質問に答えていくことにしました
29. ところでみんなこれ使ってみて欲しい 質問に答えていくことにしました
30. 大事なこと 大抵答えは自分の中にある 整理の仕方や視点が足りないだけ 質問に答えていくことにしました
31. 大事なこと みんなでディスカッションして視点増やしましょ！ この後のテーブルディスカッションも楽しんでね！ そこに繋げるために空気読んで煽ったからね！ 僕のnoteも読んでね！ 質問に答えていくことにしました
32. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 おまけ
33. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 そこに愛はあるのか
34. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 そもそもビジネスってなんですか
35. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 ここじゃ無いよ ←マーケや営業
36. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる ビジネスは営業やマーケティングではない よくある誤解 ビジネス ＝ 営業・マーケティング つまりHowだと思っている
37. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる ビジネスは事業戦略だ！ 本来の定義 ビジネス ＝ 事業戦略・スキーム つまりWhatでありStructure
38. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 ここだよ！重要なのは「事業構造（PL）」
39. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる PLはただの算数だよ アレルギーを捨てよう 基本構造はシンプルで算数レベルです 利益 = 売上 - 原価 - 販管費 LTV > CAC（顧客生涯価値 > 獲得コスト）
40. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる PLはただの算数 こんなの全部算数だよ
41. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる プロダクトで何が動くかが大事 実装した機能がPLの中のどの数字を動かすか？ というのがわかることが大事 トランザクションが増える？ UUが増える？ コストが減る？
42. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 実装した機能がPLのどの変数を動かすか考えられてる？ 実装した機能がPLのどの変数を動かすか これ考えられていますか？案外考えられてないかも。 「PLがわからない」というのは 実装した機能が何を起こすかを 考えられていないということだと思います
43. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 自分が作り出したものに愛持て 自分が作ったものがどういう影響を与えているか わからないの気持ち悪くないですか？ 自分が作り出したものに愛持ててますか？ どうですかPL 興味持てそう？
44. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる ただの算数なんだけど、ただの算数にしてはいけない ただの算数なんだけど、ただの算数にしてはいけない 血肉を通わせることが大事 エクセルだけ見ててもわからない プロダクトで儲けている会社であれば 実装した機能がPLのどの変数を動かすかだろ！ そして動かした実感を一番持てるのは 実際につくった人でしょう
45. DevとPMだけで十分？ 事業構造を実感を持って操る ただの算数なんだけど、ただの算数にしてはいけない Dev x PM x PL エンジニアはビジネス構造を作れる 価値を積み上げていけ
46. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる プロダクトが作れるゆえに事業マネジメント エクセル上のシミュレーションではなく現実の話 エンジニアやプロダクトマネージャー経験のない 事業企画や事業責任者にはできないことが プロダクトを作る我々にはできると思う！！
47. DevとPMだけで十分？ 計画がないと確かめられない！予実管理大事！ プロダクト開発に例えると 予実管理はスプリントレビューであり スプリントレトロスペクティブです Dev x PM x PL エンジニアはビジネス構造を作れる そもそも何で事業計画書くのか
48. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる そもそも何で事業計画書くのか 事業計画は「正解」ではない あくまで「投資計画（仮説）」 「できていない状態」から思考をスタートする 失敗したテストの差分を埋めながら成功させていく感覚 PLがわからなければ差分わからず
49. THANK YOU 🎉