SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

AI時代の「壁」を乗り越えろ。プロダクトマネージャーが直面するカオスと、現場を動かす「仕組み化」のリアル

ProductZine Day 2026

ProductZine Day 2026

「Product Engineering Conference 2026」レポート

AIで開発は速くなった。なぜアウトカムは増えないのか──BASE柳川氏が語る「拡大解釈」と練習の回数

「Product Engineering Conference 2026」レポート

レビューが「ハンコ」になった瞬間、責任は誰のものでもなくなる

 ラストマンという言葉には、一方で引っかかりもあると柳川氏は続けた。言葉としては知っていて、かっこいいとも思っている。ただ、腹の底で「これは自分のものだ」と思えているかは別の話だ、と。

 その感覚が育ちにくい理由として氏が挙げたのは、レビューの存在だった。ただしレビュー文化そのものは否定していない。むしろエンジニアの強みだという。

 「人ではなく、コトに対して指摘する。あの分離が根づいているのは、すごいことだと思っています。人格へのフィードバックは、いまの時代ほとんど口にできません。下手をするとパワハラになりますから」

 人ではなくコトを見る、という建前があるから、レビューでは遠慮のない直球の指摘ができる。ただし実際には、人とコトは分けきれない。自分が書いたコードへの指摘を、自分への指摘ではないと割り切れる人ばかりではないからだ。作ったものには、その人の考えが載っている。

 「建前のおかげで遠慮なく言えて、それでも分けきれないから効く。よくできた仕組みだと思いませんか」

 問題はレビューそのものではなく、それがハンコになったときだ。書く人がいて、提出し、通す人がハンコを押す。出したあとの責任は「通ったし」「書いたのは自分じゃないし」で、誰のものでもなくなる。対して助言を求め合う関係では、「どう思う?」「ここが気になる」と対等にやり合い、出したあとの責任を2人ともが自分のものとして持つ。

 「目指したいのは、親子じゃなくて、大人どうしの関係です。通してもらう、通してあげるというのは、親子の形なんですよ」

 厄介なのは、この関係が悪意なく成立してしまうことだ。上司やリードエンジニアに自然と頼り、頼られる側もそれが心地よくなる。求める側にも引き受ける側にも悪気がないぶん、誰も気づかない。

 「権限を渡しても、働く側が親を求めていたら、その場に親が湧きます」

 そして組織の分業も、まったく同じ構造をしている。企画する人、作る人、売る人と工程が分かれ、それぞれが自分の工程しか経験していない組織を思い浮かべると分かりやすい。出した機能が使われなかったとき、その結果を引き受けるのは誰か。自分の工程の外は見えないので、全員が「そこは誰かが持っているはずだ」と考える。責任は引き受けられているように見えて、実際は誰も持っていない。逆に、お互いの仕事を一度は経験したうえで分ければ、誰がどこを持っていて、どこが空いているのかが見える。

 「分業が悪いんじゃなくて、知らないまま渡すのが問題なんです。レビューのハンコ問題と、まったく同じ話です」

 セッションの概要文で、柳川氏はさらに踏み込んでいる。調整役としてのプロダクトマネージャーもまた、この分断の副作用ではないか、と。

 そして「知ったうえで組みたい」を言葉にするとこうなる、として氏は一枚のカードを映した。「1人でもプロダクトが作れるこの時代に、私は、あなたとプロダクトを作りたいのです」。結婚にまつわる有名なコピーになぞらえた一文である。

 同じ「あなたと作りたい」でも、中身は真逆になりうる。1人で作れないから、あなたと作りたい。これは必要だから組むということだ。1人で作れるけど、あなたと作りたい。こちらは選んで組む。頼らなくてもいい人が、それでも頼ってくれる。今日の話の根っこはたぶんここです、と氏は言った。

AIが持っていったのは、責任の実感が溜まる時間だった

 責任感なんてAIが来る前からずっと大事だっただろう。想定されるこの反論を、柳川氏は自分で口にして、そのとおりだと認めた。そのうえで、変わったことが2つあるという。

 1つ目は、責任感が「あったほうがいいが必須ではないもの」ではなくなったこと。かつて差がついたのは手の速さと知識の量で、そこができていればアウトカムへの責任感がなくても「バリューを出している」と見なされた。その2つは、いまやAIの得意分野である。差がつく場所として残ったのは、それまで必須ではなかったほうだった。

 2つ目が、この講演の核心にあたる。

 「訓練と思わずに訓練できていた時間が、減りました。動かないコードの前で、何時間も悩みましたよね。人間とコンピューターのどちらが間違っているかといえば、人間のほうです。コンピューターは言われたとおりにしか動かない。だから矢印が強制的に自分に向く。あの時間を、AIがかなり持っていきました」

 動かない、自分を疑い続ける、直る。このサイクルの真ん中に、責任に対する実感が溜まっていた。いまは、動かない、AIが出す、直る、になった。溜まる場所そのものが減ったのである。

 「責任感は、要る量が増えて、育つ場所が減ったんです」

 では、責任感は持とうと思って持てるものなのか。柳川氏はここで話を二層に分けた。

責任感は「持ちたいか」の層と「実感を持てるようになるか」の層に分かれ、後者は練習でしか手に入らない(出典:柳川慶太氏の登壇資料)
責任感は「持ちたいか」の層と「実感を持てるようになるか」の層に分かれ、後者は練習でしか手に入らない(出典:柳川慶太氏の登壇資料)

 一層目は、そもそも責任感を持ちたいかどうか。同じチームで同じものを作っていても、担当外の不具合に「まずい」と反応する人と、「担当じゃないので」で終わる人がいる。能力の差というより感じ方の差で、ここは一種の才能に近く、選べない。持ちたくない人がいてもいい、と氏は明言した。

 二層目が、その実感を持てるようになるかどうか。こちらは練習だという。作る、出す、触られる、直す。この一周を繰り返すことでしか、実感は手に入らない。

 「『責任感を持って』という言葉は、どちらの層にも効きません。思えるかどうかは言葉では変わらないし、実感は言葉では渡せないからです。だから、責任感をもっと持ってというだけなら、無責任なんです」

 では何をすれば持てるのか。氏は「自分にも答えはない、たぶん人によって違う」と率直に言い、宿題として持ち帰るよう会場に求めた。成果が懸かると入る人。頼まれると入る人。怒りで入る人。自分の構造を知っていると、練習場の選び方が変わる。

練習の場は、会社の中では作りにくい

 ただし、その練習を会社の中でやるのは無茶だ、と柳川氏は言う。会社で作っているものは自分のものではない。給料をもらい、複数人で作り、成果物は会社に帰属する。自分が辞めても続くし、担当も変わる。その対象に自分の人格を直結させるのは冷静に考えれば無理があるし、直結させられるほうが自意識過剰で怖い、とまで氏は言った。

 それでも、いいものを作る人は勝手に引き受けている。頼まれていない範囲まで気にして、担当外の不具合に腹を立てる。合理的にはやる理由のないことなので、放っておいて身につくものではない。

 分業され、レビューがあり、リリースの判断も自分ではない。どれも合理的にそうなっているだけで悪いことではないが、一人で全部を引き受ける経験は積みにくい。

 それでも巡ってくる瞬間はある、と氏は3つ挙げた。新規事業の立ち上げ、人が抜けた直後、誰もやりたがらない仕事。柳川氏の場合はYELL BANKの立ち上げだった。スライドには一言添えられている。練習場は、渦中では練習場の顔をしていない。

 とはいえ、そうした瞬間がいつ巡ってくるかは分からないし、来ないまま何年も過ぎることもある。巡ってこないなら、外に作るしかない。作るものは何でもよく、しょぼくてもいいし、お金を取らなくてもいい。ただし、趣味や遊びで終わらせないでほしいと氏は言う。大人になってから真剣になれる設定を作るのは難しい。子どもの頃には部活があったが、大人にはそれに代わるものがない。その点、お金を稼ぐというのは真剣の設定として手軽だ、と。

 柳川氏自身の練習場は、複眼道場という個人事業である。エニアグラムとインテグラル理論を使った自己理解の診断ツールとセッションで、企画も実装もデザインも価格も1人でやり、AIと二人三脚で回している。

 講演では時間の都合で飛ばされたが、スライドには、その事業でAIに何を任せたかの星取表が載っていた。

柳川氏が個人事業でAIに任せたものと、任せなかったもの(柳川慶太氏の登壇資料をもとに編集部作成)
判定 扱い 領域
◎ ほぼ任せた プロダクト実装/決済・規約まわり/CS・日々の運用
◯ 二人三脚 ドメイン知識の学習/事業計画・収支/デザイン・LP/コンテンツ制作/集客・ファネル/データ分析
△ 補助だけ 課題発見・コンセプト設計/ネーミング・ブランドの言葉
✕ 渡さない 価格・商品設計/商品を増やす判断/ユーザーインタビュー

 渡さなかった3つに共通するのは、外に答えがないことだ。

 「AIに渡せなかったのは、スキルではなく、現場感覚と実感でした。その場の空気と表情。いくらなら払うか、の手触り。自分がどうなりたいのか。どれも、テキストになっていないものです」

 1人で事業をやると、隣の人が急にすごく見えるようになる、とも氏は言う。何を作るか決まらない企画の地獄、誰にも見つけてもらえない集客の地獄、自分の値段を自分でつける価格の地獄。ひととおり通ると、リスペクトが自然に湧いてくる。スライドはそれをこう言い切っている。リスペクトは、心がけではなく、通った地獄の数で決まるものでした。

次のページ
拡大解釈とは、心技体を割らずに範囲だけ広げることだった

この記事は参考になりましたか?

この記事の著者

斉木 崇(編集部)(サイキ タカシ)

株式会社翔泳社 ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine(コードジン)」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine(エドテックジン)」...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/29773 2026/09/25 09:30

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー