いちPMの振り返りから考えるソフトウェアエンジニアからプロダクトマネージャーの目指し方 PM転向編
こんにちはfurufuru（@rilmayer_jp）です。
このシリーズ記事では現在ソフトウェアエンジニアをやっている、もしくはソフトウェアエンジニアをしていた方が、もしプロダクトマネージャーを目指したいとなった時にどのようなスキルやマインドを身につけると良いかというのをお話しします。
最近、ソフトウェアエンジニアの方から「プロダクトマネージャーに興味がある」、「プロダクトマネージャーを目指したい」といった相談を受けることが増えてきました。そこで、そうした方に向けて私の体験を共有することで以下のようなことを考えるためのヒントになればいいなと思っています。
どうやったらPMになれるの？（どうやってなったの？）
どのような勉強やトレーニングをしたの？
苦労したことや良かったことは？
向いてる人、向いてない人
書いてる中で長くなりそうだったのでいくつかの記事に分割して投稿することにしました。初回は「プロダクトマネージャーに転向する」がテーマです。前半は私の体験で、後半はそれを元にどのようにPMに転向するのが良いかの考察について紹介しています。
著者のプロフィール
大学院卒業後、図書館情報学をバックグランドとして情報検索や情報推薦のプロダクト開発に従事。2019年より現在の会社（Eコマース系）にソフトウェアエンジニアとして入社し、検索評価やレコメンドシステムのプロトタイプ開発に取り組む。現在はプロダクトマネージャーとしてディスカバリー体験全体を改善するような開発の推進をしている。
注意
この記事では特に私が経験していたEコマース、その中でも特に検索・推薦領域での経験をメインでお話します。ですので、特定業種の特定領域に限定される話であるということは注意して読んでいただけると良いかと思います。
また、この記事では私の経験に沿ってエンジニアからプロダクトマネージャーになっていく話をお話しします。ですので、上記の質問の答えだけを知りたいという方にはやや冗長な内容となってしまうかもしれないのでご注意ください。
最後に私自身は「エンジニアはPMを目指すべき」等の意見を持っていないことを明記させてください。PM職には向き不向きがありますから、全てのエンジニアがPMを楽しくやっていけるとは思っていません。
ですが、同時に現在エンジニアでPMを始めたいという方は全力で応援したいと思っています。この記事はそういった方の参考になると良いなと思い書いてみました。
私の体験：PMを始めたきっかけ
当時の状況・直接のきっかけ
私のPMキャリアのスタートは社内の尊敬するPMから「PMをやってみないか？」と誘われたことです。
ただ、誘われた当時は結構大変な状況でした。
当時はソフトウェアエンジニアとしての肩書はあるものの、スクラムマスターを兼務しており、さらに一部PMの仕事を肩代わりしていたような状況でした。というのも、元々チームのPMをやっていた方が他のプロジェクトに参加する形になっていき、PMが不在っぽくなるシーンが増えてきてしまったからです。（今となっては、私が一部肩代わりできるから当時のPMが別プロジェクトにフォーカスしていったのか、当時のPMが別プロジェクトにフォーカスするから私が一部肩代わりしたのかは明確な因果はなかったと思います。両者のバランスが徐々に変化していったと記憶しています。）
スクラムで御法度とされる2つの役割兼任だけでなく、POまで兼任ということで3役兼任という形になってしまいました。業務もけっこう滞ってしまい周りにも迷惑をかけているという結構しんどい状況だった記憶があります。このような状況ですから、どこかに自分のフォーカスを定めないと中途半端になってしまうぞ…という状況でのPM転向の意思決定でした。
そんな状況を見かねてか、PMの人材不足からか、冒頭のシーンである社内のPMから「PMに転向しないか？」と誘われたのが、PMを正式に始めたきっかけです。
ソフトウェアエンジニアへの未練
とはいえ、私自身まだまだソフトウェアエンジニアやっていたい気持ちもありましたし、スキル的にもまだまだ発展途上という自負がありました。
そのような状況でPMになってしまうのはどうなんだろう・・・という気持ちも強かったのですが、最終的には「まあ、エンジニアしたくなったらまたエンジニアすれば良いか。」という気持ちでPMに転向することにしました。
昨今のキャリアは一方通行ではありません。
PMが向いてないと思ったり、周りから思われたらエンジニアに戻ればいいです。気持ち的にまたやりたくなったらエンジニアをすれば良いのです。
実際にPMになってからエンジニアになる人を何人も見てきましたし、可能そうに見えました。また、最悪今の会社でエンジニアに戻ることが難しくても、自社に限る必要がなければ仕事はあるだろうと思っています。
ということで、いつかエンジニアに戻ることができるように、できるだけ腕が錆びないように個人開発だけは続けるようにしていたりします。
転向するための準備
転向するにあたり、以下のような（主に事務的な）準備も行いました。
スキルやマインドセットの準備はまた次の記事などで紹介できればと思います。
エンジニアとしての仕事をきちんとやめる
エンジニア組織からPM組織への移動
PMとしての期待値調整
まずはどのような比率でPMとしての仕事に時間をかけるかを決めました。
私の場合はできればすぐにPMとして使える時間を100%にしたかったので、まずはエンジニアリングタスクの引き継ぎを行いました。
人によっては「エンジニアとしての仕事をやめる」というのが難しいかもしれません。実際に自分自身がコーディングを始めとるするエンジニアリングタスクを行わないように周りと調整していくのは大変でした。過去に自分が作ったけれどうまく引き継げていないものを他のエンジニアに引き継いだり、運用体制（オンコールなど）から抜けることなどが必要です。
現在の仕事の引き継ぎ以外にも、会社によってはPM転向をするために、面接が必要な場合があるかもしれません。私の場合は職種の転向にあたってPM組織のトップ（CPO）や人事と面談等を行い、実際の組織移動を行いました。
また、PMとして配属される先のマネージャーとも丁寧に面談をしました。事前に自身の期待値を明文化した上で、ずれがなさそうか他に期待したいことはあるかなどを確認していきました。
考察：どのようにPMに転向するか
さて、ここからは私の経験を踏まえた上で、どのようにソフトウェアエンジニアからPMとしての最初の一歩を踏み出すのと良いかを考えていきたいと思います。
転職か社内移動かでいうと社内移動
全くのPM未経験な場合、他社のPM職として採用されるのは難しいと思ってます。最近はPM採用の面接も行っていますが、社内移動と他社からの採用ではPMに求められるレベルが全く違います。
当時の自分のレベル感だと、まず間違いなく自社のPMとしては採用されないと思っています。おそらく多くの会社の面接で「PMとしての経験」を話すことを求められ、そこで話す内容が全くない、もしくは不足している状態ではなかなか採用まで辿り着けないのではないかと思っています。
そこでおすすめしたいのが、社内移動でPMを目指す方法です。
まずはEMやPMと相談
将来的にPM職に興味があれば、早い段階で自身のエンジニアリングマネージャー（EM）や近い領域のPMと相談するのが良いと思います。EMとしてはキャリアを検討する上でPMに向けた成長に寄与する仕事を優先的に振ってくれるかもしれませんし、PMはおそらくオープンに相談に乗ってくれると思います。（なぜならPMはどこも人材不足で、できれば人手が欲しいから）
実際に私が相談を受ける経緯としてもEM経由であることがそこそこあります。ですので、まずは以下のようなコミュニケーションをとってみましょう。
PMとの相談では以下のような話を聞いてみましょう。
どうすれば・どのような経験を積めばPMになれるか
どのようにPMになったか
自社のPMとしての基準
などなど
徐々にPMの仕事を奪う
上記のコミュニケーションなど通して、自分のチームのPMとコミュニケーションをとっているのであれば、徐々にPMの仕事をまわしてもらったり一部やってみましょう。
例えば以下のようなところから始めるのも良いかもしれません。
もう少し上段の仕様決め
顧客ニーズの分析や仮説の洗い出し
チームが担っているプロダクトの一部の計画を立てる
成果をまとめたドキュメントの作成
などなど
注意：この活動ではPMの雑用になってはいけません。どのようなタスクに取り組む場合でも「どのようなことを学ぶか」、「（次に示す）どのような実績を示せることになるか」などをきちんと考えておきましょう。
仕事の中で実績を積む
PMとして入門するにあたって非常に重要かつ本質的なスキルだと私が考えるのは「投資対効果を最大化する（ROI最大化）」スキルだと思っています。（ちなみに、PMを実際に始める時には「ビジョンを作り、ステークホルダーの共通言語とする」スキルが重要かなと思ってます。）
そして、基本的にはこのROI最大化のために何ができて、どういう実績があるかを揃えていくことでPM職に転向しやすくなるかなと思います。
具体的には、エンジニアであれば何を作るかというのがそのまま投資となります。なぜなら作るべきものを考えることは、エンジニアの人件費を使って何をするかという投資判断になるからです。そして会社によって異なりますが、その機能による売り上げの増加などが成果として考えることができます。（ちなみに、「成果の定義」自体もPMの重要な仕事だったりします。）
つまりROI最大化の観点に立って、以下の3点を積み重ねることで実績及び自身のスキルを示すことにつながるかと思います。
何を作ることをどのように意思決定（もしくはサポート）したか
その意思決定を実施するために何をしたか
その結果として、どのような成果を得られたか
機会を待つ
上記のような活動は、（ややしんどいですが）エンジニアをしながらでも続けられると思います。ある程度の実績がたまってくれば、基本的にPMとして迎え入れられやすい状況になります。
実績の積み上げと並行して「PMに興味がある」という声を上げ続けていれば、現在のチームのPMが辞めるとか移動するとかのタイミングであなたに声が掛かるはずです。または他のポストのPMにあなたが就任することになるかもしれません。
それでもダメなら機会を作る
ある程度待ってても機会がない場合は、「社内の新規プロジェクト立ち上げ」、「転職」などの手段を使うことができます。
社内プロジェクトの立ち上げでは、それぞれの会社のフローに沿って役員から承認を得ましょう。うまくいけば新しいチームのPMとして仕事を始められると思います。過去の話ですが、私の経験として「新しいチームが立ち上がるから」という理由でPMをやったことがあります。
エンジニアリングができてROI最大化について意識しているエンジニアであれば、PM候補としてエンジニアで転職するのもPMへの近道だと思います。さらに、ここまで積み上げてきた実績があれば、ジュニアPMとして転職できる可能性も高まっていると思います。
おわりに - PMをやりたいからという理由でPMになるのはありか
最初に私の意見を言っておくと、「解きたい課題があり、その手段としてPMという職種が最適だった」というモチベーションが、PMを始めるきっかけとしてはスムーズかと思っています。
なぜなら、PMと呼ばれている職業の定義が会社によってバラバラなため、実はその実態を特定することが難しいからです。さらに、（エンジニアやっていた時と比べると）やることが多岐に渡り、コミュニケーションも多く取らなくてはならないため、うまくワークするためには何かしらの強いモチベーションが必要だと考えるからです。「やりたいことがある」というのは、結構良いモチベーションだと思っています。
ですが、一方でPMをやりたいからPMになるのだというのも全然ありだと思います。人手不足のこの世の中で、プレイヤーが増えるのは助かるので、どんなモチベーションでも大歓迎です。（このような記事でお手伝いしたいと思います！）
次の記事はPMを初めて最初の1ヶ月間をどう過ごすかの振り返りと学びのガイドなどをできればと思います。