「技術的にできません」を越えて価値 を生み出せ———研究開発チームをPM が率いて生み出した価値創出 Takahiro YAMAGUCHI / @hiro93n 26.02.18 Developers Summit 2026 1 

2 今日のスライドは追って公開予定です！ 

登壇者について 山口 隆広 ユニファ株式会社 執行役員CPO プロダクトデベロップメント本部 本部長 兼 AI開発推進部 部長 1981年生、福島県出身、子(6歳)の父。 HCD-net認定 人間中心設計専門家。 ねこ大好き。ベーススキルは企画職。 @hiro93n 3 

4 ルクミー：保育園・幼稚園・こども園向けICTサービス 「保育AI」に関わる プロダクトに 関わっています 

5 いわゆるR&D組織に対するイメージ ※過去所属していた組織も含めた山口の主観です ● 研究計画を立てて予算を取り、「なんだかよく分からないけどすごそう」 な成果や論文を定期的に発表する組織 ● 事業部に技術提案されるmtgが組まれるが「この原価では無理だな･･･」 という気持ちになってしまうこともある ● 少なくとも、自分が要望を出して何かを実現してもらうようなイメージは なく、技術的興味はあるが日常とは縁遠い組織 いわゆる開発チーム間コミュニケーションとはまた別の位置にあり 懇親会で同じチームになったらなぜか緊張しちゃうようなこともある組織。 

今日お話しすること PMが研究開発(R&D)組織と向き合うとき プロダクトの可能性をどう広げられるか 6 

「技術的にできません」と言うとき 7 

8 そもそもPMが判断できること･･･？ ただ自分が知らないだけというパターンなんじゃない？ 「できない」を知る技術って結構大変なはず。 でも、それを専門にしている人たちがいる。 

9 みなさんは R&D組織 と、普段から接点がありますか？ その道のプロが、R&D組織 

10 なぜユニファにR&Dチームができたか ● 2018年誕生、社長のトップダウン案件 ● フォトだともっと顔認識とか画像AIとか頑張りたい、午睡チェックも立ち 上がってきて今後IoTデータ分析とかもR&Dしたい、そんな時に画像AIに 携わっていた方がエンジニアの面接を受けてくれたのがきっかけ 2018年、R&Dチームのslackの始まり 

11 ユニファにおける、外部環境によるR&Dチームの立ち位置の変化 研究開発部門 研究開発&社内情シス& インフラ部門 いつの間にか「何でも屋」化してしまったR&Dチーム ● 提供していた顔認識機能の性能向上のため顔認識モデルの内製化を進めて いたが、戦略変更によりモデルも塩漬け。 ● 保育ICTプロダクト立ち上げへの直接貢献はできないため、事業戦略と距 離のあるところでしばらく成果模索することに。 フォト顔認識の強化や IoTデータ分析に注力 戦略 組織 保育ICT立ち上げに注力 組織と戦略がマッチ 研究開発は後回しに 1~2年後 

R&Dチームをリードしてみるぞ編 12 

13 

14 保育AIビジネスをやろう、となった2023年 ● 従来のPM+エンジニアで小規模なAIサービスを開発したら利用率が想定 よりも高まった ● 保育施設での受容性を見て、さらなる拡大が戦略に含まれた ● R&Dメンバーは機械学習から走り抜けてきたスペシャリスト ○ 使うだけのノウハウだけでなく、作るためのノウハウがある ○ もちろん何人もいるわけではない。そんな人たちに組織マネジメン トコストや社内お困りごと解決に時間を使わせて良いのか？ 「部署」としては解体し、開発本部付チームとして再構成。組織長は当時の CTOが担い、組織タスクを担うリードはPMとして山口が担うことに。 

15 とはいえ果たしてリードできるのか･･･？ 

16 おさらい：一般的なR&D組織周辺でよく見る事例 「こんなことできるよ」という技術Demoの提示 「これはすごいね」とその場では盛り上がるが その先の施策には繋がらない事業現場 いま別に重要と感じていない課題解決に対する「すごい」であったり 「すごい」かもしれないが事業に対するコストが見合っていなかったり 特にニーズがない状況での「すごい」は価値まで遠く、実現されない。 

なぜ、ニーズと遠くなってしまうのか 17 

18 R&D組織が、情報が少ない中で模索している問題 事業現場からの視点 R&D組織からの視点 研究開発という概念が分から なすぎて、何を頼って良いの かが分からない ● 変なことをお願いして、 貴重な工数をムダにして しまうことが怖い ● 専門性が高すぎて話すの に緊張する ● 話のお作法も分からない 事業現場に何のニーズがある か分からないので、何を訴求 すれば良いのか分からない ● プロダクトアウトで技術 デモをするが、今の必要 性とは遠い ● それを実用化するキャパ が現場チームにないので 後に続かない 

19 R&Dに関わらず、様々な機能チームから聞く話 自分たちの疑問解決のため 事業現場の人に時間を取らせてしまうの は忍びない 

20 各所でなぜか起こってしまう「相手の時間尊重しすぎ問題」 ● 相手は忙しいので、自分の疑問解決に時間を割いてもらうのがもったいな いと感じてしまう。 ● 仮に時間を使ってもらって他の重要な施策が動かなくなることに責任が取 れないのでそもそも伝えない方が良いと思ってしまう。 「あなたが気を遣っても、全然気を遣わない他の誰かが私 の時間を奪うので、普通に奪ってください」 という関係性が重要であり、早くこれに至る必要がある。そのための遠回りで 時間がどんどん溶けていく。 

21 PMもやりがちな「忍びない」の一例 良かれと思って自分で色々考えたHowから持ちこむ PMがHowを指定し「技術的選択の自由」と「より良い解決策を提案する機 会」を奪ってしまうと、時間だけかかって誰も幸せにならない。 

22 結局分かった、リードとして解決すべき課題 本来とるべきアクションに必要な 情報を得るハードルが心理的に高い。 よって提案の質を上げにくく、成果発揮 に繋がりにくい。 そして、その解釈を手伝ってくれる人も身近にいない。 

23 リードとして、R&Dチームに何ができると助かるか実際聞いてみた 「期待値を教えて欲しい」 「事業戦略を教えて欲しい」 

24 誤解しがちな「リード」への期待値 PM出身のリードに対し、上司も部下も R&Dチームの持っているような専門性を 期待してるわけがないということ。 そんな短期で成果出せると思ってるとしたら、むしろ専門性に対するリスペク トがない。それより得意なことで成果出してもらって良いですか？が普通。 

25 PMが貢献できる「得意なこと」 PMの立ち位置だからこそ、いま解くべき課題を理解している。 その情報獲得パスがないR&Dチームに課題を伝えられることが貢献。 

26 3ヶ月に1回、チームとプロダクト半年計画の話をするようになった 2025年 1月 2025年 3月 2025年 6月 2025年 9月 半年後(25.06)にどういう状況である必要があるか 半年後(25.09)にどういう状況である必要があるか ● PMと同じ情報量で半年後のプロダクトのあるべき状態を示す。 ● ここ3ヶ月で解決したい技術課題、3ヶ月では解決できないものの、半年 後以降には解決できていて欲しい課題も並べる。（短期だけにしない） ● それらに対し実現性のレビューや想定されるHow、解決順の整理に向け た会話を行う。 ※3ヶ月毎に半年を見通す 

さらに成果を出すための体制強化編 27 

28 チームの成果が認められ、AIプロダクト部署として再構築 リード → 部署マネージャーの立場へ。 当然期待値も上がる中、PMとしてのコミュニケーションパスだけでは解決で きない課題にも向き合っていくことに。 

29 R&Dメンバーだけだと足りない、成果を発揮する組織への課題 1. 実証検討するにも開発環境の構築や既存プロダクト理解など、本筋でな いところに時間を取られてしまう機会が多い 2. 保育AIプロダクトが仮説検証段階で既存チームから人を連れてくること がまだ難儀であり、チーム内で「作れる」馬力を確保しないと検証ス ピードがコントロールできない 3. 新しい取り組みのwillがあるが、誰に話を通せば良いのか分からない 必ずしも今のR&Dメンバーが解決することだけではないため、 誰が本来担当するのが適切なのかを棚卸してみる。 

30 1&2の解決策：サーバーエンジニアに「気軽に」依頼できればよい 1. 実証検討するにも開発環境の構築や既存プロダクト理解など、本筋でな いところに時間を取られてしまう機会が多い 2. 保育AIプロダクトが仮説検証段階で既存チームから人を連れてくること がまだ難儀であり、チーム内で「作れる」馬力を確保しないと検証ス ピードがコントロールできない 3. 新しい取り組みのwillがあるが、誰に話を通せば良いのか分からない 同じチーム内にプロダクトチーム出身のサーバーエンジニアがいれば心理的 ハードルもなく、タスクも相談でき、プロダクトチームの状況も相談でき、 プロダクトとして求められる要件を満たして仮説検証できる。 → 異動によりサーバーエンジニアがチームメンバーに参加。 

31 サーバーエンジニア参加による副次的なメリット 下記のような「ありがちな悩み」に対し、事前にR&Dチーム内のサーバーエ ンジニアとある程度解決した上で持ち込まれるようになった。 ● PMがR&Dチームと詰めてきた技術を「新機能として使いたいから取り込 んで」と言われるものの、既存プロダクトのインターフェースとマッチ しておらず使いにくい ● 開発チームで考えているプロダクト開発・運用ルールと別のルールで環 境構築されていたり、監視されていたりするので、トラブル発生時の状 況が見えにくい、コントローラブルではない 開発チームにとっても、事情を理解している有識者がいるのは良い話。 

32 3の解決策：「プロダクトの人」に閉じない姿勢で事業に向かう 1. 実証検討するにも開発環境の構築や既存プロダクト理解など、本筋でな いところに時間を取られてしまう機会が多い 2. 保育AIプロダクトが仮説検証段階で既存チームから人を連れてくること がまだ難儀であり、チーム内で「作れる」馬力を確保しないと検証ス ピードがコントロールできない 3. 新しい取り組みのwillがあるが、誰に話を通せば良いのか分からない 事業ニーズを理解して技術開発ができているのであれば、プロダクト以外の 提案でも当然ニーズにマッチしているはず。 → 「プロダクトだけの人」ではなく事業全体に対するR&Dという姿勢を示し 事業リードと特別感なく定常的に話せる場を確保。 

33 やれることに注力することで生まれた価値創出 施策化頻度の向上 明確なニーズに対して先 を見越して技術開発する ため、R&Dの技術が施策 化される機会が定期的に 発生。 技術の資産化 サーバーエンジニアとの 議論でプロダクトへの実 装も見越して設計されて いるので、扱える技術選 択肢として有効に機能 営業活動にかかるデータ 分析への進出 データでの意思決定強化 のwillをもとに提案。営 業部とのコミュニケー ションパスを構築しPJ化 へ。 

R&Dマネジメントとして必要なスキル 34 

35 R&Dの専門性を避けてるように見えるけど、本当に成立してるの？ ● マネジメントとしての共通スキルと専門性は切り分ける ○ チームとして価値を出す部分のスキルは領域が分かれても共通点は 多くある ○ 「技術の目利き」「育成プラン」は専門性のあるメンバーに相談 ■ マネジメントなのでと明るくない領域まで全部丸抱えしても結 果は出ない ● 着手候補のテーマとそれに関わる妥当な期間については、チームの中の シニアとも相談しつつ事業上受容できる期間設定を行う ○ 全部を丸呑みする話ではなく、事業上求められる期間設定は提示 ■ 1ヶ月以内で解決できる課題ばかりだとしたら模倣難易度が低く テーマ設定の筋が悪いのでは、なども適切に悩む 

36 さらに、マインドセットとして これだけは必要と考えること。 

37 その技術領域における尖った専門性は要らない。でも、リテラシーは必要。 リテラシーがない状況とは･･･？ ● 常に説明コストが高かったり、意思決定の方針に違和感が募る ○ 事業推進と専門性は対立しないはずなのに、常に専門性を蔑ろにさ れるシーンが増える ● 何でもYesと言われるがそれに興味がない、リテラシーがないがゆえの 「スゴイデスネ〜」しか言われない状況 ･･･とはいえリテラシー、どうやって身につける･？ 

38 例えば保育AIなら･･･ 「AIでできるでしょ」と言われているものを本当にできるのかVertex AIやBedrockで 色々とモデルを変えながら試してみる。普段からCursorなどで文書要約の実力値を見て おく。ネットの記事を読みながら手元の結果とギャップがあれば「これどう言うことな んだ」とチームメンバーに聞いてみる。n8nでプロトタイプを作って動かしつつ、中で どういう処理が行われているのかログを見て悩んでみる。技術だけでなく保育現場に 行ってみてAIの受容性を定点観測し、越えてはいけないボーダーが何か、実際に保育現 場から入れられる情報のバリエーションにはどんなものがあるのかを見極める。普段の 業務と関係なくともAI系アプリケーションが出たら触ってみてそのUXを思い知る。 色々触ったなーと思ったら改めてLLMプロンプトの技術書を読んでみて「なるほどそう いう仕組みなのか」と基本に返りつつ定例でその話をして「ちょっと認識誤ってます ね」と適切に突っ込みを受ける。何かを読んで分かって気になっていても分かっていな いので適切に言語化して発信したり、必ずしもAI理解がある人たちだけではない場に出 て説明責任を果たす、などなど、読んで、動かして、話して、また試しての繰り返し 興味を持って潜る 

39 まず、正しく「分からない」ことがリテラシーの第一歩 「知ろうとすること」「手を動かして学ぶこと」が大事。 そこからの「これは分からん！」がリテラシーの基本。 私は手を動かすつもりはないので全部教えてよ、ではもちろんダメ。 分からなくなって、教えてもらって、そのスゴさがより分かる。 

40 結果、R&Dチーム組織の現状 研究開発部門 研究開発&社内情シス &インフラ部門 「高度な技術によるWowを予定やスコープが見える状態で実現していて、 日々の営業活動やプロダクト開発にも縁がある組織」化。 ● 事業戦略エンジンとなり、全社からも頼られる存在へ。 ● 組織自体の増強ニーズも現れ、採用も活発化。 データ分析に注力 戦略 組織 保育ICT立ち上げに 注力 組織と戦略がマッチ 研究開発は後回しに AIプロダクト定着及 びデータ分析部門 データでの意思決定 保育AIを推進 事業戦略エンジン 

41 おまけ：自分の「技術的にできません」認識を越えてたと思う例 （資料にせずこの場限りで話しますが、写真関連の何かです） 

まとめ 42 

43 大事なポイント ● 専門家への依頼がHowになっていないか ● 事業戦略とR&Dのテーマが合っているか ● すべてをR&Dメンバーだけで解決しようとせず、適切に周囲の人の力を 借りられているか ● R&Dの専門性で戦力になることはあなたに求められていない。大事なの はあなたが専門性を身につけることではなく、専門家が成果を発揮でき るようにするための結節力だと認識できているか 結局は、期待値を伝え、外部とのコミュニケーションのハブになり、常に成 果の最大化のために取り組むアクションが取れることが大事 PMだったら普段からやっている人が多いですよね！ 

44 プロダクトを伸ばすため、正しくBeyondしていく PMがプロダクトを伸ばすため何でもすると言うなら 「いつものパターン」「おなじみの選択肢」に留まらず R&Dの力で価値を出し続けるBeyondにも取り組もう！ 生成AI時代だからこそ、突き抜けた専門性を頼ることが武器になる。