ブログ

ryuzeeによるブログ記事。不定期更新

PdMとして担当するプロダクトに興味が持てないときにどうするか

みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。

本記事は、先日Xに書いた記事を加筆修正したものです。


イベントや勉強会なんかでたまに「PdMとして担当するプロダクトに興味が持てないときはどうしたらいいですか?」なんて聞かれることがあります(こういうことはあらゆる職能で起こりうる話ではありますが、今回はPdMに限定します)。自分が好きな領域のプロダクトを担当できればそれに越したことはないですが、組織で働いていると「誰かがアサインを決める」みたいなこともあるので、必ずしも自分の思うとおりの仕事を担当できないこともあります。

「いや、給料としてお金をもらう以上はプロなんだから、ごちゃごちゃ言わずにやれや」と言ってしまうと話が終わりなので、ちょっと深掘りしてみたいと思います。

「興味が持てない」って具体的には?

一口に「興味が持てない」と言っても色々ありそうですよね。そのまま扱うと抽象度が高すぎるので、どんなことが考えられるか列挙します。興味のありなしは人間の内面の話なので、あくまで想像です。

  • ドメインがつまらなく見える(経費精算とか在庫管理とか、必要なのはわかるんだけど……)
  • ドメイン知識がなくて何が面白いのかわからない(知らない単語ばっかでなんとなく拒否反応……)
  • ユーザーが身近じゃなくて想像できない(自分が使うプロダクトでもないし、誰が使ってるんだろ……)
  • 天上人から降ってきた思いつきなので最初から呆れている(またなんか言い出したよ……)
  • 技術的に新しくなくて地味
  • とにかくなんとなくイケてなくてテンションが上がらない
  • ……

なんか違う、ということであれば自分で言語化してみましょう。PdMであればそういうのは得意ですよね?

何が問題なんだろう?

少なくともここではっきり切り分けたほうがいいのは「プロダクトマネジメントの問題なのか」それとも「個人の感情としての問題なのか」でしょうね。

上の例で言うと、「天上人から降ってきた思いつき」はプロダクトマネジメントの問題です。戦略が曖昧、誰のどの課題を解くのかよくわからん、市場に合わなさそう、上から脈絡なく機能開発の要求が飛んでくる……みたいな話です。これは個人の関心以前に、プロダクトマネジメントに問題がある状態で、そのままにしておくとお金も時間もバンバン溶けていくので、手を打たなければいけません。

一方で「ドメインがつまらない」とか「技術的に地味」とか「なんとなくテンションが上がらない」あたりは、個人の感情です。経費精算プロダクトのプロダクトマネジメントに問題があるわけじゃありません(多少はあるかもしれないですけど)。自分が乗り切れていないだけです。

これを最初に切り分けるのは、端的に言えば、プロダクトマネジメントの問題は向き合うべき「仕事」の問題であり、感情の問題は自分のなかの「認知」の問題なので、対処方法がぜんぜん違うからです。

プロダクトマネジメントに問題があるのに「自分の関心やモチベーションの問題」にしてしまうと、「情熱が足りないせいだ」とか「いい大人なのに好き嫌いしてるのやばいなー」と自分に問題の原因を求めて消耗します。逆に感情側の問題なのに「プロダクトマネジメントがイケてない」みたいに外側のせいにしてしまうと、プロダクトを変えようが転職しようがまた同じことを言うハメになるかもしれません。だいたい常に隣の芝生は青いしね。

なので、まずは自分の「興味のなさ」がどっち由来なのかを正しく切り分けるのが先決です (両方が同時に起きるパターンもあります。その場合もまずプロダクトマネジメント側から手をつけるのが定石です。仕事の問題は周囲を巻き込んで動かせるけど、感情の問題は自分の中でしか処理できないので、外に向けて動けるほうから片付けたほうが対処しやすいです)

プロダクトマネジメントの問題なら、PdMの仕事として正面から取り組む

「戦略が曖昧」「ターゲットユーザーが定義されてない」「上から脈絡なくモノが降ってくる」みたいなのは、PdMが正面から取り組むべき問題そのものです。こういう問題を解決するためにPdMが存在します。「ぐちゃぐちゃな状況なので関心を持てない」ではなくて、「ここが自分の出番」と考えて、打てる手をバンバン打ちましょう。ステークホルダーを特定したり、責任範囲や期待値を明らかにしたり、成功や失敗を定義したり、ディスカバリーをやり直したり、上から降ってくる何かをゴミ箱に捨てたり握りつぶしたり、みたいなことをしていけばいいだけです。PdMであれば、これを他人に期待しないほうがいいですねー。自分でやりましょう。

感情側の問題ならあれこれ試すしかない

感情の問題だとすると、色々試してみるしかないです。ここではいくつか試すとよさそうなことを紹介しておきます。

ドメインを勉強する

「興味が持てない」の正体が、実は「ドメイン知識がなくて何が面白いのかわからない」だけということもあります。人間、知らないものに対しては反射的に拒否反応を示しがちです。聞いたことがないドメインの用語とかアルファベット3文字くらいの略語(外資系の入社直後はまじで辛かった)とか、法律とか慣習とかに毎日接するハメになると、何がわからないのかもわからなくて頭パンパンだし、そりゃネガティブにもなります。

これは放っておいても改善しないので、とりあえず試しにしばらく勉強してみましょう(勉強したくねーんだよ、というのはわかります)。 本を読んだり、自社や競合のプロダクトをいじり倒したり、詳しい人に聞いたり、なんならプロダクトを使って行う業務をしばらく自分がやったり、やれそうなことは色々あります。しばらくするとなんとなくわかってきて、少しは関心を持てるかもしれません。

ユーザーや顧客の話を聞いたり実際に使っているところを観察したりする

勉強の話と同じかもしれないですが、ユーザーや顧客の話を聞いてみるのもいいかも。 自分が使わないプロダクトって、それだけで関心を持ちにくいです。どう使っているのかを想像できないとなおさらです。 なので話を聞いたり、実際に使っているところを観察したりしましょう。 1人や2人じゃなくて5人とか10人とかそれなりの数が必要です。業務内容とか困りごととかプロダクトがどう役に立っているかとかがわかれば、少しはマシかもしれません。

プロダクト以外で情熱を持てる箇所を見つける

PdMの仕事は細かいドメイン知識に関するところだけでもないです。プロダクトチームの運営とか、戦略の検討とか、データを集めて意思決定するとか、ステークホルダーマネジメントをするとか、色々あります。プロダクトのドメインそのものにはあまり関心が持てなくても、他の箇所にエネルギーを突っ込めるならなんとかなるかもしれませんね。

仕事自体をゲーム化する

プロダクトのドメインに興味はなくても、「チャーンレートを10%減らすゲーム」「サインアップの成功率を20%増やすゲーム」みたいにして乗り越える手もあるかも。ぼく自身、昔性能が低くて困っているプロダクトを支援したことがあったんですが、そのときは「性能改善タイムアタック」とか「めざせ実行時間百分の一」みたいな感じでゲーム化していました。

それでもダメなら

上の対処でダメなら選択肢は2つ。

仕事として割り切る

冒頭で書いた「ごちゃごちゃ言わずにやれや」ですが、最終的にはこれが正解になることもあります。お金をもらって仕事している以上はプロなので、もらった分の仕事はしなければいけません。関心や情熱がなくても、淡々と価値を出すのがプロとも言えます。この方向に振り切るなら、PdMとしての責任範囲と求められる成果をハッキリさせておくのがよいと思います。ただねぇ、やっぱり四六時中プロダクトのことを考えている人との戦いになったら分が悪いのは確かです。

担当プロダクトを変えてもらうとか転職する

社内に複数のプロダクトがあるなら、マネージャーに異動を相談する手もあります。まともなマネージャーであれば、成果の最大化とメンバーのキャリアや満足度に関心があるはずなので、相談してみる価値はあります。

それでもダメなら転職もありです。関心がないことをダラダラ続けても、自分にとってもプロダクトにとってもユーザーにとっても、得がありません。PdMは結構裁量と影響力がある仕事なので、プロダクトに無関心なまま続けると、プロダクトがダメになる可能性もあります。 お互いのために、合うところに行くことは逃げではないのではないかと思います。

ということで、頑張りすぎないように頑張ってください。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 Agile is dead なわけがない

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World