blog2019-11-01QAからCSへレンタル移籍をしてきた話はじめにプロフィールでは「スニーカー好きのQAエンジニア」と書いていましたが、若干訂正があり...。2019/10/31のおよそ5か月の間、社内のカスタマーサクセス(CS)チームへレンタル移籍に行っていました。ここ5か月弱くらいはほとんどカスタマーサクセスサポートがメイン業務でしたので訂正しておきます。いえ振り返ってみると、QAエンジニアとしてはとても良い経験だったのでここに書いておきたいと思います。(また、11月からはQAエンジニアとして再始動です。件のチームメンバーの退職&産休が重なり、局所的にメンバーが不足するということで、ヘルプのメンバーの招集がかかり、開発チームから自分とバックエンドエンジニアの二人でヘルプに行くことになった。他の職種にチャレンジする際の注意事項として、伝えたいことは一言だけです。望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。今回はチャレンジに前向きなメンバーでヘルプに行ったため、二人とも非常に実りがある時間を過ごすことができました。一方でもしそうでない場合は、トラブルになりかねない出来事だと思うので要注意。Cloud上であげられるサポートケースの調査・回答がメインの業務として行いました。開発チームでの詳しい領域(勤怠管理)のケースを中心に割り振られて回答していました。その他アカウント管理や、データ修正もあわせて実施。この辺りはQAエンジニア前の前に運用プロジェクトのエンジニアとして働いていたこと、サポートチームが手厚い研修をしてくれたため、比較的すんなりと働くことができました。二人で行く形になったのですが、同じ境遇の同期(厳密には違うけど)がいるのはかなり良かった。分からないながらも助け合うことができたり、互いにレビュー等ができたので、それもまた良い方向に作用したかなと思っています。〇:ドメイン知識がついたサポートケースに回答する以上、質問を正確に理解して正しい回答をする必要がある。製品に関する知識、Salesforceに関する知識、勤怠管理にまつわる業務知識、が質問者と同等の理解にないとケースには回答できない。そのため、検証環境を用意して、実際に問い合わせ内容が再現できるか・案内した手順が実施できるか検証を行う。この仕事は開発でのバグの再現確認等とかなり近しい仕事に感じられた。違いとしては、QAの時はある程度で調査を切り上げてfixを担当するメンバーに任せることができたが、原因を突き止める(回答として伝えられる)まで調べる必要があるのが大きい。結果としては粘り強くやることや、限られた時間の中で戦略的に進める力が養われ、自信の知識を整理やさらに深めるために有意義な時間となった。〇:ユーザーの声が聴ける人事や総務が片手間で対応する場合や、システム開発部の担当などシステム管理者といっても様々な属性があることが分かった。作る側にとって難しい仕様は大抵ユーザー側も理解するのが難しい機能になるということが認識できた。ユーザーにとって、問題が製品部分なのか自身のブラウザやネットワークなのかは関係なく、「機能が使えない」という一つの状態になってしまう。して状況を切り分けるための情報が足りていないことが多い。そのため、サポートで切り分けやある程度は相手の気持ちになって状況の推理する必要がある仕事だということが分かった。(ちなみに変に勘ぐってしまい検討違いの回答をする可能性もあるので、思い切ってきちんと状況を整理する等のコミュニケーション力も必要)〇:様々な背景のメンバーと話せる&仲良くなる前職で人事の営業だったり、歴戦の導入メンバーだったり、普段開発チームにはいないようなメンバーと話す・一緒に仕事をすることができた。日々の会話の中で新しいインプットが入ってきたりすることで、また別の刺激になった。サポートケース対応がないときは、仲良くなった営業メンバーが使う資料のデモ画面の準備を手伝ったり、開発メンバーの時とは違った種類の差し込みタスクは新鮮。×:引継ぎは計画的に突発的に移動してしまったので、残されたQAメンバーに負荷を与える結果になってしまい、本当に申し訳ないことをしてしまった。本当に申し訳ない気持ちでいっぱいです。結果的にお詫びの肉をおごることで難を逃れたが、きちんと仕事の引継ぎはするべきだと思いました。あれ、でも...自分も肉おごられても良いのでは...。まとめQAエンジニアに必要なスキルとしてはテストの技術といった「テクニカルスキル」のほかに「ドメインスキル」が重要だと思っている。いう意味でいうと製品のドメインや顧客の属性など様々な情報をインプットすることができたので非常に有意義な時間を過ごすことができた。一方で、有意義な時間を送れたからといって全員が同じ経験をすべきかというとそうでないと思っている。CSチームでのやりがいはお客様の成功(カスタマーサクセス)を通して感じれるかどうかがポイントになりそうだと思った。自分の場合は、困っているシステム管理者がケースを通して課題を解決していく姿に立ち会うことで開発とは違ったやりがいや仕事の意義を見出すことができた。一方で、開発チームとしてのやりがいというのは難しい機能・案件をリリースしたりチームに貢献したりすることで感じる部分だと思っている。互いにやりがい・難しいポイントが違うからこそ、合わない人が同じ経験をしたところでなんの実りにならない時間を過ごすことになってしまうので...要注意。QAエンジニアの自分としてはとても良い経験だったので、ちょっと伸び悩んでて興味がある人はあえて新しい環境に身を置くことで新しい発見があるかもしれないと書いておく。望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。いう一言に尽きるかなと思う。2019会社のオフィスの引っ越しをしたり...www.teamspirit.comJSTQBテストマネージャ試験受けたり...引越し大名やってたせいで、試験勉強の完成度としてはすごい自信ない...。最新記事なぜQAとして発信するのか考えてみた話。月別アーカイブはてなブログをはじめよう!riririusei99さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。