「私が一番顧客に詳しい」を捨てる～ 全員が一次情報に精通する開発チームをつくり、PMが次のボトルネックへ染み出すまで

プロダクトマネージャーカンファレンス 2026
「私が一番顧客に詳しい」を捨てる～ 全員が一次情報に精通する開発チームをつくり、PMが次のボトルネックへ染み出すまで
https://2026.pmconf.jp/event-fukuoka/session-7

吉岡 詩織
プロダクトマネージャー

Transcript

1. 〜「私が⼀番顧客に詳しい」を捨てる〜 全員が⼀次情報に精通する開発チームをつくり PMが次のボトルネックへ染み出すまで 株式会社カミナシ 吉岡詩織
2. ⾃⼰紹介 吉岡 詩織 株式会社カミナシ プロダクトマネージャー 略歴 ◾2018~2021: 株式会社LIFULL サービス企画 / 新規事業⽴ち上げ ◾2021~2024: コネヒト株式会社 「ママリ」PM ◾現在：株式会社カミナシ 「カミナシ 教育」PM こんな⼈ #パン作りが好き #伊能忠敬界隈 #福岡市早良区出⾝ Xはこれです 2
3. 2年前の私 3
4. 2年前の私 PMは誰よりも顧客に詳しくあれ 4
5. 2年前の私 PMは誰よりも顧客に詳しくあるべき？ 5
6. 2年前の私 PMは誰よりも顧客に詳しくあるべき？ PMは”誰よりも顧客に詳しいチーム”を 作るべき 6
7. 今⽇話すこと 1. なぜ信念を捨てたのか 2. チーム全員を「⼀次情報」に巻き込んだ実践 3. そして、PMが次のボトルネック解消へ染み出すまで 7
8. ちょっとだけ会社の話を
9. MISSION Mission ノンデスクワーカーの 才能を解き放つ
10. 先⽇プレスリリースを出しました 2026/10/21 に 資⾦調達 & 新構想 & 新製品を発表しました🔥🔥🔥 10
11. プロダクトラインナップ カミナシは“現場の基盤”となる 3つの領域をまたぐデジタルインフラに
12. カミナシのお客様 オフィスでPCを開く⾃分たちとは、 「働く環境も前提知識も全く違う現場」が相⼿。 1⼈1台PCを持っていない 全員が会社メアドを 持つわけではない 両⼿が物理的な作業で塞がっている …etc 12
13. ⾃⼰紹介 だからこそ、カミナシは「現場ドリブン」を⼤切にしています 13
14. ⾃⼰紹介 全員で顧客の現場に⾏くことが当たり前になっています 現場訪問総数 約3,300回（延べ）/年 ⼊社後の私の訪問数 77回/2年 （約週1回ペース） 14
15. そんなカミナシに⼊社直後の私 要求を書いて、要件は任せる とにかく現場に⾏く 全員が現場に⾏くカルチャーの中でも、 誰よりも顧客に詳しくありたかった 顧客に 詳しくなる ユーザーストーリーを書いて 仕様‧要件はチームと⼀緒に議論 15
16. なぜ信念を捨てたのか
17. AI時代になった AIで開発が加速 ⼀つのチームの中で 複数の開発レーンを ⾛らせることが可能に AIで作りながら 体験にこだわって改善 17
18. AI時代になった AIで開発が加速 ⼀つのチームの中で 複数の開発レーンを ⾛らせることが可能に AIで作りながら 体験にこだわって改善 しかし、「PMが顧客に最も詳しく、PMしか決められない」だと‧‧‧ PMが要求を決める/PRDを 書くことが追いつかなくなる エンジニア⾃⾝が PMの判断を待たずに 改善を回すことが難しくなる 18
19. スタンスの変化 とにかく⾃分が現場に⾏く 要求を書いて、要件は任せる 誰よりも顧客に 顧客に詳しくなったPMが 詳しくありたかった ユーザーストーリーを書く 19
20. スタンスの変化 とにかく⾃分が現場に⾏く 要求を書いて、要件は任せる 誰よりも顧客に 顧客に詳しくなったPMが 詳しくありたかった ユーザーストーリーを書く とにかく “チームを” 現場に連れていく 戦略やロードマップだけ 書いてチームに任せる 全員で顧客に 詳しくなるハブへ 🔥 事業成長・未来 コミットする人へ 🔥 20
21. 開発フローの変化 PMがチームに渡すものはこう変わった Before: 機能単位 After: テーマ単位 ユーザーストーリー 四半期でこれをやりたいぞ なテーマ なぜやるか 数⾏のビジネスゴールと 期待するアウトカム ざっくり受け⼊れ条件 21
22. 開発フローの変化 開発フローはこう変わった 従来 PRD的なものを 書く 議論する デザイン する 開発する 成果物を 確認 リリース PM PM/エンジニア/ デザイナー デザイナー エンジニア PM エンジニア PMが戦略‧ロードマップだけ提⽰🚩 PRD的なものを 書く デザインする リリース 開発する 現在 議論する エンジニア/デザイナー PMはみている👀 エンジニア 22
23. スタンスと開発フローの変化、その結果 作業時間を削ってでも現場に⾏ったエンジニア‧デザイナーに 任せることで、早く‧良いものができている エンジニアとデザイナーの議論の末できた体験が良すぎたやり取り PMM 私が考えてたらこの体験には ならなかった（確信） 23
24. スタンスと開発フローの変化、その結果 これができるためには PMが最も顧客に詳しい チーム全員が顧客に詳しい ⼀次情報をチーム全員が 同じレベルで知っている ことが必要 24
25. どうやって「全員が詳しい」 チームを作ったか
26. 「全員が詳しい」チームを作るために、やったこと 󰝋 💎 🔍 ⼀次情報を知る ⼀次情報の ⼀次情報への 機会の創出 ストック アクセス 26
27. 「全員が詳しい」チームを作るために、やったこと 󰝋 💎 🔍 ⼀次情報を知る ⼀次情報の ⼀次情報への 機会の創出 ストック アクセス 27
28. 「全員が詳しい」チームを作るために、やったこと①機会の創出 顧客訪問機会を作り、そこに必ずチームを巻き込む 制約があるメンバー（育児があるため帰宅時間 が決まっている/ 遠⽅在住など）も 参加しやすいように⼼がけています 28
29. 「全員が詳しい」チームを作るために、やったこと①機会の創出 そもそもなぜそこまで機会を⽣み出せるのか？ ❶ 既存顧客との接点 ❷ 新規顧客との接点 CSが⽇々強固な関係を築いてくださっている PM⾃⾝がハウスリストに対して架電したり お客様に、ヒアリングなどを依頼 メールを打ってアポを取り、商談 カミナシに⼊った時の私の動き⽅ 詳しくはこちらのnoteへ👉 29
30. 「全員が詳しい」チームを作るために、やったこと①機会の創出 事例：通称”現場訪問ゾス⽉間”を開催 ディスカバリーテーマや時期によって訪問頻度はまちまちですが チーム全員で10件⾏くぞ！と決めて動いた⽉のカレンダーはこんな感じでした チームの誰が⾏くかを 案件ごとに わりふり 30
31. 「全員が詳しい」チームを作るために、やったこと 󰝋 💎 🔍 ⼀次情報を知る ⼀次情報の ⼀次情報への 機会の創出 ストック アクセス 31
32. 「全員が詳しい」チームを作るために、やったこと②⼀次情報のストック カミナシではインサイトマネジメントツール「Centou」を活⽤しています ⽇々の顧客訪問の記録/ヒアリングの議事録などをインサイトに昇華してストック 引用：https://centou.jp/ 32
33. 「全員が詳しい」チームを作るために、やったこと②⼀次情報のストック ⼤量の記録/学びがあるからこそ 「分析しやすい」「⾒返しやすい」形に整理する ローデータ まぁ、正直マニュアルを普段⾒ること はほとんどなくて。思い込みとかね、 記憶に頼った作業っていうので、 まぁ、ミスが起きる。そこをちょっと どうにかしないとなと。 ファクト インサイト 従業員が⼿順書を⾒返さないことで 作業ミスに繋がっている マニュアルを定期的に⾒返して もらうことで、作業ミスや 労災リスクを減らしたい 管理者は、マニュアルの注意点に ついては特に定期的に ⾒返してほしいと思っている ⽂字起こしなど、リアルなセリフを残す ➡ 鉄が熱いうちに共有する⽤途 顧客の⾏動がイメージできる粒度で残す ➡ 後から⾒返して分析する⽤途 複数のファクトから⾒⽴てた課題や要求 ➡ 施策に反映する⽤途 33
34. 「全員が詳しい」チームを作るために、やったこと②⼀次情報のストック 2年弱で2000件くらい溜まってました 34
35. 「全員が詳しい」チームを作るために、やったこと 󰝋 💎 🔍 ⼀次情報を知る ⼀次情報の ⼀次情報への 機会の創出 ストック アクセス 35
36. 「全員が詳しい」チームを作るために、やったこと③⼀次情報へのアクセス 新鮮なうちに共有 いつでもアクセス 朝会で前⽇の現場訪問や Centouに直接 or MCPを使って ヒアリングのローデータを共有 いつでも知りたいファクトやインサイトにアクセス カミナシに⼊った時の私の動き⽅ 36
37. 「全員が詳しい」チームを作るために、やったこと③⼀次情報へのアクセス 新鮮なうちに共有 いつでもアクセス 朝会で前⽇の現場訪問や Centouに直接 or MCPを使って ヒアリングのローデータを共有 いつでも知りたいファクトやインサイトにアクセス カミナシに⼊った時の私の動き⽅ さらに ⼀次情報を元に施策の要求を起こすSkillを エンジニアが作成‧利⽤ ➡ ⼀次情報を元にしているので、全く違和感がないものに 37
38. 「全員が詳しい」チームを作るために、やったこと③⼀次情報へのアクセス 実際にエンジニアが作ったPRD的なもの 💎は実際の顧客の発⾔ そこから導き出される受け⼊れ条件は 全く違和感なし 38
39. 再掲：開発フローの変化 開発フローはこう変わった 従来 PRD的なものを 書く 議論する デザイン する 開発する 成果物を 確認 リリース PM PM/エンジニア/ デザイナー デザイナー エンジニア PM エンジニア PMが戦略‧ロードマップだけ提⽰🚩 PRD的なものを 書く デザインする リリース 開発する 現在 私の承認を待たずに先に進む （”承認”ではなく、”回覧”） 議論する エンジニア/デザイナー PMはみている👀 エンジニア 39
40. 意思決定にはPMが責任を持つ もちろん移譲しても意思決定には責任を持つ 特に以下のようなものは、検討過程にもしっかりと⼊り込む ❶ 職種を跨ぐフィードバックに関する 意思決定 ❷ マルチプロダクトを跨ぐ体験に関する 意思決定 セールスが”売れる”ために欲しい機能と、 カミナシは複数プロダクトが存在するが、 CSが”使い続けてもらう”ために欲しい機能は カミナシに⼊った時の私の動き⽅ 時に異なり、時にバッティングしうる。 時に体験の不⼀致が発⽣しうる。 どちらを優先するか？ あえて今はどちらを向くか？等は PMが責任を持って意思決定する 統⼀を優先するか？ スピードを優先するか？等は PMが責任を持って意思決定する 開発はそれぞれのチーム。 40
41. PMの仕事はどこへ？
42. AI時代に移動したボトルネック プロダクトは「作って終わり」ではない フィードバック 企画する 開発する セールスが理解する お客様に 販売する 販売状況を知る CSが理解する お客様に 利⽤される 利⽤状況を知る リリースする フィードバック 42
43. AI時代に移動したボトルネック 開発が速くなり、ボトルネックが移動した フィードバック 企画する ここが速くなった 開発する セールスが理解する お客様に 販売する 販売状況を知る CSが理解する お客様に 利⽤される 利⽤状況を知る リリースする ここが ボトルネックに マルチプロダクトということもあり、 新規プロダクトの理解が追いつかない ようやく理解できても、売り⽅がわからない （機能売りになってしまう） 43
44. AI時代に移動したボトルネック 開発が速くなり、ボトルネックが移動した フィードバック セールスが理解する 企画する 開発する お客様に 販売する 販売状況を知る リリースする お客様に AIで「作る」は速くなった。 利⽤状況を知る CSが理解する 利⽤される でも「売れる」「届く」は速くならなかった。 ここが速くなった ここが ボトルネックに マルチプロダクトということもあり、 新規プロダクトの理解が追いつかない ようやく理解できても、売り⽅がわからない （機能売りになってしまう） 44
45. ボトルネック解消のために PMがセールス向け免許センターを開講 セールスマネージャーと合意し、PMがセールスイネーブルメントを担うことに 【⽬的】 新規プロダクトを正しく理解してもらい、顧客との期待値 ギャップを防ぐ & 初期Go To Market を成功させる 【概要】 PMによるテスト＋ロープレに合格した⼈だけが ⼀⼈で商談できる「免許皆伝制度」 45
46. ボトルネック解消のために 作ったものが「ちゃんと売れる‧お客様に届く」ようになった やったこと 地道にセールスと1on1、ロープレ 結果 リリースして数ヶ⽉で （途中からAIロープレを導⼊） 🔥狙った業界の提案率 : 100% 商談資料のアップデート ⾃ら商談 & セールス同席 そのほかの業界も 想定を⼤きく上回る 🔥受注件数 : ⽬標⼤幅達成 価値がお客様に伝わり、短期受注も⽣まれた 46
47. このトライはあくまでHow PMが「届く」まで責任を持てるようになった フィードバック 企画する 開発する セールスが理解する お客様に 販売する 販売状況を知る CSが理解する お客様に 利⽤される 利⽤状況を知る リリースする フィードバック 従来の主な責任範囲 + 届くまでに責任を持つ 47
48. スタンスと開発フローの変化、その結果 ぶっちゃけやったことは 地味 & 地道 だし それってPMがやるの？と 思われそうだし これがセオリーとは思っていません 48
49. スタンスと開発フローの変化、その結果 それでも 私に解消できる ボトルネックを 解消したかった 💥 49
50. プロダクトマネージャーって ⾯⽩い？
51. ⾃分の歴史 いろんな経験を経て、視野がどんどん広がっていった PMなりたて PM慣れてきた頃 今 🚩 事業戦略‧ビジョン なぜ作るか 定められた⽅針‧⽬標に 応じて⾏動 担う プロダクトのKPIメイン （事業全体は担えず） 主担当 事業成⻑への オーナーシップ 🎯 機能ごとの要求 何を作るか 担う ⼀⼈で決められず チームで決める 主担当 Whyを起点に要求を 決める チームで推進 （チームを”動かす”） 主担当 PRD‧仕様書作成 チームへ移譲 チームへ移譲 ⚙ 仕様‧実装詳細 どう作るか 51
52. 今回の経験を通して得られたもの ”事業成⻑”のために、従来の役割に固執せず動いた結果 💪 🔥 ✨ セールスなど これまで未経験の領域への チャレンジ チーム全員で顧客のことを 理解し、⽩熱議論する ⾯⽩さ 速く/良いプロダクトが でき、事業がしっかり 伸びている実感 52
53. 今回の経験を通して得られたもの ”事業成⻑”のために、従来の役割に固執せず動いた結果 💪 🔥 ✨ セールスなど これまで未経験の領域への チャレンジ チーム全員で顧客のことを 理解し、⽩熱議論する ⾯⽩さ 速く/良いプロダクトが でき、事業がしっかり 伸びている実感 あんなに⼀番顧客に詳しくありたかった私はどこへ…？ でも、その変化‧チャレンジが⾯⽩い。 ‧今はどこが事業のボトルネックなのか ‧そこを解消するためにPMとしてなにができるのか 是⾮ 問い直してみてください💡 53
54. Thank you! ご清聴ありがとうございました🫶 【宣伝】 カミナシ、絶賛PM採⽤中です！！！！！！！！！ 懇親会とかで話しましょう🫶 54