Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
エンジニアに事業やプロダクトを理解してもらうためにやってること
Search
bayashi
October 29, 2025
Programming
620
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
エンジニアに事業やプロダクトを理解してもらうためにやってること
プロダクトエンジニア2025 キャリアとしごとの”今”
https://tenshoku-draft.connpass.com/event/372648/
bayashi
October 29, 2025
More Decks by bayashi
See All by bayashi
XP祭りでしか伝わらないフリップネタ #xpjug
murabayashi
0
160
スタートアップにおけるアジャイルの実践について #shibuyagile
murabayashi
4
4.5k
複雑さを受け入れるか、拒むか? - 事業成長とともに育ったモノリスを前に私が考えたこと #RSGT2026
murabayashi
1
4.6k
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
800
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
640
個人事業主型開発からの脱却
murabayashi
14
10k
スクラムフェスを支える配信の仕組み
murabayashi
1
1.3k
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.7k
商用アプリケーション開発基本のキ
murabayashi
0
350
Other Decks in Programming
See All in Programming
GitHubハンズオン講座 — 実務レベルのチーム開発のフローを身につけよう
junhat6
0
120
Verilogで学ぶCPU自作入門
uyuki234
8
4.1k
複雑なUIコンポーネントとの ⻑い付き合い⽅:波及するバグからテスト戦略を経て、安全な再設計へ
mixplace
0
250
AWSに止められる覚悟してますか?
morizo_1984
2
520
Simple Storage Service(S3) is not simple
iwatsukayura
0
230
半永久的に提供し続けられるプライベートクラウドを目指して ― 利用者の認知負荷を抑えるAPI抽象化とハードウェア世代交代の基盤設計
tomokon
0
470
SREの越境 / SRE Collaboration
y0hgi
2
300
RAG の “R” を Swift で覗いてみる 〜「意味から探す」検索の仕組み〜
nao_randd
0
120
大喜利で理解するLLM as a Judge / Understanding LLM-as-a-Judge through Ogiri
rockname
0
200
自サークルのIdPからログアウトできるようになるまで
taiseiue
1
120
Starting & Sustaining Code-Based E2E Testing for Non-Coding QA Teams( #jasstniigata )
teyamagu
PRO
1
940
難しいけど、読めた。- OSSの入口に立った話。
sts11142
0
140
Featured
See All Featured
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
69
66k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.8k
Test your architecture with Archunit
thirion
2
2.4k
HDC tutorial
michielstock
2
950
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
530
How to train your dragon (web standard)
notwaldorf
96
6.9k
KATA
mclloyd
PRO
35
16k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
280
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
[RailsConf 2023] Rails as a piece of cake
palkan
59
7.1k
Transcript
エンジニアに事業やプロダクト を理解してもらうために やってること プロダクトエンジニア2025 キャリアとしごとの”今” 2025/10/29 Kei Ogane
自己紹介 ばやし(Kei Ogane) オンライン診療システム提供サービスで エンジニアやった後、今はEMやってます 最近の趣味は そろそろ一歳の息子に 肩をかじられることです
プロダクトエンジニア Linc’well社内ではそういう呼称は用いてないし 私自身プロダクトエンジニアというロールにそこまで詳しいわけではないので 弊社のエンジニアや私が大事にしている - 言われたものを実装するのではなく誰のどんな課題を解決するのかを理解し た上で解決する あたりが実現されるためにやってることを紹介していきます
会社紹介
オンライン診療システム提供サービス システム提供 診療
患者さん向けもクリニック向けも
BtoBtoC 患者さんの理解もしなきゃいけないし クリニックのオペレーションも理解しなきゃいけないし そこら辺のバランス取るため事業の理解もしないと
理解できるようになると何ができるか ただPdMが持ってきた仕様をそのまま実装するのではなく、 仕様の中で守らないといけない部分と 変更して良い部分の見分けが(ある程度)つくようになる
今行うべき開発かどうかはコスパが大事 それがとっても大きなビジネスインパクトを生 むならたくさんコストをかけて開発しても良い ただ逆に変えようが変えまいがビジネスインパ クトが変わらないものにたくさんコストかける ことを誰が望んでいるんだろうか
コストに関しては 実際にどれくらいコストがかかるのかは エンジニアが一番詳しい そのためPdMのみで出した仕様に関しては コストパフォーマンスが最適かどうかはわからない つまりエンジニアが積極的に関与し コストパフォーマンスが最適な仕様を一緒に検討する必要がある
例え話 検索機能作りたいです。仕様 は☓☓で (うっ...この☓☓って今の アーキテクチャだと相当難し いぞ) エンジニア PdM
背景理解してない場合
背景がわかってないと ログイン機能作りたいです。 仕様は☓☓で あー、☓☓は今のコードだと できないですね。逆に△△な らできますけど。 エンジニア PdM
背景がわかってないと △△はこういう背景があって 難しいですね。 じゃあ□□は...? エンジニア PdM
背景がわかってないと いや□□も同じく難しく て...(なんもわかってない のに仕様に口出さないで欲し い...) (なんやこいつ否定ばかりで だるいな...) エンジニア PdM
背景がわかってないと いや□□も同じく難しく て...(なんもわかってない のに仕様に口出さないで欲し い...) (なんやこいつ否定ばかりで だるいな...) エンジニア PdM 喧嘩するしかない!!
背景理解している場合
一方背景がわかってると ログイン機能作りたいです。 仕様は☓☓で 確かに今って◯◯で離脱して る人多いですもんね。あと ユーザ属性的にも☓☓できる といいですね〜。ただ☓☓は 難しくて。△△だったらいけ るんですけど エンジニア
PdM
△△はこういう背景があって 難しいですね〜 たしかに、そういえばそうで した。お、••だったら全部 満たせるかも? エンジニア PdM 一方背景がわかってると
確かに!••ならいけそうで すね!それでいきましょう やったぜ エンジニア PdM 一方背景がわかってると
15年前くらいにマーティン・ファウラーがもう言ってた ユーザーストーリーの場合、これが意味する のは、 誰もが対話を通じて常にストーリーを 洗練させていくことができるということだ。 そして、開発者は、ストーリーを明確化する 役割を積極的に担うべきだということだ。 - ストーリー間の矛盾や隙間に気づく -
技術知識を使って、プロダクトオーナー のビジョンに合うような新しいストー リーを考え出す - 技術的見地から、コストがかからずに構 築できる代替ストーリーを考える - ストーリーを分割して、計画や実装をや りやすくする Martin Fowler's Bliki (ja) - 対話的ストーリー https://bliki-ja.github.io/ConversationalStories
でもエンジニアの中には プロダクトとか事業に興味ない人いるよね? 己の中の斜に構えマン
興味がないのは知らないからかも ある腫瘍専門医は、診療所間で患者がスムー ズに移動・紹介されるようにすることなど、 重要だとも思わないと言い放った。 とはいえ、彼のような扱いづらい医師たち も、患者の話を聞き、彼らやその家族のこと を知り、「ケアの調整」に関する調査に目を 通すうちに、態度が変わっていった。 FRICTION(フリクション)職場の問題を解決する摩擦の力 ロバート・I・サットン
(著), ハギー・ラオ (著)
事業やプロダクトの理解はどうやってくか - 実際に自分で体験する - 実際のデータから把握する - 現場を見学する - スプリントレビューで事業理解を深める
実際に自分で体験する 自分たちが提供しているプロダクトは一体どんな 体験を提供してるのか理解したい 自分も病弱なのでよくオンライン診療を使ってい るし、メンバーにも使うようおすすめしてる 体験したメンバーが長文の感想を書いてくれるこ ともある
実際のデータから把握する みんな(PdM,デザイナー,エンジニア)で ユーザーインタビューの動画見たり ユーザの行動データを分析しながらわいわいした りしてます
現場への理解 入社したら一度は現場を見に行ってもらってい る。 プロダクトが実際に使われているところを見る ことで、プロダクト改善にもつながると思う が、どちらかという現場の空気感や如何にオペ レーションが高度化されているかとかを学んで 欲しい
スプリントレビューで事業理解を深める スプリントレビューはこれまでただ機能のデモをしているだけだった そこからデモ以外に - 過去リリースした施策の影響 - 現在追ってるKPI状況の共有 もスプリントレビューでやることにした デモの際にも機能ではなく機能の価値を説明してもらうようにした みんな自分が作った機能が事業に役立ってることがわかるようになってきた
事業やプロダクトを理解することで もっと開発は楽しくなると思ってます これからもどんどん理解していきたいですね