入社３か月で見えてきた、 “プロダクトエンジニア”という仕事のリアル

by Masato Tezuka

Slide 1

Slide 1 text

入社３か月で見えてきた、   “プロダクトエンジニア ”という仕事のリアル 1 株式会社RightTouch プロダクトエンジニア   手塚真斗 

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 2024 RightTouch Inc.　|　Confidential 自己紹介  株式会社 RightTouch プロダクトエンジニア⼿塚真⽃ 4 2023.04 - 2023.12　フリーランス    2024.01 - 2025.07　株式会社Speee    2025.08 - 現在　　　株式会社RightTouch      前職ではフルスタックエンジニアとしてチームリーダーを担当。   現在は、QANT スピークの開発を担当。      趣味：サウナ・旅行・キャンプ  

Slide 5

Slide 5 text

© 2024 RightTouch Inc.　|　Confidential 会社紹介  沿革   2021年12月株式会社RightTouch設立  2022年3月次世代のコンタクトセンターを創ることに賛同いただいた   お客様との実証実験を経て、 KARTE RightSupport（β版）  をリリース 2023年10月 Webサイトとコールセンターの分断をなくし、問い合わせ体験を抜本から変革する新プロダクト「 RightConnect by KARTE」β版を提供開始  2023年10月 RightSupport by KARTEの正式版をリリース     主な導入企業様設立：2021年12月  従業員：69名、うちエンジニア24名（2025年10月現在）  資本金：10,000,000円（資本準備金含む）   RightTouch 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 2024 RightTouch Inc.　|　Confidential 転職を考えたきっかけ   8 課題探索  要件定義  設計  実装・テスト  リリース  PdM Eng 一般的な開発組織  ● ディスカバリーとデリバリーで分けることで責任領域が明確になり、作業に集中できる   ● 一方、責任領域を明確にすることでコンテキストが分裂しコミュニケーションコストが増える   ● PdMは基本多忙なので、 PdMが開発のボトルネックになりがち  

Slide 9

Slide 9 text

© 2024 RightTouch Inc.　|　Confidential 転職を考えたきっかけ   9 課題探索  要件定義  設計  実装・テスト  リリース  PdM Eng 一般的な開発組織  ● ディスカバリーとデリバリーで分けることで責任領域が明確になり、作業に集中できる   ● 一方、責任領域を明確にすることでコンテキストが分裂しコミュニケーションコストが増える   ● PdMは基本多忙なので、 PdMが開発のボトルネックになりがち   業界解像度 / 顧客解像度が高いエンジニアが一気通貫でプロダクト開発ができれば、   コミュニケーションコストが少なくなり開発サイクルを早く回せるのでは？    

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2024 RightTouch Inc.　|　Confidential RightTouchのプロダクトエンジニア   1 1 RightTouchの「プロダクトエンジニア (PdE)」は下記の振る舞いを期待される。   01  プロダクトの成長に寄与するあらゆることに主体性をもつ   02  分業せず、フルサイクルな開発を行う   Why-What-Howすべてに責任を持つ。課題の発見から、何を作るか、どう実現するかまで一気通貫で担当する。   03  他の職種のメンバーと積極的にコミュニケーションをとる   デザイナー、ビジネスサイドとの協働しながら、チーム全体でプロダクトを作り上げるために積極的な連携をしていく。   エンジニアリングだけに囚われずにプロダクトの成長に必要なことであれば、領域を問わず主体的に取り組む。  

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2024 RightTouch Inc.　|　Confidential 入社から3ヶ月経過して感じたこと（ポジティブ編）   1 4  AIネイティブなプロダクト構想では技術理解がより求められる   冪等的なプロダクトから確率論的なプロダクトへのシフト   従来のSaaS input  output  AIプロダクト ● 実現可能性の可否だけでなく   実現可能性の程度の判断が求められる   ● Step by step で試行錯誤していく必要がある

Slide 15

Slide 15 text

© 2024 RightTouch Inc.　|　Confidential 入社から3ヶ月経過して感じたこと（ギャップ編）   1 5  01  課題探索の時間を確保できない   デリバリーが業務の中心になっており、顧客解像度を上げたり課題探索する時間を確保できていない   02  コンテキストスイッチが激しい   色々手を出していると、1日の終わりに「今日何してたっけ？」となることがある  03  個別開発になりやすい   顧客との距離が近いので、期待に答えるために顧客要望を鵜呑みにして開発してしまう時がある  

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2024 RightTouch Inc.　|　Confidential プロダクトエンジニアとして意識していること   1 7  周囲と積極的にコミュニケーションを取りながらも、意思決定のボールを譲らないようにする   Designer/PdE PdE 顧客 CS 要望を課題として定義する     ● 顧客からの要望を課題として定義する   ● 最初から顧客にヒアリングをしようとせず、   まずはCSと密にコミュニケーションする   ● 顧客解像度が高い CSから前提情報を聞いておくことで、   限られた時間の中で顧客により深い問いができる     自分の意見を持ってから周りを巻き込む   ● 今まではHowを中心に責任を持っており、   PdMに意思決定の拠り所があった   ● PdEは機能単位では意思決定の責任を持つ必要がある   ● 要件やユーザー体験で悩んだ時は、   自分なりに整理してから周りを巻き込むようにしている  

Slide 18

Slide 18 text

© 2024 RightTouch Inc.　|　Confidential プロダクトエンジニアとして意識していること   1 8  業界解像度   事業貢献  顧客解像度   プロダクト解像度   プロダクト解像度だけでなく、業界解像度・顧客解像度を上げる   爆速でプロダクト開発することが 1番成果と称されやすいが、実装だけに集中しすぎないようにしている   3つの解像度を上げていくことで中長期的にレバレッジが効く（ =自らプロダクト価値を定義できる）  