こんにちは！
dely開発本部でクラシルのサーバーサイドエンジニア兼PdMを担当しているyasuoです。
この記事は「dely #1 Advent Calendar 2020」の5日目の記事です。
昨日はfunzinさんのRenovateをiOSアプリ開発に導入してみたという記事でした。 ライブラリの自動アップデートに興味がある方はぜひご覧ください。
本日は「エンジニアがゼロから始めるプロダクトマネジメント 」というテーマで、僕自身が2020年7月にプロダクトマネージャー（以下、PdM）となってから約5ヶ月間で得た学びを、よかったこと3選という形でご紹介したいと思います。
PdMになった背景
6月以前のクラシル開発本部は、全員同じスクラムに所属して開発を行なっておりましたが、規模の拡大に伴ってSquad体制化し、分解したKPI毎に小規模チームを作り、各チームに権限移譲をすることになりました。
それに伴って、各Squadに1人PdMを立てることになり、1つのチームのPdMを僕がやっていくことに決まりました。
詳しくは以下のTweetをご覧ください。
delyのエンジニア・デザイナー採用ページリニューアルに伴い開発カルチャースライドをアップデートしました！全てが実現できているわけでは無くまだ成長過程ですが方針が伝わると嬉しいです。共感いただける方ぜひお茶でも行きましょう！https://t.co/vQmng5x0Iz pic.twitter.com/0ZzUqDWBwy
— 坪田 朋 / クラシル (@tsubotax) 2020年8月28日
それでは、いよいよよかったこと3選を紹介していきます。
よかったこと3選
PdMをやるにあたって、本や記事で学んでやったこと、実際に取り組む中での失敗から学んでやってみたこと色々ありますが、中でも特にやってよかったと思っている取り組みを3つ紹介したいと思います。
1. ステークホルダー間で登りたい山だけでなく、登り方まで合意する
こちらは僕が失敗から学んで改善したことの1つですが、この取組みをやる前の課題として次のようなことがありました。
- 関連する他チームに自分たちのチームがやろうとしていること、やったことがきちんと伝わっていない
- 関連する他チームからの差し込みによって、計画通りに開発を進められない
多くの会社において、部署毎やチーム毎の目標を決めてその達成のための計画を立てて仕事をするというのはやられていることだと思いますが、一方で他部署・他チームの目標や達成計画まで頭に入れながら仕事をしている人は少ないのではないでしょうか？
僕も最初はチーム内のことだけで精一杯で他チームがやっていることの把握や、自チームでやっていることを他チームに伝えるということがほとんどできていませんでした。
その結果、チームの信頼や評価が思うように得られず、他チームを巻き込まないと実現できない施策を思ったように進められなかったり、他チームの目標達成のために必要な開発が緊急で入ってきて、自分たちの目標達成のための施策が後回しになるというようなことが発生していました。
そこで、関連するチーム間で、お互いの目標・ロードマップを共有し合う場を設けることにしました。
結果、チーム間で協力し合う必要がある施策が可視化され、事前に余裕を持って懸念事項について議論することができるようになり、上述したような課題が解決することができました。
2. ユーザーの定性、定量的な理解
多くのプロダクトマネージャーに関する書籍や記事に書いてあることですが、プロダクトマネージャーの重要な役割の1つにユーザーに関する深い理解というものありますが、クラシルにおいてもこれはとても大切だと思います。
僕がPdMになって最初にやったことは、徹底した定量理解で、クエリを書きまくって重要な数値をとにかく可視化し、どこに課題があるのか大枠を理解するということでした。
ここまでは良かったのですが、僕の場合は定性理解を最初サボってしまったのは失敗でした。
定量理解だけでも既存機能の改善程度ならうまくいくこともあるのですが、新しい価値をつくったり、より多くユーザーに満足してもらうためには、ユーザーの行動・心理を深く理解しないと的外れな施策となり、ユーザーに刺さらないということをこの後痛いほど痛感することになりました。
定量分析よりもかなり手間はかかるのですが、ユーザーインタビューをしっかりやることで、「この機能をリリースしたらあの人が喜んでくれそう」と具体的な1ユーザーをイメージしながら企画をすることができるようになったのがとても良かったと思っています。
3. 経験値の共有
これは僕たちのチームオリジナルの取り組みというよりは開発部のカルチャーの1つですが、意思決定のプロセス・理由をチーム全員で共有するということを徹底して、良いプロダクトをつくる上でとても大切なことだなと思っています。
施策実施前に目的、期待する効果、どうやって効果検証するか、成功の定義など、PdMが施策に関して考えていることをドキュメント化した上でチームメンバーで、それを更にブラッシュアップしてから開発することで、PdM1人で考えるより明らかに良い施策になりますし、開発も言われたものをただ作るよりもより高いモチベーションで行うことができています。
また、リリース後の効果検証についても数値を可視化した上で全員で行い、今回のリリースでどういう学びがあったか、ネクストアクションをどうするかの意思決定にも全員が関わるようにしています。
最後に
本記事では、僕がエンジニア兼PdMにチャレンジする中で得た学びをご紹介させていただきました。 PdMというキャリアに興味を持っている方や、現在PdMをしている方にとって少しでお役に立てれば嬉しいです！
明日はMatsuokaさんの記事です。お楽しみに！
また、dely ではエンジニアを絶賛募集中です！ ご興味ある方はこちらのリンクからお気軽にエントリーください！ join-us.dely.jp
さらに、定期的に TechTalk というイベントを通じて、クラシルで利用している技術や開発手法、組織に関する情報も発信しております。 ノウハウの共有だけでなく、クラシルで働くエンジニアがどんな想いを持って働いているのかや、働く人の雰囲気を感じていただけるイベントになっていますので、ぜひお気軽にご参加ください！ bethesun.connpass.com
