テクニカルサポートからの回答を良く・早くするコツ

こんにちは、サーバーワークス入社から5か月が経ったテクニカルサポート課の佐藤光晃です。突然ですが、皆様は日常生活や仕事の中でどれくらいヘルプデスクやユーザーサポート、テクニカルサポートにお問い合わせをしておりますでしょうか。
お問い合わせの結果、期待通り・期待以上の結果を得られた経験がある人や、うまく意図が伝わっていなかった事で誤った回答をされた、スケジュール感を考慮されずサポート側の都合が優先された等、残念に思った経験がある人や、一切お問い合わせをした事が無い、という方もいるかと思います。
そういった経験をお持ちの方や、不慣れの人でも出来るだけ期待通り、もしくは、期待以上の回答を頂くためのコツを紹介させていただきます。

テクニカルサポートの仕事内容について
テクニカルサポートから良い・早い回答をもらうためにできること
まとめ

テクニカルサポートの仕事内容について

そもそもテクニカルサポートって何をしてるの？ということで、テクニカルサポートがお問い合わせに対し回答を出すまでに行っている事を下記に記載しました。

ヒアリング

お客様よりお問い合わせいただいた際に、お客様の状況をより正確に把握するために実施します。
「システムが動かなくなった」という問い合わせがあれば、いつから動かなくなったのか？どの AWS サービスが関連しているのか？そのシステムが動かないことによる影響やビジネスインパクトはありますか？など、お客様のお問い合わせ時点の状況や背景を把握するために実施します。
このヒアリングの結果からテクニカルサポートが受け持っているお問い合わせの優先度が決まりますので、お急ぎの旨を受けている場合はより詳細な状況をお伺いすることが多いです。テクニカルサポートからの回答速度に影響しがちです。
お問い合わせ時にこちらの情報が整っていれば、このヒアリングや以下の事実確認のやり取りが減り、回答をお出しする時間が早くなります。

事実確認

お客様からのお問い合わせ内容をもとに、CloudWatch Logs や CloudWatch メトリクスなど、AWS コンソールから状態を確認したり、お客様からいただいたログファイルの内容の確認を進めます。
一例をあげますと、お客様から「昨日 EC2 インスタンス (インスタンス ID) が再起動されてたけど何かありましたか？」というお問い合わせをいただいた場合には、CloudWatch メトリクスで StatusCheckFailed_System や StatusCheckFailed_Instance が記録されていないか確認するといった対応をしております。

仕様調査

お問い合わせいただいた内容がエラーによる障害、パフォーマンス遅延などが発生した場合、それが想定された動作かどうか調査を進める上で仕様を確認します。
仕様どおりであれば対処法について回答し、想定外の事象の場合には不具合の可能性も踏まえ、検証も行いつつ確認を進めます。 AWS のドキュメントや、ブログなどの公開情報の確認、調査がこちらにあたります。

事例調査

出力されているエラーメッセージや、類似する環境によるお問い合わせ履歴の確認を進め、同様の問題が無いか社内事例を調査します。エラーメッセージ本文や、エラーメッセージが出力されるまでの過程が一致している場合、その事例で行われている対処策がそのまま有効となる場合があります。
日常生活においても、誰かの成功例や失敗例を参考に物事を進める事があると思いますが、事例調査はそれに類似します。

検証

上記の事実確認、仕様調査、事例調査の結果だけでは回答の根拠として弱い事が多々あります。そのため、上記の調査結果から得られた情報をもとに仮説を立て、検証をする事で根拠を強くします。
一連の流れとしては、お客様環境で発生しているエラーやトラブルを検証環境で再現 → 仮説どおりの対処で解決できるか確認を進めます。
また、仮説がうまくいかなくても、再現手順を AWS に連携する事で、AWS 社内調査の手助けになる事があります。

テクニカルサポートから良い・早い回答をもらうためにできること

テクニカルサポートの仕事内容を上記で紹介させていただきました。お読みいただくとわかると思いますが、この仕事内容は基本的にお問い合わせいただくお客様のご協力のもと進める前提となっております。
お客様とテクニカルサポート間のやり取りが、テクニカルサポートからの回答の品質や速さに影響しますので、このやり取りのコツを以下に記載いたします。

お客様環境について詳細を記載する

お客様環境を理解することで、お客様環境に適した回答をお出しするためとなります。文章で説明が難しい場合や複雑な環境の場合は予め構成図をご共有いただく事が有効となります。
また、テクニカルサポートが行う検証のために必要な情報となります。

利用している AWS サービスやそのリソース名、ARN について記載する。
お客様環境で行われている処理の詳細（利用している AWS サービスがどのような役割を持っているか、サービス利用者がどのような通信経路を必要とするか等）
オンプレミスやクラウドの混在、もしくは、複数の AWS アカウントや VPC が関わる場合は構成図を共有する。
OS の問い合わせは、使用している OS の種類やバージョンを記載する。

(障害等のトラブルの場合) 問題の詳細

障害やパフォーマンスの遅延などの何らかの問題が発生した場合には、可能な限り下記すべてご準備いただく事が、ヒアリングやテクニカルサポートが行う事実確認や事例調査の時間を削減でき、早い回答をいただくための有効な手段となります。

その問題に関係するメッセージのコピー&ペースト (テキスト形式)
問題を確認できるログファイル、ログファイルの収集元について
問題を確認できるスクリーンショット
問題の頻度、再現度 (初めて / たまに / 毎回など)
UTC/JST などのタイムゾーンを含めたタイムスタンプ
問題発生に至るまでの作業内容や作業ログ
その作業で実現しようとしていた事について
その作業を実施するうえで参考にしている前例やドキュメント、ブログなど

お問い合わせに関するスケジュールや影響、ビジネスインパクト

お急ぎの場合、そのお問い合わせに対する回答がいつまでに必要なのか、遅れた場合にどのような影響やビジネスインパクトがあるのか詳細を記載いただく事で、テクニカルサポートが持つケースの中で優先度が上がり、結果として対応速度があがります。
また、ビジネスインパクトを記載いただく場合には定量的に記載いただくと、テクニカルサポートや関係者に影響が伝わりやすいです。

例: 急いでます。この作業ができないと約 20 万のユーザーが弊社サービスを利用できず、ビジネス全体に影響があり、大体 1000 万円ほどの損失が発生します。

上記例のように問題が影響するユーザーの人数や、損失する金額が記載されていますと緊急性が伝わりやすくなります。
ただし、お問い合わせ起票時に定量的な情報はすぐには出せない場合もあると思います。その場合は、最初は分かる範囲で影響をお伝えいただく形でご連絡いただき、詳細を把握でき次第、上記例のようなご連絡をする、ということが有効となります。

複数の質問がある場合はお問い合わせを分ける

テクニカルサポートは 1 つのお問い合わせの中に複数の質問がある場合、すべての回答が揃ってからお客様に回答することが多いです。そのため、質問の一部はすぐに回答が来るだろう、とお考えになられている場合には想定より回答が遅くなる場合があります。
また、複数ある質問に関連性が無い場合、テクニカルサポートの調査や検証に必要な時間も増えてしまい、回答が遅くなってしまいます。
上記の事から、基本的には 1 つの質問につき一回のお問い合わせをすることが回答を早くいただくためのコツとなります。もし、複数ある質問に関連性がある場合は一回のお問い合わせにまとめていただくのは OK です。
こちらは AWS でも推奨しておりますので、複数のご質問をしたい場合には、お問い合わせを分けることをご検討ください。

技術的なお問い合わせに関するガイドライン | AWS サポート

1 ケース＝ 1 質問をおすすめします

１つのサポートケースには、一時点で、１人のサポートエンジニアが対応しますので、独立性の高い質問は、複数のケースに分けて起票いただくと対応を迅速化できる場合があります。もちろん相互に関連の強い質問は１ケースにご記載ください。迷った際は、書きやすい形でご記載ください。サポートエンジニアがサポートケースの分割をご提案する場合もあります。

まとめ

以上がテクニカルサポートからの回答を良く・早くするコツとなります。
いきなり最初から全部やれる人は中々いないと思いますので、上記の点を意識することから始め、徐々に慣れていただければと思います。
また、弊社の Zendesk ガイドや AWS の公式サイトで問い合わせの記入例等を紹介しておりますので、そちらもぜひご参照ください。

・技術的な問い合わせにはどのような情報が役立ちますか？（サーバーワークスサポートセンター）
・お問い合わせ時に高い緊急度をご選択いただく場合の注意点について（サーバーワークスサポートセンター）
・技術的なお問い合わせに関するガイドライン | AWS サポート