大学では物理を専攻 エンジニアのバックグラウンドを持たないPdM
酒井良氏：「新米PdM奮闘記」と題しまして、株式会社Speeeの酒井が発表いたします。
今日は、僕が得た「今後もずっと大事にしていきたい学び」について話したいなと思っています。また、僕はコミュニケーションの課題をチームの中に抱えていたのですが、それを解決して事業を前に進めようとした話もしていきたいと思っています。そして、この学びを過去の自分や、あるいは今PdMになりたての方々にお届けしたいなと考えています。
つまり、教科書的なテクニックに頼るのではなく、メンバーに向き合って対話することで解決しようという学びをお伝えしたいなと思っています。
自己紹介をすると、僕は株式会社Speeeに新卒で入社して今2年目で、2021年4月からPdMみたいなことをしています。大学では物理などを勉強していて、ぜんぜんエンジニア的なバックグラウンドはないのですが、思考的にエンジニアリングの部分を学んでいました。
今日の話の流れは、チームの状態と葛藤していた時の課題をお話ししてから、僕がいったんテクニックに走ってしまい、迷走してしまった話を失敗談的にしていきたいと思います。次に、そこから僕は立ち直っていったのですが、その時にやっていたことなどをお話ししたいと思っています。
働く中で感じた「なんかコミュニケーションがうまくいっていないな」
まずは、僕のチームのその時の状況、新卒で入社した時に配属されたプロダクトの話をします。僕は、リリースしたばかりのBtoBtoCのプロダクトに配属されて、チームの構成としては事業責任者とPdMの僕、あとはエンジニアが数名いるようなチームでした。
ユーザーの集客部分を強くやっていくことが最初の僕のミッションになっていたので、SEO施策を自分で企画して、それをリファインメントとかの場でエンジニアに説明、実装してもらい、そこから集客の数値などを自分で分析しながら事業を前に進めていました。
ここで僕は、「なんかコミュニケーションがうまくいっていないな」という、ざっくりとした課題感を持ちました。その「なんかうまくいっていないな」という感覚がうまく言語化できないまま、でもうまくいっていないことだけはわかる、そういったモヤモヤとした状況を抱えていました。
それは何かというと、例えば、僕が施策を説明した後の（エンジニアの）反応がすごく薄くて、「本当に僕がやりたいこと伝わっているのかな？」と、伝わっているのかよくわからない感じがあったんです。僕は施策の目的を説明したつもりになっていても、「でも、この施策ってなんでやるんですか？」と説明した直後に質問をもらったりすることもありました。
僕はそういった大小さまざまな事象に対して、どうやって向き合っていったらいいのかがわかりませんでした。でも、なんとなく悪いところとしては、コミュニケーションがうまくいっていないというところと、あとは僕は新卒で入ってSEOなどがわからなかったので、そこの単純な知識不足という2点があるなと考えていました。今日は、コミュニケーションの部分についてお話ししたいなと思っています。
テクニカルにやろうとした結果「やったことが効果を発揮しなかった」
まずは、テクニカルにやろうとしました。「テクニカルにやろうとした」というのは何かというと、僕はPdMという職種を入社してから知ったので、それについてまず相談や勉強をしたんです。
具体的には、他のチームの先輩に「エンジニアとの関わり方ってどうしてますか？」「あんまり反応がないんですけど、どうしたらいいですかね」など相談をしました。「他のチームのエンジニアさんってどういう方なんですか？」みたいなことも聞いたりしました。
あるいは、他のチームのスクラムイベントに参加して、「リファインメントってどういうものなんだろう」「どのように施策を説明しているんだろう」など、実践のイメージを自分の中に作ろうとしていました。
あとは、ネットの記事や本から、PdMはどういうものなんだろうというのを勉強して、本に書いてあることをそのまま自分のチームに還元しようとしていました。
SEOなど、単純な知識の部分は勉強して、「こういう施策どうですか？」みたいなことをずっとお話ししたり、勉強させてもらっていました。
でも、これは結局うまくいかなかったんですよね。今では自分でも（うまくいかなくて）当たり前だろうと思うんですけど。自分がエンジニアを巻き込んで事業を伸ばすことがぜんぜんうまくいかなかったんです。
ただ、「やったことが効果を発揮しなかった」というのが表現として正しいなと思っていて、ぜんぜん僕がやってきたことは失敗ではないと思っているんですよね。失敗ではないのですが、僕が抱えていた、コミュニケーション課題を解決しながら事業を伸ばす点において、うまくいかなかったと解釈しています。
ここでの学びや気づきが3つあります。本に書いてあるようなことや、「他のチームではこうしているんです」というような行動を、チームのエンジニアに押し付けようとしてたことに気づいて、それ自体をすごく猛省しています。
冷静になってみれば、そういうのはぜんぜんうまくいくはずがありません。また、僕は僕でそういうコミュニケーションを押し付けるというか、「こういうふうにしてほしいです！」と伝えるスタイルもそんなに合っていないなと自分でも思っていました。
ただ、うまくはいきませんでしたが、正解がそもそもありませんし、1つも知識や情報がない中で、自分がどうしていくか？ というところでは、「勉強したことをそのままやってみる」というのが、当時の自分のベストエフォートだったので、そのようなことをしていました。
あとは、教科書的なアプローチに書かれている状況と、自分のチームはぜんぜん一致していないんだなというのが、大きな気づきとしてあって、実感を得られたというのが大きかったなと感じています。
この実感から、ではどうしたかというのが、学びの部分かなと思っているのですが、ここから僕は、このコミュニケーション課題が解決するまで、「向き合い続ける」ことにしました。
向き合い続ける中で取り組んだ3つのこと
「向き合い続けるって何？」という感じですが、まず、僕自身がチームのほうにぜんぜん向いていなかったなと思っています。先ほどお話ししたように、他のチームのことを聞いたり、本に書いてあるような一般的な抽象化されたモデルの話を考えていたりと、自分のチームのほうを向いていなかったなと思っています。
「他のチームってこうしているよね」「本にはこう書いてあるよね」みたいな、みんながそれをやっているから僕らもそれをやろう、そのままやろうとするのは、なんか違っていないか？ と思ったんですよね。
「僕らがどうしていきたいか」「僕らのチームだとこういうところは取り入れられるし、こういうところは取り入れられないね」という話は、僕だけでは判断できません。なので、エンジニアチームのみなさんを巻き込んで、一緒に話し合って決めていこうというアプローチを取りました。
「向き合う」について具体的に何をしたかというと、「すでにあるコミュニケーションの場を活用する」「やりたいことの目的を僕が説明し続ける」「僕のやっていることに対してきちんとフィードバックを受け取りに行く」。この3つを特に重視してやってみました。
取り組み1 「すでにあるコミュニケーションの場を活用する」
1つずつお話ししていきます。「すでにあるコミュニケーションの場を活用するってなんやねん」って感じですが、事業を前に進めるというのが僕のミッションであり、やりたいことだったので、そこに対してメンバーと向き合って一緒に進めていく、そしてそれをやりきるというイメージですね。
ここで注意したいのは、僕はエンドユーザーに向けての価値提供や、エンドユーザーに向けた施策を考えていますが、それをうまく活かすためにはチームに向き合う必要があるという点です。
まずは、すでにチームに組み込まれているようなフレームワークがあったので、その運用を徹底していきました。僕のチームだと、OKRやスクラム、KPTなどのフレームワークが存在していて、チェックインやリファインメント、win sessionなど、デイリーやウィークリーでメンバーとお話しするようなタイミングがありました。そこの場で、しっかりとやりたいことを伝え続け、コミュニケーションを取ることを行ったんです。
フレームワークの運用を徹底するのとは別に、雑談をしたり、SlackやGitHubのIssueでのコミュニケーション、質疑応答、「こういうふうになりました」「こういうことが良かったです」などのコミュニケーションも、もちろん取っていきました。
ですが、まずはフレームワークの運用を徹底して、その後しっかりとコミュニケーションの場を確保することで、活用し続けられる状態を作っていきました。
取り組み2 「やりたいことの目的を説明し続ける」
次に「やりたいことの目的を説明し続ける」ということをしていきました。ここは中長期的な部分と短期的な部分の2つがあって、中長期的な部分は、ロードマップを自分で作っていました。ロードマップの説明や「こういうものになっていきたいんですよね」など、プロダクトの世界観の部分で、「僕らはこういう施策をやりたい」「こういうふうにユーザーたちに価値を提供していきたい」という考えを説明し、お互い議論していました。
最初のうちは、僕がぜんぜん説明できていなかった状態だったので、とにかくきちんと説明することをし続けました。そうしていくにつれて、エンジニアからも、「これってどうなんですか？」「もっとこうしたら良くなるんじゃないですか」など、質問や意見をもらえるようになっていきました。
もちろん、ドキュメンテーションも行いましたが、対面やリモートで話すタイミングで、毎回「僕らはこういうプロダクトを作っていきたくて、ユーザーに対してこういう価値を提供していきたいんです」「ユーザーってこういう人なんで、こうなんですよね」みたいな話をずっとしていました。
取り組み3 「フィードバックをきちんと受け取りに行く」
ほかにも、「フィードバックを受け取りに行く」ということをやっていました。僕はずっと「なんかうまくいっていないな」と思っていたのですが、反応がないとかそういうところも含めて、どうコミュニケーションを取っていったらいいのかがわからなかったんです。だから、まずは自分からフィードバックを受け取りに行くことで、改善していこうとアクションを起こしました。
例えば、（スライドを示して）これはそのままエンジニアさんなどに話した内容なのですが、「今の僕の説明でやりたいことは伝わってますかね」「〇〇さんは、今僕がしゃべった内容で見積もりができる状態ですか？」「ちょっとまだ足りない部分もありますか？」「足りなかったら、どんな情報があれば実装できるようになりますか？」など。あるいは、「今、僕がバーッとしゃべったんですが、引っかかるポイントや、不安に思っている点があったら、今教えてほしいです」みたいな。
そういって話を聞きながら、「それはこういう話がありますね」「確かにそれは僕も考えられていなかったので、ちょっと考えてきますね」「こういうふうにしたらいいんですかね、どうなんでしょうね」みたいに相談をしていました。
あとは直接的にですが、反応がないと僕はけっこうつらくなっちゃうので、「もっとリアクションしてほしいです」みたいな（笑）。リアクションを求めるというか、僕がフィードバックするというよりはリクエストすることで、フィードバックを受け取りやすい環境を作りながら、きちんとフィードバックを受け取って、僕の行動やチームの行動を改善していく動きをしていました。
課題が生まれても解決できるサイクルができた
「おわりに」というところで。あらためて、僕が抱えていた課題は「エンジニアとのコミュニケーションがなんかうまくいっていない気がする」という点でした。「なんかうまくいっていない」「うまくいっていないことはわかっているんだけど」というコミュニケーションの課題です。
僕はまず、テクニックに走って迷走しました。（これについては）ぜんぜん失敗ではないなと思っているし、SEOの施策を考えたり、あるいは「PdMとしてこういう立ち振る舞いをしたらいいのかもな」みたいなところでは、すごく学びがあったので、やって良かったなと思ってます。（それらについては）今もやり続けていますが、「事業を前に進めるため」という点においては迷走していた時期がありました。
ここから僕は、だんだんとチームに向き合っていくことにして、「コミュニケーションの場をつくる」「目的を説明する」「フィードバックを受け取りに行く」という3つをやり切ることを徹底していきました。
その結果、課題が解決できたと思っています。とはいえコミュニケーションの課題なので、解決してはまた発生して、それをまた解決していくみたいに、課題が完全になくなることはないと思うんです。でも、発生してもまた解決できるサイクルができるようになりました。
それは「チームで困難を解決していこうぜ！」みたいな感じに、チーム同士で話せるようになったからです。「なんかうまくいっていないな」と僕が思うこともあれば、エンジニアが思っている時もあって、それをチーム内の会話で相談しながら解決できるようになりました。
あとは、シンプルに会話量が増えたなと思っています。お互いを知ることを僕は対話によって実現できたと考えています。対話あるいは同じ方向を向く時間を増やしたことによって、議論なり雑談なり、そういういろいろな会話量が増えたと感じています。
チーム内での対話はメチャクチャ重要
振り返りとして、「やってみてどうだったか」というポイントでお話ししたいのですが、入社して1年目からこの経験ができてすごく良かったなと思ってます。コミュニケーションの課題が発生しても、先ほど言ったように解決していける自信がついたので、その点においてとても良い体験だったし、良い自信になりました。
これから、自分の行動1つで事業がどう進んでいくのか、チームの動きがどう変わるのか、という実感を得られたのも大きかったなと思っています。ちょっと連動していますが、チームの動きを変えるためには自分が変わればいいし、自分が変わろうとする時にまず仲間を知るということ、その対話が大事だなと感じました。
なので、チーム内の対話はメチャクチャ重要だというところが、まとめとしてあるのかなと思っています。「なんでやるのか」「何をやるのか」みたいな、とにかく「Why」を説明しながら「何をやりたいのか」を話す、そして、話し続けることがすごく大事だと感じました。
あらためて、コミュニケーションはやはり双方向的なものであるというのも、当たり前ではありますが感じています。双方向的なものだからこそ、僕からも話すし、相手からも引き出して、しゃべってもらうことをとにかくやっていました。
フィードバックを受け取って一緒に改善するのは、すごく大事だなと思っていて、フィードバックがあるからこそ対話が進み、事業が前に進むことに直接的につながるなと感じています。
フィードバックは現状をより良くしていくためのギフト
最後に僕がお伝えしたいメッセージは、教科書的なテクニックに頼るのではなくて、メンバーと向き合って対話することで課題を解決しようという学びです。ここはあらためてのメッセージになりますが、コミュニケーションの課題はみなさんも多かれ少なかれ、プロダクト開発にかかわらず持っていると思います。仲間を知ることで、対話によって解決できるというのが、僕のすごく大きな自信になったと思っています。
フィードバックはギフトだなと思っていて。（スライドを示し）僕は理系でこういう制御工学などの勉強をしていました。これは「フィードバックってこうなっているんだよね」みたいな、フィードバック回路の図です。目標に対してしっかりと差分を見つけて、まず自分の差分を知ることで目標値に向かって走っていける。フィードバックを受け取れるということは、とても大変なギフトだと、ありきたりな言葉ではありますが感じています。
この1年目の大きな学びを活かして、僕が今2年目にやっていることを紹介します。2年目は、新規事業の立ち上げに奮闘していて、そこでもコミュニケーションの部分の課題がエンジニアに限らず起こっているのですが、コミュニケーションの課題が発生しても解決していけるという自信がついてるのは、すごく大きいなと感じています。
周りに相談して、解決に向けてショートカットしていくこともできるし、最後は僕とその人で向き合って話して、解決していこうというアクションが、勝ち筋の1つとして持てているのがすごく大きいなと思っています。
あとは、「なぜやるのか」という目的を説明し続けたところで「言語化」をしているんですね。この「なぜやるのか」を言語化して説明する重要性をあらためて実感しています。1年目は、エンジニアに向けての説明でしたが、今は事業部長などから投資判断を得る時に「なぜやるのか」「なぜこれが大事なのか」を言語化することがとても重要だなと感じています。発表は以上になります。ご清聴ありがとうございました。
