Product Manager Tips


Product Manager (プロダクトマネージャー) に関連する記事をまとめていきます。

プロダクトマネージャーに必要な資質とは?

プロダクトマネージャーは、要はものを決める人

河合:会社によってPMはいろんな形があると思いますが、シリコンバレーでは、要は「ものを決める人」という共通の理解があります。「これ、どうしようかな」と悩んだときにとりあえず伝える人。そして、何か言ったら怒らずに決めてくれる人。エンジニアが「PMがこれでいいって言いました」って言える、そういう、「ちょうどいい人」という役割なんですよね。

及川:会社を立ち上げたときには、PMがファウンダー陣の中にいるはずです。その人の思いをちゃんと受け取って、プロダクトやサービスを作っていくのが次のPMの仕事ですよね。その部分に関して、ファウンダーなりCEOとしっかり共通理解ができていれば、「サービス価値を貶めないで、事業サイドからのいろんなリクエストにどのくらい合わせるべきか」というよくある質問への答えも出てくると思います。

でも、複数のタスクやイシューがあったとき、優先順位はどのように決定していますか? 当然トレードオフがあると思いますが。

河合:これは永遠のテーマで……ずっと試行錯誤してます。最後はカンです。データを分析して出てくるものもありますが、出てこないものもありますよね。例えばポケモンGOでいうと、次にどの機能を追加するのか。同時にはできないものをどちらからやるか、すごく難しいです。時にはエンジニアリングのコストやスケジュールといった外的な要因も見て、それらを並べて、「うーん、こっちだよね」という話をするしかない。機能の追加と、今出ている問題の改善とのトレードオフもけっこう大変です。

同じことをやっていたら、プロダクトマネージャーとしては負け

Q:いまは一人でPMの業務に就いていますが、サービスや組織が大きくなるにつれて、自分一人では抑えきれない領域が出てくるかもしれません。そのとき、どのように役割分担すべきかを教えてください。

河合:PMの仕事って、「その他全部」ですよね。だから、その他全部がいっぱいになってきたらどうしようっていう話ですよね。キャパシティを増やすにはやり方は二つあって、仕組みを作って誰かにやってもらうか、PMを増やすしかないです。

この四半期と次の四半期で同じことをやっていたら負けです。僕も言われてきたんですが、僕らは「チェンジエージェント」であり、変化の仕掛けを作るのが仕事。プロジェクトに入っていって、問題を聞いて、要件を立てて、直す。で、回るようになったら「じゃ、よろしく」といって次に行かなきゃいけない。定常的なルーチンのタスクになったらそれは離して、次の仕事に行かないと負けです。これが、その後も続く仕組みを作るPMの仕事だし、同じことをやってちゃダメ。

でも、それでも回らなくなることもあるので、そうしたらPMをどう組織にするか、ということになります。ユーザーに見えるフロントとインフラに近いバックで分けるやり方もありますし、フィーチャーで分けることもありますよね。プロダクトとユーザーの種類で分けるのがいいと思います。

プロダクトマネージャーには強い奥歯と厚い面の皮が必要

及川:Twitterでいただいた質問は「ポケモンGO」は、「最初の展示会ではネガティブな反応を受けたと聞いたんですが、そこからどうやってローンチまで持って行ったのか」だそうです。

河合:そうですね、フィールドテストでは結構こてんぱんにされましたね。僕らとしては、修正できるところはした上で、とにかく出して、良くしていくというプロセスを回さないと、最終的なユーザーの反応は分からないだろうからと、最後はエイヤ、と見切って出しました。パッケージソフトじゃないので、出して終わりじゃないんですよね。ですから、出してからもずっと、ユーザーの意見を聞いて直すサイクルをどれだけ早く回せるか、やってみようと。

及川:freeeの佐々木さんの講演でも、「最初にプロダクトを出したとき、ユーザーからのフィードバックがあまりよくなかったとき、開発者のモチベーションが下がるんじゃないですか」という質問があったんですが、同じようなことはありませんでしたか?

河合:ちゃんと凹むのって大事ですよね(笑)。PMには強い奥歯と厚い面の皮が必要だとよく言っているんですが、言われたことは笑顔で聞く。ユーザーさんが言ってくれることは宝物で、そこには必ず改善のヒントがありますから。ただ、ぐっと来るのも事実。だから、熱いお風呂にゆっくり入るとか、それをうまくプロセスする方法は持った方がいいと思います。

それから、エンジニアをどこまで守るかはみんな悩むんですよね。ユーザーの言うことをがちんとぶつけてエンジニアに目を覚ましてほしい場合もありますが、あんまり言ってばかりだと「俺たち、つまんないものを作ってるんじゃないか」って悪い方にいっちゃう。そこのバランスは大事です。

ただ、僕たちはユーザーの代弁者なんだっていう思いは、PMなら誰しも抱いていると思います。ですがユーザーの代弁者というのも、一部のやかましい人だけが大声でいっている場合と、多くの人が軽く嫌だと思っている場合では、実は後者の方が大事です。でも、大きい声やネガティブな声に引きずられやすいので、全体のバランスは見るようにしています。

及川:声なき声を拾うってことですが、けっこう難しいですよね。グーグルの場合は、あまりユーザーの声を拾わないで、データを見て、そこにある、声を出さないユーザーの声をとっていましたね。

それから、PMって技術力がどのくらいいりますか、という質問もよく聞かれます。もちろん開発力があるほうがいいとは思うけれど、僕は、ちゃんと技術の会話ができて、エンジニアからリスペクトされる存在であることが大事だと思います。河合さんはガチに技術を深掘りするタイプではないけれど、そこがうまくできていたように思います。そのコツは?

河合:知ったかぶりも、最後までばれなければ知ったかぶりにはなりませんから(笑)。聞きながらひたすら「うんうん、こーいうことかな?」っていうのが上手かどうかですよね。もちろん、最低でもある程度のことは分かっていないといけませんから、そこは教えてもらいながら。あとは、この人がドーナツが好きかな、ビールが好きかな、と。

及川:焼き肉に連れて行くのがPMのタスクの一つとか(笑)

河合:PMの責任って、プロダクトを作って、世に出して、愛されて、使ってもらうことです。それに必要なリソースがないなら、ないものはしょうがないから、どこかからかき集めてくるしかない。それも含めて自分の仕事ですから、もし焼き肉をおごったらコード書いてくれるかもしれないならおごります。そういうのはよくありました。

エンジニアに納得感を持ってもらうことが重要

Q:(省略)仕様に関して、PMとエンジニアの関係はどうあるべきでしょうか。

河合:(省略)ボトムアップの見かけは大変重要です。

PMとしては、エンジニアが同じ思いを持っているとすごくいい。言われて作らされている感をもたれるとやめちゃいますし。ですから、いかにエンジニアに「これがやりたかったんだよね?」「うん、これがやりたかった」と思ってもらうかが、PMの腕の見せ所です。

その上でどこまでこだわるか、どこまで細かくやるかは、PMによって幅があります。シリコンバレーでも、スティーブ・ジョブスのようにとことんこだわる方がいい、いやそれだと作ってくれる奴がいなくなる、と意見が分かれるところですが、僕は、そこに集まったチームでベストのパフォーマンスが出せればいいと思っていて、自分のこだわりをあまり持たないようにしています。もし、エンジニア二人でどっちがいいかぶつかって決まらないときは、僕が入ってとにかく決める。どんなディシジョンでもノーディシジョンよりはいいですから。

まとめると、いかに「自分ごと」にしてもらって、プロダクトの成功にチームがコミットできる環境を作ることが大事です。あとはPMのキャラクター次第ですね。

及川:PMって、全員に納得感を持って決定を受け入れてもらうため、ファシリテーション能力がけっこう必要ですよね。既にいろんなところで話しているのでバレちゃってるテクニックですが、自分にこうしたい、という方向があっても、自分では言わずに相手の口から言わせるようにするんです。そうすると、相手は自分が決めたかのように、納得感を持って仕事を進めてくれる。

このテクニックで良いところは、もし自分が間違っていたときには、相手からもっと良い意見が出てくるんですね。自分では99%こうやろうと決めていたとしても、1%のそれよりもいい意見を拾える可能性があるんです。なので、最終的にはトップダウンで決めるかもしれませんが、ある程度ボトムアップの仕組みを取り入れるのは非常に重要です。でも、時には相手にミエミエってこともありますが(笑)

Q:優先順位を付けるときの「カン」って何ですか、もう少しブレークダウンして教えてください。

河合:ビジョンとミッションは何なのか、が最初に来ると思うんですよ。僕らの場合はさっき言った「Adventures on foot」。それにExplore、Excersice、Engageという3つの軸に沿っているかの判断もします。もう一つはプロダクトのゴールです。KPIをユーザー数で見ているならば、どちらを取ったらユーザー数が増えるのか、と考えます。そして最後は自分が一ユーザーとしてどちらが好きか、ですね。ユーザー目線でぶれないのが大事です。

及川:ChromeのときはStability、Speed、Simpleという3つのSを挙げていて、そこを失ってはいけない。機能がついてもスピードが遅くなってはいけない。もう一つ、KPIツリーを作って、本当にそれが必要なのか、どのくらいインパクトがあるかを、ポジティブネガティブ、両方見ていました。

Q:意見の衝突があったとき、どうやってゴールまで持ってきますか?

河合:衝突、上等ですね。衝突のない会議の方がよっぽど心配ですよね。衝突はあったほうがいいという前提で、どこでディスアグリーなのかを整理するのがファシリテーターの仕事ですから、「言っていることはそんなに違わないよね」といった具合に整理して、あとはひたすら自分がサンドバッグ、クッションになると。

及川:何も反対意見が出てこないアイデアっていうのは、大したことのないアイデアである可能性がありますよね。それを引き出すようなファシリテーションやチーム文化を作ることが大切かなと思います。衝突があるところには、実はチャンスのタネがある。普段から信頼し合っていれば、人格攻撃にならないような環境を作った上で、激論が交わせると。外国の人はそのへんがうまいですよね、さっきまで大激論したのに、部屋を出たらけろっとしていたりしますから。

「衝突」が無い方が問題という発想がよいですね。より良くしていこうという点でお互い妥協してないって証拠なんでしょうね。あと、「人格攻撃にならないように」ってのは自分も日頃から気を遣っていることなんだけど、改めて重要なポイントなんだと思いました。

この記事へのコメントは閉じられています。