20260707_Product Engineerが機能する条件、Epic Ownerというロール

https://medicalforce.connpass.com/event/394639/

の登壇資料

Transcript

1. Product Engineerが機能する条件 Epic Ownerというロール 2026-07-07 Product Engineering Lab #2 @ryugen
2. whoami 山本竜玄 Yamamoto Tatsunori (@ryugen04) 経歴: 株式会社ヘンリーに2025年11月join 医療・ヘルスケア領域のWebエンジニア(ロール はEpic Owner)やっています。 趣味・領域 : Neovim好きです/スクラム好きです アクアリウム/カポエイラ/薬剤師 その他: ビールが好きです！
3. 5分で Product Engineerって何？ と私の社内のロールのEpic Ownerについて個人的に考 えていることを話します (※会社の意見は代表しません)
4. 最近流行りのProduct Enginnerとは？
5. 一番イメージされるのは、end-to-endでや るスーパーマンでは？ 顧客もわかる、課題設定もできる、実装か らリリースまでできる！！ 俺一人で十分だぜ！！
6. Product Engineerの個人的な解釈 バズワードということもあり、どのような定義・期待をされるのかは組織によると考えて いる PdM融合型 ◦ エンジニアが顧客課題、何を作るか、実装、検証まで持つ ◦ 小さなプロダクト領域を end-to-endで回す ◦ 例: PostHog, Pendo, Ubieなど Product-mineded Engineer型 • 実装者のまま、顧客理解、問題定義、 UX、データにも近づく • PdMやDesignerの代替ではなく、共同でプロダクト判断に入る • 例: Atlassian, Intercom, hacomono, SmartHRなど 横断ハブ型 • 複数職能、複数プロダクト、リリース、運用をつなぐ • 何を作るかではなく、作ったものが成立するのか • 例: RightTouch, LayerXなど 下にいくほど変数や調整コストが増える
7. ということで、 ドメインの特性によってその考え方は変わ るのではという話をします
8. 医療システムとしての特性 • 医療ドメインの弊社のシステムでは、電子カルテ・レセコン一体型 で相互依存性が大きい • データフローとしても複雑で時系列性もある
9. プロダクトが外部依存する特性 • プロダクトとしてのシステムの他に、厚生労働省を始めとした公的な計算 ルール、提出様式が決まっている • それらのルールが、頻繁に改変される。プロダクトとしては追従が必須と なる ←例としてはこういう のとか
10. Product Engineerの適合性 • 医療ドメイン・現プロダクトの特性として、以下の特徴がある ◦ ドメインがあまりに複雑すぎて、エンジニア全員が理解するの は現実的でない ◦ ドメインのモデリング、実装自体も難易度が高い ◦ システム内で電子カルテ・レセコンなどの患者、臨床データの 時系列や一貫性がある。相互依存性が大きい ◦ とはいえスタートアップなので、開発速度は早い ひとりのProduct Engineerが、課題探索から実装、導入、検証まで 一貫して持つには変数が多い
11. 私のやっているEpic Owner • SAFe(Scaled Agile Framework)にもあるが、今は少し違うロールとして私は 担っている • Epicという単位でプロジェクトライフサイクルを回す中で、以下を並行して高速で 回しながらEpicをクローズさせる責務があると認識している ◦ Discovery: ドメインエキスパート ◦ Delivery: エンジニア ◦ Release: Biz ◦ Validation: Biz・CS • なので、やっていることはCS・ドメインエキスパート・デザイナー・エンジニアがこ のサイクルを円滑にまわすためのハブ的な責任 • 実際に、滞っている部分があれば自分でも手を動かす
12. エンジニアの越境としての考え方 • 分業を前提とした越境の種類として、縦と横の軸がある • 考え方もいくつかある ◦ Epic Ownerは縦、接続点を重視したロール ◦ この構造でのEngとしては、Delieryを軸に左右上下への越境・Deep Dive が期待される ◦ end-to-endなPdEは、狭い縦を一貫しているようにとらえている すべてを越境すればよいわけ でなく 一律に全員が同じ越境の仕 方をする必要もない
13. まとめ • プロダクトエンジニアの定義もいろいろあるが、一番イメージされるのは顧客か らの課題発見〜実装〜リリースまで一貫するエンジニアではと思っている • これが適合するケースとして、プロジェクトが小規模・他との影響が疎な構造と なっている場合だと感じる • ドメインが複雑すぎる、プロジェクト間の依存関係が多いなど、変数が多い場合 には調整・意思決定役は集約したほうが効率的 • 越境の仕方として、縦の一貫した考え方、ハブ型、横の影響などいろいろある。 ドメインやプロダクト特性によっての最適さがありそう (case by case…)
14. 最近流行りのProduct Enginnerとは？
15. プロダクト特性によって いろいろありますよね
16. ご静聴ありがとうございました