00:01
皆さんこんにちは、クライス&カンパニーの山本です。 この番組では、プロダクトマネージャーのキャリア全般についての情報を発信してまいります。
今回は特別ゲストとして、なんと各種イベントでも大人気 エムスリーのVPoP山崎さんにお越しいただきました。
よろしくお願いします。 よろしくお願いします。
では、もう早速なんですけども、山崎さんに今回どんどんお伺いしていきたいなと思ってるんですが、
まずテーマなんですけども、プロダクトマネージャーの組織について、 いろいろお伺いしていきたいなと思っています。
組織についてなんですけども、山崎さんの思う理想のPM組織、 プロダクトマネージャー組織ってどんなのかって伺ってもいいですか?
なるほど。面白い質問ですね。 これはやっぱりその事業形態とか、やっぱり事業がターゲットしている領域、
もしくはそのプロダクトの形によって、やっぱり様々だと思いますね。 これが答えだっていうのが一つ用意されているわけじゃなくて、
その自分の事業の形態に最も適した組織を作り上げるべき。 おそらくこれチームのパターンっていうのが、
組織パターンですね。っていうのはあるんだと思うんですけど、 まだやっぱりプロダクトマネジメントの世界って、
まだまだ未成熟な段階なんで、 これ今後はこういう事業にはこういう組織っていう、そういう考え方が出てくるんじゃないかなとは思いますね。
かなり事業によって違うと。 おそらくそうなんじゃないかっていうのが今の仮説ですね。
我々もいろんな会社さんのインタビューさせていただいていく中で、 例えば事業部の中に入っている、
例えばバーティカルの中の組織の中に、 セールスもプロダクトも一緒に入っちゃってるってことで、
縦に繋げているようなものもあれば、 プロダクトマネジメントと後はエンジニアチームを一緒にして、
開発チームみたいな感じで横で横断にしている場合と、 あとエンジニアチームはまた別にいて、
もうプロダクトマネジメント組織っていうのを横だけ置いてたり、 なんとなくそんなパターンがあるんじゃないかなと思ってるんですが、
それぞれどういう事業体だと合うとかってありますかね?
そうですね。一番の違いになってくるのは、 その企業が元々持っているアセットですね。
どう活用しようとしているかによって、 だいぶ変わってくるんじゃないかなと思います。
分かりやすい例で言うと、 例えば本当に一からプロダクトを作っていくスタートアップ組織、
その中でのプロダクトマネジメントの組織的な考え方と、
我々M3のような既に大きいアセットがあって、 それを活用しながらプロダクトを伸ばしていく、
サービスを伸ばしていくような考え方だと、 そこには差はあるような気がしますね。
M3さんって過去から振り返って、 プロダクトマネージャーの組織形態って変わってきてるんですか?
03:03
そうですね。模索しながらやってるっていうのが正直なところですね。
M3の場合は社内に大きく分けて、 2つのプロダクトマネジメント組織があるので、
そこによっても役割というのは違いますね。
もし可能だったら、過去のM3の組織、 今の組織にどういう違いがあるのかって教えていただけますか?
そうですね。すごく簡単に説明すると、 M3.comを中心とした従来のM3のアセットを
最大活用する制約プラットフォームグループを 中心としたプロダクトマネジメント組織と、
もう1つが昨今のSaaSやアプリ、そういったものを できるだけ素早く立ち上げていくための
エンジニアリンググループ内の プロダクトマネジメント組織みたいな、
大きくは2つの考え方をうまく融合させながら、 この2つの組織もコラボレーションするので、
そういった取り組みをしてますね。
今の1つ目の2つ目の組織ってどう違うんですか?
エンジニアがいる、いないとか、 ビジネスチームと分かれている、分かれていないとか、
そういう違いはあるんでしょうか?
大きな本質的なところでは、そのプロダクトを、 いわゆる顧客が喉から手が出るほど欲しくなるような
プロダクトを開発していく、そういった意味では同じです。
究極のゴールは同じです。
ただ、微妙なところではいくつか差があって、
先ほど申し上げたM3のアセットを最大化していく、
そのM3.comを中心としたチームっていうのは、
プロダクトマネージャーだけが所属する 組織になってるんですね。
その組織のメンバーが、例えばビジネスサイダーだったり、
例えばエンジニアだったり、例えばデザイナーだったり、
そういうところと部門間のコラボレーションみたいな、
実際にはプロジェクトチーム編成みたいなことは されるんですけれども、
そういった形で編成されるところに向いている 組織形態を取っています。
一方で、エンジニアリンググループ内にある プロダクトマネージメント組織っていうのは、
ほぼエンジニアと近い同じ組織にいますので、
エンジニアQAとより近い立場で仕事ができる。
大きい会社だと、事業側付きのプロダクトマネージャーと、
プロダクト開発チーム付きというか、 エンジニアリング付きというか、
そこのプロダクトマネージャーと 両方いるケースってあると思うんですけれども、
そういった考え方がイメージには近いかなと思います。
なんで高校者のエンジニア系のチームだと、
それはSaaSとかスタートアップ系の 新規プロダクト系に向いてるんですかね。
06:01
なんでなんですかね。
必ずしも新規プロダクト系に向いているっていう話というよりは、
その時に有利になる点が多いっていう話ですね。
特徴ですね。いくつかの特徴があるんですけれども、
一つはエンジニアリングバックグラウンドを持っている
プロダクトマネージャーが所属しているケースが多いっていうのが
一つ目の理由で。
もう一つは、例えば01の立ち上げの時とかって、
例えばインフラ整備が必要で、
インフラの中に例えばAWSだったりGCPだったり、
そういったかなりテックをコントロールしなきゃいけない、
そういう話とか含まれたりするので、
そういう意味で自分がエンジニアリンググループの中にいるってことは、
非常に早く動ける重要な特徴になったりはしますね。
なるほど。立ち上げが早くなるチーム編成になってるってことなの?
そうですね。普段から接しているのがエンジニア組織の中で働いてますから、
エンジニアと二人三脚っていうのがより強く出るっていうことですかね。
ただそれぞれにやっぱり特徴があって、
かなりM3の場合はどっちの組織でもハイレベルなチーム間の融合、
つまりエンジニアとのコラボレーションっていうのは行われてるんですよ。
その前提でさらに磨き込まれてる。
98点か99点間の違いみたいな。
なるほど。
そういった磨き込みの違いだと思いますね。
逆にその既存事業というか、もう既に大きいアセットを持たれてるM3.comの方は、
プロダクトマネージャーのみってことだと思うんですけども、
そこにエンジニアが入ってない意味ってどういうことがあるんでしょうか。
いろいろな考え方があるんですけど、
まず目標としている金額感は全然違いますね。
そういった既存のアセットをうまく活用していく製薬プロットフォームなどは、
目標金額が100億円とか500億円とか、そういう形になってくるんですね。
エンジニアリングの中にあるチームっていうのは、
もちろん将来的にはそういった500億円規模を目指していくんですけれども、
まずは1億円、10億円っていう話からスタートすることが多いので、
そういったビジネスに対する規模感みたいなものも違いとしてあると思います。
そうなった時に、どちらのチーム編成も、いわゆるビジネス側っていうんですかね。
事業開発だったりとか、セールスの人たちとタッチすることはあると思うんですけども、
それぞれの組織体によってビジネスの人たちとの関わり方って変わってくるものなんですか。
基本的にそこは全く変わらないですね。
基本的にプロダクトマネジメント組織以外に、事業開発の組織、
ビズサイドと呼べる事業があって、そこをどう説明するのが分かりやすいのかというと、
09:04
M3は大きく分けると、ビズ側の組織とプロダクト側の組織に分かれます。
ビズ側の組織が、例えば事業A、B、C、D、Eっていうふうにあって、
そこに繋がるように、事業Aのプロダクトチーム、
ここにプロダクトマネージャー組織から入ってきたり、
エンジニアリスト組織から入ってきたり、デザイナー組織から入ってきたりすると、
そういったいわゆるマトリックス組織みたいなところが、
プロダクト開発チームにあって、そこが縦に割られて、
事業Aを支援する、事業Bを支援する、事業Cを支援すると、
そういう形でプロジェクト編成されてるみたいな、そういうイメージですかね。
そうか、じゃあチーム編成がそもそも先ほどのM3.comの方なのか、SaaSの方なのかだったとしても、
結局はこの事業A、B、Cごとに縦のラインでプロジェクト化されるので、
そこの関わり方は変わらないということなんですね。
例えば事業Aを支援するのは、アセットを有効活用できるプロダクトマネージャーが入ったり、
事業Bはそのメンバーがいなくて、エンジニアリンググループのプロダクトマネージャーがやってたり、
事業Cになるとまたアセットを活用するところから来たりとか、そういった形ですね。
事業によってどちらかのPMが入る。場合によっては両方のプロダクトマネージャーが入ることもあります。
ありがとうございます。今のM3さんってまさに右を曲折を経て、この形にたどり着いたんじゃないかなと思うんですけども、
過去山崎さんが関わってた中で、この組織形態失敗したなとか、うまく機能しなかったなというのはありましたか?
そうですね。なかなかこれは、M3は基本的に大きな失敗しない会社なんで、
本当にそれこそ勝つべくして勝ってきているというところがあるんですけれども、
その中で挙げるとすると、エンジニアリンググループ内にPM組織を立ち上げていったのは大成功だったかなと思いますね。
その心は?
いろんな見方があるんですけれども、もともとM3.comというメディアを中心とした、
そこにいろいろなMR組織であるとか、ウェブ講演会などの便利な機能がついているという、
そういう形態を取っているんですけれども、やっぱりそれ以外にSaaSとかアプリとか、
そういったものは作っていかなきゃいけない。
そうなった時に、やっぱりエンジニアリンググループ内にプロダクトマネージャーがいた方が、
やっぱり柔軟に動けるというのはあるんですね。
リソースアサインの関係とか、そういうところもエンジニアリンググループ内で自由にできますから、
そもそも上長が一人だったりしますので、そういったところのメリットというのは非常にあったなと感じますね。
他社さんの事例で、エンジニアリングチームの中にPMの人たちがいると、
12:03
結構、ワイワットをやらずに、ハウのところの開発のみになっちゃうケースをよく見るんですけれども、
多分M3さんってそうじゃないじゃないですか。
そうならない工夫というかポイントってあるんですか?
そのポイントはありますね。
それ本当にあるあるで、いわゆるテックPMみたいなところを採用すると、
本当にプロダクトオーナー的な、本当にそういったバックログを消化するみたいな、
そういった話に本当になりがちなんですけれども、
そこをポイントは、私がリーダーやってるってところだと思いますね。
私はやっぱりエンジニア出身ですけれども、プロダクトマネージャーとしてもキャリアは長い。
直近までVP of Eをやってたぐらいで、4月からCTOとCTO兼VP of Pやらせていただいてますけど、
やっぱりプロダクトマネージメントはそれなりに経験がありますし、それなりに知っているつもり。
そういったところで、やっぱり罠は全て避けられるので、
そういったようにならないように、ちゃんとマネージメントしてるっていうのが大きいところかなと思いますね。
そういったものにならないように、どんな罠を避けるテレンテクダがあるんでしょうか。
いろいろありますよね。
例えばなんですけれども、これもしかしたら次の話題に関連してくるかもしれないんですけれども、
まずインスパイアとちゃんと読んでもらうとか、そういった基本的なところから、
やっぱりフィーチャーチームになりかけてるって時に、きちんと介入したりであるとか、
日々のワンオンで、そういった思想レベルの問題を、
私7つの思考っていうフレームワークを提案させてもらってるんですけれども、
その7つの思考に沿って、より上位の概念に移動することもあれば、
より具体的な概念に移動することもある。
そういったものを、日々のコミュニケーションの中で、
どれだけやっていけるかっていうところが重要なのかなとは思いますね。
なるほど。でもそうなると、組織に罪はなくて、
そこをどう運用するかっていうところが、ホワイワットまでやれるのか、
ハウスの開発フィームになっちゃうのか。
まさにその通りだと思います。
組織の割り方というよりは、トップの考え方とか、
組織の冗長がどう考えてるかみたいなところが大きいと思うので、
そこに左右されることが大きいんじゃないですかね。
山崎さんがいない会社のそういう組織、どうしたらいいですか。
そうですね。大きくは考え方は2つかなと思います。
1つは、例えばエンジニアリングのトップには、
エンジニアリングを期待する。当たり前なんですけれども、
そういった割り切りというか、プロダクトのトップには
プロダクトを期待するというふうに分けて、
その2つの組織でうまくやっていく。
そういう方向を見つけるか、もしくはエンジニアリング組織に
15:02
プロダクト志向を期待する。
エンジニアを全員プロダクトマネージャーぐらいの感じで
期待していく。もちろんエンジニアの中でも、
それが得意、不得意というのはもちろんありますし、
でも一部のメンバーはプロダクトマネージャー的な志向を持ち得るので、
そういった人たちを増やしていくであるとか、
そういったところがあると思います。
特にこれですね、CTOの世界を見るとすごく面白くて、
いわゆる創業企業にいる創業CTOみたいな方ですね。
そういった方っていうのは、かなりの確率で
プロダクトマネージメント的な志向をちゃんと持ちですね。
一方で、会社が大きくなってから採用されたCTOであるとか、
VPOVとかがすでにいて、テックを期待されているCTOであるとか、
そういう場合はかなりテックによっている可能性はある。
なのでCTOっていろんなタイプがいて、
エンジニアリングマネージメントに特化したタイプもいれば、
技術的に特化したタイプもいて、
実はですね、プロダクトも分かるCTOってタイプが一部いらっしゃるんですよね。
そういったところも関係してくるかもしれないです。
ありがとうございます。
次回はですね、まさに今の話でもねました、
どうやってPMを育てていくかだったりとか、
PM組織に関する育成マネジメントの極意について、
山崎さんに引き続きお伺いしていきたいと思います。
それでは今回もリスナーの皆様、山崎さん、松永さんありがとうございました。
ありがとうございました。
ありがとうございました。