CLOSE

エンジニアからPdMになって苦労している話(全2記事)

PdMについて学んだら生まれた“優しい目”と“厳しい目” いちエンジニアがPdMについて調べて感じたこと

日本XPユーザグループ(XPJUG)が主催になり、毎年秋に開催されている「XP祭り」。ここでナビプラス株式会社の水越氏が登壇。まずは水越氏がこれまで関わってきたプロジェクトを振り返りつつ、PdMの役割などについて話します。

水越氏の自己紹介

水越明哉氏:よろしくお願いします。「エンジニアからPdMになって苦労している話」というタイトルです。水越明哉と申します。Twitterアカウントは「@akiyah」です。

では進めていきます。自己紹介です。今、ナビプラス株式会社というところに2年半ぐらいいて、レコメンドサービスという「あなたへのおすすめアイテム」みたいなものを出すサービスをしています。タイトルにあるように、エンジニアをやっていて、2022年3月からPdMをやっています。

あと、アジャイルプロセス協議会という会をやっています。その中にアジャイルマインド勉強会があって、読書会をやっています。(XP祭り2022の)基調講演をされた懸田さん(懸田剛氏)の本である『「アジャイル式」健康カイゼンガイド』読書会を月1回のペースでやっていて、今2回終わって、10月に3回目があります。

思い出した。趣味は統計や工作で、(スライドに)牛乳パックフエと書いたんですけれど。(このイベントの)ちょっと前にやった「Maker Faire」に出して。伸縮するんですよね。(フエを鳴らして)音が出る。子どもたちが触って遊んでくれています。

PdMは「プロダクトに関する意思決定を周りの意見を聞いた上でする人」

「PdMって?」と。私も今の会社に入ってからPdMという言葉を認識したんですけれど、調べてみると、もともと知っていた役割だなと思って。

PdMの社内の役割定義を見ると、「プロダクトの方針を定め、成功に責任を負う」と書いてあって。(本当は)もうちょっと(詳しく)書いてあるんですけれど、「ああ、なるほどなるほど」と。

「自分の知っている言葉だったら、プロダクトオーナーのPOだね」と。(PdMは)スクラムでいうプロダクトオーナーで、ほぼイコールだと思っています。

でも、一応書籍で調べてみて。プロダクトマネジメント本って、流行りっぽくってけっこう出ているんですね。及川さん(及川卓也氏)の『プロダクトマネジメントのすべて』という本に定義として(PdMのことを)バシッと書いてあるかというと、ちょっと違うかもしれないですけれど。

「プロダクトマネージャーは、中長期の戦略立案、ビジョンの構築、プロダクトのビジネス、開発、UXのすべてのプロセスに携わり、ステークホルダーの承認を得たうえで、プロダクトに関係する意思決定に責任をもつ」と書いてあります。一番わかりやすい定義かなと思います。

『INSPIRED』という本にもプロダクトマネジメントについて書いてあって。「プロダクトマネージャーこそが製品の成功に責任を持ち、説明責任を負う人だと考えるのである」と、ちょっと定義っぽくはないんですけれど、「こういうことかな」ということが書いてあります。

もう1つは『ゼロから始めるプロダクトマネジメント』という本で、この本はもうちょっと易しい書き方で、定義っぽくは書いていないんですけれど。「プロダクトマネジメントを実践することで、ユーザーに価値あるプロダクトを提供することと、持続的なビジネスを実現することを両立できるんだ」という、プロダクトマネジメントのメリットみたいなことが書いてあって。(これも)定義みたいなものかなと思いました。

簡単にざっくりまとめると、「プロダクトに関する意思決定をする人」がプロダクトマネージャーかなと思いました。

(スライドを示して)「ただし、周りの意見などを聞いた上での意思決定」と書いたのは、(PdM)本人に「全部決定して」と言うとやはりかなり難しくて、いろいろな話を聞かなくちゃいけないことが見えてくるので、「周りの意見、周りのサポートがあった上での決定をする人」かなと思います。

これまでのプロジェクトでもPdMの役割をしている人はいた

先ほども言ったように、PdMという言葉を私は最近知ったんですけれど、今までのプロジェクトでもPdMっぽい人はいたなと思い出して書いてみました。懸田さんのチームにいたことがあるので、その時のTRICHORDチームの話です。

このチームはエンジニアのチームで、懸田さんがリーダーでした。先ほどPOと言っていたと思いますが、PdMと言ってもいいのかなと思います。

みんなで意見を出して、懸田さんが最後に決定するというような動きをしていました。小さいチームなので、リーダーがいるとそういう役割分担になるのかなと思います。「あまり難しく考えなくてもこうなる」という例かなと思います。

その後、受託開発したこともありましたが、受託開発していると、発注した会社のプロジェクトの担当者みたいな人がPdMになるのかなと思います。こういうパターンはあるけれどこれはラッキーなパターンで、自分がいる右側のシステム開発会社では誰かが窓口になったりしますが、PdMに聞けば決定してくれる。この人はたぶん裏でいろいろ調整するんでしょうけれど、聞けば決めてくれるのでやりやすいパターンです。

でもやりやすいパターンばかりでもなくて、(こちらのパターンの方が)むしろ多いと思うんですけれど、「そういう調整はやってください」みたいに、システム開発会社にいる時の窓口のようになると、結局PdM代理という役割をこなすようなことになって、「でも、発注しているのはお客さんですよね?」みたいなことを内心思ったりして。

もう決めてほしい、決めてほしいというか、誰か1人(が)PdMになってほしい気持ちが起こったりします。(これが)うまくいかないと、プロジェクトとして失敗しちゃう(ことになる)んだと思いますが、こういうこともチョイチョイありました。

(これとまた)別の時で、自社サービスでB2C(BtoC)のポイントサイトなどをやっていた時です。お客さまが一般のユーザーで、そういう人に向けてのサービスを(やっていました)。

ちょっと思い出したんですけれど、その時のチームはスクリューというやり方をしていて。ディレクター、エンジニア、デザイナーの3人が(スクリューの)最小単位です。ディレクターの役割をする人も、エンジニアも、デザイナーも何人でもいいんですが、最初は3人でやっていました。

その時はディレクターがPdMで。ディレクターの人はいろいろですが、できないこともいっぱいあるんですよね。エンジニアがサポートしたり、デザイナーがサポートしたりするんですが、決定するのはディレクターという感じで役割分担があって。この時もPdMみたいな人はいたんだなと思い出しました。

そして、これはまた別の会社であったことですが、B2BのSaaSサービス(を作っていた時)ですね。この時(のサービス)は社長の想いで作っているサービスでもあったので、プロダクトオーナーという人はいました。今思えばPdMだったんだなと思うんですけれど。

プロダクトオーナーの人がいて、開発チームはその人に聞けばいいという体制でした。実際に大きな流れの決定をするのは社長ですが、社長に権限を委譲されているプロダクトオーナーというかPdMがいて、細かいことはすぐに決めてくれる。

社長にはなかなか会えませんが、質問したら答えてくれる人が近くにいて。現実的にプロダクトオーナーはこういう役割なのかなと思ったプロジェクトでした。

(スライドを示して)これは最近というか今の1個前というか、今に至る前任者がいた時です。私はこのエンジニアチームの1人で。今の会社では、エンジニアリングマネージャーとテックリードとプロダクトマネージャーの3つの役割があって、兼任もしていますが、前任者の人はエンジニア兼プロダクトマネージャーだったんですね。

ただ、そんなにプロダクトマネージャーの仕事をしているような感じに見えなかったので、「PdMって何をしているんだろう?」「PdMとしての仕事って何だろう?」が(私は)あんまりよくわかっていなかった。あと、プロダクトの方向性も私はいまいちよくわかっていなかったんですね。というのが当時でした。

水越氏がPdMに対して抱いていたイメージ

エンジニアとして近くにいたプロダクトマネージャーを思い出して考えると、「PdMはプロダクトに関する意思決定をする人です」でいいのですが、(PdMの人も)いろいろな出身の人がいて。

エンジニア出身だったり、ディレクター出身だったり兼務だったりですけれど。「どの出身であっても、PdMはその人がもともといた職種とは違う役割だ」ということがわかってきたんですね。

PdMの人ってみんな初心者というか、みんな完璧じゃない。PdMの守備範囲がプロダクトに関連すること全部で広すぎて、どっちにしろ1人じゃカバーできない。

プロダクトマネジメントはチームで行いますが、PdMが決定者という考えかなと。このあたりがPdMを優しい目で見るほうですね。PdMは大変なので、みんなでサポートしようという考えの1つです。

もう1つはもうちょっとPdMに期待しているほうで、「でも、プロダクトのコンセプトや方向性というのは決めてもらわないと」「PdMが示してくれなくちゃ」という期待というか、「これをやってくれなくちゃだめでしょう」というような、ちょっと厳しいほうの目でした。

これが私の頭の中に、たぶん自動的にできていたイメージです。

(次回につづく)

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

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

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

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

人気の記事

新着イベント

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

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

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