AIネイティブ時代における 開発組織の役割と拡張の可能性

2026/7/22に、Givery Summit 2026で発表した立花の資料になります。

Transcript

1. AIネイティブ時代における 開発組織の役割と拡張の可能性 株式会社リクルート 立花 優也 ※公開用に一部修正済の資料です
2. 立花 優也 住まい領域プロダクトデザイン1部 部長 プロダクトマネージャー 東京大学大学院にてシステム量子工学を専攻。 NTTドコモでのAI R&D・複数の大規模サービスの事業開発を経て 現職。現在は『SUUMO』の中長期プロダクト戦略立案を主導し、 Web・アプリ・リアル接点を統合したUX戦略を推進する。 「システム思考」を武器にビジネスの多目的最適化問題を解くこ とを信条とし、「論理と情緒」を統合した意思決定の実現に向け、 AI活用やデータ基盤の刷新、組織の構造変革をリードしている。 2
3. About Recruit リクルートにおけるAI活用について AI Native 住まい領域における、AIを前提とした組織・ プロセスの再設計 Agenda Issue AIネイティブ化を進める上での構造的な課題 Case 具体的な実践事例（3つの取り組み） 3
4. リクルートグループについて HR テクノロジー SBU マーケティング・マッチング・ テクノロジー SBU 人材派遣 SBU 4 参照：https://www.recruit.co.jp/employment/students/service/ 4
5. 出典：リクルートホールディングス 2026年3月期 第3四半期決算説明 https://file.recruit-holdings.com/files/ja/Recruit_202603Q3_presentation_jp.pdf 5
6. リクルートにおけるAI活用 事業・プロダクト 組織・プロセス 事業・プロダクトにAIを組み込み、 プロダクトづくりや事業運営そのものを どうAI ネイティブ化していくか どう成長させるか 6
7. 住まい領域における、 AIを前提とした組織・プロセスの再設計 7
8. 生産性を飛躍的に向上させるために、 AIを前提とした組織、プロセスにつくりかえる AIツールを導入するだけでは生産性は上がらない AIが下げたのは「How（作る）」のコスト。それは、現場から学ぶルー プを圧倒的な速度で回せるようになった、ということ プロダクトの作り方そのもの — プロセス自体の再設計に取り組んでいる 8
9. 目的は、「現場から学ぶループ」の回転数と質を上げること 企画する Why / What の定義 学び、賢くなる プロダクトと組織を更新 AIは、このループの つくる 全工程を速くした AIと共にプロトタイプ、プロダク ション 現場で試す ユーザー・現場の一次情報 役割の越境は、このループが回り始めた「結果」 ループを止めない設計こそが、組織の仕事 9
10. AIネイティブ化を進める上での 構造的な課題 10
11. プロセス上の課題 分業ワークフロー（PdM/Des/Eng）では、コミュニケーションコスト・待ち時間が必要だった また、情報の受け渡しの際にContextの消失が発生する 現実から学ぶループが、繋ぎ目のたびに減速・劣化する構造だった PRD Idea WF/Design 詳細設計書 PdM Des Eng Eng 要求 デザイン システム要件 コード Product コミュニケーションコストの発生 / コンテキストが一部欠損 11
12. AI時代のプロセス①（例） AIによって1人で実行できる幅が広がった 極論1人でend to endで企画からリリースまで実行できれば コミュニケーションコスト・待ち時間・ コンテキスト消失もない チームで進める場合も、高速で動くモノをつくれば解像度の高い議論ができる 人間 Idea Des Eng Prompt (要求) (Finalize) ※ 必要なら Prototype Product context design.md api.md 各種Doc 既存code 12
13. 複雑な制約条件にどう向き合うか AI×簡易プロトタイプは民主化された 一方で、巨大なプロダクト、複雑な業務プロセス、技術負債、全体 整合性など実務で向き合う課題は多い 本題は、日々多くのユーザーに使われている 既存プロダクト、複雑な実運用に対してどう組み込むか 13
14. AI時代のプロセス②（例） 実際には個々のケーパビリティも加味しながら「最も効率的にスケールする」手段を “意図的に” 取る 個人のケーパビリティの伸ばし方としての「プロセス完走」は良いことである前提で、チームとしてはあ えて分担する (コミュニケーションコストを受け入れる) ことで生産性が上がることもある。 戦略などハイレベルに物事を決められるPdMは、 ハイレベルな意思決定にフォーカスしたほうが良い場合もある PdM Idea Idea Idea ハイレベルな 要求 ハイレベルな 要求 ハイレベルな 要求 レーン① 要求 Sub PdM Prototype Prototype Product (Finalize) ※ 必要なら Product Eng レーン③ 要求 (Finalize) ※ 必要なら Des レーン② 要求 個々のケーパビリティによって、 どこまで走れるかは実際違う Prototype (Finalize) ※ 必要なら コミュニケーションコストは発生するが、レーンが増やせることでチームの生産性が上がる Product
15. ループを止めない、3つの設計ポイント(仮説) AIがHow（どう作るか）の大部分を担えるようになった今、大事なのは、どこに人間の意志を入れる べきかを見極めること 1 意思決定の設計 2 Contextの設計 3 信頼の設計 AIが「How」を担えるようにな Contextは徐々に育っていく、 AIは間違う、100%はない。 っても、「Why」 「What」の 育つContextをどう活用するか、 これを前提にしたときに、どう 定義と Go/No-Go は人間にし 膨大になりすぎないようにする システムの信頼性を担保し続け かできない にはどうするか るのか 人間の意志を入れるべき箇所、 Context量を意識したアーキテ 間違うことを前提とした、確 入れる必要のない箇所を見定 クチャと、Contextの育て方・ 率論の外で品質・信頼性を担 め、質と速度を両立させる 育ったContextの上手い活用 保する仕組みを構築する 15
16. 人間の仕事の重心が変わる 「作る」から「定義する・判断する・向き合う」へ 人間に残ること AIが担うこと “こうしたい” の意思の部分 成果物の出力 (ものづくり部分) • 何を / なぜ作るかを決める (Why / What) • データの分析 • AIの成果物の見極め・判断・修正 (Go / No-Go) • デザイン案を作る、コードを書く • 周囲を巻き込み実行しきる (Execution) • テストで検知したエラーを自動で修正する 人 AI 人 AI AI AI ※ 業務によって、人の介在度合いは変わる 16
17. 作り方が変わっている、企画と開発は溶け合う だからこそ 組織、プロセスに変化を 17
18. 具体的な実践事例 （3つの取り組み） 18
19. 具体的な実践事例（3つの取り組み） 1 意思決定の設計 2 Contextの設計 3 AI時代の人材育成 19
20. AIによってプロセスを変えた事例：リサーチプロセス PdMがPrototypeを高速で作れるようになった結果、今度はリサーチ準備の方がボトルネック化 PdM→責任者承認→調査設計/配信→実施、という形にプロセス自体を作り替えた Before：調査対象のPrototypeの開発期間がボトルネック（ex. 数週間） Idea デザイン/ 開発 要求 Prototype リサーチ リサーチ準備（選定、契約、調査設計/配信、等） After：リサーチ準備にボトルネックが移動→リサーチ準備プロセスを変えた（ex. 最短翌営業日） リサーチ 事前準備 (選定/契 約) Idea Prompt (要求) Prototype リサーチ 調査設計/配信 20
21. 制約条件に向き合い続ける AI導入による成果は、 単一業務の改善だけに目を向けてもなかなか見えてこない。 組織としてプロセスごと作り替え続けることで 非連続な改善につながる 21
22. リクルートにおける具体事例共有 1 意思決定の設計 2 Contextの設計 3 AI時代の人材育成 22
23. Contextの消失にどう向き合うか Contextの設計は、“どう詳しく伝えるか”の勝負だけではない 書いた瞬間から劣化していくWhyを、 どう伝搬するかという設計 23
24. Contextを受け渡さない Context設計における1つ解決策は、Contextを受け渡さないこと。 PRDに書くと消える意思が、本人の中では消えない ― ループが人の中で回った事例 担った役割 起きた変化 エンジニア出身メンバーが「自分も企画をやりたい」と意志を 示し、企画のミッションを兼務で付与 最初はHow起点で苦戦したが、徐々にWhy起点で考えられるよ うになり、エンジニアリングという武器を持ったまま一気通貫 でチーム全体の生産性を高めるリーダーに成長
25. 人が介在すると悪意なくContextは失われていく 既存の役割に固執せず、 個の能力の拡張と 組織・役割の再設計に向き合うことが重要 25
26. リクルートにおける具体事例共有 1 意思決定の設計 2 Contextの設計 3 AI時代の人材育成 26
27. AI時代における育成の前提の変化 役割の境界を溶かすことと、個人のスキルを定義すること。 この二つは、セットで実施する必要がある背景として、4つの要因が存在します。 01 02 03 04 多様なメンバー特性 育成の“正解”の消失 従来型OJTの限界 育成・アサインの複雑化 メンバーの役割・スキル・経験 はもともと多種多様で、上司と 同じ特性を持つケースの方が少 ないため。 AI時代は、誰も経験したことの ない変化のスピードであり、育 成の正解そのものが消失しつつ ある。 かつてはOJTにおいて暗黙的に 機能していた「従来の育成の 型」が、現在はもう通用しない 局面が増えてきた。 役割が流動化するほど、明確な 評価やプロファイルの物差しが なければ、育成もアサインも難 易度が増す。 だからこそ、AI時代を見据え、個人の強み・弱みを改めて言語化し、目線を合わせる必要がある 「スキルセットを再定義」 27
28. プロダクトマネージャーのスキル定義(現状版) 経験 テクニカルスキル Business & Marketing UX Design Technology Operation Data ToC ToB 新規立ち上げ 大規模 etc … 戦略策定力 課題設定力 課題解決力 コアスキル PdMとしてコアとなるスキル (総合戦闘力) マインド・スタンス 実行力 当事者意識 リーダーシップ ラーニング アビリティ ※ 実際には各スキル毎により細分化・言語化して定義している etc … 28
29. 役割の境界は溶けていく 評価の物差しを溶かさないことが、 流動化を混乱ではなく成長機会に変える 29
30. 変化への適応と伝搬の設計 30
31. 激動のAI時代への適応 変化のスピードが激しいAI時代、トップダウンだけでもボトムアップだけでも追いつけない。 従来の意思決定の限界 変化に向き合う自律適応 指示や提案を待つだけの構造では遅すぎる 変化の兆しを捉え、自律的にサイクルを回す 変化が複雑かつ迅速に起きる環境下では、一方向のみの情報伝 達や従来型のプロセスだけでは市場のスピードに追いつくこと が困難になる。 だからこそ、変化の兆しに向き合い続け、備え、意思決定し、 適応していくプロセスを組織全体で回し続けることが大事にな る。 全員で向き合い、備え、意思決定し、適応していくことがこれからの組織の核心 31
32. 変革のループ設計 プロダクトを賢くしてきたこのループは、組織にも同じ構造で回る。 現場の気づきを組織の意思決定に引き上げた結果、広がり方は一つではない。 職種を越えた意欲の伝搬 AI活用・業務改善の波及 「自分もやってみたい」という自発的な意思 個人の取り組みから組織全体へ エンジニアだけでなくデザイナーやマーケのメンバーからも 「自分もPdMをやってみたい」という声が上がり、声に呼応し て越境が進んでいる。逆もしかり。 メンバーが自発的に始めたAI活用・業務改善の取り組みがシェ アされ、組織全体に広がっていったケースも生まれている。 あるメンバーのAI活用に刺激を受けた別のメンバーが、自分も 利活用を始める、という広がりも起きている。 小さなきっかけから大きな変化へと伝搬していく。 他のチーム・事例への関心が引力となって、変革は連続的に広がっていく 32
33. 声を上げる・動くことこそが、 変革とリーダーシップの最初の一歩 33
34. Thank You 情報交換やカジュアル面談を ご希望の方はぜひQRから フォームへのご回答をお願いします。 34