2018-10-26

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

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

CS担当がエンジニアリングを学び、解決したかったもの
CSがエンジニアリングを学ぶための社内体制
エンジニアの手を借りながら自社ツールを改善
エンジニアリングへの知識が低コストなコミュニケーションを生み出す
CSからエンジニアにお願いしたいこと
- リリース情報は共有すべし
- ユーザー目線での回答をすべし
お問い合わせとFAQはローンチ時から実装すべし

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

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

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

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

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

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

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

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

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

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

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

CS担当者が立てたIssue

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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