テクニカルサポートで大事そうなことをまとめる
Red Hatサポートエンジニアの方の記事を読んで、あー面白いなーと思って私もまとめてみたいと思います。私も長い間テクニカルサポート（特に障害対応周り）をやっていたので参考になれば。
Red Hat の杉村です。Ansible のテクニカルサポートエンジニアをしています。
今回は「テクニカルサポートエンジニアの10の心得」と題しまして、これまでの約4ヶ月で意識するようになったことをまとめてみようと思います。
10の心得（orangeitems版）
お客様の名前と連絡先をまず聞く
いろいろお客様から聞き出して、「あ！連絡先聞くの忘れた！」となることがたまにありました。学校のテストで名前を書き忘れるヤツですね。システム的にどの契約番号からかかってきたかはテクサポならわかるようにはなっていると思いますが、契約者と違う人が電話してくることはざらなので、まず連絡先をお伺いすることは非常に大事です。
手順より何よりまず環境を聞く
何をサポートしているかにも寄りますが今なら、ソフトウェアであれば下記のことを聞くのは必須でしょうね。
・オンプレミスか、パブリッククラウドか。
・オンプレミスなら、ハードウェアの種類やスペック。仮想基盤の有無など。
・パブリッククラウドなら、どのIaaSのどんなサービスか。
・OSとバージョン、ミドルウェアのバージョン、アプリケーションのバージョン。
・パッチ適用の有無
環境の小さな変化で同じ再現手順を踏んでも再現しないことがよくありました。お客様は手順を早く言いたいのですが、いやいや、環境聞かなきゃ先に進めないよという気合がとても必要です。
そもそも、サポート切れのプロダクトであることがこの時点で発覚することもありますね。サポート切れなら理由をお伝えして対応はここで終了です。
どれくらい急いでいるかを聞く
病院で言えば、かるい風邪から命に係わる場合まで、問題にもいろいろな幅があります。思いっきり急ぐ場合は、もはや自分の手には負えないのでさらっと聞いて偉い人にエスカレーションするのが吉です。下手に自分でやろうとして時間をかけてしまうと、クレームを食らう厳しい世界です。
また、急ぐのも、「急ぐ！急ぐ！」だけではわけがわかりませんので、何がそんなに急がないといけないのかを聞きます。本番サービスの停止で、どれぐらいの損失が出る話なのか、みたいなビジネス的な観点が重要です。
通常範囲の問題であれば次に進みます。
今何が困っているかを聞く
まだ手順まで行きません。
異常終了なのか、想定外の動作なのか、高負荷なのか。
再現手順を持っているのか。たまに起きるのか。初めての事象なのか。
まずは問題解決へのゴールを定めます。
環境と、困っていることをまず聞きながら、何を情報収集すべきか、回避策はないかを考え始めます。考えるだけで、まだ口は挟まず、聞くことが重要です。
手順を聞く
詳しい手順のヒアリングに入ります。あんまり長い場合はメールなど、まとめてもらって文書で頂きます。GUIなどはもはや電話だけで伝えるのは厳しいものがあります。手順をうかがうのは時間がかかるので、裏で対応を考えているのが普通です。
情報採取の依頼をする
ログ等々を頂いて調査の根拠とするために、情報採取の依頼をします。メールで手順を頂く場合はそのメールの返信で依頼します。電話の場合は後でメールでご送付しますとして電話は伝えない場合が多いです。
情報採取の方法なんていつも決まり切っているので、方法を文書化しておいてコピペして送付するのが一般的かと思います。
即答できる場合は即答する
ここは満足度を上げるポイントでもあるのですが、いろいろとテクサポをやっていると即答できる問題があります。その場合は、とりあえず答えちゃうと満足度が上がります。連絡してよかった！となります。
間違えると叱られますので、ヒアリングした情報の精度は重要となります。
過去事例を調査する
再現テストするのは楽しいので、すぐに再現テストしたくなるのですがぐっとこらえて。情報採取できたらログを見て、キーワードとなるようなエラーから過去事例の検索をします。
私の好きな言葉なのですが「世界で初めてのトラブルが、ここで起きるはずはない」です。かなりの確率で過去事例があります。これを見つけ出せるかどうかでパフォーマンスが大きく変わってきます。世界で初めての事象だったら、それは逆の意味でモチベーションが上がります。
私の検索力は、このテクサポの時の経験で鍛えられたなあと思います。
開発チームへ問い合わせる
テクサポが、過去事例を開発チームに問い合わせたら負けです。
過去事例を見つけ出すのはテクサポの仕事で、未解決の問題を解決するのが開発チームの仕事です。
そして、環境と再現手順をわかりやすく伝えつつ、お客様から取得した情報をスマートに送付すること。1GBも2GBもログを送られたら開発チームもたまったものではありません。問題の焦点に対してスマートに切り取って、開発チームが仕事をしやすいように情報処理して、資料を送付する必要があります。
本筋の調査とは別に、代替策を並行して考える
もし、問題の修正に時間がかかる場合は、回避策が必要になります。これも開発チームに伝え一緒に考えてもらいます。
問題を発生させたのは開発チームに瑕疵があるため、結構親身に答えてくれるはずです。お客様は開発チームと会話することはできないので、お客様目線で調整する必要があります。
基本的だがビジネスの基本
元記事にもありますが、テクニカルサポートじゃなくてもビジネスの基本のようなものだと思います。今ではインフラ／クラウドが専業ですが若い時のテクサポ経験は非常に私を助けてくれています。
ご参考まで。
