前編の記事は こちら
プロダクトロードマップ、どう作る?フェーズごとの違いと共通点
- 安達:
- 次のトークテーマは「プロダクトのロードマップをどのように作っていますか?」ということで。
- 土岐:
- プロダクトロードマップもまた、人や会社によって全く違いますよね。これも悩みどころはたくさんあるんですが、私の場合はだいたい半年単位くらいです。まずは前提となる顧客戦略に基づいて機能をつくりましょうとなって、エンジニアに粗く見積もりを出してもらってから順番を整理します。ただやっぱりうまくいかなかったり途中で変更があったりしますから、毎週周りの事業部長とも話をしながらロードマップを更新していく、という流れです。
- 安達:
-
半年って、具体的にどのくらいの粒度で作り込んでます?
- 土岐:
-
最初の3か月間は機能ベースでしっかりめに作っています。あとの3ヶ月はいったんぼんやりさせて、近づいてきたらだんだん明らかにしていく、みたいな形ですね。
中長期のロードマップは、社内でも作りたいねといいつつつうまく作れていないのが現状。プロダクトの大きな方針を3年くらい見越して作ってみてはいるんですけれど、やはりどんどん状況が変わってしまうこともあって実際は難しいです。今まさに経営陣と一緒に悩んでいるところ。
ちなみにツールはmiroでやっています。最初はJiraでやろうとしたんですけど、自分達にはちょっと細かすぎたなと。いろいろ試した結果、今はそれが一番運用しやすいと思っています。
- 小神:
- 状況にもよりますが、トイポではmiroでざっくり作ってから、プロジェクト管理はnotionでやってますね。期間としても土岐さんと同じで3ヶ月分くらいを具体的につくって、残りの3ヶ月はざっくりと。ただ毎週アップデートをかけているわけではなく、毎月1回見直して調整するかどうかという感じ。ちゃんと更新できてなくて、直前になって次の3か月は何しよう?と困ったりすることも正直あります(笑)。
- 安達:
- 機能ベースで書いていますか?そこまでは細かくない?
- 小神:
- どういう課題を解決したいのかをベースにして、たぶんこのやり方でいけそうというのをざっくり機能として置いています。実際にこれでいいのかどうかは随時検証して、場合によってはなくなることもある…という感じ。
- 安達:
- それぞれフェーズは違いますがロードマップ自体は意外と同じような管理の仕方をされてるんですね。
- 土岐:
- そうかもしれません。ただこれも、いまだにベストソリューションかどうかずっと悩んでるから、いいロードマップの書き方があったら教えてほしい(笑)。
ロードマップは誰のためのもの?
- 小神:
- たとえばスタートアップの初期って3ヶ月作っても、状況変化が激しいからあまり作り込んでも仕方がないところはあります。以前6ヶ月くらいしっかり作ってみたことがあったんですけど、半年も経つとまるっきり方向転換していたこともありました。今のフェーズでは6か月をベースとして何か戦略を考える必要はないんだなという気づきはありましたね。
- 土岐:
-
一方でロードマップって、プロダクト・マネージャーやエンジニアのためだけはなく、事業部長や他のステークホルダーのコミュニケーション材料のためにつくっている側面もありますよね。「やりたいことは沢山ありますが、整理すると今期にできることはここまでなので、こういう風に優先順位つけるのはどうでしょう」ということを話しています。そのようなことを見える化して理解してもらうためのための一番わかりやすい資料という意味もあるとは思います。
とくにYAMAPはソフトウェア以外の事業も結構あるので、お互いが認識を合わせてコミュニケーションを取りやすくするというところが大きいのかなと。
- 安達:
- たしかに上に説明するため、という側面はあるかもしれません。
- 小神:
- トイポの場合は上というのがいないため、自分達自身の整理や3ヶ月くらいの単位でみんなと認識をそろえるため、というのが大きいかもしれません。安達さんはなにかロードマップに関して知見はありますか?
- 安達:
- 最近ロードマップ作ってないからなあ(笑)。僕達はとにかくシード期の立ち上げをやることが多いので、仮で半年分くらいは計画を立てるものの、やっているうちに完全に変わってしまって途中からあまり見なくなる。あまり有効活用できていないですね。とにかくみんな走ろうとか、このゴールに向けてとにかくやろうっていう感じですね。
会場からのQ&Aタイムは、プロダクトマネジメントに関わる方からのリアルなお悩みも…
トークテーマをあらかじめ設けての対談の後は、会場の参加者からあらかじめ募集したお悩みをもとにした質疑応答へ。
プロダクトマネジメントに関わる方からのお悩みに、3名が直接答えてくださいました。
Q「プロダクトをつくるうえで、顧客(ユーザー)の声を、どういったタイミング/頻度/やり方で収集・反映しますか?また、やってみてうまくいった・いかなかった経験などあれば教えてください。」
- 土岐:
-
先ほど少し話した、ヒアリングやユーザーリサーチをどう生かすか問題ですね。
さっきも言いましたが未だに自分もしっくり来ていないんですが…愚直に自分でお話を聞き、まとめたものを一覧化して、実際にプロダクトをくるときに参照する、ということをしてはいます。ただ仕組みとして固まったものができているわけではないから、もっといいやり方がないかなーとはつねに模索しています。
- 安達:
- 前提としてユーザーヒアリングのタイミングや頻度・やり方が気になっているというときには、絶対にもっと顧客の声を聞きにいった方がいい。そもそもユーザーの解像度が低いと考えられるので、何かしら絶対に動いた方がよさそうだなとは思います。一番いいのは、ユーザーと友達になることなんですけどね。友達であれば、どういう状況で何に悩んでいてどうしてあげたらいいのかって分かるじゃないですか。それくらいユーザーと仲良くなる気持ちで関わってみては。
- 土岐:
- ロイヤルユーザーはいろいろ話をしてくれるんですが、離反ユーザーやこれから使うユーザーの声が一番聞きづらくて難しいと思っています。お二人は何か知見ありますか?
- 小神:
-
僕達のサービスも店舗向けSaaSサービスなので、低いとはいえ一定の数値で解約されることはあります。その場合音信不通のような状態になるがほとんど。だからちょっと迷惑かもしれないけれど実際にお店で何か食べて、お会計した後に「実は…」みたいな形で話を切り出すしかないのかな、とは思っています。解約した顧客の声は取りづらいものの、重要ではあるので。
それ以外だと、トイポではセールスやCSはじめ社員全員がSlackのフィードバックチャンネルに自由に投稿できるようにしています。改善要望や顧客からの課題感といった投稿がnotionのデータベースに連携されるので、週1で棚卸して優先順位つけて上から対応していました。
- 土岐:
- フィードバックを社内で仕組化しているのは素晴らしいですね。
- 小神:
- そうですね、機能が多い分いろんなところで整合性がとれていないところがあるので、それをフィードバックをもとに見つけて対応しています。顧客にとっての課題の重要度と、行っている顧客数や対応工数をもとにある程度notion上で自動で優先順位がつけられるようになっています。ただ、それ通りに対応している、ということはほぼありませんが。
- 土岐:
- 少し前にリサーチカンファレンス福岡という場所で登壇してきたんですが、リサーチ専門の部門がある企業だとリサーチして開発してというのを繰り返していく体制ができている。それはやっぱりすごいですね。スタートアップではなかなかできないですが、自分としてはやってみたいなと思いました。
Q「いざ仕様を考えているとあれもこれもになって機能がもりだくさんになります。MVPのために機能を落としていくコツがあれば教えてください」
- 土岐:
- これは安達さんのためにあるような質問ですね(笑)ミスターMVP、いかがですか。
- 安達:
- これねえ、めっちゃコツがあるんですよ。MVPにおいて僕が大事にしている定義は、「最小の価値を見つけてください」ということ。ユーザーがお金を払っていいと思える最小の価値をまず厳密に定義して、それが実現できる最小のプロダクトを設計する。これがMVPのスタンスです。だから「どこを削ぎ落せばいいかわからない」という人はおそらく、最小の価値がまだ定義できていないんだと思います。ここが定義できていれば、これいらないよね、という判断は自然とできます。
- 安達:
-
2つめは、ユーザーを限定すること。例えばおじいちゃんと女子高生が同じアプリを使うとしたら、ぜったいフィードバックが違いますよね。おじいちゃんにも女子高生にも同じ価値を提供するというのは絶対に無理なので、どちらかにしましょうということ。
3つめはユースケースを限定すること。たとえば山登りアプリだとしても、暗闇で使うのかお昼どきに使うのかで全然違うわけで。だからまずは明るい時に山に登る人に限定しましょうという話。教科書通りのことではあるんですけどね。
- 土岐:
- 教科書通りと言えばその通りなんですが、なかなか難しいかもしれません。価値を定義できているかどうかを見分けるポイントってありますか?
- 安達:
- クライアントにはバリュープロポジションというフレームワークを徹底的に書いてもらうようにしています。それが書けないときは定義できていない、というのが一番わかりやすいかもしれません。ぜひやってみていただけたらいいのかなと。
Q「機能開発のいわゆるWhyはPdMが中心に決めるものと想像しているんですが、そこからWhat・Howに落としていくにあたりどのあたりからPdMの手を離していますか? それともHowに至るまでPdMが細かく見ていますか?」
- 土岐:
- 個人的にはPdMはWHATを担っていると思っています。ただし、WHATを決めるためにはやはりWHYも知らなきゃいけないし定義しなきゃいけない。WHATを軸足に置きながらWHYやHOWも場合によっては自分が動く、というイメージを持っています。
- 安達:
- うちでは全員がWHYをやる、と定義しています。シード期のプロダクト開発の担うことが多いからというのが大きいとは思うんですが。トイポはどうですか?
- 小神:
-
WHATもWHYもやりますし、HOWに関しても「これをやるならこういうやり方だと解決できるんじゃないか」みたいな仮説までは持ったうえでエンジニアやデザイナーの方と詳細設定していく、というのが基本的な流れです。WHATやWHYは絶対にプロダクトマネジメントやっている方の方が解像度が高いので。
逆に、HOWの部分をまるっきり渡すってこともあるんですかね?
- 土岐:
- どういう機能によってこの課題を解決したいのか、というのはWHATとしてPdMが決めて、どうやって解決するか(たとえば言語など)はエンジニアの判断でお任せします、ということはあるんじゃないかなーとは思います。
Q「PdMの仕事の理解のために質問ですが、受託開発ベンダーのプロジェクトマネジャー、スクラム開発のスクラムマスターと似た仕事なのでしょうか?差分があるとしたら何でしょうか?」
- 安達:
-
PdMというのは簡単に言えば「どんなプロダクトがいいか考える人」。スクラムマスターはどんなプロダクトにするべきかという議論には入らず、司会進行や意思決定の進め方の設計をする仕事。受託開発ベンダーのプロジェクトマネージャーも、プロジェクトがスケジュール通りに進行するようにする人だから、どういう機能にするか、プロダクトにするのかという話は本来スコープから外れているはずです。
たとえば僕、実はプロジェクトマネジメントめちゃくちゃ苦手なんです(笑)。セットで頼まれると進まないから、両者の違いを説明したうえでどんなプロダクトにするかは考えますから進行はお願いします、と顧客にはお伝えしています。
- 土岐:
- プロジェクトマネジメントが落ちたときにはPdMが拾わなければいけない、という意味で一部を担うことはありますが、そればかりやっているとプロダクトマネージャーってできなくなってくるんですよね。その辺がもうずっと悩んでいるところかなと。あと、ピープルマネジメントとも間違えられるのもあるあるパターンですね。
- 安達:
-
これはむしろ経営者が意識した方がいいところだと思います。PdMにプロジェクトマネジメントをさせないこと。
もし会場に社長の方がいたら、よろしくお願いします(笑)。
Q「YAMAPのPdMの中にCS対応を担当されている方がいたかと思うんですが、カスタマーサポート(サクセス)はPdMが担当されているのでしょうか? CSはユーザーに一番近い業務なのでPdMにとって情報の宝庫であると思いつつ、CSチームが別途いる状態でどうPdMが入ればいいかわからずもやもやしてます。
- 土岐:
-
もやもやしていますと仰っているので、なんとか解決してあげたいですね(笑)
YAMAPの場合、PdMのチームとは別にCSチームがあります。問い合わせ担当チームがいるので、主にそこのチームと連携しつつ、同時にユーザーからのヒアリングをしています。だから自分の中では割と整理がついていてすっきりしています。
- 安達:
- 質問者の方は、カスタマーサポートとカスタマーサクセスどちらのことを話されているんでしょうね?YAMAPもカスタマーサクセスとサポートを分けていますか?
- 土岐:
- 呼び方の問題ではあると思うんですが、やはりどちらかというとカスタマーサクセスの方に軸足を移していきたいねとは社内で話をしています。
- 安達:
- トイポでも、カスタマーサクセスかカスタマーサポートか、という議論がありましたよね。
- 小神:
- そうですね。toB向けSaaS事業は導入して価値を感じてもらうところまでフォローしないと解約も発生しますしアップセルにもつながりません。だから能動的にカスタマーサクセスのために動きたい、という気持ちでカスタマーサクセスにしました。でもどうしてもサポート業務の方が多くなってサクセス的な動きがなかなかできないということは去年ありましたね。
- 安達:
-
そもそも事業として実現したい価値とか体験っていうのは、プロダクトだけで達成するには無理があります。プロダクトでできない部分を人力でやるというのが、僕はカスタマーサクセスだと思っています。
まず会社としてこの事業で提供したい最小の価値や体験を定義したうえで、プロダクトにはできない価値とか体験を人力でどうフォローするかというオペレーション設計をするというのは結構大事な仕事かなと思っています。
- 小神:
- 初期だとやっぱりプロダクトのクオリティがまだまだ低いので、カスタマーサクセスに依存する割合は高いです。カスタマーサクセスがちゃんとできていないと価値を提供できない状況になってしまうので、その意味でかなり重要な役割を担っているなと。もちろん、その割合を徐々にプロダクトに寄せていくっていうのがやるべきことなんだろうなとは思っています。
- 土岐:
- カスタマーサクセスの行動というのは具体的にどういうことを指しています?
- 小神:
- たとえば初期のオンボーディングから、実際に活用して成果を出してもらうために必要なコンサルティングのようなことですかね。
- 安達:
-
たとえばトイポだと、アプリとしては「お店が1分でアプリを始められる」と謳っているんですけど、実際にはお店の方がすぐ始められない、っていう課題が一時期ありましたよね(笑)
あとはお店のお客さんがお店の中でアプリをちゃんとダウンロードしてくれるような店頭ポップのデザインにこだわったり、どういう特典をつけたりしようか、というのをかなり頑張って議論した時期もありました。
- 小神:
- その節はありがとうございました(笑)
- 安達:
-
だからSaaSや開発初期のフェーズだとPdMがサクセスをやるというのはかなり相性がいいと思っています。質問者の方がどういう会社・フェーズなのかはわかりませんが、むしろPdMとCSで一緒にやれることはたくさんあると僕は思います。
ただ、それは初期だけかもしれません。やはり大きくなってくるとカスタマーサクセスのマネージャーを入れるのがいいんじゃないでしょうか。
Q「PdMをする上の持論、ポリシー、信念のようなものはありますか?逆にこういう考え持ってたら良くないぞ、みたいなのはありますか?」
- 土岐:
-
この質問、最後っぽくていいですね(笑)
私がなぜいままでPdMをやっているのかをあらためて考えてみたんですが、やはり自分自身がプログラマ出身でモノづくりが好き、ということに尽きると思っていて。自分の作ったものが動く、それを人に喜んでもらえるというのが好きで、関わる人の関係性やモノはどんどん大きくなっていっていますが根本的にやっていることはあまり変わらないと感じています。いいものを作るために自分がどういうことをやれば一番効果的か、というシンプルなモノづくりの面白さがあるのかなと。
- 小神:
- 難しいですが…先ほども話した通り、僕の場合は自分自身がこのプロダクトの生みの親ということもあるので、なんていうんですかね、信用、信頼、子供のように接するというか…子供はいませんけど(笑)。とにかくプロダクトが大事なんです。
- 安達:
- めちゃくちゃいい話。つまりは愛ですよね。
- 小神:
-
そうですね、愛することが大切なのかなって(笑)。
PdMやっていると、本当に何というか…プロダクトに対してどうしても辛辣なフィードバックとかあるんですよ。このプロダクトって本当はよくないんじゃないか、全然だめで意味ないんじゃないかという考えになってしまうときもあるんです。でもそう考えだすといい方向に絶対に行かないので、自分で変えて良くしていって顧客に対して価値を提供できるようにするんだ、という観点をもって改善を進めるというのが大事なのかな、とは思います。
- 土岐:
- ありがとうございます。安達さんはどうですか?
- 安達:
-
もう、愛すること以上にいいこと言えない(笑)。
「一番はプロダクトへの愛」っていうオチでお願いします(笑)。
- 土岐:
- ありがとうございます(笑)。トークテーマとしては以上です。
トークセッションの後はピザを片手にネットワーキングタイム!
密度の濃いトークが終わった後は、お待ちかねのネットワーキングタイム。会場でトークイベントに参加した方々がピザを囲み、お互いの仕事やプロダクトマネジメントに関する情報交換を積極的に行っていました!
三者三様の立場からPdMの仕事に関するリアルな意見が交わされ、あっという間だった2時間。 今後「Project Management Fukuoka(PMF)」では、に関わるこうした意見交換やナレッジ共有の場がリアル/オンライン上で設けられるとのこと。福岡のプロダクトマネジメント界隈がますます盛り上がること間違いなしです!
-----------
最後に…各社採用絶賛強化中!PdMが盛り上がる街・福岡であなたもPdMに挑戦しませんか?
本キックオフイベントの登壇者・安達さん率いるシリアル株式会社の関連求人はこちらからエントリー可能! キャリアアドバイザーがエントリー~選考まで徹底サポートいたします。
この会社の求人情報
-
この会社の求人情報はありません
にできること
九州・沖縄のいい職と出会うなら、Kyu-syokuで。
このサイトについて・あなたに対してKyu-syokuができることについて書いています。
© Recruiting Partners Co.,Ltd.