Upgrade to Pro — share decks privately, control downloads, hide ads and more …

カスタマーサポート市場の改革に挑む 急成長中のプロダクトエンジニアチームの挑戦と舞台裏

RightTouch
October 22, 2024
210

カスタマーサポート市場の改革に挑む 急成長中のプロダクトエンジニアチームの挑戦と舞台裏

2024/10/22 「プレイド・kikitori・ダイニー・RightTouch_技術領域の垣根を超えた開発手法」発表資料

https://righttouch.connpass.com/event/333501/

RightTouch

October 22, 2024
Tweet

Transcript

  1. © 2024 RightTouch Inc. アジェンダ 
 2 自己紹介・会社紹介 
 


    
 プロダクトエンジニアについて 
 
 
 チームの取り組みと課題 
 

  2. © 2024 RightTouch Inc. 3 自己紹介
 2020 東京大学理学系研究科博士課程修了 
 


    2020-2021 日立製作所
 
 2021-2024 株式会社プレイド
 
 2021-現在 株式会社RightTouch
 
 
 レーザー物理で博士号取得後、日立製作所で ITプラットフォームの設 計・開発に従事。
 
 その後、プレイド/RightTouchで、テックリード/フルスタックエンジニア としてアプリケーション開発に従事。 
 
 
 好きなもの: 旬、React、データ
 
 
 
 齋藤 成之
 X: @nakaakist

  3. © 2024 RightTouch Inc. RightTouch
 沿革 
 2021年12月 株式会社RightTouch設立
 2022年3月

    次世代のコンタクトセンターを創ることに賛同いただいた 
 お客様との実証実験を経て、 KARTE RightSupport(β版)
 をリリース 2023年10月 Webサイトとコールセンターの分断をなくし、問い合わせ体験を抜 本から変革する新プロダクト「 RightConnect by KARTE」β版を 提供開始
 2023年10月 RightSupport by KARTEの正式版をリリース 
 
 主な導入企業様 設立:2021年12月
 従業員:40名、うちエンジニア15名(2024年8月1日現在)
 資本金:10,000,000円(資本準備金含む) 
 RightTouch 4
  4. © 2024 RightTouch Inc. 6 「カスタマーサポート市場の改革」に挑むプロダクトビジョン 
 各システムは個別ベンダーが開発 ユーザー体験は分断、システムは個別最適化 RightTouchが複数プロダクトと基盤を提供(コンパウンド)

    シームレスで全体最適なユーザー体験を実現 カスタマーサポートの現状 施策 Web閲 覧 Web システム ユーザージャーニー データ
 応対 システム データ
 顧客管理 システム データ
 企業システム RightTouchのアプローチ Web システム ユーザージャーニー 応対 システム 顧客管理 システム 統合データ
 企業システム システム基盤(ミドルウェア) 電話/チャット web閲覧 応対後処理 電話/チャット web閲覧 応対後処理
  5. © 2024 RightTouch Inc. アジェンダ 
 7 自己紹介・会社紹介 
 


    
 プロダクトエンジニアについて 
 
 
 チームの取り組みと課題 
 

  6. © 2024 RightTouch Inc. 8 開発組織に求められること 
 新規開発の多さ 
 レガシーが残る複雑なドメイン

    
 コンパウンド 
 ⾼速開発
 事業性 x 汎⽤性
 スモールチーム
 RightTouchの事業
 求められる開発特性
 高速に検証のPDCAを回し、
 改善し続ける
 複雑な企業ニーズを理解し、 
 あるべき理想の仕様を提案 
 多数の少人数チームで、 
 プロダクトと基盤を並行開発 

  7. © 2024 RightTouch Inc. 組織のベースとなる考え方 : プロダクトエンジニア 
 9 ref:

    アセンドさんのプロダクトエンジニア定義 : https://note.com/niwa_takeru/n/n0ae4acf2964d
 RightTouchのエンジニアは、基本的に下記3つを持つ「プロダクトエンジニア(PdE)」として動く (※もちろん、個⼈の得意不得意/チーム特性によって濃淡と例外はある) フルスタックな技術スキル
 プロダクトや事業への志向性‧視座 UXの設計能⼒ 2
 1
 3
 特定の技術領域に閉じず、機能全体を高速開発できる 
 技術だけではなくプロダクト・事業の成功に目線があり、そのた めに必要なことを考えられる 
 機能の使われ方や、顧客体験を考えて設計できる 

  8. © 2024 RightTouch Inc. 組織のベースとなる考え方 : プロダクトエンジニア 
 1 0

    新規開発の多さ
 レガシーが残る複雑なドメイン
 コンパウンド
 事業特性
 ⾼速開発
 事業性 x 汎⽤性
 スモールチーム
 フルスタックな技術スキル
 プロダクトや事業への 志向性‧視座 UXの設計能⼒ エンジニアに 
 求められること 
 開発特性
 • 職能間コミュニケー ションの最小化 
 
 • エンジニア目線を活か し、 顧客ニーズを適切 に抽象化、技術的可能 性から仕様を作る 
 
 • 強力なPdM無しでも事 業を進められる 得られる効果 

  9. © 2024 RightTouch Inc. プロダクトエンジニア = No PdM?
 1 1

    PdMを置くチームはある。が、特に0→1では強い営業⼒と技術知⾒を両⽴したPdM⼈材は貴重でボトルネックになりがち BizDev/エンジニア/デザイナーが越境しつつ協⼒してプロダクト作りを進めていくケースが多い 0→1:リリース前、事業探索
 BizDev
 越境しつつ協力して
 プロダクトの形を作る
 Biz組織と連携
 PMFを深化させる
 Sales / Success /
 Marketing
 1→10:リリース後、PMF
 ニーズからの仕様検討 
 モノがない状態で営業 
 Engineer
 抽象レイヤーでの 
 仕様検討、
 技術検証、MVP開発
 Designer
 理想の体験からの 
 仕様検討、
 モック作成、 
 MVPデザイン
 PdM
 Bizとの連携
 PMF深化のissueと
 仕様を考える 
 Engineer
 プロダクトissueから
 技術目線で 
 仕様検討・実装 
 Designer
 つまずきなく 
 広く使える
 UI/UXを作る

  10. © 2024 RightTouch Inc. 具体例: RightSupportの開発 (0→1フェーズ)
 1 2 bizdev

    (1) + エンジニア (2-4) + デザイナー (2)
 
 
 • プロダクトのコアとなる、顧客のつまずき (= ペイン)検知の仕様設計を、 bizdev/エンジ ニアでホワイトボードで議論 → データ分 析 → 議論... を繰り返して練り上げる 
 
 • 画面ワイヤー等の仕様は必要に応じて各 ロール関係なく作る
 初期のワイヤー
 ペイン検知議論のホワイトボード

  11. © 2024 RightTouch Inc. 具体例: RightSupportの開発 (1→10フェーズ)
 1 3 PdM

    (1) + エンジニア (3-4) + デザイナー (1)
 
 
 • bizからのFBやビジョンに基づく全体の issue整理はPdM中心に行いつつ、個々 の機能は引き続きengineerが仕様検討 から参加して開発
 
 • エンジニアがsuccess/sales/顧客と会話し たり、機能の要求仕様書を書いたりするこ ともある
 Feedbackの整理
 機能要求仕様書

  12. © 2024 RightTouch Inc. アジェンダ 
 1 4 自己紹介・会社紹介 


    
 
 プロダクトエンジニアについて 
 
 
 チームの取り組みと課題 
 

  13. © 2024 RightTouch Inc. 1 5 プロダクトエンジニアが活躍する環境 
 PdEには技術を超えた越境が求められるが、それに慣れているエンジニアばかりではない。 ゆえに

    エンジニアが⾃然とPdEの理想状態に近づく環境が必要。そのために下記3点を重視 (※PdEのコンセプトに共感していただける⽅を採⽤する、は前提) 構造
 PdEが動きやすい 組織‧技術の 構造を整える 機会
 エンジニアが 顧客や事業全体に 向き合う機会を作る 文化
 PdE的な動きが 当たり前になるような ⽂化を育てる
  14. © 2024 RightTouch Inc. 構造を整える 
 1 6 職能ではなくプロダクト/機能でチームわけ •

    エンジニアが仕様からオーナーシップを持つ • プロダクトを束ねた全体最適の観点は、プ ラットフォームチームの設置、全体仕様議論 の会議体、⼀定頻度でのメンバー⼊れ替えな どでカバー 専⾨性の⾼い分野はスペシャリストを • AIなど、PdEが担いきれない部分を対応。PdE の負荷を低減 Full TypeScript • フルスタック開発が圧倒的に楽 プラットフォームチーム (eng) 新規 プロダクト チーム (bizdev/ eng/des) 新規 プロダクト チーム (bizdev/ eng/des) 既存 プロダクト チーム (PdM/ eng/des) …
 AI (eng)
  15. © 2024 RightTouch Inc. 機会を作る 
 1 7 bizからのインプット •

    ⽉⼀でサクセスから、クライアントのプロダ クト活⽤を紹介 • 不定期で顧客をオフィスに招待 コールセンター⾒学 • ⽉⼀程度、現場でプロダクトが使われている 様⼦や応対の課題をみる slackでのコンテキスト共有 • biz/dev分けずに1つの#memberチャネルでや り取り 商談同席、顧客ヒアリング • エンジニアが担当プロダクトの商談に出たり 仕様をクライアントに当てたり コールセンター見学

  16. © 2024 RightTouch Inc. 文化を育てる 
 1 8 越境と視座の⾼さを是とするRT Mind

    • RightTouchのバリュー • 「全員プロダクト担当、全員顧客担当」「コ ンフォートゾーンを超え続ける」 「Backcasting」など Slackでの賞賛 • mindを体現した発⾔があったら#rt_mind チャネルに投稿される仕組み • PdE的な動きが当たり前に賞賛される #rt_mindチャネル

  17. © 2024 RightTouch Inc. 1 9 課題 • 認知負荷の増⼤ ◦

    組織規模が拡⼤する中で、biz含めた全体を⾒続けるのは難しくなる(特に新しくjoinするエンジニア) ◦ 対応 ▪ slackチャネルの分割を徐々に検討。コンテキストの共有はサマライズされたドキュメントをよ り活⽤していく ▪ プロダクトごとに共通の技術基盤をplatform teamがas a serviceの形で提供する ◦ ただ、認知負荷を下げ切るのはPdEの特性上難しい。 • 採⽤ ◦ 技術スキルを持ち、事業にも熱意とポテンシャルのある⽅が今まで以上のペースで必要。もちろんス ペシャリスト枠も ◦ 対応 ▪ 継続して検討中
  18. 21