プロダクトマネージャーの育成に必要な2つの要素
――確かに既存のメソッド、フレームワークなどは重視されがちですが、目的を取り違えてしまうと、元も子もなくなってしまいますね。
坂田：そうですね、効果があると思われるものなら何でも使えばいいし、それがジョブ・ディスクリプションにないものだっていい。市場変化に合わせて「プロダクトの成功」も再定義してもいいと思います。プロダクトマネージャーはこんなセット！ と決めた途端にルーティンになり、金太郎飴のような量産型になってしまうのが怖いですね。自分もUXデザインの経験者なので先入観がないわけではありませんが、起点はともかくとして、プロダクトの成功を純粋に考えて行動し、勉強をし続けながら、自分なりのプロダクトマネージャー像を描いて進むこと。それしか本当の意味でのプロダクトマネージャーになる道はないように思います。
――これからプロダクトマネージャーとして働いていく人にはぜひ受け取って欲しいメッセージですね。ただ、組織の中には、再現性を持ってプロダクトマネージャーを育成したいニーズがあると思います。
坂田：その機運が高まっているのは私も感じます。その時に”プロダクトマネージャーセット”を学ばせるのは一見効率的に見えるかもしれません。ただし、そこ実感が伴わないとしたら徒労に終わると思います。
よって、いきなり1年目からプロダクトマネージャーとするのは難しいでしょう。器用な人ならツールやメソッドを使って一見”回す”ことはできるかもしれません。しかし、それが「何のためなのか」が腹落ちしてなければ、チームが気持ちよく仕事をしたり、価値を発揮したりすることができず、プロダクトの成功からは離れてしまうと思います。そこで、まずは何かしらその人なりに養っておきたい視点や特技とするもの、専門スキルを身につけることから始めるとよいでしょう。そこで何らかの意志が見えてくれば、そこを起点にプロダクトの成功のために自分が何をすべきかが見えてくる。そうすれば周囲もサポートしやすくなるはずです。
現在はエンジニア出身のプロダクトマネージャーが多いですが、それはサービス全体の仕組みやアーキテクチャなどを知っていて開発に生かしやすいからではないかと思います。私も含め、デザイナー出身のプロダクトマネージャーは少数派です。でも、強みが異なるだけで、誰もがどこかしら欠けていて、全部において強くなる必要はないと思います。足りない部分を、透明性をもって周知し、自身の勉強やメンバーのサポートで補完する方法を見出そうとすること。それができれば、チームは機能していくと思います。いわば、プロダクトマネージャーは本人の在り方だけでなく、周囲のサポートという環境があって成り立つものなんです。
そう考えると、組織でプロダクトマネージャーを育成したいと考えるなら、一定の専門スキルを持ちプロダクトマネージャーを志向する人をチームとして支え、経験を積ませていくというのが理想的ではないでしょうか。その時に、その意志は「プロダクトマネージャーになる」ではなくて、「プロダクトマネージャーになってどうしたいか」が大切です。
「ミニCEO」での失敗を経て、チームを生かすように
――プロダクトマネージャーの姿のひとつとして、近年「プロダクトマネージャーはミニCEOだ」という表現を見かけることもあります。
坂田：確かにプロダクトマネージャーの肩書きを持つ人にお会いすると、ミニCEO的に振る舞われる方が多いです。おそらくこれは因果関係が逆で、組織でプロダクトマネージャーをアサインしようとすると、そうした人になることが多いからではないかと思います。プロダクトマネージャーという職種がなかった時代に、プロダクトを成功まで導く人となれば、必然的に管理職が適役と考え、その人の経験や実績で調整することが多かった名残ではないかと。絶対的な存在として「CEO的に意思決定して下に降ろす」というスタイルですね。
でも、私はPivotal Labsの1年目で「ミニCEO」になろうとして大失敗したこともあり、この考え方には反対です。私の場合は、プロダクトマネージャーだからと張り切って、無理にチームを引っ張ろうとしました。自分の弱いところに気付きながらも、他のメンバーに補ってもらうという意識に至らず、かなり頑なでした。プロダクトにおいてはエンジニアやデザイナーを起点として生かした施策が有効であることが多いし、生かすべきだと思っています。だからプロダクトマネージャーとしては、チームメンバーの心理的安全性を担保し、自由に意見交換ができるような環境を整えることが重要だと考えています。
ミニCEO的な振る舞いだと、上から下へのコミュニケーション形態となり、チームメンバーが「プロダクトマネージャーの意思決定を待とう」と受け身になりがちです。特に日本文化は縦割り社会ではそうした関係に陥る可能性が高いです。上下のコミュニケーションは楽かもしれませんが、よりよいプロダクト開発のためにはできるだけ避けるべきでしょう。まずはプロダクトマネージャー自身が上下のコミュニケーションに陥らないよう意識し、むしろ一歩下がるくらいで自由にやらせて、ちょっと道を誤りそうな時に踏み込むくらいが丁度いいのではないかと思います。そのほうがみんな生き生きとしていいものができます。
――プロダクトマネージャーがコミットすべきゴールとして「プロダクトの成功」をあげられていますが、その成功というのはどのようなものとお考えですか。
坂田：いい質問ですね。プロダクトの目的いかんによると思いますが、まさにそれを考え続けることがプロダクトマネージャーだと思います。いわばプロダクトの成功に圧倒的にコミットし、こだわるからこそ、何をもってプロダクトが成功したというのか、考え続けるわけです。「成功とは何か」と自問自答を続ける中で、さまざまな可能性や選択肢を探っていく。そして、できることは何でもする。それが何より重要だと思っています。
そしてもうひとつ、私が重視しているのが、「チームとしての成功」です。チームが満足できているか、お互いを尊重しながら気持ちよくプロダクトを開発できているか、その環境を維持できているかということですね。両方があってこその「プロダクトの成功」といえるわけで、どちらにも100%の力を注いでいます。
経営層からチームまで、プロダクトマネージャーのコミュニケーションの取り方
――プロダクトの成功とチームの成功を両立させるために、坂田さんが意識されていること、工夫されていることをお聞かせください。
坂田：チームがプロダクトを作るので、まずチームを成功させるための方法として、まず私が大切にしているのは、ソロワークをできるだけ減らし、共に作業するスペースと時間を多く確保することです。各人のナレッジやリソースの集積がいいプロダクトを生むならば、横の連携をしやすい環境づくりが必要です。そこで、ワークショップをはじめ、ユーザーインタビューも、その分析作業も、いろんなアクティビティを随所に設けて一緒に行うようにしています。一見非効率に見えるかもしれませんが、それによって圧倒的にコミュニケーションコストが下がり、文脈も失われずに済みます。結果として、いいアイディアが生まれ、スムーズに実現しやすくなるんです。
そしてもうひとつ、各人の責任を明示することも重視しています。たとえば、デザイナーはユーザーを深く理解すること、エンジニアは実現可能性や最適技術を担保すること、そしてプロダクトマネージャーは両者のバランスを取りつつ、プロダクトの事業的成功に責任を持つこと。それぞれを明示しておくと、たとえ仲が悪くても連携ができるし、意見が食い違っても相手の役割や背景を理解した上で議論ができるんです。
元サッカー日本代表チーム監督の岡田武史さんが、「選手には、共感や信頼なんてなかなか生まれないから、お互いに存在を認め合うだけでいい。今まで全員仲良しなチームなんてなかったけど、"こいつは未だにどうもソリが合わないけど、パスしたら絶対決めてくれる"って思える関係性なら強いチームになる」っておっしゃっていて、我が意を得たりでしたね。
――経営層やビジネス側との付き合い方としてはいかがでしょうか。「翻訳」という言い方もされていましたが。
坂田：開発が走り始めたらそこに注力していくことになりますが、組織にいるプロダクトマネージャーの場合、プロジェクトが始まる際に上から「Why」や「What」が降ってくることが多いと思うんです。反発することが面倒故にそのまま受け入れてしまう人も多いと思うのですが、そこは改めて自分の中に取り込んで違和感や疑問があれば、とことん納得できるまで聞くことが大切だと思います。そして、成功しないと思ったら正しく反発する。そのためにも自分の中に常に「Why」や「What」への感度は高めておく必要があると思います。プロダクトの成功という意味で、プロダクトマネージャーはチームを納得させる責任も負うので。
そこでやはり必要になってくるのが「翻訳」のスキルで、そのためにシンプルなフレームワークを使うことは有効だと思います。たとえば、ビジネスやプロダクトのゴールを可視化し、その上で実装する機能に優先順位をつける必要がある場合、ビジネスとしての価値を縦軸に、ユーザーとしての価値を横軸として整理し、その議論に時間を費やすことが多いです。たいてい「両方高い」となるので、「本当に重要ですか」「こっちとこっちはどっちが重要ですか」と削ぎ落としていく感じですね。
フレームワーク自体はシンプルですが、ファシリテーションにはコツがあります。「なぜそれが価値が高いと思われますか」「どちらが高いと思いますか」など、できるだけシンプルで強めの問いを投げかけていきます。これをけっこう上層部の方にも行っていきます。そこで自信がない、データが曖昧であるなら、それを明確にするための調査など、次のアクションへとつなげていきます。いちばん大切なのは「嫌われる勇気」でしょうか。
プロダクトを継続して育てていくために
――近年、縦割りといわれる大企業でもプロダクトマネージャーも含めた開発組織を内製化するところが増えてきました。その際に気をつけるべき点についてアドバイスをいただけますか。
坂田：組織としては受発注の関係になりがちなので、できるだけ開発部門に裁量や権限を与えて自由に作らせるようにしたほうがいいと思います。というのも、やはりプロダクトチームのほうがユーザーに近く、理解しているので、そのほうがいいプロダクトができるんですよね。またチームメンバーは移動させないほうがいいでしょう。大企業ほど異動が頻繁ですが、その度に培ってきたナレッジがリセットされ、チームの関係性も再構築する必要があるため、プロダクト開発のスピードも品質も低下する可能性があります。プロダクトは昔と違ってソフトウェアであり、生きたものとして作り続ける必要があります。そのためにもできるだけチームメンバーは変えないほうが望ましいと思われます。
――プロダクトは生き物ということですが、市場にフィットするプロダクトを作り続けるために、プロダクトマネージャーの具体的な実践についてお聞かせいただけますか。
坂田：リーンスタートアップの手法である「ビルド・メジャー・ラーン（BML：Build Measure Learn）＝作って、検証して、学び考察する」のサイクルをいかに速く回していくか。そこにフォーカスして取り組むこと、そのスキルこそ大事だと思います。それは、仮説をたてて検証し、得られた学びをプロダクト開発に生かして、次のリスクを解消するために前に進む、そしてその精度を高めていくことが大切です。そのためには仮説を立てるスキル、検証スキル、検証から学んで蓄積するスキルなどが必要でしょう。そして、もうひとつ「変化を楽しむ」というマインドは大切ですね。すぐにうまくいくことはないですから。
そして、プロダクトが一定成功し、収益が上がってきたところで、大きくしていくためには、まずは既についているユーザーがどこに価値を見出しているのか、知ること、発見することが大切だと思います。その際に新しい価値や改善すべきところを見つけたら、そこをまた仮説を立てて検証していく。ユーザーに寄り添う時間を増やしていくステージといえるかもしれません。そこで価値が市場にフィットしているという確信が持てたら、マーケティングなどの顧客開発に予算を投じるなど拡大のための施策にシフトするわけです。最初はスモールにスタートすることで、深く細かく分析することができますよね。ユーザーの母数が多くなればなるほど、見えにくくなることも多いので。
――最後にプロダクトマネージャーになった人、なろうとしている人にメッセージをいただけますか。
坂田：「ミニCEO」になろうとしなくていいんです。意気込まず、疑問があったら素直に聞く、シンプルに物事を考える。嫌われる勇気を持ちつつ、価値あるものを作ろうとしている人を信じましょう。プロダクトを成功させることに集中して、いいものを作っていきましょう。
――力強いお言葉をいただきました。本日はありがとうございました。
