プロダクトマネージャーの役割

毎週更新 #PdMノウハウ の第2回目のnoteです。第1回目のnoteは「プロダクトには愛が必要だ」です。もし良ければ読んでいただけたら嬉しいです。今日は言語化されづらいプロダクトマネージャー (PdM) の役割を言語化したいと思います。

PdMは「プロダクトの成長に責任を持つ人」と定義されますが、役割は会社、組織、プロダクトのフェーズによって本当に多種多様です。PdMになる前に何をしていたのかによって得意領域が異なることと思います。

多種多様な顔をもつPdMの役割の中で、特に重要だと考える3つを言語化したいと思います。その3つとは以下です。

・もっとも解決すべきイシューを決定する
・プロダクト開発におけるプレイヤー間の領域において100点の動きをする
・チームメンバーがコトに向かうための障壁を取り除き、100点のパフォーマンスが出せる環境と仕組みを整備する

もっとも解決すべきイシューを決定する

PdMの役割の中で、もっとも難しい役割の一つだと思っています。個人的には、まだこの役割においては十分にワークできていないので、自分なりの考え方を書き留めておきたいと思います。また「意思決定」についてはそれだけでnoteを書こうと考えているので、簡潔に書きたいと思います。

まずは「なぜ、解決すべきイシューを決めるべきなのか」ということについて考えます。日々、プロダクトに向き合っていると多くの問題に遭遇します。新機能の開発という問題から、ボタンの文言や色を変えるなどの問題まで様々です。これらの問題を発見された順番から片付けていけば良いのでしょうか。それでは、いくらリソースがあったとしても足りなくなってしまいます。僕たちを取り巻く環境が日々急激に変化して、プロダクトのライフサイクルがどんどん短くなっている時代において、何に取り組むべきかという選定がプロダクトの成功を大きく左右します。これはスタートアップやベンチャー企業だけの話ではなくなってきました。安定していると言われきた大きな企業でさえも取り組むべき課題を間違えたら、生き残っていくことが難しい世界になったのです。

プロダクト (≒ 事業) の解決すべきイシューについて考える前に、もう少し大きな枠組みで考えて、属している会社としてどこを目指しているのかということから考える必要があります。しかしながら、そこまで考慮するとかなり大きな話になってきてしまうので、別の機会にしてプロダクトにおける解決すべきイシューについてというスコープで考えます。

前置きの最後に、解決すべきイシューについてのアプローチについては非常に多くの書籍があります。おすすめは「イシューからはじめよ」と「エッセンシャル思考」です。それぞれの書籍の要約を書いたり、ハイブリッドさせた言葉を連ねても焼き回しになってしまうので、僕が考える要点を3つ挙げて書きたいと思います。

・逆算思考
・自分の範疇で考えない
・仮説を立て、不確実性を落とすために情報を収集し、説明可能にする

まず最初に「逆算思考」について考えたと思います。逆算思考の本質は目標設定と時間スケールでの目標の因数分解だと考えています。つまり、僕らはどこを目指すべきなのか、なぜ目指さなけばならないのかという旗を遠くに打ち立て、そこに到るまでの目標を因数分解していきます。

具体的には、以下のような考えを持つことが良いのかなと考えています。

・プロダクトの最終的なゴールを立てる (変更しても良い)
・3年後にはプロダクトがどのような状態になっていないといけないのか
・1年後にはプロダクトがどのような状態になっていないといけないのか
・半年後にはプロダクトがどのような状態になっていないといけないのか
・3ヶ月後にはプロダクトがどのような状態になっていないといけないのか
・1ヶ月後にはプロダクトがどのような状態になっていないといけないのか
・2週間後にはプロダクトがどのような状態になっていないといけないのか
・来週にはプロダクトがどのような状態になっていないといけないのか
・明日にはプロダクトがどのような状態になっていないといけないのか

というように時間スケールにおける目標を無理やりにでも言語化してみるのが良いと考えています。最終的なゴール (遠くに旗を立てる) を設定する目的は、自分たちが現時点でエベレストを登ろうとしているのか、富士山を登ろうとしているのかによって、チームの認識が異なるため、まずは自分たちが何を目指しているのかという認識を合わせるためです。

逆算思考でのフレーズは常に「N日後までには〜という状態になっていないといけない、そのために今もっとも解決すべき課題はなにか、今取り組んでいることは本当に解決すべき課題なのか」を自分の魂やチームに問い続けて、思考停止に陥らないようにします。そして、あるべき状態に達するためのアプローチが間違っていないかどうかを確かめるためにも有効です。もしも目標としている状態と実績から予測される数値との間にギャップが大きく存在する場合に、既存の方法では目標を達成することができない、ではどうすべきか？という思考にいたることができます。言われてみたら簡単な話ですが、日々目の前の仕事に追われているとなかなか目を向けられなくなってしまいます。

次に「自分の範疇で考えない」について考えます。僕もよくやりがちなのですが、多くの人が陥ってしまうことに、自分が扱える物事の範疇で課題をみつけ、解決しようとしてしまいます。ですが、本当にプロダクトを成長させるための解くべき課題は実は思考の外に隠れているかも知れません。

僕自身もまだうまく実践できているわけではないですが、自分の範疇で考えないコツは、アンテナを高くして1次情報を集めることとあらゆる物事の本質を捉えて点と点の繋がりを意識することにあるのかなと思います。あとは「それは無理だ」と頭がシャットダウンしている領域にアクセスすること。

インターネットに落ちていて皆がアクセスできる情報はほとんどは物事の良い面を都合よく切り取ったものであることがほとんどです。プロダクトに活かせる本当の情報にアクセスするためには、その情報を持っている人に聞きにいくしかないと思っています。もちろん、その情報は価値が高いのでGive&Takeの関係性を作ることが重要です。そして、世の中にある物事の本質、意図を捉えるクセをつけることも重要です。「なぜ、今〜の領域に参入するのか」や「なぜ、このプロダクトのオンボーディングで〜の訴求をいれているのか」など、実行者の意図を汲み取り、それらの点を繋ぎ合わせていくと、実は思いもよらなかったことに気が付くかもしれません。

書き始めたら長くなってしまいましたが、最後に「仮説を立て、不確実性を落とすために情報を収集し、説明可能にする」について考えます。ある課題があったとします。例えば「新しくリリースした機能が想定していたほど使われていない」という課題があったとして、それはなぜかという仮説がいくつか出てきます。「階層が深く気がついてないのか？」や「機能がわかりにくかったのか？」などから、こうすれば新機能が使われるのではないかという仮定を考えることができます。ここで「本当にそうか？」という不確実性が潜んでおり、PdMはこの不確実性を落とすために、定性と定量の両面で情報を収集し、確からしいことを探します。ユーザー体験に沿ってSQLを叩いてファネル分析をしたり、ユーザーインタビューを通して答え合わせをするかも知れません。集めた情報を集積し、整理して、ドキュメントにまとめることを通して、その課題が本当に解くべき課題なのかという度合いに対して客観的な判断材料をつけます。山積している課題に対して、それが本当に解くべき課題なのかをPdMの独自の思考回路ではなく、客観的に説明することが可能な状態にすることが大切だと考えています。

プロダクト開発におけるプレイヤー間の領域において100点の動きをする

PdMの役割は様々あります。その中で本質的にはこうではないのかという考えを書きたいと思います。

そもそも、PdMという役職は必要なのでしょうか。明確にPdMという役職が存在しなくても伸びているプロダクトは多くあります (役職名が違うだけなケースもありますが) 。とすると「PdMの役割とは」という大きな疑問が出てきます。

PdMの役割の結論としては「プレイヤー (部署) 間の領域において、プロダクトの成長のために必要な役割を担う」だと考えていて、以下の図で説明します。

この図はプロダクトの初期フェーズについての概念図です。灰色 (#DDDDD) の枠組みがプロゼクトの成長に必要な役割全てを表しています (具体的に何が必要かは言及しません) 。四角、三角、丸はプロダクトに関わるプレイヤー (広くは部署/部門) を示しています。 プロダクトの初期フェーズにおいては、灰色の領域は少なく、個人が手を伸ばせば届き解決できる程度です。このフェーズにおいて、PdMがすべき役割 (=「プレイヤー (部署) 間の領域において、プロダクトの成長のために必要な役割を担う」) はチームの誰かが担っている状態であると言えます。要するに、プレイヤーがある程度のジェネラリスト的な側面 (何でも屋とも表現できそうです) を持ってプロダクト開発に向き合っている状態です。

次にプロダクトは順調に成長している拡大フェーズについての概念図です。灰色の領域が増えてきました。前提としてプレイヤーは急速には守備範囲が広がらず、そして守備範囲には限度があるとします。つまり、プレイヤーがカバーしきれない領域が増えてきました。要するに誰も取らないボールがプレイヤーの間に落ちてしまうという状態です。この解決策として、新しく人員を補強する (ここでは専門領域の丸を持った人を入れることを仮定) という方法もありますが、灰色の領域はなかなか埋まりません。その時に必要になってくるのがPdMなのではないかと考えています。プロダクトを成長させていくためには灰色の全領域は欠かせず、専門的な役割を持ったメンバーではカバーしきれなくなった役割をカバーするのがPdMだと説明づけられるように思います。そして、灰色の領域はプロダクトのフェーズやメンバーのスキルセットによって変化します。そのため、様々な役割が存在することになります。

また、重要な点はこの領域で100点を出すことを目指すこと、権限を移譲することができる人をアサインすることです。例えば、本当にプロダクトが市場に受け入れられているのかをユーザーインタビューを実施することになりました。しかしながら、PdMは経験をしたことがなく専門領域ではないため、最初は無知な状態です。ここで重要なことは、素早い情報収集能力と理解力、実践力になります。そして、ある程度内容を把握したら、適任となる人を社内で探すか外からひっぱってきて権限を移譲します。決してPdMがずっと特定領域で戦い続ける必要はないと考えています。ゆえにカメレオン的な動きが求められているのだと思います。

なんでもこなすというより、プロダクトを成長させるために必要だと思うこと (イシュー度が高い) をこなして行く時に、予測が難しい世の中において採用を含めて、柔軟に対応することはかなり困難です。組織を筋肉質に保ちつつ、適切な採用をしていくには、本当に一つのポジションをオープンにしてよいのかを含めて不確実性を落とすために、PdMが要点を抑えてアジリティ高く役割を埋めていくことが必要だと考えています。

拡大フェーズで徐々に問題になってくるのが、部門間の情報の非対称性とプロダクトに対する意思決定、開発リソースです。拡大フェーズでは、セールスやマーケティング部門の確立、人員の補強、プロダクトのさらなるグロースと様々な変化があります。その中で生じるのが情報の非対称性によるプロダクトに対する意思決定の複雑化です。それぞれの部門では目標が設定されており、ほとんどの場合プロダクトへの変更が伴います。部門というスコープでみれば、目標達成するためにはプロダクトへの変更や運用リソースの確保がトッププライオリティになります。しかしながら、開発リソースは限りあるものであり、本当に解決すべき課題を見極めなければ、プロダクトの成長はありません。

プロダクトに対するステークホルダーの情報を集積し、正しい意思決定をしていくためには、情報の非対称性を解決するPdMの出番です。具体的には、それぞれの部門の定例に出席したり、週次で開発のプライオリティを確認する場を設けて、情報を集めます。全ての情報をインプットし、整理して、どの課題から解決するかということを説明するための準備をする必要があります。なぜ、その施策を遅らせるのか、いつ実施する予定なのかというロードマップを策定する必要があります。

最後に、プロダクトがさらに成長したフェーズについての概念図です。プロダクトがさらに成長した際には、一つのプロダクトに対して、複数の領域ができるようになります。これは一つの大きな機能かも知れませんし、メルカリなどのように一つのカテゴリごとに責任者をおいたり (現在はどうなっているのかはわかりませんが) するケースもあります。僕自身のこのフェーズはほとんど経験したことがないので、もし知見がある方がいたら教えてください。もっと知見がたまったら言語化していきたいと多います。

このフェーズで重要になってくるのが、各PdMの意思決定と施策実行の独立性を担保しつつ、プロダクトがあらぬ方向にいかないように全体を俯瞰したパランスを保つことだと思います。それぞれが、独自のKPIを追い、自分たちだけのノルマをクリアすれば評価されるというような組織になってしまうと、局所最適化になってしまうため、俯瞰した視点と自分の管轄領域での成果を出していく必要があるため、プロダクトマネージメントの難易度が飛躍艇にあがってくると思っています。PdMを横串でみるポジションの設置 (CPOやCXOなど) や積極的にPdM同士が情報交換、全体の目標の確認などをしていく必要があると思います。

チームメンバーがコトに向かうための障壁を取り除き、100点のパフォーマンスが出せる環境と仕組みを整備する

チームメンバーがコトに向かうためには様々な障壁が存在します。組織の中には、様々な問題が生まれ続けます。それはドキュメントの未整備や情報の伝達が上手くいっていない状態、本当は自動化した方が良いけれど後回しになってできていないなど様々な原因である可能性があります。タスクの棚卸しを定期的に実施すると、本当にその人が解決すべきなのかというのが浮き彫りになることもあります。

ドキュメントを整備し、情報伝達のフローを整えて、依頼フロー (背景や目的の説明が抜けて、手戻りが発生してしまう可能性を防ぐ) を整備するなどをすることもPdMがカバーすべき範囲だと考えています。それを自分で手を動かして解決すべきかは考えるべきですが、少なくとも障壁があるのかどうかを定期的にチェックして、取り除くためのアクションを撮り続ける必要があります。

次に、チームメンバーが成果に対して100点のパフォーマンスを出すための環境と仕組みを整備することについて考えます。プロダクトが成長し、経験もバックグラウンドも異なる新しい人が仲間に加わっていくと、プロダクト開発に対する価値観やアウトプットに対する100点の基準も異なります。

このチーム内の成果に対する基準を揃えるための場を設定することが重要です。週に数回、今週出てきたアウトプットに対して良い点と改善すべき点をチーム内でプロダクトを触りながら認識し、基準を揃えていく方法もあります。プロダクトの品質をPdMに依存させず、問題が起きたら都度対応するのではなく、このように仕組みに落としこんでスケジュールに組み込んでおくことが大事かと思います。

dely CXOの坪田さん (@tsubotax) のこの記事がとても参考になるので、読んでみてください。

終わりに

言語化されづらいPdMの役割について、自分なりの考えを言語化してみました。一気に書いたため読みにくい部分あるかと思いますが、少しでも参考にしていただき、お役に立てたら幸いです。