Webエンジニアがプロダクトマネージャーにキャリアチェンジするとぶつかる壁とその超え方
SecureNavi株式会社でプロダクトマネージャーをしているゆーたろーです。(@shimotaroo)
このnoteでは実経験をもとにWebエンジニアがプロダクトマネージャーにキャリアチェンジするとぶつかる壁とその超え方を書いてみます。
僕は2022年4月にWebエンジニアからプロダクトマネージャー(以下、PM)にキャリアチェンジしました。（ちなみにキャリアチェンジと同時に現職に入社しました。入社エントリはこちら）
PMにキャリアチェンジしてからの2年半ほど、僕は色々な壁にぶち当たってきました。もちろん現在進行形でも壁にぶち当たっています。
また、2024年春頃に弊社に入社した同僚PM（僕と同じく入社と同時にWebエンジニア→PMにキャリアチェンジ）が仕事をする中で悪戦苦労しているのを見たり、相談に乗ったりしていると「ああ、2年前の僕を見ているようだ...」と感じることが結構ありました。WebエンジニアからPMにキャリアチェンジするとだいたい同じような壁にぶち当たるんだなと思いました。
というわけで、僕と同僚PMのN=2の経験則ですが、Webエンジニア→PMにキャリアチェンジすると「ぶつかる壁」「ぶち当たる理由」「壁の超え方」を書こうと思っています。
Webエンジニア→PMにキャリアチェンジしたばかりの方（Webエンジニアに限らず他職種→PMの方にも当てはまることがあるかもしれません）
これからPMにキャリアチェンジしたいと思っている方
このような方に少しでも参考になれば嬉しいです。
なお、このnoteは先述した同僚PMにも事前に目を通していただいたうえで公開しています。
夢中で書いていたら6,000字を超えてしまったので、はじめにこのnoteで取り上げる4つの「壁」を列挙します。詳細はここからスタートです。ぜひ最後まで読んでください！
・壁① - 自分で意思決定できない
・壁② - スコープが大きくなってしまう
・壁③ - わかりやすいドキュメントが作成できない
・壁④ - PMが自分に合っているのか不安になる
壁① - 自分で意思決定できない
僕がPMになってぶち当たった壁の中で最も高いものは間違いなくコレです。
PMになったばかりのとき、ことあるごとにCEOに「これってどちらが良いと思いますか？」と聞き、意思決定を委ねていました。（当時はCEOとビジネスサイド2名と僕の4名だった）
エンジニア→PMで大きく変わったことの1つは意思決定の多さです。エンジニアのときは「決める」ことよりも「決まったことを実現する」ことの方が多いですが、PMは圧倒的に「決める」ことが多いです。
UX実践者のためのプロダクトマネジメント入門には以下のように書かれています。
どんな業務も決定権を独占することはできないが、プロダクトマネジメントに関しては意思決定がメインの仕事といっても過言ではない。
当時の僕は意思決定はCEOに頼ってばっかりだったので「PMとして働いているのに他人に意思決定してもらっているって…自分の存在価値無くねえか…？」と思っていました。（し、実際のところマジで無かったかもしれません）
壁にぶち当たる理由🤔
ドメイン理解、プロダクト理解、市場理解が不足していることにより自分の意思決定に自信が持てない
失敗したくないから、自分より経験・スキルが豊富な人（＝失敗する可能性が低い人）に意思決定して欲しいと思ってしまう
壁の越え方🏋️
意思決定に必要な知識は精一杯キャッチアップする（とはいえ、人間が働く時間は有限なのでここはある程度時間が解決すると思いますが早ければ早い方が良い）
失敗を恐れない。失敗が悪いのではなく、失敗から学ばないことが悪いのだ、というマインドを強く持つ。（シニアPMの知人と話すと「いやあ、今も失敗ばっかりだよ」と言っていました。駆け出しPMが失敗しないなんてありえねえ！）
「どっちが良いですか？」ではなく「こっちで良いですか？」「こっちが良いと思います。どう思いますか？」と聞く。間違っていても良いから今の自分が出せる最高の答えを出すことが大事だと思う。
余談ですが、最近読んだnoteにめちゃくちゃ共感したので一部抜粋して紹介させてください。
最後に、そもそも「判断を求める」のか、「意見を求める」のかを間違えてもいけません。判断を求めるのは相手にオーナーシップを渡す行為、意見を求めるのはこちらにオーナーシップを保持する行為です。
デザイナー向けのnoteですが、全ビジネスパーソンにも当てはまる内容だと思いました。
壁② - スコープが大きくなってしまう
施策を進めていく中でスコープ（何をどこまでやるか）を適切に決めることは難しいです。
MVP（Minimum Viable Product）とは、「実用最小限の製品」という意味である。機能をつくり込んでからプロダクトをリリースするのではなく、実用最小限の単位でプロダクトをつくり価値検証することを促すものである。ここでいう「実用最小限」とは、プロダクトの価値をユーザーに提案することができる最小限を意味する。
PMとして働いていると「MVP」という言葉はよく聞きますが、「プロダクトの価値をユーザーに提案することができる最小限」ってなんですの、と思っていました。
例えば、とある課題を解決したいとなったとき、PMになったばかりの人は「これもあった方がお客様は喜ぶよな」「これがあった方がリッチだよな」「これをできるようにするなら、これもできるようにしたいな」などと思い、機能モリモリの施策にしてしまいがちです。（こんにちは、2年半前の僕です）
実は解きたい「課題/提供価値」に大きなインパクトを与える「ソリューション/機能」は1つしかなく、それ以外は「あった方がそりゃ良いけど、今なくてもお客様の解きたい課題は解決できる」というパターンは結構あります。
今回のケースは極端かもしれませんが、理論上は1つの「ソリューション/機能」だけが"適切なスコープ"だと言えます。
ここで「スコープが大きくなればなるほど、顧客に多く価値を提供できるから良いんじゃないの？」という疑問を持たれる方もいるかもしれません。個人的にスコープが大きくなるデメリットには以下のようなことがあると思います。
リリースするまでに時間がかかり、顧客への価値提供（デリバリー）が遅くなってしまう
そもそもすべての施策は仮説検証なので、満を持して大きくつくったとしても実が顧客はそこまで喜ばない可能性もある（その場合、そのために費やしたリソースは無駄になってしまう）
ちなみに何かの課題を解消するために"開発をしない"選択肢があればそれが1番良いと思っています。プロダクト・機能はつくった時点から負債になるので。（弊社CEOは「できればコードを書かない方が良い。コードは書いた瞬間から負債になる」とよく言っています）
壁にぶち当たる理由🤔
「解きたい課題/提供価値」と「ソリューション/機能」の対応がちゃんと整理できていない
「小さくつくる」ことのメリットと「大きくつくる」ことのデメリットを知らない
PMとして、なるべく良い状態で機能リリースしたい（＝機能をモリモリにすることが良いと思っている）（Linkedin共同創業者リード・ホフマンの言葉「もしあなたがリリースしたプロダクトについて少しも恥じることがないと言うなら、それを手を離すまでに時間をかけすぎたことを意味する」は金言だと思います）
壁の越え方🏋️
常に「これはもっと小さくできないかな？」という気持ちを持つ（とはいえ小さくすればするほど良いわけではないというのが難しいところ…😫）
正直、慣れな部分もあるので、定期的に内省する
他PM・エンジニア・デザイナーにスコープサイズを壁打ちする
（若干話が逸れますが）解きたい課題を小さく分解できないかも大事
例えばあるオブジェクトの「カスタマイズ」機能といえば登録/編集/削除が含まれますが、まずは「登録」だけできてもお客さまは喜ぶケースはあります。その場合は「登録機能」だけ爆速で実装してリリース→編集/削除の要望がどれくらいあるかを見るのが良いと個人的には思っています。
[心の声💭] 「壁の越え方」なんて調子に乗ったことを書きましたが、今でも難しいと思っています。一気に越えられるというより、"筋が良くなる"くらいのものだと思っています。（そう思った方が楽というのもある）
壁③ - わかりやすいドキュメントが作成できない
ドキュメント作成はPMの仕事の中でもかなり重要ですし、時間的なウェイトも結構占めます。
プロダクトマネージャーは、たくさん書く。Eメール、仕様書、もっとEメール、Slackのメッセージ、ユーザーストーリー、仮説、報告書、ロードマップ、バグレポート、スプリントの振り返り・・・とにかく、何かしら書いている。書くことが仕事の一部なのだ。
PMは普段から関わるメンバーがかなり多いので、相手に伝わりやすい(=わかりやすい)ドキュメントやメッセージを作成するスキルが求められます。ドキュメントやコミュニケーションの内容がわかりづらいと業務の進行に結構支障があると感じています。
Webエンジニアの中にはドキュメント作成が苦手な方がそれなりにいると思っており、PMにキャリアチェンジすると初めは苦労する可能性が高いと思います。
壁にぶち当たる理由🤔
ドキュメント作成の経験が少ない
Webエンジニア→PMになると関わる部門の数がかなり増える
壁の越え方🏋️
ドキュメント作成が得意なPMにレビューしてもらう
複雑な情報は文字だけでなく、図解を用いる（僕はMiroを頻繁に使います）
読み手視点でドキュメントを作成＆見直しを必ず行う
日常的に本を読んだり、記事を書いたり、アウトプットをしてドキュメント作成スキルを磨く
僕は新卒のJTC在籍時代に大量の自治体向けのドキュメントを作成していた＆Webエンジニアになってからも技術記事や個人ブログで高頻度で記事を書いていたので、幸いなことにドキュメント作成を壁に感じることはありませんでした。同僚PMは苦戦している印象でした。（ファイト📣）
壁④ - PMが自分に合っているのか不安になる
（当たり前ですが）Webエンジニア→PMにキャリアチェンジしたばかりは上手くいかないことが多く、ストレスフルな状態で仕事をしなければならない可能性があります。
僕はPMにキャリアチェンジする前はWebエンジニアとして2年働いており、開発業務にも（そこそこ）慣れたくらいだったので、PMになったばかりは「Webエンジニアだったら気持ち的にもっと楽に仕事ができていただろうな」と思うことが結構ありました。
PMに限らずキャリアチェンジすると多くのケースでほぼ振り出しに戻ったようなものになるので、もちろん仕事は思うようにいかず「あれ、PMになりたい・PMが合っていると思ってキャリアチェンジしたけど、もしかしたら合ってないかも...？キャリアチェンジ失敗した…？」と思う可能性があります。
壁にぶち当たる理由🤔
キャリアチェンジすると「初めての仕事」ばかりになるから
うまくいかない理由が「まだ経験したことない業務だから」なのか「自分には適性がないから」なのかの判断が難しい
そもそも自分に合っている職種がわからない（これは成果を探すためには壮大な旅になってしまうのでこのnoteでは扱わないことにします）
壁の越え方🏋️
結論、時間が解決してくれる可能性が高いのであまり気にしないで良いと思います！（誰だって初めてのことはうまくできない）
（とはいえ）PMはエンジニアより悩む要因が多い職種だと思うので、心を強く持ち、上手くいかないことすらも楽しむ。また、自分なりのストレス発散方法を確立するのも大事。
様々な理由によりPMが本当に自分に合わないと思ったら別の職種に再度キャリチェンジする（人生は長い）
まとめ
自分が実際に感じた＆同僚の仕事を見たり話したりして感じたWebエンジニアがプロダクトマネージャーにキャリアチェンジするとぶつかる壁とその超え方を書いてみました。
Webエンジニアに限らず、他職種からPMにキャリアチェンジすると必ず壁にぶち当たると思います。壁にぶち当たること自体は当たり前なので、それも楽しみ（成長の機会）と捉えてゆっくりでも良いので1つずつ超えていきましょう。
と言いつつ、1つの壁を超えた頃にはいくつもの新しい壁にぶち当たっているんですけどね…笑
僕はPMになってまだ2年半なのでわからないことはたくさんあるし、上手くいくことより上手くいかないことの方が多いですが、PMになってよかったと思っています。PMライフは楽しいですよ。
今PMになりたてで辛みを感じている方は一緒に頑張っていきましょう。
このnoteを公開する前に、同僚PMにnoteを読んでいただき、直接コメントしてもらったので原文のまま載せておきます。Webエンジニア→PMにキャリアチェンジして半年の現役PMの生の声です。
4つの壁全てにぶち当たった本人です。
壁を越えることも大事ですが、壁だと認識することができたこと、そして相談できる先輩がいたことが大きかったなと改めて思いました。
1人で抱えがちになってましたが、早く失敗しFBを頂く、先輩に気を遣わず質問や相談をする、経験から改善に繋げることが何よりの近道だなと今では思えてます。（まずは当たって砕けろ精神）
プロダクトマネージャーにキャリヤチェンジした方はぶち当たる壁だと思うので（本人経験済み）とても参考になると思います。
壁は今も立ちはだかってますが乗り越える方法を掴み始めているので「負けてたまるか！！」の精神で頑張ります！
素敵なコメントをありがとうございました。
PMになって1年9ヶ月時点で自分の失敗についてnoteを書いているので、こちらもよかったら覗いてみてください。
このnoteを書くにあたり、以下の書籍から抜粋させていただきました。（以下はAmazonアソシエイトのリンクなのでポチってくださると僕に紹介料が入ります）
SecureNaviではメンバーを募集中です！
2022年4月で4人だった組織もこのnote公開時点で70名を超える組織になりました。が、登りたい山を登るためにはまだまだメンバーが足りません。SecureNaviで働くことにご興味がある方はぜひ連絡ください。カジュアル面談も募集中です。
このnote執筆時点でSecureNaviに入社して2年半ほどが経過します。1年半経過時に書いたnoteを貼っておきます。ついでに冒頭でも紹介した入社エントリーも。
P.S.
[ゆる募] プロダクトマネジメントには正解がないので、他社のPMからプラクティスやTipsなどを色々お聞きしたいです。僕から何かできることがあるかはわかりませんが、ゆるく情報交換させていただけるPMの方がいらっしゃいましたら、Xでお気軽にメッセージいただけますと幸いです。今BtoB SaaSのPMなので、BtoBだと尚嬉しいです。