作れるエンジニアから、価値を届けるエンジニアへ

手羽先プロンプト#2　2026/11/06の登壇資料です

Transcript

1. 作れるエンジニアから、 価値を届けるエンジニアへ 手羽先プロンプト #2 中山 龍 / Ryu Nakayama
2. 自己紹介 中山 龍 (なかやま りゅう) @ryu_develop 事業会社でAIエージェントプロダクトの • • • • • エンジニア PdM見習い UI/UX周り インサイドセールス マーケティング を担当 名古屋市在住
3. はじめに AIを使うようになって、 プロダクトを作るスピードは 上がりましたか？
4. はじめに AIを使うようになって、 プロダクトを作るスピードは 価値を生み出すスピードは 上がりましたか？
5. AIによるエンジニアの役割の変化
6. 「決めてから作る」が変わった これまで 何を提供するか決める 決まったものを作る 作るコストが大きいので、先に決めてから作るのがセオリー 現在 試しに作る 何を提供するかを意思決定する AIによって作るコストが下がり、先に意思決定することの優位性が相対的に下がってきた 作った物を起点として、何を提供するかを取捨選択しやすくなった → エンジニア (作る人) が意思決定に関与しやすくなった
7. エンジニアの役割がプロダクトの意思決定へ ← プロダクトの意思決定 技術の意思決定 → 事業・戦略 何を作るか どう作るか 市場分析・ロードマップ 仕様・体験 設計・実装・品質 エンジニア（これまで） PdM エンジニア（現在） ← 広がる 従来では PdMがメインで担っていた「何を作るか」の意思決定の領域に、 エンジニアの役割を広げやすくなってきている 実際、本実装とは別でプロトタイプを作ったり、意思決定に関与する機会が増 えた方もいるのではないでしょうか？
8. 価値のあるものを速く作れる人の価値が上がる プロトタイピングなどでプロダクトの意思決定に関与していく場合、「価値のある プロトタイプ」を「速く作る」ことができるエンジニアの価値が高まっていく 本当に価値のあるものを 作っていますか？ ※ 価値の上げ方はこれだけではない。技術的な意思決定の精度を高める、決まったものを実装する工 程を最適化するなど、様々な方向性があると考えている
9. 「どうしたら価値のあるものを 作れるか」を考える
10. 何を作るか ここでは「何を作るか」を、 誰に・何を・どう届けるか に分解する 結果 価値 ターゲット ＝ 誰に 届けるもの × 何を 体験価値 × どう届けるか
11. 誰に
12. ターゲットを選定する プロダクトを届ける相手 (ターゲット )を選定する → 「誰に」が変われば、「何を」も「どう」も変わる 例: 同じ「美味しいご飯」というものを届ける場合でも … 量が多い 安い 薄味 食べやすい
13. ターゲットの抽象度を考える ターゲットはどの観点・抽象度で捉えるかによって変わる 地方と年齢層という観点での例 抽象 日本に住む人 東海地方に住む若い人 愛知県に住む若い男 性 具体 岐阜県に住む若い人 東京都に住む年配の 人
14. ターゲットが適切に決まらないと ターゲットが適切な観点・抽象度で決められないと、 提供すべきものを考えづらくなる ターゲットに「価値」を届ける ＝ 「ターゲットに含まれるそれぞれが共通して求めているもの」を届ける → 共通部分を拾いやすい抽象度でターゲットを決める 共通部分を拾いづらい抽象度でターゲットを決めてしまうと、共通しな いそれぞれの要望を叶えようとしてしまい、提供価値がチグハグなプ ロダクトになりやすい
15. 何を
16. ペイン・求めている価値を捉える ターゲットが抱えるペイン・求めている価値を捉える → 「何を」届けるかは、ペインと価値から考える 例: 東海地方に住む若い人に「美味しいご飯」を届ける場合 … ペイン（今の困りごと） 求めている価値 量が足りない お金はあまりない 味噌が足りない 安く、お腹いっぱい 食べられる 味噌を食べたい
17. ペイン・求めている価値を捉える ターゲットを適切な抽象度で選定できていると共通のペイン・ 価値を捉えやすい 往復すると考えやすい ペイン・価値をベースにターゲットの適切な抽象度を考えやすい (また、そのターゲットの市場規模や実現可能な手段も確認)
18. 要望の背景を探る 「〜が欲しい」という要望は、具体ターゲットの持つ解決策の一案 にすぎない → その声が求めている価値に立ち返り、選定した抽象度のターゲットで共 通の価値を考えてみよう 例: 「大盛り無料にしてほしい」という声があったら … 要望 大盛り無料に してほしい ターゲットに届けるべ き価値 ペイン → 量が足りず すぐお腹がすく → 安くても 満足できる
19. どう届けるか
20. どんな体験で届けるかを考える 同じものを届けても、体験によって価値は変わる 本当はそのプロダクトにはすごく価値があるのに、届け方によっては本来 の価値を感じてもらえないかも... ウニ 本来価値のある物でも、提供 の仕方 (体験)によっては価値 を感じてもらえない
21. どんな体験で届けるかを考える 体験までを考え、ユーザーに本来の価値を提供する → ユーザーの体験価値をプロダクトの最大価値に近づける ウニ 本来価値のある物でも、提供 の仕方 (体験)によっては価値 を感じてもらえない プロダクトの価値をユーザー が感じやすいような方法で 提供する (+ CSなども)
22. ここまでの話をまとめると
23. 何を作るか エンジニアの得意領域 ※ 役割拡張の際に進出していく領域 ターゲット 誰に ユーザー・市場の理解 届けるもの × 何を コンセプトの設計 体験価値 × どう届けるか 具体手段の検討・実装 ※ 従来のエンジニア領域だけでなく、 UI/UXを含む
24. 実践するには
25. ここまでの話、ぶっちゃけ難しい 実際、やってみても ... ユーザー・市場を理解できているかわからないし、 ターゲットもうまく選定できたかわからないし、 プロダクトのコンセプト設計もいいものかわからない、 ってなると思う
26. 仮説・検証・学びのサイクルを回す 誰に・何を・どう届けるかは、一度で正解を出すのは難しい → 仮説検証のサイクルを回そう 仮説 仮説を立てる 仮説からプロダクトを作成・提供 新たな知見で再設計 学び 検証 検証結果から 洞察を得る 反応を見る 結果を分析する
27. 仮説・検証・学びのサイクル with AI AIは実装だけでなく、このサイクル全体の効率化に貢献 → 仮説検証のサイクルを高速で回せるように 仮説 仮説との矛盾点の指摘 や仮説の提案 前提知識を得や すくなった 提供までのスピードを高速化 学び 検証 分析結果から示 唆を与えてくれる ようになった 検証の仕組みを 簡単に構築でき るようになった 大量のデータを扱 いやすくなった
28. 速く、正しく失敗する 失敗を繰り返すのは大切。ただし、正しく失敗する → 仮説があるから、失敗から学べる プロトタイプで試すときの心がけ Fail Fast Fail Right 速く作って 速く試す 狙いを持って 仮説を検証する
29. まとめ
30. まとめ 作るコストが下がり、エンジニアも「何を作るか」に関われるようになった だからこそ、 「価値のあるもの」を速く作れる人 の価値が上がる ① 誰に：共通部分を拾いやすい抽象度で、 ターゲットを選定する ② 何を：要望の背景にある、 ペインと求めている価値 を捉える ③ どう届けるか：体験まで考えて、 本来の価値を感じてもらう
31. まとめ 誰に・何を・どう届けるかは、一度で正解を出すのは難しい だから、 仮説・検証・学びのサイクル を回して磨いていく AIは実装だけでなく、 サイクル全体を速く 回せるようにしてくれる 速く、正しく失敗する
32. AI時代、速く作れるからこそ 本当に価値のあるものを作れるように 速く正しく失敗をしましょう