クリアコードでFirefox・Thunderbirdの法人向けサポート事業に従事している結城です。
去る10月18日、サポートエンジニアNight vol.4が開催されました。当日の発表資料はTECH PLAYのイベントレポートのページから閲覧できます。 （未見の方は、前回（サポートエンジニアNight vol.3）の内容の紹介も併せてご参照下さい。）
今回のテーマは「X人からY人までサポート組織が成長したときに発生した課題や失敗」という物で、Arm Treasure Data、Salesforce、Red Hat、MapRの4社のサポートエンジニアの方から発表がありました。 「一人サポート」から数人・十数人規模への成長の事例もあれば、100人以上の規模への成長の事例もあるという、ある意味でバラエティに富んだ物でした。
一人体制から複数人体制への移行、少人数体制から多人数体制に際しての課題や解決方法には、どの会社にも共通する傾向が見られました。 そこで本エントリでは、発表順ではなくトピック別に各社の取り組みをご紹介します。
なお、口頭のみで話されていた内容を重視して取った記録を元に作成しているため、スライドと口頭での説明の両方で語られていた内容の一部は、このエントリには含まれていない場合があります。 公開されている各発表のスライドおよび他の方の参加記録と併せてご覧頂くのがおすすめです。
サポート専門人員が置かれる以前の時点での取り組み
今回の発表の中で、Red Hat社の木村氏による発表の中に、サポート専門人員が一人体制になる以前の取り組みの紹介が含まれていました。これはRed Hat社に買収される前のJBoss社の話だったのかRed Hat社の話だったのかをきちんと控えそびれてしまったのですが、会社の規模が小さくサポート専門人員を置いていなかった頃には、サポートの質がサービスの評価に強く影響するという考えから、社内で 「エンジニアリングチームは作業時間の30％をサポート対応に充てる」というルールを設けていたそうです。
前回開催時の発表において、サポート専門の人員を置く前の状況として「回答できる人が回答する」といった運用を取っていた事例が紹介されていましたが、専門の担当者がおらず回答期限などがサービスの品質として明記されていない状況では、回答が後回しになるなどの問題が生じやすいのが問題だという事が語られていました。エンジニアリングチーム全体でのサポートへの参加を制度化するというのは、その解決策としてはずいぶん思い切った対応であるようにも思われますが、当時の会社全体でサポートをいかに重視していたかが窺えます。
この制度そのものはサポート専門部署の設立に伴って廃止されたとのことですが、そのような体制が確立されるより前の時点で一定のサポート品質を担保するための取り組み方として興味深い事例と言えるでしょう。
属人化の問題をどう回避するか？
サポート人員が一人またはごく少人数に限られていて、各人の負担が大きいフェーズにおいては、各社共に知識の属人化が課題となっていたようです。 知識が属人化するとその人が単一障害点になってしまうため、どの会社もその解消への取り組みについての話がありました。
その代表的な取り組みとして、やはり各社ともナレッジベースの構築に力を入れている旨の説明が為されていました。
Red Hat社では、ナレッジの量がサポートそのものおよびサポート人員の質の向上に繋がるという事から、再現性が少しでもありそうなものはナレッジにする方針を取っているそうです。 また、一般のエンジニア自身が各自でドキュメントを書く形にすると、実際にそのナレッジを参照する人にとって分かりやすくない書き方になる事もあるため、ドキュメント執筆を専門に担当するチームを設けているとのことでした。
また、日々のサポートの中での知識の共有だけでなく、サポートチームの新メンバーに対するトレーニングも重要です。 Red Hat社ではかつてはトレーニングは担当者の個人リソースに依存していて、やり方が担当者ごとにバラバラだったり、作成されたトレーニング用コンテンツも現状に合わない古い物が未整備で放置されているといった状況があり、サポートチームの規模拡大に伴ってそれを改め、サポートトレーニングチームという専門の部署を設けたそうです。
MapR社ではまだそこまでの規模に至っていないためかトレーニング用のドキュメントという物は用意されていない様子でしたが、新メンバーには社内ドキュメントだけでなく公開のドキュメントも読んでもらっているという事が語られていました。 MapR社では製品の直販を行っていないことから、販売パートナーのエンジニアに対するスキルアップのための情報共有も必要となっているとのことでしたが、そういう場面での資料に使えるという意味でも、公開可能なナレッジを公開しておくことは重要そうです。
Salesforce社の発表では、このような形で構築され公開されたナレッジにより、ユーザー同士の相互サポートによる解決が促進され、問い合わせの発生が減る事にも繋がったとの事でした。
当社の場合も、そういったノウハウの一部はこのククログに記事として公開しており、実際に、過去記事をナレッジベースとして使用する場面もあります。
属人化解消の次のステップとしての専門化
その一方で、Salesforce社の杉本氏の発表においては、特定の技術に専門のチームを設けるという取り組みが紹介されていました。
製品数や機能数が増加してくると、すべての知識を全員が持つというのは現実的に不可能になります。 また、全員で共通して把握できる程度の浅い知識では解決できない、より深い知識が必要となる種類の問題もあります。 特定の技術に精通した専門のチームを設ける事が、そういった問題に対する回答のスピードを上げるために有効だったとの話でした。
これは、一定以上の規模にサポートの人員数が増えた状況において再び専門ごとの分担を行うという事です。 技術が属人化した状態と比較すると、ある技術の専門として働くチームの中ではチームメンバー間での知識の共有により属人化が解消されるために、単一障害点が発生しないという事になります。 少人数での分担の結果として発生する属人化を解消した先で、再び分担が有効に作用するというのは、興味深い事です。
ただ、このようにチームごとに専門分野を分けた場合には、複数の分野にまたがる知識やどの分野にも属さない（チームの隙間に落ちてしまう）知識が求められる問い合わせに対する回答をどのようにすればよいか、という問題が生じます。 そのような問い合わせが増加してくるようであれば、チームの編成を見直したり、分野を横断して「広く浅く」取り扱うチームを新たに設けたりといった形で、何らかの対応を取る必要が生じてくるでしょう。
このような分野ごとの担当分けをSalesforce社の事例では「スキルグループ」、MapR社の事例では「テクニカルディビジョン」といった呼び方で表しているようでした。 Salesforce社ではスキルグループ間の移動は本人の希望を踏まえて行っているとのことで、おそらくはそうして分野をまたいだ知識を身に着けた人が、上記のような「チーム間の隙間に落ちてしまう」問題の解決にあたる事になるのでしょう。
サービスレベルの維持・向上のための施策
SLA1の定めの有る無しに関わらず、サポートへの問い合わせに対する回答は早いに越したことはありません。 前述の専門分野ごとのチーム分けも、回答のスピードアップのためだった事は既に述べた通りです。
Salesforce社では当初、サポートチームが実際に技術サポートを提供するのにかかる時間そのものよりも、サービスレベルの確認や、翻訳、メールでの連絡といった雑務によるオーバーヘッドが負担となっていたそうです。 この状況を改善するために、
-
メールでの応答を廃止し、オンラインでの問い合わせ窓口をWebサービスに集約した。
-
契約ごとのサービスレベルの差異を減らし、サービスレベルの確認の手間がそもそも不要になるようにした。
-
深刻度による問い合わせの仕分けを専門的に行うチーム（トリアージチーム）を設けた。
といった変更を行い、サポートチームが技術的な回答に集中できるようにした事によって、実際に回答に要する時間を短縮することができたとの事でした。
Red Hat社では、製品が普及しデファクトスタンダード化するにつれてユーザー層が技術レベルの高くない人にまで広がっていったことから、技術的難易度の低い問い合わせや、無関係の物への問い合わせ、契約上のサービスレベルを超える対応を望んで食い下がるような問い合わせなどが増加し、技術職の人がその対応に長時間拘束されるという状況が発生していた事から、その解決方法としてエスカレーションマネージャーという担当者を置くようにしたそうです。 問い合わせ内容が契約上妥当かどうかなど、技術とは異なる観点での仕分けを行う専門家を置くことで、こちらも技術者が技術の事に集中して取り組みやすくなった模様です。
当社においても、契約上妥当かどうかの判断が難しかったり契約範囲に含まれなかったりする問い合わせ、交渉が必要な場面などがあり、契約関係を取り仕切っているスタッフに対応を一任する事があります。技術者が技術のことについて自信を持って迅速に回答できるのと同様に、契約や法律の専門化はそれらの問題に自信を持って迅速に回答できるという事で、可能であればやはりそのような体制を作っておくに越したことはないでしょう。
サービスの質の向上という観点からは、問い合わせを受けてから動く「サポート」に留まらず、先を見越してサービス提供者側から積極的にサポートを提供する「プロアクティブサポート」 に取り組んでいる、という説明も複数社からありました。
具体的には、Red Hat社では顧客に電話でコンタクトを取ったり実際に訪問したりといった活動をされていて、MapR社でもTAM2が顧客訪問を行っているとの話がありました。 また、各社とも顧客環境のテレメトリデータを収集し、異常の兆候を捉えて先回りして提案を行うという取り組みをされているそうです。
問い合わせが発生する前に問題を解決するという意味では、ユーザー同士での相互サポートが促進されるような公開のナレッジの充実も、その一種と言えるかも知れません。
24時間サポートを実現するために
今回の発表を行っていた4社はいずれもグローバル企業で、中には24時間休み無しのサポート体制を敷いている会社もあります。 これは、タイムゾーンが近いエリアごとに現地時刻での日中を主な担当領域として実現しているそうです（例えば、アメリカが日中の時間帯はアメリカやカナダの拠点が対応し、アジア地域の夜が明けたら今度は日本の拠点が対応、という具合）。
ただ、各拠点の通常の業務時間のみで24時間をカバーしきれる体制が整うまでは、夜間対応などの負担が大きかったという声も聞かれました。 例えばRed Hat社では、当初はサポートエンジニアが稼働しているのはアメリカ・インド・ヨーロッパの3拠点のみだったため、アジア地域の問い合わせはアメリカの拠点の人が残業や夜勤で対応していたとのことでした。 その後発表者の木村氏が日本でサポートエンジニアとして稼働し始めたことから、アジア地域の問い合わせが一気に木村氏に集中したという苦労話を披露されていました。
Red Hat社は現在では、例えば日本では17時までにその日の対応内容の情報をまとめ、次の時間帯の担当として稼働を始める拠点に情報を引き継ぐ事で、残業や夜勤をしなくても済むという運用を取られているそうです。
夜勤などの特別なシフトの一例として、アメリカでは「4×10シフト」と呼ばれるシフトが広まりつつあるという話も紹介されていました。これは「日曜から水曜日まで、1日10時間勤務」と「水曜日から土曜日まで、1日10時間勤務」の2チームでシフトを組むという運用です。ただ、健康面の悪影響の懸念や、日本国内では保育園のお迎えの時間帯に間に合わない、労働基準法に抵触する恐れがあるなどの問題があり、日本国内ではまだ採用していないとのことでした。
顧客に喜んでもらえるようになるために
顧客の満足度についても、各社非常に重視している様子が窺えました。
Salesforce社のQ&Aにおいては、顧客満足度の向上に最も効果があったのは何だったかという問いに対して「回答の速度」と回答されていました。「専門チームの設置」といった施策も回答スピードの高速化のためだったという話は前述の通りです。 それ以外の施策として、アンケートの回答で評価が悪かった時にはマネージャーが自ら顧客に電話し、不満を詳しくヒアリングするといった事もされていたそうです。
Red Hat社では、顧客満足度の指標として、「顧客満足度」ではなく「CES（Customer Effort Score）」と「NPS（Net Promoter Score）」を用いているそうです。CESとは「サポートを利用するのが面倒か、簡単か」を数値化した物、NPSは「そこの製品を他の人にお薦めできるかどうか」を数値化した物です。実際の所、「顧客満足度」は主観によるため定量化が難しいですが、顧客満足度が低くなる理由は「問い合わせてもなかなか回答が無い」「サポートに電話をかけても繋がらない」といった物がかなりの部分を占めているそうで、その点にフォーカスした指標であるCESに切り替えた事で、評価の定量化が容易になり改善を図りやすくなったとのことでした。
Arm Treasure Data社の高橋氏による発表においても、顧客の納得感を何より大事にするという事を念頭に置き、反応を早く・マメに返すことを意識されているとのお話がありました。また回答にあたっては、周囲の人の協力を得たり、エスカレーション先となる専門のエンジニアからの反応が悪ければ回答を催促したりといった具合に、社内の都合で手段を選んだり遠慮をしたりはしないよう心かげているとのことでした。
サポート部門のモチベーション維持、人事について
MapR社の発表の中では、社長などの経営層がサポート部門を重要視していて、また、そのように認識している事を公言しているという事を話されていました。 サポートをアウトソースせず自社内で育てていく方針を取っているのもそのためとのことで、そのようなメッセージが内外に向けて示されているという事は、サポートに関わる人のモチベーション維持にも良い効果があると言えるでしょう。
開発エンジニアなどの目立つ部分に比べると、サポートエンジニアの採用には人が集まりにくい事から、各社とも苦労している様子です。 それだけに離職者が発生するとダメージが大きく、Arm Treasure Data社では1on1を行ったり、他部門とのコミュニケーションを密に取ったり、会社の買収といった大きな出来事の前後でもメンバーが動揺しないように気を遣ったりと、メンバーの心理面のケアに関する取り組みが行われている旨のお話がありました。 興味深いところでは、サポートの業務だけをやっていると気分が滅入りやすいため、やる気が高まるような別のタスクも随時並行してこなすという事も行っているとのことでした。
サポートエンジニアの人事評価の難しさについても、各社から語られていました。 実際にRed Hat社の発表においては、ナレッジの執筆を数で評価すると質の低いナレッジが増産されてしまうというような形で、数値目標を設定すると必ずその裏をかかれるという事や、解決した問題の「難しさ」を第三者が客観的に評価できないという事などが例に挙がっていました。
この点についてArm Treasure Data社では、「チームの目標」と「個人の目標」をそれぞれ別々に設定した上で、チームの目標にのみKPI3を設定しているとの事でした。これは、顧客の数や地域の顧客層などによって個人の目標の達成度合いに差が出やすいため、単純に評価すると却ってモチベーションの低下を招きかねないという事からだそうです。
まとめ
以上、各社の取り組みをトピックごとに整理する形で、サポートエンジニアNight vol.4の発表内容をまとめてみました。
Salesforce社の発表では、サポート部門のなかでTier1からTier3までの3段階にチームを分け、簡単な内容への回答はTier1で行い、そこで解決できなかった問題をTier2、Tier3へとエスカレーションしていくというサポート体制の説明がありました。 また、特別な顧客向けに別ラインのプレミアムサポート的な窓口も設けているという説明がありました。
当社のサポート業務は基本的には、ここでいうTier3やプレミアムサポートに特化して顧客企業向けにサポートを提供する物に近いです。 組織体制や事業内容的にも、サポート人員のみを10人、20人と増員していく事は現実的でなく、そのため残念ながら、今回拝聴した内容の多くの部分は直接的に当社のビジネスの参考にはなりにくいのは否めません。
もし当社のような規模・業態のサポート事業での知見にもニーズがあるようであれば、発表を通じてサポートエンジニアコミュニティへ何らかの有用なフィードバックを行っていければと思います。
