dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

「各社CREチームのサポート体制と独自の取り組みについて【はてな|freee|アンドパッド】」参加メモ

参加しました。

動画

ハッシュタグ#hatena_freee_andpad

以下メモです。

テクニカルサポートをプロダクトの強みにするMackerel CREの取り組み

f:id:dackdive:20220224210845p:plain

f:id:dackdive:20220224210905p:plain

  • サポートのフロー

f:id:dackdive:20220224211345p:plain

  • CRE内にテクニカルサポートとカスタマーサクセスがある
    • 今日はテクニカルサポートの話が中心
  • どう対応しているか
    • すでに情報があるもの:セルフサービス化
      • 独自のセルフサービススコアという指標で、お客様がどれぐらい自己解決できたかをモニタリング
      • FAQの検索語監視君
        • FAQで検索したけど検索結果が0件だったものを、検索回数が多い順に定期的に Slack に流す f:id:dackdive:20220224210950p:plain
    • 定形の回答がないもの
      • CREによる調査:環境の情報提供、ソースコード確認、アプリケーションログ
      • CREでもだめならエスカレーション。開発チームにもサポート担当がいる
      • 応用的な活用方法の提案
    • 課題
      • ヘルプとFAQのプラットフォームが異なるので相互にサジェストできない
      • セルフサービススコアは実際に自己解決した割合ではない
      • プロダクトへのフィードバックループの強化

freeeのCRE誕生から現在までの歩みとセルフサービスへの挑戦について

  • 問い合わせフロー
    • ユーザー起点なのか開発者起点なのかでフロー分けてる。開発者起点の場合は最初からCREが対応

f:id:dackdive:20220224213156p:plain

  • プロダクトとチーム進化の軌跡
    • 最初はテクサポチーム
  • 業務内容 f:id:dackdive:20220224213315p:plain
    1. 問い合わせ対応
      • 全体のフロー改善も担当
      • 対象プロダクトはfreeeのプロダクトラインナップのうちの一部
    2. セルフサービス開発
      • chat bot開発など、ユーザーが自己解決できるしくみを
  • チーム構成
    • プロダクトごとにさらにユニットに分かれている
    • ユニットごとにOKRにを設定
      • ユーザー様回答までのSLOを持ってるユニットや、一次回答までのリードタイムを目標にしたり
  • チームの歩み
    • QAチームの1チームとしてテクサポ誕生
    • 最初はフローを整えることに専念

f:id:dackdive:20220224213723p:plain

  • エンジニアへの問い合わせ数は順調に減っている
  • 03 セルフサービスの開発
    • chat bot
    • お問い合わせフォーム統合
    • ヘルプページ刷新: Zendesk → React + TypeScript、検索を Algolia に
  • これから
    • ユーザー対応領域:解決時間を短く
      • セールスエンジニア的な動きを模索中
    • プロダクト対応領域:問い合わせを減らす

アンドパッドのテクニカルサポートと要件定義への関わり方

  • 問い合わせフロー
    • カスタマーサポート、営業、カスタマーサクセスが問い合わせを受ける
    • CREは問い合わせの一次窓口という感じ

f:id:dackdive:20220224213605p:plain

  • バグ対応フロー
    • CRE自身は修正まではやらない
  • テクニカルサポートにおける意識
    • SaaSであることを意識する
    • お客様の疑問の意味を常に考える
  • 現状の課題
    • 仕様か不具合かの判断が難しい
      • 仕様FAQ作成中
    • ドメイン知識の難しさ
      • オンボーディング資料として各種ドメイン資料を作成中
  • 要件定義への関わり方
    • 開発チーム側へCREとしての懸念を伝える
      • 関連する機能(影響範囲)
        • 機能が複雑化、マイクロサービス化により機能間の連携が増える
        • 問い合わせを一本化しているので様々な問い合わせが CRE に来る→幅広い知識を身につけているCREからの目線を伝える
      • 改善を実施することによって実現される運用上の影響
        • ある改善が一部のお客様にとってデメリットとなる

パネルディスカッション〜各社の取り組みのここが気になる!〜

Q. ドメイン知識はCREとしてどれくらい求められる?
  • 段階があると思う by アンドパッド
    • テクニカルサポートをするに十分なドメイン知識は教えていきたいと思っている。それを学ぶ方法がないというのが現状の課題
  • 専門的な知識が必要だと思うところはある by freee
    • プロダクトの仕様に関することは過去の問い合わせのナレッジなどもあるのでそれを参考にしながら
Q. CREはまだできて浅い職種なので、役割定義が難しいと感じています。どのようにCREを定義していますか?
  • はてな
    • セールスエンジニア→CREという経緯
    • 隔週ぐらいでCREについて考える会をやっていた
  • freee
    • 混乱期って書いてた
    • テクニカルサポートの延長戦上、って思われてしまいがちだけど、エンジニアとして問い合わせ自体をなくしていく活動も大事
  • アンドパッド
    • freee さんと似てるなと思った。2年遅れぐらいで歩んでる
    • エンジニアの負荷を下げて、エンジニアが本来やるべきことに専念できるようにする
Q. 各社CREの採用のときにどのようなCRE像をイメージしていますか?
  • freee
    • ドメイン知識は最初から要求していない
    • どちらかというとエンジニアの素養
    • 最先端の技術使いたい、よりユーザーに寄り添いたい、という気質の人
  • はてな
    • お客様の課題にどれだけ自分ごととして関心を持てるか
    • 面接でも「こういうこと言ってるお客様がいたらどのへん気になりますか?」とか聞く
  • アンドパッド
    • 顧客信頼性とはお客様の本当の課題を解決すること
Q. はてなへの質問
  • お知らせメールをCREで出すに至った理由は? by freee
    • セールスエンジニアからスタートしていろんな業務を吸収してったという歴史的経緯から
    • エンジニアは仕様とか厳密な文章書くのは得意だが、お客様が知りたいことを想像して書くみたいなのはCREの方が得意
    • お知らせ書くことがCREにとってめちゃめちゃ勉強になる、というのもある
Q. freee への質問
  • なにから手を付けるか、どこからやるか、という優先度はどう決めている? by はてな
    • CREだけで決めてるわけではなく、サポートチームと連携してやっている
  • チャットでも優先度の基準ってどういう感じで策定してますかってあった
    • あれは「サポートからエンジニアに依頼するときの優先度」の話だと思う
    • 優先度を策定した。代替手段がないもの、とか判断の軸を作った
Q. アンドパッドへの質問
  • 要件定義にも関わるとのことだが、そのきっかけは?
    • 元々は個人の経験を活かして。テクサポチームがない時代に、自分の役割とか抜きに誰かが困ってることをやっていた

所感

サポート体制や業務内容、現状の課題など各社の具体的な話が聞けて参考になりました。
CRE という職が生まれた歴史的経緯が会社によって様々なので、サポートひとつとってもどのような体制でCREが何をどこまで担うかはけっこう違う印象を受けました。また、どこも「CREとはこうあるべき」という絶対的な解は持ってなく模索中なんだなとも。

CRE は「エンジニア」である以上、日々のサポート業務にとどまらず技術で問題を解決することが求められると思っていますが、一方でフローの整備など泥臭く地道な作業も各社やられていて、そのへんは今まさに自分もやっていることなので安心しました。