Dev x PM x PL エンジニアはビジネス構造を作れる

Transcript

1. DEV X PM X PL エンジニアは ビジネス構造を 作れる AI時代の生存戦略として ロングコンテキストを操らざるを得ない 2026.2.18 DEVELOPERS SUMMIT 2026 柳川慶太
2. 自己紹介 自己紹介 義務と権利 プロダクトで稼いでるならプロダクトわかる人が偉くなるのが道理 名前 肩書き 職歴 会社歴 趣味 サブプロジェクト その他活動 スタンス 柳川慶太 BASE株式会社 金融事業責任者 エンジニア→PdM→事業責任者 SIer→広告配信→現職 note書く/Gem作る お悩み相談を中心に軸足を作っていきたい プロダクトぶれんじゃねぇラジオ/ノッカリアドカレ とにかく繋げる、ジェネラリスト万歳 | | | | | | | | Dev x PM x PL エンジニアはビジネス構造を作れる
3. 自己紹介 自己紹介 狂ったようにnote書いてます Dev x PM x PL エンジニアはビジネス構造を作れる
4. 序章：DevとPMだけで十分？ 1章：DevとPMだけじゃ足りない - PLが必要な理由 2章：AI時代における「ロングコンテキスト」と人間の役割 終章：まとめ 目次 Table of Contents Dev x PM x PL エンジニアはビジネス構造を作れる
5. DevとPMだけで十分？ 序 Dev x PM x PL エンジニアはビジネス構造を作れる
6. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 問い：「DevとPMの両輪」だけで十分？ 確かに両輪は大事
7. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 問い：「DevとPMの両輪」だけで十分？ DevとPMだけで本当に事業インパクト最大化している？ CxO本当に事業わかってる？
8. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 答え：「DevとPMの両輪」だけで十分じゃねぇ！ 事業責任者やってPLにも責任持とうよ！ 事業構造やっていきましょ！ 事業構造計画書いちゃいましょ！
9. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる そもそもPL（損益計算書）とは？ 一言でいうと、会社が「1年間（または特定の期間）で、 どうやって稼ぎ、何にお金を使い、最終的にいくら手元 に残ったか」を表す成績表です。 英語の Profit（利益）and Loss（損失）Statement の 頭文字をとって「P/L（ピーエル）」と呼ばれます。
10. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 別に事業が大好きなわけじゃない 本当は事業事業言いたくない でも会社員として仕事する以上は資本主義のルールに従う 理想と現実の間で強かにやる
11. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 今日の話はなぜかAIの話につながります ロングコンテキストで価値出せないと 生き残れないので領域を広げざるを得ない という話に繋がっていきます
12. KOTO Creative DevとPMだけじゃ足りない PLが必要な理由 1 Dev x PM x PL エンジニアはビジネス構造を作れる
13. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 そもそもビジネスってなんですか
14. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 ここじゃ無いよ ←マーケや営業
15. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる ビジネスは営業やマーケティングではない よくある誤解 ビジネス ＝ 営業・マーケティング つまりHowだと思っている
16. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる ビジネスは事業戦略だ！ 本来の定義 ビジネス ＝ 事業戦略・スキーム つまりWhatでありStructure
17. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 「プロダクト vs ビジネス」という不毛な対立 ここだよ！重要なのは「事業構造（PL）」
18. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる PLはただの算数だよ アレルギーを捨てよう 基本構造はシンプルで算数レベルです 利益 = 売上 - 原価 - 販管費 LTV > CAC（顧客生涯価値 > 獲得コスト）
19. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる PLはただの算数 こんなの全部算数だよ
20. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる プロダクトで何が動くかが大事 実装した機能がPLの中のどの数字を動かすか？ というのがわかることが大事 トランザクションが増える？ UUが増える？ コストが減る？
21. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 実装した機能がPLのどの変数を動かすか考えられてる？ 実装した機能がPLのどの変数を動かすか これ考えられていますか？案外考えられてないかも。 「PLがわからない」というのは 実装した機能が何を起こすかを 考えられていないということだと思います
22. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる 自分が作り出したものに愛持て 自分が作ったものがどういう影響を与えているか わからないの気持ち悪くないですか？ 自分が作り出したものに愛持ててますか？ どうですかPL 興味持てそう？
23. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる ただの算数なんだけど、ただの算数にしてはいけない ただの算数なんだけど、ただの算数にしてはいけない 血肉を通わせることが大事 エクセルだけ見ててもわからない プロダクトで儲けている会社であれば 実装した機能がPLのどの変数を動かすかだろ！ そして動かした実感を一番持てるのは 実際につくったエンジニアでしょう
24. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる ロングコンテキストの話がちらつく(後で話します)
25. DevとPMだけで十分？ 事業構造を実感を持って操る ただの算数なんだけど、ただの算数にしてはいけない Dev x PM x PL エンジニアはビジネス構造を作れる 価値を積み上げていけ
26. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる プロダクトが作れるゆえに事業マネジメント エクセル上のシミュレーションではなく現実の話 エンジニアやプロダクトマネージャー経験のない 事業企画や事業責任者にはできないことが プロダクトを作る我々にはできると思う！！
27. DevとPMだけで十分？ 計画がないと確かめられない！予実管理大事！ プロダクト開発に例えると 予実管理はスプリントレビューであり スプリントレトロスペクティブです Dev x PM x PL エンジニアはビジネス構造を作れる そもそも何で事業計画書くのか
28. DevとPMだけで十分？ Dev x PM x PL エンジニアはビジネス構造を作れる そもそも何で事業計画書くのか 事業計画は「正解」ではない あくまで「投資計画（仮説）」 「できていない状態」から思考をスタートする 失敗したテストの差分を埋めながら成功させていく感覚 PLがわからなければ差分わからず
29. 2 AI時代における 「ロングコンテキスト」 と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる
30. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる AIはもはや人間を超えた AIはもはや人間を超えました(×10) ショートコンテキスト（局所的な課題）においては、 もはやミドルクラス以上の思考力を持つ 局所のコード生成、要約、翻訳、論理構築... 単純なスキル勝負では、人間は分が悪い
31. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる ロングコンテキスト問題 by みやっち
32. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる AIの唯一にして最大の弱点 「ロングコンテキスト」の保持ができない 全体の文脈、過去の経緯、複雑な利害関係、 未来へのプライオリティ... AIは超優秀だけど記憶喪失だし価値判断もできない天才 これらを繋ぎ続け、整合性を取ることは まだ人間にしかできない
33. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる もはやコンテキストを広げていくことは既定路線 広げるか深めるかの２択 ポジショントークだけど広げにいくことを推奨したい そしてそれは多分エンジニアが得意 という話をしてきます
34. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる PL（損益計算書）を見る意味 PLを見る 事業全体のロングコンテキストを保持するということ PLを見ない 自ら「AI以下のコンテキスト」で戦うと宣言している のと同じ ちょっと極端かもしれないが 自分の生存領域を事業全体まで広げることが生存戦略
35. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる エンジニアの強み：マシンに矯正され続ける「自責思考」 なぜエンジニアなら 「広げたコンテキスト」に耐えられるのか① 「複雑なシステムのエラー原因を、自責で特定する訓練」 事業（PL）は、複雑な変数が絡み合う巨大なシステム 変数が多すぎると「他責（環境のせい）」にしがち しかしエンジニアは、「複雑なシステムのエラー原因を、 自責で特定する訓練」を受けている
36. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる エンジニアの強み：マシンに矯正され続ける「自責思考」 なぜエンジニアなら 「広げたコンテキスト」に耐えられるのか② コンパイラは絶対 言い訳無用。動かないのは100%自分が悪い。 この「強制的な自責思考」があれば、事業という理不尽な システムもハックできる
37. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる エンジニアの強み：マシンに矯正され続ける「自責思考」 なぜエンジニアなら 「広げたコンテキスト」に耐えられるのか③ 健全な自責思考 AIが変なアウトプットを出しても、「AIが使えない」では なく「自分の指示が悪い」と考える この思考回路こそが、AIと事業をハンドリングする鍵
38. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる (仮説)未来の組織図：「人月AI管理者」への進化
39. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる (仮説)未来の組織図：「人月AI管理者」への進化
40. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる (仮説)未来の組織図：「人月AI管理者」への進化 AIに「働かされる」準備をせよ AIは文句も言わず、爆速でアウトプットを出してくる 人間の役割は、AIに適切な「ショートコンテキスト」を切り出 して渡すこと 新しい役割：人月AI管理者 10人のAI部下（特化型AI）を並列に働かせる 求められるのは、AIの速度に負けない「早い思考」と、全体を 統合する「ロングコンテキスト」 オフショア管理やSIerのPMに近い（ただし相手は爆速）
41. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる (仮説)未来の組織図：「人月AI管理者」への進化
42. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる 「人月AI管理者」おもしろいよ AIマネジメントの特徴 人間相手より楽な点 AIは品質のブレが少なく育成（学習）も早い 人間相手よりキツイ点 AIはレスポンスが爆速です 自分がボトルネックにならないよう脳みそをフル回転させ続けなけ ればなりません 疲れますし向き不向きもある
43. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる 「人月AI管理者」おもしろいよ 「人月AI管理者」という仕事 「AIの管理？ 誰でもできるでしょ？」 「保守的な退屈そうな仕事？」 「そういう仕事こそAIにやらせるべきでは？」 そんなことない AIに「ロングコンテキスト」は求めず、そこは人間が担保する これは 「AIに働かされているようでいて 実は人間にしかできないコンテキスト管理をフル回転で行う」 ことなのだ
44. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる ボトルネックは「AI」ではなく「人間の意志」 AIは選択肢（Option）は出せるが、決断（Decision）はできない 合理的な正解だけなら、全員同じ結論になる（コモディティ化） 差別化要因は「非合理な意志（これがやりたい）」だけ ロングコンテキストの維持には「意志」が必要 膨大なコンテキストの中から、何を選び、何を捨てるか それを決めるのはロジックではなく「意志」 意思っていうとふわふわしているけれども、要するに強弱です 忘れることとかも含めて大事！ コンテキストの容量が増えればいいという話ではない Dev x PM x PLを学ぶのは、この「意志」を通すため
45. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる 事業責任者は「構造」を作る仕事 ＝ コンテキストの設計 事業責任者の仕事 プロダクトだけでなく、組織、財務、情報の流れ（構造）を設 計する これは「AIがワークするためのコンテキスト設計」と同じ 良い構造を作れば、AI（とメンバー）は自律的に動く エンジニアリングの延長 スパゲッティコード（カオスな組織・事業）をリファクタリン グする仕事 依存関係を整理し、疎結合な組織を作る 狭いコードの世界で培った設計力を、事業という広い世界で発 揮せよ
46. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる エンジニアは本当の意味での「ラストマン」 エンジニアの宿命 トラブルが起きたら、最後に直すのはエンジニア 物理的な最終防衛ライン。「動かない」という事実からは逃げ られない その覚悟を拡張する AIが出してきたアウトプットの責任を、自分が取る 事業の数字（PL）が悪かったら、自分の責任として受け止める 「最後は自分の手でなんとかする」という覚悟だけが、人をリ ーダーにする
47. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる あえてギャップを言うならば 不確実なことへの耐性の低さ ビジネスにおける争いは「正しいvs正しい」ばかりなのである その中でどう決めるか、どう進むか 気が張っちゃうのはわかる それこそラストマンシップの裏返しだと思う 不確実な時にどしっと構える強さ 強さとかいうと精神論だけど、時間軸を長く持つというのは大事
48. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる PLまで見るのはキツイ？ せめてフルサイクルにやりましょう 特に運用！運用です！ 運用したことない人が、運用しやす いシステム作れますか？ 運用しやすくなくて良いなら、本当 にAIで一瞬で作れちゃう ジェネラリストを恐れるな！とにか く守備範囲を広げていこう。
49. まとめ 終 Dev x PM x PL エンジニアはビジネス構造を作れる
50. AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる まとめ：Dev x PM x PL 1. DevとPMだけじゃ足りない：前提となる「事業（PL）」を握ろう 2. AI時代の生存戦略：ショートコンテキストではなく、ロングコ ンテキスト（事業全体）で戦う 3. エンジニアの適性：「マシンに矯正された自責思考」でAIにコ ンテキストを渡し続ける 4. 今日からやれ！：「PLを見に行け。コンテキストを広げろ。AI に負けたくないなら」
51. Next 柳川 AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる
52. Next 柳川 AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる ガチでAIを使いこなす組織のために真正面から向き合う
53. Next 柳川 AI時代における「ロングコンテキスト」と人間の役割 Dev x PM x PL エンジニアはビジネス構造を作れる AIを使いこなすためにAIに育成される
54. THANK YOU 🎉 少しでも領域を広げていく気持ちを持ってもらえたら嬉しいです 誰にも期待されていないことを自分が必要だと思うからやる そんな仲間が増えて欲しいです！一緒に頑張ろ！ 手を動かせる奴が一番偉い！型にハマるな！