この記事は、Microsoft Azure Tech Advent Calender 2024の12/23 公開のものです。
Tech と書いていますが、そんなことは私は気にしません（ぉぃ
本稿の目的と背景
本稿では、日本マイクロソフトのテクニカルサポートエンジニアとして働いている中で、感動したチームの協力体制ならびにエピソードについて、参考になればと思い、ご紹介いたします。
世の中のテクニカルサポートエンジニア組織へ届け！！ という気持ちで書いています。
世の中には、数え切れないカテゴリの製品、サービスが存在し、目的に応じてそれらを取捨選択しながら会社に取り入れ、仕事を効率化しながらビジネスを進めていると思います。
例えば、社内のファイル共有する仕組み１つにしても、社員同士の1：1のファイル共有の場合は、OneDrive を利用しているが、1:N のときは、他のベンダーの SaaS を使っています、といったこともよくある話です。複数の製品が複雑に絡み合いながら、会社のITは成り立っているのはみなさまご存知のとおりで、便利な世の中になってきていると感じる一方、疑問点が出た場合や問題に遭遇した際の解決方法においても複雑化していることは言うまでもありません。
10年、20年前のテクニカルサポートエンジニアよりも、現在は幅広い知見を求められる傾向にあると感じています。
テクニカルサポートエンジニアはそのような複雑に絡み合った問題から原因を切り分け、原因を突き止め、解決することが求められる職種になりますが、人間の脳自体は数十年で一気に進化しているわけでもなく、日々悩みながら調べ、切り分けしながら、原因まで辿り着こうと頑張ります。
Microsoft Azure においても、多種多様なクラウドサービスを提供し、各機能が連携しながら稼働しています。簡単な例を挙げると、Azure VM 側に問題があると思いきや、連携しているストレージサービス側の動作の問題であった、ということや、OSの問題かと思いきや、通信経路にある Azure Firewall の設定漏れだった、なんてこともあったりします。
多くのサービスが絡み合う中で、トラブルシューティング時のサポートチームの動きについて、他のサポート組織でも使えそうに感じた Tips を後述していきます。
緊急対応編
マイクロソフトでは、お問い合わせ頂く際に優先度A～Cをご選択頂きます。
優先度は、事業継続性を軸とした影響度に応じて設定いただいています。
また、サポート契約ごとに決められたルールに基づいて、テクニカルサポートを行っています。
重要度と応答時間
ここで注目すべきは、最も優先度の高い重要度Aです。
お客様の事業に大きな損失が発生し、サービスの質が大きく低下、即時の対応が必要である場合にのみ設定可能な重要度です。
最上位のプランである「Azure Rapid Response」は、初回応答時間が 「15分以内」 に設定されています。つまり、お問い合わせ頂いてから15分以内でご連絡し、問題解決に着手します。
初回応答の早さのみならず、ありとあらゆる手を尽くして、早期の問題解決を求められるのも重要度Aの特徴です。
お客様にサポート契約を結んで頂き、ビジネスに影響が出ている状況下であるため、このような対応は当たり前であるというのは十分理解できます。
一方で、もしあなたが重要度Aを担当するテクニカルサポートエンジニアの立場になったときに精神的に余裕はあると思いますか？
内容や状況にもよりますが、サポートエンジニアも人ですので、個々で得意な領域や苦手な領域が存在します。日々、数百のお問い合わせがある中で、自分が対応する案件が全て得意なものばかりではありません。そのような場合においても、トラブルは待ってくれません。
一般的な精神の持ち主であれば、当然焦りますし、常に次のアクションと次のご連絡時間をセットして動きますので、次のアクションを決めれず、悩んでいるときは更に焦ったりもします。
メンバー全員がジブンゴトとして緊急対応案件に参戦！
我々は皆が思いやりの気持ちを持ってチーム運営されており、メンバー全員が１つのトラブルに対して ジブンゴト と捉えて、次々に調査を行います。
では、どのように調査を連携するのか？
１つ例をご紹介します。（あくまで例です）
１．SevA のサポートリクエスト依頼が来る
２．その Sev.A を対応することになったエンジニアが、社内のコミュニケーションツールとして利用している Microsoft Teams のチャネルに相談内容を貼ります。
例えば、私がSevAをメインで対応する人として、以下のような問い合わせが来たので、メンバーに相談するとしましょう。
既に業務に支障が出ており、朝までに復旧しなければ、開店業務が行えない、なおかつ、店舗運営が半日止まると３億円の損害と書いています。これは急がねばなりません。
３．SevA リクエストが来て、大体５分～１０分以内には、以下のようなやり取りが行われ、チームメンバそれぞれの視点でスレッドにどんどん書き込まれていきます。
以下のスクリーンショットの例においても、６名がスレッドに対して、コメントをしています。
見て頂いたとおり、次に次に切り分けがされていきます。
”メンバーD” は、もう既に Webサーバーが稼働しているAzure基盤側を調査した ことを報告してくれています。
このように、１件のSevA対応についても、１人で黙々と最初から最後まで調査を行うのではなく、
どこに問題があるのか、切り分けすべきこと、などをチームメンバーからどんどんコメントをもらえ、
なおかつ、チームメンバーが調査の一部を肩代わりして調査していることもあります。
このチーム一丸となって、前のめりに調査するメリットは、いくつもありますが、私は大きく２つあると思っています。
お客様の問題を早期解決できる
チームメンバーの多数の意見や視野を用いて調査が行われます。
複数人が関わることで、偏った視点での調査にならないメリットや、調査の漏れを限りなく無くすことができ、結果としてお客様に高品質のテクニカルサポートを提供することができます。
サポートエンジニアの精神的負担の軽減
お客様の業務影響が大きい障害対応において、サポートエンジニアは、精神的に追い込まれます。
メンバーそれぞれが 「自分は１人じゃない」 と思える職場環境は非常に大切です。
日々精神的に追い込まれる環境では、当然離職率も高くなりがちと思いますし、メンバー全員が思いやりの精神でチーム運営することは、これからのサポート組織には必要に思えます。
過去の会社では…
余談になってしまいますが、過去に私はとあるサーバーベンダーでテクニカルサポートエンジニアをしておりました。
その現場では、緊急対応案件が来た場合、担当のエンジニアがその案件を必死に対応し、わからないことや確認が必要なことについては、当然ながらエスカレーションを行って対応をしていましたが、非常に個人への負荷が高いオペレーションになっていました。
１人の視野で調査を行い、エスカレーションを行っていたため、「なぜ初動で◯◯を確認していないのか？」であったり、「先に営業サイドに共有しておくべきだったね」などといった、予期せぬ指摘なども多くあったように思います。
１件の案件に複数人が寄って集って対応するこの現在のスタイルは、ぜひ世の中のテクニカルサポート組織においても、オペレーションにマッチするようであれば、取り入れてほしい、とおもい、記事にしました。
どこかの会社のテクニカルサポート組織の参考になれば幸いです。
メリークリスマス＆よいお年を～！
Discussion
有用な記事ありがとうございます。
toCビジネスでサポート経験があるものです(いわゆるレイヤ1から3までやりました)
記事を拝見する限り皆さんが一丸になって対応していることがわかりました。
質問なのですが、サポートエンジニアの中でも対応体制上レイヤ分けみたいなことってされているのでしょうか？(されてた上で一丸となっているのは素敵だなと思いました)
体制のあまり話しにくい部分の話なのでコメントしにくかったら申し訳ないです