この記事はウィルゲート Advent Calendar 2025 16日目の記事です。
こんにちは、開発室の吉田です。
エンジニアとPdMの兼任を初めて2年になりました。現在はアポトルのPdM兼エンジニアとして、プロダクト開発に携わっています。 以前、エンジニアとして開発業務をしていた頃は、プロダクトディスカバリは「すでに終わっているもの」でした。
プロダクトディスカバリとは、「誰の、どのような課題を解決するプロダクトを作るべきか」を探求、検証するプロセスを指します。
仕様から要件を考える中で、課題をちゃんと考えていたつもりになっていましたが、実際には誰かが課題を定義し、課題がある状態からどういった解決方法があるかを考え、仕様への落とし込み、実装する、という流れの中で仕事をしていました。
PdMになってからも、しばらくはその感覚のままでした。
「次はこの機能を作りましょう」と自然に提案し、「どういった課題が解決するの？」と聞かれて言葉に詰まる。
そのとき初めて、自分は課題を理解しないまま How から考えてしまっていたのだと気づきました。
この記事では、PdMになってからの2年間で、プロダクトディスカバリの“見え方”がどう変わったのかを、実体験ベースで振り返ります。
1. 課題が見えていないまま「How」から入ってしまった、PdM最初の失敗
PdMの兼任になって間もない頃は、エンジニア視点のままでプロダクトディスカバリに取り組んでいました。
次に作るべき機能の提案も、エンジニア時代の感覚のまま行っており、結果として、課題をちゃんと理解しないまま、How（どう作るか）から入って機能提案をしていました。
あるとき、「それは何の課題を解いているんですか？」と聞かれました。
ユーザーからの声はいくつも思い浮かぶし、実現したいことの説明はできました。
しかし、「それが本当の課題なのか」「誰にとっての課題なのか」を、自分の言葉で説明することができませんでした。
ユーザーから直接聞いた要望をそのまま鵜呑みにし、「要望＝課題」だと捉えてしまっていたことに、初めて気づき、課題をちゃんと理解しないまま、How から入ってしまっていたのだと認識しました。
本来プロダクトディスカバリとは、「何を作るかを決めるプロセス」ではなく、「何が課題なのかを見極めるプロセス」だったにもかかわらず、そこをちゃんと理解せずに何を作るかだけにフォーカスして考えていました。
エンジニア時代は、与えられたものに対して「どう解決するか」を考えるのが役割でしたが、 PdMとしての役割は、「本当の課題は何なのか」から考える必要がある立場に変わったのだと、強く意識するようになりました。
2. エンジニア時代、プロダクトディスカバリは“すでに終わっているもの”だった
エンジニアとして開発に携わっていた頃、プロダクトの課題は「すでに定義されているもの」でした。
ユーザーの本当の課題を考えるというよりも、渡された課題に対してどのように解決するかを深掘りしていく。そうした関わり方が当たり前でした。
仕様を検討する際も、課題設定そのものを疑うことは、ほとんどありませんでした。
そのため、「この機能は本当に必要なのか」「この課題は本当に存在しているのか」といった問いを立てることは、日常の仕事の範囲外にありました。
そもそも“プロダクトディスカバリがある”という認識自体を持てていない状態で、開発に取り組んでいたのだと思います。
この認識のままPdMとしての役割を担ったことで、思考の切り替えがうまくできず、本当の課題を見極めることができていませんでした。
課題はすでにあるものだと捉え、その課題に対して「どう解決するか」から考えてしまった結果、Howから入ってしまい、失敗につながっていました。
課題が「与えられるもの」だと捉えている限り、「何を作るべきか」を自分自身で問い直すことはできていなかったのです。
3. PdMになって気づいた、ディスカバリの本当のスタート地点
PdMとしてプロダクトディスカバリに向き合うようになって気づいたのは、 課題は「与えられるもの」ではなく、「探しにいくもの」だということでした。
ユーザーから出てくる要望の多くは、「困っていることの表現」そのものではなく、 ユーザー自身が考えた「解決策」であることがほとんどです。
「ここが使いにくいから、こうなっていれば良い」といった形で要望が語られることも少なくありません。
これを課題としてそのまま受け取り、機能に落とし込もうとすると、ユーザーの本当の困りごとを見逃してしまう可能性があります。
本来PdMとして向き合うべきなのは、
「なぜその要望が出てきたのか」
「どんな業務の流れの中で、どんな不便が生まれているのか」
「それは本当にプロダクトで解くべき問題なのか」
といった、要望のさらに奥にある背景でした。
PdMとしてのスタート地点は、解決策を考えることではありません。
ユーザーの言葉をそのまま信じるのではなく、その裏にある構造や前提を疑い、本当の課題を探しにいくことから始まるのだと、このとき認識しました。
この視点を持つようになってから、
「何を作るか」を考える前に、「何が起きているのか」「何が本当の課題なのか」を掘り下げる時間の重要性を、強く意識するようになりました。
4. これからは、答えを探す前に「課題」に向き合っていく
PdMとして業務をしていく中で、プロダクトディスカバリに対する向き合い方は、大きく変わりました。
以前は、「正しい解決策を出すこと」が仕事だと思っていました。
今は、その前に「何が本当の課題なのか」に向き合い続けることの方が、はるかに重要だと感じています。
課題は最初から明確な形で存在しているわけではなく、ユーザーの言葉の中に紛れていたり、業務の違和感として表出していたり、ときには言葉にもなっていないこともあります。 だからこそ、プロダクトディスカバリは「正解を見つける」ではなく、「問い続けながら、少しずつ課題の輪郭をはっきりさせていく」なのだと思うようになりました。
これからは、機能や解決策から入るのではなく、まずはユーザーが抱えている本質的な課題に向き合い続けることを大切にしていきたいと考えています。
課題が見えたときに、プロダクトとして必要な解決策を選び取っていく。
そんな向き合い方を、これからも続けていきたいと思います。
※この記事では、プロダクトディスカバリに対する考え方の変化について整理しました。
顧客からのフィードバックをどのように課題として整理し、Notion上で管理しながら、開発やCSと認識を揃え、優先順位や仕様に落としているのかといった「実務の部分」については別の記事で紹介しようと思います。
ウィルゲート Advent Calendar 2025 、翌日は武田さんの「PHPで複雑な配列を使うのをやめよう！」です！
