BOXILでプロダクトマネージャー（以下PM）をしている笹原です。
PMを名乗りだしてから1年が経過し、実際に自分はどういった働きができていたのかを振り返ってみたいと思いました。
そこで、今回は開発チームのエンジニアや企画メンバー、セールスやメディアなど関係する部署の方たちにアンケートに答えていただき、360度フィードバックを受けたのでその結果を共有していきたいと思います。
アンケートの質問項目
答えてもらった設問は10点満点評価1問、記述7問で合計8問です。
- あなたが考えるPMの役割を教えて下さい
- あなたが考えるPMの役割に照らし合わせたときに今期のBOXILのPMは何点でしたか
- 点数の理由を教えて下さい
- PMが行いすぎていた、もしくは行う必要がなかったと思うことを教えて下さい
- PMが行わなかった、もしくは行なっていたが不足していたと感じることを教えて下さい
- PMが行なっていたことのうち、優れていたと思うことを教えて下さい
- 来期、PMに求めることを教えて下さい
- その他、なにかあれば自由にどうぞ
実際の回答を紹介しながら、これから振り返って行きたいと思います。
PMという役割に対する社内の認識
一番最初には『あなたが考えるPMの役割を教えて下さい』という、直接的な評価ではない質問を用意しました。
周りがどういった期待をしているのかを知ることで、現在とのギャップを見たいと思ったからです。
回答を見ていきましょう。
この回答を見て、想定していたよりも回答がバラけたなという印象を受けました。
これは質問自体がざっくりしすぎて回答しづらかったのが一因としてあると思いますが、まだ社内でのPMに対する認識が薄いことも要因としてありそうだなと思いました。
これは次の質問の結果にも表れています。
次の質問は、前述の回答と比べて今期のBOXILのPMはどうか、について評価点方式で回答してもらうものです。Q1で回答してもらったところとどれだけギャップが有るのかを知りたく、10点満点で点数をつけてもらいました。
点数の分布は結構高い点に固まっていました。これは回答者が、PMという役割の者と仕事をする経験が少なく、Q1での回答が私のしていたことに引きずられてしまったことが理由かなと思います。
PMの役割に対する認識が揃っていないことは、他部署との協力が不可欠なPMにはよくはない状況だと思います。
プロダクトによって求められるPMの役割は異なるとは思うので、ボクシルに求められるPMとはかくありき、というものをさらに探り、それを発信していくと周りからの協力も得やすくなるだろうと思いました。
セールスとの連携
BOXILというプロダクトは、ユーザー向けには「法人向けSaaS比較サイト」であり、ベンダーには「SaaSマーケティングプラットフォーム」としてリードを提供しています。
ただ、2020年11月期については注力ポイントをユーザー向けに絞ることとしており、ベンダー向けの施策はあまり行っていませんでした。
ベンダーの方と直接、接点を持っているのがセールスです。今回はセールスの方にもアンケートの協力をお願いしていました。
実際のコメントはこちらになります。
書いてくださっているのですが、あまりフィードバックすることがなかったということがわかる内容になっています。
今期はユーザー向けに注力していたため、セールスとの連携が薄くなっているのは意図していたことではあったのですが、このフィードバックにもそれが表れています。
ただ、振り返ってみると、ユーザー向けの価値提供のための機能であってもベンダーに影響することは少なくなかったです。
ユーザーに対して提供している情報はベンダーに入力してもらっているものであり、ユーザーに対してどのように見られるのかを気にされるベンダーも少なくないからです。
そういった施策を行うタイミングではセールスの方への説明をさせてもらうこともあったのですが、優先度が低くなってしまうこともありました。そういった連携の仕方が『セールスとのコミュニケーションが少し唐突すぎた』というフィードバックにつながったのだと思います。
業務の移譲と分散
PMを名乗りだしてから一年と冒頭で書きましたが、それまではBOXILの開発リーダーをしていました。
もし、今までの経緯に興味がある方がいらっしゃれば、以下の記事にまとまっているので併せてお読みください。
ボクシル開発チームの変遷を振返ってみる - SMARTCAMP Engineer Blog BOXIL開発チームの「今」と「これから」 - SMARTCAMP Engineer Blog 半年間でエンジニアが3倍！！ボクシルチームの変遷をまたまとめてみた - SMARTCAMP Engineer Blog
開発リーダーをしていたところからPMになる上で意識したことのうちの一つが、エンジニアリング業務の移譲です。
データ構造からフロントの設計、インフラの環境などBOXILのエンジニアリングに関するところは、リーダーとして一番詳しいという自負がありました。
だからこそ、エンジニアリング領域に過剰に口出しをしてしまうことを危惧しており、そうならないように意識していました。
その確認の意味合いで『PMが行いすぎていた、もしくは行う必要がなかったと思うことを教えて下さい』という質問を入れました。
その回答は以下になります。
特になしというコメントが大半で、エンジニアリングに関する回答はありませんでした。
この結果は意識していたことが他者から見ても達成できていたことの表れだと思ったので、嬉しかったです。
ただ、逆に企画に関してはタスクの分散がうまくいっていなかったことが、フィードバックから分かる結果となりました。
『PMが行わなかった、もしくは行なっていたが不足していたと感じることを教えて下さい』という質問でも、
- （企画チームのメンバーから）全部に対してする必要はないけど、時々説明をもう少ししてもらいたいなということはあったかな。
- 企画チームの組織化・マネジメントができれば、もっと上流に集中できたかもしれない。
というようなフィードバックもあり、PMとしての領域についてはもう少しタスクを分散することでうまくいくところがあったのではないかと思います。
定量分析と情報共有
『PMが行なっていたことのうち、優れていたと思うことを教えて下さい』という質問では、主に定量分析と、情報共有に関して書いてくれている人が多かったです。
定量分析については、BOXILの中でデータアナリストが設けられていなかったため、足りない部分を埋めるためにPMである私がやっていたので、そこを評価してもらったのだと思います。
また、もともとBOXILのエンジニアをしていたこともあり、テーブル構造やログ仕様についても詳しかったため、仮説を立てたり、施策を評価するために必要な分析を適切に行うことができました。
定量分析を評価してもらったのは、もう一方の情報共有がうまくいっていたこともその一因ではないかと思います。
BOXILでは開発をScrumで行なっており、情報共有の場としてSprint Reviewが活用されています。Sprint Reviewにはセールスやメディアと言った他部署の方にも積極的に参加してもらっており、仮説をたてるために行なった分析や、施策の評価も共有しています。
Sprint Reviewを盛り上げるためにチーム全体で試行錯誤してきた結果が回答として表れており嬉しいです。
ただ、定量分析がしづらい領域について、適切に定性的な評価をすることはあまりできていませんでした。
『PMが行わなかった、もしくは行なっていたが不足していたと感じることを教えて下さい』という質問でも以下のようなフィードバックがありました。
数字に対する目標を定めるのはとても早く、迅速に感じたが、数字以外の要素で判断する明確な基準があまり定まっていない気がした。 そのため、低い数字が出てから対策、その結果がでたらまた対策と言ったような施策の進め方になってしまい、後手後手で回ってしまった気がする。
終わりに
この一年間、PMとしてやってきたことを360度フィードバックを用いながら振り返ってみました。
PMは多くのステークホルダーとの密接に関わりながら仕事を進めていくので、他者からのフィードバックを得ることは大事だと思います。
この機会に、いつも関わっている方たちから様々なフィードバックが得られたので良かったです。
