こんにちは！ TRILL開発部PdMの米田（@rice_ynd）です。
この記事は「dely #2 Advent Calendar 2020」18日目の記事です。
昨日はTRILL Android担当 永井さんの記事「Merged Manifest を使って uses-permission を調査した話」でした。
dely #1 Advent Calendar 2020 - Adventar adventar.org
dely #2 Advent Calendar 2020 - Adventar adventar.org
さて今回の記事ですが、プロダクト開発においてPdMが果たすべき役割について書いてみたいと思います。
「PdMに任命されたけど、何をしたらいいの？」な人や「言われたことを言われたとおりにしかできない。やばい。」な人にぜひ読んでみてほしいです。
そもそもPdMって？
一口にPdMといっても、プロダクトやチームの規模やフェーズ感、そのチームが担う責務によって細かく役割は異なるかと思います。
ただどんなプロダクトやチームにおいても本質は変わらないと考えていて、「プロダクトをより良くするために、方針を指し示し舵を切ること」がPdMの役割だと思っています。
いまチームがどこを向くべきで、そのために何が必要かをメンバーに明示し、それをマネジメントすることができている状態が、PdMとして正しい役割を果たせている状態だと言えると思います。
そもそもPdMがどうあるべきかという包括的な話は、弊社で新規事業開発をしている奥原さん（@okutaku0507）の記事「プロダクトマネージャー1年目の教科書」が参考になりますので、興味がある方はぜひ読んでみてください。 note.com
"伝書鳩"になっている状態
では、どのような状態がPdMとして正しい役割を果たせていない状態なのでしょうか。
PdMに限らず、チームを推進する立場にある人が陥りがちなのが"伝書鳩"になってしまう状態です。
これはわかりやすく、PdMとして正しく機能していない状態であると思います。
具体的にどういうことかというと、例えばPdMにあたる役割の人が
- 他部署や他チームからの依頼や相談をそのまま自チームのメンバーに伝えている
- 経営層や上長の提言をそのまま方針としてチームに指し示している
- 物事の優先度が"言われた順"になってしまっている
に当てはまる状態は、怪しいです。
これらが具体的にどう正しくないのか、ひとつずつ見ていきます。
◯ 他部署や他チームからの依頼や相談をそのまま自チームのメンバーに伝えている
これ自体が悪いというわけではありませんが、依頼の意図や相談によって解決したいことなど、本質を理解せずにチームに落とすだけではPdMを介する意味がありません。
むしろフローがひとつ増える分、コストが増えてしまいます。
その依頼を遂行すること or 相談を解決することで
- 何が改善するのか
- どんな価値が生まれるのか
- どんな負が生まれるのか
などを理解し、優先順位を決定したり、足りない情報を補完したり、時に別の提案を返したりと、プロダクト開発をスムーズに推進するための付加価値を生むことがPdMの役割として適切です。
◯ 経営層や上長の提言をそのまま方針としてチームに指し示している
前述の項目とほぼ同様ですが、意思を持たないPdMはチームに必要ありません。
他者の意見やアドバイスを咀嚼し、それがプロダクトにとって本当に必要かどうか、有効な打ち手かどうかを見極め、施策に取り入れるなどの判断をするのがPdMの役目です。
◯ 物事の優先度が"言われた順"になってしまっている
「プロダクトをより良くする」ためには、数多ある問題の中からインパクトの大きいものを課題化し改善していく必要があります。
"インパクトの大きいもの"を測る観点として重要なのは、事業KPIに与える影響やユーザーに与える体験の質などです。
このインパクトの大小を根拠を以て判断し、対応コストを考慮した上でどこから手を付けるべきかを意思決定します。
言われた通りに物事を進めたら、何も進んでいなかった過去
偉そうにあれこれ語っていますが、これらはすべて過去の経験から学んだことで、自戒の意味もありこのテーマにしてみました。
まさに伝書鳩が原因で失敗した話ですが、とあるサービス課題を解消するために企画領域の担当者から施策の相談を受けたことがありました。
それを言われるがままタスクとして積み進行しようした際に、実装担当のエンジニアから指摘を受け、様々な観点において考慮すべき点が考慮されていないことが発覚しました。
発覚した時点ではすでに要件も仕様もfix、スケジュールもほぼ確定。
結局漏れていた観点を再考し、施策内容自体が変更になりスケジュールも引き直すはめに。
この失敗においては、あらかじめ施策の意図を理解し、プロダクトへの影響範囲や仕様や設計上の懸念点、リソース状況などを把握した上でどう進めるかを判断すべきでした。
とはいえ、例えば非技術者のPdMが実装についてすべてを把握したり、管轄外で走っている施策への影響を考えたりというのも現実的に難しかったりします。
ひとりで考え込まず、早い段階で有識者を巻き込み意思決定するというのもプロダクトマネジメントにおいては重要なポイントです。
担当プロダクトにおける「良し」を定義しておくこと
冒頭で「いまチームがどこを向くべきで、そのために何が必要かをメンバーに明示し、それをマネジメントすることができている状態」をPdMの果たすべき役割と述べました。
基本的に"改善"は、理想と現実のギャップをひたすら埋める作業だと考えています。
理想が存在しないプロダクトにギャップは存在しません。つまり、改善は行えません。
PdMは何よりもまず、プロダクトがどうなることが「良し」なのかを知っておくことが重要です。これがあらゆる意思決定における指針となります。
先に挙げた「"伝書鳩"になっている状態」は、プロダクトに対するPdMとしての意思が存在しないために他者の意見や依頼をそのまま受け入れざるを得ないことでそうなってしまっているというパターンが多いように思います。
月並みですが、プロダクトを理解し、ユーザーに寄り添い、どうなることがそのプロダクトにおいて理想かをひたすら思い描き、そこにチームを導く意思を持つことが脱"伝書鳩"の第一歩です。
まとめ
今回は、"伝書鳩"が意思を持ってプロダクト開発を推進するために気をつけるべきことをお伝えしました。
- プロダクトの理想形を思い描く（「良し」を知る）
- 現状と理想とのギャップを知る
- ギャップを埋めるために、施策の優先度を根拠を以て正しく整理する
- 自分がチームを理想形に向かわせる意識を高く持つ
かくいう自分も初心忘るるべからず、これらの意識を念頭に置いて今後もTRILLを推進していきます。
明日は、TRILL開発部 フロントエンドエンジニアのmaseoさんによる「Google Optimizeでテストをしてる話」です。お楽しみに！
積極募集中
delyでは一緒にサービス成長させるエンジニアを積極採用中です。 興味のある方はぜひカジュアルにお話ししましょう！
また、delyではTechTalk という社内のメンバーがテーマ毎に話すイベントも開催していますので、こちらもぜひチェックしてみてください！
