現場感と大局観 -具体と抽象の両端からチームと事業を動かす-

https://product-manager-kansai.connpass.com/event/408692/

Transcript

1. 現場感と大局観 -具体と抽象の両端からチームと事業を動かす- 2026/11/06 PM Kansai Meetup #9 @kony_um
2. 自己紹介 小西 裕真 Konishi Yuma 株式会社タイミー プロダクトマネージャー • プロダクト開発 meetup関西主催 • pmconf2025@大阪登壇 • 趣味色々 ◦ 個人開発、麻雀、ゲーム ◦ 筋トレ、ゴルフ、ピアノ
3. PMが真に果たすべき 仕事とは何か？
4. 自分の仕事の付加価値とは AIで様々なことが効率化される中、 PMとして何ができるのか、何をすべきなのか。 「超具体か超抽象にしか、価値は宿らない」 AI時代におけるPMの付加価値は、中間的な作業ではなく、現場・顧客の緻密な解像度（超具体）か、本質を見抜く構想・ 概念化（超抽象）の両極に宿る。AIで思考や作業を効率化するだけでは魅力的品質の仕事をすることはできないのでは ないか。 出典記事 「なぜ経産省、BCGのキャリアを捨てて、スタートアップで挑戦するのか？」 https://note.com/famous_macaw5829/n/nf9682f67739c
5. 具体と抽象の両端に厚く張る 開発現場から離れて前後の領域に活動を拡張 【 超抽象 】 ・事業戦略 ・競争戦略 ・市場分析 拡張 拡張 開発領域（従来） ・ロードマップ作成 ・要件定義 ・QA etc 事業戦略・競争戦略 事業としての勝ち筋を考える。 事業としての関心ごとがまずあり、それに貢献するためにプロダ クトが存在するという思考順序。 事業戦略を踏まえた目標設定、事業戦略仮説の検証など俯瞰 の観点を持つことが結局良いプロダクト作りに跳ね返ってくる。 【 超具体 】 ・営業活動 ・業務理解 ・機能 GTM 顧客や営業現場の一次情報 顧客や営業現場で起きている事実をもって、事業課題やプロ ダクト価値を検証する。 とにかく現場に出向き一次情報を集める。顧客のみでなく営業 活動自体も把握する。 顧客、自社、競合の動きを現場で捉え、機能や事業の在り方に ついて具体的な事実ベースで議論をできるようになる。 ★ 半年で約 50商談に同席・現場観察を実施。
6. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場 現場での 初期検証 戦略仮説 論点の更新 論点の精査 ロードマップ 反映 現場との反復 で要件定義 実装 GTM 新規論点の 探索
7. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場での 初期検証 戦略仮説 論点の更新 ・そもそも事業としての勝ち筋、負け筋は何か ・どのような課題があるか ・その課題は確からしいか ・どのように解くべきか ロードマップ 反映 実装 論点の精査 現場 現場との反復 で要件定義 GTM 新規論点の 探索
8. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場 現場での 初期検証 戦略仮説 論点の更新 ・その課題は今解くべきなのか ・他の課題との優先順位をどうするか 論点の精査 ロードマップ 反映 現場との反復 で要件定義 実装 GTM 新規論点の 探索
9. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場での 初期検証 戦略仮説 論点の更新 ・どんなものならばその課題は解決できるのか ・実際に受け入れられるものになっているのか ロードマップ ・営業が提案できる形になっているか 反映 実装 論点の精査 現場 現場との反復 で要件定義 GTM 新規論点の 探索
10. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場 現場での 初期検証 戦略仮説 論点の更新 ・事業課題は解消したのか ・次は何を解決するべきなのか ・そもそも未知の課題はないか 論点の精査 ロードマップ 反映 現場との反復 で要件定義 実装 GTM 新規論点の 探索
11. 現場横断仮説検証の実例
12. 仮説検証の実例 : 競合比較編 戦略 プロダクト 現場での 初期検証 戦略仮説 論点の更新 論点の精査 現場 ・競合との機能劣位性 がサービスの導入ハードル になっているのではないか？ ・それが本当なのか？埋めるとして何をどのように 進めるべきか？ ロードマップ 反映 現場との反復 で要件定義 実装 GTM 新規論点の 探索
13. 仮説検証の実例 : 競合比較編 戦略 プロダクト 現場での 初期検証 戦略仮説 論点の更新 ・星取表ベースで判断しない。 ・現場の業務を学ぶことでサービス利用に必要な 要件を精査。 ロードマップ 反映 実装 論点の精査 現場 現場との反復 で要件定義 GTM 新規論点の 探索
14. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場 現場での 初期検証 戦略仮説 論点の更新 ロードマップ 反映 実装 ・劣位性は一定 サービス導入の KOFになっている ・ただし、機能によっての濃淡はありそれに応じて 優先度やスコープを調整する余地はある 論点の精査 現場との反復 で要件定義 GTM 新規論点の 探索
15. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場での 初期検証 戦略仮説 論点の更新 ・実装前にコンセプトから 顧客と壁打ち する ・リリース後の提案も自ら行い 、提案手法や不足機 ロードマップ 能のキャッチを行う 反映 実装 論点の精査 現場 現場との反復 で要件定義 GTM 新規論点の 探索
16. 具体と抽象の往復での高速仮説検証 戦略 プロダクト 現場 現場での 初期検証 戦略仮説 論点の更新 ・機能劣位性の論点は概ね終了 ・他の論点の探索に移行 論点の精査 ロードマップ 反映 現場との反復 で要件定義 実装 GTM 新規論点の 探索
17. 動き方を変えて良かったこと 具体と抽象、事業とプロダクト全ての観点があるからできること。 01 事業戦略は具体での検証を求めている 事業戦略も究極的には、事業についての仮説群である。 「なぜ現状こうなっているのか」「この打ち手は通用するのか」というのは、結局具体でぶつけてみないとわからない。 だからこそ、 AIだけでは得にくいファクト、強烈な N1成功事例が重要。 02 プロダクトを経由しない仮説検証は早い 「出してみて反応を見る」よりも早く仮説検証をできるならそれに越したことはない。 顧客の価値受容性をものが無い状態でも検証できるし、いざものを作るとしても顧客と共に作れば大きくは外れない。 プロダクトに閉じない発想がむしろプロダクトの価値と改善速度を高める。
18. 元々やっていた仕事は どうしたのか？
19. エンジニアの 問題解決能力を頼ろう
20. 問題解決に向き合うチームを作る エンジニアにもどんどん実装以外の行程に染み出してもらう 01 問題解決の当事者として扱う エンジニアを「実装する人」として矮小化してはいけない。 「PMだって全ての答えを知っているわけではない」「全てに手が回り、考慮が行き届くとは限らない」 問題解決に向けて主体的に動いてもらうことを期待する。 02 エンジニアには担当機能 (エピック )のPOのように振舞ってもらう。 価値創出のために必要な取り組みを総合的に期待 する。 必要な情報は自分で集めてもらう。当然直接営業や顧客と話すケースもある。 自ら作るべきものを描き周りを説得し実際に形にする。 PBIの起票や記載も任せる。 作ったものを外部に説明し質問に答え、要望管理もする。改善すべきことか否かも自分で判断する。 ことを前提に
21. チームの役割分担の全容 Product Team Tech Lead 技術的整合性と品質に対する説明責任 Product Engineer Designer サービスを横断しての UXの担保 個別のエピックの 探索、実装、GTMの 推進 Product Manager エピックの創出、精査、優先順位付けなど総合的なチームの取り組みの意思決定と説明責任を 負う。
22. まとめ 良いプロダクトを作るためにもプロダクトの外にもっと出よう 01 本来は何に 1番時間を使うべきか考えよう PMの責任は重い。重要な意思決定をするに足る活動を日々できているか。 自分の時間の希少さを認識し、必要なことベースで見直そう。 事業戦略を語れないとしたら、しばらく顧客に会っていないとしたら、十分な材料を持って意思決定ができていると言えるのか？ 02 自分にもチームにも変化を求めよう AIの進化でデリバリーの速度は急激に改善した。 エンジニアのあり方だけでなく、 PMの在り方も見直すべきではないか。 PMがより向き合うべき複雑で不確実な事象に没入しよう。
23. We are Hiring！！ 一緒に社会のインフラを作りましょう PdM採用情報 エントランスブック
24. 現場感と大局観 -具体と抽象の両端からチームと事業を動かす- 2026/11/06 PM Kansai Meetup #9 @kony_um