QAからCSへレンタル移籍をしてきた話

はじめに

プロフィールでは「スニーカー好きのQAエンジニア」と書いていましたが、若干訂正があり…。
実は2019/06/10 ～ 2019/10/31のおよそ5か月の間、社内のカスタマーサクセス（CS）チームへレンタル移籍に行っていました。
なのでここ5か月弱くらいはほとんどカスタマーサクセスサポートがメイン業務でしたので訂正しておきます。
とはいえ振り返ってみると、QAエンジニアとしてはとても良い経験だったのでここに書いておきたいと思います。
(また、１１月からはQAエンジニアとして再始動です。)

レンタル移籍の経緯

件のチームメンバーの退職＆産休が重なり、局所的にメンバーが不足するということで、ヘルプのメンバーの招集がかかり、開発チームから自分とバックエンドエンジニアの二人でヘルプに行くことになった。
他の職種にチャレンジする際の注意事項として、伝えたいことは一言だけです。

望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。

今回はチャレンジに前向きなメンバーでヘルプに行ったため、二人とも非常に実りがある時間を過ごすことができました。
一方でもしそうでない場合は、トラブルになりかねない出来事だと思うので要注意。
ホントに注意。

CS（Customer Success）チームの仕事内容

Salesforce上のアプリケーションなのでユーザーのシステム管理者からComunity Cloud上であげられるサポートケースの調査・回答がメインの業務として行いました。
開発チームでの詳しい領域（勤怠管理）のケースを中心に割り振られて回答していました。
その他アカウント管理や、データ修正もあわせて実施。

この辺りはQAエンジニア前の前に運用プロジェクトのエンジニアとして働いていたこと、サポートチームが手厚い研修をしてくれたため、比較的すんなりと働くことができました。
また、偶然二人で行く形になったのですが、同じ境遇の同期（厳密には違うけど）がいるのはかなり良かった。
分からないながらも助け合うことができたり、互いにレビュー等ができたので、それもまた良い方向に作用したかなと思っています。

よかった事・悪かった事

〇：ドメイン知識がついた

サポートケースに回答する以上、質問を正確に理解して正しい回答をする必要がある。
製品に関する知識、Salesforceに関する知識、勤怠管理にまつわる業務知識、が質問者と同等の理解にないとケースには回答できない。
そのため、検証環境を用意して、実際に問い合わせ内容が再現できるか・案内した手順が実施できるか検証を行う。
この仕事は開発でのバグの再現確認等とかなり近しい仕事に感じられた。

違いとしては、QAの時はある程度で調査を切り上げてfixを担当するメンバーに任せることができたが、原因を突き止める（回答として伝えられる）まで調べる必要があるのが大きい。
結果としては粘り強くやることや、限られた時間の中で戦略的に進める力が養われ、自信の知識を整理やさらに深めるために有意義な時間となった。

〇：ユーザーの声が聴ける

人事や総務が片手間で対応する場合や、システム開発部の担当などシステム管理者といっても様々な属性があることが分かった。そして、作る側にとって難しい仕様は大抵ユーザー側も理解するのが難しい機能になるということが認識できた。

また、ユーザーにとって、問題が製品部分なのか自身のブラウザやネットワークなのかは関係なく、「機能が使えない」という一つの状態になってしまう。そして、往々にして状況を切り分けるための情報が足りていないことが多い。
そのため、サポートで切り分けやある程度は相手の気持ちになって状況の推理する必要がある仕事だということが分かった。
（ちなみに変に勘ぐってしまい検討違いの回答をする可能性もあるので、思い切ってきちんと状況を整理する等のコミュニケーション力も必要）

〇：様々な背景のメンバーと話せる＆仲良くなる

前職で人事の営業だったり、歴戦の導入メンバーだったり、普段開発チームにはいないようなメンバーと話す・一緒に仕事をすることができた。
日々の会話の中で新しいインプットが入ってきたりすることで、また別の刺激になった。
サポートケース対応がないときは、仲良くなった営業メンバーが使う資料のデモ画面の準備を手伝ったり、開発メンバーの時とは違った種類の差し込みタスクは新鮮。

×：引継ぎは計画的に

突発的に移動してしまったので、残されたQAメンバーに負荷を与える結果になってしまい、本当に申し訳ないことをしてしまった。
本当に申し訳ない気持ちでいっぱいです。
結果的にお詫びの肉をおごることで難を逃れたが、きちんと仕事の引継ぎはするべきだと思いました。
~~あれ、でも…自分も肉おごられても良いのでは…。~~