技術サポートは製品への貴重なフィードバック源。だから開発チームが担当する

八巻 : 今日は、皆さんにテクニカルサポートを行う際に実践していることなどを伺ってみたいと思っているのでよろしくお願いいたします。では早速、テクニカルサポートの仕事内容について教えていただきたいのですが、その前に明らかにしておかなければならないことがありますね。皆さんはテクニカルサポートの専任スタッフじゃないんですよね？

馬渡 : はい。担当製品は違いますけど、実はみんなローカライズや製品設計も行う開発チームのメンバーです。グレープシティの技術サポートは、各製品の開発チームのメンバーが担当しています。

八巻 : それはどういう理由からなのか、説明していただけますか？

馬渡 : お客さまから寄せられた製品に対する技術的な質問にメールで回答するのがサポートの基本的な仕事ですが、お客さまは実際の開発の中で困っておられますので、とにかく早く解決のお手伝いをしなければなりません。そうすると製品と技術の両方について理解していないといけない。なので製品について一番詳しい開発チームのメンバーが技術サポートも兼任するということになっています。

八巻 : グレープシティのテクニカルサポートは回答が早いというのは、以前から利用者に評価してもらっている部分ですが、早さの理由はそういうところにあるんですね。

門馬 : 原則3営業日以内に何らかの回答することになっているのですが、8割ぐらいはその日のうちに課題が解決していると思いますよ。

武藤 : 早い時は、3時間もかからずにクローズ（課題が解決すること）とかもありますよね。ITの技術サポートでしかもメールでの受付は時間がかかると思われがちですが、「意外と早い」と実感していただけるようにがんばっています。

八巻 : 実は、テクニカルサポートの満足度調査のデータがここにあるんですが、1日以内での回答は全体の79.6％。そのうちの61.3％は半日以内に回答しています。それにクローズするまでのやり取りが1回で終わるケースが全体の73.4％です。これはメールのサポートとしてはかなり早いと思いますよ。

武藤 : お客さまはこの課題が解決しないことには次に進めないですから、とにかく早く回答しなくちゃと思いますよね。

八巻 : 解決に時間がかかりそうなものに対してはどのような対処を？

門馬 : 環境が複雑だったり、開発元への確認が必要だったりして時間がかかりそうだと判断した場合は、まずそのことを回答しています。午前中に質問が来ていたのに、夕方になってこれからさらに時間がかかるとは申し訳なくて言えないですから。

馬渡 : ですよね。私もそうです。きっとサポートを担当する人はみんなそのようにしているんじゃないかな。

八巻 : 問題を検証するには現象の再現が必須ですけど、再現環境はどのように用意しているのですか？

馬渡 : サポートの対象となっているOSやサーバー、開発ツール、ブラウザは検証用に各バージョンを用意しているのでそれを組み合わせて作ります。ただ、印刷に関する問題の場合だと、お客さまと同じプリンタを実機で準備するのは難しいので社内にあるプリンタで検証することになります。でも問題の種類によっては、お客さまと同じプリンタドライバをインストールして検証することもありますよ。

武藤 : 私もそうですね、やはりお客さまに納得していただける回答を提供したいので、やれることはとにかく全部やってなるべく再現環境に近づけて検証します。

八巻 : ローカライズや製品開発の作業に加えてのサポートではかなり忙しいんじゃないんですか？

門馬 : 忙しいのは確かに忙しいんですけど、サポートでいただいた課題って製品への貴重なフィードバックになるので、とてもありがたいなぁと思ってます。製品側の不具合なら修正版を提供できますし、回避策をナレッジベースに登録したりとかもできるし。

武藤 : そうそう。実際に製品を利用しているお客さまのご意見は本当にありがたいです。積極的に製品やドキュメントの強化に取り入れさせていただいています。

馬渡 : フィードバックで思い出したのですが、以前担当したあるローカライズ製品のサポートで、問題の検証を進めるうちに日本のあるメジャーなメーカーのプリンタの場合に、製品側からプリンタの解像度がうまく取得できていないことが分かったんです。別の関数を使うと大丈夫なのですが、その時に製品内部で使われていた関数だと、解像度が正しく取得できないんですよ。なので、日本のプリンタメーカーのシェアを表わす資料を作り、メーカーごとの検証結果に添えて開発元に提示しました。一番メジャーなメーカーでこのように解像度が正しく取得できないから別の関数を使うようにしてほしいと要望したんです。それで仕様変更をしてもらったことがあります。

八巻 : それは貴重なフィードバックでしたね。そういった製品の不具合や仕様の問題がサポート業務で見つかったときに、早く対応できるのも開発チームがサポートを担当しているからこそできることですね。

文章だけのやり取りの中に、真の課題を見つけるための洞察力

八巻 : ところで、テクニカルサポートはメールで行われますが文章でのやりとりには独特の難しさがありますよね？そのあたりで何か工夫しているところとかありますか？

馬渡 : そうですね、いただいた質問だけではお客さまが本当に実現したいことを把握できないことがあるので、回答を作成する前にまず履歴を見るようにしています。以前にもサポートを利用されたことがあれば、やり取りのなかでどういうアプリケーションを開発されているのかといった背景が少しわかるので。

門馬 : 私も履歴は見ますね。問題そのものとは別のところでも参考になりますよ。たとえば、前回の質問で解決までに何度もやり取りをしていたとしたら、今度はできるだけ早く解決できるようにしようとか。

武藤 : 私はご挨拶にしても使い古されたような、決まりきった文章は書かないようにしています。私たちのサポート業務は毎日のことですが、お客さまにとってはそうではありませんから。なるべく顔というか人が見えるようなものにしたいと心がけています。

門馬 : あと、メールならではの良さもありますよね。お客さまから再現用のサンプルプロジェクトを添付いただいた場合には、スムーズに検証が行えますし、それをカスタマイズしてお渡しすることもできますから。

八巻 : サンプルコードを提供することは多いんですか？

門馬 : そうですね。文章で説明するより具体的な使い方をイメージしていただけると思っていますので。部分的なサンプルコードを回答メールに直接書くこともありますし、こちらからサンプルプログラムを作成してお送りすることもありますよ。

八巻 : それは喜ばれるでしょうね。開発者はそこからいろいろな方向に派生させられるから。実際、サポートアンケートに寄せられたコメントにも、サンプルコードが役に立ったという声が多いですよ。それにしても皆さん、洞察力を使ってサポートを担当していますね。

馬渡 : 電話と違って直接ことばを交わすわけではないので、より良いコミュニケーションのために、いろいろなことを手掛かりにするようにしているんです。誰が回答するにしても利用者にとってはその人がグレープシティの代表者ですから。

八巻 : なんだか良い話がたくさんでてきましたが、失敗談はないんですか？

馬渡 : そうですね。特別なエピソードではないですけど、以前に終業間際に回答した件などで回避策はあれで十分だったろうかとか、もう少しわかりやすい文章にできたかもしれないとか、後から気になったことがあります。なので、そういう時は意識して心と時間に余裕を持つようにしています。

武藤 : わかります。終業前と昼前は私も要注意なので、送信ボタンを押す前にいつも再確認します。お客さまに今日中に回答をお渡ししなくちゃとか早く回答することのほうに気がいってしまうと、後からああすればよかったとか、こういう方法もあったと考えてしまうことが多いので。

門馬 : 私も急ぐ気持ちに空腹が加わったときは特に（笑）。だからその時は一度送信を保留して、落ち着いてからもう一回見直すようにしています。

八巻 : 話が最初に戻ってしまうようですが、もし、技術サポートの専任だったら、そういうことの連続でお客さまの顔がどんどん見えなくなってしまうこともあるのかもしれませんね。

馬渡 : それはあるかもしれませんね。よく言われることですが、サポートする側は同じ内容の回答をする場合でも、受け取る側は一人一人違うお客さまですから。いつでもお客さまの気持ちに立って対応するようにしています。

八巻 : 今日はWebサイトには載っていないテクニカルサポートについてのいろいろなお話が聞けました。お忙しい中、ありがとうございました。