こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp
PdM（プロダクトマネージャー）って、企業によってやることがバラバラですよね。
「仕様書を書く人」みたいになってる会社もあれば、 「戦略を決める人」だったり、「なんでも屋」だったりする。その中で、よく出てくるモヤモヤがこれです。
顧客インタビューをしていないPdMって、本当にPdMなの？ 逆に言えば、 エンジニアやデザイナーでも、顧客理解しながら動いていたらPdM的じゃない？ この記事では、toB SaaS という文脈に絞って、この疑問をカジュアルに掘っていきます。
こんな方が対象：
- PdMを目指している人
- いま PdM をやっているけどあまり顧客に会えていない人
- 「自分はPdMと言えるのか？」と不安になっている人
- ✋ 結論から言うと…
- 👀「インタビューをしているエンジニア/デザイナーはPdM行為をしている」という話
- 🤔 では「なぜ顧客に会わないPdM」が生まれるのか？
- 🔚 最後に：PdMとは「顧客理解から逃げない人」
- 🌟 最後に PdMを目指すあなたへ
✋ 結論から言うと…
toB SaaSでは、顧客接点がないと、PdMとしての意思決定が難しくなりやすい／PdM的になりづらい
これは辛口でもなんでもなく、
プロダクトマネジメントの本質が “顧客理解に基づいた意思決定” だからです。
じゃあこれで決まり？
いや、もちろん例外もあります。 ちゃんと後半で書きます。
🧩 PdMの仕事って結局こういう構造
上の段に行くほど “PdMである必要性が高まる” のですが、意思決定の源泉が 顧客の一次情報 である以上、
一次情報を持っていないPdMは、そもそも材料不足で判断できない。
となるわけです。
💡 toB SaaSではなぜ顧客インタビューが必須級になるのか？
toCと違って、toB SaaSは 業務の中に深く入り込むタイプのプロダクトです。
つまり、顧客側の現実がめちゃくちゃ複雑。
① 顧客の業務は会社ごとに全然違う
フローも違う。 権限も違う。運用ルールも違う。
机に向かって仕様を書くより、5分の会話のほうが100倍早い。
② 営業やCSの声は貴重だが「偏り」がある
営業：売りたい人 / CS：困りごとを聞く人 なので、本質はその奥にあることが多い。
③ 機能の一つが全体の業務に影響する
toB SaaSでは、以下みたいなことがよくある。
- 承認フローが変わる
- 会計処理に影響する
- セキュリティに関わる
- 別部署の仕事まで変わる
つまり、 「ちょっとした仕様判断」が全社レベルの業務変更につながる。 これは顧客理解なしには危険すぎる。
🧩 顧客理解なしのPdMが陥る罠
はい、負のスパイラルのできあがりです。
👀「インタビューをしているエンジニア/デザイナーはPdM行為をしている」という話
これも多くの現場で起きています。
- デザイナーがユーザーに話を聞いて課題を整理してる
- エンジニアが仕様理解のために顧客にヒアリングしてる
- CS が課題を深掘りして問題の本質に迫ってる
これ全部、PdMの本質的な行為です。
肩書きがなんであれ、
顧客理解を元に意思決定に影響を与えているなら、それはPdM的な動きです。
逆に、肩書きがPdMでも顧客理解がなく、意思決定していないなら、
PdM行為をしているとは言えない。
🧩 肩書きPdMと実質PdMの違い
【肩書きPdM】
- 社内調整
- 仕様書作成
- 会議進行
- タスク管理
→ 顧客理解なしでもできてしまう
【実質PdM】
- 顧客理解（一次情報）
- 課題定義
- 仮説検証
- 優先順位の意思決定
→ 顧客理解がないと成立しない
あなたが見てきた「名ばかりPdM」が前者であることは多いです。
🤔 では「なぜ顧客に会わないPdM」が生まれるのか？
理由はいくつもあります。
● PdMのロール定義が曖昧（仕様担当にされがち）
・PdMの歴史が浅い会社でよく起きる。
● 組織として顧客インタビューの文化が薄い
・営業主導企業だと、とにかく営業が顧客を抱え込みがち。
● 社内会議が多すぎて外に出られない
・PdMが“社内の渋滞ポイント”になっているケース。
● リサーチャー不在でPdMが全部やる必要がある
・でも仕組みがないから後回しになる。これ、PdM個人の怠惰というより構造の問題です。
🧩PdMの価値が最大になるポイント
顧客理解 × 課題の定義 × 意思決定の責任
この3つの重なる部分が、PdMが最も価値を出せるゾーン。
顧客理解が抜けると、一気に価値が落ちます。
🌱 とはいえ、「PdMが必ずインタビューすべき」とも限らない
少し補足しておくと、例外は存在します。
■ 顧客理解の仕組みが成熟している場合
- UXリサーチャーが常に一次情報をとってくれる
- データ分析基盤が整っていて行動が全部見える
- CS Ops が定性情報を構造化してくれる
こういう企業では、PdMは意思決定に集中できる。ただし、
👉私の経験上、国内toB SaaSでは“仕組みが成熟していてPdMが会わなくても回る”ケースはまだ多くありません。
だから、PdMが顧客に会う価値はやっぱり高い。
🔚 最後に：PdMとは「顧客理解から逃げない人」
肩書きがPdMかどうかより、
- 顧客を理解しているか
- 課題から逃げていないか
- 一次情報に触れているか
- 仮説と学習を回しているか
ここがPdMを定義します。
🧩 PdMとは何か？（一言で）
PdM ＝ 顧客理解を起点に意思決定する人
だからこそ、
- 顧客に会うデザイナーはPdM的
- 顧客に会うエンジニアはPdM的
- 顧客に会わないPdMはPdM的ではない
という状態が生まれる。
🌟 最後に PdMを目指すあなたへ
最後に一言だけ。
顧客と話すこと。それが PdM への最短ルートです。
経験年数より、肩書きより、スキルセットより、 一次情報に触れて意思決定していく行為こそが あなたをPdMにします。
以前にイベントで以下のような話をしましたので合わせて見てもらえればと思います。
この記事が、あなたの「PdMとは何か？」を考えるきっかけになれば嬉しいです。
ラクスの開発組織では『顧客志向』を大切にしています。PdMはもちろん顧客を向いて業務をしていた方はラクスはオススメです。
また、本記事を読んでラクスのプロダクト部に興味を持ってくださったデザイナー / PdM の方は、ぜひカジュアル面談からご応募ください。
※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！
●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp
デザイナー career-recruit.rakus.co.jp
└ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp
