本記事は『プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで』（松永拓也、山本航、武田直人、監修：及川卓也）の「第4章 一人のプロダクトマネージャーとして立ち上がる」から抜粋したものです。掲載にあたって一部を編集しています。
プロダクトマネージャーになってからまず意識すべきこと
優れたプロダクトマネージャーになれるかどうかはあなた次第。ではどのようにして一人のプロダクトマネージャーとして立ち上がっていけばよいでしょうか。プロダクトマネージャーの育成環境が整っている企業であったとしても、「身を委ねていれば大丈夫」なんてことはありません。早期に周囲から頼られて信頼されるプロダクトマネージャーになるために、意識すべきこと、実行すべきことを紹介します。
一緒に働く人を理解する
もっとも肝心なことは一緒に働く人、チームメンバーを知り理解することです。業務時間だけでなく積極的にランチに誘ったりして、コミュニケーションをとるようにしましょう。業務とは関係のないちょっとした雑談から、その人の傾向や大事にしている価値観を理解でき、今後のやりとりを円滑にする情報が得られるかもしれません。
リモートワーク頻度の多い企業であっても、最初のうちはできる限り対面で話をしたほうが理解度が高まります。場合によっては「自分は出社しているので、○○さんもオフィスにいらっしゃれば一緒にランチしませんか？」と積極的に会話の機会を設けてもよいでしょう。みなさん家庭や普段の働き方があるとは思いますが、異動・入社直後であれば誘いに応じてくれやすいはずです。
プロダクトに関する情報を徹底的にインプット
次に自らが関わるプロダクトや事業のミッション、戦略、ロードマップなどをもれなくインプットします。入社前にあらかじめ調べていた点も、入社後に改めて社内情報に触れることで異なった角度で新しい気づきを得ることができます。
場合によっては想定外に技術的負債があるかもしれないですし、MRR（月間売上）が伸びていたりするかもしれません。とくにプロダクト戦略は今後あなたがプロダクト開発を進めていくにあたって大きく影響するものです。社内DBやSlack、Wikiなどで情報が不足している場合は、社内のキーマンを見つけて積極的にヒアリングをかけてみてください。
戦略やロードマップを理解できたら社内のルールや開発ツール、過去のSlackのやりとりなどを読み漁り、所属している組織の進め方をインプットしてみてください。郷に入っては郷に従えというように、その組織特有の進め方や方針があるかもしれません。前職や前チームでの自分なりのやり方を披露するのは信頼貯金が貯まってからでも遅くないでしょう。
「自分ロードマップ」をつくる
これらの動き方や意識は決してプロダクトマネージャー職だけに限った話ではなく、その他の職種に適用できることでもあります。ただ、プロダクトマネージャーはとくに関わるステークホルダーが多いので、積極的にチームメンバーとのコミュニケーションを意識していきましょう。
企業によっては30/60/90 Days planとよばれるオンボーディング計画が用意されているかもしれません。既存の育成プランを活用しつつ、自らの考えで早期立ち上がりを目指してみてください。
そして必ず自分なりの目標、すなわち「自分ロードマップ」のようなものをつくり（もしくはイメージし）、定期的に上司やメンターからフィードバックを受けるようにしましょう。自身の成長を客観視することで不足していること、足りていることを理解することができます。必要に応じて私たちのようなキャリアアドバイザーと壁打ちすることも有効です。
プロダクトマネージャーになりたての人が最初にぶつかる5つの壁
プロダクトマネージャー特有の仕事の難しさは頭では十分理解していたものの、実際の業務に臨んでみて初めてわかる壁があるでしょう。ここでは多くの方が直面する5つの壁を紹介します（図1）。
1. 決断の場面が多い
前職でどんな経験をしていたかにもよりますが、これまで以上に自分で判断し、決断を求められるのがプロダクトマネージャーの仕事です。担当するプロダクトがどんなものであっても課題は山積みでしょう。その解決のために本当にたくさんの人がプロダクト開発チームで動いています。
優秀なチームであるほど解決のための手段は数多くあり、どの選択肢をとるかを決めるのはプロダクトマネージャーであるあなたの仕事です。ベテランエンジニアはA案を、他社で大活躍していた中途入社のデザイナーはB案を推しており、そのどちらもよさそうに思えます。しかし、同時に進められるものではなさそうです。そんなときも自らの責任において、どちらかの案を採択して課題に立ち向かわなければなりません。
また、課題解決の方法を選択するだけでなく、「そもそもいま優先的に解決すべき課題なのか」という段階から検討する必要があります。リソースは限られているので、重要度の高低も検討しなければなりません。たとえば、ある課題を解決すれば即効性が高く、大手企業の顧客から喜ばれるかもしれません。もう一方の課題は緊急度が低いけれど、早期に手を付けたほうが中長期的にはメリットがありそうです。こんなとき、どちらを選ぶべきでしょうか。プロダクトマネージャーの打つ手によって数年後のプロダクトの成長や、事業の成長が決定づけられるのです。しかも、こんな多くのプレッシャーの中で、決断を「スピーディーに」していくことも求められます。
こうしたときに、決断の手助けになるのはプロダクトのロードマップに照らし合わせて判断することです。プロダクトの成長のためにはいくつもの課題がありますが、それをどのように、いつまでに解決していくかという道標を見ながら判断することが基本になります。また、優先すべきKPIについて関係各所と相談して決めておくことも有効です。どの数値を伸ばすことを最優先にすべきかが明確であれば、判断の際の大きな手助けとなるでしょう。
このように決断時には優先順位を決めることが非常に大切です。優先順位付けのフレームワークとして、たとえば「RICE」があります（図2）。
どのくらいのユーザーに届くのか（Reach）、どの程度の影響を及ぼすのか（Impact）、期待通りの価値を提供できるのか（Confidence）、どのくらいの時間や労力がかかるのか（Effort）の4項目をそれぞれスコア化し、最終的にRICEスコアとよばれる総合スコアを算出する手法です。具体的には以下の式で算出します。
RICEスコア＝ユーザー到達度 × 影響度 × 確度÷労力
これらを活用し、プロダクトマネージャーに多く求められる決断の場面を突破していきましょう。
2. 他職種との連携がうまくいかない
プロダクトマネージャー業務は関係者が多い仕事です。関係者が多いだけでなく、彼ら・彼女らの考えていること、性質、向かいたい方向性などをどれだけ本人に近い気持ちで理解できるかが欠かせません。前職の経験に近い職種の気持ちは理解しやすいと思われますが、果たして本当にそうでしょうか。まずはそこから、謙虚にとらえていきましょう。
たとえばSIerでのプログラミングとプロジェクトマネジメントの経験を経てプロダクトマネージャーになる場合を考えてみましょう。自社開発のエンジニアは受託開発のエンジニアと比べて、サービスへの愛着や思い入れ、理想などを強くもって業務に臨んでいることが多いです。新人プロダクトマネージャーであるあなたの方針が、彼ら・彼女らの理想と離れたものだったらどうでしょう。
「エンジニアはコミュニケーション下手が多い」「進捗管理の際に気を付けるポイントはこんなこと」という程度の浅い理解でわかったつもりになるのが一番危険です。何よりその「わかったつもり」がチームの信頼を失いかねません。経験のない職種へのリスペクトと謙虚さをもつことは誰にでもできます。自身の経験に近しい職種のメンバーと接点をもつときこそ、わかったつもりにならないことを強く意識していきましょう。
一方でプロダクトマネージャー自身の問題ではなく、組織として役割分担、責任境界線が不明確である場合もあります。承認フローや進捗を共有すべき相手が不明瞭なまま、ハブ人材にならないといけないプロダクトマネージャーが疲弊していく事例も多く見られます。
そんなときは、DACI（Driver（意思決定の推進者）、Approver（承認者）、Contributor（協力者）、Informed（進捗の共有先）の役割を関係者に当てはめて意思決定速度を高めるためのフレームワーク）などの意思決定フレームワークを用いて関係者に役割を当てはめてみましょう。多くの職種や階層が絡む場面でも、プロダクトマネージャーとしてどう動くべきか、誰に何を依頼すべきかが明確になり連携がしやすくなります。
3. 正解がわからなさすぎる
プロダクトマネージャーの仕事には正解がないといわれています。それは「多くの課題がある中でどれを選んでもプロダクトの進化には寄与しているから」「実施した施策がどうなるかは後になってみないとわからないから」といった背景があるためです。
プロダクトマネージャーはその時々で進む方向性を決め、進み方を決断しなければなりません。その業務がひと段落した後も、下した判断は正しかったのか、明快な答えが出ないままのことも多くあります。成功や達成感を短期で味わいたい人には向かない仕事かもしれません。正解がわからない期間における忍耐力は、プロダクトマネージャーに必須のスキルといえるでしょう。
これに対する具体的なアクションとしては、KPIを設定することが一番の近道です。KPIをさらに階層化しサブKPIなどを設ければ、比較的手触り感のある目標が設定できるかもしれません。どのKPIに対しての施策なのかを明確にし、KPIを測定し、その測定結果をもとにPDCAを回していきましょう。一度で思うような結果が得られることがなくとも、何度も試行錯誤を繰り返すことで正解に近づいていく感覚が得られるはずです。
4. 真の課題かどうかの判断が難しい
プロダクトマネージャーはユーザーの声を聞き、ユーザーの課題を解決するためにさまざまな意思決定をしていきます。しかし多くの場合、ユーザーは自身の課題を正確に把握していません。悪気なく、真の課題からは外れた回答をすることも多いのです。ユーザーの真の課題を抽出することは、想像以上に難度が高いことを覚悟したほうがよいでしょう。
また、プロダクト自体の抱える課題についても適切に把握することは難しいものです。どんなプロダクトも構成要素が非常に多く、複雑な掛け算ででき上がっているものばかりです。
その構成要素のうち、どのパラメーターをいじるとどんな効果が出そうなのか。絶対に変えてはいけない部分はどこなのか。複雑に絡み合った要素のうち、表層化している課題に直結するものを探り当てることすら、最初は難しいと思います。それがプロダクトにとって本当に解決すべき課題かどうか、という問いに至っては、経験が浅いうちはなかなか判断が難しいかもしれません。
この壁を乗り越えるためには、ユーザーインタビューやカスタマーサクセスとのコミュニケーションを通じて、ユーザーのもつ課題の解像度を高めることがもっとも役立ちます。また、図4-3に示すフィッシュボーン図（特性要因図とも表される）などの分析手法を学ぶことで、複雑に構成されたプロダクトにおいても、真の課題にたどり着く基礎能力を身につけることができるでしょう。
5. メンバーと対面で会えない
令和のプロダクトマネージャーならではの悩みとして、メンバーと対面で会いづらいということがあります。多くの関係者の中心に立つプロダクトマネージャーにとって、関係者・メンバーとのコミュニケーションが業務の基本となります。伝えるべきことを伝える、聞くべきことを聞くのはもちろん、いまのチームのコンディションをメンバーの身ぶり手ぶりやちょっとしたしぐさといった非言語情報で察知し、問題がありそうであれば早期に手を打つことが求められます。これがすばらしいチームの運営のために、ひいてはプロダクトの成功のために必要なのです。
しかし、昨今のリモートワーク下で、これまでオフィスで自然と起こっていたことが起きなくなっています。たとえばコンビニで偶然会ってオフィスに帰るまでの間の近況報告、チームメンバーの覇気のなさに廊下ですれ違ったときに気づくことなど、いままでは流れの中でとれていたコミュニケーションが、困難になっています。このことが新しく加入したチームで、プロダクトマネージャーとしてふるまう難度を上げています。
企業によっては「プロダクトマネージャーは週2日を目安に出社推奨」などのよびかけがあったりします。しかし、本質的にはリモートワーク下でもプロダクトマネージャーが主導して、オフィス出社と同等のコミュニケーションレベルを確保するための工夫を行うのがよいでしょう。
たとえば、これまで行っていたユーザーインタビューやセールスとクライアントとの商談は、リモート環境だからこそ録画しておくことができるようになりました。プロダクトチームで録画を見ながらユーザーの反応を共有し、今後の方針決めに役立てることもできます。また、週次でも隔週でも、カスタマーサクセスやエンジニア、セールスなど、プロダクトに関わるメンバーが集まって現状の課題や懸念事項、学びの共有を行っている職場もあります。
そのほか小さなことですが、Slackなどのツールにおけるコミュニケーションをプロダクトマネージャーが率先して丁寧すぎるくらいに行ったり、リアクションを細やかにしたりすることも有効です。リモートワークにおけるチーム内コミュニケーションも、プロダクトマネージャーの必須スキルになっていくでしょう。
これらの壁を乗り越えるために必要な素養と心構え
ここまで5つの壁を紹介しましたが、いずれもプロダクトマネージャーとして一歩を踏み出そうとするみなさんを脅かすような内容かもしれません。しかし、これを読んでプロダクトマネージャーを目指すのは辞めようかな、とは決して思わないでください。これらを乗り越えるために、どのような素養と心構えが必要なのかを解説します。
未経験からプロダクトマネージャーになり、成功している方々はみなさん勉強家です。ある方は、プロダクトマネジメントの関連書籍を半年で100冊読み漁ったそうです。別の方は社会人向けの教育コンテンツでプロダクトマネジメントと名の付くものはすべて見たとのことでした。まったくの門外漢だった開発業務を理解するために、コーディングを勉強して簡単なスマホアプリをつくり、リリースし、運用する経験から入ったという方もいました。
副次的なものではありますが、プロダクトのために努力することは自身を成長させるためだけでなく、その姿を見ているであろう数多くのステークホルダーを味方に付ける効果も期待できます。
身も蓋もない表現になりますが、最初はとにかくやってみて失敗するしかありません。成功体験のみでキャリアをつくっていければもちろん最高ですが、なかなかそううまくいくものではないでしょう。大事なのは失敗をきちんと振り返ることです。そのときに先輩のプロダクトマネージャーや関わった他職種のメンバーなどまわりのすべての人から学びを深めていきましょう。新人プロダクトマネージャーにとってはみんなが師匠です。
これまでお会いした優秀なプロダクトマネージャーほど、多くの失敗談をもっています。プロダクトマネージャー同士で失敗談で盛り上がれるようになったとき、あなたは一人前になっているのかもしれません。
