ジュニアPMを育成するには？馬田隆明氏が語る、プロダクトマネージャーの育成方法とその評価

国内でも少しずつ根付きつつあるプロダクトマネージャー（以下PM）という仕事ですが、こと育成となると、まだまだ明確な教育方法が確立されているとは言えない状況です。

そこで、今回ウェブエキスパートドラフトでは、マイクロソフトでPMを経験後、東京大学で教鞭を執りながらスタートアップ支援活動を行っている馬田隆明氏にインタビューを実施。前編となる本記事では、企業でのPM育成と、成果をどう評価していくかにフォーカスした内容をお送りします。

«後編はこちら»

東京大学産学協創推進本部　
東京大学本郷テックガレージ・ディレクター
馬田隆明
University of Toronto 卒業後、日本マイクロソフト株式会社にて Visual Studio のプロダクトマネージャ、テクニカルエバンジェリストとして数多くのスタートアップを対象に、技術面とビジネス面での支援を行う。現在は東京大学にて学生や研究者のスタートアップ支援活動に従事。

ジュニア PM をどう育成していくか

―さっそくですが、PM の育成に悩んでいるという声をよく耳にします。馬田さんはジュニアPMを育てるにはどうしたらよいと思われますか？

馬田： そもそも、会社としてどういった PM がほしいのかが明確になっていないと育成はできないと思います。まずは会社側が、海外の例などを参考にしながらジョブディスクリプション（職務記述書）をちゃんと書くところからでしょうね。

加えて、エドガー・シャインが提唱しているようなロール・マップを書いてみると良いかもしれません。たとえば PM なら、 PM に関わる社内外の利害関係者をすべて挙げてみて、その人たちに PM への期待を挙げてもらうという人間関係を中心に考える方法です。

ジュニア PM 自身が、PM に必要な能力をどう伸ばしていけばよいかについては、『ストラテジック・キャリア ― ビジネススクールで教えている長期的キャリア戦略の7つの原則』という本にも書かれていますが、「もし自分がそのポジションの上司を務めるとしたらどんな人を採用したいか」を考えてみるといいと思います。それが理想の PM 像となるので、そこと今の自分とのギャップを埋めていくという方法です。

こうして視座を上げて、何が自分に足りないのかを自分で考えてみるというのは、ジュニアPMの方はやっておくといいのではないかと思いますね。

―上司とはどのくらい上の人のイメージですか？

馬田： マネージャー、できれば自分の二個上レベルのポジションから見てみると良いと思っています。スタートアップなら社長のポジションから見た理想の PM ですかね。 PM の仕事はやることが多いぶん、チーム全体としてみれば誰もカバーできていない空白地帯も多いです。プロダクトマネジメントトライアングルを参照いただくと分かりやすいのではないかと思います。

以下は私が使いやすく抽象化したものです。

馬田： この各領域のうち、プロダクトチームに足りないものをカバーするのが PM の役割です。そしてチームや状況が変わると、 PM の果たすべき役割はどんどん変わっていきます。例えばデザインがボトルネックなら、 PM がその役割をするか、デザインができるような人材をリソースとして借りてくる。チームにデザイナーが入ったら、デザイン以外のボトルネックになっている部分をカバーする。メンバーが増えてきたら、メンバー間の利害調整も PM の役割になります。

見ていただいたらわかるように、非常に多くの領域についての能力を求められます。そして、高いコミュニケーション能力と信頼される力が必要になります。

私の経験から言うと、チームにはこのプロダクトを中心とした空白地帯が必ずあります。完璧なチームなんてないですしね。その中で、実は必要とされているのに誰も手が回っていなくて、そして自分のケイパビリティ（＝能力、素質、強み）が一番活きる部分を見つけて飛び込んでいくのは、自分の能力を伸ばすうえでも、チームの信頼感を醸成するうえでも有効だったと感じています。

私の場合は数字やリサーチに強かったこともあり、周りに比べて自分の経験がない中で自分の意見を通すにはデータに基づかないと難しいと考え、リサーチ系の手が回っていなかったところを進めていって、そこから仕事が増えていきました。

初期値はランダムに取り、登るべき山を見つける

―領域が広い PM だからこそ、満遍なく能力を付けてきており、このあと何を目指すべきか悩んでしまうという話も聞くことがあります。自分のケイパビリティが活きる場所をうまく見つける方法はあるんでしょうか？

馬田： 何を伸ばすべきか分からないなら、探索して実験していくしかないと思います。たとえばサイドプロジェクトを始めてみるとか。それは個人であってもよいし、社内の別プロジェクトへの貢献でもよいでしょう。

―実験する際、伸ばす能力はひとつに絞るほうがおすすめですか？

馬田： 時間を決めてやってみて、ダメだったら考え直す、がいいんじゃないでしょうか。以下は、「探索アルゴリズムをキャリアに応用してみる」という記事で書いたキャリアの話です。

馬田： 詳細は記事を読んでいただければと思いますが、例えば山登りをするのに、このように山がふたつあったとします。もし初期地点が低い山に近い場合、単純にそこから上へ上へと登っていった場合、最も高い山を知らないまま、小さい山の頂上で探索が止まってしまいます。つまり局所的な最大値しか得られません。

これを避けるために、初期はランダムにいくつか点を取り、その中で一番高い地点から上に行くように動くとよいとされていて、これはキャリアにおいても応用できるんじゃないかと思っています。自分の伸ばすべきケイパビリティを探すために、この考え方で初期地点をランダムにとり、実験していくのが良いでしょう。

体系立てて教えるか、疑似体験させるか

―なるほど、わかりやすいですね。では今度は育てる立場から見た場合について教えてください。たとえばジュニア PM をカオスな現場に放り込んでがむしゃらにやる体験をさせる方がよいのか、体系立てて順々に教えていくのがいいかでいうと、どちらがよいとお考えですか？

馬田： 人によってベストな学び方は違うとは思いますし、そもそも教育手法は「体系立てた講義」か「疑似体験」の二択ではないと思います。どの教育手法を選んでも「教育すれば何かしら効果がある」のは当然で、問題なのは「どの教育手法が効果的か」という点です。

そうした文脈で言えば、教育の分野では、一般的に有効だと思われていた教育手法が実はそこまで効果的ではないという分析結果が出てきていたりします。たとえば宿題はゼロか1かであれば教育効果はあるので1だけれど、他の教育手法に比べるとそこまで効果的ではない、といったようなものです。

こうしたデータはようやく日本でも翻訳されだしたジョン・ハッティという人が行っている教育手法分析から取ってきたものですが、この数字が0.4以上になると教育手法として効果的だと言われています。

これは1,200以上のメタ分析をベースを統合して、学生の学力に影響を与える要因や教育手法の効果を示したデータです。これを見てみると Teacher Clarity （教師の明晰さ）や Teacher Credibility （教師の信頼性）が高ければ効果も高くなりますが、課題ベース（ Problem-based learning ）の教育手法の効果はそこまで高くありません。宿題も0.29と実はそこまで効果的ではないようです。もちろん、これはあくまで学校教育という分野での研究でしかありませんが、社会人の学習でも参考にできる部分は多々あるのではないかと思います。

私は今東京大学で講義をするときには、このデータを参考にしながら、実施コストに見合った教育手法をできるかぎり選択するよう考えています。はやりの「エビデンスベース」というわけではありませんが、企業教育で使えるところもあると思いますね。

―体系立てられない PM の知識を教える場合に、大事なことはなんですか？

馬田： 私はマイクロティーチングに近いメンタリングが一番効果的だと思います。

―それはなぜでしょうか？

馬田： 会社の考え方や文化、そこでの経験など、会社によって違う部分があると思うんですよね。これは会社で働く上でとても重要なことです。これらを学ぶという意味では個々人の暗黙的な知識体系を徒弟制度的に教えてもらうのは良いと思います。

私の経験で言うと、 Visual Studio の PM として働いていたときは近くに何でも聞ける先輩たちがいたのですが、そういう人がいるとすごく成長の進みがよかったと感じます。プログラミングでも、やっぱり近くになんでも聞ける人がいれば学びが早まるじゃないですか。そういった周囲の環境があるかが、伸びるかに関係してくると思います。実際、先ほどのハッティの研究でも、フィードバックは学習に有効だとされています。

また、私の場合はだいたい5人くらいの PM でやっていたのですが、それぞれキャラクターが違ったのも大きいですね。これはあの人に聞けばよい、など誰が何を知っているのかを把握しやすい環境でしたし、自身のやり方や考え方の言語化が上手な先輩がたくさんいたので、そのそばでたくさんの異なる視点や方略も得られました。その結果、「あの人だったらどう考えるだろう」といったような自己質問のパターンを作れました。

ハッティの研究によれば自己質問は学習にも効果的です。結局、自分が一番話す相手って自分自身なので、自問自答のヒントを周りからたくさんもらえたのはありがたかったですし、振り返ってみると、いわゆる「自己調整学習 ( self-regualted learning )」がやりやすい環境だったのかなと思います。

―環境が重要ですね。ただ社内の他の PM が少ない場合は厳しいですね…。

馬田： その場合、たとえば私は以前、 Microsoft で「プロダクトマネージャーとは」というテーマでレポートを書くために、社内の別チームの PM 20人くらいにインタビューして回ったことがあります。それがとてもいい経験になりましたね。なかなかそういう先輩方に時間を取ってもらうのは気が引けたのですが、そうした理由があれば誘いやすいなと感じましたし、それが最終的には社内人脈にもなりました。

もちろん会社やプロダクトによって違う面がありますが、同じように社外の PM に話を聞きに行き教えてもらうことで得られるものはあると思っています。たとえば「こういう PM コミュニティに役立つアウトプットを出そうとしているから、少しだけお話し聞かせてください」と言えば社外の PM の人も協力してくれやすくなるかもしれません。

それに、「残酷すぎる成功法則」でも引用されていますが、何らかの分野の第一人者になるには良きメンターにつくことが重要だと言われているそうです。また職場でのメンターシップよりも、自分で見つけてきた非公式なメンターのほうが効果的だったという調査もあるようなので、複数人の非公式なメンターを社外に持つことは PM にとっても良いのではないかと思います。

―ちなみに、伸びる人と伸びない人の違いは事前にわかりますか？

馬田： 成功するプロジェクトの傾向自体は記事にまとめたことがありますが、事前にということだと、なんとなくこの人は期待できそうだなくらいで、ハッキリとはわかりません。ですが、一度やってみてもらって、失敗が続いてもプロジェクトを3回くらいやるとコツが掴めてくるという印象がありますね。

私の担当している施設では、だいたい2ヶ月くらいの技術的なプロジェクトを学生のみなさんにやってもらっているんですけれど、早い人で半年間合間なくプロジェクトを3回やって、ようやく自分のやりたいプロジェクトと、マーケットに受け入れられるようなプロダクトがマッチしはじめるような感じです。

―具体的にはどんなプロジェクトなのですか？

馬田： 光るドローンや、できたての鰹節を削って出汁をつくる出汁メーカーなどですね。ソフトウェアだと名探偵コナンが付けているような変声機のシステムをディープラーニングを使ってつくったチームもいます。

ただ、もちろん何度やってもプロダクトを作れない人もいます。なぜできないかというと、顧客が欲しがるプロダクトではなく、自分のつくりたい、自分がいいと思うものをつくり続けてしまっているため、という印象です。もちろん自分の技術を磨いて、自分が面白いと思うものを作り続ける生き方も良いと思うので、無碍に否定するつもりはまったくありません。

サポートしつつ意思決定は委ねる

―そのプロジェクト、すごくおもしろそうですね！ 企業で行う場合は、最初に体系立てて教えた後、トライできるプロジェクトを3回くらい経験させると良いというイメージでしょうか。

馬田： そうですね。その際は小さなゴールやマイルストーンを設けながら進めるといいと思います。そしてその際重要なのは、コンテキストをきちんと見てあげることと、意思決定をしっかりと任せること。アドバイザーとしてメリットやデメリット、こういう選択肢もあるよと教えはしますが、「最終的に選ぶのはあなたです」と伝えることです。

―意思決定のやり方について何かアドバイスはあるでしょうか。

馬田： そうですね、スタンフォード大学ハース教授の著書『決定力！　正解を導く４つのプロセス』によると、「選択肢を広げる　( Widen your options )」「リアリティテスト( Reality test your assumptions )」「いったん距離を置く( Attain distance before deciding )」「失敗に備える(Prepare to be wrong)」という4つのプロセスを考えながら意思決定するといいと言っています。意思決定の仕方や認知バイアスの逃れ方などは、なかなか体系だって学ぶ機会がありませんから、こうした手法を聞くと新鮮に映るようです。

―なるほど。ではそんな中でも、プロジェクトに取り組んでいる人がよく躓くポイントはありますか？

馬田： 顧客のところに持っていけと言っているのに、なかなか持っていかないことでしょうか（笑） あまりそうした経験がないので億劫なのか怖いのか分かりませんが、単に慣れていないだけのような気もします。人と話すのが苦手で、営業なんてしたくない、という面もあるかもしれません。ただ私が今見ている学生は基本的に工学部の生徒なので、そのあたりはちょっと間引いて考えていただければと思います。

PM の仕事をどう評価するか

―育成の話の一方で、 PM の評価についても悩むという声も聞くことがあります。評価はどうすればよいとお考えですか？

馬田： OKR （ Objectives and Key Results ＝目標と、カギとなる成果指標の集まり）のようなプロセスを用いて、きちんと設定することでしょうか。

その理由として、ブルーオーシャン戦略で有名なチャン・キム教授の提唱する『フェアプロセス』という概念を引用すると、人はプロセスにも納得できないと、結果が満足のいくものでも不信感を持ってしまって、やる気を失うそうです。 OKR はその点、フェアプロセスの 3 E ( Engagement, Explanation, Expectation Clarity ) の原則を満たすようなプロセスを実施しやすいので、評価を受ける側に不必要にモチベーションを低下させる可能性が低いのではと思います。

ただ Key Result の設定が難しい印象があります。そんなときは例えば社会的インパクトの分野には「インパクトチェーン」や「リザルトチェーン」とも呼ばれるロジックモデルも使えるかもしれません。このチェーンでは「 Inputs 」「 Activity 」「 Output 」「 Outcomes 」そして「 Impacts 」といった流れになっています。こうした抽象度で分けてみると、完成した結果（ Output ）で見るのか成果（ Outcome ）で見るのかをきちんと設計してあげないといけません。

OKR の場合、O＝目標（ Objectives ）を設定してから、その達成に必要な KR ＝成果指標（ Key Results ）が決まりますから、こういったロジックモデルや流れの全体像を踏まえて考えないと設計しにくい印象がありますね。このあたりは、最近翻訳されたクリスティーナ・ウォドキーの OKR の本や、Google に OKR を紹介した投資家の John Doerr が書いた 「Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs」 あたりを参考にしたほうが良いと思います。

ただ評価については、 PM に売上責任まで持たせるのかという点は決めておいた方がいいとは思います。プロダクトのどこに重点を置くかが決まらないと評価も難しいですし、結局のところやはり組織設計の話になってしまうんじゃないでしょうか。

―どうするかは「会社ごと」に方針を決めないといけないと。

馬田： 組織の方針で、 Key Results をどう設計していくかについては分解していけばいいだけの話といえばそうなんですが、正直なところ評価は組織設計とインセンティブ設計の問題だとも思うので、 PM の評価が難しいというよりは、評価全般が難しいといった感じでしょうか。

私がいたころの Microsoft では必ずゴールが数字に紐付いていましたね。ただ評価制度って時流によっても変わりますし、採用や従業員継続率にも関わるので本当に難しいですよね。

―人事評価は難しい、それにつきますね。

馬田： ただ、最近だと Google が re:Work というサイトで、彼らがどのように採用からチームビルディングを行っているのかの情報を公開しています。さらに OKR についてはツールキットまで公開していて、これらの情報は参考になるかもしれません。

あと、私は評価制度の中に「人にちゃんと教えたかどうか」を入れている企業が好きですね。それは後任を育てて組織を育てるということでもありますし、本人にとっても誰かに教えるという経験は自分が学ぶ経験にもなるので、「教える」を評価するというのは個人的にとても良いと考えています。

«後編はこちら»