プロダクトマネージャーに訊く #4：Kaizen Platform瀧野さん（後編）

チーム開発を成功させるためのプロダクトマネジメント

― 最近、日本でもプロダクトマネジメントが注目されていますが、その理由はなんだと思いますか？

小さいチームでも大きな影響力を持ちうることや、チームの力を最大化することで新たな価値を生み出せることに、皆んなが気づき始めているのでしょう。その手段の一つとしてプロダクトマネジメントが注目されているんじゃないかというのが個人的な見立てです。

チームの重要性はスタートアップであれ大きな会社であれ変わらない。少し前に「ビジョナリー・カンパニー」がトレンドになったことががありましたがビジョンやイノベーションの重要性が先行して注目されて、それを実現するチームを支える役割としてプロダクトマネージャーが必要とされるようになったのではないでしょうか。

― もともと個人でビジネスをしていた瀧野さんがチームの重要性に気づいたのはどんなきっかけがあったのでしょうか。

GREEの時の経験が大きいですね。GREEに入って最初の仕事は、売上が下がるトレンドにあったソーシャルゲームをリニューアルすることでした。売上目標と撤退期限が決められているプロダクトをエンジニア2人と新卒一人の4人のチームで立て直すことになったのです。

普通にやっていたら達成できない高い売上目標が設定されていたので、「どうやったら売上を伸ばせるか」ではなく、「どうやったらゲームチェンジを仕掛けられるのか」ということをチームで議論しました。

どういうゲームが流行っているのか、ユーザーはどういうものに興味を持つのか、どういうメカニズムでソーシャルゲームにハマるのか、など色々なことを調べてプロトタイプを作り、テストを繰り返した結果、売上を大きく伸ばすことができました。目標から逆算してやるべきことをチームで知恵を絞って考える。そうしたら見事に目標を達成できた。コラボレーションが生む力を実感できた成功体験です。

ただ、その頃は「プロダクトマネジメント」という言葉は知りませんでしたし、意図的に仕掛けられてはいなかったです。エンジニア、プロジェクトマネージャー、マーケターといった、違うスキルセットを持った人たちを集めてチームにし、目標に向かって自立的に稼働するようにする。こうしたマネジメントを意識的にやったのはやはりアメリカの子会社でプロダクト開発の組織作りをしたときですね。

本質的な価値を見極めてチーム全員が腹落ちする状態にすること

― 良いプロダクトを作るためにはこうすべき、という定石があれば教えて下さい。

「本質的なプロダクトの価値を考える」ということです。我々が作るプロダクトはなぜ価値があるのか、なぜ買ってもらえるのか、ということを突き詰めて議論します。開発期間の3割はそうしたディスカッションに時間を割いています。
その際に主観ではなく客観的に価値を捉えることが大切です。toCならコンシューマーの心理や行動、toBなら構造を客観的に理解する必要がある。そのためにはユーザーインタビューや市場調査、統計調査を通じてマーケットを見ることです。

自分の頭の中の仮説だけでプロダクトを作ると大抵ダメですね。思い込みを外すのはすごく難しいんですが、自分に対して正当な批判を行って主観を外すことがPMには求められます。

もう一つは、本質的な価値は何かということについて、チームが腹落ちしている状態にすることです。いくら要件定義を細かくしても、何を達成するために作っているのかわからないと、拘りや熱量も生まれませんし、なにより良いアイデアも出てこないんですよね。

それだけでなく、実装のしやすさを優先して要件を修正するような、訳のわからないことが起きてしまいます。本質的な価値を実現する上で、これは完全にアウトです。価値を提供するために何が一番良い選択なのか、チームのメンバーひとりひとりが判断できるようにすることが良いプロダクトを作るための必須要件です。

― 逆にこういうやり方をすると失敗するというアンチパターンはありますか？

目的が本質的でないオーダーを安請け合いすると失敗しますね。そういうプロジェクトでは大抵スケジュールが先に決まります。例えば、決算までに何らかの成果を言えるようにしなければならないから何か出してくれ、といったように、何を成すべきかという議論が無い中で、いつまでに何かを出してくれ、という期日だけが決まるようなケースです。

プロダクトマネージャーは真意のわからないオーダーに“YES”と言っちゃいけない。「なぜやるのか」「その時に達成しなきゃいけないことは何か」ということを経営に対して問わなければならない。そういうコミュニケーションをきちんとしないでただ受け入れてはいけません。

そういうわけのわからないプロジェクトでは、期日に近くなるとチームメンバーが「デスマーチだ」と言い始めます。目的が明確で一生懸命やっているときは忙しくてもデスマーチだとは言わないんですね。目的を達成できるようにスケジュールは自分たちで決めるし頑張るんですよ。なぜやるのか、ということを皆が強烈に自分ごと化しているときは、良いプロダクトができます。

― これからPMをめざす人とか悩んでる人におすすめの本とか、こういう本を読んでおいた良いよとかっていうのはありますか？

このインタビューシリーズの以前の記事でも紹介されてましたが、Inspiredは実例を交えた良い本ですね。あれに加えて“CRACKING THE PM INTERVIEW”という本がおすすめです。プロダクトマネジメントについて広く浅く書かれた本なので、この本の後にInspiredを読むとよく理解できると思います。 

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~

 “TEAM OF TEAMS”という本もこれからPMになる人にはお勧めです。ちょっと前に「チームが機能するとはどういうことか」という本がエンジニアの間で話題になりましたが、“TEAM OF TEAMS”のほうは読み物として単純に面白い。機能しないチームと機能するチームの対比がすごくわかりやすく描かれています。 

TEAM OF TEAMS (チーム・オブ・チームズ)

 もう一つはマーケティングベーシックセレクションシリーズにプロダクトマーケティングという本があります。この本ではプロダクトマーケティングについて広く浅く体系的にまとめられています。 

プロダクト・マーケティング(マーケティンク゛・ヘ゛ーシック・セレクション・シリース゛) (DO BOOKS―マーケティング・ベーシック・セレクション・シリーズ)

 PMの仕事の中でもプロダクトマーケティングは特に重要です。プロダクトマーケティングを理解することで自分たちのプロダクトの価値を俯瞰的に捉える能力が身に付きます。

経験や知識以上に重要な「情熱」や「我の強さ」

― 記事の読者に伝えたいことはありますか？

もしKaizen Platformがやってることを見て「いいな」と思ったらぜひ話聞きに来て欲しいです。PMが僕を含めて2人しかいないんですよ。30人エンジニアいるので、あと二人ぐらいPMがいてくれると助かります。

― こういう人に来て欲しいという人材要件はありますか？

我が強いことですね。さきほどの「主観は外せ」という話と矛盾しているように聞こえるかもしれませんが、「主観を外せるけど我が強い」みたいな人が理想ですね。

Kaizen Platformはすごくディスカッションが多い会社なんです。アジェンダが決まっているミーティングは短時間で終わらせるべきですが、答えがわからないことを話すときは何回でも何時間でも話すようにしています。だから突き詰めて考える力や、拘りや我の強さがすごく大事です。

諦めないでロジックを突き詰めることができる人は、すごく楽しく一緒に仕事できるんじゃないかと思います。

― PMとしての経験や知識よりも、我の強さを求める、と。

私自身が叩き上げでプロダクトマネジメントを学んだということもあるんですが、あんまり方法論に囚われないほうが良いと思っています。経験はないよりあったほうがもちろんいいんですが、手法は常にアップデートされますし、時流を捉えて世の中が求める新しい価値を発見する上では、経験が役に立たないこともあります。ですから経験よりも本当にやりたいと思っているか、情熱を持っているか、ということがすごく大事です。

PMになる人には、「自分が本当にそれをやりたいと思っているのかどうか」を大事にして欲しい。PMは誰よりもその事業やプロダクトについて考えないといけないポジションです。だから心からやりたいと思えないと考えきることができません。

僕はやりたくないことはやりたくないタイプなので、職業的なPMは向いていないと思います。「これはすごい価値がある。ぜひやりたい」という強い衝動が生まれたときは良い物を作れるんですが、そうじゃない時は難しい。僕自身はそうだし、他の人を見ていてもそう感じます。

― 情熱や衝動以外に必要なものはなんでしょうか。PMはコードを書けるべきか、という点が議論になることがありますが、PMにエンジニア経験は求めますか？

書けたほうがいいんでしょうが、要は自分の強みをどこに持つかです。自分の弱点を認識して、それをどう補うか。メンバーが弱点を補ってくれて、チームとして成果を担保できるのであれば問題ありません。ただそのためにはコミュニケーション能力や、思考のオープン性が求められます。

とはいえ、出来ることと出来ないことは知っておいて欲しいですね。実現性のないアイデアに価値はないと思っています。僕が自分でコードを書いていたのはもう十何年も前ですが、その後もずっとエンジニアがやっていることを横で見てきたので、最低限の概念や仕組みは理解しているつもりです。

もしコードが書けないことを弱みに感じているのであれば、1回勉強して何か作ってみるのはどうでしょう。「こういうプロダクトを作りたい」というアイデアがあるのであれば、自分でプロトタイプを作ってみて誰かに触ってみてもらうぐらいのことはした方がいい。それぐらいの情熱がないと、「作りたい」という気持ちは嘘だと思う。自分で作るのが難しければ、知り合いに頼んでもいい。自分のアイデアを何らかの方法で実現してみるという経験は、PMを志す人とって必ずプラスになると思います。

― ありがとうございました。