2026.6.27_プロダクトヒストリーカンファレンス2026_登壇資料

Transcript

1. AI時代。 それでも組織で開発したい プロダクトが、ここにはある。 マルイユナイト CTO 巣籠 悠輔
2. 巣籠 悠輔 略 歴 • 東京大学・大学院在学中に Readyfor、Gunosy の立ち上げメンバーとしてアプリ 開発に従事。 • 株式会社MICINを共同創業。CTOとして医療画像・ヘルスケアデータを活用した AI開発、およびオンライン診療アプリの開発に従事。 Forbes 30 Under 30 Asia 選出。 • エグジット後、ベンチャー企業を中心に複数社のCTO・技術顧問等を務める。 • 東京大学招聘講師としてディープラーニングの理論および実装の講義を担当。 日本ディープラーニング協会 有識者会員としてG検定のテキスト執筆・問題作成 に従事。 • 著書に『詳解ディープラーニング』『ディープラーニングG検定 公式テキスト』等。 • 2024年にマルイユナイト参画。2025年よりマルイユナイトCTO。 2026年より丸井グループCTO。 Y U S U K E S U G O M O R I
3. 2024年9月に立ち上がった、丸井グループのテックカンパニー
7. メッセージ： 個人は、ユーティリティをつくる。 組織は、つくれる人を増やし、価値循環を育てる。 AI時代に組織で開発したいのは、便利な機能そのものではなく、 人が集まり、関係性・信頼・文化が循環するコミュニティである。 7
8. P A R T 1 組織で開発したいプロダクトとは何か？ 個人はユーティリティをつくる。組織は価値循環を育てる。 P A R T 2 そのプロダクトを生む開発組織はどう変わるのか？ コードを書く組織から、プロダクトが生まれる仕組みをつくる組織へ。 8
9. P A R T 1 組織で開発したいプロダクトとは何か？ 個人はユーティリティをつくる。組織は価値循環を育てる。 P A R T 2 そのプロダクトを生む開発組織はどう変わるのか？ コードを書く組織から、プロダクトが生まれる仕組みをつくる組織へ。 9
10. ユーティリティは、個人でも作れるようになった かつて開発には専門的な実装力と組織が必要だった。 いまはAIによって、個人でも短時間でユーティリティをつくれる。 課題を見つける AIと要件化・実装する 個人でも、使えるものが作れる 解法が増え、代替される ⇒ 便利なものを作れること自体は、希少性を失っていく 10
11. AIエージェント・BtoA時代の到来 これからは、人がサービスを探すだけではない。 AIエージェントが、探索し、比較し、推薦し、取引する。 B E F O R E 人が探す → 人が選ぶ → 人が使う A F T E R AIが探す → AIが比較する → 人が承認／利用する プロダクト設計は、BtoC だけでなく、BtoA / BtoAtoC を前提に変わっていく。 ⇒ AIに発見されないサービスは、存在しないのと同じになっていく 11
12. ユーティリティだけのプロダクトは、なぜ苦しくなるのか 機能だけなら、すぐに模倣される 価格だけなら、すぐに比較される 便利なだけなら、AIがより良い代替案を探してくる AIエージェントは、感情よりも構造化された条件を読む ⇒ ユーティリティだけのプロダクトは、AIに比較される市場に飲み込まれやすい 12
13. ここで問いが変わる 「何を作るか」ではなく、 「何が蓄積されるプロダクトを作るか」 機能は作れる UIも真似できる コンテンツも増やせる でも、時間をかけて蓄積される関係性・信頼・文化は、すぐには作れない ⇒ 組織で開発する意味は、蓄積される価値を設計・運営することに移る 13
14. 個人はユーティリティ。組織は価値循環。 個人で作りやすいもの 課題を解く機能 小さく便利なユーティリティ すばやく試せるプロダクト 組織で育てたいもの 人が集まる場 関係性・信頼・文化 安心して継続できる価値循環 ⇒ 組織の仕事は、便利を作るだけでなく、便利が人を集め、関係性へ育つ構造を作ること 14
15. 組織で開発したいプロダクトとは 使われるだけでなく、人が集まり続けるプロダクト 利用が、参加に変わる 参加が、関係性に変わる 関係性が、信頼に変わる 信頼が、購買・推薦・共創に変わる その循環が、プロダクト価値を増幅する ⇒ コミュニティは、プロダクト価値を増幅する 15
16. ただし、コミュニティは自然発生では経済圏にならない 熱量は価値を生む。でも、熱量だけでは持続可能な経済圏にはならない。 盛り上がりは起きるが、放っておくと分断・炎上・不信も起きる 参加者が増えるほど、ルール・安全性・継続運営が必要になる 価値が増幅するほど、信頼設計が必要になる 企業が担保するもの 安全性 信頼性 継続性 公平性 責任性 ⇒ 企業は、その増幅を、安心して継続できる経済圏へ変換する 16
17. AI時代に、組織が育てるべきものは、単体のユーティリティではなく、 人が集まり、関係性・信頼・文化が循環するコミュニティである。 丸井グループが掲げる「『好き』が駆動する経済」 それは、AI時代の組織プロダクト開発の方向性と重なる。 ⇒ 個人は、ユーティリティをつくる。 組織は、「好き」が価値循環へ育つ場をつくる。 17
18. AI時代のプロダクト構造：2階建てモデル 2F コミュニティ／プラットフォーム層（価値増幅層） 好きが、関係性・信頼・文化として増幅する / 時間と共に強化され、模倣困難 コミュニケーションデザイン（横断） 好きが発見され、伝わり、参加に変わる導線 / 人にもAIにも読まれる意味設計 1F ユーティリティ層（価値成立層） 好きが、利用・購買・取引・データとして成立する / 技術で代替可能、参入障壁は低い ⇒ 1F＝必要条件 ／ 2F＝選ばれ続ける理由 ／ 横断＝循環を起動する設計 18
19. 1F：ユーティリティ層 好きが、利用・購買・取引・データとして成立する基盤 1Fで必要なもの 課題を解く機能 使いやすいUX 価格・在庫・条件・予約・決済の明確化 構造化データ、API、メタデータ AIエージェントに発見・比較・取引される設計 ⇒ 1Fは、AI時代の生存条件 19
20. 1Fだけでは、組織で作る必然性が弱くなる 1Fは必要だが、1Fだけでは差別化しづらい AIに読まれるほど、比較もされやすくなる 価格・機能・スピードの競争に巻き込まれる 個人でも作れる領域が広がるほど、組織の存在理由は問われる ⇒ 1Fは「入口」だが、組織で開発したい理由そのものにはなりにくい 20
21. 2F：コミュニティ／プラットフォーム層 好きが、関係性・信頼・文化として増幅する場 2Fで起きること 同じ熱量を持つ人同士がつながる 体験・情報・意味が共有される 参加者同士の関係性が生まれる 信頼と文化が蓄積される 購買・推薦・共創が自然に起きる ⇒ 2Fは、AIでは代替しにくい価値増幅層 21
22. 2Fがあるから、組織で開発したくなる 2Fは、短期間でコピーできない 2Fは、運営・安全性・信頼性・継続性を必要とする 2Fは、プロダクトを「道具」から「場」へ変える 2Fは、企業のアセットを横断して価値をつなげられる ⇒ 組織で開発したいプロダクトとは、ユーティリティを入口に、コミュニティ／プラットフォームへ育つ プロダクト 22
23. コミュニケーションデザインがすること 好きが、発見され、伝わり、参加に変わる導線を設計する 招き入れる言葉をつくる 出会う接点を設計する 「自分ごと」になる語り方をつくる 次の行動を促す 体験が共有される仕掛けをつくる 参加者の声を、場の改善に還す ⇒ コミュニケーションデザインは、1Fと2Fをつなぐ階段／循環設計 23
24. コミュニケーションデザインは「広告」ではない 広告・告知 伝える コミュニケーションデザイン 発見される 意味が伝わる 参加したくなる 続けたくなる 誰かに話したくなる 場に戻ってきたくなる ⇒ 企業に必要なのは、発信量ではなく、1Fの利用が2Fの参加へ変わる導線設計 24
25. 価値循環として見る ユーティリティを使う 意味が伝わる 自分ごとになる 参加する 誰かとつながる 購買・推薦・共創が起きる 関係性・信頼・文化が蓄積する また使いたくなる／関わりたくなる ⇒ この循環を設計することが、組織でプロダクトを開発する理由になる 25
26. AIに読まれる設計と、人に響く設計を両立する AI — AI-readable 発 見・ 比較 ・推 薦 ・取 引さ れ る 構造化データ、API FAQ、レビュー 在庫・価格・条件 実績 人 — Human-resonant 共感・参加・継続・推薦され る 物語、世界観 参加導線 コミュニティ文化 安心感 ⇒ BtoA時代のコミュニケーションデザインは、AI-readable と Human-resonant の両立が必要 26
27. Part 1 のまとめ コミュニティは、プロダクト価値を増幅する。 企業は、その増幅を、安心して継続できる経済圏へ変換する。 個人は、ユーティリティをつくる。 組織は、価値循環を育てる。 それが、AI時代にそれでも組織で開発したいプロダクトである。 27
28. P A R T 1 組織で開発したいプロダクトとは何か？ 個人はユーティリティをつくる。組織は価値循環を育てる。 P A R T 2 そのプロダクトを生む開発組織はどう変わるのか？ コードを書く組織から、プロダクトが生まれる仕組みをつくる組織へ。 28
29. ここまでの話を、開発組織に戻す Part 1 では、プロダクトの構造を話した。 2 F コミュニティ／プラットフォーム コミュニケーションデザイン（横断） 1 F ユーティリティ ⇒ では、そんなプロダクトを生む開発組織は、どう変わるべきなのか？ 29
30. 価値循環を育てるプロダクトは、エンジニアだけではつくれない 顧客を知っている人 売場を知っている人 業務を知っている人 コミュニティの熱量を知っている人 ブランドや事業の文脈を知っている人 ⇒ その人たちの意図が、できるだけ直接プロダクトに変わる組織が必要になる 30
31. AI時代の開発組織は変わる コードを書く組織から、プロダクトが生まれる仕組みをつくる組織へ エンジニアの仕事は、実装そのものから、 実装が生まれる構造を設計することへ広がる。 ⇒ 組織で開発する価値は、コードを書く人数ではなく、多様な意図がプロダクトになる仕組みに宿る 31
32. マルイユナイトで進み始めている開発フロー → ビジネスサイドメンバーが Slack Bot に Mention Bot と開発したい内容をすり合わせる 要件が固まったら OK AIエージェントが自動開発 ephemeral build まで自動生成 すぐに触って確認できる 32
33. これは「AIがコードを書く」だけの話ではない 重要なのは、ビジネスサイドの意図が、会話を通じて、動くプロダクトに変わること。 Slack Bot は、ただの受付窓口ではない。 R O L E 「こうしたい」 → 要件に変換 → 開発可能な粒度に整える → 確認・承認・実装へ接続 ⇒ Slack Bot は、意図を動くプロダクトへ変換するインターフェースである 33
34. 組織で開発する楽しさは、レバレッジにある 01 多様なチーム人材によるレバレッジ 顧客・売場・業務・コミュニティを知る人の知見が、開発に直接入る 02 AIエージェントによるレバレッジ 実装・修正・ビルド・検証の一部が自動化され、試行回数が増える 03 仕組みによるレバレッジ エンジニアがワークフローやパイプラインを設計し、組織全体の開発力が上がる 34
35. レバレッジ1：多様なチーム人材 価値循環を育てるプロダクトには、エンジニア以外の知見が不可欠になる。 顧客の変化を知っている人 売場や運用を知っている人 業務の痛みを知っている人 コミュニティの熱量を知っている人 事業の意思決定を担う人 ⇒ AIが要件化と実装を支援することで、これらの知見がプロダクトに入りやすくなる 35
36. レバレッジ2：開発の自動化 AIエージェントによって、開発の一部は自動化されていく。 要件整理 実装 修正 ビルド テスト 検証環境の生成 フィードバック反映 ⇒ 自動化の価値は、単に速くなることではない。試行回数が増えることである 36
37. レバレッジ3：仕組みをつくる エンジニアは、コードが安全に生まれる仕組みをつくる人になる ワークフロー パイプライン 承認プロセス コンテキストの渡し方 自動化の境界 失敗を小さく閉じる仕組み 組織の誰もが使えるインターフェース 37
38. エンジニアは、仕組みをつくる AIがコードを書けるようになるほど、エンジニアの価値は「手で実装すること」だけではなくなる。 必要になるのは どこまでAIに任せるか どこで人が承認するか どう安全にビルドするか どう検証可能にするか どう失敗を小さく閉じるか どう組織の誰もが使える流れにするか ⇒ エンジニアは、プロダクトをつくる人であると同時に、プロダクトが生まれる仕組みをつくる人になる 38
39. プログラミング的思考は、細部から構造へ移る これまで 具体的な処理手順を細かく書く 例外ケースをコードで潰す 実装者の手元で完結する これから 目的を言語化する 制約を定義する 状態遷移を設計する AIが判断できるコンテキストを渡す 人間の承認点を設計する ⇒ AIは細かな実装をセマンティックに解決する。だから人間は、より上位の構造を設計する 39
40. Human in the Loop は、ただの承認ではない AIに任せるほど、人間の関与点の設計が重要になる。 いつ人が確認するのか 何をもって OK とするのか どのリスクは自動化してよいのか どの変更は必ず人が見るべきなのか どうすれば失敗を小さく戻せるのか ⇒ Human in the Loop は、責任と学習を組織に残すための設計である 40
41. 開発組織そのものも、2階建てになる 2F 開発コミュニティ層 多様な人の知見・意図・熱量が、プロダクト改善に参加する ↑ コミュニケーションデザイン 意図を要件へ、要件を実装へ、フィードバックを改善へ ↓ 1F AI開発基盤 要件化・実装・ビルド・検証を支える自動化された開発フロー ⇒ プロダクトだけでなく、開発組織そのものも2階建てで考える 41
42. 1F：AI開発基盤 要件化・実装・ビルド・検証を支える自動化された開発フロー AIエージェント リポジトリ接続 開発環境の自動構築 テストと検証 ephemeral build ログとトレーサビリティ 権限管理とセキュリティ 承認フロー ⇒ この基盤があることで、プロダクト開発の試行回数が増える 42
43. 2F：開発コミュニティ層 多様な人の意図が、プロダクト改善に参加する場 本当に重要なのは、誰の意図がプロダクトに入るか。 ビジネスサイド エンジニア デザイナー 店舗・運用メンバー 顧客に近い人 コミュニティを知る人 ⇒ 多様な人が参加することで、プロダクトは現場と顧客に近い価値循環へ近づく 43
44. 開発におけるコミュニケーションデザイン 「こうしたい」 対話によって意図を明確にする 要件に変換する 実装可能な粒度に分解する AIエージェントが開発する ephemeral build で触って確認する フィードバックする 次の改善につながる ⇒ コミュニケーションデザインは、意図がプロダクトに変わる導線になる 44
45. 開発組織を、プロダクトとして設計する AI時代、開発組織は単なる人員配置ではない。 それ自体が、プロダクトが生まれるためのシステムである。 誰が参加できるか どこから要望を出せるか どう要件化されるか どの粒度で確認できるか どこで人が判断するか どう学習が蓄積されるか ⇒ 開発組織そのものを、価値循環を生むプロダクトとして設計する 45
46. 組織で開発するとは、開発できる人を増やすこと AI時代、個人でもユーティリティはつくれる。 だからこそ、組織の開発力は、エンジニアの人数だけでは決まらない。 組織の開発力は、多様な人の意図を、 安全に、速く、何度も、プロダクトに変換できる仕組みで決まる。 エンジニアは、その仕組みをつくる。組織は、その仕組みによって価値循環を育てる。 46
47. Part 2 のまとめ AI時代の開発組織は、コードを書く組織から、 プロダクトが生まれる仕組みをつくる組織へ変わる。 エンジニアの仕事は、実装そのものから、 実装が生まれる構造を設計することへ広がる。 ⇒ それが、組織で開発する楽しさであり、AI時代の開発組織のレバレッジである 47
48. まとめ P A R T 1 組織で開発したいのは、ユーティリティを入口に、価値循環へ育つプロダクト。 P A R T 2 そのプロダクトを生むには、開発組織も、プロダクトが生まれる仕組みへ変わる必要がある。 個人は、ユーティリティをつくる。 組織は、つくれる人を増やし、価値循環を育てる。 48
49. それでも組織で開発したい プロダクトが、ここにはある。 AI時代、個人はユーティリティをつくれる。 でも、組織には、人が集まり、関係性が生まれ、文化と経済圏へ育つプロダクトをつくる力がある。 そして組織には、多様な人の意図を、プロダクトへ変換する仕組みをつくる力がある。 49
50. 個人は、ユーティリティをつくる。 組織は、つくれる人を増やし、 価値循環を育てる。 AI時代。それでも組織で開発したいプロダクトが、ここにはある。
51. Thank you