TreasureDataというBtoBのSaaSで、10数人の頃から100人規模になるまでTechnical Support Engineer (今は、Support Engineering Managerだが。)として社会人１年目から関与し、かれこれ4年がたった。その中で、最初期は人数も少なかったので、Sales Engineerのようなこともしたりしていた。日本のエンジニア界隈では、上記のような経験をしている人はそんなに多くないように思うので、BtoBのSaaSにおけるSE/Supportにおける顧客のサービス導入時の役割についてとりとめもなく書いてみる。 （書いている途中で力尽きたのでそのうちちゃんと改めてまとめたい。）
前提
初めに、SaaSのポジションで、SEといったらSales Engineerを指す。どんなことをしているかは、Clouderaの方が書いたブログを参照すると良い（http://shiumachi.hatenablog.com/entry/2016/06/04/160916）。 ちなみにAWSさんなどでは、SA(Solution Architect)というポジション（https://www.amazon.jobs/en/jobs/487213）があり、これは上記のSEの役割とほぼ同じと僕は認識している。そのため、この記事の中ではSEという表現で統一する。
B2BのSaaSにおけるSEとSupportの役割の難しさ
SEとSupportの従来のビジネス（ライセンス販売系やオンプレ系）とSaaSのビジネス（色々ありますが、PaaS/IaaSっぽいやつ）とでは、役割が異なってきている。従来のビジネスでのサービス導入では、SEとSupportの役割がOnboardingとProductionとで分離されており、システム導入フェーズであるOnboardingでは、例えばSIer(System Integrator)を含めて要件定義をする際に良い構成案をアドバイスしたりヘルプするSE。そして、きっちりかっきりシステムが作られ、Productionフェーズに入った後の問い合わせや障害対応をするSupportという形である。
しかし、B2BのSaaSでは、上図のように作った後は保守するだけ〜という考え方ではなく、ユーザがサービスを気にいってくると、自主的に新しい使い方を見つけたり、新しいビジネスで更に活用したりしてよりディープなユーザに発展していってくれる。これはつまり左図のように、Productionに入っているシステムがある一方で、同一プラットフォーム上で新たなOnboardingが発生するということだ。
従来型の考えでSEやSupportをしていると、ここで問題が起きる。それは、この新しいOnboardingが始まることを誰もフォローできず、人知れず失敗してしまっていたり、また初めのシステム用に最適化されたリソースになっている場合に、後者のビジネスの影響でお互いが最適なパフォーマンスがでない。ということが発生し不満がたまり、Churnしてしまう（サービス解約）ことがありうる。 そのため、SEはサービスを売って終わりではないし、Supportは問い合わせを待っているだけではない、という認識が重要になる。
SEとSupportの役割分担は？
お客さんとの会話をするのは、やはりSEである。そのため、Supportで上記のようなビジネス的な機微を見つけたら、SEにSyncし、SEがビジネスも踏まえて会話をする。一方で、Onboardingでもよりテクニカルな内容になったらSupportが裏でヘルプをする。というやり方でお互いにフォローし合う形を、TreasureDataでは現状はとっている。 ちなみに、前述のような機微を見つけたり、逆に新しいビジネスにも使ってもらえるに働きかける役割として、Customer Successがあるhttps://www.slideshare.net/takaumada/startup-customer-success-support。しかし、日本ではCustomer Successという職種はあまり馴染みがない。これはCustomer Successとして役割を切り出すよりもSalesやSEがその役割をになっているケースが多いからだと思う。
結局何が言いたいか
BtoBのSaaSは、サービス全体でお客さんのことを考えて、全ての役職がお客さんのビジネスの成功のために行動する、ということが重要でそれが面白い。
そうしたSaaSの会社でやってみたいと思ったときに、SEやSupportは、単純なエンジニアと違って日本ではあまりポピュラーじゃなくて、けっこう穴場なのでぜひ興味あるところに応募してみると良いと思いますよ！
(本記事はmediumにかいていたものを移行したものとなっています。)
