アウトカムを最大化させるプロダクトエンジニアの動き

実践プロダクトエンジニアリング ~ドメインを制する者は開発を制す！~

株式会社hacomono
山下 翔

Transcript

1. Last Update 2022.03.16 アウトカムを最大化させるプロダクトエンジニアの動き 実践プロダクトエンジニアリング ~ドメインを制する者は開発を制す！ ~
2. 2 自己紹介 山下 翔 (@shoy75) • 新卒でITコンサル会社でPM • エンジニアにジョブチェンジし、スタートアッ プ数社で開発に従事 • 2023- hacomonoにジョインし、現在はス クールチームのリーダー • 走るのとビールが好きです
3. 3 会社紹介
4. 約8,000店舗・施設以上での導入実績 ヨガ・ピラティス パーソナルジム 24時間ジム 総合スポーツクラブ 運動スクール プロスポーツ（サッカー・バスケ） 公共運動・学校施設 ゴルフ サウナ・エステ コワーキング
5. 5 今日のテーマ 話すこと 顧客にとっての価値を理解し、刺さるプロダクトを提供する ために、 hacomonoのプロダクトエンジニアがどのような動きをしているかを紹介 話さないこと 設計・開発・エンジニアリングスキルに関する話 気になる方はこちら: https://techblog.hacomono.jp/entry/2024/12/16/000000
6. 6 目次 1. hacomonoのプロダクトエンジニアとは 2. 顧客への価値の解像度を上げるために 3. 機能ギャップをなくすために 4. まとめ
7. section hacomonoのプロダクトエンジニアとは 1
8. 8 hacomonoにおけるプロダクトエンジニアの定義 プロダクトの成長を軸に、オーナーシップを持って追求・越境していくエンジニア
9. 9 hacomonoにおけるプロダクトエンジニアの定義 プロダクトの成長を軸に、オーナーシップを持って 追求・越境していくエンジニア • プロダクトの成長 顧客に価値を提供し続けること • 追求・越境 職種にとらわれず何でもやっていく 顧客の課題を解決し、喜ばれるサービスを作り続けよう！ もちろんやれる範囲はあるけど、エンジニアだからこれはやらないという考えをいった ん捨てる。 エンジニアだってPRD書いてもいいし、デザイナと一緒に UI/UX決める動きをしてもよ い！なんならセールスの商談や CSオンボ同席もOK！
10. section 顧客への価値の解像度を上げるために 2
11. 11 なぜ顧客への価値の解像度を上げる必要があるのか 顧客の解像度が低かった事によるスクール業態向け機能の作り直し • 2022年にスクール業態向け機能を開発・リリース • 顧客・社内から不満の声が続出してしまう ◦ システムを入れたことで業務時間が増えた等 • 2024年に新しくスクール機能を作り直し・リリース • うまく行かなかった理由の 1つとして、スクール業界への理解度が低かった まずは顧客にとって価値のあるプロダクトとはなにか解像度を上げる必要がある
12. 12 hacomono 顧客にとっての価値を知るには 顧客に直接聞くのもいいけど、hacomonoにはドメインエキスパートが沢山いる！ 顧客に近いビジネスメンバーとコミュニケーションをとり解像度を上げる！ プロダクト部門 • PM • 開発 • サポート ビジネス部門 • マーケ • セールス • CS ドメインエキスパート多数 • 総合フィットネス出身 • スイミングスクール • Jユース • etc
13. 13 アプローチ① ビジネスメンバーから直接要望を聞ける場にエンジニアも顔を出す • 週次のGTM(Go-to-Market)定例 ◦ 領域を担当する各チームが情報共有や機能改善要望を出す会 • 月次の開発要望棚卸し会 ◦ 開発要望リストに対してビジネスメンバーがポイントを割り振り、PdMが優先順位を付ける ◦ 各改善要望の詳細についても議論する これができるように なるとめちゃ喜ばれ ます なくても運用的には問 題ないですが売りや すくなります サッカースクールだ とグラウンドを持って ないところも多いの で〜 直近スイミングの商 談でそこがないと運 用回らないと言われ ました そこはこういう運用でカ バーできるんじゃないで すかね そこはhacomonoとしてやる べきかは要検討ですね
14. 14 アプローチ① 得られるもの 💡 より現場に近いメンバーから情報を直接聞くことで、どんな業態の顧客がどんなユースケースで困って いるかイメージすることができる 💡 要望に対して深堀って議論することで、課題のスコープがわかったり、 hacomonoとしてやるべき・やらな いべきかを改めて考えることができる 💡 PRDからだけではわからない、要望に対する現場の熱量を感じることができる
15. 15 アプローチ② ビジネスメンバーの日報やslackをみてみる • hacomonoは日報文化(任意だけど書くメンバーが多い ) • 特にビジネス部門のメンバーは、日々の商談で得た顧客の課題感や学びをしっかり書くメンバーが多 く、顧客解像度を上げるチャンス 💡 商談や導入オンボーディングでの学び・ログから現場の課題や既存の hacomonoに対するギャップを理 解できる 同席した体操案件で、進級管理のリアルな現場ニーズ を細かく教えていただき、現機能の改善ポイントが明確 になりました！… 本日はスクール機能要望について共有です！ 現在担当している〇〇様からXXXと要望をいただきました。 背景としては〜...
16. 16 顧客の解像度を上げることのメリット 顧客の課題・価値の解像度を上げることが、プロダクトエンジニアとしてどんな valueにつながるか 💡 PRDのブラッシュアップや優先順位、課題解決のアプローチをエンジニアから提案・議論することができ る 💡 なぜこの機能をいま作る必要があるのかを腹落ちさせることができ、迷いなくスピーディに開発を進める ことができる 💡 スコープを工数ではなく顧客への価値を基準に調整できる 顧客に対して必要な価値を適切なタイミングで提供することにつながる
17. section 機能ギャップをなくすために 3
18. 18 リリース前にもビジネスメンバーを巻き込みレビューしてもらう（リリース前レビュー） これまでそもそもステークホルダーに対するレビューしてもらう機会がなく、 QA通ればリリース(あってもPdM確認) • 顧客に対してデモをしながら説明、設定、運用時の課題解決策を提示する のはセールス・CSといったビジネスメンバーであり、このメンバーが良いと思 わなければ顧客も価値を感じることができるはずがない • 一度出して一部顧客に運用されてしまうと、機能ギャップがあったとしても 引っ込めるのが難しい より現場に近いメンバーに フィードバックをもらう
19. 19 レビュー会に対するスタンス • お披露目会ではなく、機能が顧客にもたらす 価値に対して議論しフィードバックをもらう こと で、より価値を高めることを意識する • PdM・エンジニアは事前にユーザーストーリーを考えて仮説を持って臨み 、現場メンバーと 答え合わせをする場 ◦ 単に画面上の操作性だけでなく、 どんな場面・場所で使われる機能なのか までイメージ してみる(事務所のPCで落ち着いてできる作業なのか、グラウンドやプールサイドで指導 しつつタブレット等で入力するのか等 ) • 一方的なデモだけでなく、時には現場メンバーにその場で触ってもらって 詰まる箇所や問題な く運用できるか等を明らかにする • あくまで一部メンバーの意見であるということは忘れない
20. 20 レビューしてもらってみての学び① 想像以上に現場メンバーに刺さるポイントが違う ここはまだできてないですが、お客様的にはないとまずいですよね？ (必須だろうなぁ ...) まぁそこはなくても大丈夫だと思います。 むしろこっちでこの操作できちゃうのが懸念です。 おぉ、、、なるほど ...ありがとうございます！ (そっちは問題ないと思っていた ...) • PdM・エンジニアが気にしていた部分が意外と現場的には問題がなかった • 特に論点ないかと考えてた部分が実は現場的には気になりポイントだった • ここは妥協できる機能かなと思っていたら顧客の運用を大きく変えなければならなかった セールス
21. 21 レビューしてもらってみての学び② 普段からユースケース意識していないと議論できない • 機能ベースの質問には答えられるが、ユースケースベースの質問に対しては普段からイメージできてい ないと議論できない • 編集項目1つとっても、ユーザがどんな場面・背景で編集する必要があるのかを考えることは凄く大事 うーん、そこは一回削除して、再度契約して貰う必要があるかもです お客様が一度契約したあと、やっぱり別の日に契約変えたい みたいな時どうしたらいいですか？ あ、、、そうでした。。ごめんなさい CS PdM 管理サイトからここ編集したらいけますよね
22. 22 リリース前レビューのメリット リリース前に現場に近いメンバーにレビュー・触ってもらうことで機能ギャップを減らすことができる 💡 実際に出来上がったものを現場視点でみてもらうと、作る前に想定していなかったギャップに気づき、本 当に価値を提供できる機能になっているのかを検証することができる 💡 実はプロダクトの負債になるような機能を世に出さずに済む 💡 次の機能では、より深く現場のユースケースをイメージしながら開発することができる 💡 ビジネスメンバーも自信を持って販売・導入できる モノを作るのはエンジニアかもしれないがプロダクトの質は全員であげていく！
23. 23 開発メンバー以外を巻き込むのが難しい 開発タスクが忙しかったり、開発メンバー以外との調整が大変な場合もあるが、小さくできることから 始めていく • 稼働状況で難しかったり、参加のハードルが高いミーティング ➡ 録画でも要望に対する現場の熱量や背景を知ることができる • ビジネスメンバーが忙しくレビュー会の時間調整が大変 ➡ 少人数でもよいので、しっかり意見をくれるメンバーに絞って小さく始めてみる (レビュー会の価値を感じてもらえればスケジュール調整もしやすくなる ) ➡ 不定期でもよいので継続して開催する
24. section まとめ 4
25. 25 まとめ 💡 hocomonoのプロダクトエンジニアは、プロダクトの成長を軸にオーナーシップを持って追求・越 境していくエンジニア 💡 作る前に提供する価値の解像度を上げるのが大事 💡 リリース前に現場に近いメンバーにレビューしてもらうことで、機能ギャップをなくす 💡 ユーザに喜ばれる価値あるプロダクトを作っていきましょう！！！