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

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

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

Transcript

1. カスタマーサポート市場の改革に挑む 
 急成長中のプロダクトエンジニアチームの挑戦と舞台裏 1 株式会社RightTouch テックリード
 齋藤成之

2. © 2024 RightTouch Inc. アジェンダ 
 2 自己紹介・会社紹介 
 
 
 プロダクトエンジニアについて 
 
 
 チームの取り組みと課題 
 

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

4. © 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
5. © 2024 RightTouch Inc. 自己解決を促進する 1stプロダクト｜ RightSupport
 5 問い合わせ前の Webサポートで顧客の自己解決を促進し 、電話の問い合わせ削減と web上での解決比率を向上 

6. © 2024 RightTouch Inc. 6 「カスタマーサポート市場の改革」に挑むプロダクトビジョン 
 各システムは個別ベンダーが開発 ユーザー体験は分断、システムは個別最適化 RightTouchが複数プロダクトと基盤を提供(コンパウンド) シームレスで全体最適なユーザー体験を実現 カスタマーサポートの現状 施策 Web閲 覧 Web システム ユーザージャーニー データ
 応対 システム データ
 顧客管理 システム データ
 企業システム RightTouchのアプローチ Web システム ユーザージャーニー 応対 システム 顧客管理 システム 統合データ
 企業システム システム基盤(ミドルウェア) 電話/チャット web閲覧 応対後処理 電話/チャット web閲覧 応対後処理
7. © 2024 RightTouch Inc. アジェンダ 
 7 自己紹介・会社紹介 
 
 
 プロダクトエンジニアについて 
 
 
 チームの取り組みと課題 
 

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

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

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

11. © 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を作る

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

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

14. © 2024 RightTouch Inc. アジェンダ 
 1 4 自己紹介・会社紹介 
 
 
 プロダクトエンジニアについて 
 
 
 チームの取り組みと課題 
 

15. © 2024 RightTouch Inc. 1 5 プロダクトエンジニアが活躍する環境 
 PdEには技術を超えた越境が求められるが、それに慣れているエンジニアばかりではない。 ゆえに エンジニアが⾃然とPdEの理想状態に近づく環境が必要。そのために下記3点を重視 (※PdEのコンセプトに共感していただける⽅を採⽤する、は前提) 構造
 PdEが動きやすい 組織‧技術の 構造を整える 機会
 エンジニアが 顧客や事業全体に 向き合う機会を作る 文化
 PdE的な動きが 当たり前になるような ⽂化を育てる
16. © 2024 RightTouch Inc. 構造を整える 
 1 6 職能ではなくプロダクト/機能でチームわけ • エンジニアが仕様からオーナーシップを持つ • プロダクトを束ねた全体最適の観点は、プ ラットフォームチームの設置、全体仕様議論 の会議体、⼀定頻度でのメンバー⼊れ替えな どでカバー 専⾨性の⾼い分野はスペシャリストを • AIなど、PdEが担いきれない部分を対応。PdE の負荷を低減 Full TypeScript • フルスタック開発が圧倒的に楽 プラットフォームチーム (eng) 新規 プロダクト チーム (bizdev/ eng/des) 新規 プロダクト チーム (bizdev/ eng/des) 既存 プロダクト チーム (PdM/ eng/des) …
 AI (eng)
17. © 2024 RightTouch Inc. 機会を作る 
 1 7 bizからのインプット • ⽉⼀でサクセスから、クライアントのプロダ クト活⽤を紹介 • 不定期で顧客をオフィスに招待 コールセンター⾒学 • ⽉⼀程度、現場でプロダクトが使われている 様⼦や応対の課題をみる slackでのコンテキスト共有 • biz/dev分けずに1つの#memberチャネルでや り取り 商談同席、顧客ヒアリング • エンジニアが担当プロダクトの商談に出たり 仕様をクライアントに当てたり コールセンター見学

18. © 2024 RightTouch Inc. 文化を育てる 
 1 8 越境と視座の⾼さを是とするRT Mind • RightTouchのバリュー • 「全員プロダクト担当、全員顧客担当」「コ ンフォートゾーンを超え続ける」 「Backcasting」など Slackでの賞賛 • mindを体現した発⾔があったら#rt_mind チャネルに投稿される仕組み • PdE的な動きが当たり前に賞賛される #rt_mindチャネル

19. © 2024 RightTouch Inc. 1 9 課題 • 認知負荷の増⼤ ◦ 組織規模が拡⼤する中で、biz含めた全体を⾒続けるのは難しくなる(特に新しくjoinするエンジニア) ◦ 対応 ▪ slackチャネルの分割を徐々に検討。コンテキストの共有はサマライズされたドキュメントをよ り活⽤していく ▪ プロダクトごとに共通の技術基盤をplatform teamがas a serviceの形で提供する ◦ ただ、認知負荷を下げ切るのはPdEの特性上難しい。 • 採⽤ ◦ 技術スキルを持ち、事業にも熱意とポテンシャルのある⽅が今まで以上のペースで必要。もちろんス ペシャリスト枠も ◦ 対応 ▪ 継続して検討中
20. © 2024 RightTouch Inc. 2 0 いろいろあるとはいえ... プロダクトエンジニアの動き⽅は楽しい ⾃分がSIer企業から転職を決めたきっかけでもある 「作ったものが誰の何の役に⽴つのか」をとことん考えられるし、 痛いほど結果が返ってくる 少しでも興味を持った⽅がいれば、ぜひお話ししましょう！ 👇RightTouch採⽤情報