PMとしてLLMと上手くプロダクトを作るための抽象度レイヤーの設計

https://d-cube.connpass.com/event/354319/

Transcript

1. 2025 | © Commune Inc. All rights reserved Kokoro Higuchi / ौ୩ Biz × LLM: Ϗδωεʹ͓͚Δ LLM ར׆༻ ࣄྫษڧձ ୈ2ճ 2025/06/11 PMとしてLLMと上 手 くプロダクトを作る ための抽象度レイヤーの設計
2. 2025 | © Commune Inc. All rights reserved PMとLLMがプロダクトを共創するには、 課題のレイヤーを分けて、 レイヤーに応じた問いかけを設計する必要がある 今 日 お話ししたいこと
3. 2025 | © Commune Inc. All rights reserved お話したいと思った理由 PMになってから思ったより LLMを使いこなせなかったから🥲
4. 2025 | © Commune Inc. All rights reserved 樋 口 心 (X: @zerebom_ 3 ) • 現職:Communeの新規事業のプロダクトマネジャー(PM) • 誰の何を解決するか、何を作るかを決める • 関 心 ) ヒアリング, ロードマップ, 要件定義･･･ • 前職: Wantedlyのデータサイエンティスト(DS) • 人 と仕事がより良くマッチングするように 推薦システムのアルゴリズムを改善する • 関 心 ) 推薦システム,MLOps, A/Bテスト… 自 己 紹介 ↑資料はXに掲載
5. 2025 | © Commune Inc. All rights reserved 会社紹介
6. 2025 | © Commune Inc. All rights reserved あらゆる 組織とひとが 融け合う未来をつくる Our Vision
7. 2025 | © Commune Inc. All rights reserved
8. 2025 | © Commune Inc. All rights reserved 立 ち上げ、成功できるコミュニティプラットフォーム
9. 2025 | © Commune Inc. All rights reserved 会社紹介
10. 2025 | © Commune Inc. All rights reserved PMになってから思ったよりLLMを使いこなせない 大 きめの機能の要件定義の壁打ちに使ったものの、難航 • CursorでLLMと壁打ちしながら要件定義 • 高 性能なLLMと会話し、詳細な情報は得られたが チームの納得感は得られず • 会話の論点がズレたり、時間もかかった • DSの頃に 比 べてLLM活 用 の難しさを感じる → 何か気をつけることがあるのかも🤔
11. 2025 | © Commune Inc. All rights reserved 自 分の職務の変化: DSの頃の職務 最終的に『どう作るか』を考え、形にすることに責任を持つ • 業務内容 • 良い仕事のマッチングのための推薦システム改善 • コミュニティの状況を俯瞰できるダッシュボード作成 • LLMの活 用 • 難しい課題に対して、解法アイディアや実装を相談 • ex).ユーザーに多様なアイテムを推薦するには、どうアルゴリズムを作るべき？
12. 2025 | © Commune Inc. All rights reserved 自 分の職務の変化: PMになってからの職務 PJの中間地点にたって、作る物を決める. Why/Whatに責任を持つ • 業務内容 • 顧客の課題を 見 つける ・ 解くべき課題をきめる • 課題解決に必要な作るべき物をきめる • LLMの活 用 • 課題抽出や解くべき課題について壁打ちする • ex).こういうユーザーがいて、この課題を解決したいけど、どんな機能が必要?
13. 2025 | © Commune Inc. All rights reserved 自 分が 行 っていたPMとDSの業務の違い PMは相対的に発散的 / 定性的 / 必要な抽象度が幅広い DS(解決策を形にする) PM(何を作るか決めて、形にする) 主な抽象度と役割 解決策の深掘り 課題の探索と解決策の定義 成果の評価軸 指標中 心・ 客観的 多 角 的 ・ 定性的 問題解決プロセス 問題に対する最適な解を 見 つける (収束的) 問題発 見・ 定義や解決策の探索を繰り返す (発散的) ※あくまで 自 分の経験した範囲上の相対的な傾向です
14. 2025 | © Commune Inc. All rights reserved 前提がズレた中で 大 量の情報を受け取りやすい PMの業務: • 抽象度の 高 い前提を詰める LLMとの壁打ちの特徴: • プロンプトの内容を前提として 多量に詳細な情報を出 力 業務の差異によってLLMとの会話が難しくなっていた
15. 2025 | © Commune Inc. All rights reserved 業務の差異によってLLMとの会話が難しくなっていた • 本当はこの先を 思考すべき • 詳細情報を 大 量にもらうが… 前提がズレた中で 大 量の情報を受け取りやすい
16. 2025 | © Commune Inc. All rights reserved できあがってしまった 長 文 の要件定義書…🪦 前提がズレた中で 大 量の情報を受け取りやすい
17. 2025 | © Commune Inc. All rights reserved PMとLLMがプロダクトを共創するには、 課題のレイヤーを分けて、 レイヤーに応じた問いかけを設計する必要がある 学んだこと
18. 2025 | © Commune Inc. All rights reserved 解決策の全体像 抽象度レイヤーを理解し、LLMに渡す。独 自 のコンテキストで具体度を上げる • プロダクトの概念階層を正しく理解する • プロダクトの概念階層をLLMに取り 入 れる • 顧客 ・自 社のコンテキストを取り 入 れて、具体度を上げる
19. 2025 | © Commune Inc. All rights reserved 解決策1. プロダクトの概念階層を正しく理解する なぜ、なにを、だれに、を決めてから、どうやって(画 面 や実装)を固めていく ٴ઒
    ୎໵
    ીࠜݪ
    य़थ
    খ৓
    ٱඒࢠ
    
    ʮϓϩμΫτϚωδϝϯτͷ͢΂ͯ
    ࣄۀઓུɾ*5։ൃɾ
    69σβΠϯɾϚʔέςΟϯά͔ΒνʔϜɾ૊৫ӡӦ·Ͱʯ
    ষΑΓҾ༻ • Core:プロダクトでどんな世界を実現するか • Why: 誰をどんな状態にするか • What: どんな順序でどんな価値を提供するか • How: どのように実現するか アーティファクト機能などで プロンプトから直接How(ex. UI)が出 力 されやすいが、Howは最後
20. 2025 | © Commune Inc. All rights reserved 解決策1. プロダクトの概念階層を正しく理解する ビジネス > 業務 > システム ＆ 要求 > 要件 と作るものや考える範囲を狭めていく 赤 俊哉 「だまし絵を描かないための要件定義のセオリー 」1章 より引 用 例) • ビジネス要求: 顧客の拡 大 • 業務要求: EC会員数の増加 • システム要求: 新決済システムの作成 • 要求: 本当にほしいもの • 要件: 制約を踏まえシステムにすべきもの
21. 2025 | © Commune Inc. All rights reserved 解決策2. プロダクトの概念階層をLLMに取り 入 れる LLMにも抽象度を理解させ、コンテキストを狭めていく • Claude.mdや.cursor/ 配下にルールを設定 • 上流設計の前にLLMが詳細を提 示 しない ようにする
22. 2025 | © Commune Inc. All rights reserved 解決策2. プロダクトの概念階層をLLMに取り 入 れる LLMにも抽象度を理解させ、コンテキストを狭めていく • 自 分の中でどの順序で具体化するか型を持っておく • 上流のアウトプットを下流のインプットにし順序 立 てて会話する
23. 2025 | © Commune Inc. All rights reserved 解決策3. 顧客 ・ 自 社のコンテキストを学び、取り 入 れる 具体度を上げ、個別性のある回答を得る 「〜がより 高 い、強い…」など 比 較優位性 だけだと、苛烈な競争に陥りやすい コンテキストがないとLLMは 比 較優位な機能を提案しやすい (ex. パーソナライズ化 ・ リアルタイム化) 西口 一 希 「たった 一人 の分析から事業は成 長 する 実践 顧客起点マーケティング」 より引 用
24. 2025 | © Commune Inc. All rights reserved 解決策3. 顧客 ・ 自 社のコンテキストを学び、取り 入 れる 具体度を上げ、個別性のある回答を得る クレイトン ・ Ｍ ・ クリステンセン (著), 依 田 光江 (翻訳) ジョブ理論 　 イノベーションを予測可能にする消費のメカニズム より引 用 > ジョブは 日 々の 生 活のなかで発 生 するので、 その 文 脈を説明する「状況」が定義の中 心 に来る。 自 社のプロダクトポートフォリオやユーザーの状況などを深く理解し、 LLMに独 自 性のある解決策を作成してもらう
25. 2025 | © Commune Inc. All rights reserved まとめ • PMになってからLLMに要件定義などを 手 伝ってもらったがうまくいかず • PMは抽象的な問題に対応する& LLMは詳細な情報を提供しやすい → より抽象度の設計が必要になった • 下記対応でより上 手 く 手 伝ってもらえるように • 自身 がプロダクトの抽象度レイヤーを理解する • 抽象度の設計をLLMに渡す • 独 自 のコンテキストで具体度を上げる ↑Communeの プロダクトマネージャーに 興味を持った 方 がいたら是 非 ！