dely Tech Blog

クラシル・TRILLを運営するdely株式会社の開発ブログです

エンジニアがCSと上手く連携するためのコミュニケーション

iOS カスタマーサクセス（CS） アドベントカレンダー2018

この記事はdely Advent Calendar 2018の17日目の投稿です。
昨日は、プロダクトデザイナーのミカサ トシキ（@acke_red）が「Fluid Interfaces実践 - なめらかなUIデザインを実現する」というタイトルで投稿しました。

Qiita: https://qiita.com/advent-calendar/2018/dely
Adventar: https://adventar.org/calendars/3535

はじめに

こんにちは、delyでiOSエンジニアをしている堀口（@takaoh717）です。
今日は、普段僕が行っているCS（カスタマーサクセス）担当者との取り組みについてご紹介しようと思います。
僕の普段のメイン業務はiOSアプリの開発ですが、CSの技術的なサポートも毎日行っています。
内容としては、主にクラシルの利用に関する問い合わせが来た際にCS担当者が分からないことの解説を行ったり対応方法を教えてあげたりしています。
今回は1年ほどCS担当者とのやり取りを行った中で、エンジニアがこういうことを意識してコミュニケーションすると良いなと感じたことを挙げてみたいと思います。

CSとのコミュニケーションで意識して良かったこと

ボールを宙に浮かせない

弊社ではクラシルの問い合わせ対応においてはCS用のツールを特に使用していません。
現在は主に以下のツールのみで運用を行っています。
（掲載しているレシピに関する質問への対応は社内ツールを使用しています。）

  • Gmail
    • ユーザとのやり取り
  • Slack
    • 社員同士のやり取り
  • Qiita:Team
    • 対応テンプレ作成やナレッジの蓄積

基本的にはエンジニアとCS担当者とのやり取りはSlack上で行われますが、管理ツールを使用していないと、たまに以下のようなやり取りが発生します。

CS < ユーザからアプリが正しく動作しないと問い合わせが来ましたが、何か分かりますか？
エンジニアA < うーん、こちらでは再現しませんね・・・
エンジニアB < 最近ここ特に触ってないですよね・・・
エンジニアA < そうですね、謎ですね・・・

このまま問題が放置されて、しばらく時間が経ってしまうということが以前はたまに起きてました。 これだと、CS担当者も対応が分からず不安なままですし、何よりユーザを待たせてしまいます。 このように、原因がすぐに特定できない場合は、CS担当者にその旨を伝えてユーザに返信をしてもらうようにします。

↓改善後はこのようなコミュニケーションになります

CS < ユーザからアプリが正しく動作しないと問い合わせが来ましたが、何か分かりますか？
エンジニアA < うーん、こちらでは再現しませんね・・・
エンジニアB < 最近ここ特に触ってないですよね・・・
エンジニアA < じゃあ一旦ユーザには調査する旨を伝えてIssue作成しておきます。
　　　　　　　@CS  ユーザさんに調査する旨をお伝え下さい。

質問しやすい状態を作る

CSの対応ではスピード感がとても重要だと思います。
内容にもよりますが、ユーザの問題の解決は早いに越したことはありません。
そして、素早い対応を行うには、躊躇せずに質問ができる状態を作っておくことが大切です。
そこで、どういう風にすれば素早く質問をしてもらえる状況を作れるかを考えて以下のようなことを行っています。

  • 質問の仕方をフォーマット化する
    • 質問したい問い合わせのユーザのメールアドレスのみをSlackに投稿し、スレッド内に聞きたいことを書く
      • フォーマットが自由になっていると、「お忙しい所すみませんが・・・」みたいなやり取りが無駄に発生しがちです。簡潔なフォーマットが決まっていれば、無駄なやり取りに気を使う精神的コストや文章を考える負担をかけることがありません。
  • 週１回は対面でのコミュニケーションの場を設ける
    • 問い合わせが来たわけではないけれど気になっていることなどをここで質問してもらう
      • オンラインのやり取りだと中途半端な理解で済ませがちなことも、きちんと納得がいくまで説明する機会が作れます。
      • サービスに関する説明は画面を見せながら説明すると理解しやすいことが多いです
  • Slackでやり取りするときは絵文字や！などをなるべく使う
    • テキストのみでの会話だと感情が読み取りにくいため、相手の顔色を伺いながら話しかけるような状態が生まれやすく、生産性の低下に繋がります。

対応方法だけではなく、きちんと仕組みを説明する

不具合があったときに、非エンジニアの人でも理解できる言葉を使って説明することも意識しています。サーバーやデータベースなどの技術的な単語は使わずになるべく一般の人が理解できる言葉に置き換えながら説明を行います。

その一例として、クラシルで実際に起こった例をご紹介します。

起きたこと：
iOSアプリの内部のデータベースの一部のデータの保存先を変更した際に、変更する予定じゃなかったデータ（お気に入り）の読み書き先も変わってしまい、データが表示されなくなってしまった。
この現象を担当者に理解してもらうために以下の説明をしました。

クラシルのお気に入りはアプリの中にデータを保存しています。  
イメージとしては、アプリの内部にWindowsのマイドキュメントのようなデータを保存する仕組みがあると思ってください。
マイドキュメントの中には「お気に入りフォルダ」があります。ユーザがお気に入りボタンを押したときはレシピがこのお気に入りフォルダに入ります。
これが普段のクラシルの状態です。
今回のパターンを説明します。今回はお気に入りとは違うデータを保存しないといけなくなりました。
そこで、マイドキュメントの中に「新しいフォルダ」を作成して、ここにデータを保存するようにしました。
しかし、開発上のミスで、ユーザがお気に入り一覧画面を開いたときに、今までは「お気に入りフォルダ」を開いていたんですが、
「新しいフォルダ」を開くようになってしまいました。

これをちゃんと行うことで以下のような効果があると思います。

  • きちんと仕組みを理解してもらうことで、納得感を持ってユーザに説明することができるようになる
  • 問い合わせ対応の質（説明の内容やスピード）が向上する
  • 問題がどういう状態のものか理解することで、似ているけれど違う要因の問い合わせがきたときに判別ができる
  • 内容は同じだけど、問い合わせの文章が異なっていて同じ要因かどうか判別しづらいものが判別できるようになる

対応方法を共有する場合は、自分がその解に至った経緯やロジックを共有する

何らかのサポートをするときに解決方法を共有しただけでは、次に同じ問題が発生した場合に解決することができない可能性が高いです。 そのため、自分がどうやってその解を導き出したかという経緯も共有してあげると良いと思います。 例えば、こういう感じでコミュニケーションをしています。

  • 「ユーザさんが「昨日から〜〜ができない」と仰っているので◯◯ではなくて、△△に該当すると思います」
  • 「Slackやドキュメントで「〇〇」で検索をしたら、こういう結果が出てきたので△△の対応が適切だと思います」

こういった共有を行うことで、次に同じような問題が発生した際に対応方法は分からなくても調査を行うことができますし、 全く別の問題が発生した場合の調査方法の幅も広がります。

まとめ

以上、自分としてもまだまだ改善できることはあると思っていますが、やってみるとチーム的にもCSの対応としても良くなったんじゃないかなと思っています。 ここで書いた内容に関して、まとめると総じて重要なことは以下のことだと思います。

・ちゃんと納得感を持った上でユーザへの対応行う

・素早く的確にユーザの問題を解決できるようにする

明日はSREの井上が投稿します。こちらもぜひご覧ください！