5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

エンジニア出身プロダクトマネージャーの1年目の通信簿【Qiita Night~プロダクトマネジメント~】

Last updated at Posted at 2023-01-31

はじめに

2022/12/16に開催された Qiita Night~プロダクトマネジメント~ にて、「エンジニア出身PMの1年目の通信簿」というタイトルでLTをさせていただきました。

Youtube

この記事では、登壇でお話しさせていただいた内容を要点だけまとめさせていただきます。

お話しした内容

会計システムのエンジニアとしてキャリアをスタートし、コンサル会社を経て現在NewsPicksでプロダクトマネージャーをしています。
類似のキャリアチェンジをした方や、今後検討される方のための一例となればと考え、エンジニア出身でPMを1年やった結果を振り返り、思ったことやもう一度最初からやるならどうするか、など考えたことをまとめております。

image

対象プロダクトと着任時スキルセット

株式会社ニューズピックスにて、ソーシャル経済メディア「NewsPicks」の改善に参画しました。
プロダクトの特徴を簡潔にまとめると、以下のような特徴が挙げられます。

  • さまざまなメディアのニュースを人とテクノロジーでキュレーション
  • ユーザーのコメントによって、ニュースの深い・多様な理解を促す
  • オリジナル記事・動画で楽しく経済を学べる
image

NewsPicksはiOS/Androidアプリと、Webでもサービスを提供しています。
App Store
Google Play
Web

着任時点でNewsPicksのプロダクトマネージャーはリーダー1人、メンバー2人で私が参加して全4人でプロダクトマネジメントを実施する体制でした。
また、着任時点での自分のスキルセットは以下のようなものでした。
image

1社目のワークスアプリケーションズで会計パッケージの開発・運用に携わりました。この頃はプロダクトマネージャーという役職もまだ日本ではメジャーではなく、エンジニアが自身の担当モジュールのプロダクトマネジメントを兼任しているような形でした。
そのため、プロダクトマネジメントについては「類似の仕事を全くやったことがないわけではないが、メインの職務としてやったことはない」という状況でした。

通信簿

前置きが長くなりましたが、通信簿形式でPM1年目を振り返りました。
image

キャリアチェンジにめげずに日々頑張ることをはしましたし、初めてtoCのプロダクトを扱う中でUIUXデザインやユーザーリサーチの重要性は初年度にかなり学べたと感じています。
また、特定KPIの改善のための「施策検討→A/Bテスト→定量分析・次のアクション決定」のPDCAサイクルを回すことも一定慣れました。

ただ、振り返ると黄色で色付けした以下3点はあまり上手くできなかったなという部分が多く、この点を中心に振り返っていきました。

  • PMの主たる役割を理解しワークし始める
  • 対象ドメインを理解する
  • ユーザー・ビジネスにインパクトを与える

振り返り:PMの主たる役割を理解しワークし始める

PM着任にあたり、類似するような仕事は少ししたことがあるものの完全初心者なので、書籍や各種記事を読みPMについてキャッチアップしました。
その上で、着任時点で以下のような点を心構えとして持ちました。

image

この心構え、着任時点のスキルセットを踏まえ、文字通りなんでもやってみました。

image

結果を振り返ると「アウトカム(ユーザー体験や事業上のインパクト)のためになんでもやったが、忙しさもあり気づくとアウトプット思考になっていた」という部分がありました。
特に、私見ですがエンジニア出身だと、エンジニアの際に「ともかく作って出さないと意味がない(何も起きない)」という事実と戦うため、アウトプットに責任を持つあまりどうしてもアウトプット思考になりやすいのでは、と感じました。

image

2年目からは、「いまPMが最もやるべきこと」を見定めて、アウトカム最大化を常に考えていきたいと思います。

振り返り:対象ドメインを理解する

新卒入社で初めて、これまで一番長く携わったプロダクトはtoBの会計システムで、ドメイン知識(会計システムでは、業務や法制に関する知識)がないと何もできないようなプロダクトでした。

そのため、ドメイン知識の重要性は理解しているつもりでしたが、toCのニュースサービスで、自身も使ったことがあるしなんとなくの「こうだったらいいな」は割と最初の段階から言える部分がありました。
image

さらに、定量分析やユーザーインタビューを重ねることでさまざまな理解が深まり、根拠をもった「なにが必要か」の意見が言えるような気持ちになっていました。

ただ、1年を終えて振り返ると、表面的な改善が多く、ユーザーのニュース・情報摂取体験を変えるような根本的な改善はほとんどできなかったように感じました。
これは

  • そもそもニュースとは
  • ニュースは、生活の中でどういう役割を持っていて、どう扱われるべきか
  • ユーザーは、何をどう知りたいのか、どういう課題を持っているのか

といった部分を深く考え尽くさないと実現できないと感じました。
image

これを特に強く感じたのは、NewsPicksでは「ビジネスサイド」と読んでいますが、コンテンツに普段から深く携わっている方々と話した時です。
記者/動画クリエイター/編成など、「ニュース・情報の提供内容」を常に考えている方々と話すと、プロダクトでの実現方法はさておき、心にストンと落ちるような仮説がさっと出てくることが多くありました。

image

PMが全てをできる必要はない、アウトカムに至れればOKと考えると、こういった方とのコミュニケーションを増やせばいいということになります。
もちろんそうなのですが、今後それをやっていくにあたり、コミュニケーション量が増えることは得てして実行・実現速度とのトレードオフになります。
PMとしては、先の通り当然アウトカムが重要なので意味のない機能のリリースは意味がないのですが、とはいえ「議論の発散を繰り返し、なにもアウトプットされない」のも怖いです。アウトカムが大事とではあるが、アウトプットがないとそれも発生しないためです。
また、私見ですがエンジニア出身だと、発散フェーズでどうしても実現性や実装を考えてしまい、自由な発想の妨げになる部分もあるかと思いました。ここも、エンジニア出身の場合には注意すべき点かもしれません。

2年目からは、徹底的な発散と収束をPMのソフトスキルとして身につけていきたいと考えています。

振り返り:ユーザー・ビジネスにインパクトを与える

最後は少し小さめな振り返りポイントですが、端的にいうと

  • すべてから学ぼうとしすぎない
  • 「目指すところをわかりやすく言い切ることは大事」

という振り返りです。

初年度はA/Bテストの施策をたくさんやり、いい効果があることも悪い効果が出てしまうことも、なんの変化も産まないこともありました。ここまでは、よくある話かと思います。

これを1年の終わりに振り返り 「失敗したA/Bテストから学ぼうとすることをしすぎる瞬間があった」 と感じました。
悪い変化も、「ユーザーの動きが変化するポイントを見つけた」という意味では学びになるので、良い効果よりも色々と調べたくなります。
ただ、これを定量調査でやり始めると際限がなくなり、時間は際限なくかかっていきます。また、そこから得た発見で次の施策を検討するといつの間にか「定量的に確実に説明がつく、小粒な施策が大量に走る」という状況に陥る時がありました。

image

とはいえユーザーを知ることは重要で、分析は重要です。「いまこの分析にどれくらい時間をかけるか」を「X時間まで」といった方法でルール化するのは、場合によってはよくない結果を産むこともあるし、あまり納得感がありません。

今後こういった事態を防ぐためにも重要と感じたのは「どんな世界を目指しているのか?(どれくらいの改善を目指しているのか?)」の認識を合わせることかと考えました。

「こんな水準まで改善したいと考えている。それを目指す上で、今時間をかけるべきはどれなのか?」

という視点を共有して議論すると、特定施策の分析に時間を使いすぎたり、小さな施策に終始することも起きないのでは、というのが現時点の仮説です。(もちろん、細かい改善を否定する意味ではありません)

image

とはいえ、「達成できる根拠を説明できない目標を掲げること」はしたくない、無責任だと感じる部分もあり、この辺りは今後も考えながらやっていきたいと思っています。

総括

総括として「入社時に戻るとしたらどうするか?」を考え、以下のようにまとめました。

  • 初期の「できることをなんでもやった」動き方は、仮に入社時に戻ったとしても変えない
  • PMの役割・ミッションにフォーカスし始めるタイミングを自分の中で見計らい、その時がきたら意識的に行動を変える
image

最初から「自分はプロダクトマネージャーなのだから、その役割に集中する」というところで価値が出せるならもちろんそれが一番ですが難しいことが多いと思いますし、特に会社を変えてPMにチャレンジするような場合はまず周囲からの信頼を得る必要があります。

そのためにも、まずは自分の 「エンジニア出身」という持てるスキルを使って、PMの役割に固執しすぎずプロダクト改善のためにできることをやる のが良いのでは、と考えました。

その上で、プロダクト・ドメインの解像度が上がり、PMとして注力すべきことが見えてきたタイミングで一気に意識的に「PMとしてやるべきこと」にフォーカスするのがエンジニア出身でPMにキャリアチェンジした際には良いのでは、と振り返りました。

また、この「タイミングを見計らう」のは難しいので、上長に客観的な意見を求めても良いかもしれません。

最後に

「エンジニア出身PMの1年目の通信簿」としてLTさせていただきました。
あまりこういう発信は得意ではないのですが、他の方の記事や登壇から得るものはとても多いので、恩返しのためにもやれるときにはやっていきたいと思います。

最後までお読みいただき、ありがとうございました。

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?