新米PdM奮闘記～プロセスやツールよりも個人と対話を～

これはなに

デジタルトランスフォーメーション事業本部イエウール事業部PdMの酒井です。2020年に新卒でSpeeeに入社しました。
新卒で入社し、配属先は「おうちの語り部¹」というリリースしたばかりのBtoBtoCの新規プロダクトのPdMとして、主に集客面でSEO開発の企画とディレクションを行っていました。

開発PdM1年目の学びを当時課題と感じていた出来事を振り返りながら棚卸ししました。
振り返ってみると当時感じていた課題は結構あるあるなものだと思いますし、社内にもPdMの先輩が多いわけではなく、色々な方が書いた記事に助けてもらっていたので、同じように困っている人の少しでも助けになればと思っています。

学び

結論から書くと、結局コミュニケーションが大事です！

コミュニケーションは双方向である
なぜやるのか、なにをやるのかを説明し伝え続けることは大事
リアクションは貴重なフィードバックである

当時の状況と課題

状況

リリースしたばかりのプロダクト
目標はOKRで運用していた
チームメンバーはごくわずか
- 事業責任者
- エンジニア数名
- PdM（酒井）

PdM（酒井）が抱えていた課題

私はこのような状況で、開発を進めるうえで以下のようにエンジニアとのコミュニケーションに課題を抱えていました。

エンジニアから「この施策ってなんでやるんですか？」という質問が多い
施策の説明をしてもエンジニアからのリアクションがない（いまいち伝わっている感じがしない）
リファインメントの時間が長引くことが多い

どうしたか

ここでは3つに絞って会話します。

まず、徹底的に先人の肩に乗った
目的を説明し続けた
リアクション・フィードバックを受け取りにいった

これらのアクションを並列で行うことで、抱えていた課題はだいぶ解消されていきました。

まず、徹底的に先人の肩に乗った

すでにチームに組み込まれているOKRやスクラムのようなフレームワークの運用を徹底し、上記の取り組みに集中できるように決めました。

OKRについては本やブログ記事を読んだり、定期的に社内の記事を読み返して自分がハマった失敗に気づいて改善策を考え行動したり、チームで振り返ったりしながら運用改善を進めていきました。
スクラムについても、スクラムとは？というかアジャイルとは？というくらいの初心者だったので、アジャイルソフトウェア開発宣言を読んだり本を読んだりしました。けどなんだかんだ、すでに感覚をもっているエンジニアの方々に質問しつつ行動してみて、実践知を積んでいくことで分かっていった気がします。 tech.speee.jp

目的を説明し続けた

シンプルに、「なんでやるのか」の説明をするようにしました。集客の施策目的から、半期のロードマップなど、幅広く目的（あるいは目標の達成戦術）についてエンジニアに話し続けました。
そのなかでも大切なことは何回も伝えることと、具体的に伝えることの2点を意識しました。

一つひとつの施策の目的について説明することはもちろんですが、リファインメントの最初に目標（OKR）と見込みと課題と打ち手を話すようにしました。
そうすることで「なんのための施策なのか」「リリースによって成したいこと」が、施策単体より大きい粒度で伝わりプロダクト理解につながることを期待しました。
結果として、チームの自己組織化（自分ごと化）が始まっていきました。たとえば、以下のような効能がありました。

次のスプリントではどこまで開発する必要があるのか。それを達成するために、工夫はできないか？といった議論が活発になる
また、施策目的についても「すぐには効果が見えにくいがこの長さの時間軸では効果がある」というような施策に納得感をもって開発する
ロードマップをみるとこの時期までにこういったリファクタリングをしておいたほうが良いのでやりたいです。とリクエストが生まれる
エンジニア同士での主体的に振り返りが生まれる
PdMとのコミュニケーション不足による開発の作業戻りが減る

リアクション・フィードバックを受け取りにいった

チームのエンジニアから、施策についての疑問点などについてのリアクションがほしいタイミングでも受け取れないことが多く、自分としては「うまく意思疎通できていない感」を感じていたのですが、「何がどう伝わっていないか」がわからない状態でした。そこで、リアクションがないとどうにも改善できないなと考え、特に3つ意識して取り組みました²。

自分の課題定義能力の低さを、リファインメント前に壁打ちすることで解決する
リアクションをリクエストする・問を投げかける
相手に沿った伝え方を意識する

ここまでやって、結果的に開発物の認識ずれを減らすことができたし、チームのエンジニアもスムーズに実装を進められる様になり、開発のベロシティを高めることができました。

自分の課題定義能力の低さを、リファインメント前に壁打ちすることで解決する

自分の要件定義の能力が低いという課題が間違いなくあるだろうと考え、それを解決するためにリファインメント前にエンジニアから企画した施策についてフィードバックをもらう時間をいただきました。
具体的には、施策の説明をして、「xxxさんなら今の状態で見積もりできそうですか？あとどんな情報があったら見積もりできますか？」を質問して、必要な情報を聞いていました。

リアクションをリクエストする・問を投げかける

チームメンバーに直接「やりたいことは伝わってますか？」「もっと反応がほしいです」「引っかかっている・不安な点があれば教えてほしいです」といった問いかけ、リクエストをしました。
結果として、なぜこの施策を開発するのか？施策がどうKRに紐づいているのか？という部分でエンジニアの納得感を得ることができていないときがあることが分かりました。
また、エンジニアのみなさんが積極的に質問や反応をするようになったことがとても嬉しかったです。

相手に沿った伝え方を意識する

また、エンジニアの方々が作業しやすいようなissueドキュメントを書くように改善していきました。
PdMの話した／書いたものをみて実装するのはエンジニアなので、チームのエンジニアに「こうしたら読むとき／実装するときわかりやすい」の観点でフィードバックを貰いに行きました。
「なぜやるのか」が明確にわかることが重要だと考えている方もいれば、「このissueでなにを実装するのか／しないのか」が明確にわかることが重要だと考えている方もいることが分かりました。

どうだったか

1年目からこんな体験ができて本当に良かったと思っています。
大げさですが、自分の行動一つで事業の成長角度や、チームの動きが変わるという重圧は大きかったです。
そんな環境だったからこそ、大小問わず意思決定の機会が毎日あったことは、なんか強い体力がついた気がします。

忘れちゃいけないことは、エンジニアのみなさんのご協力があってのチャレンジ環境と学びだということです。
不安も多くあったんですが、課題に向き合って一緒に事業成長に向かって走りつづけられたことが、まじでいい体験でした。

学び

コミュニケーションは双方向である
なぜやるのか、なにをやるのかを説明し伝え続けることは大事
リアクションは貴重なフィードバックである

まさに同じようなところで苦労している、、という方やSpeeeに興味がある方、ぜひカジュアルにご連絡ください。
https://twitter.com/ryo_touch

追記：2021/12/01

プロダクト筋トレコミュニティのプロ筋Confに「新米PdM奮闘記～プロセスやツールよりも個人と対話を～」というタイトルで発表させていただきました。

スライドはこちらです：
speakerdeck.com

おうちの語り部は、不動産売買経験者から体験談を集めた、不動産会社の口コミ・評判サイトです。（https://ouchi-ktrb.jp/）↩
※番外編※
感想や意見を吸いあげるために、通常のKPTに加えてリファインメントの振り返り時間も設けたことがありますが、期待していた効果を出せず2週間位やってみて辞めました。
その後はKPTの中で会話したり、話しかけに行って自分の振り返りをメンバーにぶつけて対話するような形に変えたりしていきました。↩