エンジニアのためのプロダクトセンス（Product Sense）完全ガイド: 顧客共感・JTBD・North Star・ABテスト・PMF・優先順位・ロードマップまで (2025~2026)

"Fall in love with the problem, not the solution." — Uri Levine (Waze創業者)

エンジニアがStaff+へ向かう道で最も大きくつまずく区間: プロダクトセンス。技術力でL4~L5に到達したあと、L6 Staffへ進むには「何を・なぜ作るのか」の判断が不可欠だ。

2024~2025年、AIによるコード生成で「どう実装するか」の価値は相対的に下がり、「何を・なぜ」を判断する価値が上がった。この記事はエンジニアが毎日使えるプロダクトセンスのシステムを作る。

1. プロダクトセンスとは何か

1.1 定義

プロダクトセンス = ユーザーのニーズ・行動・文脈を理解し、ビジネス目標と整合したプロダクト意思決定を下す能力。

3つの軸:

1. Customer Empathy: 誰が・なぜ・どんな状況で使うのか。
2. Problem Framing: 本当の問題は何か。
3. Solution Judgment: 複数の解法のうち何をなぜ選ぶのか。

1.2 技術センス vs. プロダクトセンス

Staff+ = 2つのセンスの統合。片方しか持たないエンジニアはSeniorに留まる。

1.3 エンジニアがプロダクトセンスを得ると起きること

• スペックレビューで本質的な質問ができる。
• PMと対等な会話ができる。
• 技術的負債の議論でトレードオフの言語を使える。
• ロードマップ会議で優先順位についての意見を持てる。
• 起業・社内起業ができる。

2. Customer Empathy — 顧客共感の3段階

2.1 Level 1 — Data-based Empathy

• Google Analytics・Mixpanel・Amplitudeの分析。
• Cohortの継続率、Funnelの離脱。
• 誰がどれだけ長く留まるのか。

限界: 数字は「何が」は見せてくれるが、「なぜ」は説明できない。

2.2 Level 2 — Observational Empathy

• User Session Recording: Hotjar・FullStoryで実際の利用を録画。
• Support Ticketの分析: 繰り返される痛み。
• NPS・アンケート: 直接聞く。
• Sales Callの録音: Gong・Chorusで聴く。

限界: ユーザーが「言ったこと」と「本当に望んでいること」は違いうる。

2.3 Level 3 — Immersive Empathy

• 顧客訪問: 彼らのオフィスや自宅で実際の利用を観察する。
• Dogfooding: プロダクトを自分自身が毎日使う。
• 顧客のShadowing: 一日そばについて業務を観察する。
• 顧客の役割を演じる: PMや開発者がペルソナのプロダクトなら、自分でやってみる。

例: Airbnbの創業者3人が1か月間、自社プロダクトだけを使い続け、「もう一度予約したい宿」がなぜこれほど少ないのかを発見 → プロ写真サービスを無料で導入 → 売上が2倍。

2.4 エンジニアが今すぐ始められる5つ

1. 毎月5人の顧客と30分通話する。「先週、この製品をいつ使いましたか？」
2. Supportチャンネルを購読する。Slack・Zendeskの通知。
3. 自社プロダクトを毎日使う。Eat your own dog food.
4. Reviewサイトをモニタリングする。G2・Capterra・Product Hunt・App Storeのレビュー。
5. 週1回Sales Callを聴く。

3. Jobs-to-be-Done (JTBD) — 問題フレーミングの革命

3.1 Christensenの「Milkshake Story」

マクドナルドのミルクシェイク売上増加の原因調査:

• 人口統計的セグメンテーションは失敗。
• 顧客観察: 朝7時に30〜40代の男性が通勤途中で購入している。
• JTBD: 「退屈な通勤をまぎらわせ、空腹を10時まで持たせてくれる手軽なものが必要」。
• 競合相手: バナナ・ベーグル・コーヒー（他のミルクシェイクではない）。
• 解法: 朝専用の濃いミルクシェイク、素早く出せる仕掛け。

3.2 JTBD Framework

「人は製品を買うのではなく、自分の人生で何らかのProgressを作るために製品をHireする」 — Christensen

Job Storyのフォーマット:

When [situation], 
I want to [motivation], 
So I can [expected outcome].

例:

• Bad: 「顧客はモバイルアプリを求めている」。
• Good: 「出張中に空港のラウンジで、素早く予定を確認したい。会議直前に準備できていると感じるために」。

3.3 Functional/Emotional/Social Jobs

• Functional: 機能的な課題（やることの追跡）。
• Emotional: 感情（不安の低減・達成感）。
• Social: 社会的なもの（プロフェッショナルに見えること）。

例 — Teslaの購入:

• Functional: AからBへの移動。
• Emotional: 環境への罪悪感の解消、未来感。
• Social: 環境に優しいイメージ、アーリーアダプターの地位。

Functionalだけを見るとプロダクト設計は失敗する。

3.4 エンジニアのためのJTBD実践

自分がいま作っている機能について:

1. この機能を使うユーザーはどんな状況にいるのか。
2. この機能でどんなProgressを作ろうとしているのか。
3. Functional・Emotional・Socialはそれぞれ何か。
4. 同じProgressを与える別の解法は何か。（競合）
5. この機能はこのProgressを本当に作り出すのか。

この5つの質問だけでスペックの50%は改善できる。

4. North Star Metric — 全員が同じ方向へ

4.1 North Star Metricの定義

"The one metric that best captures the core value your product delivers to customers." — Sean Ellis

たった一つの指標が上がれば、プロダクトと会社が成功する — そういう指標。

4.2 有名なNSMの例

共通点:

• 顧客が実際に価値を体験する行動であること。
• 会社の売上と相関すること。
• 測定可能であること。
• 向上可能であること。

4.3 NSMのアンチパターン

• Revenue自体: 遅行指標で、チームが直接動かせない。
• PV・クリック: 量的な増加は簡単だが価値とは無関係（Yahoo時代の失敗）。
• 複数ある: 4つ以上なら北極星ではない。

4.4 エンジニアの実践的な適用

機能単位のNSM設計:

• チームが作る機能のNSMは何か。
• この機能は自分のチームのNSMにどう寄与するのか。
• NSMを上げられない機能をなぜ作るのか。

スペックレビューでこの機能のNSMへの貢献は何かという質問を一つ投げるだけで、チームの意思決定の水準は変わる。

5. Product-Market Fit (PMF) — 有無と段階

5.1 PMFの定義

"Product-Market Fit means being in a good market with a product that can satisfy that market." — Marc Andreessen

PMFはOn/OffではなくSpectrumである。

5.2 Rahul VohraのPMF Survey

「もしこの製品がもう使えなくなったら？」

• Very Disappointedが40%以上ならPMF。
• 40%未満: まだPMFではない。

Superhumanはこの方法でPMFへの経路を設計した。

5.3 PMFの4段階

1. Idea Fit: アイデアが実際の問題を扱っているか。
2. Problem Fit: ユーザーがその問題を実際に感じているか。
3. Solution Fit: 我々の解法がその問題を解くか。
4. Market Fit: 市場に支払い意思があるか。

エンジニアが頻繁に陥る罠: 3番に多くの時間を使い、1番・2番の検証なしに走り出すこと。

5.4 PMFの後 — Scale Fit

PMFの後も成功ではない。Go-to-Market Fit・Channel Fit・Pricing Fitをそれぞれ確保しなければならない。

多くのTechスタートアップはPMFはあるのにGTMがなくて失敗する。

6. AB Test — 実験の技術

6.1 AB Testが失敗する理由（60%以上）

1. Sample Sizeの不足: 統計的有意性に届かない。
2. 短期の測定: 一週間の実験では長期の影響が見えない。
3. Novelty Effect: 初期の効果を持続的な効果と誤解する。
4. Metricの誤り: 代理指標（Proxy）しか見ていない。
5. Segmentationの無視: 平均は良くても一部のグループは壊れている。
6. 外部変数: 季節・イベント・マーケティングの変化。
7. Implementationのバグ: AとBが意図どおりに分離されていない。
8. Selection Bias: グループの割り当てがランダムでない。

6.2 まともなAB Testのプロトコル

1. Hypothesis: "If X, then Y, because Z."
2. Sample Sizeの計算: Power Analysisで事前に。
3. 期間: 最低2週間~1か月、週次のCycleを考慮する。
4. Primary Metric + Guardrail: 主指標 + 悪化させてはいけない指標。
5. Segmentationの計画: 事前に。
6. MDE (Minimum Detectable Effect): 検知したい最小の効果。
7. Analysis Planを事前に: 事後のp-hackingを防ぐ。

6.3 Airbnb・Booking.comの事例

• Booking.com: 同時に1,000件の実験を運用。年1,000件のうち90%はNULL・Negative。改善するのは10%だけ。
• 教訓: 実験のほとんどは失敗する。実験文化とは失敗を素早く発見することだ。

6.4 エンジニアの実験Mindset

• 各機能の前に「実験で検証できるか？」を問う。
• 失敗した実験を学習として再フレーミングする。
• Confidence Intervalを理解する（統計の基本を知る）。
• Launchは実験の終わりではなく、継続的なモニタリングの始まり。

7. 優先順位のフレームワーク

7.1 RICEフレームワーク

• Reach: どれだけ多くのユーザーに届くか。
• Impact: どれだけ大きな影響か（1・2・3点）。
• Confidence: どれだけ確信があるか（0.5・0.8・1.0）。
• Effort: どれだけ大きな労力か（Person-Month）。

RICE Score = (R × I × C) / E.

7.2 Kano Model

ユーザー視点での機能分類:

1. Must-be（必須）: なければ不満、あっても当然。
2. Performance（性能）: 多いほど満足。
3. Attractive（魅力）: なくてもよいが、あれば驚く。
4. Indifferent: 気にしない。
5. Reverse: あると嫌われる。

戦略: Must-beは確保し、Attractiveへの投資で差別化する。

7.3 ICE — 軽量版

• Impact, Confidence, Easeを各10点。
• 合計が高いものから先に。

RICEより速く、会議で使いやすい。

7.4 エンジニアが優先順位会議で貢献する方法

• エンジニアだけが見える費用: 技術的負債の蓄積と維持コスト。
• エンジニアだけが見える価値: Future Optionality・Platform効果。
• 数字で出す: 「これを今やらないと6か月後にXのリファクタリングがY週間必要になる」。

8. Roadmapの設計 — 3か月・6か月・2年

8.1 Now / Next / Laterのフレーム

• Now（次の1~3か月）: Commit、具体的。
• Next（3~6か月）: 優先順位づけ済み、変動しうる。
• Later（6か月以降）: 方向性、柔軟。

8.2 Outcome-based Roadmap

Feature listの代わりにOutcome + 実験で:

Q1 Outcome: Free→Paidの転換率 10%→15%。
Experiments:
- Onboarding checklistの改善
- Paid Trialの友達招待インセンティブ
- Usage-based pricingの実験

利点: 特定の機能が失敗してもOutcomeの達成に集中できる。

8.3 Lean Roadmap (Opportunity Solution Tree)

Teresa TorresのContinuous Discovery:

• Outcome: 目標。
• Opportunities: 問題・機会を3~5個。
• Solutions: 各機会につきアイデアを2~3個。
• Experiments: 各ソリューションの検証。

Top-downなロードマップの硬直性を解消する。

8.4 2年Vision + 90日Tactical

• 2年Vision: 変わらない、チームの方向。
• 90日Tactical: 3か月ごとにReview・Adjust。
• 毎月: Progressのチェック。
• 毎週: Blocker・Shift。

9. エンジニア + PM関係のデザイン

9.1 最悪 vs. 最高の関係

9.2 エンジニアがPMとの関係で投資すべきこと

1. PMのWhyを理解する: OKR・NSMを体得する。
2. Customer Empathyの共有: Session・Ticketを一緒に見る。
3. Tech Constraintの説明: PMが理解できる言語でTrade-offを話す。
4. Proactive Proposal: 「これはどうですか？」と先に提案する。
5. Respect Product Thinking: 「PMはただSpecを書く人」という偏見を捨てる。

9.3 PMのいないチームのエンジニア

スタートアップや小さなチームではエンジニアがPMの役割を兼ねる:

• Customer Callを自ら Lead する。
• OKR・ロードマップのドラフト。
• 優先順位の決定権。
• 成果の測定。

こうした経験はStaff+や起業に向けた強力な資産になる。

10. プロダクトセンスの学習資料 Top 15

10.1 書籍

1. 『Inspired』 — Marty Cagan（プロダクトチームの原則）。
2. 『The Lean Startup』 — Eric Ries（実験文化）。
3. 『Escaping the Build Trap』 — Melissa Perri（Outcome）。
4. 『Competing Against Luck』 — Clayton Christensen（JTBD）。
5. 『Hooked』 — Nir Eyal（習慣の設計）。
6. 『The Mom Test』 — Rob Fitzpatrick（顧客インタビュー）。
7. 『Measure What Matters』 — John Doerr（OKR）。
8. 『Trustworthy Online Controlled Experiments』 — Kohavi。

10.2 ブログ・Newsletter

9. Lenny's Newsletter。
10. First Round Review。
11. Reforge Blog。
12. Stratechery (Ben Thompson)。

10.3 Podcast

13. Lenny's Podcast。
14. Acquired (Ben Gilbert, David Rosenthal)。
15. This Week in Startups (Jason Calacanis)。

11. 90日プロダクトセンス・スターター

11.1 Month 1 — Empathy Foundation

• 週5人の顧客との通話。
• 毎日自社プロダクトを使う。
• Supportチャンネルを毎日10分。
• 顧客のReviewサイトを週1回。

11.2 Month 2 — Framing

• JTBDのフォーマットで3つの機能を書き直す。
• NSM・Guardrailをチームと議論する。
• Session Recordingを週1時間。

11.3 Month 3 — Judgment

• RICEでロードマップを再優先順位づけする。
• 実験を1つ自分で設計する。
• 90日Outcomeのドキュメントを作成する。

12. プロダクトセンス・チェックリスト12

• 毎月5人の顧客と30分会話している。
• 自社プロダクトを毎日使っている。
• Supportチャンネルを購読している。
• JTBDのJob Storyフォーマットに慣れている。
• チームのNSMを理解・共有している。
• 自社プロダクトをPMFの段階で診断している。
• AB Testの基本統計を理解している。
• RICE・ICEで優先順位をつけている。
• Outcome-based Roadmapを使っている。
• PMと対等なProductの会話ができる。
• 四半期ごとにCustomer Deep Diveを行う。
• 書籍・Podcastを継続的に摂取している。

13. プロダクトセンスのアンチパターン10

1. 「エンジニアは実装だけ」: Staff+は不可能。
2. Featureの要望をそのまま実装する: JTBD・Opportunityの無視。
3. 「売れないのはマーケのせい」: PMF不在という認識がない。
4. 短期の指標だけを追う: Retention・LTVの無視。
5. AB Testの結果のチェリーピッキング: 望む結果だけを選んで見る。
6. NSMなしで働く: 方向なしに機能を作る。
7. 顧客が「言ったこと」をそのまま: Fordの「もっと速い馬」の罠。
8. Feature Factory: 機能の数 = KPI。
9. 「No Time for Discovery」: 実行に忙しく検証しない。
10. PMを敵視する: 学ぶ機会を放棄する。

14. まとめ — プロダクトセンスは筋肉である

"Good judgment comes from experience. Experience comes from bad judgment." — Mulla Nasrudin (推定)

プロダクトセンスは生まれつきではない。ユーザーと過ごした時間の関数である。

週5回の顧客通話 × 10年 = 2,500回の通話。この経験があなたを別のエンジニアにする。

2026年のエンジニアにとってプロダクトセンスはStaff+へ向かうTier-1の経路だ。技術力はAIで相殺されるが、ユーザー・市場・ビジネスの理解は依然として人間の領域である。

始めるには3つで足りる:

1. 今週、顧客1人と30分通話する。
2. JTBDのJob Storyで次のPR descriptionを書く。
3. 自分のチームのNSMを読み、次のスプリントでの貢献を一文にまとめる。

3か月後、あなたのスペックレビューは別の品質になっている。

次回予告 — 「エンジニアの政治力: 組織・権力・意思決定・Alliance・Political Capitalの設計まで」

プロダクトセンスが「何を」なら、組織の政治力は「どう通すか」だ。次回は:

• 権力(Power)の定義 — Jeffrey Pfeffer『Power』
• Political Capitalの蓄積と支出
• AllianceとStakeholder Mapping
• 対立の種類と解消 — Lencioniの5 Dysfunctions
• 「Push vs Pull」の影響戦略
• Good Politics vs. Bad Politics
• Promotion・Reorg・予算確保の実践
• エンジニアがよく忘れる政治力5つ

「政治は汚いもの」という偏見を捨て、善く効果的な政治力を設計する。次回に続く。