丹野簡単に言うと、「市場に適した製品を出荷する」のがPMの役割。世の中に出すだけなら誰でもできるかもしれませんが、ユーザーに使い続けてもらえる・求められているモノをつくることで、提供者側のビジネスを実現するのが仕事です。

組織によっては事業責任者とニアリーイコールの場合もありますが、事業責任者はビジネスゴールの達成、PMはユーザーの代表としてユーザーゴールの達成に軸足を置いていることが、役割として異なる点だと考えています。

そのため、PMの仕事は、ターゲットとする市場にはどのようなユーザーがいて、どんな課題を持っているのか発見するところから始まります。徹底したユーザー視点で“負”を発見し、それを生み出す問題構造を把握して、解決するために必要なソリューションを考える。その企画フェーズが終われば、開発チームと伴走してプロダクトを作ります。

よく、PMは企画することだけが職務の範囲だと思われがちなのですが、企画しただけではプロダクトはできません。開発途中に想定外のニーズが発覚したり、機能が矛盾したり、技術的に実現が難しい要件があったり。開発過程で起こるさまざまなことを開発チームとともに一つひとつ解決していくのもPMの役割です。

さらに、「作ったら終わり」ではありません。プロダクトの良さをターゲットユーザーに伝えるのもPMの役割。その手段はオンライン・オフラインのマーケティングもあれば、セールスや広報などと連携した取り組みもあります。

さまざまなチームを横断して、プロダクトの企画・開発だけでなく、ユーザーがプロダクトに魅力を感じ、使い続けるまでの責任を担うため、それぞれの職種と会話ができる共通言語を持つ必要もあるのです。

丹野そうですね。世の中にはいろんなサービスが次々と生まれているため、人の基本的なニーズは充足して、欲求がほぼ満たされている状態です。そうした状況で新しいプロダクトを作って、ユーザーに選ばれ、使い続けてもらうのは簡単ではありません。

プロダクトを作った後の、ビジネスとしてのゴールは、継続的に使ってもらい対価を支払っていただくことです。使い続けてもらうことで初めてビジネスが成立するので、本当にユーザーに愛されるものをつくらなければなりません。

そのためにも、以前にも増して自分がターゲットユーザーになりきることが重要だと感じています。ユーザーを特定したらインタビューをして情報を集め、その人になりきって世の中を眺めてみる。そのとき、どこに課題があるのか、価値があるのかを探すのです。

丹野もちろん、ターゲット属性と自分に距離があることは多々あります。だから、仮説が外れることはよくあること。外れたら再びヒアリングを重ね、ターゲットの課題や価値観と、自分の仮説は何が違うのかを考える、その繰り返しが重要ですね。

丹野最初のキャリアはNTTの研究所でロボットの研究をしていたのですが、次にジョインしたベンチャー企業での経験が、PMとしての原体験になりました。そこでは、コールセンターの業務効率改善、生産性向上、対応品質を向上させるためのシステムを作ったのですが、業務プロセスの分析、ヒアリング、設計、開発、導入、フィードバックを受けて改善、という一連の流れを「PM」という言葉を知らない頃から全部一人でやっていたんですね。

その結果、コールセンターの現場の働き方がガラッと変わったんです。今まである人が1カ月張り付いていた業務がなくなり、その人が本来やるべき別の仕事に時間を使えるようになった。大げさかもしれませんが、人の働き方や生活を変えたと思いました。

その後、サイボウズに入社して8年ほどPMに携わった後、ビズリーチに入社しました。

サイボウズとビズリーチの違いは、前者はグループウェアを作っているので日常的に自分たちの製品をいちユーザーとして使えるのに対し、後者は転職サービスのため自分たちで使えないこと。ユーザーとして何が欲しいかを日常的な経験から抽出できるのとできないのは大きな差でした。

もう一つ、違っていたのが、ビズリーチはデータドリブンの文化が強いこと。たとえば、スカウトの返信率、アクティブユーザー数、登録導線の突破率などを重視します。何かを改善するにあたって、数字をもとに分析する文化が強いんです。これまでユーザーのインサイトから発想するタイプだった自分としては、この文化から学ぶものが多くありました。

ですから、入社後は定性的なインサイトベースのやり方と、数値ベースのやり方をうまく混ぜて、社内になかったPMの役割を定義し、メンバーを育成することに努めました。

丹野最初の課題は、発想が「How」に寄ってしまうことでした。たとえば、アクティブユーザー数を増やしたいという課題があったら、新規ユーザーと既存ユーザーのどちらが定着しないのかを解き明かすのではなく、「通知メールを増やしてはどうか」などの対処療法的な考え方になる傾向があったんですね。

これは、たとえば具合が悪くて病院に行ったら、「顔色が悪いからお化粧しましょう」と言われるのと同じようなもの。そこで、原因を特定することから始める思考に変えていくことから始めました。

丹野ユーザー視点で考え、ユーザーのニーズやペインを自分事として捉えることの徹底です。そこができるようになったらペインを生み出す問題構造を把握し、問題を解決するためにどうすべきかをチームでブレストする。それを繰り返して解決策を見つけるプロセスを、チームに浸透させていきました。

丹野巻き込み力やファシリテーション能力は必須です。さまざまなステークホルダーをうまく巻き込めたとしても、人によって意見は異なります。「これが欲しい」とHowで言われた機能を全部そのまま追加しても、ユーザーは使ってくれません。

なぜその機能が必要なのかを分解して、シンプルなプロダクトにする必要があるので、いろんな意見をうまく集約し、問題を分析して解決策の合意を得ていく。この能力がなければPMは難しいと思います。

チームで問題を分析する際には、議論を可視化して整理できるホワイトボードの活用がおすすめです。巻き込んだ人は、誰もがそれぞれの視点で「いいプロダクトを作りたい」と思っているからこそ、激論になるケースが多々あるんですね。すると「あなたVS私」の構造になりがちなのですが、ホワイトボードに書いていけば、「解決したい問題VS私たち」という構造を作れます。

丹野そこである程度議論がまとまれば、まずはプロトタイピングを作り、みんなで客観視して、検証する。それを繰り返して、ようやくプロダクトのコンセプトが明確になります。

議論して検証する際に、PMが気を付けるべきは、自分の考えにチームメンバーを誘導しないことです。いろんな意見を検証しながらブラッシュアップしていかないと、いいものはつくれません。

それに、チーム全員が「何のために作るのか」を理解し、自分ごと化した状態でプロジェクトを進めなければ、開発途中で開発者が「違うかもしれない」と気付いても、声が挙がってこなくなるんですね。都度、軌道修正しながら完成させないと、結局ユーザーにとって役立つプロダクトにならないのです。

丹野提供者側の都合ばかりを考えてプロダクトを作ってしまうことです。もちろん、営利企業なので売上を上げる必要はあります。しかし、そこに引っ張られ過ぎてしまうと、自分たちが作れるモノ・作りたいモノ・売りやすいモノを作ってしまいがちなのです。

逆に、ユーザーの要望を聞きすぎてしまうと、それらをすべて詰め込んだ、複雑すぎて使えないプロダクトをつくってしまうケースもあるでしょう。ビジネスゴールとユーザーゴールのバランスを取るのが重要ですね。

それから、エンジニアやデザイナーの算出した工数見積を無理に圧縮して押し付けるのもNGです。仮に3ヶ月で作らないといけないプロダクトがあるとしたら、その期間内で実現可能な機能セットになるよう、シビアに優先順位を見極めるべきです。

丹野デザイン思考、システム思考、リーンスタートアップ、アジャイル開発、問題解決のフレームワーク、ファシリテーション、マーケティングなどに関する本を読むことをおすすめします。多岐にわたる分野ですが、それら全領域が「55点」分かる状態になるのが、PMとしての第一歩ではないでしょうか。

そうして初めて、各領域のプロフェッショナルたちと会話ができる知識が身につきます。ただ、問題解決とファシリテーションは誰よりもできる必要があります。

PMとして鍛えられるのは、立場が異なる複数のユーザーが利用するプロダクトをつくるケースです。ビズリーチのようなtoBとtoCの両方が重なる事業は、その一つの例。たとえば、弊社が提供しているスカウトサービスの場合、採用企業の立場では優秀な方にスカウトメールをたくさん送りたいと思うでしょう。でも、受け取る側からすると、1日に何十通もスカウトメールが届いたら対処しきれません。

B側には良いことがC側にはネガティブにならないよう、両方の話を聞いて、両方の課題を解決する最善のアイデアを見つける必要がある。こういった環境で経験を積むと、絶妙なバランス感覚を養えるので、強いPMになれるのではないかと思います。

いずれにしても、ユーザーに愛され、使い続けられるプロダクトをつくれたら、ユーザーの生活習慣や、業務プロセスを大きく変えることができます。その大きな変化を生み出せるかどうかは、PM次第。これが非常に大きなやりがいであり、醍醐味だと思っています。