PdMの仕事

新卒社員が入ってきたり、中途入社も活発だったりで、どこの企業でも忙しい時期になりますね。私が所属している企業でも同じような感じで、新卒中途とpdmの人数が増えてきました。
新卒はモチベーションが個々で多少違う程度で、スキルという点ではどこも似たようなものでしょう。
しかし、中途入社の場合、どう言った人材を求めているという観点で入社時点である程度力量や教育コストを把握できます。また、他部署から異動してきた方なども、そもそもpdmの役割を誤解して異動してくる場合もあります。

今回はpdmの仕事や役割について、浅い部分をご紹介していければと思います。

pdmの役割とは

もちろん、ミニCEOや企画者など色々な呼ばれ方や役割がありますが、私が考えるpdmの役割は、企業におけるビジネス価値を何が何でも作り出すことが仕事だと思っています。
かなり抽象的ではありますが、どんなものでもプロダクトと定義すれば、なんでもやるというイメージでしょうか。
それがハードウェアであれ、ソフトウェアであれ、はたまたリアル店舗とのビジネススキーム構築もpdmが関わってビジネスとして作り上げていくのだと思います。

一歩間違えると便利屋やなんでも屋さんと思われてしまいます。その違いは組織やpdm一人一人の考え方や取り組み方によって成り立ってくるのだと思います。
役割にビジネス的価値を見出せるか、作り出せるかで便利屋と思われるかどうかがきまってくるのではないでしょうか。

プロダクトをビジネスとして捉える

私の記事でも良く口にしますが、プロダクトはビジネス価値のあるものなのか。この定義を明確に打ち出して顧客体験を良くしていくことこそpdmのあるべき姿なのだと思います。
顧客体験はとても良いが、使われるほどに赤字になるプロダクトや、ビジネス価値は高いが顧客体験は最悪のものは良いプロダクトとは言えません。顧客のためになり、且つビジネスとして価値が高いものこそ、選ばれ続けるプロダクトと呼べるでしょう。

ディレクターやプロジェクトマネージャーとの違い

この二つもpdmとよく混同して考えられる職種なのではないでしょうか。私も求人をかける際に、前職での経験にこれらがあると候補には残すようにしています。
ただ、それはイコールpdmが務まるという認識ではなく、pdm経験者が驚くほど求職者リストにいないのです。どの求人媒体の担当に聞いても、pdm自体人数が多くないということと、プロダクトの核となる人材のためどの企業も手放さないようにしているようです。ということで、多少の教育コストはかかっても、pdmの役割の一部を経験しているディレクターやプロジェクトマネージャーを最終的に採用するということです。

実際にどのくらい違うのか

特にディレクターなどは企業によって役割も違うでしょうから、明確ではありませんが、圧倒的な違いはあります。
まず、一般的なディレクターは要件定義を経験している方が少ないです。その名の通りディレクターなのでディレクションがメインの仕事、企画が進んだものを進行する場合が多いでしょう。
さらに、ビジネス的な価値や顧客体験の設計などもあまり経験している方は少ないと感じます。

次にプロジェクトマネージャー（PM）は一つ一つのプロジェクトを担当していますので、プロジェクトが完成すれば、別のプロジェクトに行きます。
完成したプロジェクトをスケールするというところまではあまり担当しません。もちろん、スケールするプロジェクトを担当すれば、そこの分野もこなしていることでしょう。ただ、その場合、立ち上げは別のPMが担当していたケースが多いです。

一方でpdmは入口の企画から社内のステークホルダーへのプレゼン、開発ディレクションに検証とエンハンス、最終的にはプロダクトの撤退の打診など一連の流れを全てこなします。

慣れない人が陥る罠

以前ご紹介したビルドトラップとは違う、もっと初歩的なことです。
ちょうど二週間ほど前に、社内エンジニアの1人がセールスサポートチームから依頼があり、pdmを通さずに開発してしまったことがありました。
車内で使うCRMのちょっとした改修で、デザインなどは関係せず、自分自身とバックエンド側の開発だけすれば良いと考え、自分なりに要件をまとめ進めていると、バックエンドのエンジニアと依頼元のセールスサポートチームで仕様が違うという話になり、検証したものがエラーばかりで根本的な部分に問題があることが発覚しました。

ランチの時に問題のエンジニアの上司から声をかけられ、ある程度経緯を聞かされたので、ちょっと手伝うことにしました。うまくいかなかった原因は大きく2つです。

• 要件漏れ
• バックエンド側へ伝わっていない

まあ、内容がまとまっていなくて、さらに内容が伝わっていないとなれば、それはうまくいきませんよね。
後日時間をもらい改めて要件をまとめて、ざっくりと仕様をfigmaで図解にして、セールスサポートチームとバックエンドに伝え、問題なくリリースされました。
話しかけてきたエンジニアの上司がお礼伝えにきてくれた際に、今回のエンジニアから「あんなに簡単に要件をまとめてささっと伝えるってすごいですね」と驚いていたと聞かされ少しはやった甲斐があったかなっと思いました。

ただ、私からするとエンジニアは自分達で開発できるほどのスキルがある人たちなので、そっちの方がすごいだろうなと考えています。私たちpdmはデザインやプログラミングに深く知識を持つ必要はなく、どちらかというと広く浅く知識を持っている必要があると考えているからです。
※もちろん深い知識があればその分良いですが

これは小さな案件の例えでしたが、広く浅い知識で要件をまとめ、デザイナーや開発者にうまく伝わるように工夫をする。pdmの仕事はこの部分に肉付けをしていったものだと考えています。
要件に肉付けをしてビジネス価値や顧客体験を考え、ステークホルダーに企画を説明し、実際の開発がスムーズに行えるよう各セクションの担当者に伝えていく。
これの繰り返しがpdmなのだと考えています。

PdMのキャリアパスとスキル開発ガイド

PdMとして年収を上げる方法

PdMが避けるべき5つの落とし穴

まとめ

教育コストの話から少しずれてしまいましたが、中途入社の方などはその方の職歴に合わせて足りない部分を補う役割を担当させて教えていくしかない。ということですね。
あとは、どこまでいってもビジネスパーソンとして、高いモチベーションと自分ごととして捉える姿勢が当人たちを成長させていくのだと思います。