PMの仕事は組織でプロダクトマネジメントを実施することと気づけた話(半年の振り返り)

PMの仕事は組織でプロダクトマネジメントを実施することと気づけた話(半年の振り返り)

みなさんこんにちは。PMの根津(@hiro_winjoy)と申します。

この度株式会社フライル様の主催する「プロダクトの急成長の裏側で、PMはどんな機能開発の優先度づけをしてきたか？」というイベントに登壇させていただきました。

ちょうどエンペイに入社し半年が経過したこともあり、イベントの登壇が振り返りのいいきっかけになったので、この半年間を振り返ってスタートアップの1人目PMとして何をやってきたのか、考えたことや感想などを書き記したいと思います。

PMのキャリアスタート ～ 壁にぶつかる

2021年10月 エンペイ入社

2021年10月エンペイに入社しました。それまでの経歴はエンジニア9年→経理コンサルタント1年→コーポレートエンジニア1年 という感じなので、PM未経験からの入社となりました。

正直未経験の状態でスタートアップのPMになることに不安もありましたが、エンジニア時代の同僚でもあった弊社CTOの田野から「根津さんならできると思う」と言っていただいたので、その言葉を信じ、PMの仕事や責任に非常にワクワクし、チャレンジングだけど今しかできないと感じたのでこの環境に飛び込むことを決めました。

入社後まもなく大型案件

入社後まもなくエンペイの中でもかなり大きめなエンタープライズ向けの機能開発のPMをやることになりました。その時点ではPMの仕事がまだ不鮮明でかなり手探りで案件を進めていたように思います。そんな中でしたが、結果としては無事に目標の期日までにリリースでき、リリース後一部ユーザーからフィードバックを頂きましたが、大変好評でした。初めての大型案件が成功しホッとしましたが、案件自体は私の入社前から走り始めており、セールス、CS含め多くのメンバーに支えられて成功したと感じました。この成功が後で課題にぶつかったときのヒントになったように思います。

自分の許容量を超え始める

その後もPMとして様々な業務にあたっていましたが、徐々に不完全燃焼な日々が続くようになってきました。色々と仕事はやっているしリリースも定常的に出来ている。しかしなんかやりきれていない感じ。おそらくこの頃はPMの仕事の定義が今より曖昧で眼の前にある様々な「やるべきこと」をこなすことに追われてしまい、結果的に大きな価値が出せないまま自分のキャパを超え始めていることに焦り始めていたんだと思います。

具体的には主に以下のようなタスクに追われていました。

  • POとしてのバックログの管理
  • 要件定義/仕様検討/開発時のエンジニアからの相談対応
  • 顧客からの問い合わせのハンドリングと各所へのコミュニケーション

これらは今もなくなったわけではなく今後も常に付きまとうやるべきことだと思います。問題なのはこれらをこなすことで私の工数が逼迫してしまっていたことにあると思います。

また、PMの業務は一般的な定義に落とし込んでも非常に広義で、また会社によっても定義が変わってくる部分だと思います。今でも自分の中での正解やエンペイとしてのPM像を模索していますが、この頃は更に不鮮明な頃だったと思います。そのため自分のPMとしての限られた工数を本来はどこに当てるべきなのか、そのために今かなりの工数が取られている上述したタスクへの取り組みをどうするべきなのか悩んでいました。

参考までに、PM業務の一般的な定義については以下の記事が非常に参考になったので載せておきます。

プロダクトマネジメントトライアングルと各社の PM の職責と JD

Product Manager Conference 2017 (#pmconfjp) の最後のセッションで登壇させていただきました。セッション中にはあまり時間がなかったので、セッションでいくつか触れたことについて補足しておきたいと思います。 セッションで挙手をお願いしたとき、意外と多くの方がご存じなかったので PM Triangle について私の方でも取り上げておきます。 プロダクトマネージャの職責は比較的曖昧で、そのため「プロダクトマネージャーとは何か」という議論は混迷を極めます（その曖昧さが PM の本質だ、という話もあります）。 そんなとき一つ参考になるのが、 The Product Management Triangle (by Dan Schmidt) という記事にあるプロダクトマネジメントトライアングルです。 この記事についてはにんじんくんさんの翻訳が素晴らしいです。 ただ、原案のトライアングルは網羅的であるがゆえにちょっと細かすぎて、話し合うときには使いづらいという話を聞いたので、極力内容を変えずに、少し抽象化してそれぞれ 3 つずつに変更してみたのが以下のトライアングルです。 記事によれば、プロダクトマネージャーはこれらの領域を健全に機能させることが役割であり、 機能がなければ自分で役割を演じたり、補う方法を見つける（たとえばデザイナーがいなければ、自分でデザインを行ったりデザイナーを雇う） 「開発者-ビジネス」「ビジネス-顧客」「顧客-開発者」の融合領域における、各種の複雑さや衝突、トレードオフの統合を行う といったことが PM の職責であると理解しています。 逆に言えば、これらを俯瞰して見ることができる能力が PM には求められています。そうした意味で、PM は様々なことを広く学び、組織やビジネスの変化に柔軟に対応できる必要があるとも言えます（今回の PM Conference はそうした視野を『広げる』部分が一つの目的だったと伺っています）。 また「PM にはコミュニケーション能力が必要になる」というのは、それぞれの機能が組織的に分かれている場合、それぞれ違うゴールや言語を持つ人たちを滑らかに機能させたり、衝突を統合しながらプロダクトを前に進めるためにコミュ力が必要だと言われるのだと思います。 トライアングルから見えてくるもう一つのことは、「PM に求められる能力は会社や組織、製品によって異なる」ということです。 なぜなら、現状の組織でトライアングルのどの部分が機能していないかは、時と組織によって異なるからです。 組織のリソースが豊富な場合はプロダクトの仕様を策定するだけの PM なのかもしれません。スタートアップのようにまったくリソースのない組織の場合は、全部の機能を一人がやらなければいけないのかもしれません。人を採用して少しリソースが増えたら、また PM に求められるバランス感が変わってきます。 組織の今の状況に応じて PM はその役割を変えますし、同じ組織においても時間が過ぎれば役割が変わっていくと認識しておくほうがよいのでしょう。 また、McKinsey の今年の『 デジタル世界のプロダクトマネージャー 』という記事には、以下のように会社ごとに異なる PM のあり方が描かれていました。それは の３つです。 自社の PM が、どういう位置付けの PM を求めているかを考える際に、この分類は一つ参考になるのではないかと思います。 またこうした背景があるから、異なる会社の PM 間のノウハウ共有の際に大きな違いが出てくるのではないかと思います。 こうした会社間での違いは企業文化的なものも影響しているのだと思いますが、そもそもはビジネスモデルに依る部署間のパワーバランスが PM の役割にも影響していると考えられそうです（黒田さんの指摘によるもの）。それは主に以下の二つの極のグラデーションではないかと思います。 主にエンジニアのコードで利益の成長が加速するビジネスモデルか →テクノロジ寄りになりがち 主に営業の頑張りによって利益の成長が加速するビジネスモデルか →ビジネス寄りになりがち つまりプロダクトの Engine of Growth が組織のどこにあるのか、というのによってビジネスモデルや組織のパワーバランスが左右され、さらに PM の立ち位置も左右されるのだと思います。 （とある営業組織が強い会社の PM の人と話したときは、ほとんど営業さんの御用聞きになってるみたいで大変そうでした...） またスタートアップにおいては、一会社＝一製品ですが、大きくなってくると一つの会社が複数の製品を持つことになります。そして同じ会社でも、製品によっても PM ...

tumada.medium.com

プロダクトマネジメントトライアングルと各社の PM の職責と JD

解決策を模索し、壁を乗り越える

CTOからのアドバイスで示唆を得る

そんな時、CTO田野との1on1で「眼の前のタスクに追われ価値が出せていないと感じている」と相談を持ちかけました。すると田野から以下のようなアドバイスを貰いました

🗨️
『PMの仕事は範囲が広く、落ちそうなボールも拾わなくてはいけないので大変。だけど、全部PMがやる必要があるわけではない。PMの責務はいかにプロダクトの成長を推進させていけるか。』

同じような文脈で、最近は地味PMという言葉が生まれてきていて、私はそのタイプのPMに合っているのではないかという助言ももらいました。(地味PMについては以下の記事参照)

これらのアドバイスを受け、PMとして視野が狭くなっていて、適切なアプローチが取れていないことに気付きました。そこで、1人で抱え込むのではなく、他部署を巻き込みチームとしてプロダクトマネジメントを実施するための方法を検討することにしました。

改善に向けたストーリーを考える

チームでプロダクトマネジメントを実施するためには小手先の方法ではうまくいかないかもと考え、実現に向けたストーリーを考えるところから始めました。 以下の資料のように「社内の認識を変え、それにあった組織や会議体の形に整え、それを効率的に運用するためのツールを導入する。」と言った形で順序立てて改善を実施することを考えました。

image

あとになって振り返ってみると最初に上のようなストーリーを描き、各メンバーが納得感ある形で施策を実施できたことが今回の取り組みを成功させる要因になったと思います。 具体的に行った施策については本記事では割愛させていただきます。プレゼン資料に関しては後日株式会社フライル様より資料付きでイベントレポートが公開されると思うので、そちらをご覧いただければと思います。

バリュー表彰

上述の通り、今回エンペイとしてのプロダクトマネジメントのあり方を変えるために様々な施策を実施し、今のところうまく回っていると思います。

また今回の実施したことが評価され、社内で実施しているバリュー表彰(※弊社で掲げているバリューを体現できている人を表彰する取り組み)を受賞することもできました。

弊社バリューについては以下のコーポレートサイトを御覧ください。

次なる課題

今回チームでプロダクトマネジメントを実施するための地盤を整えることが出来ました。 しかし、やはりまだエンペイとしてのPMの責務は定まりきっておらず、自分のスキルもまだまだ伸びしろだらけだと感じています。今後はそういったPMの責務をより具体化して、その中で自分に必要なスキルを伸ばし、足りない部分は他で補うことで円滑なプロダクトマネジメントを実現していきたいと思います。

最後に

プロダクトのさらなる成長を目指すために絶賛採用中です！ 職種も幅広く募集しておりますので、興味がございましたら是非お問い合わせ頂けますと嬉しいです。