【CS修行の道】CS（カスタマーサポート）と開発チーム【2日目】

CS修行の道、2日目。
今回は、僕自身も業務を遂行する上で必要不可欠な開発（エンジニア）チームに関しての記事を読みました。

この記事自体はnoteさんのエンジニアチームのCS対応の取り組みについてがメインですが、「それわかるー」と100回くらい頷いたり、これができたら理想だわぁと納得することばかりで、とても勉強になりました。

問い合わせ対応は知識を増やすチャンス

noteさんでは、エンジニアが問い合わせ対応をすることで知識を増やし、成長のきっかけにしたいという思いがあったそうです。
僕も前職時代にサポート担当をしていた際、サポート業務を通じて新入社員を育成することに関わっていたので、実感としてその通りだなと思います。
ユーザーさんってほんとにいろんな方がいらっしゃるので、1ヶ月の研修でも自社のサービスについてはもちろん、関連する知識も結構身につくんですよね（本人の意欲にも左右されますが）。

そんな研修担当を任されていた僕はといえば、「今日はめんどくさい問い合わせ来てないといいなー」なんて思いながら、毎朝メールの受信ボックスを開いてばかりで（笑）。
サービスの特性上、ユーザーとクライアントの間に挟まれる立ち位置だったこともあり、それぞれが自分の立場で主張をするので、都度調整役に回ることが多く、それに疲れてしまうことが多々ありました。

そんな僕が今の会社ではどうなってるかというと、初めて見るパターンの問い合わせが来ても「どういう理由で上手くいってないんだろう？」とか、「この事象の原因って何？不具合？それとも端末依存？」みたいな、一種の謎解きゲームみたいな感覚で楽しんでることが多いです。

自分でも驚くほど、問い合わせに対する意識が違ってるんですよね。もちろん今の会社は自社でサービスを開発し運営しているという違いもありますが、カスタマーサポートって仕事に専念できていて、それなりに結果も出せていることも理由かもしれません。

そんな感じなので、今まで対応した経験の中ですぐに解決できることは爽快な気分になりますし、自分の知らないことにも比較的前向きに取り組めているのかなぁと。
ただ、自分の理解が足りない機能とかの問い合わせには、まだちょっと構えてしまうところがあるので、まだまだ勉強して行く必要があると思っています。

チームの課題を解決するには、ディスカッション・ルール化（仕組み化）する

これもその通りだと思っていて、チームの課題（だと自分が思っていること）が必ずしも他のメンバーが同じように理解しているとは限りません。
「それはそういうものだ」と、良くも悪くも会社のカラー・文化的なものとして認識されている場合もありますし、課題として捉えられていないこともよくあります。

それを解決するには意見を出し合って議論して、あーだこーだ言う機会は重要だと思います。

そして、その議論の中で決めた方針をルールとして明文化して、チームとして取り組んでいくことで、これまでの固定観念を打破しつつ新たな価値観を作り上げ、より良い対応ができるチームへと変えていけるのかなぁと、漠然と考えています。

結局、人ってルールがないとやりませんし、最初は意欲が高い人でも、ふとした瞬間に気が緩むこともあるので、ルールを定めておくことは思っている以上に有効だなーと思います。
ルールを作ると、必ずルールの監督者みたいな人が現れるので（笑）、ルールを守ってない人をちゃんと指摘できたりするので、やっぱりルールって大事なんだなと。

サポート専任のエンジニアはモチベーション管理が難しい

自分はエンジニアさんに調査をお願いする側の立場ですが、「お願いされる側」に立つことを考えると、確かに調査メインはキツいよなぁ、と（笑）

サポート専任ではなく、開発と兼任だとしてもプロジェクトの進行が停滞するリスクが出てくるので、バランス取りはなかなか難しいですね。
普段「CS専任のエンジニア欲しいですよね〜」みたいなことを軽々しく言ったりしますが、今後は自重しようと思います←

僕の会社の場合、サポートからエスカレーションするエンジニアさんは日替わりで担当を変えていますが、別にプロジェクトを抱えながら日々調査をしてくれていることに改めて感謝したいと思います。

逆にエンジニアさんの負担を少しでも軽くするべく、自分のナレッジを貯めたり、自分で確認できる範囲を広げたり（例えばデータベースを確認したりとか）、開発に聞くことなく自分で解決できることを増やすことを意識しています。
できることが増えるのって純粋に楽しいですし、自分だけで解決できたときに一人でドヤ顔してます（笑）。

とまぁ、今回はエンジニアさんの立場で考えつつ、サポートチームとしても非常に参考になったので、今後に活かして行きたいなと思います。