既存のプロダクトチームにJOINしたプロダクトマネージャーがまずやるべきこと

はじめに

私はどちらかというと初期メンバーとしてゼロからプロダクトを開発する経験の方が多いのですが、元々存在しているプロダクトにプロダクトマネージャーとして参画する機会が最近あったのでその備忘録です。

こんなプロダクト開発の現場って意外と多いのではないでしょうか？

事業責任者とエンジニアでとりあえず開発をスタート
 　↓
いい感じにグロース
　↓
社内外からの要望が増えてタスクが積み上がる
　↓
プロダクトチームメンバーを増やす
　↓
思うように生産性上がらない・チームが一つの方向に向かずハレーション発生

まさにこんなタイミングでプロダクトマネージャーとしてプロダクトチームにJOINしたときに何をしたかということを書いていきます。ちなみに私がJOINする前のプロダクトチームはエンジニアリーダーとプロダクトマネージャーを兼任している人が1人いてあとはエンジニア3人とデザイナーが1人いるという状況でした。

この記事が誰かしらのお役に立てたら幸いです（いいなと思ったらハートマークを押していただけたら喜びます）。

1. チームのヘルスチェック

"良いプロダクト"は"良いチーム"によって生み出されます。特定の人に極端な負荷がかかっている状態やプロダクトに全員が向き合ってない状態のチームは持続性のある良いプロダクトチームとは呼べません。

全員がプロダクトに向き合っているチームのことをプロダクト志向のチームと呼びます。

まずチームがプロダクト志向のチームになっているかを把握するかが重要だと思っています。

1.1 メンバーリストを用意する

まずはプロダクトチームのタレントを把握するためにチームのメンバーリストを用意します。ない場合はこの機会に作ります。どんなチームでも最初から最後までメンバーが変わらないということはまずないと思いますので、途中で参画した人のためにもWikiなどチームメンバーがいつでもアクセス可能場所に作っておきましょう。すでに存在している場合は最新の状態にメンテされているかだけ確認します。

なお私が担当するプロジェクトではConfluenceなどのプロジェクトページに貼っておくことが多いです。

1.2 プロダクトメンバー全員との1on1

プロダクトメンバー全員と1on1をします。チームの規模感にもよりますが開発や個別の作業に影響を与えないように30分程度でクイックに行うのがいいと思います。

アジェンダは大体こんな感じ。

・自分（プロダクトマネージャー）の自己紹介
・現状のモチベーション確認
・チームに伝えてないプロダクトやチームに関するアイデアがないか
・困っていること、改善したいこと

中には「今まで話を聞いてくれる人がいなかったけどやっと話を聞いてもらえる人がきた！」と思って困ってることや改善したいアイディアを堰を切ったように話し始める人もいて30分では時間が足りなくなるかもしれません。その場合は時間を延長せず別途30分押さえて話すのがいいと思います（途中で話を聞くのをやめてしまうとメンバーにとってはむしろフラストレーションになります）。

大事なのは思いをすべて吐き出してもらうことと、ただの感情論ではなく建設的な意見を吸い上げることです。メンバーはそのプロダクトに関わる先輩なわけなので、傾聴力をもって話を聞くのが重要だと思います。

ちなみに逆に何も意見がない人の場合は、プロダクトに対する思いやこれからどうしたいかのアイデアを確認することで、プロダクト志向かどうかを確認します。

そしてここまででプロダクト志向のチームかどうかを見極めます。プロダクト志向のチームかどうかは私の中ではこんなイメージです。

プロダクト志向のチームの例
・常に会話の主語がプロダクトである
・プロダクト方針が数字（ファクト）、個人の想い、外的要因のバランスをとって決定されている

プロダクト志向ではないチームの例
・誰が言った意見かによりプロダクト内の優先度が変化する
・プロダクト方針がない、または個人の想いや外的要因のみで決定されている

そしてプロダクト志向ではないチームだった場合は2に進みます。プロダクト志向のチームの場合は3に進みます。

2. （プロダクト志向ではない場合）マインドチェンジ

プロダクト志向なチームにマインドチェンジしていく必要があります。手法としてはこんな感じでしょうか？

・チームルールの策定（主にコミュニケーションを促すようなもの）
・チーム懇親会
・合宿

基本的に日本人は真面目な人種だと思うのでプロダクトに対する感情が全くない人はいないと思ってます。そんな人はとっくにチームからいなくなってるはずですし。経験上言っても無駄だから意見を押し殺しているという状況のほうが多い気がしています。

それに対して個人的に大切にしているのは雑談がしやすい状況をうまく作り出すことで良い情報も悪い情報も早く伝わるようにしていたりします。私のチームのSlackチャンネルが雑談チャンネルと化して「このチャンネルは居心地が良い」と言われることはしばしばです...w

3. プロダクトの整理

プロダクトに対して最も熱い思いを持っているのはプロダクトマネージャーである必要はあるとは思いますが、それに共感する人がチームにいないとチームとして強くなれません。そのためにはプロダクトマネージャーや思いを持った人の脳内をすべて吐き出して「今後こういうことをやっていこうと思うんだよね」というものが可視化されている事が重要です。

そのために私は2つのことを実践しています。

3.1 プロダクトビジョンの作成

3ヶ月ごとくらいの粒度で「プロダクトをこうします」というロードマップを描きます。プロダクトの種類によっては外的要因（例えば法律が変わるとか競合の状況など）もその変化のポイントに書き加えます。

3.2 プロダクトバックログの整理

「この機能を追加する」というタスクをまとめたものです。書くべき内容はこんな感じ。

・起案者（誰のアイディアなのか。詳しく聞きたい場合のために）
・優先度（緊急・高・中・低）
・内容
・関連するPRD（要件定義のフォーマット・あとから書くことがほとんど）

ガッツリ内容を書く必要はなく、私の場合Slack等で「こうしたいなぁ」みたいなことが書かれたら都度拾ってバックログに突っ込むようにしてます。粒度も一旦気にしません。でかすぎるなと思ったらあとからサブタスクにしたりします。

そして最も重要なのはとにかく一つのツール内にすべての情報を入れておくことだと思います。ツールがバラバラだと見落としても発生しますし視認性がよくありません。

ツールはAsanaでもNotionでも何でもいいと思いますが個人的にはJIRAが好きだったりはします。プラグインが有償・無償問わず豊富でとにかくJIRAに突っ込んでおけばViewはあとからどうとでも作れる気がするところが好きです。

参考になれば幸いです。私も経験を重ねる中でさらに思ったことがあれば随時加筆していきます。