"hey Talk" PdM #2「エンジニアと連携した優先順位決め」を聞いてきました #heytalk
はじめに
「企画側と開発側で深く議論して優先順位決めるの難しいなー」と課題を感じていたところ、heyさん主催の勉強会を見つけたので参加してきました。
tl; dr;
- 「やらなければならないもの」はやった先に何が得られるかを明確にすることで、着手順を明確にできたり、取り組むモチベーションをあげることができる。
- 工数大・リターン大のものはロードマップ積む、工数小・リターン中のものは手が空いた時にやっていく。
- 職種間を超えて意思決定をするには腹落ちしてもらえるまできちんと伝え合う努力をする必要がある。heyでは随筆のような長文ドキュメントをしたためる文化があり、それを活用している。
LT① 「STORES 決済における【攻めの安定性】」
プロダクト開発で考えなければならないことは2つあり、バランスを保たなければならない。
- やりたいこと
- やらなければいけないこと
プロダクトの「最適なバランス」はフェーズによって異なる。STORES決済は「やらなければいけないこと」がたくさんあるフェーズ。
「やらなければいけないこと」を「やりたいこと」に変えられると良い。 変えるには「チーム全員が顧客の事業のために必要なことだと理解し、腹落ちする」必要がある。 より具体的には「客が体験するストーリーと紐づけて理解する」必要があると考えている。
決済は客からみて引っ掛かりがあってはならない重要な要素だと考えている。 安定稼働はあたりまえのことではなく、サービスの強みではないかという発想の転換に至ることで、安定稼働という「やらなければいけないこと」を「やりたいこと」に変えることができた。 安定稼働が他社との差別化になるまでやり切りたいと考えている。
プロダクトマネージャーは、なんでもないことにも面白みを見つけられるような素養があると良いのではないか。
LT② 「エンジニアから見た hey の PM とプロダクト開発」
開発チームは職能横断チームで構成されている。目的はコミュニケーションの円滑化と、チーム内の意思決定を促すことである。
開発チームではプロジェクトを理解したり、自律的なチームを育む取り組みをしている。例えばプロジェクトのREADME(入隊キット)を用意したり、ドラッカー風エクササイズを実施したりしている。
PdMは「何のためにやるか」を考える責務がある、先の開発チームは「どうつくるか」を考える責務がある。 PdMは開発チームから「顧客の理解」について強い信頼(期待)が置かれている。
エンジニアリングマネージャーはプロダクトロードマップの計画をPdMと一緒に作ったり、プロジェクト開始前の事前調査(プリプロジェクト)のサポートでPdMと協力している。
PdMはいろいろ大変なこと・求められる責任の大きさがあるが、「コアの課題を見つけてフォーカスできる」「たくさんのステークホルダーからコアの課題を引っ張り上げる」ことがすごいと思っている。
トークセッション
やりたいことがたくさんある中で、やらなきゃいけないMUST案件をどう扱って優先順位決めるか
「やらなきゃいけないこと」は締め切りが決まっているのでやらないといけない。なので「やった先に何が得られるのか」をイメージして動くようにしている。 それが見えるとやらなきゃいけないことの中でもどれを先に取り組むかが見えてくる。 法律で決まったことは「やらなければいけない」だが、人が「やらなきゃいけない」と言っていることはそうでないことがある。 きちんと見極める必要があり、思考停止しないように気をつけている。。
ユーザーから寄せられる多種多様で膨大な要望に対して、やる/やらない、いつやるの優先順位をどう判断するか
[1例目] 要望は社員がGoogleフォームで気軽に投稿できるようにしている。Zapier経由でGitHub Issue化している。 エンジニアが週次リファインメントで工数感を相談している。その後「小案件リスト」化して着手しやすい状態にしている。 「小案件リスト」から汎用的な課題、かつ1〜2スプリントで完了するものを優先してスプリントに割り込ませている。 全体ロードマップは別途あるので、それを邪魔しないように一石三鳥が狙えるものを優先している。
[2例目] 組織規模が小さい時は毎週集まって顧客の声を議論していたが、現在は月一で報告会を開いている。 問い合わせのサマリ・推移などの定量情報や、顧客の生の声のような定性情報も共有している。 「解決したい課題」「発生原因」「解決案」まで整理した状態で共有している。
[3例目] Googleフォーム→slack投稿でカジュアルに要望を集める仕組みを設けている。 週次定例でCS Manager/PdM/EM/Designerが集まってロードマップに組み込むか検討する。 ロードマップは「将来あるべき姿」で作る。登り方は後から考える。
Q: ロードマップとユーザー要望との優先度ってどう決めているか
技術的負債とどう向き合うか
影響度・返済コストがある。 エンジニアから見てまずいものはエスカレーション・提言して、PdMから信じてもらい、エンジニア主導でやらせてもらうことがある。
ロードマップ作成。中長期のやることと短期のやることの紐付け
長い文章を書く文化があり、ドキュメントを活用して「まきこみ・議論・共有」を重要視している。 「決めたことを伝達して終わり」ではなく「理解して腹落ち」してもらうことを気をつけている。
感想
メンバー間のゆるい会話をたくさん聞くことができ、「良い会社なんだろうな」ということが終始感じられました。 思いを文章化する文化、職種間で互いの立場を理解してもらおうと努力する姿勢が根底にあることで、うまく優先順位づけが議論できる文化につながっているのだろうと感心しました。見習えるところは自社でも取り入れていきます。
