課題の本質を見極めることの重要性─PdM1年目の学び

はじめまして。
jinjerでプロダクトマネージャーをしているそごうです。

中途入社後、テクニカルサポート（現カスタマーサポート）として顧客対応を経験し、現在はプロダクトマネージャー（PdM）として日々邁進しています。
今回は、PdMへキャリアチェンジしてから学んだことを振り返りたいと思います。

はじめに

私のキャリアは、これまで主に顧客（toB/人事）と直に接する経験が中心でした。
もともとPdMを志して入社しましたが、まずは「顧客の声に触れ、自社プロダクトの価値や課題をより深く理解したい」と考え、サポートからキャリアをスタートしました。

ジンジャーには、人事労務、勤怠、給与など多岐にわたるプロダクトがあり、サポートチームは全領域を横断して対応します。この経験は、現在PdMとして全体最適の視点で意思決定を行う際の大きな支えになっています。

そして、顧客対応を通じて痛感したのは、お客様が本当に求めているのは特定の “機能”そのものではなく“課題解決”である ということです。
課題は複雑で多層的であるため、要望として明確に言語化されないこともあります。
だからこそ、PdMはお客様とともに課題を整理し、その奥にある本質を見極める必要があると感じています。

現状（As-Is）の正確な理解

プロダクト開発において、まず最も大切なのは現状（As-Is）を正しく理解することです。現状の認識を誤ってしまうと、どれだけ開発を進めても本質的な解決にはつながりません。

例えば、「この機能が欲しい」という表面的なご要望の背景を探ると、実際には業務フローの複雑さや既存機能の未活用、社内ルールの不統一などが根本原因になっているケースが多々あります。

表面的な要望だけで開発を終えてしまうと、便利そうな機能追加に留まり、本質的な改善には至らないこともあります。

また、私が担当するワークフローは他プロダクトと密接に連携しており、統合型人事データベースという強みを活かすには、ユーザー体験や業務全体を踏まえた設計が不可欠です。

そのため、「なぜそう感じるのか」「どんな状況で困っているのか」と背景まで掘り下げ、曖昧な点はその場でお客様と整理するよう心がけています。

あるべき姿（To-Be）の設定と「やらないこと」の決断

As-Isを踏まえ、あるべき姿（To-Be）を描くことが必要です。これは機能を羅列することではなく、ユーザーにとって理想的な体験をどう設計するかに焦点を当てます。

ユーザーの声やユースケースを深く理解しているからこそ、「これも便利になりそう」と機能を追加したくなる誘惑は少なくありません。しかし、 本当にターゲットユーザーに必要か？　 追加することで複雑化しないか？　という視点で考えると、「便利」なことと「プロダクトにとって必要」なことは必ずしも一致しません。

特に、「細かい設定をもっと柔軟にしたい」という声をそのまま取り入れれば、確かに自由度は増します。ですが、同時に操作が複雑化し、使いやすさを損ねるリスクもあります。

そこで、「複雑さを増やさずに価値を届けられるか」を判断軸とし、特に次の3つのステップで整理するよう心がけています。

複雑さを抑えるための判断軸🌟

1. 要望を基に、必要な項目を同一粒度で洗い出す

   • 現時点での要望を満たすために必要となる機能や要件を、漏れなく洗い出します。

2. ユースケースと利用導線を描き、必要な関連項目を補完する

   • 要望には明記されていなくても、実際の運用で必須となる要素（UIの導線、前後条件、例外処理など）を想像し、全体像を一覧化します。

3. 到達状態を基準に精査し、主要ユースケースへ絞り込む

   • 一覧全体を俯瞰し、「リリース後にユーザーをどんな状態に導きたいか」を最終判断軸に、優先度を決定します。すべてに対応するのではなく、主要ユースケースに絞り込み、過剰な複雑化を避けるためあえてやらないことを決断します。
     

この学びを通じて、要望をすべて取り込むのではなく、優先順位を見極め、あえて「やらないこと」を決める大切さを痛感いたしました。これは、まだ駆け出しの私がプロダクト開発に臨むうえで最も大きな学びのひとつです。

おわりに

最後まで読んでいただきありがとうございました！
他プロダクトと結びつきの強い領域では、部分最適ではなく全体を見渡す視点が不可欠です。
そして、その視点を持って課題に向き合えるのは、多様なプロダクトと関わりながら挑戦できるジンジャーという環境があるからこそ だと思います。

PdMとしての役割はまだ模索中ですが、これからも“横断的な価値”をお届けできるよう学び続け、ジンジャーをより良いサービスにしていけるよう尽力してまいります。