0人から6人のグローバルサポートチーム、そしてArmへ (髙橋 達 トレジャーデータ株式会社)

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

トレジャーデータのサポートエンジニアリングマネージャーをしている高橋と言います。

僕がトレジャーデータのサポートエンジニアとして入社して、5年ぐらい経ちました。今日の内容は、まずトレジャーデータはArmという会社になったということをお話しした後、トレジャーデータのサポートチームが1人で始まり、どういうことをして、どんな苦労があったかという話をお話していきます。

体系的にかっこよくしゃべれたらよかったんですけど、そんな体系的に考えてやってこなかったので、あまり体系的にまとまりませんでした。エモい感じの話になってしまうかもしれないんですが、ご清聴いただければうれしいなと思います。

改めての自己紹介になってしまうんですが、高橋です。Twitter、Githubとかブログもやっています。もともと僕のバックグラウンドとしては、高専を出て、NAISTという大学院を出ました。最初はSIerの会社に2013年に入って、ほぼそのあとすぐトレジャーデータのサポートエンジニアとして働いています。キャリアのほとんどがずっとテクニカルサポートエンジニアというロールでやってきています。

2018年8月、めでたくArmのデータビジネスというグループにトレジャーデータが入りまして、引き続きサポートエンジニアリングマネージャーをやっています。今日のトピックとしては、僕が2013年10月にトレジャーデータの初サポートエンジニアとして入社して、いろんなことがあったよという話をします。

8年目を迎えるトレジャーデータ

まずトレジャーデータについて簡単にご説明させていただきますと、2011年に創業しまして、最初はFluentdとか出しつつ、Big Data as a Serviceの会社として始まっていきました。クラウドでデータ分析簡単にできるよといっていて、Big Data as a Serviceと言うとあまりかっこよくないので、もうちょっとかっこいい感じの、クラウドアナリティクスプラットフォームとしていました。

そのあとビジネスが発展し、デジタルマーケターにフォーカスしたカスタマーデータプラットフォームというかたちで、よりビジネスを発展させていきました。それが2017年頃です。

トレジャーデータのCDPを使うことによって、お客様が、自分たちの顧客のWebサイトの回遊だったり、IoTだったり、そういったデータを使ってカスタマージャーニーを分析し、より良いマーケティング施策をすることができるようなプラットフォームになってきています。



そして、2018年に買収があり、Arm Pelion IoT Platformということで、カスタマーデータプラットフォームと並行して、IoT向けのプラットフォームを今後Armとして作っていきましょうというのをやっています。

じゃあ、このArm Pelion IoT Platformは何なんだというと、Armという会社はチップの設計図を売って商売をするような会社なんですけども、チップの設計図だけじゃなく、デバイスから取れるデータとか、デバイスをネットにちゃんと繋げてIoT施策をしようというビジネスを始めていて、MbedというOSだったり、Mbedデバイス向けのOSと、それのマネジメントの仕組みをクラウドで提供したりしています。
あとはトレジャーデータの前にStreamという会社を買収していて、そこはもっとデバイスが簡単にネットワークにつながるような仕組み、Connectivetyというサービスを提供しています。

デバイスもあって、ネットにもつながったけど、じゃあそれをどうするのっていうので、データマネジメントをトレジャーデータが担い、この3つを一気通貫でArm Pelion IoT Platformというプラットフォームを提供して、いろんなことができるようにしましょうという感じになっています。

ひとりめのサポートエンジニアとして入社

そして、本題です。
2013年の10月、正確に言うと僕は正式には入社してないんですけど、最初に入社した会社から週4の常駐で来ていました。初のサポートエンジニアです。このときトレジャーデータは、セールスとかエンジニアとか、グローバルで全部ひっくるめて30人以下ぐらいでした。

僕が入る前はCTOがサポートを兼任して、チャットをするとCTOが返信するみたいな、そんなスタートアップあるあるな感じの組織でした。当時、サポートエンジニアは1人しかいなかったんですけど、雰囲気で、サポートのメールはいつでも受けつけていました。返すのはいつかわからないですけど、24時間365日で提供していて。ファーストレスポンスのSLAなんかも当時はなかったです。スマホアプリとかがあるサービスデスクを使っていると、どこでも通勤中から、風呂の中でもサポートできていいよねというのをやっているような感じです。

この頃は僕も2013年新卒だったので、そもそもよくわからんというのが正直なところでした。サービスについてもわからないし、エンジニアとしてもそんなに優秀ではなかったので、聞く学ぶを繰り返していました。また、セールスエンジニアなんかもこの頃は人出が足りないので、サポートと言いつつ、セールスエンジニアもするみたいなのも、こういう時期はよくある話かなと思っています。

顧客訪問も手伝ったりして、何でも屋さん感がありました。この頃、小さい組織のときは、目の前のサポートのチケットだったり、タスクを捌くのに必死で、組織改善については特に何も考えてないような、目の前を捌くので必死でした。

トレジャーデータのお客様ですが、この頃はテック系のお客様、Webとかソーシャルゲームとかのお客様が結構多く、緩く返しても緩く返してくれるみたいな感じでした。
この頃のサポートチーム、それに関連する組織としては、CTOがいて、TSE、いわゆるテクニカルサポートエンジニア、あと、2014年の1月、僕が入って数カ月後ぐらいでUSに1人ディレクターのエンジニアがいて、グローバルでもソフトウェアエンジニアが10人ぐらいしかいないような時期でした。USのセールスエンジニアも1人ぐらいしかいない感じで、これでなんとか回していました。

お客様を待たせてはいけない

今日ってスタートアップ系の人って結構いらっしゃいますか？
スタートアップだとそんな感じのサポートをしている人、そんな感じの組織構成なんじゃないかなと思っています。

この頃の、1人時代の学びとしては、皆さんには釈迦に説法かもしれませんが、とりあえず何もわからなくても何も進捗がなくても、お客様を無意味に待たせるサポートは一番良くなくて。お客様がサポートに期待するのは、答えというよりは納得感、これがすごく大事だと思っています。
ファーストレスポンスはとりあえず速くとか、ミッションクリティカルの度合いによって、ヒアリングによって定期的にレスポンスするとか、そういう、あまり実がなくても納得感が大事というのが結構あります。

困っているのはお客様ですから、問題解決のためにあらゆる手段を使います。そのために何でもするっていうのがこの頃は大事でした。例えばよくあるのが、自分でわからなくて困って、止まってしまうということ。こういうのが一番よくなくて、他のエンジニアが忙しそうだから迷惑とか、そういうのは関係ないことです。レスポンスが悪い人にひたすらpingするとか、速く回答くれとかやるのが大事です。

CTOから「サポートエンジニアが上司みたいだ」という感じのことを言われるぐらい、お客様にきちんとレスポンスするためにはCTOに対しても指示を出すというのが、1人でサポートエンジニアとして働いているときは大事かなと思っています。

お客様が必要としているのは回答ではないです。ビジネスのゴールがあって、そのために我々のサービスを使っていたらトラブって困っているのです。当初のゴールまで行くこと、それが問題を解決し、サポートがすべきこととなります。それできないですといってその場で終わらせるのではなくて、じゃあゴールを目指すには、最短だとこれはできないんだけど、迂回してこうすればできるんじゃないかという、ビジネス的な部分のヒアリングをセールスとかカスタマーサクセスチーム含めて巻き込んで、全体でサポートする事が大事というのが、1人でやっていた頃の学びになっています。

社外ベンダーのサポートをする難しさ

そして、2015年1月、1年後に日本は2人体制になりました。あとUSにもプロダクトマネージャーが加わり、なかなかいい感じになってきているという感じでした。この頃もまだ僕週4で常駐しているくらいで、この2人目の人も週4で常駐みたいな感じで、オフィシャルのサポートじゃないですけど、やっていました。

この頃に感じていた難しさとして、トレジャーデータというサービスは、BIの機能を自分たちで開発してなくて、でもお客様はデータを可視化したいという要望があるんですけど、そのためにいくつかのBIをOEMしているという時期がありました。今もしています。そのとき特に、最初にOEMしていたメトリックインサイトという機能、インスタンスを、トレジャーデータとしてホスティングしてお客様に提供するということをやっていたんですけど、それのサポートも当然サポートでやっていたと。

今日、自社サービスのサポートじゃなくて、どこかにベンダーがいてそれのサポートをしているみたいな人たちってどのぐらいいますか？これもそこそこですね。まさにそういうことをこの時にしていて、これもトレジャーデータがベンダーとしてサポートするのではなくて、間に入ってサポートして、何かお客様からその製品について質問があったら、このベンダー、例えばメトリックインサイトとか、そういったベンダーに対して問い合わせをして回答するっていうことも並行してやってました。これで結構つらいのは、自分たちの開発プロダクトじゃなく、そもそも全然中身がわからないので、エンジニアはとりあえず頼りにならないということでした。それに、オペレーションの自動化も後手になりがちです。

また、これは皆さんがOEMするようなことがあれば気をつけてほしいんですが、OEMするサービスはマルチテナントであるべきだと思っています。じゃないと結構つらくて、お客様ごとにインスタンスを立てていると、何かアップデートするときに全てのお客様にちゃんとコミュニケーションして、このパッチを何時にあてますみたいなのをやらなきゃいけなくなり、これは果たしてSaaSなんだろうかみたいなことになります。

あと、ベンダーコントロールという言葉自体あまり好きではないんですが、お客様から来た問い合わせ、ベンダー側のプロダクトに関わる、例えばバグの報告とかリリースのときの温度感の共有は難しかったです。

さらに、誰が主体になるかというのが特に難しくて、トレジャーデータでホスティングしてるんだからトレジャーデータやれよっていう話なんですけど、普段のサポートと同じ感覚でいるとそこら辺に行けなかったりします。このときは人数が少なかったので、サポートがそういうのを主体性を持ってやるというのがすごく大事だなというのを感じていました。ですので皆さんも、OEMのサポートするようなときがあれば、マルチテナントかどうかというのはひとつ大事なポイントになります。また、片手間でサポートはできないので、気合を入れてする必要がありますし、あとは温度感共有のためのビデオミーティングとかも必要です。

お客様の間に人が入るとサポートって難しくなると思っていて、そういうときに温度感の共有を気軽にベンダーとできるような関係性を持っていると良いです。間に挟まると、お客様の顔ってどうしても見えにくいので、ちゃんと顧客のバックグラウンドとか、どういうふうな戦略があるのか、ビジネスがどう発展しようとしているのかというのを共有するのは大事だなというのを感じていました。

USとの連携。グローバルでの対応がはじまる

この頃はサポート2人のときなんですけど、そういうことを感じながら普段のサポートもしていました。そして1年後は、なんとサポートがまだ2人です。ただ、このときは僕がちゃんとマネージャーとして週5で社員として働いていて、USになんとテクニカルサポートエンジニアが入りました。しかし2人、みたいな感じです。そして、営業肌を持っているすごいエンジニアのCTOが今までレポートラインだったのが、このときは組織が結構大きくなって、セールスのほうにも力入れたいということで、僕のレポートラインがUSのVP of Engineerに変わったりしました。< br>

トレジャーデータのサポートは結構テック寄りで、技術的なこととかリリースとかも常にキャッチアップしながらエンジニアとともに働く必要があるので、VPのエンジニアへのレポートラインが変わって、よりシンクしやすいようなかたちというのに体制が変わりました。USにメンバーが入って、少人数のグローバルサポートチームというふうになっています。夜、英語対応してくれる人がいるのって、めっちゃうれしいです。ただ、夜に日本人働きすぎ問題というのがあって、みんな5時ぐらいから問い合わせがめっちゃ来て、まだ来るのかみたいなところがあるので、皆さん早く寝ましょうというのがよく思っていたことです。たまにお願いすると代わりに日本語で返してくれたりするので、USに日本語できるエンジニアがいるとすごくうれしいなという感じです。

少人数のサポートとか、リモートで働く人がいるときって、1on1が大事だなと感じました。人数が少なくて一番何がつらいかって、せっかく入った人が辞めるのが一番つらくて、こんだけ頑張って教えて、おお、やったと思ったら、辞めちゃったとなるのがすごいつらいです。特にUSは辞めるサイクルが早いので、なるべく楽しく働いてもらえるようなのを考えるためにも1on1で定期的に話して顔が見えるようにして、孤独感がないようにしたりとかしていました。僕はアメリカの生活についてそんなに知らないので、そういうところを、VP of Engineerが定期的に1on1をUSのメンバーにしてくれたりしていました。そういうのをチームとしてちゃんとやっていくのが大事だなと思います。

そして2017年は、なんと3人でした。日本にもう1人サポートエンジニアが入って、USはそのまま働いてくれていて、僕がマネージャーみたいな感じです。PMがなくなったのは、これは正直に貼っているのであれなんですけど、たまたま辞めちゃったというのがあります。PMみたいな人がここにいて、VP of Productみたいな人がいて、同じような体制で、人数がちょっと増えたという感じです。

人数が増えてきたときに気をつけること

もう1人増えると、すごいいいです。僕マネージャーなんだけど、基本的に毎日のプレイングマネージャーみたいな感じで、常にチケットも捌きながらUSのメンバーのケアもするみたいな感じだったので、もう1人入るとすごいうれしいです。サービスの成長とともにチケットも増えていっているんで、そもそも1人で捌けなくなってきているので、そういう意味で2人になるというのは大事でした。

人数が増えたとき、Day to Dayのサポートって飽きるときってあるじゃないですか。なんか起きたらめっちゃチケット来てるみたいな。そういうのやっぱりあるので、そういうときに気分転換にできるようなプラスアルファのミッションというのを常に考えるのは、チームに対しても何かタスクを考えるというのがすごい大事だなと思っています。例えば、社内のKPIダッシュボードの作成を補完するとか、調査方法の改善のための仕組みづくりをチームでするとか、そういう感じで、通常のDay to Dayサポートのほかにもいろんなそういうプラスアルファのミッションを普段のサポートとは違うようなことができる仕組みをこの頃は考えてやっていました。ただ、そのプラスアルファのタスクがサポートチームとして見当違いな方向に行くのが一番よくないと思っています。ちゃんとサポートチームとしてこういうゴールがあって、それに向かってやっていくためのタスクをいろいろ考えるのが大事だなと思っています。

この頃にカスタマーサクセスチームがセールス側でも立ち上がって、普段のお客様とのコミュニケーションがよりカスタマーサクセスとか、ソリューションアーキテクトチームのほうに移っていきました。そういう意味でそことの連携を考えるというのが課題としてあります。いい解決方法はとりあえずないんですけど、普段からよくしゃべるっていうのが一番大事かなというところになっています。

そして、2018年1月、今年の頭は5人になっていました。日本に2人とUSに1人とウガンダに1人という構成です。EUタイムゾーンが結構つらい気持ちになるので、そのサポートのために1人雇ったらたまたまウガンダでした。ちょっとチームっぽくなりました。この頃は、さっきのクラウドアナリティクスプラットフォーム、データマネジメントプラットフォームから、カスタマーデータプラットフォームというほうに移り変わることによって、よりエンタープライズなお客様というのがどんどんお客様として増えていったというのがあります。それに伴って、お客様の層が、エンジニアだけじゃなくてデジタルマーケターみたいなお客様も増えていて、顧客のペルソナが変わっていったというのが、去年の終わりから今年の頭ぐらいにかけて起こったことです。

特にサポートが難しいのは、マーケティング専門家じゃないとはいえ、お客様がマーケティングの言葉を使ってくることです。きちんとそういうのまで知りつつテクニカルなところまで支援するというのが難しさであり、そういうところを知って製品も知ってなきゃいけないことが大変です。お客様のことも知ってなきゃいけないという、なかなかチャレンジングなことが起きました。お客様もよりエンタープライズになってきて、いろんな無茶な要求が来るとき、最初はなんでもサポートでやるような体制でした。

とはいえやりすぎて、それが当たり前になると良くないので、ちゃんとNOと言えること、エンタープライズのお客様のときに良いサポートをするためにもきちんと責任の分界点を明確に決めることが大事というのがこの頃の課題と気づきです。 あと、サポートエンジニアの採用って本当に難しいというのは常々思っていることです。1人採用するのに1年ぐらいかけて、なかなか応募来ないというのがありました。今もあまり来ないので、興味ある方は是非という感じなんです。

買収前後、マネージャーとして重要なミッションとは

そして、2018年8月に買収がありました。この頃は、採用面談がやりづらい感じでした。あなたが入る頃は、実はトレジャーデータではないですとはなかなか言えないので、面接がすごくしづらかったです。

買収されたからといって、今すぐ何かが変わったかというと、そんなに変わってなくて、トレジャーデータのビジネス自体はこれからも継続してやっていくし、そのほかにプラスアルファでPelionというIoTのプラットフォームをやる感じなので、何か変わったかというと、変わってないです。福利厚生がよくなったり、給料とか諸々変わったというのはあります。あと、ストックオプションとか税金については、エンジニアは疎くなりがちなんですが、ちゃんと勉強したほうがいいなって心から思いました。 このときのマネージャーの重要なミッションというのは、皆さんも買収されるようなことがあれば、ちゃんとみんなに継続して働いてもらうというのが大事なので、普段から一人ひとりネゴっておくのが大事かなと思いました。

そして今月、たった数ヶ月でなぜかメンバーが9人に増えて、ちゃんとサポートチームになってきたという感じです。日本が今3人で、USが2人で、USにテクニカルアカウントマネージャーというのがなぜかサポートの下に入ったり、あとカスタマーオペレーションズマネージャーというのがいます。お客様のリソース変更とか、そういったセールスオペレーションみたいなのをするのがサポートチームに入ったりして、サポートは一体？みたいなところはあるんですが、今までいろんなことしてきたらいろんなことが起こったという感じです。

組織をグロースしていくためのポイント

Armという会社になって、もっと成長させていくために、サポートチームで組織の改正がありました。具体的には、今までレポートラインがVP of Engineerだったんですけど、エンジニアの下にサポートがあるという体制はよくないとなりました。やっぱりサポートってプロダクトとしてすごく重要だよねというのがあって、組織体制として、もう1回CTOにレポートラインが戻りました。なので、エンジニア、サポート、プロダクトという、この3グループの体制というふうに今はなっています。こういう発想はかたちから入るというのが大事です。

あと最近常々思うのは、全体としては今9人いるんですけど、それぞれの国としてはそんなに人数いないので、どうしても普段のDay to Dayサポートをまだ僕がやっていたりするときがあるので、なるべくそこから脱却し、サポートチームをどうマネジメントするというか、もっと飛躍させるにはどうすればいいかなと考えています。人数が自分たちのチームで4人とか5人とかぐらいになったころには、そういうことをちゃんとマネージャーの人はやらないといけないんじゃないかなと思っていて、サポートチームの今後数年のビジョンとか、チームとしてどういう課題を解決しなきゃいけないかとか、そういうのをどんどんやっていきたいです。

特にこういう買収によって、さらにチームを成長させるために投資していくので、どんどんほかのチームもすごく増えていくことになります。今、ソフトウェアエンジニアがグローバルで60人ぐらいになっていて、今後数年で倍々にしていくという感じです。今までそれぞれが持っていた知識が新しい人に伝わらないので、そういうプロセスをきちんと整備していくような時期になりますが、Day to Dayのサポートをしながらではなかなかそういうことできないので、飛躍しようと思ったら、誰かはきちんと専任でそういうのをする人がいないとダメかなと思っています。

あと、サポートチームに、テクニカルアカウントマネージャーとか、カスタマーオペレーションズマネージャーとかいろいろ増えて、コンテクストスイッチの切り替えをしながら成長させていくのが重要だなと思っています。

3年後、30人のサポートチームにするために

3年後の目標としては、サポートチームが今9人なので、30人ぐらいにしようという心持ちでいます。10人以上のテクニカルサポートエンジニアチームにするための課題として、まずひとつは、サポートの品質を属人化させないということがあると思います。これは、1人で捌いている頃って、1人のその人の能力が高くなっていて、大体その人に返すと一発で解決して、すごくクオリティ高いみたいな感じなんですけど、新しい人が来るとクオリティ下がるというのが、これが一番よくないです。レビュー体制を作ったり、ナレッジ共有、入社時のランプアップのためのドキュメントの更新とか、そういうのができる体制を作っていかなきゃいけないというのがまず大きい組織を目指すために必要かなと思っています。

あと、さっき言ったプラスアルファのチャレンジって、一人ひとりの、30人分のプラスアルファのタスクを作るのはシビアなものがあるので、チームで課題に取り組めるようなものになると思います。また、US、日本でそれぞれで大きくなってくると、それぞれでマネジメントが入って、リージョン間での分断が起きてしまうので、そういうふうにしない、分断されないような取り組みを考えなきゃいけない。そのためにも中長期のビジョンを明確にして、サポートをグローバルでどうするかというのを常に考えながらやるべきという感じです。

あと、僕たちサポートがよりお金をもらえるようにするためには、有償のサポートみたいなものを、エンタープライズのBtoBとして考えなきゃいけないかなとか、そういうときにプロフェッショナルサービス、コンサルティングみたいなものとの差別化を考えたりとかする必要があります。ビジネスにどういうふうに寄与しているかというKPIもそろそろ考えなきゃいけないのかなというのを最近思っています。このあとの発表でそれをどう解決したかという話を聞けるんじゃないかなと僕は勝手に期待しています。

「会社全体がサポートを大事だと思ってくれること」が大切

最後に、エモい感じで終わるのはあまり好きじゃないんですが、いいサポートチームを維持して拡大させる上で大事だと思っていることで、最近常々思うのは、会社全体としてサポートが大事だと言ってくれる、そういう感謝みたいなのは大事なのかなと思います。例えば、この間Armのマネージメントチームのミーティングがあって、そのときに、CTOがこのサポートがトレジャーデータにとって一番キーパーソンだみたいなこともちゃんと紹介してくれました。

マネジメントチームとかも含めて、そういったことを常日頃から言ってくれるというのがひとつのモチベーションになりますし、そういうふうな期待を裏切らないようにするためにも、常日頃のサポートがおろそかにならないようにするとかは、大事だなというのを最近思っていています。 従業員10人、100人になってもそういう組織であり続けるのが大事だなという感じで、これで終わりです。会社としてそういうサポート大事だよと言ってくれるいい会社なので、是非皆さん、入りたい方は僕までお声がけください。ありがとうございます。何かご質問ある方いますか？

質問者1：サポートの品質を属人化させないためにやっていること、何か具体的にあれば教えてください。

—これは、僕が見る、しか今のところなくて。人数少ないので、なかなかテッキーな内容なので見るしかなくて。誰かがレビューするというのが一番大事だと思っていて、もうちょっと人数が増えたら、例えばある日1日はこの人がレビュー担当で、ほかの人もちゃんとレビューする、という体制を作ろうと今のところ考えていますが、今はいないので、僕がたまに見て、変だなと思ったら、これ間違っているよ、とやっています。チケット数多くて最近は見切れなくてつらいですね。

質問者2：サポートの教育について、どういうふうに取り組んでいらっしゃるか教えてください。

—これも体系立ったものがあればいいんですけど、とりあえずよくある、メンターをつけますと。で、最初の2週間で、大体大きいところのプロダクトとか、VPとかからそれぞれのチームについて説明があって、今後のビジョンとか、そういうのを一通り説明受けて、最初の1カ月以内とかでUSに行って、いろいろ話したりとか。あと、僕がステップバイステップで教えたり、というのをまず最初やります。ただ、それで絶対覚えられないので、たまに直接来て、日本に来るなりUSに来るなりして、直接行ってそこで、数カ月後とかに来たときにもう1回レビューすると。そうすると、普段チケット返しているような内容が、全体のサービスの中でどういう立ち位置で、そういう事象が起きているかというのを結構理解できるので、いきなり例えばHadoopについて理解しろと言ってもポカンとなるので、そういうふうな時間をおいてのトレーニングと、最初は会社全体としてどうなっているか、とかを共有するのは常日頃やっています。

質問者3：マネージャーをされているということなので、部下というか下にいる人たち、サポートエンジニアたちの目標設定とかKPIの設定もされているんじゃないかと思うんですけど、どういう目標設定をされて、各サポートエンジニアのモチベーションにつなげようとされているのか、お聞かせいただければなと。

—今のところKPIとしては、クオーターごとに振り返りをするようにしていて、KPIはチームでは明確な数字としてあります。例えば週に7日以内のチケット解決率を何％にするとか、エンジニアリングのエスカレーションレートを何％以下にするとか、そういうKPIがチームとしてあります。ほかに、個人としてこういうことを達成しますよ、というタスクを作ってもらうのを基本的にはやっています。なぜ個人に対してKPIを出してないかというと、お客様の増え方によって、リージョンによって偏りが出たりするので、フェアではないかなというか、お客様とかチケットの数が安定してあればそれを元にしてできるんですけど、チケットの数もお客様の数も伸びているのにそれをやると、ちょっと不公平感が出たりするので、あまりそういうのをしたくなくて。今のところは、チームとしてこういう目標を達成しましょうというKPIと、個人としてこういうことやりたいです、という個人目標をつけている、という感じですね。

質問者4：マネージャーの方からメンバーへのチケットのアサインはどういうロジックでやっているんですか？

—人数が少ないので、とれる人がとる、です。USの時間帯だと、2人しかいないのにロジックもへったくれもない、という感じですね。
質問者4：わかりました、ありがとうございます。

トレジャーデータの採用情報:

現在、弊社WEBサイトにて採用情報を公開中です。是非ご覧下さい！