こんにちは！Kyu-syokuに興味を持ってくださりありがとうございます。私たちがより良い情報を提供できるように、プライバシーポリシーに基づいたCookieの取得と利用に同意をお願いいたします🙏🍪
同意する
Cookieを無効化
無料登録
  1. トップページ
  2. プロダクトマネージャーのためのコミュニティ＠福岡キックオフイベントレポート【前編】

レポート

プロダクトマネージャーのためのコミュニティ＠福岡キックオフイベントレポート【前編】

  • 2023.11.01

プロダクトマネージャーによるプロダクトマネージャーのためのコミュニティ、福岡に誕生！

昨今名前をよく聞くようになったPdM（プロダクトマネージャー）。ITスタートアップ企業が続々と生まれている福岡において、その役割の重要性は増してきています。一方で、そもそもPdMの仕事は職種自体が新しく経験者の絶対数が少ないうえにニーズが首都圏に集中していることもあり、地方におけるPdM人材は不足しがち。加えて社内にシニアクラスが在籍しているケースも少ないため、PdM自身の成長につながる研修やナレッジシェアも十分とは言えないのだとか。

市政をあげてスタートアップが盛り上がりを見せている福岡市において、PdMの、PdMによる、PdMのために立ち上がったのがこの「Product Management Fukuoka（PMF）」。 本記事では福岡におけるPdMコミュニティのキックオフイベントとなる対談レポートをお伝えいたします。（2023/10/20開催＠Fukuoka Growth Next）

【本記事を読んでいただきたい方】
・福岡／九州でプロダクトマネジメントの役割を担っておられる方
・プロダクトマネージャーとしての仕事に課題感やモヤモヤを感じていらっしゃる方
・プロダクトマネジメントのスキルや経験を活かして転職やキャリアアップを考えていらっしゃる方

トークイベント登壇者

株式会社YAMAP
PdM/VPoP　土岐 拓未さん
音楽誌の編集職という異色のキャリアを経て東京のソフトウェア・ベンダーにてBtoB製品の開発責任者、新製品の提案・開発などに従事。YAMAPの企業理念に賛同し、2019年より福岡に移住しジョイン。YAMAPではPdM/VPoPとして戦略策定や事業部長との連携、機能開発、組織改善などプロダクトグロース実現のために奔走中。

シリアル株式会社/SEREAL.Inc
CEO 安達誠寛さん
スタートアップを創業した経験や複数の事業・プロダクト開発の経験を活かし、「良質なスタートアップを量産する」ことをミッションとしてスタートアップスタジオSEREALを立ち上げ。シードからシリーズAまでの領域に特化しプロダクトマネジメント・UI/UXデザイン・CS、マーケティングなど経営レベルで設計実行までをサポート。会社として「シード・アーリーに関わるクリエイターに適切なリターンを設定する」という裏ミッションも掲げている。

株式会社トイポ
CPO 小神寛晴さん
九州工業大学情報工学部卒業。在学中よりハッカソンやインターンシップを通じてプロダクト開発に携わる。2019年より、お店のファンを増やす店舗向けSaaS「toypo」を運営する株式会社トイポを共同創業（創業者の村岡氏とは高校時代の”ヨッ友”だったとか…）。1人目エンジニアとしてゼロイチでのプロダクト開発を担当。現在はCPOとしてプロダクトの提供価値向上・事業成長にコミットしている。

なぜ、福岡でPdM（プロダクトマネージャー）コミュニティ？その背景とは

安達：
この度福岡でPdMが集まるコミュニティを創ろうと思った背景には、なにより事業や会社を運営するうえでプロダクトが占める影響がかなり大きくなってきている、ということが挙げられます。とくにスタートアップや新規性の高い事業において、プロダクトのもたらす影響はかなり大きくなっています。
一方で、そもそも職種的に新しいということもあり「プロダクトをつくれる人材」が日本にはまだ絶対的に少ないんです。ましてや福岡となると、スタートアップが盛り上がっているとはいえPdMは東京と比べても体感10分の一くらい。だから福岡においてプロダクトマネジメントできる人材を増やしましょう、というのがこのコミュニティを立ち上げた背景です。
小神：
自分自身も最初にプロダクトマネジメントを勉強するときには、経験者や先輩もいないなか手探りでやってきました。このコミュニティではそういったことをいっしょに解決していきながら、プロダクトマネジメントできる人材を増やしていっていければなと思っています。
安達：
ちなみに今日、プロダクトマネージャー、もしくは何らかのプロダクトマネジメント業務に関わっている方、どれくらいいらっしゃいますかね？
安達：
（50名ほどの会場の中、15名ほど手を上げる）
おお～けっこう多いですね！　今たぶんもう福岡中のPdMがここに集結していると思います（笑）。というのは半分冗談ですが、まあこういった背景のもと、これからPdMで集まって各社のナレッジを共有する研究会とか、ナレッジが溜まったらそれを広くシェアするような勉強会とかもやっていこうと思っています。よろしくお願いします。

PdMは普段何をやっている？——会社やフェーズによって異なるPdMの実務

自己紹介を終えて、3名によるトークセッションへ。プロダクトマネジメントといっても職務要件が会社によって異なるのがPdMの特徴。キャリアや立場、toB/toC、プロダクトのフェーズも異なるお三方だからこそ、それぞれの価値観や役割の違い・共通点が対談を通じて明らかになるシーンも多々ありました。

安達：
YAMAPって結構フェーズがもう上のほうまで行ってるじゃないですか。一方で、トイポはまだシードからアーリーくらいですよね。お互いPdMとは名乗りつつも実際の仕事はやはり違うものでしょうか？
土岐：
YAMAPは今PdMが6人ほどいて、それぞれがチームでプロダクト開発にあたっています。私自身はエンジニアとチームで動いているわけではなく、他のチームの事業部長と話したり経営層と顧客戦略を作ったり、ロードマップ作成やリファインメント、全体のプロセス設計などを他事業部のいろんな人とやり取りしながら考えてやってみてまた考えて…。まとめると「だいたいミーティングしている人」ということになります（笑）。

安達：
じゃあ機能設計にはほとんど入らないんですね。
土岐：
はい、今はそれぞれのチームに任せています。
開発した機能に対してどのような効果があったのか、というアウトカムの部分を主に見ています。なにかの機能を作った際に、それによってどれくらい人が動いたかというのをKPIなどで確認しながら、この機能は継続しよう、あるいは違うやり方でやってみようといったことを事業部長や他部署のマネージャーと話しながら考える…ということをやっています。
安達：
数字を見る側面が強いとのことですが、具体的にどういう指標を見てますか？
土岐：
YAMAPはtoC向けアプリなので、やはり一番見ているのはMAU（Monthly Active User）です。あとは登録直後のユーザーの動きを見たい時には1か月後にログインしたユーザーが何％いるのか、その中でも登山経験ある人がどれくらいか…など、それぞれの施策に従ってある程度仮説を立てて検証し、改善していきます。アプリはやっぱりデータが取りやすいのでそういうことをみんなでやりやすいんですよね。
安達：
それぞれの施策はエンジニアと一緒に作っているPdMの方が開発して、その効果の全体像を土岐さんが管理する、ということですかね。
土岐：
課題設定はデータやユーザーインタビューなどを通して、デザイナーやプロダクト・マネージャー、事業メンバーなど様々なメンバーが関わって話しながら行っています。それを通して事業部長がまず顧客戦略と呼ばれる戦略を立て、その戦略に基づきプロダクト・マネージャーが施策の優先度を検討するような流れになっています。私自身はそれをプロダクト開発の部門から全体統括してバランスを取っているというような、そんな感じですね。お二人はいかがでしょう？
小神：
僕の場合はまだ人やチームのマネジメントというよりも、実際に手を動かすことと顧客やセールスチームから情報収集することが主な動きです。あとはプロダクト開発のプロジェクトが問題ないかを確認したり、要件定義したり、ときにはUIを作ったり、全体のうちどこがボトルネックになっているかを分析したり…というのがほとんどですね。
それに加えて、なにか問題があった時には顧客対応も入る感じです。極論言うと、導入していただいているお店にセールスと一緒に謝りに行くことも…。
土岐：
「社内の人と会う・社外の人と会う・机に向かう」の割合ってどのくらいですか？
小神：
時期にもよるんですが、それぞれ等分くらいでしょうか。一時的に開発の要件定義など時間かけて作らなければいけないタイミングであればその割合が高くなっていく…みたいな感じです。
土岐：
ご存知の方も多いと思うんですが、プロジェクトマネジメントトライアングルという考え方があって。「ビジネス・開発・ユーザーの3つの軸の間をすべて取り持つのがPdMである」というものなんですが、一方でそのトライアングルから外れたボールも取りに行くのもまたPdMの役割と言われていて。そうなるともうめちゃくちゃ仕事が増えていくんですよね（笑）。小神さんのように現場に謝りに行くというのは、そういうボールを拾っているんだろうなと感じました。

（引用元：The Product Management Triangle※日本語訳はこちらのサイトを参照。）

小神：
まさにおっしゃる通りで、今いろんなプロジェクトが一気に立ち上がっててんやわんやしているので、そろそろ任せていかないと自分自身がボトルネックになってしまう。だからこれからは今まで自分がもらっていたボールも基本的には専門の部門にお任せしていこうと動いています。
土岐：
そうなってくると、だんだんと組織作りや組織同士をつなげていくことが役割として広がってくるんでしょうね。

PdM、明らかに大変すぎ問題

安達：
お2人の話を聞いていても思うんですけど、PdMって大変すぎません！？（笑）
小神：
そうですよね（笑）。明らかにやることが多いし求められるスキルも多いうえに、会社やフェーズによって役割も変わる。そこに経営層ともコミュニケーションをとって経営戦略にもかかわって…ってなるとかなり大変です。
僕はまだ創業メンバーで1人目エンジニアということもあって流れ上PdMになりましたが、そういう経験をしていない中でいきなりPdMになるってなかなか厳しいだろうなとは思います。
安達：
VPoCやCPOクラスのお2人ならまだしも、本来プロダクトマネジメントってもうちょっと直接的にプロダクトの設計だけに集中してやる、というのが僕はいいと思うんです。どこかで線引きしないと便利屋さんになってしまって、結局プロダクト自体が良くなっていかないということになりがちだなと。
土岐：
すごくよくわかります。ただ一方でスタートアップやシード・アーリーの会社だとそうはいっても人も足りないから自分が全部やりますか、となってしまう矛盾はどうしてもありますよね。
安達：
そう、だからプロダクトマネジメントだけピュアにやりたい人はスタートアップに入っちゃいけない（笑）。
デザインでもなんでもそうかもしれない。スタートアップでは自分がやりたいことは半分くらいしかできませんから。

ユーザーとどう向き合うか？——数字と定性情報のはざまで

安達：
僕はスタートアップスタジオをやっているので、MVP（Minimum Viable Product）開発がほとんど。そうなるとそもそもKPIを置くよりもとにかく作れ、って感じなんですよね。そこが大きな違いだなと思います。
土岐：
私もこんなに数字を見るようになったのは現職からですね。toCだと細かく数字を見られるし、だからこそ次の一手を取れるというところはある。そういう意味で、YAMAPでかなり鍛えられました。
安達：
数字を見ることも重要な一方で、実際に顧客がどう使ってるかというのは数字からだけじゃ分からないじゃないですか。その辺はどういうすみ分けですか？
土岐：
これね、実はずっと悩んでるんです（笑）。
安達：
ですよね（笑）。誰に聞いても明確な答えを持ってる人っていない。
土岐：
逆に明確に答えられる人はすこし胡散臭いなとも思います（笑）。
あくまで自分の暫定解なんですが、基本的には数字も定性情報も二重人格的に見ていくしかないのかなと。数字だけだとどうしても1人1人の生活や感情が見えなくなってしまうし、かといってユーザーからの意見だけに偏ると話者のタイミングや状況にも影響されて情報が歪んでしまうことも多い。両方の意見を取り入れることで自分のバイアスを矯正させながらバランスを取っています。
YAMAPのいいところは、「ユーザーさんと一緒に登山にいく」っていう接点を取れること。そうするとユーザーリサーチっていう感じじゃなくて、一緒に山登ったついでにちょっと聞いてみようっていういい関係が築けるんです。ユーザーさんとそういう関係の中でヒアリングしながら同時並行で数字も見て…ということができていけるといいなと。
私、もともと編集者で人文的な人間なので、油断するとすぐ「人の心が～」とか言って定性的なところに寄っちゃうんですけどね（笑）
安達：
山に登るっていう共通の土台があるのはいいですよね。

プロダクトマネジメントは無数の小さな失敗の繰り返し

土岐：
次のテーマに行ってみましょうか。「PdMとしてこれは失敗したなと思うこと」。ありますか？
安達：
あまり「めっちゃ失敗したなー」と思うのは実はないんですよね。訴えられたことがあるくらい（笑）。でもそれはどちらかというとビジネス的なものですしね。まあでも、むしろ小さな失敗をめちゃくちゃしてるって感じがします。
土岐：
僕も同じ答えを言おうとしていました（笑）
安達：
MVPなんてほぼ毎回失敗です。もっとこうしとけばよかった、って思うことがたくさん。
できるだけ最初から精度高く作りたいんですけど、実際は不要な機能だったなというのが必ずある。だからある意味、毎回失敗しているともいえます。
そういうこともあってMVPを作るときに気をつけているのは、想定している機能のさらに2～3割、下手するともっと削ぎ落とそうということ。とくにプロダクトマネジメント経験がない事業責任者やPO（プロダクトオーナー）がMVPを設計すると、半分以上が無駄になってしまうんですよ。だから想定の半分くらいに落とす、というのはマストでやった方がいいと思ってます。
小神：
あるあるですね。自分も失敗はしょっちゅうしています。それこそ教科書によくあるような、「顧客の声聞きすぎ問題」というか。顧客に限らず社長とか代表とかセールスの声を聞きすぎて言われた通り作ってしまうことも結構あったり。
創業初期でプロダクトができたばかりのときって、どうしても「この機能があるなら契約しますよ」みたいな話があるんですよね。シンプルに喜んでほしいという気持ちもありますし。そうなるともう追加機能が重なって、かなりつらくなってしまう。
じゃあどうすればいいのかというと、やはり機能開発という「HOW（どうしてほしい）」のリクエストに対して、「WHY（なぜその機能が必要なのか・その機能で顧客はどういう状態になりたいのか）」を深掘りしたうえでPdMが総合的に検討してHOWを提案したりステップを構築したりするのがいいのかなと。
土岐：
そういうことっていろんな教科書に載ってますけどやっぱり難しいですよね。
小神：
やっぱりそれが成約につながるって考えるとどうしても抗えなかったな、というのはあります。自分も教科書は読んだつもりではいたんですけど（笑）。
土岐：
今お話しいただいたようなユーザーやステークホルダーからの”HOWの罠”もありますし、もう一つテクノロジーからの”HOWの罠”もあると感じます。技術的にはこういうことが可能だからといって機能を作ったもののユーザーからは別に喜ばれなかった…という失敗が自分にもあります。
たとえばむかし、アプリの中に「（登山中の）軌跡の中でどこで休憩したのかが分かる機能」をつくってみたんです。技術的には可能だからやってみようとなって作ったんですが、実際はちょっとトイレに立ち寄ったことなんかまで見えてしまって、それって全然欲しくないよね、となったという…。
人はHOWの話でつい盛り上がってしまうけれど、その時に「待て待て」といってそもそもの課題に立ち戻るというのもPdMの役割なのかもしれません。

"WHY/課題"から始めることで取りこぼしてしまうリアル

小神：
少し話は変わるかもしれませんが、ヒアリングの中でユーザーが「こういう機能が欲しいです」ということを話しているときにそもそもの課題の話って切り出しにくくないですか？
安達：
僕は逆に聞いちゃいます。「なんでほしいんですか？」って。
小神：
そうそう。僕も安達さんがガンガン聞いてるのを見てはじめて「こんなに聞いちゃっていいんだ～」と学んだ気がします。でも最初のほうはすごく聞きづらいと思っていたなと。
安達：
聞きにくいと感じるときには、「なんで」って直接聞かずに、まずはその人が置かれている状況に関する質問をどんどんしていって、その人自身への理解をしようとするのが良いと思います。
土岐：
ファシリテーションのテクニックにもありますが、「なぜ」って結構ドキッとしてしまう質問なんですよね。「いつ」「どんなシチュエーションなの」という質問の仕方がいいかなと。
安達：
「なぜ」と聞かれて出てくる答えって、意外と違っていることが多い。これも罠だと思います。プロダクトマネジメントをする際に、WHYが大事だとかまず課題から始めましょうとかってよく言うけど、課題って直接聞いちゃダメなんです。ユーザーと自分が近くないときに課題を聞いたとしても、まずその解答が間違っている場合が多いし、正しかったとしてもその課題の周辺状況が分からないから解決できない。だからその前にまずはその人自身を理解することが大切です。
土岐：
たしかに。これはみんな必ず通る失敗かもしれませんね（笑）。

トークテーマにもとづいて、異なる立場から三者三様の考え方が明らかになった前半。ユーザー理解を深めるための方法論などについても意見が交わされました。トーク後半ではロードマップのつくり方や参加者からの質疑応答など、よりリアルな対話が繰り広げられます。つづきもどうぞお楽しみに！

後編へ続く

この会社の求人情報

    この会社の求人情報はありません
九州のしごとを探してみる

kyu-syoku にできること

九州・沖縄のいい職と出会うなら、Kyu-syokuで。
このサイトについて・あなたに対してKyu-syokuができることについて書いています。

詳しくはこちら

© Recruiting Partners Co.,Ltd.