【小城久美子】エンジニアからプロダクトマネージャーへの転向で「ポンコツ」に。成果を出せるようになるまでの試行錯誤と学びとは

前回は「人生もプロダクト。「トンカツ」で考えた小城久美子流キャリアの創り方」と題して、いろいろな職種を経験する良さについてお話しました。とはいえ、別の職種に転向するのはゼロからのスタートになるので不安が大きいものです。

今回の記事では、

• ・職種の転向を検討したとき
• ・職種を転向してすぐ
• ・次の転向を考えはじめたとき

の3つのフェーズに分けて、私がやってきた試行錯誤と、振り返ってそれをどう思うのかを紹介しようと思います。

• keyboard_arrow_down 職種の転向を検討したときの試行錯誤
• keyboard_arrow_down どれくらい勉強してから転向すればいいんだろう
• keyboard_arrow_down 職種の転向を検討してすぐの試行錯誤
• keyboard_arrow_down こんなに頑張っているのに、仕事で成果が出せない！
• keyboard_arrow_down 「いつも同じことばかりしている」と思ったら、次の転向を考えるとき

私はエンジニアからプロダクトマネージャーに転向しました。その時の私にとっては「コードを書くのをやめる」というのはとても大きな決断で、時間をかけて迷いました。

さまざまな職種を経験すると、専門職一筋の人には敵わないのでは？

転向前に一番大きかった不安は、その道一筋でやっている方には勝てないのではないかという不安です。1つの領域に真摯に向き合って専門性を深堀りしている人には敵わずに、中途半端なスキルしか身につかないのではないか。今までのキャリアを白紙に戻し、ゼロベースのスタートを切ることが正解なのだろうか、と悩んでいました。

今の私は、キャリアを白紙に戻したわけではなく、専門性の切り口を変えただけだと捉えています。つまり、ソフトウェアエンジニアという切り口で専門性を伸ばすのか、それともプロダクトを成長させる人という切り口にするのかの違いです。ソフトウェアエンジニアとしてキャリアを構築するなら、コードを書き続けて専門分野を深めるのが良いでしょう。でも、私はプロダクトを成長させる人としての専門性を身につけることにしました。エンジニアもプロダクトマネージャーも、これまで経験してきたその他の名前の付いた役割も、私がプロダクトをうまくつくるための引き出しとなっていると感じています。

また、スキルは勝ち負けや、上下があるものではありません。誰かに敵うかどうかではなく、自分が自分のキャリアに納得できるかのほうが重要ではないでしょうか。そもそも、次々と新しい技術が生まれる中で、一人で全部のスキルを身につけるのは不可能です。プロジェクトメンバーそれぞれが、さまざまな切り口の専門性を身に着けているからこそ、お互いの専門性を活かし合ってプロダクトの成長を加速させられます。誰かが名前をつけた職種のものさしで評価されなくても、自分の中で専門性の軸を持ってプロダクトの成長に貢献することのほうが本質的です。

一方で、さまざまな職種を経験する前に、ここまで開き直って思考できていたわけではありません。私の場合は複数の職種を経験したことで多面的なスキルが身について、結果としてタイミングよく生まれたプロダクトマネージャーという役割と合致しました。しかし、プロダクトマネジメントが市民権を得たのは「自分がやっていることはプロダクトマネージャーだった！」と感じた人が多かったからではないでしょうか。自分の職種の役割はここからここまでと定義するのではなく、自分の仕事は何を達成するものという定義の仕方をして働くことで、新しい役割が生まれたときにもスムーズにキャッチアップできるはずです。

エンジニアを辞めるという大きな決断をする前に、まずはこれからする職種がどういうものなのか理解を深めるために勉強をしました。自分なりに手の届く範囲の本や記事を読み漁ったり、既に仕事をしている人の話を聞いたりしたことは役に立ったと思います。しかし、今改めて振り返ると、事前にした勉強では必要な知識はほとんど学べていませんでした。同じ本を読むにしても、経験していない状態では腹落ちせず、身にならなかったように感じます。仕事を始めてから勉強をした方がずっと効率が良かったです。

時々、プロダクトマネージャーを目指しているという方が、知識の学習で即戦力レベルになってから職務に就くことを理想とされているのを見かけます。ですが、座学の勉強だけで仕事で活用できるスキルを身につけることはできません。仕事をする上で、会話ができる程度に事前に知識を詰め込んでおくことは必要でありつつ、早く打席に立つことをお勧めします。

また、勉強の仕方も職種によって異なると感じます。

エンジニアだった頃は1冊ずつ本に書かれた内容を実践していました。本を読むだけでは血肉にならず、本の内容に沿って手を動かすことが大事だと感じました。

プロダクトマネージャーになって気づいたことは、1冊だけ読んでも学びが深まらないという事実です。例えばKPI設計を学ぶとしてもその手法論はたくさんあり、その時々の状況に応じて最適解は異なります。そのため、なにか学びたい分野があれば同時に複数のKPI設計の知識を集めて、その差について理解をし、今の環境で最もよい方法を選ばなければいけません。

エンジニアの頃は、すぐに環境を作って手を動かしてみることができましたが、何度もKPIを設計し運用できる機会が回ってくるわけではないので、手を動かしづらいという違いもあります。ケーススタディでは理解したつもりでも、現場で設計できるかというとまた違ってきます。また、KPIだけ設計できても、KPIをどう機能開発に落とし込むのかという次の課題があるので、その著者が書いた別の本やブログを確認して全体像を掴みにいくことも必要になります。

そして、残念ながら、プロダクトマネージャー職においては一通りの手法論を学んだからといって、それを現場で実施すればうまくいくわけではありません。どこかの本に書かれているとおりにやるのではなく、環境に応じて別の手法論を提案したり、実践をしながらよりよい方法を検討することのほうがずっと重要です。即戦力になれるレベルまで勉強するのは諦めて、自分がプロダクトマネージャー職を楽しめるか判断できるレベルまで勉強するくらいで良いかと思います。

「コードを書くのをやめる」という意思決定をして職種を変えたあと、それで悩みが終わるわけではなく、その後も考えることは続きました。

向いていなかったらどうしよう、という不安

「プロダクトマネージャー職が向いていなければ、エンジニアに戻れば良い」と考えてはいたものの、日々勉強をしなければついていくのも大変なエンジニア業です。だからこそ、一度やめてしまえばもう戻れないのではないかと不安でした。

その不安から、私はエンジニアを辞めたあともいつでもエンジニアに戻れるように、休日はコードを書いたり新しい技術書を読んだりしていました。しかしながら、プロダクトマネージャー職は総合格闘技であり、幅広いスキルが求められます。それゆえに、キャッチアップしなければならないことが多くあり、学ばなければいけない知識は他にもありました。

二兎追う者は一兎も得ずと言いますが、新しい職種にチャレンジするときは腹をくくって新しい職種のキャッチアップに専念すればよかったと感じています。「向いていなかったらどうしよう」ではなく、「成果を出すためには何をすればよいか？」を考えるほうがずっと良かったです。

職種を転向してすぐ、私は本当にポンコツでした。そして最悪なことに、役に立てない焦燥感から、自分が役に立てる得意分野で居場所をつくろうとしてしまいました。エンジニアのバックグラウンドがあるからといって、エンジニアとプロダクトマネージャーの境界線に落ちている仕事を巻き取って成果を出したつもりになりました。プロダクトマネージャーとして本来に向き合う仕事から目をそむけて、ただ仕事をたくさんつくって一人で忙しくなっていました。

私はたくさん働きましたが、成果には繋がりませんでした。よく頑張っていると褒めてくれた人もいましたが、一人で忙しくなっていることを白い目で見ていた人もいたはずです。この経験から私は、がむしゃらに仕事をしてはいけないこと、いまやるべき仕事はなにか優先順位をつけることを学びました。

そして、思いついたタスクをこなすことよりずっと、タスク候補のアイデアを出すこと、どのタスクをやるのかという意思決定をすることのほうが重要だと感じるようになりました。「ユーザーから要望があった機能Aを追加する」というタスクではなく、「プロダクトの売上を上げる」ことを自分の仕事とし、そのために今すぐ機能Aを追加するのか、今は顧客ではない層を取り込む施策を打つのか。判断を正確にするためにリサーチをするのか、どのタスクに自分とチームの時間を使うのかを判断することが自分の仕事の成果を決めます。

まずは俯瞰して、自分が出すべき成果を定め、それを分解すること。分解した成果を出すために、どんなタスクがあるのかを洗い出し、優先度をつけること。そして、自分が今からしようとしているタスクとそのゴールをチームにレビューしてもらい、それを自分の成功の指標にすることを大事にしていきたいと思います。

最後に、ある程度自分の仕事を理解して成果を出せるようになったあとの試行錯誤について記載します。

右も左も分からなかったところから、数年経つと自分なりのやり方が確立されました。チームでのコミュニケーションも最適化されていき、方法論を意識せずともなめらかに仕事が回るようになりました。このとき、私は「仕事がつまらない」と感じるようになりました。はじめはどうして自分が仕事がつまらないと感じるのかが分からず、社外のコーチングしてくれるサービスを頼って話をさせてもらい、その原因は「WILL/CAN/MUSTで自分の目の前にあるタスクを分類したときに、CANとMUSTしかない」からだとわかりました。

理想論に当てはめると、プロダクトマネージャー失格です。プロダクトマネージャーがWILLのない状態で「まあこんなもんでプロダクトは成長していくだろう」というCANの計画を立てていれば、プロダクトはそれなりの成長しかしません。「プロダクトを10倍成長させるにはどうすればよいか？」という問いに、立ち向かっていかなければいけないのです。

仕事がつまらなく感じてモチベーションが下がったとき、その原因は、タスク候補のアイデアのマンネリ化だと判断しました。「売上を伸ばす」という仕事を達成するために取れる手段は複数あります。ですが、そこが思考停止してしまい、自分の頭の中にある引き出しの中からしかタスクが考えられておらず、いつも同じやり方になっていました。その結果、私自身も仕事がつまらなく感じてしまい、プロダクトの成長も鈍化してしまっていたと感じます。

解決策としては、外部からのインプットに助けられました。他のプロダクトをどのように作っているのかという話から、今までやったことがない手法論を知りました。UXリサーチャーやUXデザイナーなど、他職種の視点を学ぶことで引き出しが増えました。あえてユーザーではない人にヒアリングをすることで、次の成長のヒントを貰うことができました。

なんとなくうまく行っているときこそ、やり方を見直してみること。そして「自分の仕事はここからここまで」という定義を外して、新たな学びを得てみることが大事だと感じています。そのためにはプロダクトマネージャーという役割の定義を変えたり、一度別のミッションを持って職種を変えて知識を得るのも手段であるはずです。

以上のことが、私がキャリアを試行錯誤しながら学んだことです。20代の頃は誰かに評価されるために何を学べばよいかを考え、30代になるにつれて自分がしたい仕事をするためには何を学べばよいかを考えるように変化しました。キャリアに正解はなく、私自身もこれからまた仕事をする中で別の考えを持つこともあるかもしれません。40代、50代と年齢を重ねるに連れて、キャリアが変化できることを楽しみにしています。