hey初のPMイベントを開催しました！（質問への全回答&資料共有あり）
heyでSTORESのプロダクトオーナーを務めている御守です。去る2月25日に、heyとして初のPM向けイベント「"hey Talk" Product Manager」を開催しました。第1回のテーマは「データ分析を活用したプロダクト開発」。CPO塚原をはじめとしたPM陣に加え、hey1人目のデータアナリストである西村も登壇しました。
このnoteでは、当日答え切れなかった全質問への回答、参加者の方々の反応、当日のスライド資料、などを紹介しつつイベントを振り返ります。（※ 後半にログミー様による全文記事を紹介しております）
（なお、早速第2回イベント「エンジニアと連携した優先順位決め」を3/30(火)19:30から開催しますので、こちらもぜひご参加いただけるとうれしいです！）
200人以上の方にご参加いただきました！
初イベントで人数が集まるのか本当に不安でしたが、応募者272人、当日参加者200人以上、とたいへん多くの方にご参加いただきました。参加者満足度は87%。次回は90%を目指します。
当日はハッシュタグ #heytalk に多くの方から投稿いただきました。一部の感想をご紹介します！
結論だけ共有して説明するくらいの視点しか持ってなかったので、データ分析の結果だけじゃなく、その結論に至る過程も共有して、議論が生まれる土壌も作っているという話も聞けて良かった。#heytalk
— もいもい (@mori_samidori) February 25, 2021
社内にデータアナリストは居ないし、メインのプロジェクトでも顧客含めてそういう役割の人は居ない。
— Fuzico (@RNG75) February 25, 2021
知りたかった「より喜ばれるサービスにするためのデータ活用」について、かなりライブ感がある形で聞くことができた。基本スタンス・着眼点・注意点って、こんな感じなのかー。#heytalk
今までデータアナリストと一緒に働いたことなかったので、分析は全部自分がやらなきゃ！みたいな気持ちになっていたところがあった...が、今後はサービスの改善にあたって、施策立案の段階からデータアナリストをバンバン巻き込んで一緒にサービスをよくしていきたいなという気持ちになった#heytalk
— マキヤマミルテ@SUZURI (@_mmakiyama) February 25, 2021
いただいた質問にすべて回答します！(全20問)
当日答え切れなかった質問と、事後アンケートでいただいた質問に対する回答をまとめました。プロダクト開発において切り離せない「データ」については、私たち含め多くのPMの方にとって悩ましいテーマのようです。本イベントが少しでもヒントになればうれしいです。
まずはPMによるプロダクト開発や施策分析系の質問です。
Q1.「なぜ」を明確にして説明する部分の、具体例が知りたい。
[STORES 予約 | PM 西岡]
去年、担当した品番管理機能という機能の要求仕様書では、「プロダクト戦略上の狙い」というアジェンダを一番上に記載しました。具体的な内容はプロダクト戦略にも関わる部分でありここで記載できないのですが、競合含めた市場でのポジショニングやなぜこのタイミングでこの機能を開発する必要があるのかという点に関して記載しました。
Q2. 定性的な情報（例えばオーナーさんのインタビューなど）を意思決定にどう活かしているのか。定量データと定性データのバランスはどうしているか。
[STORES 予約 | PM 西岡]
定量データでは、機能の利用や結果の数値を把握することは出来ますが、利用している（利用していない）ユースケースを理解する事は絶対にできません。特に弊社のようなオフラインでの作業も発生するプロダクトは、ストアオーナー様ごとにユースケースが多様化している事が多いです。
こうしたユースケースを把握せずに機能開発を進めてしまうと全く利用されない機能開発をすすめる危険性があるので、ニーズが発生するタイミングと状況は事前にヒアリングなどを通じて情報を整理する場合が多いです。
また、定性的な情報はプロダクトの新しい可能性を発見できる機会でもあります。想定と違うユースケースを抽象化して新しいターゲットユーザーとして定義することで事業の成長を促せる場合があります。不確実な未来のあるべき姿を考える点において、定量データだけではなく定性的な情報をもとに意思決定する必要があると考えています。
Q3. 西岡さんのスライドに出ていた Issueの判定 について、選定したIssueに対してどういった形で良し悪しを図るのか。意識していることがあるか。
[STORES 予約 | PM 西岡]
プロダクトやビジネスモデルにも依存すると思うので一般的な回答になってしまいますが、すぐに施策レベルで優先順位をつけないように気をつけています。社内や顧客からは「Aという施策をやりたい」という切り取られた内容が共有される事が多いです。PdMとしては、施策内容を抽象化して、「誰のどのような課題に対しての施策」なのかという部分を言語化し、課題レベルで優先度を決めるようにしています。
例えば、「配送量が多いストアの配送作業工数を削減したい」という課題と「初めてECストアを使うストアの配送作業を簡単にしたい」という課題は、プロダクトとしてどちらのほうが先に解くべき課題なのかを考えます。その課題の優先順位が決まったあとに、よりインパクトが出せる施策を検討するようにしています。まとめると「課題の優先順位」->「施策の優先順位」という思考過程を意識しています。
Q4. 売上への効果は長期目線で見ていると思うが、施策の効果自体はどのくらいのスパンで出ている想定で追っているか。長期的にしか売上が上がらない構造の中で、優先順位付けはどうやってしているか。
[STORES 予約 | PM 西岡]
施策の効果は、基本的に利用されているかどうかを計測するため、リリース後1週間以内・1ヶ月と幾つか確認ポイントを設定して計測し、社内レビューをまわしています。（優先順位付けの話は上記Q3.の回答をご参照ください）
Q5. 施策が失敗した、と判断するときに迷われるケースなどはあるか。基本すぐ判断できる場合が多いのか。
[STORES 予約 PM 西岡]
機能企画時にこれぐらい利用されるのではないかという事前の見立てを実施しているので、リリース後一定期間経って計測したあとに事前の見立てを大きく下回っていたものに関しては、基本的にあまり筋が良くなかったと考えています。
ただ、これを失敗したと認識するよりは、事前の想定していた仮説の間違いに気づける機会として捉えています。事前の見積もりも含めて、どの部分で前提認識が違っていたのかを振り返り、次回以降の開発に活かしていくことが重要だと思っています。
Q6. 機能の認知度はどのように計測しているか。
[STORES 予約 | PM 西岡]
すべての機能の認知度を定量的に把握する事は難しいと思っています。
機能リリース後は可能な限りリリースの告知を実施し、後ほど顧客と対面しているカスタマーサクセスチームやサポートチームを通して顧客が正しく認知しているかどうかのフィードバックをもらう場合が多いです。それでも利用率が上がらない場合は、事前に想定していたターゲットユーザーに対してメールを送付し、利用率が上がっていない理由を深堀りする場合もあります。
Q7. すぐに効果が出ないというお話でしたが、効果が出るまでに間に他の影響要素もあるかと思う。それぞれの施策・機能追加をどのように切り分けて効果測定しているか？
[STORES 予約 | PM 西岡]
現状では機能リリース時のスプリットテストを実施していないため、正確に機能の効果を把握するのは不可能だと考えています。特に機能と事業売上の相関性が見えづらいのがSaaSプロダクトの悩みどころです。
ただ、実際に利用されているユーザーやログは取得する事ができるため、機能の短期的な成果指標としては利用率を重視しています。複数の機能を短期間の内にリリースする場合もありますが、機能的に同じ場所を複数チームが同時に開発することはないように開発ライン間で調整しています。
Q8. データアナリストに出力をお願いするデータと、自分でSQLかいて集計するデータを切り分ける基準などあるか。
[STORES 予約 | PM 西岡]
30分以内で出来そうなものは自分で書いてみて、データチームにレビューしてもらいます。時間がかかりそうなものやそもそも集計方法が分からない部分はデータチームに要件を伝えて協力してもらっています。
次にPOによる事業分析系の質問です。
Q9. KPIをどう分解して考えているか。
[STORES 決済 | PO 谷塚]
決済事業においては、何か特別なことをしているわけではなく、シンプルな形、基本的な分解方法で行っています。何を目的としたツリーなのか、各チームごとの施策に落とせる形になっているか、とかを考えながら分解してたりします。目的が違う場合に関しては違った切り口でのツリーを作成したりもします。例えば、店舗数×店舗単価みたいな指標から分解する時もあれば、新規×既存みたいな指標から分解する時もあったりします。分解した結果、どのチームがどの KPI を追いかけていて、そこに紐付く打ち手がわかりやすく整理できていると PDCA がまわしやすいなと思っています。
Q10. 「成長性の高いKPI」の判定基準を教えて下さい。
[STORES 決済 | PO 谷塚]
オーナーさんの行動と社内でのサポート体制などの一連のフローを整理して、定量面ではフローごとの遷移率などの数値面の整理、定性面ではオーナーさんが困っていそうなことや、そこに対して現在行っている施策の整理などをして、いったん全体像を整理します。それをベースに、やりきれていないこと、これからやってみたいことなどを整理していきながら、伸ばす余地がありそうな所を発散・議論しながら判断する、みたいな感じです。
Q11. KPI分解時に検討している「ぐるぐるするフロー」とはどういうものなのか。
[STORES 決済 | PO 谷塚]
様々な切り口でマーケットごとのオーナーさんが抱えている大きな課題を整理し、そこに対してうちが提供できる価値、具体的な施策などと連動させながら伸び代を探しながら KPI を整理していくという感じかなと思っています。そんな過程の中で、どうやってプロダクトとして成長させていくのか、みたいなものを何回も試行錯誤している状態がぐるぐるという状態です。
数字や言葉だけだと伝わりにくいケースもあるので、こんな感じで図式化したりしながら共有してます。（下図）
Q12. コントロール可能なKPIなのか、というところの見極めはなぜ難しいのか。
[STORES | PO 御守]
市場成長と自分たちのアクションによる効果の切り分けが難しいためです。私たちの事業は大変ありがたいことに継続的かつ堅調な成長市場にあるため、良くも悪くも「何もしなくても色々な数値が伸びやすい」状態にあります。その状態の中で何か施策を打つと、基本的に何かしらポジティブな数値は出てしまうので、自分たちのアクションによって影響が出たのはどこなのか、それはどれくらいの差分なのか、という効果測定をキッチリやるのはなかなか難しいです。数値的にもそうですし、人間の心理的にも「自分の努力で伸ばした」と解釈したくなってしまうので。
Q13. POの方々のプロダクトリテラシー、データリテラシーはどれくらい持っているのか。PdMに一任しているのか、POも理解はできる（肌感ある）のか。
[STORES | PO 御守]
POそれぞれの特性によっても多少違いはあります。
まずプロダクト面については、私自身は、元々ずっとPdMなので、ビジネス的な側面よりプロダクト的な側面の方が強いです。
次にデータについては、私は自分自身でSQLを書くことはなく、データチームと連携して、民主化すべき数値は誰でも参照できるようにダッシュボード化してもらうなど、なるべく分析結果にレバレッジが効くようなアクションを常に考えています。POとしては、SQLスキルというよりも「何に対して答えを出すか」という「問を立てる力」や、「今何が起こっているのか」という「現状を把握する力」が重要で、ここについてはPdMメンバーよりも強さが求められるかなと思っています。
次にデータ分析組織やその立ち上げについての質問です。
Q14. 依頼をデータチームに集約する運用方法にした時、全社的な勉強会や共有時に意識したことはあるか。
[hey｜データアナリスト マネージャー 西村]
私たちデータアナリストがどういうことに気をつけながらデータを扱っているかみたいな記事を社内のドキュメントツールに書くようにしていました。あとはPMもそうですけど、部署関係なくいろんな人と気軽に会話するようにしていたことが1番大事にしていました。勉強会に関しては、どの会社でもよくやられているSQL勉強会はやっていました。
Q15. (データ組織立ち上げ期について)データチームへの依頼の質を上げたりしたのか、前提が間違っててもなんでも相談OK！みたいな体制にしたのか。
[hey｜データアナリスト マネージャー 西村]
1番よくないのは、間違ったままデータが使われることなので前提が間違ってても相談してもらえれば軌道修正できるので、初期の頃は何でもOK！のような雰囲気を作ってました。
Q16. hey社のデータリテラシーの中央値が気になる。営業含め、今どれくらいで、理想はどれくらいか。理想に近づけるためにどうやって啓蒙しているか。
[hey｜データアナリスト マネージャー 西村]
全員と詳細に会話しているわけではないので現状を正確に把握することは難しいのですが、例えばアンケートを設計するときにできるだけ偏りが起きないようにどうすべきか、A/Bテストを実行するときグループをランダムに分割するとはどういうことかみたいなことは統計の勉強会を開催して感覚として持ってもらいたいなと考えています。
Q17. データサイエンティスト、アナリストがどれくらいの割合でいると嬉しいのか
[hey｜データアナリスト マネージャー 西村]
これは完全に会社の状況によると思うんですが、割合というより目的に応じてそれぞれのスキルが必要になってくると思います。heyの現状としては機械学習のようなサイエンス寄りのスキルがこれからより必要になっていくステージなのでサイエンティストの採用も視野に入れないとなと考えています。
Q18. データアナリストの評価がどのように行われるか気になる。PO/PMのように事業数値にダイレクトにつながる業務ではないと思うため。
[hey｜データアナリスト マネージャー 西村]
私たちの価値は、いかに意思決定のスピードや質をあげることができたかというところに尽きると思います。ですので、評価の際には、各メンバーが関わったPMやビジネスの方にヒアリングをして、実際のアウトプットと総合的に判断しています。
最後にheyについての質問です。
Q19. heyさんは今、社員数ってどれぐらいなんだろう。250人ぐらい？
[STORES | PO 御守]
はい、現状250人くらいです！250人と聞くと「もう結構いるな〜、今入ってもあまりやることなさそう」と思われてしまうかもしれないのですが、実態は全然そんなことないです。そもそも3事業あるので、1プロダクト当りでいうと数十人のアーリーな規模ですし、変化も激しいので、きちんと整っている部分が逆に見当たらないくらいです。全職種採用強化しておりますので、助けていただける方を募集しております...！（特にプロダクトマネージャーの方！）
Q20. データの話ではないのですが、最も強く感じられる会社の可能性や、課題はなんでしょうか。
[hey｜CPO 塚原]
お商売のデジタル化の波が、お客様と直接接点を持つ点（＝フロントオフィス業務 と呼んでいます）で加速されている点が強い可能性を感じます。コロナをきっかけに会計業務や契約書業務などのバックオフィス業務から急速にスタートしていますが、実店舗ありきでお商売をされてきた（例：飲食店さんや、ヨガや料理レッスン等）方々が、最終顧客と繋がるお店の場所自体も、ネットショップや予約サービスに流れはじめてきています。卸取引が中心になっていた中小企業さんも、卸先さんの業績悪化に伴い、直販をスタートしていく方々も増えています。
このように、今までは実店舗が当たり前だったところから、最終顧客と繋がるお店側＝フロントオフィス業務のデジタルシフトの波が加速していると感じています。
コロナ以後の、お商売のデジタル化のスピードは上がっているにもかかわらず、お客様からの需要にお応えできるだけの、開発や直接的なお客様対応スピードが追いついていない点は課題ですね。ですので、採用を頑張っており、ご興味ある方は、全職種OPENしておりますので、お待ちしております！
当日の発表資料を共有します！
イベントでは下記3つのLTを実施しました。それぞれの資料と全文文字起こし記事をご紹介します。
・「hey における PdM の役割とは」（CPO塚原）
・「データに向き合うプロダクトマネージャー」（PM西岡）
・「データアナリストから見た hey のプロダクト開発」（データマネージャー西村）
プロダクトマネージャーを募集しています！
heyではSTORES(EC)、STORES決済、新規プロダクト において、一緒にプロダクト開発に取り組んでいだけるプロダクトマネージャーの方を募集しています。まずはカジュアルに話を聞きたい、という方でもお気軽にご応募・お声がけください！御守に直接DMいただいてもOKです！情報交換・雑談させてください。
いきなり人と話すのはちょっとアレだけどheyの事業方針や組織についてもう少し深い話を聞きたい、と思っていただいた方は、ぜひオープンオフィス「Hello hey」にお越しください！経営陣が、最新の方針や課題感についてお話します。オンラインなのでラジオ感覚でお気軽に！
もっとサクッとheyの全体感を知りたい方は、ぜひ「hey BOOK」をご覧ください。heyのミッションや働く環境、職種割合など書いています。PMの割合はわずか5%！少数精鋭です。
おまけ：初めてイベント開催してみての反省
自社の認知拡大や採用広報を目的としてイベントを開催してみようかな〜、と考えている方はPMに限らず各社にいらっしゃるかと思います。私たちも今回初めてのトライだったので手探り状態でしたが、1回やってみたことで色々と反省点が見えてきました。次回以降のイベントに活かしていきますが、もしかしたら他社の方にも役立つかもしれないと思い、反省内容を共有します。（社内の振り返りMTGの議事録コピペです）
次回以降も継続すべきGoodポイント
【事前の準備・コンテンツ設計】
・口頭だけだと伝わりにくいので、具体的な事例を話す予定の人は簡単に1枚でも説明用スライドを作る
・イベント後の振り返りアフタートーク（雰囲気が伝わって好評だった）
【当日のオペレーション・進行】
・登壇者は全員カメラON
・社内が視聴者目線で Slack でリアルタイムのアドバイス・カンペ出し
・視聴人数を定期的に読み上げる
次回以降に改善すべきMoreポイント
【事前の準備・コンテンツ設計】
・スライドのデザイン、マスタをデザインチームにお願いする
・コンテンツを組みやすくするために、前回参加したかどうかのアンケート項目をつくる
・オンライン開催の場合は、締切は当日までにする（滑り込みで参加希望の方が2名いたため）
・待ち時間用BGM の準備
・イベント本番前にアイスブレイク / チェックインの前座トークタイムをつくる
・誰にどういう話をしてもらうか事前に一定設計する
・heyの事業とかPdMの役割については前座トークで済ませて、対話形式で話すようにする。加えて、資料作ってシェアする。
・どちらかというとプロダクトオーナー視点ではなくもう少し現場よりのPM視点に寄せていく方が、当事者感出る
・開始時間はもう少し早くても良さそう
【当日のオペレーション・進行】
・Zoomでの質問は「パネリストと参加者向け」にしてもらうアナウンスをする
・答えきれなかった質問は後日noteで回答します、と最初に明言する
・話すスピードは気持ちゆっくり目を意識する
・わかりやすいワード / シェアしたくなるワードを意識する
なお、今回は少しでも多くの方にご参加いただきたいと頭を捻り、ログインボーナス施策「参加者全員にheyグッズ3,000円クーポン」を入れたのですが、想像以上の10倍近くの方々にご参加いただきました。（予測30人、実績200人）
第2回にご期待ください！
ここまで読んでいただいた方、ありがとうございました！今回ご参加いただけなかった方も、次回、3/30(火)19:30から「エンジニアと連携した優先順位決め」というテーマで開催しますので、ぜひご参加いただけるとうれしいです！
この記事が気に入ったらサポートをしてみませんか？