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

---

こんばんは、Red Hatの木村 貴由と申します。今日は、日本人1人体制からのということで、1人体制から始まったのはトレジャーデータさんも一緒ですね。Red Hatはそもそもグローバルチームは既に展開していて、私はミドルウェアのサポートとして日本で初めて入り、買収製品の日本のサポートの1人目という位置づけでスタートしています。よろしくお願いいたします。

オープンソースに基づくエコシステムを作る

Red Hatという会社は、恐らく皆さんご存知かと思うんですけれども、オープンソースソフトウェアの会社です。一番主力の製品が、Red Hat Enterprise LinuxというLinuxのディストリビューションが主力の製品となってます。オープンソースの会社って何やってるんだというと、OSSのデベロッパーさんを雇用したり、各種テクノロジーを買収して、そのテクノロジーを大体全部オープンソース化するというようなことをやってたりします。日本だとRubyの開発者さんがどこどこの会社に雇用されましたみたいなのがよくニュースとかになったりするんですけど、Red Hatという会社はそれをグローバルで十何年前からずっと、粛々とやっている会社です。

Red Hatのミッションは、基本的にお客様と開発者とパートナーをオープンソースというかたちでビジネスを回す、お金を回すということです。重要なのはビジネスとして回すというところで、OSSはすごい便利だし、OSSを頑張っている開発者とかいらっしゃると思うんですけれども、その人たちをちゃんと雇用して。エンタープライズ領域で使われるすごい有用なOSSの開発をしているぞという人って、年収1,000万ぐらいもらってしかるべきだと思うじゃないですか。そういう人たちをちゃんと雇用してお給料を払い、その分、お客さんからいろんな機能追加のリクエストも聞いて、その対価としてお金をもらって、それを開発者に還元するというエコシステムを作っていくのがRed Hatのミッションになっています。

私なんですけども、2007年の3月に入ったので、今11年半ぐらいです。もうそろそろ干支が回ってカビでも生えるんじゃないかなと思っています。

最初はJBossというミドルウェア、Javaミドルウェアの担当として入りました。JBossというのはもともとJBoss Inc.っていう会社がやっていたんですけども、それがオラクルに買収されそうになったかなというちょっとあとにRed Hatが買収しまして、そのとき日本でJBossやってた関係でRed Hatに雇用されました。それより前の話をすると、JavaアプリケーションフレームワークのApache Strutsというのがあったんですけども、それを日本に流行らせたグループ、悪の組織みたいですけど、その一員だったりしていました。

Red Hatが提供しているサポート

Red Hatのサポート、Red HatはLinux皆さん結構ご存知かなと思うんですけど、今は製品がどこ見たらいいのみたいな画になっちゃうぐらいになっています。僕が入社した当時だと、左下にあるEnterprise Linuxと、あとJBossアプリケーションサーバーと、コンサルティングサービスっていうのはもちろん、トレーニングサービスみたいなのはあって、多分それぐらいしかなかった気がします。12年前くらいは、5個くらいしかありませんでした。僕が入社した12年前ぐらいだと、日本のオフィスも40人ぐらいしかいなかったので、最初入ったとき、日本のサーバーサイドアプリケーションとかやっている人たちは、大体Red HatのLinuxサーバーでした。それが40人ぐらいで回っていたというのを知ってちょっとびっくりしました。

サポートはカスタマーポータルというお手製で、特にZendeskとかの外部サービスとかを使っていません。お手製のサポートポータルがあって、昔から運用しています。ここでサブスクリプション契約の管理であるとか、ソフトウェアダウンロードをできたり、もちろんサポートケースを作成したりといったことができるようになっています。



提供しているサポートですが、基本はさっきの、Webサイトからのチケットインターフェイスによるやりとりがメインです。どうしてもログとかが多いので、電話とかしても、ログ読み上げたりとかちょっと現実的ではないです。電話とかチャットとか、このチケットのステータスどうなっているんだみたいな話だったらいいんですけど、そんなにはないです。後は場合によって、ブラウザから何かやったときの挙動がおかしいみたいなのを確認しなきゃいけなかったりするので、スクリーンシェアの内部セッションとかもあります。サポートレベルとしては基本的に2つあります。プレミアムの24時間対応と、営業時間内対応のスタンダードレベルが用意されています。

日本では1人体制からスタート

2007年の3月ということで、入社した直後、2週間後にUSに飛ばされました。そこで、ニューハイヤーオリエンテーションと、そこから1週間、サポートケースの捌き方みたいなものをみっちり教えてこまれました。このとき、当時のグローバルで、JBossのサポートの全人員が今ここに移っています。もちろんこのときも24時間サポートはやっているはずなので、世界の1カ所に集まってミーティングしていることがまたすごいんですけども、普通に夜ご飯食べながらサポートしている人とかが横にいたりして、面白いなと思ってました。

その時の上司はフランス人の方で、今はCloudBeesっていうJenkinsの会社の共同創設者になっています。もちろん日本人は僕1人という状態でスタートです。

初期は、チームがすごい小さいというか、僕は日本で1人チームなんで、同僚がUSとインドとヨーロッパにしかいないので、日本のオフィスに行ってもあまり意味がないというところがあり、会社にもあまり行きませんでした。なので、コミュニケーションコストはすごく低いです。この問題に対して聞く相手が誰かというのが、選択肢としてほとんどないので、そういうところが楽ではあります。人数がそんなにいないので、当然やらなきゃいけない範囲も大きくはなるんですけど、その分個人の裁量も大きくなってきます。あれもこれも対応、勝手にあなたの判断でやっていいよみたいになります。この頃はまだ人数が少なく、トレーニングとかも、トレーニングされる対象である僕を旅行させたほうが安いので、トレーニングなんかで海外に行く機会もかなり多くて、シンガポールやUS、チェコ、スペイン、ポルトガル、ドイツあたりとか、いろんなところに出張してトレーニングを受けてました。

ユニークな組織文化

この頃、まだJBoss Inc.のルールが結構生きていたんですけど、面白いなと思ったことがありました。JBoss Inc.では開発者が何十人もいたんですけど、エンジニアリング、サポートチームが15人ぐらいでとても小さいです。ただ、エンジニアリングは何十人もいました。このときのルールとして、エンジニアリングチームの時間の30％はカスタマーサポートにあてるべきだというルールがあって、会社全体でサポートケースに直接コメントするっていうような文化がありました。結構面白いんですけど、CTOみたいな人が普通にサポートケースにコメントをしているということがありました。すごい経営層の偉い人が、お前のトランザクションの扱い方は悪いみたいに書いてたりして面白いなと思いました。
初期の過程なんですけど、正直、若干騙されて引っこ抜かれた感じがありまして、僕は当時、英語読める、書けない、しゃべれないっていう日本人によくありがちなレベルで入りました。なので、入ったら、上司もフランス人なのでもちろん英語ですし、チームメンバーも全員英語ですし、日本のオフィスは行ってないしで、英語がかなり大変でした。
あとは、先程Salesforceさんとかの話もあったんですけど、プロセスの整備がまだ全然できていないので、いろんな質問やら問い合わせやら契約やらお客さんとの交渉とかが全部決まっていませんでした。誰もそんなことやろうと思ってなかったみたいな質問がくることが多くて、それを確認する作業が非常に多かったです。それももちろん全部、製品側の責任者とかが英語なので、全部英語のコミュニケーションになって結構大変でしたね。
これは入ったときに既存のチームメンバーから聞いた話なんですけど、Red Hatに買収される前の、JBoss Inc.だった時代のサポートってどうやっていたの？という部分です。Red Hatになってから、Red HatはもうLinuxのサポートで、サポートのインフラが若干整っていました。JBossのサポートってどうなっていたのというと、当時みんな高機能端末だったブラックベリーを支給されていて、それで晩ご飯食べながらサポートケースに回答していたという感じです。
私が入るまで、メンバーはアメリカの東海岸寄りで、そこからアジアを全部ぶっ飛ばして、インド、ヨーロッパっていうメンバー構成だったので、アメリカの人たちが昼から働いて、夜まで働く、みたいなシフトがその頃ありました。私が入社したと同時に、みんな、やったと言って、それをやめましたので、いきなり入社した瞬間から西海岸の重要顧客が全部僕の担当になるということでした。結構びっくりしますよね。新しい携帯電話が発表されましたっていって、わーっといって、Webサイトがつながらないと表示されるのがJBossのデフォルトのエラーメッセージ画面だみたいな感じです。

トレーニングコンテンツを整備し体系立てる

サポートが成長するにつれて、メンバーもどんどん増えていって、2007年の後半に、タロウさんが入って、上司がそのあと、アメリカ人のジムさんになって、そのあとタロウさんになりました。そして、1年に数人ずつ入ってくるような状態で、併せて、製品がどんどん増えていくようになりました。さっき出した製品図なんですけども、30近くあります。ミドルウェアの製品なんかが特に、1個だったのが8個とか9個とかに増えていっているので、製品とメンバーがどんどん増えていきます。そうするとトレーニングをしなきゃいけないんですけど、途中までは既存のメンバーが個々に、新しくメンバーが入るのでトレーニングマテリアルを作ってくださいと言われて、日々のサポートケースの対応のほかに時間を割いてトレーニングのマテリアルを作ったり、トレーニングを実際にしたりしてたんですが、これがばらばらに世界で、いろんなところで起きると、トレーニングコンテンツの共有がちゃんとされてなかったり、引き継ぎができないものだったりします。トレーニングのマテリアルって作る人によって癖が出やすいところでもあるので、ほかの人のを見て、これだったら自分で作り直そうといってまた作り直しちゃったりとかします。そうやってばらばらに作られたトレーニングコンテンツが、製品のバージョンアップとかにちゃんと追従していってなくて、古いままずっと野放しになっていたり、どこかに置き忘れられてリンクがたどれなかったりとかします。そういったトレーニングが個人リソース依存になってばらばらになるというような状況が散見されました。
結局どうしたかというと、サポートの中でトレーニングチームというのが、これは2年前ぐらいにできて、各製品のオフィシャルなトレーニングです。トレーニングといっても3つぐらいあって、製品のテクニカルトレーニングと、あとはサポートのプロセスのトレーニング、あとは顧客とのコミュニケーションとかの、コミュニケーションスキルのトレーニングだとかを、ちゃんと体系立ててコースにして、中央管理するようなかたちになってきました。

規模の拡大とともにプロセスを改善

製品が増える、メンバーも増える、当然お客様も増えています。お客様の数が増えると、いろんな性格のお客様の数も増えてきます。Javaのミドルウェアとかいったら、アドバンスドなスキルの高いお客様しか最初は来ないんですけど、デファクトといったようなかたちに近づいてくるにつれて、スキルが低い、使い方がよくわからないというレベルのお客様もどんどん採用して、問い合わせをしてくるようになります。それまで別の文化でやりとりをしていたお客様が、いきなり技術のところで問い合わせしてくるようになって、対応が気にくわないみたいな、結構不条理なエスカレーションもあったりします。そういう人たちの電話とか、そういったものを、テクニカルな問題解決ができる人がずっと対応しているみたいな状況が発生しました。これはすごいもったいないことで、その人たちは問題解決ができます、できるんですけど、苦情対応みたいな、よくわからないギャップが生まれます。これはあまり健全ではないので、結局エスカレーションマネージャーという、そこを専門にハンドリングするようにします。お客さんのエスカレーションの内容が適切か、契約に基づいているか、妥当性はあるか。あとは、ちゃんとコミュニケーションが長けている人たちなので、まず最初にお客様の話を聞くとか、そのあとでいろんな提案をするとか、そういったフレームワークみたいなものを、ちゃんとスキルトレーニングされている人たちがそういったものをハンドリングするという体制で導入されました。
規模が大きくなってくると、いろいろなプロセスとかワークフローが増えてきます。すごい大口顧客であったりとか、一部センシティブになってしまうお客様であるとか、そういったいろんな注意事項みたいなものが増えていきます。これもさっき言った、カスタマーポータルに一応システム上いろんな実装はされていて、あとは自由記入欄みたいなものもあるんですけど、この人のサポートはちょっと特別ですみたいな注意記入欄とかもあるんですけど、そういった、様々なシチュエーションに対応できるように、プロセスとかワークフローがどんどん改善されています。
日本でやっていると例えば、ニュージーランドとオーストラリアのお客様が、日本でケースを対応すると、2時間、3時間のギャップができてしまいます。それをすごい嫌がるお客様がいます、というものとかが、こういうところに特殊対応みたいなかたちで記述されていたりして、必ずニュージーランドかオーストラリアのサポートメンバーが、ケースをハンドリングしてくださいみたいなプロセスがあったりします。
あとはセキュリティ要件です。政府国防関連と書いてありますけど、例えばUSの国防関連の技術のところとかだと、USのレジデントしかアクセスできない情報みたいな、そういう特殊なレギュレーションが出てくるので、そういった機能も全部、カスタマーポータル上にセキュアサポートという形で実装されていて、僕らからワークキューを見ると、タイトルから何から全部暗号化されているサポートケースが見えて、そういうのが見えたりします。

サポートサービスの差別化要因はナレッジ

あとは、GDPR関連とかで、顧客のデータを正確にトラッキングする必要が出てきたので、ケースの内容であるとか、添付ファイルとか、誰がいつダウンロードしたとか、そういうのも社内システムでは、全部監査ログに残るようになってたりしています。一般的なものですけど、採用しているツールとしては、ナレッジセンターサービスが一番大きいところかなと思います。再利用性のありそうな問い合わせです。再利用性がパッと見て全くないのはどうでもいいんですけど、再利用性が少しでもありそうなお問い合わせは全てナレッジにするという仕組みがあります。これはユーザーさんに結構ヒアリングするんですけど、ほかのサポートを提供しているベンダーさんに比べて、質も量もかなりいいというフィードバックを受けていて、利用頻度がかなり高いと言われています。
弊社はオープンソースの製品を主に提供しているので、オープンソースなので皆さんソースは見れます。誰でも動かせますというのが大前提になるので、結局サポートサービスの差別化要因って何っていうと、ナレッジが勝負になります。ナレッジといっても、ここに文章として書いてあるナレッジだけではなくて、もちろん人としてのナレッジです。要は、サポートを使うにあたって、問い合わせてくれたら、JBossに超詳しい人と会話ができますよというところです。
質問にはいろんなパターンがあるので、定型になる以外のナレッジが必要になる面もかなり多いので、そういったところがサポートの質として勝負になってきます。この辺は、Salesforceさんとだだかぶりになります。お問い合わせ作成画面からいろいろ入力したら、動的にナレッジが表示されます。こんな感じで、これはお問い合わせ作成画面なんですけど、ディスクがフルになりかけたよっていったら、新しいディスクにデータをマイグレーションする方法とか、そういったものが表示されるようになっています。
問い合わせを受けてから解決するまでの速度は大事なんですけど、そもそも問い合わせをする前に問題を解決するというところで今力を入れています。これもその一環です。英語のナレッジが大量にあります。だけど日本語のナレッジというのは、人が対応していて、人気のナレッジは人がちゃんと翻訳したものが用意されていますが、全部できないので、結局Googleトランスレートをバックエンドとしたマシーントランスレーションエンジンが実装されています。言語選択のところから日本語を、ちゃんとした日本語記事がある場合が日本語、ちゃんとした日本語記事がない場合はGoogleトランスレートを表示するという仕組みになっています。

「お問い合わせ」前にアクションする

それから、これはサポートから生まれたプロダクトという意味でちょっと面白いかなと思ったんですけど、Red Hat Insightsという機能があります。インサイト、何が手に入るのっていうと、クライアントサイトで動くエージェントが1個手に入ります。これが、何をしてくれるかというと、そのシステムの情報をサラッと集めて、暗号化してサーバーに送信しています。それのオーバービューをカスタマーポータルから見ることができるようになっています。例えば、セキュリティ脆弱性であるとか、アクションが必要なやつであるとかです。個々の項目をクリックしていくと、面白いんですけど、Ansibleを使って、そのまま修正の適用を実行するような、実行できるような機能もあったりします。多言語対応、私たち日本人なので、お客様も日本語のリソースをいろいろ求めてきます。いくつかの製品はまだされてはいませんが、日本はかなり製品ドキュメントが日本語対応されてはいます。あとは、ナレッジの翻訳もしていますし、日本語のサポートをもうちょっとスケールして、応答速度とか改善するために中国とかインドとかに多少リソースの確保もしています。
近年サポートといっても、お問い合わせを受けたのをトリガーにしてやるのをリアクティブサポートとカテゴライズしてるんですけど、それを超えた顧客体験が必要ということで、プロアクティブサポートの部門もあります。この中に、特定顧客専門のテクニカルアカウントマネージャーであるとか、広く顧客にコンタクトして、問い合わせしてこなくても、何かありませんかと電話したりとか、営業と一緒にお客様を訪問したりということを所属はサポート組織内なんですけど、そういうことを行う人たちがいます。

ベストプレイストゥーワークな職場に

24時間対応ということで、Salesforceさんは北米に人を送れるだけのトラフィックがあったとのことなんですけど、弊社は一応過去に1回試みました。北米に日本のサポートセンターを置こうみたいなことを試みたんですけども、実際にパイロットやってみた結果、採用が非常に難しいというのが1個と、あとは、コストに見合わないというのと、時間外対応の件数が北米にサポートセンター置くほどではないみたいなところがあり、基本的にそっちはやらないことになりました。



基本的にはウィークエンドオンコールです。土日誰かが時間外対応の電話を持っているという、一般的なモデルにはなっています。会社としては、4/10（フォーテン）シフトというもののパイロットをやっています。これは週休3日、4日働き、1日10時間。9時、8時で働くというもので、水曜日に全員集まれるようにして、日曜日と土曜日で切り替える。USだとほかの会社さんもやられていたりするようです。
4/10ってGoogleで引くと、4/10は健康に悪いみたいな記事があったりすんですけど、ただ週休3日というのはすごいいいなと思っています。僕は子どもが3人いるんですけど、これだど平日2人空くので、子どもみんな預けて、平日2日自分の時間になったりするので、ちょっといいなと思ったりします。ただ、いろいろ問題がありまして、まず法律です。労働法系のものと相性が悪いというか、やはり社会的には週5日8時間で設計されているものが非常に多く、例えば保育園とか基本的に8時に預けて、6時過ぎに迎えに行くみたいなモデルで実装されているので、そういうのと相性が悪いです。あと、土日どっちか働かなきゃいけなくなっちゃうんで、そうなると、奥さんが1人で土日のどっちか、子ども3人見てなきゃいけないとかいったいろんな障害もあります。まだ日本には、法律関係の精査が終わってないので、導入できないみたいです。
Red Hatはベストプレイストゥーワークという働く場所として魅力的なところにしようというところにもすごく力を入れていて、日本のミドルウェアサポートは12年間いて退職者は今のところ0です。0と言いつつも、1人はコンサルティングに異動とか、エンジニアリングに異動とか、異動はしています。また、給与と福利厚生の充実で、給与は重要です。オーバーワーク、過剰なストレスを防止するマネジメントなんですけど、基本的に僕もオーバーワークしないポリシーなので、1日8時間以上働いたら死んでしまいますって言っています。あとは、企業として透明性を非常に大事にしています。

顧客体験の向上を目指して

最後に目指すところです。結局は顧客の体験です。体験の改善のためということで、ストレートなゴールとして、ケースクローズまでの期間を短縮しようということがあります。そのほかに、そもそもサポートケースを作成する前にいろんな問題を解決するという施策をいろいろ打っています。指標としては、CESとNPSを採用しています。CESは、以前はS-SAT、普通の顧客満足度調査で、満足しましたか、してませんかというのだったんですけど、今はCESに切り替わっています。あとは、カスタマーエフォートスコアです。これは、サポートを利用することが面倒でしたか、簡単でしたかという質問です。結局、面倒であるといろいろよくない傾向が起こるというのが世間一般的に解明されてきているようですので、そういった指標になっています。NPSは、Red Hatをほかの人におすすめできますか、できませんか、ってやつです。いろんなところで利用されているやつです。組織が大きくなってきて、今どうかと言われると、海外出張とかが、もうコスト的にあまり行けなくなりましたが、やっぱりメンバーが多いので、トレーニングとか気軽に人を飛ばしている場合じゃないという感じです。
また、ロールは人が多くなってきて細分化されてきたんですけど、横連携はどうするとなったとき、Salesforceさんと全く同じ課題なんですけど、ミーティングが増えるっていうかたちで出てきているので、悪い傾向だなと思います。あとは、人の多さと製品の増加に伴って、社内のマシーンとかも増強しなきゃいけないんですけど、そっちのほうの速度が追いついてないみたいなところもあり、これも今頑張って大きい検証環境を作ろうとしています。
さらに、難しいですが評価制度です。さっきのKCSとかでいうと、ナレッジの編集とか作成とかの数をカウントしてKPIとかにすることがあったんですけど、ひどいクソ記事がいっぱいできました。そういった、KPIちょっとでも間違うと、特にいろんな国の方がいますので、目的とは異なった解釈をする方がいっぱい出てきます。そういったところが難しいなというのと、あと難しい問題をずっとやって解決しましたっていうのも、難しい問題がどれだけ難しかったかと判断できる人があまりいないです。
特に人事評価する側にはいないので、そういったところが評価指標としてはすごい難しいです。すごい時間かけて1件解決しましたみたいに見えてしまうんですけど、そうじゃないんだよというところを評価するのはとても難しいです。サポートのいろんなストーリーについては過去のエントリーにも書いてます。資料をあとで公開します。というわけで、私からのお話は終わりにしたいと思います。ありがとうございました。

質問者1：ナレッジのシェアリングについて伺いたいのですけど、エンジニアはどうしてもドキュメント書くのあまり好きじゃないという人も結構いるかなと思っていて、そういう人たちに対してナレッジシェアするのは大事なことだということを、習慣や考え方として浸透させるだとか、ドキュメントをどうやって作ると効果的だとか、そういうドキュメントを書くことは大事な仕事であるということをどうやって浸透させたかという部分を伺えればと思います。

—エンジニアと一言で言ってもいろんな種類のエンジニアの方がいらっしゃるんですけど、確かにソフトウェアを作る側のエンジニアの方って、利用者は多分こういう情報を求めてるだろうな、と考えて書く人もいるし、そういうのを全然考えなくて、自分の書きたいことだけを書くというタイプの人もいるんですけど、結局開発者本人が書いたドキュメントって、そんなに利用者から見て見やすいものになっている確率は非常に低いんですね。なので、弊社には専門のドキュメントテクニカルライターチームというのがいて、ソフトウェアを第三者視点で利用して、既存のドキュメントももちろん見るんですけど、利用して、テストして、足りない部分とか、こういうときにはどうするんだろう、みたいなのを全部チケットに上げて、開発者から回答をもらって、ドキュメントを書いていく専門のチームがいます。で、サポートはサポートで、利用者側に立った視点を持っているエンジニアの方が多いので、サポートは基本的にはそれほど悪いドキュメントを書く人は、少ない傾向にあるかなと思います。

質問者1：そもそもドキュメントを作るのはあまり好きじゃないとか面倒くさいとか、そういうのはないんですか？

—僕もそのタイプなので、確かにドキュメントを書くのは問題調査そのものよりはエキサイティングではないと思うんですけど、書いたドキュメントがいろんな人の問題を解決している例も数多く見ているので、そういったのがモチベーションになって、今は普通に書くようになっています。

質問者2：これ聞いても大丈夫なのかわからないんですけど、さっきカスタマーエフォートスコアのお話があったと思うんですけど、今回僕は初めて知りました。、サポートを利用するのが面倒か簡単かという指標だとおっしゃっていたんですけど、どういうことが面倒だと感じさせるみたいな、代表的な例ってありましたか？

—まずC-SATの問題点なんですけど、顧客満足度、満足したか、しませんか、っていうのはお客さんの性格と主体性によってかなりぶれます。ぶれが非常に大きいです。よくわからない理由ですごい低い点数をつける人もいるし、よくわかんない理由ですごい高い点数をつける人もいて、あまりCESに比べて定量的ではない傾向にあると言われています。で、面倒でしたか、面倒じゃなかったですか、というのは、サポートだと、私は中の人なんであれなんですけど、ユーザーとかにヒアリングすると、ほかのベンダーのサポートを使ったときに、そもそもつながらなかったら、とか、そういうので、サポートにコンタクトするのに非常に労力を要した、というのがやはり、満足度というよりも大きな障害としてフィードバックされてくることが大きいので、そういったフィードバックがいくかあってCESにスイッチするようになりました。

質問者3：エスカレーションマネージャーのキャリアっていうんですかね、ソフトスキルだけに全振りだけじゃ多分ダメで、ある程度製品とか、テクニカルなところも知らないといけないと思うんですけど、どこから来て、あと精神削れそうな気がなんとなくするんですけど、そのあとどこかに行くとか、ローテーションがあるのかどうかというところ、ですね。回し方、教えていただければ。

—確かに興味深い質問なんですけど、私はマネジメント職とかではないので、どちらかというと隣のロールの方、みたいになってしまって、実際にそこをどうやって回しているかという詳細を知らないです。なんですけど、基本的には、あまり個人に負荷がいかないように、普通のサポートもそうなんですけど、グローバルサポートの組織だと、残業しないとさっき言ったんですけど、なんでかというと、僕らの営業時間でいう午後5時までに次のリージョンに仕事を引き継ぐことが責務になっているんですね。なので、それをやらなかったら仕事をしていないことになるので、残業をするすべがないんです。なので、そういったエスカレーションマネージャーも、次のリージョンに引き継ぐという仕組みがあって、あまり1人で抱え込まない、という体制は基本的には共通してできています。

質問者3：チームの人はどこから来ているのでしょうか。エンジニアの人がそのエスカレーションマネージャーになったりするんですか？

—エンジニアの人がなった例も見ていますし、ほかのソフトウェアベンダーからもエスカレーションマネージャーとしてハイアリングされているというケースもあって、多分エスカレーションマネージャー自体はほかの大手のベンダーの方たちも置いている仕組みだと思うので、そういったところから移ってきているというケースが多いんではないかなと思います。