カスタマーサクセスエンジニアのお仕事

ごきげんようございます、ソーシャルPLUS チームの id:tmd45 です。今回も社内の技術勉強会（通称 FFTT）で話した内容で書きたいと思います。

毎回一貫性のないネタで（しかもあんまり Tech じゃない話を）話してますが、今回も自分のキャリアについての話をしました。

過去にこのブログで書いたこの記事↓の続編ということになります。

2018/12/05 社内では開発チームマネージャーを名乗っています

知識として役に立つ内容というよりは、自分に合った仕事ができると楽しいよね、とか、エンジニアでもこういう仕事あるよ、とか、ざっくりとした自分語りになります。

では、よろしくお願いします！

2020年10月からカスタマーサクセスエンジニアになりました

いきなり本題ですが、はい、なっておりました。

対外的に自分のポジションを名乗ることがないので、ただの自称なんですが、最近だと元同僚の id:a-know さんが転職先で正式に（？）名乗ってらっしゃいます。

自分ではあまり上手く言語化できていなかったんですが、a-know さんの記事に書かれているポジション名への思いを見て「あー！まさにそれ！」って思いました（あぁ！先に公に言われてしまった！😩というのも思いました。笑）。

他にも Customer Support & Senior Developer とも自称しています。これは単純にいまやっていることを並べた感じの肩書きです。

具体的に何をやってるのか

１つは、メールでのカスタマーサポートを担当しています。

現在ソーシャルPLUS のカスタマーサポートへお問い合わせいただくと、8 〜 9 割がた私がお返事いたします。

ソーシャルPLUS のカスタマーサポートは、メールでご連絡いただくことで対応する、受動的かつ突発的なタスクです。主に企業がソーシャルPLUS を導入するための技術的な事前調査や、導入開発に関する質問が多いです。この導入フェーズを乗り越えていただかないと、本来のソーシャルPLUS というサービスの価値を感じていただくことができないため、とても大事なサポートだと認識しています。

f:id:tmd45:20210408171759p:plain

もともと技術的なお問い合わせも多く、お客様側のシステムや利用方法を加味してご案内する必要がありました。またソーシャルログインプロバイダ側の契約や仕様についても把握している必要があります。技術面まで捉えてお返事するとなると、エンジニア以外では返答に窮することもありました。

もちろん開発チームと連携して回答するというのは以前からやっていましたが、双方のコミュニケーションコストや、開発チームが本来の開発タスクから突発的な質問（しかもちょっと複雑）に対応するための脳のスイッチングコストなど気になることがありました。

f:id:tmd45:20210408182910p:plain

ビジネスチームにはもっとたくさんの企業に利用いただけるようなまさに "ビジネス的" な施策に時間を使ってほしかったし、開発チームには開発に集中する時間をできるだけ作りたいと思っていました。

カスタマーサポートを担当しはじめたきっかけ

先日、我らがチームリーダー、Tech Lead の佐藤の社内インタビュー記事が公開されました。

media.feedforce.jp

去年の夏頃、当時まだ開発チームリーダーだった私と 1on1 をしていた佐藤から、エンジニアとしてのステップアップとして、ソーシャルPLUS の開発チームリーダーとしてもっとコミットしていきたい、という話をもらいました。自分としては断る理由もなく、めっちゃいいじゃん！むしろぜひお願いします！という感じでした。

しかし、そうなると 7 年もソーシャルPLUS にいる自分はどこに向かえばいいのか？という悩みがはっきりと表面化してきました。

ポジションや肩書きに執着はないので、リーダーでもなんでもない、ただの（と言ったらいまチームにいるメンバーに失礼ですけど）バックエンドエンジニアに戻るという道もありました。でも本当にそんな言い方は失礼だなと感じるくらい、いま開発に携わってくれているメンバーは良い開発者たちです。もっと人手があれば、とは常々思っていますが（笑）私がそこに戻るだけで、私の経験や力を充分活かせるのかしらん？それでプロダクトはもっといい方向に進めるのかしらん？と。

前の記事でも書きましたが、以前から自分はビジネス側と開発側の間に入って緩衝材をやったり、落ち穂拾いをしたりしていました。しかし自分が受ける側の 1on1 で「ここから先どうなりたいですか？」と問われて答えに詰まるような期間を過ごしていました。

そんなとき、ビジネス側のいちメンバーから「（a-know さんみたいな）カスタマーサクセスにコミットするエンジニアというのが合ってるんじゃないか」と言ってもらう機会がありました。単純なんですが、それで「あ、そっか」と目からウロコがぽろり。

いままで「担当する仕事じゃないから」と（はっきりそう言うわけじゃないですが）どこか伝言ゲームのようになっていた、問い合わせなどの仕事を、私自身が担当すれば手っ取り早いじゃないかと。それだけじゃなく、これまでのサポートメンバーが兼任で担当していたがゆえに、どうしてもサポート側の知見などを残す手間をかけづらかったところを、アウトプットに慣れた自分のようなエンジニアがやれば一石二鳥。同じように手が回らなかった仕組み化や、プロダクトへのフィードバックもやってやろうじゃないか、と。

チーム内で互いに助け合う文化ができあがっていたので、自分ひとりが何でも知っていなければならないという過度なプレッシャーはなく、とはいえ自分がこのポジションを担当すればなんかいろいろすっきり組み立てられるのでは？というひらめきがありました。

f:id:tmd45:20210408183042p:plain

結局のところ、肩書きが変わっただけとも言えます。肩書きに執着しないと言いながら、行動が肩書きに囚われてしまっていたなぁと。

チーム内外に「ポジションを変えます！エンジニアとしてカスタマーサクセスやります！」と大々的に宣言したことで、やれることの幅が広がりました。広がったというか、しっかりフォーカスする部分を切り替えることができた。そういう意味での肩書きって大切なんだなと思いました。

やってみてどうだったか

自分にはめちゃくちゃ合ってたなと、毎日楽しく働いてます。同僚にも、この仕事にシフトしてからの玉田さんめちゃくちゃ充実して楽しそうに見える、と言われました（笑）。これまでなんとなくもやもやしてたものが、自分の手で解決できていく気持ちよさを感じています。

やってみて、いまの仕事にフィットしている自分の強みはこんなところだと思ってます。

ソーシャルPLUS を 7 年もやってる（それなりの業務知識量）
開発者なのでシステムの調査にスムーズにとりかかれる
こう見えてお客様とのコミュニケーションは昔とった杵柄がある
ドキュメンテーションや情報整理にこだわりがある
細かいことに気がつくほう

前職（もう 7 年も前なわけですが）では頻度は高くないものの、企業のお客様のところへ営業さんといっしょにお話しにいくことがあったり、お客様と日々メールでやりとりしていたりという経験があって、いま役に立っています。SIer という立場で設計開発するときの心配事なんかも少しは知っているので、それも役に立ってるかもしれないなと思う場面があります。

結果として、先に書いたような課題感はどうなったかというと、まだ数値にして改善されたことを確認するなどはできていないのですが

技術的な調査・質問に以前より素早く答えられる形になった
- コミュニケーションコストや待ち時間などの削減
- ひとりの人間が対応できるので調査とお返事の文章作成を同時にできるなど
ナレッジを文章化して残すようになった
- ものによって esa 記事にしたり GitHub Issue にしたりしています
兼業していた他職種のひとが以前より本業に集中できるようになった
- 確認依頼や私でもわからないことを質問して答えてもらったりというのは今もありますが、それでも以前より中断されない時間が作りやすくなったのではないかと思います
- しかもこれがプロダクトマネージャだったりするので影響がでかい 😎

などなど、いい効果が出てると感じます。

ひとりで対応できてしまう＝属人的になってしまう、という問題も重々承知しているので、そうならないようにナレッジ化したり、やりとりを見える化したりというのは大事にしています。強みとして挙げたような "私だからできる仕事" というのも同じくらい大事にしています。

他になにやってるの

カスタマーサポートは私の仕事のうちの１つです。それ以外には Senior Developer として、プロダクトの新しい機能の検証や、機能として組み込むわけではないけどお客様が必要とするような仕様や仕組みを検証するなどしています。

こちらはとくにビジネスメンバーと以前よりたくさん話す機会が増えました。セールスが普段お客様からどのような要望を伺うのか、マーケティングがどういった訴求をしているのか、プロダクトマネージャーはどんな未来を描いているのか。そういうものから何ができそうか、具体的な方法を考えて、開発チームにシステム化してもらうような仕事です。

そこまで明確に切り分けて丸投げしているわけではないですし、開発チーム側からも活発に意見や案が出る環境でもあります。UI 面やお客様に "見せて" 提供する機能はデザイナーが具体案を詰めていくことが多いです。

Senior Developer の仕事は、以前からやっていた落ち穂拾いに近く、それを「私の仕事としてコミットしますね！」と明言して取り組んでるようなイメージです。