CLOSE

パネルディスカッション(全3記事)

「プロダクトマネージャー」の役割と立ち位置 「商品企画のトップ」「プロジェクトマネージャー」「プロダクトオーナー」との違いは何か

プロダクトマネージャー育成の第一人者であるTably社代表取締役の及川卓也氏が「サービスの成否を分けるプロダクトマネジメントスキルの鍛え方」について講演する「【DX推進・新規事業担当者向け】 サービスの成否を分けるプロダクトマネジメント“スキル”の習得法」。片岡秀夫氏とともに対談するパネルディスカッションパートでは、続いて、プロダクトマネージャーの役割について話します。前回はこちらから。

「商品企画のトップ」と「プロダクトマネージャー」の役割の違い

及川卓也氏(以下、及川):話は尽きませんが、テーマ2に行きます。プロダクトマネージャーの役割。これは事前にもらっていた質問でもいいんですが、ライブでもらった質問にも関連するので、それを1つ拾いたいと思います。読み上げますね。

「本日のお話では、プロダクトマネージャーとは、結局、商品企画のトップのような印象を受けました。それを否定するわけではないのですが、そうではないという切り口があれば、あらためてうかがえれば幸いです。」

これはとてもいい質問だと思います。どうしましょう。私が答えていいですか。

片岡秀夫氏(以下、片岡):そうですね。

及川:確かに、商品企画のトップ的な役割を持っています。ただ、従来の商品企画は、肯定的に考えた時に企画を作って、例えばソフトウェアを中心としたデジタル技術を使うものになったとすれば、それを技術陣にブリッジするような役割の誰かがいて、最終的にはその開発を行う人たちもいてというかたちで、けっこう工程が分断されている。

その最初の工程、もしかしたら最終的にGo-to-Marketで世の中に出していくことにも関わるかもしれませんが、一部に関わるかたちになることが多いと思います。

一方、今のプロダクトというのは、アジャイル開発やリーン開発と言われるように、小さく作り、すぐに顧客に当てる。顧客と検証し、その結果をまたすぐに反映させて、開発し、一部を変更し、それをまた市場に展開してどうなるかを見る。

このように横の工程を考えた時に、それを分断するというやり方ではなく、これをすごく短くして、かつ素早く回していくことになった時に、全工程を見ることが求められる。

日本だとプロダクトマネージャーは批判も多いんです。よく“ミニCEO”と言われる(ように、)企業のトップのようなかたちで、プロダクト事業全体を見る(ように)と言われる。

商品企画のトップは、あくまでも企画の部分であり、開発の部分には関わらないのが従来のやり方だと思うので、(プロダクトマネージャーは)そうではないことが大きな違いだと思います。片岡さん、何か付け加えることはありますか?

片岡:そうですね。少し補足します。たぶん、会社の中で商品企画のポジションというか、役割がどうなっているのかという部分もあると思うんですが、一般的な会社でいうと、商品企画があって、営業企画みたいなものがあって、マーケティングの部門があったり(すると思います)。

あとは、及川さんがお話しされた作る部門ですね。情報システムだったり、作るプロダクトの部門は分かれると思います。今、及川さんはこれを横断的に見るということをお話しされたのかなと思っています。

なので、商品企画ということだけを考えると、本当にいい商品を作るという……。この“いい商品”の定義はメチャクチャ難しいと思うんですが、それに特化してしまうので、そうではなく、いい商品ができた時に、「これが本当に売れるものなのか」「お客さまのためになるのか」みたいなことを横断的に考える役割がプロダクトマネージャーだと僕は思っています。

及川:わかりました。

プロダクトマネジメントの中にはプロジェクトマネジメントのスキルも入る

及川:(スライドを示して)では、このスライドにある「外部ベンダーに開発を(依頼)している中でどこまで関与するか?」(という質問)。難しいと思うんですが、片岡さんはどう思いますか?

片岡:そうですね。でも、この相談はメチャクチャ多いんですよね。入り口の話で言うと、プロダクトマネジメントとプロジェクトマネジメントというテーマもたぶん出てくると思っています。

少し補足をすると、プロダクトマネジメントという中にプロジェクトマネジメントというスキルや要素も入ってくるという関係性があるんです。

そういう時に、プロジェクトマネジメント、つまりお客さまにどういうものを作りたいのかをしっかり定義して伝えて、それを仮説検証するみたいな。このプロセスを回していく時に、きちんとできるスキルがないから、プロジェクトマネジメントのスキルを身につけたいということも、ミニマムというか最低限あるケースかなと思っています。

本来はやはりもう少し踏み込んで、例えば外部ベンダーが作ったものに対するコードの検証、どういうコードで書いたのかを検証することも含めて、事業会社側でしっかり責任を持って見ることが必要になるので。

プロダクトマネジメントという意味合いでは、一部分に留まらず、しっかりどういうプロダクトなのか、本当にお客さまに提供し得るクオリティのプロダクトなのかに対してしっかり責任を持ちきる。

それが持てていると思うのであればいいと思います。そういうようなスタンスで関わることが大事なのかなと思っていますが、及川さんはどうでしょうか。

及川:まったく同じですね。2つ目の質問にも関係するので同時に答えると、要は意思決定をしないプロダクトマネージャーは存在しないんです。もちろんどこまで権限委譲されているかだとか、どこまで自分だけで意思決定できるかにも関係するわけですが、どちらも重要なのは主体性だと思います。

先ほど言ったように、工程を分断して全部を横断的に見なければいけないと考えた時に、外部ベンダーに開発を委託したとしても、その外部ベンダーに対して主体性を持って取り組まなければいけない。

事業会社の方は残念ながら、ついつい「自分はITの専門家じゃないから」と外部に委託する=丸投げになってしまう傾向が見受けられると思うんですが、(プロダクトマネージャーに)それはあり得ないわけです。

プロダクトマネジメント、または先ほどキーワードに出したリーン開発のようなものの多くは、米国などが日本の製造業を模範にしているところがあるわけです。

例えば、日本の製造業を見ると、それこそトヨタの生産システムみたいなものを採用している製造業の会社が多いわけです。自分たちが作っていないもので、下請けという言い方はしたくないですが、サプライヤーでいろいろな問題が生じたならば、その工場に行って何が起きているかを見るし、必要なら指導するし、一緒に考えることをするわけです。

外部ベンダーに開発を委託している時も同じように、現地、現物主義でそこに(足を)運び、実際にどんな人たちがどんなものを作っていて、問題が起きた時は何が原因なのかを一緒に探る。これくらいのことはしなきゃいけないんじゃないかと思います。

プロダクトチームをどのように機能させるか

及川:ライブ(からのもの)でまた1つ質問を取り上げたいと思います。「プロダクトマネージャーの重要性はわかるのですが、プロダクトマネージャーないし、その他のプロダクトに関わるメンバーたちが、各々の役割と振る舞い方を理解しないと機能するのは難しいと考えています。このあたり、あるあるの課題なのか、どのようにしたらいいか、教えてください」という質問です。

確かに。これはどちらかというと、プロダクトチームをどのように機能させるかという話ですね。

片岡:これは難しいですね。

及川:でもここに書いてあるとおり、あるあるの課題なんです。よく聞かれます。1つは、ジョブ型雇用を採用していないとしても、やはりメンバーのジョブを定義したほうがいいと思います。「あなたはどういう役割をするか」を明確に定義したほうがいい。

勘違いされると思いますが、ジョブ型雇用はそれ以外のことをしちゃダメとかしなくていいという意味ではない。よく私がメタファー、たとえ話として出すのが、野球やサッカーなどのスポーツで、「二塁手の守備範囲はここだ」と決まっていたとしても、そこから1ミリも出ないかというとそんなことはなく、必死になって球を取りに行くわけです。

サッカーだって、オフェンスかディフェンスかが決まっていて、自分がオフェンスであったとしても、「ここで俺が守らなかったらゴールを決められる」と思ったら守るわけです。というようなかたちで、そもそもその人たちは何をやるかという定義を決める。

キーワードだけ出すので、みなさんぜひ後でググってほしいです。RACI(Responsible 、Accountable、Consulted、Informed )、DACI(Driver、 Accountable、Consulted、Informed )というマトリックスがあって、どんな意思決定なり承認なりをするか。どんな実証の時は誰がどういう役割を担うかをあらかじめ決めておくことで、だいぶここは整理ができると思います。

片岡:そうですね。僕が難しいと思うのは、その状態というか文化みたいなものがあると思うんですが、その文化を理解することや浸透させて文化を変革することが一番大変だと思うので、そこが大変だな、難しいなと(思って)お話ししました。

ある種のルールを決めてあげる。「こういうあり方や行動が正しいんだよ」みたいなことが、きちんとやっていく上では必要なのかなと、今聞きながら思っていました。

及川:そのとおりです。今のは悪い言い方でどちらかというと尺子定規的で、仕組みなり規律を決める話だと思うんです。でも、これだけじゃ組織は機能しない。組織を構成する人間は感情の生き物ですから、やはりモチベーションを持って取り組むことが必要です。

結局、それはテクノロジーもしくはプロダクトに対しての理解であり、プロダクトを成功させたいという強い情熱、パッションが必要なんだと思うんです。これはプロダクトマネージャーに求められるもう1つの役割です。

やはりプロダクトマネージャーは、ビジョンをしっかりと持ち、人々を熱狂させなければいけない。一種のコピーライティングのセンス、もしくはストーリーテリングの能力が必要になると思うんです。

そういう能力を持ち、人々を熱狂させるような、チームメンバーを熱狂させるような、動機づけになるようなことを行う。結局はそれがチームのカルチャーにもつながっていくんじゃないかと思います。

プロダクトオーナーとプロダクトマネージャーは共存するか

及川:では、いったんスライドの最後の質問に答えましょうか。プロダクトオーナーとプロダクトマネージャーは共存するか。片岡さん、いかがですか。

片岡:そうですね。僕は共存し得るんじゃないかなと思っています。役割で分けると、小さいプロダクト、例えば3、4人のプロダクトであれば、共存は難しいかなと思うんですが。

大きなプロダクトであれば役割は無数に出てくると思うので、そのあたりを明確に分けている会社が多いのかなと。共存できると思います。

及川:そうですね。私も(この質問は)聞かれるんですが、プロダクトオーナーが、どういう意味でその会社で使われているかによって違うんです。

例えば、アジャイルのスクラムを使っているとする。スクラムというのは、プロダクトオーナーという役割がプロダクトの中、スクラムの中であるので、そのことを言っているとしたら、そのプロダクトオーナーと役割は、プロダクトマネージャーが担うのが一般的だと思います。

プロダクトオーナーが、プロダクトマネージャーの上位職みたいに扱われることも多いんです。それも当然で、プロダクトオーナーは、プロダクトマネージャーが多くのプロダクトを束ね、さらにはプロダクト事業全体の責任者になるということなので、これもそういうポジショニングにすれば共存可能であると考えます。

(次回に続く)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!