未経験からFindyでプロダクトマネージャーになって最初の3ヶ月でやったことと学び
こんにちは！
エンジニア採用支援・組織支援を行うファインディで、フリーランスエンジニアと企業の業務委託案件をマッチングするFindy Freelanceのプロダクトマネージャーをしている下畠 隆志（しもはた たかし）（@t_shimo2）といいます。
今年2月頃から本格的にプロダクトマネージャー業務をメインとして取り組み出して、早くも3ヶ月ほどが経過しました。
簡単に私のバックグラウンドは以下となります。
ご覧いただくと、「非エンジニア、未経験からプロダクトマネージャーへのチャレンジ」ということがお分かりいただけるかと思います。
- 新卒で大学受験予備校に入り、校舎スタッフ、校舎長として6年ほど勤務
- ファインディに転職して最初の2年はユーザーサクセス（キャリアアドバイザー）としてフリーランスエンジニアと企業のマッチングサポートを担当
- 2023年から本格的にプロダクトマネージャー業務をメインとして担当
非エンジニアからプロダクトマネージャーを目指される方、実際これから社内異動や転職などで担当されるという方を中心として、もし自分の経験が少しでも参考になればと思い今回記事を書くことにしました。
こちらの記事は以下のような方に向けた記事となっております。
- 非エンジニアからプロダクトマネージャーにチャレンジする方、したい方
- プロダクトマネージャー歴0日目〜3ヶ月くらいの方
- （もしかしたら）プロダクトマネージャーの採用や転職に携わる方
それでは早速、タイトルにあります、「未経験からプロダクトマネージャーになって3ヶ月の学び」について、以下大きく分けて3つの章立てでお伝えできればと思います。
※諸々詳細に書くと超長文になるため、諸々端折っている部分も多々ある点、ご了承ください。
1.実は、プロダクトマネージャーになりたくてなったわけではない
いきなりおや？という見出しをつけてみました。
より正確にお伝えすると、「プロダクトマネージャーになりたいと言ってなったわけではなく、気づいたらプロダクトマネージャーになっていた」という表現が近いかなと思います。
元々ファインディ入社後の最初の2年はユーザーサクセス（キャリアアドバイザー）として、フリーランスエンジニアと企業のマッチングのサポートを中心に業務に取り組んでいました。
そんな中で、昨年10月頃、週1の開発ミーティングに参加することに。
当時始まったばかりの大掛かりな開発が自身の担当業務と関連性が高かったこともあり、企画を巻き取る形となり、気づいたら翌月の11月には22件issueを作成。
今年1月には組織図上も「プロダクトマネジメント」の肩書きがつくようになっていました。
自分なりに当時を振り返ると、結果としてプロダクトマネージャーになるチャンスを掴めたのは以下のようなポイントがあったのかなと思っています。
【会社】プロダクトマネージャーを採用したいがなかなか難しい、社内登用が必要
【部署】今後事業としてもプロダクトに力を入れていきたいフェーズ
【自身】経験してきた業務範囲が広く各方面の業務に理解があった
【自身】社内信頼の積み重ね（これもあったと信じています笑）
ただ、当時いたメンバーの中でも歴が長い方になっており、自身を1人DF兼GKと称する（笑）くらいには各方面をカバーしていたので、プロダクトマネージャー業務とそれらを並行するのは到底不可能で、急ピッチで諸々の業務移管・役割分担を進めました。
プロダクトマネージャーとしての仕事に今注力できているのはチームの皆さんに恵まれたこと、その支えあってこそで、筆舌に尽くしがたい感謝の気持ちでいっぱいです。（いつも本当にありがとうございます！）
プロダクトマネージャーになりたい、と思ってこの記事を読んでくださった方向けに、この章の最後として以下の記事を参考として載せておきます。
2.最初の3ヶ月でやったこと-学びと伸びしろだらけの毎日-
最初の3ヶ月でやったことを簡単にまとめると、以下のような感じです。
本noteでは、◯をつけたところを中心に書きます。
本・人・旅によるインプットとアウトプット（◯）
ユーザーヒアリング／ユーザー面談同席（◯）
要求定義：ユーザーストーリーを意識したissue作成（◯）
開発タスクの優先順位付け（◯）
ひたすらエンジニアとSlackハドルで諸々issue内容についてすり合わせ
開発に伴うオペレーション変更の周知共有、ドキュメント化
プロダクトロードマップ作成
データ収集（と簡単な分析）
まとめると、
インプットを進めつつ、ユーザーの声を聴き、issueを作成しその優先順位を決め、日々エンジニアとのすり合わせを行い、Biz側に開発に伴う変更を周知。一方で今後に向けてプロダクトロードマップ作成や足元のデータ収集を行う。
そんな3ヶ月を過ごしていました。
それでは取り上げる4点についてもう少し具体的に書いていきます。
2-1.最初にやることを3つに決めた
プロダクトマネージャーになったものの、何からやったらいいかなんもわからんの状態の中で、ふと、敬愛していてよく著書を拝読する、ライフネット生命創業者の出口治明さんが著書で書かれていた言葉を思い出しました。
私にいくばくか教養のようなものがあるとすれば、それを培ってくれたのは、「本・人・旅」の三つです。私はこれまでの人生で、「本・人・旅」から多くのことを学んできました。あえて割合を示せば、本から五〇％、人から二五％、そして旅から二五％ぐらいを学んできたといったところでしょうか。
これをもとに、
本：プロダクトマネジメントに関する本・記事を読む（+動画や音声メディアなども）
人：ユーザー、ステークホルダーと話す
旅：社外のコミュニティに参加してみる
という3つのことをやってみると決め、動き出しました。
本や記事は挙げると終わりがなくこれだけで1本記事が書けてしまうので代表例だけですが、
例えば本なら「プロダクトマネジメントのすべて」をまず最初に読みました。（全体把握にとても勉強になりました、ありがとうございます！）
記事だと「プロダクトマネージャー1年目の教科書」であったりから読み始めました。（上記と合わせて、定期的に読み返す記事となっています、ありがとうございます！）
上記のような書籍や記事を読んでいって、Notionに載せていって気づきやネクストアクションもそこに書く、という形で自分の資産になるようにしていきました。
※一部はここに書かず自社のSlackのtimesに書いたものもあります。
人については、自社のユーザーにヒアリングをする（2-2で書きます）、またステークホルダーと話すに関しては、エンジニアはもちろん、部署内の営業側のメンバーや、経理、マーケなど、開発で影響がある人には幅広くコミュニケーションを取りました。
旅：社外のコミュニティに参加してみる、はプロダクト筋トレ、PM Clubなどいくつかプロダクトマネージャー界隈で有名なコミュニティがあるのでそちらに参加し、Slackの投稿を見てこういう情報が飛び交っているんだ、というのを見ていました。プロダクト筋トレさんの方ではちょうど定例飲み会があったので3月に参加してみたりもしました。
まずはやることを小さく決めて、動き出す。
プロダクトマネジメントトライアングルでイメージされるように、プロダクトマネージャーの業務は際限がなく、そして当然いきなり全てできるわけがないので、どうせミスるし、やりながら修正していこうという気持ちでスタートしました。
2-2.ユーザーヒアリングは楽しい、とりあえずやってみるべし
インプットを進めていくと、ユーザーヒアリングが重要ということが各方面で書かれており、前職も現職も、現場に答えがある（会議室じゃないって言っても元ネタ分からない人多いんだろうか笑）という考えが浸透している会社で育ってきたので、まずはユーザーサクセスの面談に同席しつつ2、3質問させてもらうことから始めてみました。
ユーザーヒアリング／ユーザーインタビューも奥が深く、様々考え方・手法がありジョブ理論はじめ大変勉強のしがいがありますが、全力インプットから始めるとあっという間に1ヶ月経ってしまうので、とりあえず同席予定を入れてしまい、締め切りドリブンでとりあえず数を重ねてみるのがいいかなと思っています。
（以下の記事や書籍で勉強しております、ありがとうございます！）
ヒアリングが多少拙くても、実際ユーザーと話しているとそもそも楽しいし、自然にアイディアが生まれたりもするので楽しいです！
（この点、元々ユーザーサクセスとしてユーザー担当をしていたため、自社のユーザーとは？というところの前提を一定スキップできているのはあると思います）
2-3.ユーザーストーリーを意識したissue作成
ユーザーヒアリングでインサイトを得て、さあissueを作成しようとなるわけですが、このissue作成がまた奥深かったです。
例えばFindy Freelanceで登録したら募集中の案件を見ることができるのですが、この案件の検索性を良くしたいと思ったら、
「案件一覧画面における検索性の改善」とかっていうタイトルのissueで進んでいきそうなところなのですが、その書き方で作っていくと、絶対エンジニアにこう言われる未来が待ってます。
「で、そもそもこれをやることの目的って何なんでしたっけ？これを通じてどうしたいんでしたっけ？」
注：分かりやすくするためにキツそうな言い方にしましたが、実際は100倍以上優しく問いかけていただけるとても温かい環境です、いつもありがとうございますmm
ユーザーストーリーについては諸々記事や書籍もあるため解説はそちらに譲りますが、以下のようなメリットを個人的に感じていてとても好きな考え方です。
ユーザーストーリーの考え方で考えることで、一定優先順位が自動的に見えてくる
エンジニアとの認識齟齬を防ぎやすい
プロダクトマネージャーはWhyとWhatに集中しやすくなり、エンジニアはそれを踏まえてのHowに集中しやすくなる
ユーザーストーリーの考え方はソフトウェア開発のみならず、様々なところで役立つと思っているのでもっと知られてほしいところです。
2-4.プロダクトマネージャーなりたてあるある、優先順位どうする問題
少しずつissue作成が進んできて、つくりたいものと、つくらなければいけないものでどんどんとissueがプロダクトバックログに溜まっていきます。
そうなると次の課題はそう、優先順位どうする？です。
「issue50個溜まったけど？1〜50番目まで全部優先順位決めるんだろうか？」
「とりあえず優先度最高・高・中とラベルつくったけど、それぞれ10数個ずつあるけど？」
「全部のissueのROI算出してその順番に並べる？」
等々、優先順位に迷い、優先順位の決め方に迷い、優先順位の決め方における基準に悩み、という無限ループに陥りそうになります。
RICEスコアはじめ、様々な優先順位の手法・フレームワークがあるので、今後そこを取り入れていこうとは思っていますが、当時はいきなりそれらの記事を読んで導入しよう、という意思決定をする余裕もなかったので、「まずはやることを小さく決めて、動き出す。」のスタンスで、以下のようなイメージで進めてみました。
緊急度・重要度を踏まえ、優先度最高・高・中の3つのラベルを付与する
（本来ここをRICEで数値化して優先度を決定するわけだが、一旦ユーザーヒアリングと経験からの肌感ドリブンからスタート）上記を元に、プロダクトバックログに概ね最高・高・中の順で並べていき、基本的には上から順に着手。issue内容によって細かい順番は相談の上適宜変更。
ただし、実際問題としては足元やらなければいけないことも多々あったので、やりたいこと＜やるべきことの優先順位でこの3ヶ月は進めていました。
前提、ユーザーヒアリングを全くせず、プロダクトバックログとにらめっこをして決めていくのはもってのほかです。
ただ、ユーザーヒアリングだけで1番から100番目まで決まるか？というと実際は対ユーザー向けの機能だけでなく社内向け管理画面であったり、クライアント企業向け画面だったり、内部改善系タスクだったり、それぞれ複合した中での優先順位を決めていく必要があるので、シンプルに決めて動きながら自社の状況に合わせて修正していくのが1番良いなと思っています。
2-5.実際にプロダクトマネージャーをやってみてのやりがい、楽しい瞬間
一言でまとめると、「自分が考えたものが、目に見えるカタチになるのが嬉しい」です。
少し後付け感もあるような気もするのですが、私の場合、実家が小さい工場で、幼少期から「ものづくり」と近い環境で育ってきました。
幼稚園のころ、何かでおそらく見てつくったストローを加工してつくって簡単なおもちゃを持っていったら喜ばれて、みんなに作り方を教えて嬉しかったこともおぼろげながら覚えています。
おそらくそんなバックグラウンドも影響して、「自分が考えたものが、目に見えるカタチになるのが嬉しい」とリリースした機能を触ってみた瞬間に思える自分がいます。
※もちろん考えるだけでなく自分で作ったらより嬉しさも倍増だとは思いますが、そこは弊社の素晴らしいエンジニアの皆さんをすごいなと思いながら尊敬の眼差しで見つめています。
最初の3ヶ月は色々あってどちらかというと全体的に足元のやるべきことを優先していたため、今後はよりユーザーの課題解決に繋がるリリースを進めていって、「自分が考えたものが、目に見えるカタチになり、ユーザーからの嬉しい声を聴けることが楽しい」と言えるよう、ユーザーの課題特定、課題解決に寄与していきたいです！すでにワクワクしています。楽しみです。
3.今後の展望と目標
3-1.引き続き、ユーザーの声を聴いていく
これからどれだけプロダクトマネージャーとしての経験を積んでいっても、ユーザーの声を聴くことは辞めないでしょう。
特にフリーランスエンジニア界隈は技術の移り変わりや、最近だとリモートの温度感、インボイス制度等々も含め、変動が多い業界です。
手が止まったら、いや手が止まる前にユーザーに聴きに行く、接点を持ち続けることを引き続きやっていきたいと思います。
3-2.施策の優先順位の定量化と振り返りの定例化
2-4の優先順位どうする問題で書きましたが、まだ施策の優先順位を決めるにあたって、本来であればRICEスコアなどを用いつつ、ROIを元に優先順位を決めていくのが事業のトップラインをプロダクトの力で引き上げていくのに望ましいです。
まだまだ肌感ドリブンの状況なので、ここを数値を元に決めていきつつ、その数値に対してどうだったのかを定期的に振り返り、その精度を上げていくことにチャレンジしていきます。
これを通じて、より自身の意思決定の精度を高めていきたいです。
3-3.自分自身を尖らせていく
プロダクトマネージャーも細分化されていくのでは？と予想されています。
シンプルにSEとして開発に関するあれこれをやっていたソフトウェアエンジニアが、Webアプリケーション開発でフロントエンド、バックエンド、インフラ、iOS/Android、機械学習、等々とどんどん職種が分かれていったように。
プロダクトマネージャーも、マーケ×PMのPMM（プロダクト・マーケティング・マネージャー）を始めとして、エンジニアバックグラウンドで技術理解に長けたTPM（テクニカル・プロダクトマネージャー）、それ以外でも、デザイン×PM、データ分析×PMなど、様々な◯◯×PMが増えていく中で、自分は何を掛けていくのか。考えながらキャリアを歩んでいきたいなと思っています。
最後に
大変長くなってしまいましたが、ここまで読んでいただいた方、本当にありがとうございました。何かの参考になっていれば大変嬉しいです。
もし何かご質問、話したいなどございましたら、お気軽にTwitter（@t_shimo2）でご連絡いただけると喜びます！
そして、弊社絶賛採用中ですので、もしご興味ございましたらカジュアル面談からお気軽にどうぞ！
この記事が気に入ったらサポートをしてみませんか？