開発投資の期待値を上げるプロダクトロードマップづくり ~プロダクトエンジニアが越境して事業を伸ばす~

2026-09-17
Product Engineer Session #10 @ 株式会社RightTouch
https://pesess.connpass.com/event/400876/

primeNumber
Kenta Suzuki

Transcript

1. 開発投資の期待値を上げる プロダクトロードマップづくり ~プロダクトエンジニアが越境して事業を伸ばす~ Kenta Suzuki, 株式会社primeNumber 2026/09/17 Product Engineering Session #10
2. 危険信号：こうなっていませんか？  ロードマップ  売り⽅  顧客解像度 開発ロードマップが、 「未検証の仮説」「既存 リリース直前になって、 セールスが初めて新機能 PdMやエンジニアが、週 に1回以上、顧客に会っ 顧客の既存機能への要 を知り、売り⽅を考える ていない 望」だけで埋まっている ⼀つでも当てはまるなら、今⽇の話は皆さんのためのものです 2
3. ⾃⼰紹介 & 会社紹介 株式会社primeNumber は「データテクノロジーカンパニー」 「あらゆるデータを、ビジネスの⼒に変える」をビジョンに AIのためのデータレイヤーとコンテキストレイヤーをプロダクトとして展開 鈴⽊ 健太 データ分析基盤の構築‧運⽤を⽀ えるデータ統合プラットフォーム 株式会社primeNumber / CTO COMETA プロダクトオーナー（約1年） AIのためのデータレイヤー構築 社内向けデータAIエージェントの SaaS版。データ構造を知らなくて もAIでアドホックに深掘りできる AIのためのコンテキストレイヤー プロダクト伴⾛⽀援 Professional Services 3
4. プロダクトエンジニアとは イベント概要より 「ユーザー価値を⼤切にし、プロダクト視点で開発に 向き合う⼈」 ユーザー価値 どう測る？ プロダクト視点 何を⾒る？ 1つの明確な指標は「売上」 システムの課題解決だけではない 価値 > 価格 なら売れ、下回れば解約される 顧客に届くまでの接点⼀連を「⿃の⽬」で捉える 4
5. ユーザー価値 ＞ 価格（売上） ユーザー価値 価値が価格を上回るから、売れる 価値が価格を下回れば売れず、解約される。 売上はユーザー価値の1つの明確な指標 価格(売上) 利益 利益が残るから、再投資できる 再投資でさらに価値を増やす。 会社がやっているのは、この投資の循環 再投資 投資 開発‧営業‧マーケ… 投資をどこに向けるかを決めるのが プロダクトロードマップ エンジニアの給与は1⼈でも⼤きな投資。 今⽇はここを中⼼に話します 5
6. プロダクト視点＝「⿃の⽬」で接点⼀連を捉える  プロダクト視点 顧客に届き、対価になるまでの接点⼀連 を俯瞰する ✕ ここだけが「プロダクト視点」？ 触れるレバーは課題解決の精度、速度、品質 どの課題を解くか、何社に刺さるか、いくらで、どう届 け、どう説明するか… 全体のどこに最⼤のレバーがあるかを⾒る 課題を抱える 顧客の数 どの課題を 解くか 開発 仕様‧速度 価格設計 訴求‧集客 セールス マーケ 価値の説明 商談‧ トライアル オンボー ディング レバー レバー レバー（従来） レバー レバー レバー レバー レバー 何社に刺さる？ どの課題？ 精度‧速度‧品質 いくらで？ どう届ける？ どう伝える？ 刺さっている？ 定着する？ 顧客 対価‧価値 リターンの⼤きさ（何社に刺さるか）も成功確率も、決める情報と⼿段は開発の外側の接点にこそ多い。 💡 視野を広げるほど、動かせるレバーが増える 6
7. 投資対象 ＝ プロダクトロードマップ 今のロードマップにある数百万円分の開発投資、 ⾃分のお⾦だったら払いますか？ プロダクトエンジニアの仕事は、この開発投資の期待値を上げること 期待値 ＝ リターンの ⼤きさ × 成功確率 期待値は、開発が始まる前――ロードマップに載せる段階で⼤半が決まっている 7
8. なぜ外れるか：作っても価値につながらない3つの原因 1 2 3 ユーザーが欲しいものでは なかった 届け⽅を考えきれていな かった 既存顧客の延⻑でしか⾒て いなかった お⾦を払うほどではなかった。代替 セールスが顧客に説明できない。価 要望どおりに作ったが新しい価値に ⼿段をすでに持っていた 値説明が難しく使われない なっていない → 開発投資が無駄になる → 作ったのに売れない → 新規顧客の獲得に効かない 数百万円 の開発投資が、ほとんど売上につながらなかった。弊社でも実際に起きた話です。 3つの原因はすべて、ロードマップに載せる前の検証不⾜から起きている 8
9. 答え：ロードマップに載せる前に、仮説を商談で当てる 検証 ≠ 要望の収集 既存のお客様から⾃発的に出てくる要望は、既存機能へのフィードバックが⼤半。 新しい課題と解決策の仮説は⾃分たちで具体化し、商談で顧客と会話することで、検証に 繋がる。 既存顧客商談、新規商談問わず、新しい課題仮説を当てる 9
10. primeNumber / COMETA流の仮説検証プロセス STEP 1 STEP 2 STEP 3 STEP 4 仮説の図解化 商談資料に組み込み 業務のヒアリング 集計と判断 プロダクト‧セールスで課題 「今後の開発検討アイテム」 絵を⾒せると顧客は業務を具 Claudeで議事録からフィード と解決策の仮説を⽴て、⽂字 ではなく機能イメージに落と す として載せ、セールスや私が 顧客に提⽰する 体的に話す。課題がなければ 反応がないだけ バックを抽出‧集計し「何社 に刺さったか」を数値化 プロダクトの新しい価値 を考える事に関⼼の強い セールスメンバーが多い まずはセールス1名から プロダクト理解の深いセールス1名と組んで 取り組みを開始。 10 10
11. 3つの原因に、どう効いたか 原因（Before） 取り組み後（After） 1 ユーザーが欲しいものではなかった 事前に「刺さる社数」が数値化され、無駄打ちがなく なった 2 届け⽅を考えきれていなかった セールスが今後の課題を理解済み。トークは商談で磨 かれ、リリース直後から売れる 3 既存顧客の延⻑でしか⾒ていなかった 新規⾒込み客に当てるため、失注しても「機能追加後 に再提案できるリスト」が資産に残る 11 11
12. なぜプロダクトエンジニアがやるのか 何を作るか＝開発投資の対象を決めることが、 期待値を⼀番コントロールできるレバー ⼀番⼤きいレバー 誰でも持てるレバー 価値の総和への近道 期待値は、ロードマップに載せる段 ユーザー価値を⼤切にするプロダク 課題を決める検証から実装まで⼀貫 階で⼤半が決まる。速度‧品質より トエンジニアなら、新しい仮説を考 して回せば、開発投資の期待値を最 前に、ここで勝負がつく えることができる も⾼く引き上げられる だから、プロダクトエンジニアこそが越境して「解く課題を決める」ところまでやる 12
13. まとめ  ロードマップが未検証の仮 説か既存顧客の要望だけで 埋まっている  リリース直前に、セールス が初めて新機能を知り、売 り⽅を考える  PdM‧エンジニアが週1回 以上、顧客に会っていない ロードマップに何を載せるかで、勝負の⼤半は決まる。作る前に検証し、投資期待値を⾼める 明⽇からできること ⼀緒に事業を伸ばす仲間を募集中 今のロードマップの1番上のアイテムが、 事前にどう検証されたか考えてみる 課題を決めるところから実装まで。ビジョンに共感し、 新しいことに前向きなメンバーが多い組織です 2026/11/4 エンジニア英語キャリアMeetup #04 ＠⽬黒オフィス Thank you! 13