エンジニアの思考法はこの先も技術の外でも 通用するのか @20260618 エンジニアの役割の変化に向き合うconference

2026年6月18日にBASE株式会社執行役員柳川登壇にて使用した資料です。

Transcript

1. エンジニアの思考法は この先も技術の外でも 通用するのか エンジニアリング知見を持つことが 当たり前の世界へ 2026.6.18 エンジニアの役割変化に向き合うカンファレンス 柳川慶太
2. 自己紹介 自己紹介 義務と権利 プロダクトで稼いでるならプロダクトがわかる人が偉くなるのが道理 名前 肩書き 職歴 会社歴 趣味 サブプロジェクト その他活動 スタンス 柳川慶太 BASE株式会社 執行役員 金融事業責任者 エンジニア→PdM→事業責任者 SIer→広告配信→現職 note書く/Gem作る お悩み相談を中心に軸足を作っていきたい プロダクトぶれんじゃねぇラジオ/ノッカリアドカレ とにかく繋げる、ジェネラリスト万歳 | | | | | | | | エンジニアの思考法はなぜ技術の外でも通用するのか
3. 自己紹介 自己紹介 狂ったようにnote書いてます エンジニアの思考法はなぜ技術の外でも通用するのか
4. 序章：エンジニア役割変化するの？ 1章：AIについて整理 2章：エンジニアの3つの思考の型 3章：統合力を鍛えるために何ができるか 4章：ビジネスモデルは何にせよ大事 終章：自分の頭で考えることの大切さと難しさと愛おしさと 目次 Table of Contents エンジニアの思考法はなぜ技術の外でも通用するのか
5. エンジニア 役割変化するの？ 序 エンジニアの思考法はなぜ技術の外でも通用するのか
6. エンジニア役割変化するの？ エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアの役割変化に向き合うConferenceです 役割変化？するのか？
7. エンジニア役割変化するの？ エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアの役割はどこまで広がっているのか ふむふむ
8. エンジニア役割変化するの？ エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアの役割はどこまで広がっているのか わかるんだけど！ AIとか関係なく広げていこうぜ というスタンスを取りたい
9. エンジニア役割変化するの？ エンジニアの思考法はなぜ技術の外でも通用するのか そもそも分業しすぎだっただけでは？ 統合が大事
10. エンジニア役割変化するの？ エンジニアの思考法はなぜ技術の外でも通用するのか 例えばPdMとか必要なの？ サーバーサイドエンジニアとフロントエンドエンジニアが 分かれているのが妥協の産物であることと同じように PdMの存在は妥協の産物だと思っている
11. エンジニアの思考法はなぜ技術の外でも通用するのか 作ることと意思決定は分離していない方がいい うっすら考えていた なぜエンジニアが作るものを決められないのか なぜエンジニアが事業に決定権を持たないのか プロダクトがお金を稼ぐビジネスモデルであれば みんな当たり前にエンジニアであるべきでは AIによってそれは理想論ではなくなるのでは エンジニア役割変化するの？
12. AIについて整理 1 エンジニアの思考法はなぜ技術の外でも通用するのか
13. AIについて整理 今日の話はなぜかAIの話につながります AI時代はロングコンテキストで価値出せないと 生き残れないので領域を広げざるを得ない という話に繋がっていきます エンジニアの思考法はなぜ技術の外でも通用するのか
14. ロングコンテキスト問題 by みやっち AIについて整理 エンジニアの思考法はなぜ技術の外でも通用するのか
15. AIはもはや人間を超えた AIはもはや人間を超えました(×10) ショートコンテキスト（局所的な課題）においては、 もはやミドルクラス以上の思考力を持つ 局所のコード生成、要約、翻訳、論理構築... 単純なスキル勝負では、人間は分が悪い AIについて整理 エンジニアの思考法はなぜ技術の外でも通用するのか
16. AIの唯一にして最大の弱点 「ロングコンテキスト」の保持ができない 全体の文脈、過去の経緯、複雑な利害関係、 未来へのプライオリティ... AIは超優秀だけど記憶喪失だし価値判断もできない天才 これらを繋ぎ続け、整合性を取ることは まだ人間にしかできない AIについて整理 エンジニアの思考法はなぜ技術の外でも通用するのか
17. もはやコンテキストを広げていくことは既定路線 広げるか深めるかの２択 ポジショントークだけど広げにいくことを推奨したい そしてそれは多分エンジニアが得意 という話をしてきます AIについて整理 エンジニアの思考法はなぜ技術の外でも通用するのか
18. エンジニアの 3つの思考の型 2 エンジニアの思考法はなぜ技術の外でも通用するのか
19. エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアが日々鍛えている3つ思考の型 ① 具体と抽象を往復する力 ② 動かないコードに向き合う自責思考 ③ 複数の前提を保持するコンテキスト力 この3つは、コードを書き続けていれば日々鍛えられている
20. エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアが日々鍛えている3つ思考の型 ① 具体と抽象を往復する力
21. 型①具体と抽象の往復 実際にやっていること 1行のコード(具体) ↔ 設計(抽象) SQLクエリ(具体) ↔ ドメインモデル(抽象) 実装の細部(具体) ↔ アーキテクチャ(抽象) 1日に何十回も、両端を行き来している エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
22. 型①具体と抽象の往復 何が起きているのか 抽象↔具体への落とし込みを脳内シミュレーションしている 「そもそも何がしたいんだろうか？」 「この実装で要件網羅できてるかな？」 「例外ケースまでカバーできてるかな？」 一つの要件をカバーできるだけではダメで、現実の複雑さを 抽象化した上で具体に落とし込み実現する必要がある エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
23. 型①具体と抽象の往復 エンジニアリング文脈以外でどう効くか 例えば事業は具体と抽象の行き来の連続 事業計画(抽象) ↔ 機能リリース(具体) 戦略(抽象) ↔ 現場メンバーが話している言葉(具体) 絶えず行き来し、抽象論でも具体だけでも不十分 どの職種でも大事な能力だけど 特にエンジニアはキャリアの初期からこの訓練を積める エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
24. エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアが日々鍛えている3つ思考の型 ②動かないコードに向き合う 自責思考
25. 型②動かないコードに向き合う自責思考 実際にやっていること コンパイラは嘘つかないし間違えない ということは「動かない」のは、自分が間違っている 動く時は動く、動かない時は動かない。曖昧さがない 言い換えるとエンジニアは高頻度で 「お前は間違っている」と突きつけられる仕事 エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
26. 型②動かないコードに向き合う自責思考 何が起きているのか 他責にする余地が物理的にない 「自分が間違っているかもしれない」が標準装備になる →健全な猜疑心 細かいPDCAが高速で回る →間違いの数だけ、合っているも積み上がる 「訓練と思わずに訓練できていた」構造 エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
27. 型②動かないコードに向き合う自責思考 エンジニアリング文脈以外でどう効くか 数字が悪くても、市場や上司や部下を先に疑わない 「自分の前提のどこが間違っているか」から探す 仮説検証のサイクルが、事業のデバッグにそのまま効く AIが悪いのではなく指示を出している自分が悪いという思 考を持ちやすい 最後は自分の手で何とかするラストマンの覚悟 エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
28. エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアが日々鍛えている3つ思考の型 ③ 複数の前提を保持する コンテキスト力
29. 型③複数前提のコンテキスト力 実際にやっていること 変数のスコープ、依存関係、状態遷移を保持して1行を書く レイヤー間の前提(認証、トランザクション、副作用)を同 時に抱える 既存コードの文脈を読みながら、新しい行を足す ロングコンテキストを頭の中に保持し続けている エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
30. 型③複数前提のコンテキスト力 何が起きているのか 複数の制約・前提を保持しながら最適解を探る 手段が目的化しない/常に上位の意図と接続している ショートコンテキスト(目の前の行) ロングコンテキスト(全体の文脈) を行き来せざるを得ない 「1聞いて10わかる」の正体 = 保持している前提の広さ エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
31. 型③複数前提のコンテキスト力 技術の外でどう効くか 短期↔長期/技術↔事業/個人↔組織 を同時に抱えて判断できる 事業全体というロングコンテキストを保持出来る 複数ステークホルダーの利害を保持したまま意思決定する 1章で見た「AI時代に人間に残る主戦場」そのもの エンジニアはコードを書きその筋肉を毎日鍛えていた エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか
32. エンジニアの3つの思考の型 エンジニアの思考法はなぜ技術の外でも通用するのか 参考記事です
33. 統合力を鍛えるために何 ができるか 3 エンジニアの思考法はなぜ技術の外でも通用するのか
34. 「訓練と思わずに訓練できていた」時代の終わり これまで: 3つの型で毎日鍛えられていた これから: AIで「悩む時間」が奪われ統合力訓練機会が減る 仮説: ミドルまで半分、シニアまで3倍の時間がかかるようになる 訓練の場を、自分で意識的に作りに行く必要がある これから具体的な訓練の取り組みを4つ提案します 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
35. 取り組み① 自分のサービスを持つ ★最推し AIで企画→設計→実装→公開→運用まで一人で回せる時代 「作ってみた」で止めず「運用してみる」までやる 3つの型を同時に使わざるを得ない場ができる 動かないものに自責で向き合う 複数ステークホルダーに向き合う 具体と抽象を行き来する 続けることの難しさを知ることで世界の解像度が上がる 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
36. 取り組み① 自分のサービスを持つ ★最推し 難しいと思いますか？コツを教えます！ 最初からお金をもらおうと思わなくていいです！ お金もらおうと思うと色々ややこしくなる。 とにかく半径３mの人に使ってもらえそうなものを作る！ 自分が欲しいものでいいが人に使ってもらうことも大事！ お金をもらうのはまた別の技術なので分割して学ぼう！ 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
37. 僕の場合はこんなの作りました 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
38. 100件単位で使われたり後続の講座に繋げられたりした 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
39. 参考記事です 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
40. 取り組み② 言語化と発信を続ける 毎週noteを書く / 日報を残す / SNSで発信する 「言語化された資産」を手元に貯めていく 言語化が苦手ならAIに助けてもらう(箇条書きでも話が飛ん でてもOK) 具体↔抽象の翻訳訓練 自分のコンテキストをAIに渡す素材作り 柳川の例: 毎週noteを書く。アウトプットというより、自 分のコンテキストを言語化する儀式 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
41. 参考記事です 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
42. 取り組み③ 自分の意志をAIに乗せる(Skill/Gem化) Skillsを作る 自分の判断軸・前提・口癖をAIに教え込む ショートコンテキストの作業を任せられる相棒が増える Option(AIが出す)vs Decision(自分が引き受ける)を日常 で体感する場になる 育てる過程そのものが、意志を編む練習 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
43. 参考記事です 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
44. 取り組み④ 越境して人と話す 自社のBiz/営業/CSの人と、雑談ではなく事業の話をする 他社の事業責任者と話す機会を作る(勉強会・登壇・SNS) 違う前提を持った相手と話すと自分の前提が浮かび上がる AIだけで完結させない人と話す摩擦が、器を育てる 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
45. 取り組み⑤ 未来の構造を考えてみる 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか 未来の組織図を考えて備えてみる
46. (仮説)未来の組織図：「人月AI管理者」への進化 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
47. (仮説)未来の組織図：「人月AI管理者」への進化 AIに「働かされる」準備をせよ AIは文句も言わず、爆速でアウトプットを出してくる 人間の役割は、AIに適切な「ショートコンテキスト」を切 り出して渡すこと 新しい役割：人月AI管理者 10人のAI部下（特化型AI）を並列に働かせる 求められるのは、AIの速度に負けない「早い思考」と、全 体を統合する「ロングコンテキスト」 オフショア管理やSIerのPMに近い（ただし相手は爆速） 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
48. 「人月AI管理者」おもしろいよ AIマネジメントの特徴 人間相手より楽な点 AIは品質のブレが少なく育成（学習）も早い 人間相手よりキツイ点 AIはレスポンスが爆速です 自分がボトルネックにならないよう脳みそをフル回転させ続け なければなりません 疲れますし向き不向きもある 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
49. 「人月AI管理者」おもしろいよ 「人月AI管理者」という仕事 「AIの管理？ 誰でもできるでしょ？」 「保守的な退屈そうな仕事？」 「そういう仕事こそAIにやらせるべきでは？」 そんなことない AIに「ロングコンテキスト」は求めず、そこは人間が担保する これは 「AIに働かされているようでいて 実は人間にしかできないコンテキスト管理をフル回転で行う」 ことなのだ 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
50. ボトルネックは「AI」ではなく「人間の意志」 AIは選択肢（Option）は出せるが、決断（Decision）はできない 合理的な正解だけなら、全員同じ結論になる（コモディティ化） 差別化要因は「非合理な意志（これがやりたい）」だけ ロングコンテキストの維持には「意志」が必要 膨大なコンテキストの中から、何を選び、何を捨てるか それを決めるのはロジックではなく「意志」 意思っていうとふわふわしているけれども、要するに強弱です 忘れることとかも含めて大事！ コンテキストの容量が増えればいいという話ではない 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
51. エンジニアは本当の意味での「ラストマン」 エンジニアの宿命 トラブルが起きたら、最後に直すのはエンジニア 物理的な最終防衛ライン。「動かない」という事実からは逃 げられない その覚悟を拡張する AIが出してきたアウトプットの責任を、自分が取る 事業の数字（PL）が悪かったら自分の責任として受け止める 「最後は自分の手でなんとかする」という覚悟だけが、人を リーダーにする 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
52. あえてギャップを言うならば 不確実なことへの耐性の低さ ビジネスにおける争いは「正しいvs正しい」ばかりなのである その中でどう決めるか、どう進むか 気が張っちゃうのはわかる それこそラストマンシップの裏返しだと思う 不確実な時にどしっと構える強さ 強さとかいうと精神論だけど、時間軸を長く持つというのは大事 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
53. 参考記事です 統合力を鍛えるために何ができるか エンジニアの思考法はなぜ技術の外でも通用するのか
54. ビジネスモデルは 何にせよ大事 4 エンジニアの思考法はなぜ技術の外でも通用するのか
55. 「ビジネスの勉強」はしなくていいがビジネスモデルは大事 よくある言説としてエンジニアも 「PdMをやれ」「FDEになれ」「PLやBSを学習せよ」 うんざりする。肩書きや知識では事業は動かない 役割に合わせてビジネスモデルができることはあり得ない ビジネスに必要なので役割が生まれる ビジネスモデルそのものが自分の道を探すヒントになる ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
56. ビジネスモデルは単価×件数×お金のもらい方で紐解く 軸は単価(高/低) × 件数(多/少) × キャッシュポイント 組み合わせで有効なアプローチが変わる ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
57. 低単価×多件数(マス向け) スケールするオペレーションとUXに投資する必要がある 個別対応はやらない、というよりやってはいけない 例 SMB向けSaaS/プラットフォーム/to Cサービス ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
58. 高単価×少件数(エンタープライズ) 一つ一つの顧客に深く入り込んででも顧客獲得するべき オーダメイドやセミカスタムを行ってもビジネスが成立す る、むしろやらなければ顧客獲得できない 例 SIer/Palantir型セミオーダーSaaS(FDE) ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
59. どうやってお金を頂くのか キャッシュポイント 直接費用を頂くor広告費用などで間接的にお金を頂くetc 何に対してお金を頂くのか 利用に応じて(BASE)or月額(SaaS)or人月(SIer)なのか ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
60. まずは個人として3つの問いに答えられるか ① あなたの会社は 「どうやってお金をもらっているか」 ② 「何が差別化要因か」 ③ 「その差別化に自分がどう貢献して、どう差を作るか」 ビジネスモデルというと難しげだが、まずは自分を主語と した自分の半径から始める(PLとBSから入らない) ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
61. しっくりくるビジネスモデルを探そう 3つの問いへの自分なりの答えを持つことが 自分なりのナラティブ(物語)を持つということに繋がる ナラティブを語るには自分の価値の定義が大事 ビジネスモデルがしっくりくるかどうかが大事 柳川の例 SIer→広告配信→ECプラットフォーム それぞれ経験したことで自分に合う型が見えて自分なりの ナラティブが語れるようになった 副産物:ナラティブはロングコンテキストの圧縮装置になる ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
62. 前提:あなたの会社は凄い！ あなたを採用できるって凄い！ それってビジネスモデルが完成していて儲かっているって こと！凄いことですよ！！ 絶対に学ぶべきことがあります！ まずは自社のビジネスモデルに詳しくなりましょう！ ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
63. 参考記事です ビジネスモデルは何にせよ大事 エンジニアの思考法はなぜ技術の外でも通用するのか
64. 自分の頭で考えることの 大切さと 難しさと 愛おしさと 終 エンジニアの思考法はなぜ技術の外でも通用するのか
65. 自分の頭で考えることの大切さ・難しさ・愛おしさ 大切さ: 意志は最後まで人間にしか持てない Decisionを引き受けるのは人間 難しさ: 答えっぽいものに会うと、人は考えなくなる AI時代の最大の罠 愛おしさ: 思い詰めて考えた時間こそが、自分を形作る 「悩む時間は無駄ではなく贅沢」 自分の頭で考えることは無駄じゃないしコスパ悪くない 車輪の再発明上等 自分の頭で考えることの大切さと難しさと愛おしさと エンジニアの思考法はなぜ技術の外でも通用するのか
66. 「器」を育てるための矛盾を抱えて進む力 視座の変化言い換えると「器」の拡大に向き合うしかない AI＊人間の掛け算でアウトカムが変わる時代 そしてAIは履歴書に書けるスキルは全て代替していく 人間は履歴書に書けないスキルを強化していくしかない それを「器」と呼ぶ 自分の頭で考えることの大切さと難しさと愛おしさと エンジニアの思考法はなぜ技術の外でも通用するのか
67. 水平的成長から垂直的成長へ スキルを増やすだけではなく視座を上げる 自分の頭で考えることの大切さと難しさと愛おしさと エンジニアの思考法はなぜ技術の外でも通用するのか
68. 育てているのは「器」 ── 矛盾を抱えて進む力 単純化した一様な答えで誤魔化せなくなる 「矛盾を感じ、抱え、進む」ことが大事 器を育てる文化的装置(終身雇用・師弟関係)が弱体化した 今AIは新しい鍛錬パートナーになりうる 僕はこのテーマを複眼道場という個人活動で扱っています (エニアグラム × インテグラル × AI) 自分の頭で考えることの大切さと難しさと愛おしさと エンジニアの思考法はなぜ技術の外でも通用するのか
69. エンジニア役割変化するの？ エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアの役割はどこまで広がっているのか
70. エンジニア役割変化するの？ エンジニアの思考法はなぜ技術の外でも通用するのか エンジニアの役割はどこまで広がっているのか あなた次第でどこまででも広がる 自分なりの物語を持て！！
71. THANK YOU 🎉 少しでも領域を広げていく気持ちを持ってもらえたら嬉しいです 誰にも期待されていないことを自分が必要だと思うからやる そんな仲間が増えて欲しいです！一緒に頑張ろ！ 手を動かせる奴が一番偉い！型にハマるな！