非エンジニアはエンジニアに勝てないのか？

転職サイトやアプリでカスタマーサポートがどのカテゴリに含まれているかってサイトによってとてもまちまちなのですよね。営業系に含まれていることもありますし、コーポレートに含まれていることもありまして。

たとえば転職サイトのGreenさんだとカスタマーサポートは「企画／マーケティング」という大カテゴリに分けられています。Geeklyさんだと、カスタマーサポートという職種自体はないものの、「テクニカルサポート」だと「社内SE・テクニカルサポート・その他」というカテゴリに入っていますね。

この他にも大カテゴリから探し直すパターンは結構ある気がしていて、いつも検索し始める（そんなにしょっちゅう探していませんが）場合につまづくなと。

それはそれとして。

上記のカテゴライズでも一部当てはまるかもしれませんが、

「カスタマーサポートという仕事はビジネスサイドなのか、開発（エンジニアリング）サイドなのか」

とずっと疑問に思っております。

その企業ごと、または働き方、求められるものの違いによって、ビジネスサイド寄り、開発サイド寄り、という違いがあるのだと思います。はたまた、どっちにも当てはまらない仕事ですよね、というのもあるのかも。極端にいうと「会社の何に貢献する部門なのか」が定まりきっていない、または、企業によって異なる、ということなのかもしれません。（もっというと人件費を開発費に充当するのか販売管理費にするのかとかもあると思いますが。。）

表題に戻りますが、価値を何処に置くのかと考えたときに「製品を売ることができる」「サービスを作る・守ることができる」の違いで、位置づけが変わると思っています。

会社によると思いますし、業務にあたっている人にもよると思うという前提で、わたし個人的には「開発部門と協業する（信頼を得る）」が大きいと思います。この仕事を長くやってきて今更の気づきではありますが、

「お客様のご意見を吸い上げてサービスに活かす」

という模範解答もありつつも、「実サービスと向き合う」という部分に重きをおくのが良いのではないかと思っております。サービス（プロダクト）をリリースすると、運用が発生します。運用＝カスタマーサポートの仕事です。

例えば「聞かれると思っていた」「予測してなかった」等いくつもの問い合わせがあるかなとおもっておりまして、これを「いかにに予測できるか」または、

「予測できなくても、いざ聞かれたときに都度エンジニアに確認しなくてもわかるような仕組みにできないか」

というのも割と大事な仕事だと思います。

とくにSaaSにおいては、運用費用を最小化する、に意識していく必要があると思い。

プロダクトのリリース時には、スピード優先で後手になりがちなものも多くありますが、いざリリース後に

「エンジニアさん！こういう問い合わせがあって調べたいんだけど。。。」「えっと、調べるのはできるけどログ追うんだよね、ちょっとあんまり時間がない、急ぐ？」

こういうのが多々発生します。ログ系だと調べることはできるのですが、時間がかかります。そういった場合、たとえばBIツール等でその情報をサポートでも見れるようにしておけば、確認だけでエンジニアを稼働させなくてすみます（最初はエンジニアにも「合ってますよね」は必要かと）

こういった問い合わせが後にも先にもめったにこないものであれば、無理して仕組み化する必要はありませんが、これまでの経験からある程度「勘どころ」も踏まえて事前に対処（管理画面等でログを追える、BIツールを利用できるようにしておく）しておくと、全体の運用がスムーズにいくのではと思います。

とりどめなくなってしまいましたが、エンジニアとの勝ち負けではなく、うまく得意分野を分け合ってスムーズに仕事をしましょう。っていうことかもしれないですね。

ではまた。