2026年2月18,20日の2日間、東京で開催された「Developers Summit2026」に参加してきました！
1日目はPM向けセッションも多く、まるっと1日全セッション参加してきました。
去年はオンラインでWomanデブサミ参加したんですが、現地参加はなんと10年ぶり😮
目黒でやってた時代だね
長年提供される機会、本当にありがたい🙏
株式会社翔泳社 CodeZine編集部／ProductZine編集部の皆さま、ありがとうございます！
そして、どまんなかの催しを提供くださったコンテンツ委員の皆さま、今すぐやりたくなる現場ですぐ活かせる知見やヒントをくださった登壇者の皆さま、ありがとうございました！お疲れ様でした👏
コミュニティの繁栄に共感して協賛といったかたちで関わられたあらゆるスポンサーの皆さまもありがとうございました。すべての関係者に感謝〜〜
このブログでは手元で取ったメモ1万文字（疲れたょ…）をベースにした私的な意見をまとめます。
1. 既存に「足す」のではなく「AIネイティブ」で考える
（18-A-1 AI時代のプロダクトと開発 - 経営と開発の“両輪”で考えるAIネイティブ戦略
今村 雅幸[日本CTO協会 / バイセルテクノロジーズ]/泉 雄介[日本CTO協会 / UPSIDER]/梶原 大輔[日本CTO協会 / GENDA]）
既存機能にAIを付け足すのではなく、最初から「AI前提」で作るというパラダイムシフトの話。個人的に一番耳が痛かったのは、AIによるコード生成が爆速になった結果、「次のボトルネックは、企画が決められない・レビューが追いつかない人間側にある」という指摘でした。
-
AI環境下では、6〜10人ではなく3人程度の「1ピザチーム」で動くほうが生産性が高いことを意識する。
-
シニア層のレビュー詰まりを防ぐため、テスト生成や設計の整合性チェックにもAIを組み込んでプロセス自体を見直す。
2. 複雑な現実とシンプルなUIを切り分ける「建築的思考」
（18-A-2 リゾーム構造をツリー構造へ落とし込む設計技術──DBとUIを整合するInformation Architectureの脱構築
中沢 大[Dress Code]）
複雑に絡み合う現実の業務（リゾーム構造）を、ユーザーが操作しやすい階層的なUI（ツリー構造）にどう翻訳するか。動かしにくい「基礎・構造」と、動かしやすい「家具（UI・機能）」を分けるという建築のアナロジーがすごく腑に落ちました。
-
1つの画面に機能を詰め込みすぎる「ユニットバス・アーキテクチャ」から脱却する。
-
UIを描く前に、まずは「情報の関係性」を徹底的に洗い出す手順を踏む。
3. 「誰の責任？」という感情論をデータで終わらせる
（18-B-4 『誰の責任？』で揉めるのをやめて、エラーバジェットで判断するようにした ～感情論をデータで終わらせる、PMとエンジニアの意思決定プロセス～
川崎 雄太[ココナラ]）
障害が起きたとき、失敗を個人の責任にするのではなく「エラーバジェット（失敗を許容できる予算）」という共通言語を作るアプローチ。これがあれば、攻めるPMと守るエンジニアが同じテーブルで平和に（かつ建設的に）議論できるようになります。
-
MTTRなどの技術指標を、「意思決定リードタイム」や「施策の撤回率」など、ビジネス側が理解できる言葉に翻訳する。
-
データに溺れないよう、追うべき指標は「マジックナンバー3つ」に絞る。
4. プロダクトアナリティクスの民主化
（18-A-5 プロダクトの「意思」をデータとAIで実装する──現場が自走するプロダクトアナリティクス
津久井 英樹[Amplitude Analytics]）
自然言語での深掘り調査が可能になり、SQLが書けなくてもデータ分析ができる時代になりました。「データに基づく意思決定」のハードルが圧倒的に下がっている話。
私もお世話になっているAmplitudeのお話だった。
これからもユーザーとしてたくさん事例を作って良きDiscoveryをして価値を届けられるように頑張りたいぞ💪
5. 正論だけでは動かない「組織の壁」の正体
（18-C-6 Beyond your Code：「合理的に話してるはずなのに伝わらない」はなぜ起きるのか？― 大企業×ベンチャーJVを1年経営して学んだ「合意形成」の実践知 ―
木下 寛大[Wellnize]）
データもROIも完璧なのに「ん〜なんか違うんだよね」と反発される理由を、人間社会の構造（文化人類学）から紐解く激アツなセッション。
「合理性＝正統性ではない」という事実は、変革を進めたいすべての人の救いになる視点でした。ここはAIには代替できない人間の領域ですね。
- なぜ、合理的に話しているはずなのに伝わらないのか？
- 合理性≠正統性
- 合理的なことはいいことだというCODEを内面化していると同一視しがち
- 人間めんどくせぇって思ってきたよね
- だからこそ、人間に向き合うことの価値が高まっていて、PMの重要性が高まっている
6. AIネイティブ時代の「攻め」と「守り」
（18-C-7 AIネイティブ時代のプロダクト戦略 ～既存SaaS領域への破壊的参入と防衛の定石・新規AI領域の開拓～
宮田 善孝[Zen & Company]/中出 昌哉[テックタッチ]）
既存のSaaSがAIにどう立ち向かうかの攻防戦。「SaaSの構造化データや権限管理の壁は厚いからすぐには死なない（守り）」という意見と、「機能のツギハギでは勝てないから、自己破壊的なアーキテクチャの作り直しが必要（攻め）」という視点を切り替えながらふたりの意見を引き出すやりとりがとても熱かった。
-
持ち帰った問い
-
「今のUIにチャットボットを足すだけ」の安易なAI活用になっていないか見直す
-
「もし今、自社製品をゼロからAI前提で作るなら？」という思考実験をしてみる
- TAM検証済み市場にAIファーストで参入する際、何を武器にするか？
- 逆にここは勝てるけど、ここは勝てなさそうってところは？
- 今のタイミングで攻めるべき市場は？
-
3日目
「Beyond the Code（コードの先へ）」というテーマは、技術（コーディング）そのものよりも、その裏側にある人間的な要素、ビジネスへの影響、あるいは技術がもたらす未来の可能性に焦点を当てたコンセプトです。
めちゃいいコンセプトだよね。激アツ。
7. AIで生産性が上がっているという「錯覚」
（20-B-1 なぜ、AIで生産性があがっていると錯覚してしまうのか？
広木 大地[レクター]）
コーディングが爆速になっても、要件定義や合意形成が残るため、全体の生産性は劇的には上がらない（アムダールの法則）。
逆に、AIの低い自律性に付き合うことで「認知負荷」が上がり、AI疲れを起こしているという指摘にはハッとさせられました。
「AIに都度指示を出す」という現在の疲弊する働き方から脱却し、「AIが自律稼働するためのルールとコンテキスト（文脈）の設計」に注力すること。そして、人間は「合意形成やインサイト獲得といった本質的な問題解決」へシフトすることが、真の生産性向上につながる。
まさに最近つかれているので、ここまで組み込まなければな〜とあらためて心を決めるきっかけになりました。
8. 息をするようにエージェントを作る2026年の開発体験
（20-A-4 2026年のAIエージェント構築はどうなる？
御田 稔（みのるん）[KDDIアジャイル開発センター]）
AIが「答える」だけでなく「ツールを操作する」時代。商談中に顧客の要件を聞きながら、その場でエージェントを作って見せる「Vibe商談」の概念は、仕事の進め方を根本から変えたねぇ。
クライアント時代、話を聞きながらそこで設計書作りながらイメージをすり合わせてたりしてたけど、やっぱ動くプロトタイプで見せたいよね。
-
「AIエージェント作ったことある人✋️」って聞かれたときに挙手したいがために開発しよっ！て心に決めた
9. 時代が変わっても揺るがない「コミュニティの力」
（20-C-9AI時代でも変わらない技術コミュニティの力～10年続く“ゆるい”つながりが生み出す価値～
タケハタ[Kotlin愛好会]/Roku[Swift愛好会]/七島 偉之[Swift／Kotlin愛好会]）
技術の進化が激しいからこそ、完璧な資料や時間厳守を求めない「がんばりすぎないユルさ」がコミュニティを10年長続きさせる秘訣。心理的安全性の高い場が、結果的にモチベーション維持や新たな機会創出につながっているという本質的なお話でした。
-
社内勉強会のハードルを極限まで下げ、「今詰まっていること」を飲み物片手に雑談ベースで話せる「談義スタイル」の会をやってみたい
まとめ
AIの進化が「How（どう作るか）」をどんどんコモディティ化させていく中で、私たちに残されているのは「What（何を作るか）」「Why（なぜ作るか）」…はもうほぼAIと一緒にリサーチもコンテキスト整理もしてるから、何よりも「それを実現するための人間関係の構築」なのだと改めて感じました。
なんかさ、この間まで「PMも企画もマーケターもSQL書けるようになるべき〜」みたいなこと言われてたのにさ、今では誰も言わなくなったよね😂
ただ、これに関しては教義が変わったわけではないと思って、教義の新解釈がされたって感じてる。
もうそれぐらい自然言語を使った専門性のある業務が可能になってきたから、同じビジョンに納得して動く信頼し合えるチーム関係であるべきって前提がとても大事になってるように思えてきた。
「技術力はあるけど気に入らねぇ奴」と仕事する必要はないってことだから、どんどん一緒に働きたくなる人間って？をしっかり考えないといけないですね。
