AI時代のPdMが担う_創造的責任と再現性のない価値づくり.pdf

AI時代のPdMが担う創造的責任と再現性のない価値づくり

1. AI時代のPdMが担う 創造的責任と再現性のない価値づくり TECH PLAY Product Management Conference 株式会社ログラス Yu Sato 1
2. 2 ⾃⼰紹介 株式会社ログラス 経営管理プロダクト部 プロダクトマネージャー 佐藤 悠 Yu Sato 新卒で精密機器メーカー子会社にエンジニアとして入社。営業支援システムの開 発や新規事業の立ち上げに参画する。 その後、動画メディアベンチャーにて開発マネージャーを務める。 2022年ログラス入社。エンジニアからPMへジョブチェンジしクラウド経営管理 システム「Loglass」のプロダクトマネジメントに従事。
5. AI時代のPdMが担う 創造的責任と再現性のない価値づくり 5
6. ⾃分の背景 新規プロダクト⽴ち上げでプロダクトマネジメントに従事 6 - ゼロから新規のプロダクトを⽴ち上げるためにプロジェクトの初期から参画 - プロジェクト開始から1年ほど経過したタイミング - 少⼈数でAIを駆使しながら取り組み中
7. 7 1. 創造はアブダクション思考から⽣まれる   探究‧創造のサイクル 2. アブダクション思考は⼈間が⾏う必要がある   AIが苦⼿な理由と失敗談 3. AIで探究‧創造のサイクルを加速する   閃きに集中するための仕組みづくり 4. 閃きのための「違和感」を育てる   累積の思考回数とAI思考実験 アジェンダ
8. 1. 創造はアブダクション思考から⽣まれる 8
9. 3つの推論 9 演繹 例： 「⼈間は死ぬ」＋「ソクラテスは⼈間」 →「ソクラテスは死ぬ」 帰納 例： 「このリンゴは⾚い」 「あのリンゴも⾚い」 「そのリンゴも⾚い」 →「すべてのリンゴは⾚いだろう」 アブダクション 例： 「地⾯が濡れている」 →「⾬が降ったのかもしれない」 個別事象 ⼀般法則 仮説 具体事象 仮説 具体事象 原因仮説 結果
10. 3つの推論 10 演繹 帰納 アブダクション アブダクション = 「今⾒えていないもの」を発⾒する推論、創造の源泉 論証 正当化 発⾒ 「⼈間は死ぬ」という⼀般論に結論があり この推論から新たな発⾒はない 同じような種類が集まり正当性が強化される 違うものが発⾒されることはない 観測したものとは違う、今⾒えていない 何かを新しく発⾒する 個別事象 ⼀般法則 仮説 具体事象 仮説 具体事象 原因仮説 結果
11. アブダクション 11 アブダクション＝閃き 結果：⽊からりんごが落ちた ↓ 原因仮説（閃き）：地球が引きつける⼒があるのでは？ ↓ 万有引⼒の法則
12. 探究‧創造のサイクル 12 このサイクルを⾼速で回すことで、仮説が強化され、創造が⽣まれる AI時代のPdMは、①③をAIに任せて、②の「閃き」に集中すべき ①帰納（観察） データ収集‧分析 こういう現象がある →AIで効率化 ②アブダクション（仮説） 仮説を創出 「こうではないか？」 →⼈間が集中 ③演繹（検証） 仮説を具体化‧検証 「ならばこうなる」 →AIで効率化
13. 探究‧創造のサイクル 13 サイクルを回すことで仮説が確からしくなっていく ①帰納（観察） 個別事象① A社「予実突合に2⽇かかる」 個別事象② B社「⽉末は突合で残業」 ⼀般化：予実突合に苦しんでいる ②アブダクション（仮説） 観察された結果：予実突合に2⽇かかる 仮説（原因）：部⾨ごとにExcel形式が バラバラだから？ ③演繹（検証） ⼀般知識（仮説）： 形式がバラバラだと 突合に時間がかかる 個別事象：この会社は形式がバラバラ 結論：統⼀フォーマットで時間短縮できるはず 検証結果 → 2⽇→2時間に短縮 ④帰納（観察） 個別事象① 「⼊⼒が⾯倒」 個別事象② 「既存Excelを使いたい」 ⼀般化：ユーザーは⼊⼒作業を避けたい ⑤アブダクション（仮説） 観察された結果：⼊⼒作業⾃体がボトル ネック 仮説（原因）：新しいフォーマットへの ⼊⼒が障壁では？ ⑥演繹（検証） ⼀般知識（仮説）： 既存データを⾃動変換でき れば⼊⼒不要 個別事象：ユーザーは既存Excelを持っている 結論：AI変換機能なら⼊⼒負荷が下がるはず 検証結果 → ⼊⼒作業ゼロで激減
14. 2. アブダクション思考は ⼈間が⾏う必要がある 14
15. AIがアブダクションが苦⼿な理由 選択肢を絞れない＝コンテキストが⾜りない ①探索空間が無限 結果：道端で⼈が倒れている→ 原因の推論「病気の発作？ 事故？ 事件？ 映画の撮影？ ドッキリ？ …」 ⼈間：周囲の状況から「カメラがないから撮影ではない」と瞬時に切り捨てられる ②常識と⽂脈への依存 結果：部屋が暑い→原因の推論「エアコンが壊れた」 この推論には背景知識が必要： - 「今は夏である」「窓は閉まっている」「エアコンが付いているはず」 明⽂化されていない背景や常識をAIに全てコンテキストとして渡すのは困難
16. 1. ⾝体性 a. ⽣まれた時から物理的な世界で⽣きているため「コップを落とすと割れる」「⽕は熱い」を感覚として知っている b. 「幽霊が通った」は肌感覚として「ありえない」と切り捨てられる 2. 感情による絞り込み a. 「なんとなく嫌な予感」「こっちの⽅がワクワクする」という感情が選択肢を瞬時に「有⼒な数個」に 絞り込むことができる 3. 暗黙知と経験 a. 「エアコンが壊れた」を推測するための「今は夏である」という暗黙的な前提や、先⽉もエアコンが壊れたという 経験を⼈間は多く持っている b. AIには「⼀般知識と渡されたコンテキスト」しか情報がない ⼈間はなぜアブダクションができるか 選択肢の省略
17. 失敗体験 AIへの丸投げ - ユーザーインタビューから実現したいユースケースを観察 - そのユースケースが成⽴するための仮説として機能仕様をAIに検討させた - インタビューの議事録、既存のプロダクト仕様をコンテキストとして投⼊ →アブダクション思考をAIに丸投げした結果 ❌ 選択肢を狭めるためのコンテキスト全てを渡せなかったため、期待するアウトプットは出なかった ❌ そもそもAIのアウトプット量が多すぎて評価が⼤変だった ❌ プロンプト実⾏ → ⼤量のアウトプットを読んで評価→ 修正のプロンプト → 繰り返し...で時間を浪費した アブダクション思考による「発⾒」は⼈間がやるべき
18. 3. AIで探究‧創造のサイクルを加速する 18
19. 探究‧創造のサイクル 19 （再掲）このサイクルを⾼速で回すことで、仮説が強化され、創造が⽣まれる ①帰納（観察） 個別事象① A社「予実突合に2⽇かかる」 個別事象② B社「⽉末は突合で残業」 ⼀般化：予実突合に苦しんでいる ②アブダクション（仮説） 観察された結果：予実突合に2⽇かかる 仮説（原因）：部⾨ごとにExcel形式が バラバラだから？ ③演繹（検証） ⼀般知識（仮説）： 形式がバラバラだと 突合に時間がかかる 個別事象：この会社は形式がバラバラ 結論：統⼀フォーマットで時間短縮できるはず 検証結果 → 2⽇→2時間に短縮 ④帰納（観察） 個別事象① 「⼊⼒が⾯倒」 個別事象② 「既存Excelを使いたい」 ⼀般化：ユーザーは⼊⼒作業を避けたい ⑤アブダクション（仮説） 観察された結果：⼊⼒作業⾃体がボトル ネック 仮説（原因）：新しいフォーマットへの ⼊⼒が障壁では？ ⑥演繹（検証） ⼀般知識（仮説）： 既存データを⾃動変換でき れば⼊⼒不要 個別事象：ユーザーは既存Excelを持っている 結論：AI変換機能なら⼊⼒負荷が下がるはず 検証結果 → ⼊⼒作業ゼロで激減
20. サイクルを⾼速化する3つの実践 20 ヒアリング内容を AIに自動連携 GASで文字起こしをMarkdown化し、AIにすぐ渡せる状態に GitHubでストック情報を資産化 flow/stockで情報を分け、チームで仮説を強化 1 2 バイブコーディングでプロトタイプ コードを見ずにプロンプトだけで仕様を形に 3 共通するポイント：⼈間の⼿を介さずにAIに情報が流れる仕組みを作る
21. 実践①：ミーティング、ヒアリング内容をAIに⾃動連携 GASによる⾃動処理 ⼿順 - GASは定期実⾏してカレンダーにリンクされているMeetの⽂字起こし（Google Docs）を取得して Markdownファイルに変換 - GoogleDriveアプリで⼿元のPCに同期 効果 - 議事録作成の時間を⼤幅削減 - 過去のヒアリングとの⽐較分析もAIに任せやすい ⽂字起こし Markdown GAS⾃動処理 同期
22. 実践②：GitHubでストック情報として資産化 ⾮エンジニアも含めて全員ドキュメントはGitHubで集中管理 フォルダ構成 - flow - ⾃由に作業、レビューなし - 今後⾒ないAIとの壁打ちログなど - stock - ⼈間レビュー必須で正しい情報のみ⼊る状態を担保する - 仮説、検証結果、仕様など 仮説をチームの所有物にしながら、演繹‧帰納を進める 効果 - 仮説の評価‧強化をチームで進められる - AIに正しいコンテキストを渡せる → 演繹‧帰納の精度が上がる
23. 実践③：バイブコーディングでプロトタイピング 効率が良かった役割分担 - エンジニアが整える - 環境構築、⾔語選定 - フォルダ構成、リリースの仕組み構築 - PdMがやること - コードは⼀切⾒ないバイブコーディング - プロンプトで仕様を書くだけ - PRを出して仕様確認→マージ 効果： - 「これだ」と閃いた仮説を、すぐに形にして検証できる - 検証→修正のサイクルが劇的に速くなる ⾮エンジニアもプロトタイピングで仮説検証する
24. 4. 閃きのための「違和感」を育てる 24
25. 閃きの源泉は「違和感」 どうやって閃くのか？ - 累積の思考回数が増えていくと、ふとした時に 「ん？おかしいな」「なんか変だな」という感覚が出てきます - その違和感が、アブダクションの前提になります 違和感をそのままにしない - 少しでも違和感を感じたら、⾔語化する - チームにも「違和感があれば⾔語化して欲しい」と常に伝え続けている AIと思考実験する - 違和感からの思考は、以前は⼀⼈では時間的にも体⼒的にもきつかった - 今はAIが思考実験に付き合ってくれるため実現が可能になった 役割分担：閃き（違和感）は⼈間が、それが成⽴するかはAIが考える
26. 「違和感」を育てる活動 26 AIではなく、⼈間が⾏い貯める活動 競合リサーチ → 議論 競合がこうなっている、と調べて終わりじゃなく、 なぜそうなのか？うちはどうする？をチームで議論する 顧客の現場に⾏く → 伝える お客さんのところに行って体験して、 それを周りに伝えてみる。言語化する過程で気づきが生まれる プロトタイプを作る 実際に手を動かして形にしてみる。 作る過程で「あれ？」という違和感が出てくる いろんな関係性でドメインを⾒る ユーザー視点、業務視点、技術視点 ... 多角的に見ることで、矛盾や違和感に気づける これらは「効率化」の対象ではない。むしろ時間をかけるべき活動
27. 成功事例：違和感 → AI思考実験 → 設計 今の仕様の⼟台になった考えは、違和感から⽣まれた 違和感 - 競合や既存システムを調べていて 「なんでこの仕様はxxなんだろう？」「もっとシンプルにできないか？」 ⾔語化 - 違和感を⾔葉にしてみる - 「xxをこう変えたらもっとxxになるのでは？」 AI思考実験 - AIに問いを投げて検証 - 「これで破綻しないか？」 - 「エッジケースは？」
28. 成功事例：違和感 → AI思考実験 → 設計 今の仕様の⼟台になった考えは、違和感から⽣まれた 閃きは⼈間が、成⽴するかはAIが考える。この役割分担が重要 結果：仕様の⼟台が⽣まれた - いきなり違和感なしにAIに設計させても、着想がないのでありきたりなものしか⽣まれない - 違和感という「問い」があるから、AIとの思考実験が意味を持つ
29. 違和感を育てるサイクル 違和感そのものは⼈間にしか⽣めない いろんなところでAIを活⽤する - 累積の思考回数を増やす - 競合リサーチ、ドメイン探索 - 違和感の⾔語化を助ける - こういうことを感じているんだけど‧‧‧を整理 - 思考実験に付き合う - 問いを与えて破綻しないかを検証させる 累積の思考回数 ⼿と頭を動かす 現場に⾏く、作る、議論する 違和感に気がつく 「ん？おかしいな」 「なんか変だな」 ⾔語化する そのままにしない チームにも共有する AI思考実験 まずは机上で仮説を検証する 破綻しないか確認
30. 結論 仮説を閃き、それを検証し価値として具現化すること ＝創造的責任を担う そのために 1. 帰納‧演繹はAIでショートカット a. 議事録化、資産化、プロトタイピングを効率化 2. アブダクション（閃き）に集中 a. 選択を絞り込むのは⼈間の仕事 3. 閃きのために「違和感」を育てる a. 累積の思考回数を増やし、⾔語化し、AI思考実験 AI時代のPdMの役割とは？
31. 明⽇からやる3つのこと 31 累積の思考回数を増やす習慣をつける 現場に行く、プロトを作る、チームで議論する。 違和感をそのままにしない 「ん？」と思ったらメモする、言語化する。チームで違和感を育てる 1 2 違和感が出たら AIと思考実験する 「この仮説は破綻しないか？」をAIに問う。閃きは人間、検証はAI。 3 違和感を育てて、AIと検証する。それがAI時代のPdMの働き⽅