DevRel Meetup in Tokyo #17 に参加して、さまざまな学びが得られました。今回は、参加者としての 個人的に思ったこと を書いておきたいと思います。
まず、Meetupに参加して、同じような課題を抱えているんだな、というのがとても身にしみました。デベロッパー/テクニカルサポートと言っても、かなり幅広いと思います。今回のプレゼン・ディスカッションは、API を提供しているサービスのデベロッパーサポートが多く、その中で共感されていた課題、という感じになります。
まずは、資料のリンク: https://devrel.connpass.com/event/50583/presentation/
以下に、ディスカッションで話題になったことと、自分の頭にあったことを残してみます。
サポートチャネルとしてどのチャネルが望ましいか
この話題はきっと尽きないのだと思います。メールをベースとしている会社さんが大多数ですね。そして、次に電話をどうするか、というのが社内での課題となっているようです。議論の中で、電話は履歴が残らない、というのが多くの意見でした。
メール
- メリット
- 文字でやりとりができ、リンク・サンプルコードなどが送りやすい
- サポート側のペースで回答できる
- 他のメンバー・チームに引き継ぎやすい（エスカレーション含む）
- デメリット
- ユーザさんのメール内容わからない時は、聞き返す必要があり、進みが他のチャネルに比べゆっくりめ（ユーザさんの問い合わせ内容により、返答にばらつきが出る）
- ユーザさんがメールで問い合わせるのが面倒くさそうで、壁が高い（エラーログの説明、環境...などなど）
電話
- メリット
- その場で聞き返せるので、おっしゃっていることを理解するできるスピードが上がる
- 話せることの安心感（？）
- デメリット
- 文字で履歴が残りづらい（サンプルコード、リファレンスのリンクなどが送れない）
- 早く受け取らないといけないので、張り付く人が多くの場合必要
- タスクが止まる
その場では、議論になりませんでしたが、ツールによっては、電話をそのまま記録することもできます。Zendesk は少なくとも電話のボイスの履歴を残す機能があります。ボイスを文字に起こしてくれると嬉しいですね。
(以下は議論の中には、出てきませんでしたが、チャネルとしては選択肢としてはあり得るもの)
チャット
- メリット
- 文字でやりとりができ、リンクなどを共有しやすい
- 何度もやりとりが可能で、展開が早い
- 文字で残る
- デメリット
- コールと似て、早く返す必要があるので、張り付く人が多くの場合必要
- （タスクが大部分の場合、止まる）
ツールによってコストの変動が大きいと思いますが、メールを基本線として、他をどう増やすか、というところで考えられている方が多いようでした。個人的には、チャットはデベロッパーサポートには向いてそうだと思いますが、コストが高い印象があります。チャットやメールで対応する場合、もしわからない問い合わせをいただいた時は、周りのメンバーに聞いて確かめて返答できますが、電話の場合、なかなかそれは難しいので、高いレベルの対応力が問われるのではと思います。
サポートと製品開発は兼任すべきか
製品の特徴(カバーする機能数や製品群の数、お客様の数・大きさ、難易度などなど)とそのフェーズによるところが大きいのだろうなと思います。先日のディスカッションでは、サポートするための専任のチームがある会社と、製品開発チームがお問い合わせに直接答える（兼任）、という2種類があったようです。突然やってと言われたり、専任で入ったり、と背景が全く異なるようです。
製品開発チームがお問い合わせに答えるとなると、製品開発に集中できない、というデメリットがある一方で、ユーザさんがわからないところがダイレクトに伝わるメリットがあり、両面があります。
サポート専任のチーム・人がいる場合、良いサポートをするには、製品への理解、そのチームのトレーニングとチーム同士の横のつながりをスムーズにして、情報が適切なタイミングで適所に伝わっている必要があります。
Startup フェーズでのサポート（カスタマーサクセス）について、馬田先生のとても参考になるスライドを貼り付けておきます。
マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得
サポートエンジニアのモチベーションを継続するには
この話題も結構アツかったですね。どうやら、サポートエンジニアを専任としている方と製品開発を兼任している方では、大きくことなる気がします。
サポートが好きな性格、という人は存在します。自分の所属している会社で、性格検査を行ったのですが、その結果が大変に面白いものでした。サポートを主に担当しているチーム（私が所属しているチーム）は、そもそもサポートが好きである、という人が圧倒的に多いのです。アリストテレスの Intrinsic Value に近いのだと思います。こう言うタイプの人は、本当にサポートに向いています。モチベーションがこの仕事そのものだからです。課題は、どのようにキャリアをアップさせるか、そのイメージを常に持っておくことでしょう。
また、問題解決が好き・得意な方も、この仕事でモチベーションを高く保ちつつけるられるようです。デベロッパーサポートの中で多いのはエラー・トラブルが起きた時の対処法の提供です。問題を発見し、ひもといて、解決策をなるべく早く見つける、というのは問題解決の極みです。
視座を変え、組織として考えると、会社としてサポート組織・業務をどう位置付けているか、メンバーのモチベーションに大きく影響すると考えられます。デベロッパーサポートの組織ではありませんが、Zappos のように、サポートが最重要、という会社のメッセージはそれだけで十分力があります。それに合った待遇があれば、かなりのモチベーションが高まるのではないでしょうか。多様なキャリアパスが開ける・開拓できるイメージがあると、さらに面白いと思います。馬田先生のスライド 50 枚目あたりが、まさにこのことを指摘されている気がします。
カスタマーサポートのことは嫌いでも、カスタマーサクセスは嫌いにならないでください
サポート組織・人の評価軸はどうすべきか
これは大変に難しい問題です。サポートのパフォーマンスというのは、いつもながら難しいです。異常値を発見するのは簡単ですが、サポートというのは一体どのように評価されるべきなのでしょうか？
多くの会社が社内の SLA を設けたり、目標とする数値を掲げているのではないかと思います。
- 返答時間（TAT）
- コールのアバンダン率
- 解決時間
- 対応満足度
- Churn rate
- Volume etc
（などなどなりますがきりがないです）
常に見ておくべき数字はきっとあると思います。
評価とすると、結果的には組織の文化として「どうしたいか」から始めることになるのだろうな、と感じました。自分たちが目指すサポートを実現するために、組織を設計し、目指すことを決めることが重要でしょう。面白いと思ったのは、問い合わせの数は増えた方が嬉しい、という意見と、問い合わせは減った方が良いという意見があったことです。これも製品や会社のフェーズによって大きく異なるようです。スタートアップや新しい API など新製品を矢継ぎ早に出している時は、問い合わせが増えているとどんどん使っていただいているし、どこを改善すべきかがわかるので、うれしい悲鳴なのだと思います。また、長く愛されている製品の場合は、問い合わせが減って、できるだけセルフサーブの形が好まれるようです。例えば、teratail とか Stackoverflow などで、自発的にユーザ同士が解決してくれているのが良い例かと思います。その場合、問い合わせ数が減る施策を打ち、評価することになるのだと思います。
さらに、メンバーのパフォーマンスとなるとまた厄介です。問い合わせの難易度にばらつきがあるため、ある人には困難な問い合わせが集中してハンドリングに時間がかかることがあったり、逆にある人には簡単な問い合わせが集中して数値上のパフォーマンスがよく見えたりします。言い換えると、問い合わせ 1 件が評価する際に平等であったか・評価する際の前提条件は何か、という問いが発生します。そのあたりを綺麗に、Tier 1、Tier 2、Tier 3 などとして、一定レベルで切り分けることができるのであれば、メンバーの評価ができるかもしれません。定量的に判断できる部分と、定性的に判断できる部分が混在しそうです。
問題がスムーズに解決される、回答が早い、わかりやすい文章で返答でくる、メールは一回完結、問いを正確に理解して適切な情報を提供、などなど当たり前のように見えることが大変難しい仕事です。私は、この仕事がとても好きです。
デベロッパーサポート、奥が深いです。Qiita に記事をかかれているデベロッパーの方々は、必要な時にはどのようなサポートを望んでいるのでしょう。とても気になりますね。
最後に、もう一度登壇された皆さんのスライドのページのリンクです。
https://devrel.connpass.com/event/50583/presentation/