テクニカルサポートに的確に問い合わせる技術

テクニカルサポートを活用するために

はじめまして、ひよこ大佐と申します。Red Hatという会社でAnsibleのテクニカルサポートエンジニアをしています。

我々テクニカルサポートエンジニアがどのようなことをしているのかは、以下の登壇資料にまとめていますので、一読いただければ幸いです。

何かサービスや製品を使用していると、問題に遭遇することがあります。設定方法が不明だったり、思ったような挙動にならなかったり、サービスが停止してしまうケースもあります。そのような場合に一生懸命がんばって自己解決しようとしても、運用担当者だけではうまくいかないことも多々あります。

そのような場合でも、テクニカルサポート窓口に相談し、サポートスコープの範囲内で支援を受けることができます。しかし、適切な問い合わせ方を知らないと問題解決まで時間がかかってしまったり、支援を断られたり、うまくコミュニケーションが取れずに問題が全く解決できないという事態に陥ってしまうケースもあります。

今回は、テクニカルサポートに問い合わせる際に、実際のテクニカルサポートエンジニアの目線で留意していただきたいポイントをいくつかご紹介します。このようなポイントを踏まえて問合せをすることで、サポートエンジニアと問い合わせる本人両方にメリットがあります。

サポートエンジニアは問題解決に集中することができ、対応にかかる負担が減ります。問い合わせる本人は、スムーズかつ的確なトラブルシューティングを受けることができ、結果的により早く障害の復旧をすることができるようになります。

ではさっそく、問い合わせる際のポイントを確認してみましょう。

サポートは敵ではない

まず意識していただきたいのは、「サポートは敵ではない」ということです。エンジニアに対して「はやくなんとかしろ！」「いますぐ回答しろ！」という高圧的な態度で接する方も中にはいらっしゃいますが、テクニカルサポートエンジニアはあなたと一緒に問題解決する「仲間」 です。怒鳴るよりも冷静に調査へ協力いただいた方が、結果としてより早く問題が解決できます。

もちろん激怒されているお客様と冷静にコミュニケーションを取りながら必要な情報を集めていくのもサポートエンジニアの仕事のうちですが、もちろん怒っているお客様より協力的なお客様の方がより簡単に情報収集ができ、問題解決に集中できます。

障害が発生していると、関係各所からの早期復旧へのプレッシャーや原因の説明を求められたりすることもあります。サポートエンジニアは全力を尽くしてお客様の問題を解決できるように日々対応していますので、「一緒になんとか問題を解決しよう」という意識を持っていただけるととてもありがたいです。

適切な重大度を設定する

多くのサポート窓口では、重大度や緊急度を問い合わせ時に設定できるようになっています。また、これらの重大度はガイドラインに基づき設定するようお願いをしています。我々テクニカルサポートエンジニアは、設定された重大度に基づき対応方針を決定し、SLAを遵守できるようにケースをハンドリングしています。

ところが、「俺はいますぐ回答がほしい！」と、どのような場合でも重大度を最大にしてケースを作成してしまうと、サポートエンジニアはすぐにそのケースを確認して回答する必要が出てきてしまいます。場合によっては他のお客様からの問い合わせ調査を中断して対応せざるを得ない状況になることもあり、不必要に担当者の負荷を増大させます。

また、このような最大の重大度（システムの完全停止など）が設定されるケースでは、即時に復旧させることを第一目標とすることが多く、じっくりとトラブルシューティングする余裕がなくなってしまいます。

サポートエンジニアは、仮に重大度が低いケースであってもSLAの範囲内で適切に調査・検証を行い、回答をしています。ですので、ガイドラインに沿った適切な重大度を設定することが重要です。サポートエンジニアからガイドラインに基づく重大度の変更をお願いされた場合は、ご協力いただければ幸いです。

事実を明確に伝える

件名: 問題がおきました 
問題の内容: 早く直してください。電話: [phone]

上記のような内容で問い合わせをされても、エンジニアは一体何が問題なのか、どのような影響があるのか、一切情報を得ることができません。ですので、ケースを起票する際は必ず 「問題の詳細」を明確に するようにしてください。

一般的には、以下のような情報を添付してもらうとスムーズにトラブルシューティングを開始できます。

• 問題が発生した日時
• 問題が起きた製品やOSのバージョン
• 使用している環境(オンプレ・IaaSなのか、プロキシやロードバランサー、ファイヤーウォールが間に挟まっているかなど）
• 毎回発生するか、時々起きるのか、一回だけ起きた問題なのか（再現性があるか）
• エラーメッセージのログやスクリーンショット
• 変更作業などに起因している場合は、その作業内容

これらの情報が最初に揃っていると、サポートエンジニアはある程度問題の「当たり」をつけることができたり、疑われる既知の不具合を調べた上で回答することもできます。事象の再現テストを実施する際にもとても重要な情報ですので、ご協力ください。

ドキュメントを読む

多くの製品やサービスでは、ドキュメントが用意されています。もし使用方法についてわからないことがある場合は、まず一度ドキュメントに目を通してみてください。もちろん読んでみても記載されていなかったりよくわからない場合もあると思いますので、そのような時はケースを起票いただければ幸いです。

また、会社によってはナレッジベースを一般に公開しているようなケースもありますので、そのような情報を一通り眺めてみてから問い合わせをいただけると、サポート窓口の負荷の軽減に繋がりますので、ご協力いただければ幸いです。

仕様の確認や「好奇心を満たすため」だけの質問をしない

サポートエンジニアは「お客様が遭遇している問題を解決する」ために存在しています。それなのに「どうしてこういう仕様なのか」や問題の本質と関係のない質問を連投するようになると、お客様が解決したい実際の問題から遠ざかってしまうケースがあります。

ですので、もし製品の仕様を確認する必要がある場合は、「お客様が実際に遭遇している問題」や「ユースケース」を説明いただいたうえで、「この問題解決のためにこの情報が必要」といった具体的なバックグラウンドを提示していただけると、サポート側も問題にフォーカスした内容を回答できるようになります。

最後に

ここにあげたのはあくまで一例ですが、テクニカルサポートを味方につけるためには「適切な情報提供」と「調査への協力」が必要不可欠です。

我々テクニカルサポートエンジニアは、お客様の問題を解決するために日々技術を学び、情報を収集し、より早く的確に問題を解決できるよう日々研鑽を重ねています。その分野のプロフェッショナルである「テクニカルサポート」と協力することで、より本質的な問題にフォーカスして日々の業務にあたることができると思います。ぜひ、問い合わせをする機会があれば、ここで挙げたポイントを意識してみてください。