2018年10月18日、渋谷TechPlayにて「サポートエンジニアNight vol.4 ~Support Team Growth~」と題したMeetupが開催されました。4回目となる今回は、「X人からY人までサポート組織が成長したときに発生した課題や失敗」をテーマに4名のスピーカーが発表しました。
組織規模によってサポートエンジニアの役割は多種多様です。その中でも最初の一人のサポートから成長を支えた経験・十数人から数百人規模、数百人からさらに巨大になっていくサポート組織を生で経験し、その中で得られた知見はとても貴重なもので、これまで共有されてきたこともあまりありません。会社の成長とともにサポートエンジニアとして経験した課題や取り組み・失敗談を赤裸々に語りました。全文掲載にてお送りします。

--

今回、トレジャーデータさんに登壇依頼のお話いただいたときに、今回のテーマは成長ですということだったので「うち、あまり成長してないんで結構です」と断ったんですけど、成長はとりあえずいいから何か話してといわれたで、せっかくなのでお話させていただきます。私はMapRに2年半ぐらい在籍しているんですけど、その中でのチェンジのところについては少しシェアできるので、チェンジ9割、成長1割ぐらいで聞いていただければと思います。

自己紹介ですが、私は2016年にMapRに入りました。その前は広告プラットフォームのバックエンドエンジニアをずっとやっていました。そのときHadoopは触っていたんですけど、MapRは全然触ったことなくて、今考えるとすごくいい加減に入ったなと思うんですけど、なんとか2年半やっていっています。
本日のアジェンダですが、最初にMapRという会社とそのプロダクトについて紹介させていただいて、そのあと、サポートの役割について紹介し、最後に今回の本題であるチェンジについて紹介していきます。MapRという会社を聞いたことある方ってどれくらいいらっしゃいますか？　結構いらっしゃいますね。ありがとうございます。

AIとアナリティクスのプラットフォーム、MapR

親戚とかに、MapRで働いているよって言うと、地図の会社なんだねって言われるんですけど、うちは地図の会社ではなくて、一般的にはHadoopのベンダーとして位置づけてもらっていると思います。うちの会社では、MapRはAIとアナリティクスのプラットフォームである、と言っています。Hadoopについては皆さんご存知ですかね？　MapRって正確に言うと、Hadoopではないです。Hadoopとコンパチのものを作って売っている会社であって、最近Hadoop関連だとすごく大きい統合があってニュースになったりしてたんですけど、統合してないほうの会社になります。本社はサンノゼの隣町のサンタクララというところにあります。
MapRは分散ファイルシステムをひとつのプロダクトとして売っている会社です。MapRはPOSIXやHDFSのAPIを通してこのファイルシステムにアクセスすることができます。その結果Hadoopのエコシステムが動くので、Hadoopベンダーとしても位置づけていただいているという感じです。

HDFSとMapRのファイルシステム(以降MapR-FS)の違いで言うと、HDFSはJavaで書いたファイルシステムですが、MapRは主にC/C++で実装されていてガベージコレクションは発生しません。HDFSはライトワンスなファイルシステムですが、MapRファイルシステムは読み書きできるファイルシステムです。HDFSだとメタデータは基本的にひとつのノードに集約しますが、MapR-FSはメタデータも分散して持ちます。直接ディスクにアクセスするようにファイルシステムを実装しているので、Linuxのファイルシステムにも触る必要はないというのがMapR-FSです。

そのほか、MapRが提供しているプロダクトに、MapR-DBやMapR-ES(MapR 6.1.0からMapR Event Store for Apache Kafkaに改名)というのがあります。DBは、これも分散データベースなんですけど、2つあって、1つはバイナリーDBというので、これはHBaseのコンパチを目指して作っているものです。もう一つのMapR-DB JSONというのは、JSONのドキュメント型のNoSQLです。MapR-ESというのは、分散ストリーミングシステムで、これはKafkaの代替を狙って作っているものです。

今までのところをまとめますと、これはHadoopとの比較になりますが、HadoopではまずLinuxのファイルシステムがあって、その上にHDFSが乗っていて、その上にHBaseとかのエコシステムがあります。一方でMapRは、ディスクに直接アクセスするプロセス上でこれらの機能を提供します。MapRにはPOSIXを通じてNFSでアクセスすることもできるし、HBaseのAPIでデータベースとして利用することもできます。Kafkaの分散ストリーミングとして使うこともできるという、かなり野心的なプロダクトだなと私は思っています。非常にユニークな考え方だなと思うんですけど、こういうものがMapRで提供しているプロダクトになります。

MapR上のHadoopエコシステムをサポート

このプロダクトをサポートしているんですけど、先ほど言ったみたいに、MapRはHadoopのエコシステムが動くので、MapRの上でいろんなエコシステムが動いて、私はこれらをサポートしています。具体的にはHive, Tez, Spark, Drill, Hue, Sqoopといったものがあって、範囲が広いというのがうちのサポートの特徴かなと思います。今のはクラスター上ですが、クライアントのツールというのもサポートしています。サポートの業務の流れですが、お客様とパートナー様からチケットが入ってきて、これをチケットのポータルだったりメールだったり、WebExで電話会議したりしながらチケットを捌いていくというかたちになります。チケットはお客様以外からも、うちのセールスとかSEからも来るので、これも対応したりします。

これバグだなというところでは、サポートから開発のエンジニアに修正リクエストを投げるというかたちです。開発エンジニアは日本には残念ながらいないので、グローバルのエンジニアと一緒に問題解決し、解決したらお客様にご案内するということをしています。弊社のサポートの位置づけになるんですけど、社長からはプロダクトのキーファクターだと認知して注力していると日頃から言ってもらっています。サポートへの注力の例として、パートナーさんが拡販する代わりにサポートもそのパートナーさんにアウトソースしませんかという話が来たことがあるらしいんですが、「今はサポートをプロダクトとしてしっかり育てていくという状況です」ということでお断りしたということもあったらしいです。

MapRのサポート体制と目的

ちょっと長くなりましたけど、次がチェンジ&グロースです。MapRは最初はサンノゼで始まった会社で、サポートもサンノゼに数名と、ハイデラバードに数名というかたちでスタートしています。今はローカル言語採用で東京とソウルに何人かいるという状況です。TAMはサンノゼにもいるんですけど、フィラデルフィア、ドイツ、あとハイデラバードにもいます。その他にリモート勤務でやっている人もいます。あとサポートに属している開発がいるんですけど、その人たちはウクライナに何人かいます。こうやって、24時間体制でサポート業務を回しています。ただ、ローカル言語対応に関しては24時間体制はとれていないです。

日本の業務に関しては2013年に1人フロントラインのエンジニアが入って、2016年に私がフロントとして入って、今までいたフロントの人がバックに移ったという状況です。そもそも日本になんでサポートチーム必要なんですかというところなんですけど、最初は翻訳サービスを使ってやっていたらしいんですけど、それだとテクニカルのディテールのところでコミュニケーションがうまくいかなくなり、やっぱり日本人採用しようということになったそうです。あと、日本のお客様とかパートナー様の要求の水準が高く、グローバルな観点からすると質問内容がユニークだったり、完璧主義だったりするので、日本人がいいなということらしいです。

我々が何を目的としてサポートをしているかというと、先ずはSLAを順守するということです。先程、顧客満足度の話もありましたけど、今のところまだ顧客満足度も使っているし、あとMTTR使っています。最近だとNPSを測ることもしています。あと、直接的な評価には含めてないんですけど、エスカレーションレートとか、リニューアルレートを使っています。あとは、たまに外部組織からの評価を受けていますので、あとでご紹介します。

チームにおける役割分担

サポート内部での役割分担としては、昔からフロント／バックラインで別れていて、2015年か16年ぐらいからTAMを入れて、デディケートなサポートをしています。この人たちはたまにお客様訪問とかするので、そういうときにプロアクティブなサポートもします。あと、お客様のご要望によってはオンサイトでの業務もやっています。また、今年に入ってからは、カスタマーサクセスマネージャー。これも前の方の講演で出てきたので説明は要らないと思うんですけど、お客様と我々エンジニアの間に入ってコミュニケーションの改善をしてくれる人を雇っています。

あとはテクニカルディビジョン分けというのをして、昔はシングルのキューに全エンジニアがバーッと案件を取っていくというかたちにしていたんですけど、今はテクノロジーの領域ごとに分類分けをして、そこに特定のエンジニアを配置して、それをとるようにするとしています。具体的に言うと、MapRで独自に作っているコアのところと、OSSからはSQL、MapReduce動かすYARNなどの基盤、それとSparkの区分があります。残念ながら日本と韓国に関しては一人しかフロントがいないので、基本的にその人が全部とっているという状況です。
エデュケーションです。新しく人が入ってきたときのエデュケーションは、MapRの公開しているトレーニングがあるのでそれをやってもらうというのと、あと内部用のドキュメントがあって、それを見てもらうというのやっています。最近になってもう少し進捗管理とか色々できるLearnCoreというツールを導入したりしています。

今後の課題と展望

直近の成功体験としてはこんな感じで、SLA順守率は89%くらい、顧客満足度は93%くらいです。MTTRはだいたい7.5日で、あとNPSです。NPSはnpsbenchmarks.comという各企業のNPSを公表するサイトがあって自慢してきてと言われたので一応出してみました。あと、外部評価で、テックバリデートのサーベイとか、スティービーアワードという外部からの表彰ももらっています。以上が一応成功体験でした。一方の失敗について、失敗談というほどいろいろできてないので、今後の課題という感じです。まずは、セルフサービス、キャパビリティです。これはうちのサポートのポータルからナレッジの記事というのを検索して、お客さんとか、ユーザーさんが自分で解決できるような仕組みを今整えました。ナレッジの記事を書くのは我々エンジニアなので、これを今後どんどん書いていくというのが大事という状況です。

次は、プロアクティブサポートです。今はTAMがお客様のところ行ったりしているときにやっているんですけど、通常のサポート業務としてはまだ全然できてなくて、今はやっとお客様のクラスターの環境にパッケージを入れて、それがクラスターの情報をとってきて弊社側でそれを解析して、問題の発見とかをやっていこうというのがやっと始まった状況です。

今まではグローバルでの話なんですけど、日本チームの課題として日本チームは直販をしてなくて、パートナーさん経由でものを売っているので、パートナーさんのエンジニアさんにスキルアップしていただくというのが非常に大事な課題です。現時点では特にちゃんとした教育ポリシーが定まっていないのでパートナーさんから、ちょっと教えてっていうのをチケットにして、それをどんどん我々が答えているという状況です。将来的にはMapRの資格を義務化するなどして、どんどんスキルアップしてもらいたいというのが課題です。 テクニカルドキュメントは英語のものも少ないんですけど、日本語のドキュメントはさらにないんで、さっき言ったナレッジだったり、ブログだったりを有志が書いている最中です。

あと、日本チームは本当にまだ小さいので、チームワークよく動かないと、こういう大規模クラスター用のソフトウェアなんてなかなか売れないし、継続してちゃんと契約更新してもらうのも結構難しいので、チームとして動くことが非常に求められます。まだ人数はすごい少ないんで、顔を突き合わせて、課題が出てきたときに話し合うといったスタイルがまだ有効です。日本チームもこれから大きくなってほしいんですけど、大きくなったときに、前の方たちが言われていたような問題にどうやって対応していこうかなという話があります。

時間がそろそろないんで飛ばしますけど、あなたはじゃあなんでMapRにいるんですかというところで言うと、さっき言ったみたいに、テクノロジーとしては面白いもの、ユニークなものを扱っていると思っています。あと、社長が出戻りしたというところもあって、アップルみたいにすごく劇的な出戻り劇があったわけじゃないんですけど、そういうのもシリコンバレーっぽくて面白い会社かなと思います。MapRというのは、POSIXファイルシステムにもなるんで、結構いろんな会社とコラボが発生します。最近ではNVIDIAのツールをこっちで動かすみたいな話もあったんですけど、こういうこともあるので面白い会社じゃないかなと思います。