エンジニアHubPowered by エン転職

若手Webエンジニアのための情報メディア

非エンジニアが技術を学ぶメリット - カスタマーサポートとエンジニアのギャップが解消された話

ユーザーの声が集約されるカスタマーサポート部門には、エンジニアの皆さんにとっても参考になる、サービス改善のヒントがあります。ピクシブではカスタマーサポート担当スタッフがエンジニアリングを学び、スムーズなコミュニケーションを実現しています。

Webサービス運営側とユーザーの接点となる職種が、CS(カスタマー・サポート。近年ではカスタマー・サクセスを意味する場合もある)です。サービスに対するユーザーからの問い合わせ対応、時に意見やリクエストをヒアリングするなど、運営側にとって「ユーザーに一番近い」セクションと言えます。そして、ユーザーとの接触から得られた情報には、エンジニアが学べることが多数あります。

今回お話をうかがったピクシブ株式会社ではCS担当スタッフが、エンジニアリングの基礎を学び、CSとエンジニア間のコミュニケーションギャップを解消しようと努めています。同社のコミュニティマネージャーであり、CS担当の塩坪由佳さんに、ユーザー目線でのコミュニケーションのコツ、そしてエンジニアに知ってもらいたい“CSの現場”のお話を聞きました。

塩坪由佳(しおつぼ・ゆか)さん:ピクシブ株式会社 pixiv運営本部 コミュニティマネージャー。2014年にpixivのユーザーサポートとして中途入社。pixivやBOOTH、pixivFACTORYの運営・ユーザーサポートを経て、現在はpixiv SketchとPawooを担当。

CS担当がエンジニアリングを学び、解決したかったもの

——今のお仕事を教えてください。

塩坪 タクシー会社でのオペレーターを経て、2014年にピクシブに入社しました。サービス「pixiv」の担当になり、ユーザーからのお問い合わせを返してました。その後、BOOTHpixivFACTORYpixiv SketchPawooPawoo Musicを経て、現在は新規プロジェクトの立ち上げ時にCS周辺の体制を整えることが多いです。

ほか新規プロジェクトの運営、ヘルプセンター*1の立ち上げ、サービス利用ガイドラインの制定を担当しています。

ガイドラインのページ作成も手がけています。エンジニアの方に「ペライチのページを作って」とお願いすれば一瞬で終わるかもしれませんが、新サービスの立ち上げ時は、エンジニアもディレクターも皆タスクが山積みです。簡単な作業に貴重なリソースを割いてもらうよりも、他のタスクに集中してほしいという考えから、CSもページ作成を行うんです。

——修正依頼もプルリクを投げて、ときにはデプロイまでされるのだとか。

塩坪 CSの立場からページを修正してほしいときは、FAQページに新しい質問を追加したり既存の文言を少し調整するなど、それほど難しくない作業が多いものです。

今でこそGitHubのIssueを使ってコミュニケーションを取っていますが、私が入社したばかりの頃は口頭で直接依頼していました。しかしひとつのページのたった2行の日本語修正を、エンジニアにお願いするのは気が引けていました。

CS担当者が立てたIssue

加えて、今の会社に入るまでWebやITについてはほとんど知らなかったこともあり「エンジニアの人が何を言っているのか全く分からない」という事実にショックを受けました。何をどう依頼すればいいのか分かっていなかったのです。

そんな中、当時開発本部長だった小芝(現VP of Engineering)に軽い気持ちで、エンジニアの人っていつも英語が並んだ画面を見ててすごいですよね、私には分からないですと話をしたら、「それ、塩坪さんでもできるよ、やったらいいじゃん」と言ってくれて。

「そんなのできないでしょ」って驚いていたら「じゃあ、ランチ時間にトレーニングをやりましょう」と言って、他の社員も巻き込んで勉強会の準備を進めてくれました。これをきっかけに、半年間のエンジニアトレーニングが始まりました。

CSがエンジニアリングを学ぶための社内体制

——エンジニアトレーニングでは何を学ばれたのでしょう?

塩坪 教材は当時、弊社のエンジニアが出した『pixivエンジニアが教えるプログラミング入門』という入門書に沿って勉強を始めました。週に1回、ランチタイムに1時間を割いて実施しました。メンターも「やるからには完璧に」という思いが強く、おなかを鳴らしながらトレーニングをした日もあります。

最初はターミナルとエディタの違いも分かりませんでしたが、Webサイト作りを経て3カ月ほどたつとRubyやJavascriptで画像投稿掲示板を作れるくらいになりました。スター*2が実装できるようになったときは嬉しくて、他のメンバーと「たくさん星をつけるぞ〜」と喜びあったのを覚えています(笑)。

なんとか書籍の最後まで進められたものの、プログラミングが身に付いたという感覚は掴めませんでした。小芝に相談したら「実際の業務に役立てるように、各チームからメンターをつけましょう」となり、残り3カ月はより実践的な方法を学びました。他にもWebhook連携やFAQページの日本語編集ができるようになったんです。

私のGitHubのファーストプルリクエストは「FAQページのよくある質問を追加する」です。初めてデプロイしたときの緊張は忘れられません。

CSの後輩も、エンジニアトレーニングの様子を見て興味を持ってプログラミングを学び始め、現在では私含む6人がデプロイ可能なまでになりました。

——プログラミングを学ばれていたとき、挫折はされませんでしたか?

塩坪 エンジニアの方が言っている英語が分からなくて、正直、嫌になった時期もありました。でも今では学んで良かったと思っています。お客様からサービスの挙動でご指摘をいただいたときも「××機能には問題がないようなので、このエラーは○○が原因のものだと思います」というようなコミュニケーションができるようになりました。

肌感ではありますが、ユーザーからの問い合わせへのレスポンスも20〜30%ほど早くなったように感じます。

エンジニアの手を借りながら自社ツールを改善

——コミュニケーション量も増えたのではないかな、と思います。塩坪さんや他のCSの方からの提案によって、サービスに実装された機能はありますか?

塩坪 ユーザーからは見えない部分なのですが、お問い合わせ対応に使っている管理ツールを機能改善しています。

pixivFACTORYチームで、ユーザーへ入稿データに関する連絡をしていたとき、定型文返信の定型文をGoogleドキュメントからコピペして送信する、という作業がありました。書き換えるのは一部分だけなのに、ドキュメントを開いて毎回ほぼ同じ文章をコピーするのは非効率的ですよね。連絡フォームにボタンを付けて、定型文を呼び出せるといいなと考え、エンジニアの方に「実装してほしい」とIssueを立ててお願いしました。

「見た目だけなら塩坪さん作れるでしょ」と言われて、ロジック部分をJSのエンジニアに頼み、表の部分を私が作りました。「こけてもいいからプルリクエストを出して」と言われたこともあり、不安ながらもブランチを切ってコードを書きました。

定型文が呼び出せるよう改良したツールIssue

塩坪 ほかにも、システム化できそうな業務は多くありました。ユーザーidや注文キャンセル後の返金処理などの定型文呼び出しのほか、誤送信を防ぐために、特定の文言が入っていたらメッセージ送信前にアラートを出すなど。エンジニアの方が機能を提案してくれたこともありました。

先にお話したように、ドキュメントからコピペを手作業で繰り返していたら、ユーザーに間違って返信してしまい、ユーザーからの信頼を失いかねません。ですから自動化できるものはどんどんやっていこう、としていった結果、1日に2時間、時には数時間以上かけていたユーザー連絡が、30分程度で終わるようになりました。

エンジニアリングへの知識が低コストなコミュニケーションを生み出す

——塩坪さんが管理ツールの機能追加を提案できたのも、エンジニアトレーニングの土台があったからなのでしょうか。以前はディスコミュニケーションがあったのですか?

塩坪 例えばユーザーから問い合わせがあり、何かしらのバグがあるのではと考えたとします。

以前は「ユーザーからこういうことを言われています、原因が分からないです」とそのまま自分の思っていることを話すことが多くありました。しかしそのままエンジニアに伝えると、「今どういう状況で、何がどの程度分からないのか、あなたはどこまで検証したのか」と言われて、言葉に詰まってしまいました。従来の流れはこのような感じでした。

根気強く何度かやりとりすれば伝わるものの、コミュニケーションコストがかかり、あまり気持ちのいいものではありませんでした。当時はエンジニアの気持ちを知らず「そうは言われても分からないものは分からないじゃん」と思っていたんです。

トレーニング後は、おのずと状況をはっきり伝えられるようになりました。今のコミュニケーションはこのような感じです。

これまで抽象的にしか情報を伝えられませんでしたが、検証端末やOS、ブラウザのバージョンなど具体的な情報を話せるようになり、仕事がよりスムーズに進むようになったと感じています。

CSからエンジニアにお願いしたいこと

——逆に、エンジニアの方へのコミュニケーションに対する要望はありますか?

塩坪 弊社の場合は席も近いですし、何かあっても直接口頭で伝えることが多いので、コミュニケーションに特に問題は感じません。しかし、しいて言うなら2つあります。

リリース情報は共有すべし

塩坪 リリース前に共有することでしょうか。

周知なくリリースするのは避けてほしいな、と思います。過去にユーザーからの問い合わせで初めて新機能のリリースが分かった経験があり、認識のずれから対応に戸惑ってしまいました。こうした齟齬を避けるためにも、CS担当にもリリースの情報は共有してもらうと、対応がスムーズになります。

ユーザー目線での回答をすべし

塩坪 もうひとつは、「ユーザー目線での回答」です。ユーザー(サービス利用者)の目からサービスがどう見えているか、を意識すると見えてくると思います。例えばサービスにバグがあったとき、CSが知りたい情報の優先度は以下のようになります。

※問い合わせベースでバグが判明した場合を想定

CSの考える情報の優先度

バグは一時的対処が可能なのか、対応優先度が低めなのか?
実際に何が起きているか?
復旧するにはどうしたらいいか?
どこを直せばバグが直るのか?

一方サービス開発側だと、つい「今何が起きているか」やバグそのもの対処法を追ってしまいがちです。

エンジニアの考える情報優先度

実際に何が起きているか?
どこを直せばバグが直るのか?
復旧するにはどうしたらいいか?
バグは一時的対処が可能なのか、優先度が低めなのか?

しかしユーザーは、それよりサービスを異常なく使えるかどうかを知りたいと考えられます。ですので、ユーザーから異常を指摘されたときも「運営がすぐに対応できるか」を共有してもらえるとうれしいです。

弊社では毎月CS研修というのを実施し、CS以外の職種でもユーザーからの実際のお問い合わせ文を見てその意図を考え、サービスのお問い合わせに実際に対応する、という機会を設けているので、気を配ってくれるエンジニアの方が多いように感じています。

お問い合わせとFAQはローンチ時から実装すべし

——あわせて、CSの方視点で、Webサービスのローンチ時に必要な機能にはどんなものがあるかをうかがいたいです。

塩坪 お問い合わせフォームや、ヘルプセンター(FAQページ含む)への導線はローンチ時点で必ず実装してほしいです。

ユーザーとしては、問い合わせる必要がない状態の方が良いはず。弊社でもサービスを触りプロダクトマネージャと相談しながら、ヘルプセンターへの導線を実装しています。

直近で立ち上げた「VRoid Studio」。「ローンチ時から想定質問の全てをカバーしよう」とは考えず、徐々に増やしていけば問題ない

最近ではチャットボットを実装しているサービスも多く見かけますが、チャットボットが合うケースとそうでないケースがあると思っています。そのため、ローンチ段階では必ずしも実装しなくても良いのではないでしょうか。

チャットボットが向くのは、この2つにあてはあまるケースです。

  • 問い合わせ内容のパターンが少ない
  • 素早い返信が求められる

弊社では、ユーザーがつどお金を支払って利用するサービスのBOOTHでチャットボットを利用しています。

——ボットの導入まで解説してくださりありがとうございました。最後になりますが、エンジニアの方へのメッセージをお願いします。

塩坪 先に述べましたが、バグが起こってしまうのは仕方のないことですので、正直に伝えてくれるとうれしいです。直らない場合でも、CSがうまく言葉にしてユーザーに伝えます。それがCSの仕事だと思っています。

CSとエンジニアがもっと活発にコミュニケーションを取り合って、相談しやすい環境がつくれたらいいなと思っています。

関連記事

*1:同社ではサービスごとにヘルプセンターが付属し、専属のCS担当者がいる

*2:気に入ったコメントに星を付けられる機能