テクニカルサポートエンジニアの10の心得

Red Hat の杉村です。Ansible のテクニカルサポートエンジニアをしています。

今回は「テクニカルサポートエンジニアの10の心得」と題しまして、これまでの約4ヶ月で意識するようになったことをまとめてみようと思います。

この10個の項目には特に順番はありません。

「お客様の問いに答える」

お客様からの問い合わせに対して、知っていることを答えがちなこともあります。過去の問い合わせの事例から似たものを見つけたとき、そのままコピペしてしまいそうになるところで一呼吸置くことが大事だと教わりました。聞かれていることの答えになっているか、過不足がないかをよく考えてから返しています。 これはサポートのみならず、あらゆるコミュニケーションに言えると思います。試験や面接などでもそうです。知っていることを吐き出すのは気持ちがいいことではありますが、必ずしも相手が求めていることではない場合があります。問いに答えることを意識するのが大切です。

「お客様の問題を再現させる」

お客様は何か操作をしたときに動かなくて困っています。ドキュメントや事例を検索して同じエラーメッセージが出てきた場合はこうするという解決策が見つかるかもしれません。でもそれは必ずしもお客様が訴えてきた問題なのかどうか、きちんと確認することが大事です。自分で体験せずに見聞きした情報のみでやりとりすると、どうしても長引く傾向にあります。再現させたらほぼ勝ちです。

「サポートを買っていただいていないお客様へ案内する」

我々サポートエンジニアは、お金をいただいて仕事をしています。サポートを買っていただくことは弊社の生命線です。一言二言だけのアドバイスを添えて、「ぜひサポートを買ってください」と案内するようにしています。

「バージョン番号に注意する」

他のOSSをベースにしたプロダクトも同じだと思いますが、Ansibleはバージョンアップの速度がとても早く、バージョンが違うと動きも異なることがよくあります。Ansible Towerでは3.2以前と3.3では画面の構成も違います。かと言って全てのお客様が常に最新版を導入していただいているとは限りません。以前のバージョンもサポートしている限りにおいては手元でいつでも検証できるように準備をしておく必要があります。バージョンアップに伴うトラブルやお問い合わせもよくあります。

「わからない点は素直に聞く」

お客様は世界中にいますので、直接見に行ってのサポートはできません。どういう状態にあるのか、何に困っているのか、やりとりをしていてもよくわからない場合があります。こちらも全ての動作を隅々まで把握しているわけではありませんので、何を聞かれても何でもわかるというものではありません。お客様と一緒に解決するということも大切にして、いただいた情報だけではなくどういう情報があれば解決しやすいか、こちら側でも再現しやすいかということを聞くようにしています。

「チームメイトに相談する」

わたしはいま4ヶ月目ですが、もう長らくサポートを経験しているメンバーもいます。新しく来た問い合わせに対して、すでに他のメンバーが答えた事例があるかもしれませんし、そのときの検証環境も残してあるかもしれません。 Ansible EngineやAnsible Towerに関わる技術分野はとても多岐に渡ります。LDAPならこの人が詳しい、OpenShiftならこの人、などなど得意技がそれぞれあります。世界中にサポートメンバーがおりましてタイムゾーンの関係であまり話ができていない人もいるものの、普段から積極的にコミュニケーションを取るようにしています。お客様への回答をするにしても、よくお互いにレビューしています。

「過去の問題を探す」

Red Hat では Ansible チームに限らず、KCS (Knowledge Centered Service) というナレッジを蓄積した仕組みを使って案内をしています。KCS のドキュメントはそれぞれのサポートメンバーが書いて、レビューを経て公開されます。役に立つドキュメントは問い合わせからリンクされ、数多く参照されることになります。 問い合わせを受けたときはまずこちらを探します。あるお客様で直面した問題は、他のお客様にも起こり得ます。問題を正確に受け止めて手元で再現し、KCS を見つつ一定以上の品質の回答をするというのが普段の活動になっています。

「GitHubを探す」

だいたいのことはKCSや再現テストで回答が作れる場合も多いのですが、どうしてもわからないこともあります。Ansible Engine や Ansible Tower/AWX は GitHub で開発をしていますので、そちらにも Issue が蓄積されています。特定のバージョンの不具合を見つけたり、ソースコードを特定して仕様を確認したりということのためによく参照します。

「開発チームと相談する」

サポートチーム側で結論が出せないような問題も中にはあります。オープンソース製品の「仕様」　の記事にもあるように、仕様はすべて文書化されているわけではありません。大まかな設計方針が共有されているだけで、細かいところまですべて決まっているとも限りません。開発者がテストできる範囲にも限度があり、お客様の使い方によっては想定していない動作をすることもあります。解決に向けてどう回答すべきか開発チームと相談することもありますし、新規の問題については、サポートチーム側から Pull Request や Issue を上げることでお客様にはしばらくお待ちいただくということもあります。

「他の解決方法がないかお客様に提案する」

お客様は必ずしも全ての機能について熟知して使っていただいているわけではありません。やりたいこととできたことがお客様から見えることですので、詳しくお聞きするとそのできたことではなく他の機能で実現できることが紹介できるかもしれません。真っ正面からその問い合わせに答えるべきというようなことを最初に述べましたが、お客様の実現したいことをきちんと成功させるというのが一番に大切なことです。このプロダクトのエキスパートとしての回答もできるように意識しています。

以上10項目にまとめてみました。わたしはこの業界で仕事をするようになって20年目になりますが、テクニカルサポートエンジニアに限らず、他のお仕事にも通じるところがあると思います。

何か参考になるところがあればとてもうれしいです。