つかろぐ

もしかしたらどこかの誰かの役に立つかも…

サポートエンジニアNight vol.4 ~Support Team Growth~ に参加してきた

2018/10/18(木)に渋谷のTECHPLAYで行われた『サポートエンジニアNight vol.4』というイベントに参加してきました。

techplay.jp

前日は仕事の都合でRedash Meetupに参加できなかったので、若干そわそわしながら仕事してたのですがトラブルなく参加できてよかったですw

以下はiPadで残した私のメモ書きですが、途中iPadトラブルもあり抜け落ちもあるので参考程度になれば。mac持ち歩くのつらくてiPad持っていったのですが書けないほうがつらみでした。。

また@nora96oさんがtogetterをまとめてくださったのでそちらも貼っておきます。

togetter.com

0人から6人のグローバルサポートチーム、そしてArmへ

最初はトレジャーデータの髙橋 達さん(@nora96o)の発表でした。

www.slideshare.net

  • もともとはCTOがサポート対応してた
    • 高橋さんは週4でサポートエンジニアとしてジョイン
    • セールスエンジニアも兼任
  • サポートエンジニア一人時代の学び
    • お客さんに納得感を与えるのが大事(1stレスポンス大事!)
    • ユーザーを助けるためにあらゆる手段を使う
      • エンジニアなど周囲を巻き込む
    • ユーザーが求めているのは回答ではなく課題を解決することであることを忘れない
      • 問い合わせの先に何があるのかを意識すること(**)
  • OEMサポートは難しい
    • 自分たちのプロダクトでないので質問のリレーになってしまう
    • マルチテナントでないと運用がつらい
    • ユーザーの温度をベンダーに適切に共有するのが大事
  • エンジニアリング組織の拡充
    • 技術的な内容やリリース情報もキャッチアップするのが大事
    • グルーバルサービスだと海外拠点に日本人がいるのが大事
    • 1on1でメンバーとの信頼関係を確立するのが大事
  • 日本でもチームっぽくなる
    • サポート業務だけではなく気分転換になるような施策も必要
      • ただしチームのゴールを見据えたことをやる
  • Data Management PlatformからCDPによるエンタープライズ化
    • 顧客のペルソナが変化
      • テクニカルだけでなくユーザーのビジネスも理解する必要がある
    • なんでもうけない、むりなものはNoという
    • 採用が難しい
      • そもそもクラウドサポート経験者が市場にいない
      • サポートエンジニアの教育制度の構築が重要そう(**)
  • サポートを成長させるためにレポートラインをCTOに戻す
    • プロダクトにサポートは重要
    • エンジニアの下にあるべきではない
  • 課題
    • サポート品質の属人化を避けるためにレビュー体制を整えてナレッジシェアするのが大事
    • サポートとしてお金を稼ぐ
  • 会社がサポートの重要性を認識すること、またそれを共有するのがモチベーション向上、品質向上につながる

QA

  • サポート品質を属人化させないためにやっていることはあるか?
    • レビュー体制が大事(今は人数が少ないので高橋さんが見ている)
  • サポートの教育の取り組みはどんなことをしている?
    • 最初の2週間はメンターをつけて業務やプロダクトの説明
    • 数カ月後にトレーニングもする
  • サポートエンジニアの目標設定はどのようにやっているか?
    • KPIはチームとして持っていて個人にはKPIを課していない
      • 一週間のチケット解決率
      • エンジニアへのエスカレーションレートをn%以下にする
    • 個人にはタスクを課している
      • 対応するユーザーによって偏りがあるのでKPIは設定しづらい
  • チケットのアサインはどのようにやっているか?
    • 人数が少ないので取れる人が取っている

サポートチームの成長に伴う経験談 -10名から100名以上へ-

2番目はSalesforceの杉本 敦康さん(@n_sugimoto)の発表でした。

2011年に杉本さんがSalesforceに入社されてからサポートがどのように変わったかや何をしたかをお話されていました。

docs.google.com

  • ユーザーの利用動向をログから分析してプロアクティブにサポートをしている
  • 部門名がCustomer Successでプランも ○○ Success Plan
  • はじめは10人程度でTier-1/2/3の階層体制で回していた
    • ユーザーとやりとりするのはTier-2まで
  • やったことなど
    • 10〜15人
      • 専門性を持ったチームを作る(スキルグループ)
      • カナダに人を送ってTier-2までの夜間対応を可能にした
    • 15〜45人
      • メール問い合わせを廃止した
        • チケット化の作業が減る
        • セキュリティリスク(メール誤送信)も減る
      • 問い合わせの多い時間にリソースを充てた
      • スキルグループを分割してナレッジ共有の効率化
        • どのグループが対応するかを分割するトリアージチームも導入
      • 顧客満足度調査をサンプルではなく全ユーザーに送るようにして分析品質を上げた
    • 45〜80人
      • ポータルで問い合わせ内容をサジェスト
      • 有償でサポートするチームを立ち上げた
      • 新卒採用
    • 80〜100人
      • Trailheadを公開することでユーザー同士のコミュニティが活性化
      • ユーザー同士が解決してくれることで問い合わせが減る
      • TAMを立ち上げた

QA

  • 2014年にチケット数がスパイクしたのはなぜ?
    • プラットフォームの障害や変更が大きな要因
    • ユーザーが増えたのもある
  • TDだと属人化を避けるために分担する、SFはチームで専門化していて矛盾するがバランスのとり方は?
    • すべてを全員でやってしまうと個人に属人化しやすい
    • チーム内で属人化しないようにしている(個人の属人化を避ける体制)
  • 日本の体制とグルーバルの体制の差は
    • スキルグループとしては同じ、日本は兼任があるけどグローバルは専任
  • スキルグループ間やTier間での移動はある?
    • 状況にも依るが本人の希望である
  • 顧客満足度が低い状態から高いところに持ってこれた理由は?
    • 対応までのスピードを上げた
    • 低評価をつけたユーザーにマネージャーから直接電話して理由を聞いた

日本人ひとり体制からの外資系ソフトウェアサポート

3番目はRed Hatの木村 貴由さん(@nekop)の発表。

もう10年近くtwitterでフォローさせて頂いているのですがはじめてお目にかかれました!! docs.google.com

  • 製品とメンバーが増えてトレーニングが重要に
    • 世界中でトレーニングコンテンツが作られ個人リソース依存になってしまう
    • 解消するためにトレーニングチームがオフィシャルなコンテンツを作る
  • 製品が増えるとユーザーも増える
    • ユーザーのレベル格差が激しく不条理なエスカレーションもある
    • テクニカルに問題解決できる人が苦情対応してる状況を改善するためにエスカレーションマネージャーをたてる
  • 国防関連のケースはタイトルまでも暗号化されていたり、監査ログ等を取っている
  • 再利用性の高い問い合わせはナレッジ化する(KCS - Knowledge Centered Service)
  • OSSを扱うサポートの差別化要因はナレッジ
    • ドキュメントだけではなく製品に詳しい人とやり取りできるといった人もそのひとつ
  • サポート発でRed Hat Insightsというサービスを作った
  • プロアクティブサポート
    • Technical Account Manager
    • Customer Success Manager
  • 4x10シフトは日本の法律や社会との相性が悪い
    • 社会が9〜18時で設計されている(保育園に子どもの迎えに行けないとか)
    • 土日のどちらか働く必要があるので奥さんがひとりで子どもを見ることになる
  • RedHatの日本のミドルウェアサポートは12年で退職者0!!
  • 給料と福利厚生は大事
  • 顧客UX改善のために
    • ケースクローズまでの期間
    • ケース開く前に解決
    • CES
    • NPS
  • 組織が大きくなると起きる問題
    • 人が増えるとミーティングが増える
    • 評価制度が難しい
      • 目標の解釈が異なるアウトプット

QA

  • エンジニアにどうやってドキュメント書く文化を浸透させたか?
    • ドキュメントテクニカルライターチームが第三者視点で実際に利用しながらドキュメントを書き上げていく
    • 書いたドキュメントがユーザーの問題解決をするとモチベーションに繋がる
  • CESの「サポートを利用するのが面倒か?」とはどういうことが面倒と感じさせているか?
    • CSATスコアはユーザーによって乖離が激しく定量的ではない
  • エスカレーションマネージャーのキャリアとモチベーション維持はどうしているのか?
    • 個人に負荷が集中しない仕組みになっている
    • 別リージョンに仕事を引き継ぐのも業務なので集中はしない
    • エスカレーションマネージャーは外部から来ることもある

Change and Growth of MapR Support

最後はMapR Technologiesの山田 賢さん(@bigt23)でした。

docs.google.com

  • 会社がサポートが大事だと認識している(これすごくいい!!)
    • サポートはアウトソースせずに社内で育てる
  • もともと2拠点しかなかったサポートをローカルサポート出来るように9拠点に増やす
    • 英語サポートは24x365で対応
  • 日本人が求めるサポート品質の要求が高いので対応するのは日本人がベスト
  • SLA、CSAT、MTTR、NPSなどで評価している
  • チケットは分類分けして対応するエンジニアが消化している
  • 教育は公開しているトレーニングやドキュメントベース

QA

  • グローバルチームとの連携は?
    • 情報共有や困ったときのヘルプはチャット等で気軽にできる

感想

前回のサポートエンジニアNightが急遽参加できなくなってしまったので今回はじめての参加だったのですが、各社の成長のフェーズ毎に生じる問題などを伺えたのは非常に興味深かったです。

人数が少ないうちは如何に効率的にチケット消化するかが課題で、人が増えてくるとコミュニケーションに課題が生じるなどありがちではありますが、提供するサービスやユーザーの性格など状況に応じてサポート体制の構築の仕方も違ったりでこの辺の見極めが出来ないと肝心なサポート自体が破綻しかねないなと感じました。

また、なるべくユーザーに問い合わせさせない(問い合わせなくても解決できる)仕組み作りや教育体制は各社課題のようですね。お話にもあったのですがユーザー同士のコミュニティを持つような運営はかなり大事だなと思います。

僕は現職がテクニカルサポートではない(目指している!)立場なので、こういう知見を共有して頂けるのは本当にありがたい!

また次回も参加できるのを楽しみにしています!!