プロダクトマネージャーへの道

この連載では、1回目から4回目まではSaaSビジネス全般について解説してきました。5回目と6回目は、最近特にSaaS業界で注目を集めているプロダクトマネージャー（以下、PdM）の仕事について解説します。6回目となる今回のテーマは、PdMになるためのキャリアや求められるスキルと経験です。

プロダクトマネージャーへのキャリアパス

PdMにはエンジニア経験者が就く職種というイメージがあるかもしれません。確かに日本ではエンジニアからPdMになる人がほとんどです。しかし海外に目を向けてみると、営業やマーケティングなど、ビジネス系の職種からPdMになる人が一定の割合を占める傾向があります。

筆者の経験から、その理由の一つにエンジニアとのコミュニケーションがあるからだと感じています。日本では、エンジニアと議論するにはエンジニアリングの知識があった方が話が進みやすいです。しかし反対に、海外では責任範囲がはっきり分かれているので、エンジニアリングの詳細な部分の議論はPdMに要求されません。

そのため、本来はビジネスサイドからもエンジニアサイドからも、PdMになるキャリアパスは用意されていると筆者は考えています。筆者の感覚としては、マーケティングや営業の経験があった方が顧客のメリットを考えやすいので、ビジネスサイドからのキャリアの方がマッチするように思いますが、現実的には採用する側も応募する側もエンジニアの経験を重視しているように感じます。

• 

プロダクトマネージャーのジョブディスクリプション

筆者がSaaS企業のPdMのジョブディスクリプション（職務記述書）を書くとしたら、次のような職責を記載します。前回紹介した「プロダクトマネージャーの役割」とも通じるものがあると思います。

・市場と顧客の真のニーズを情報を元に仮説を設定し、検証してプロダクトの訴求すべき魅力や方向性を決定し、開発を推進すること
・時流や市場の変化を押さえて、必要に応じて自らの計画を修正できること
・エンジニアと共にプロダクト（または機能単位）の訴求すべき魅力と目的をきちんと言語化して説明し、プロダクトを実体化してローンチする
・ステークホルダーとコミュニケーションして自らが描く価値を伝えられる

自身が持つスキルについては、提供しているSaaSプロダクトによって異なってくるでしょう。当社チームスピリットに限れば、プラットフォームであるSalesforceの知識や、海外の開発チームとコミュニケーションが取れるレベルの英語力、顧客とのコミュニケーションから真のニーズを探り出して言語化する能力、さらにはデータベースの基本的な知識が求められます。

PdMの重要な素質の一つは、「プロダクトの価値が誰にどんなメリットをもたらすかを第一に考えられること」です。反対に、「最先端の技術を使いたい」「使われるかどうかは不明だがこんな機能を作りたい」というような、誰がどう喜ぶかがわからないまま方針を立ててしまうようでは、たとえ売れたとしても、それは再現可能なものではないですし、偶然の産物に過ぎないため、楽しさも半減してしまうでしょう。

エンジニア系プロダクトマネージャーがつまづきやすいポイント

もう一つPdMに求められる素質は、自分の考えを多角的な視点から評価できることです。筆者は、思いついた考えがあると頭の中の複数の自分に「難癖」を付けさせるようにしています。

例えば、ある機能を実装したいと思った時に、エンジニアの自分が「システム上の制約があるから難しいのでは？」と問いかけます。そこで難しいからやめようとなってしまっては、最初に描いたメリットが実現できなくなってしまいます。顧客の自分が「この機能があれば効率化できる」と訴えてくるなら、別視点のエンジニアの自分が「挑戦にはなるが、こうすれば実現できる」と伝えてきます。自分の思い込みに対して、客観的に肯定または批判してみるのです。

その議論を通して出てきた方針をエンジニアに伝えて実装します。この時、結論だけ伝えてしまうと、自分の中ですでに解決した難癖を付けられてしまうことがあるので、なぜその結論に至ったか、どうすれば実現できるのかを丁寧に伝えていく必要があります。筆者もこの部分を省略してしまいがちなので、気を付けています。

エンジニアの中には、相手に要件を伝えて動いてもらうことが苦手で、自分で開発してしまった方が早いと考える人もいます。それこそが、エンジニア経験を持つPdMがつまづきがちなポイントだと思います。

筆者も初めてPdMの役割を担ったとき、自分で開発をしたいという気持ちがありました。しかし、一人で開発するよりもチームみんなで同じ方向を見て開発を進める方がより大きな成果が得られると気付き、意識が変わりました。チームの成果として顧客により多くのメリットを提供できる方が、価値があると思えるようになりました。

いろいろな人の意見や知識を積み重ねて成果を大きくしたいのか、それとも開発を極めたいのか、そこがキャリアの分かれ道だと思います。技術の知見が深くて、開発スピードが早く、バグの無いプログラムを構築することに喜びと価値を感じる人は、エンジニアリングのスペシャリストを目指せば良いでしょう。一方で、技術は手段の一つであり、それを活用して顧客のメリットや提供できる価値を最大化することを目指していきたいという人は、PdMに向いているのではないでしょうか。

プロダクトマネージャーを目指すには

これからPdMを目指す場合はどのようなプロセスがあるでしょうか。

会社によって異なりますが、当社の場合は、現状の業務に支障を来さない範囲で顧客メリットが出せる機能を設計し、提案することが挙げられます。その提案に実行する価値があると経営が判断すれば実現できます。

筆者の経験ですが、私はTeamSpiritの新プロダクトが提供すべき魅力と解決する顧客の課題、プロダクトの現在地を定義した上で、プロダクトを強化する方向性を提案しました。入社して3カ月目のことです。当時は転職したばかりの時期でしたが、提案が会社に受け入れられ、そのプロジェクトを任されることになりました。

こうした経験から、現在PdMをやってみたいと考えている人には、どんなメリットを提供できるかという観点から自分なりにアイデアを考えて設計まで落とし込んでから、PdMや開発責任者に提案してみることをおすすめします。それが一番の近道となるはずです。

しかし、この方法には強い意志が必要です。そこで次点となる近道が、PdMを目指したいという旨を周囲に発信していくことです。上司との面談などで相談すれば、PdMにたどり着くまでに経験しておくべきことや身につけるスキルなどを整理し、キャリアパスを示してくれるかもしれません。周りの人の助けを得ながら目指すというのも実践的なアプローチです。

自分がやりたい事を明確に発言するのは少しはばかられるように感じる方もいるかもしれませんが、逆に私は部下に言ってもらった方がマネジメントがしやすいと考えています。なぜなら、部下の目指す方向性が分かっていれば、お願いする仕事の方向性などでWin-Winの関係を築きやすいからです。

また、上司部下の関係であれば、部下の成長の手助けをするのは善意ではなくて、上司の「仕事」であるはずです。したがって、さまざまな事情はあれど、まず意思表示することは重要だと思っています。

なお、PdMがプロダクトの方向性を示すとき、その根拠となるのが顧客のニーズです。顧客のニーズというのは顧客の声を聞くことから始まると思われるかもしれませんが（当然これが重要なのは言うまでもないですが）、筆者はまず、ある程度の概要を調査し把握した上で、自らの仮説を立てる事こそが重要だと考えます。その上で、その仮説を検証してブラッシュアップ（時には方向転換も）するために、「顧客の声を最大限活用する」というプロセスが重要だと考えています。

理想だけでいうならば、PdMは顧客のニーズを超える魅力や利便性を構築できなければならないのです。エンジニアであれば、このプロセスを疑似的に体験できます。今ある課題に対してどう対応するかを自分で考え、PdMの方針と比較してみるのです。筆者は顧客からのフィードバックを見て、「自分ならこういう方向で提案するな」と考え、担当者の対応を見て仮説の検証をしていました。すなわち、顧客の声を仮想問題集として、仮説検証の場数を踏んでいたのです。

さて、今回はPdMになるための方法について紹介しました。開発専門でキャリアを描いている人でも、顧客のメリットという観点からプロダクトの改善や機能追加を考えているならば、PdMのキャリアの可能性があると思います。自分の力だけでなくチーム全体の方向性を合わせて、大きな価値を市場に出していきたいと考えるのであれば、ぜひチャレンジしてみてほしいです。

次回はPdMが抱える課題と、PdMとして成長していくための考え方について取り上げます。