Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アウトカムを最大化させるプロダクトエンジニアの動き
Search
hacomono Inc.
PRO
March 10, 2025
Technology
1
740
アウトカムを最大化させるプロダクトエンジニアの動き
実践プロダクトエンジニアリング ~ドメインを制する者は開発を制す!~
株式会社hacomono
山下 翔
hacomono Inc.
PRO
March 10, 2025
More Decks by hacomono Inc.
See All by hacomono Inc.
AI推進室の取り組み
hacomono
PRO
1
64
組込みエンジニアの私が長年抱えていた課題がAIで解決した話
hacomono
PRO
1
65
AI活用のための情報設計 〜もう一段上のAI活用へ〜
hacomono
PRO
0
88
カナリアリリースの異常検知を SLOバーンレートを用いて実装した話
hacomono
PRO
0
63
NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意
hacomono
PRO
3
280
hacomonoらしさをデザインする
hacomono
PRO
2
170
IoTの沈黙をどう検知する?Web系エンジニアが挑んだ苦難と改善記録
hacomono
PRO
1
200
AWS Step Functionsで実現するジョブ基盤 -プロダクトチームを支える基盤づくり-
hacomono
PRO
1
200
プロダクトの一番の理解者を目指してQAが取り組んでいること 〜現場・マネジメント各視点のプラクティス〜
hacomono
PRO
1
480
Other Decks in Technology
See All in Technology
つくって納得、つかって実感! 大規模言語モデルことはじめ
recruitengineers
PRO
20
5.4k
AIとTDDによるNext.js「隙間ツール」開発の実践
makotot
5
670
浸透しなさいRFC 5322&7208
hinono
0
120
JOAI発表資料 @ 関東kaggler会
joai_committee
1
270
モバイルアプリ研修
recruitengineers
PRO
2
240
新規案件の立ち上げ専門チームから見たAI駆動開発の始め方
shuyakinjo
0
110
広島銀行におけるAWS活用の取り組みについて
masakimori
0
130
RAID6 を楔形文字で組んで現代人を怖がらせましょう(実装編)
mimifuwa
0
300
Understanding Go GC #coefl_go_jp
bengo4com
0
1.1k
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
1
180
Goでマークダウンの独自記法を実装する
lag129
0
210
会社にデータエンジニアがいることでできるようになること
10xinc
9
1.6k
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Navigating Team Friction
lara
189
15k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
The Language of Interfaces
destraynor
160
25k
Bash Introduction
62gerente
614
210k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
GitHub's CSS Performance
jonrohan
1031
460k
Side Projects
sachag
455
43k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
KATA
mclloyd
32
14k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Transcript
Last Update 2022.03.16 アウトカムを最大化させるプロダクトエンジニアの動き 実践プロダクトエンジニアリング ~ドメインを制する者は開発を制す! ~
2 自己紹介 山下 翔 (@shoy75) • 新卒でITコンサル会社でPM • エンジニアにジョブチェンジし、スタートアッ プ数社で開発に従事
• 2023- hacomonoにジョインし、現在はス クールチームのリーダー • 走るのとビールが好きです
3 会社紹介
約8,000店舗・施設以上での導入実績 ヨガ・ピラティス パーソナルジム 24時間ジム 総合スポーツクラブ 運動スクール プロスポーツ(サッカー・バスケ) 公共運動・学校施設 ゴルフ サウナ・エステ
コワーキング
5 今日のテーマ 話すこと 顧客にとっての価値を理解し、刺さるプロダクトを提供する ために、 hacomonoのプロダクトエンジニアがどのような動きをしているかを紹介 話さないこと 設計・開発・エンジニアリングスキルに関する話 気になる方はこちら: https://techblog.hacomono.jp/entry/2024/12/16/000000
6 目次 1. hacomonoのプロダクトエンジニアとは 2. 顧客への価値の解像度を上げるために 3. 機能ギャップをなくすために 4. まとめ
section hacomonoのプロダクトエンジニアとは 1
8 hacomonoにおけるプロダクトエンジニアの定義 プロダクトの成長を軸に、オーナーシップを持って追求・越境していくエンジニア
9 hacomonoにおけるプロダクトエンジニアの定義 プロダクトの成長を軸に、オーナーシップを持って 追求・越境していくエンジニア • プロダクトの成長 顧客に価値を提供し続けること • 追求・越境 職種にとらわれず何でもやっていく
顧客の課題を解決し、喜ばれるサービスを作り続けよう! もちろんやれる範囲はあるけど、エンジニアだからこれはやらないという考えをいった ん捨てる。 エンジニアだってPRD書いてもいいし、デザイナと一緒に UI/UX決める動きをしてもよ い!なんならセールスの商談や CSオンボ同席もOK!
section 顧客への価値の解像度を上げるために 2
11 なぜ顧客への価値の解像度を上げる必要があるのか 顧客の解像度が低かった事によるスクール業態向け機能の作り直し • 2022年にスクール業態向け機能を開発・リリース • 顧客・社内から不満の声が続出してしまう ◦ システムを入れたことで業務時間が増えた等 •
2024年に新しくスクール機能を作り直し・リリース • うまく行かなかった理由の 1つとして、スクール業界への理解度が低かった まずは顧客にとって価値のあるプロダクトとはなにか解像度を上げる必要がある
12 hacomono 顧客にとっての価値を知るには 顧客に直接聞くのもいいけど、hacomonoにはドメインエキスパートが沢山いる! 顧客に近いビジネスメンバーとコミュニケーションをとり解像度を上げる! プロダクト部門 • PM • 開発
• サポート ビジネス部門 • マーケ • セールス • CS ドメインエキスパート多数 • 総合フィットネス出身 • スイミングスクール • Jユース • etc
13 アプローチ① ビジネスメンバーから直接要望を聞ける場にエンジニアも顔を出す • 週次のGTM(Go-to-Market)定例 ◦ 領域を担当する各チームが情報共有や機能改善要望を出す会 • 月次の開発要望棚卸し会 ◦
開発要望リストに対してビジネスメンバーがポイントを割り振り、PdMが優先順位を付ける ◦ 各改善要望の詳細についても議論する これができるように なるとめちゃ喜ばれ ます なくても運用的には問 題ないですが売りや すくなります サッカースクールだ とグラウンドを持って ないところも多いの で〜 直近スイミングの商 談でそこがないと運 用回らないと言われ ました そこはこういう運用でカ バーできるんじゃないで すかね そこはhacomonoとしてやる べきかは要検討ですね
14 アプローチ① 得られるもの 💡 より現場に近いメンバーから情報を直接聞くことで、どんな業態の顧客がどんなユースケースで困って いるかイメージすることができる 💡 要望に対して深堀って議論することで、課題のスコープがわかったり、 hacomonoとしてやるべき・やらな いべきかを改めて考えることができる
💡 PRDからだけではわからない、要望に対する現場の熱量を感じることができる
15 アプローチ② ビジネスメンバーの日報やslackをみてみる • hacomonoは日報文化(任意だけど書くメンバーが多い ) • 特にビジネス部門のメンバーは、日々の商談で得た顧客の課題感や学びをしっかり書くメンバーが多 く、顧客解像度を上げるチャンス 💡
商談や導入オンボーディングでの学び・ログから現場の課題や既存の hacomonoに対するギャップを理 解できる 同席した体操案件で、進級管理のリアルな現場ニーズ を細かく教えていただき、現機能の改善ポイントが明確 になりました!… 本日はスクール機能要望について共有です! 現在担当している〇〇様からXXXと要望をいただきました。 背景としては〜...
16 顧客の解像度を上げることのメリット 顧客の課題・価値の解像度を上げることが、プロダクトエンジニアとしてどんな valueにつながるか 💡 PRDのブラッシュアップや優先順位、課題解決のアプローチをエンジニアから提案・議論することができ る 💡 なぜこの機能をいま作る必要があるのかを腹落ちさせることができ、迷いなくスピーディに開発を進める ことができる
💡 スコープを工数ではなく顧客への価値を基準に調整できる 顧客に対して必要な価値を適切なタイミングで提供することにつながる
section 機能ギャップをなくすために 3
18 リリース前にもビジネスメンバーを巻き込みレビューしてもらう(リリース前レビュー) これまでそもそもステークホルダーに対するレビューしてもらう機会がなく、 QA通ればリリース(あってもPdM確認) • 顧客に対してデモをしながら説明、設定、運用時の課題解決策を提示する のはセールス・CSといったビジネスメンバーであり、このメンバーが良いと思 わなければ顧客も価値を感じることができるはずがない • 一度出して一部顧客に運用されてしまうと、機能ギャップがあったとしても
引っ込めるのが難しい より現場に近いメンバーに フィードバックをもらう
19 レビュー会に対するスタンス • お披露目会ではなく、機能が顧客にもたらす 価値に対して議論しフィードバックをもらう こと で、より価値を高めることを意識する • PdM・エンジニアは事前にユーザーストーリーを考えて仮説を持って臨み 、現場メンバーと
答え合わせをする場 ◦ 単に画面上の操作性だけでなく、 どんな場面・場所で使われる機能なのか までイメージ してみる(事務所のPCで落ち着いてできる作業なのか、グラウンドやプールサイドで指導 しつつタブレット等で入力するのか等 ) • 一方的なデモだけでなく、時には現場メンバーにその場で触ってもらって 詰まる箇所や問題な く運用できるか等を明らかにする • あくまで一部メンバーの意見であるということは忘れない
20 レビューしてもらってみての学び① 想像以上に現場メンバーに刺さるポイントが違う ここはまだできてないですが、お客様的にはないとまずいですよね? (必須だろうなぁ ...) まぁそこはなくても大丈夫だと思います。 むしろこっちでこの操作できちゃうのが懸念です。 おぉ、、、なるほど ...ありがとうございます!
(そっちは問題ないと思っていた ...) • PdM・エンジニアが気にしていた部分が意外と現場的には問題がなかった • 特に論点ないかと考えてた部分が実は現場的には気になりポイントだった • ここは妥協できる機能かなと思っていたら顧客の運用を大きく変えなければならなかった セールス
21 レビューしてもらってみての学び② 普段からユースケース意識していないと議論できない • 機能ベースの質問には答えられるが、ユースケースベースの質問に対しては普段からイメージできてい ないと議論できない • 編集項目1つとっても、ユーザがどんな場面・背景で編集する必要があるのかを考えることは凄く大事 うーん、そこは一回削除して、再度契約して貰う必要があるかもです お客様が一度契約したあと、やっぱり別の日に契約変えたい
みたいな時どうしたらいいですか? あ、、、そうでした。。ごめんなさい CS PdM 管理サイトからここ編集したらいけますよね
22 リリース前レビューのメリット リリース前に現場に近いメンバーにレビュー・触ってもらうことで機能ギャップを減らすことができる 💡 実際に出来上がったものを現場視点でみてもらうと、作る前に想定していなかったギャップに気づき、本 当に価値を提供できる機能になっているのかを検証することができる 💡 実はプロダクトの負債になるような機能を世に出さずに済む 💡 次の機能では、より深く現場のユースケースをイメージしながら開発することができる
💡 ビジネスメンバーも自信を持って販売・導入できる モノを作るのはエンジニアかもしれないがプロダクトの質は全員であげていく!
23 開発メンバー以外を巻き込むのが難しい 開発タスクが忙しかったり、開発メンバー以外との調整が大変な場合もあるが、小さくできることから 始めていく • 稼働状況で難しかったり、参加のハードルが高いミーティング ➡ 録画でも要望に対する現場の熱量や背景を知ることができる • ビジネスメンバーが忙しくレビュー会の時間調整が大変
➡ 少人数でもよいので、しっかり意見をくれるメンバーに絞って小さく始めてみる (レビュー会の価値を感じてもらえればスケジュール調整もしやすくなる ) ➡ 不定期でもよいので継続して開催する
section まとめ 4
25 まとめ 💡 hocomonoのプロダクトエンジニアは、プロダクトの成長を軸にオーナーシップを持って追求・越 境していくエンジニア 💡 作る前に提供する価値の解像度を上げるのが大事 💡 リリース前に現場に近いメンバーにレビューしてもらうことで、機能ギャップをなくす 💡
ユーザに喜ばれる価値あるプロダクトを作っていきましょう!!!