圧倒的な熱量で、組織と個人のあり方を問うソートリーダー
2026年2月18日、Developers SummitとProductZineが初コラボレーションした「Dev x PM Day」が開催された。「『技術』を『事業』に変える。その変革、誰がやりきるのか？」という重厚なテーマのなかで、ひときわ高い熱量で会場を圧倒したのが、BASE株式会社 金融事業責任者の柳川慶太氏によるセッションである。
柳川氏は、システムインテグレーターから広告配信の領域を経て、エンジニア、プロダクトマネージャー、そして事業責任者へとキャリアを拡張し続けてきた人物だ。日頃からXやnoteで、自身でも「狂ったように執筆している」と講演スライドで言及するほど精力的に情報発信を続けており、最近では「なぜ3年で転職してはいけないのか」といったエッジの効いた記事が大きな反響を呼ぶなど、深い洞察を持つソートリーダーとしても知られている。
本セッションは「エンジニアよ、事業構造（PL）を作れ」という、ソフトウェアエンジニア（以下、エンジニア）や開発者（Dev）に向けた強烈なメッセージが主軸となっている。しかしその本質は、プロダクトマネージャー（PM）にとっても「AI時代において、開発チームを単なる実装部隊としてではなく、事業構造を共創するパートナーとしてどう巻き込むか」という極めて重要な示唆を含んでいる。
聴講者からも「PLまでちゃんと見れていなかったが、生き残るためには理解する必要があると感じた」「日々のマルチプロダクトのマネジメントにおいて、ロングコンテキストという概念付けができて腹落ちした」という声が続出した。
「プロダクト vs ビジネス」の不毛な対立を終わらせよ
「『DevとPMの両輪』だけで十分？ 答えは『十分じゃねぇ！』だ」
柳川氏は冒頭から、歯に衣着せぬ力強い言葉で聴講者に問いかけた。「良い技術」が必ずしも「勝てる事業」を生むとは限らない。開発現場において「プロダクト vs ビジネス」という対立構造は決して珍しくないが、柳川氏はこの対立自体が不毛であると一刀両断する。その原因は、多くのエンジニアやプロダクトマネージャーが、ビジネスを「営業やマーケティングのこと（＝実行フェーズのHow）」だと誤解している点にあるという。
ビジネスはHow（営業・マーケティング）ではなくWhat（事業戦略）。
「事業戦略・スキーム」のレイヤーこそがビジネスである
本来のビジネスの定義とは「事業戦略やスキーム」であり、つまりは「WhatでありStructure（構造）」である。柳川氏の言葉を借りれば、プロダクトマネージャーは「プロダクト」をつくる人であり、事業責任者は「構造」をつくる人だ。そして、この事業戦略と実行をつなぐ構造の根幹を成すのが「PL（損益計算書）」なのである。柳川氏は、PLとは会社が1年間でどうやって稼ぎ、何にお金を使い、最終的にいくら手元に残ったかを表す成績表だと定義し、ものづくりに関わるすべての人間がPLへのアレルギーを捨てるべきだと主張する。
PLはただの算数。自分が作った機能に「愛」を持て
「利益 ＝ 売上 − 原価 − 販管費」や「LTV（顧客生涯価値） > CAC（獲得コスト）」といったPLの基本構造は、極言すれば「ただの算数レベル」にすぎない。原価には仕入費用や販売手数料が含まれ、販管費には人件費などが含まれる。だが、これを単なるエクセルの数字のシミュレーションとして捉えていては本末転倒だ。
柳川氏が最も強調するのは、「実装した機能がPLの中の『どの変数』を動かすか」を、血肉を通わせた実感として把握することである。その新機能は、トランザクションを増やすのか。ユニークユーザー（UU）を増やすのか。それともコストを減らすのか。「PLが分からないということは、自分が実装した機能が現実世界に何を起こすかを考えられていないということだ」と氏は鋭く指摘する。
「自分が作り出したものがどういう影響を与えているか、分からないの気持ち悪くないですか？ 自分が作り出したものに愛持ててますか？」
この問いは、会場の聴講者の胸に深く突き刺さった。アンケートでも「実装した機能がPLのどこを動かすか？という問いかけは良かった」「売上が発生して初めてプロダクトの完成だという自分の考えが裏付けられた」といった共感の声が相次いだ。
自分が作った機能がユーザーに価値として届き、それが経営資源に変わり、プロダクト開発の再投資へと循環していく。この価値の積み上げを実感できることこそが、開発者の特権なのである。
生成AIの巨大な壁「ロングコンテキスト問題」
セッションの中盤、テーマは「AI時代における人間の役割」へと大きく展開していく。現在、局所的なコード生成、要約、翻訳、論理構築といった「ショートコンテキスト」のタスクにおいて、AIはすでにミドルクラス以上の思考力を持ち、人間を超越しつつある。単純なスキル勝負では、人間はもはや分が悪い。
しかし、そんな万能に見えるAIにも巨大な壁が存在する。それが「ロングコンテキスト問題」だ。プロジェクトの歴史、全顧客への影響、機能間の複雑な依存関係、未来へのプライオリティといった、長期的で広範囲な文脈（ロングコンテキスト）の全体像を把握することは、AIの唯一にして最大の弱点である。
「AIは超優秀だけど記憶喪失だし価値判断もできない天才」
これらをつなぎ続け、全体の整合性を取ることは、いまだに人間にしかできない。聴講者からも「AIはロングコンテキストが苦手だと現在のプロダクトを扱っていて思っていたので、自分のスタンスを認識できてよかった」と深い納得の声が上がった。つまり、AIに代替されず生き残るためには、自ら「事業全体（PL）というロングコンテキスト」へ生存領域を広げるしかないのだ。PLを見ないということは、自ら「AI以下のコンテキストで戦う」と宣言しているのに等しい。
マシンに矯正された「自責思考」が、AIと事業をハックする
では、なぜエンジニアがこの「ロングコンテキスト」を操ることに長けているのだろうか。柳川氏はその理由を、エンジニアが長年マシンによって強制的に矯正され続けてきた「自責思考」にあると分析する。
事業（PL）は複雑な変数が絡み合う巨大なシステムであり、変数があまりにも多すぎると、人間はどうしても「他責（環境のせい）」にしてしまいがちだ。しかし、エンジニアは「コンパイラは絶対」という世界で生きている。コードが動かないのは言い訳無用で「100%自分が悪い」のだ。
この「複雑なシステムのエラー原因を、自責で特定する訓練」は、AIを使いこなす上でも絶大な威力を発揮する。AIが意図しないアウトプットを出しても「AIが使えない」と環境のせいにするのではなく、「自分の指示（プロンプト）が悪い」と考えることができる。この「健全な自責思考」こそが、AIと事業という理不尽なシステムをハックし、ハンドリングする最大の鍵となる。
