この記事の目的

IT関連で仕事をしていると、技術的な質問・トラブルの解決のために、いわゆるテクニカルサポートやカスタマーサポートに、問い合わせをすることが、それなりに出てくると思います。
これは別に開発者でなくても、何かアプリケーションやシステムを触っているなら、経験することだと思います。
あるいは、仕事ではなく、プライベートで使用している製品やサービスでも、問い合わせが必要になることも、しばしばあると思います。

そういった状況で、

速やかに
ストレスを感じずに
より良い解決策を得られる

には、どうしたら良いか、ということを伝えたくて、この記事を書きます。

最初に自己紹介

私は、いわゆるIT系企業、特に世間一般でいうと「外資系IT企業」のカテゴリーで、サポート関連の仕事をしています。
「関連」というのは、質問に回答するだけでなく、サポートの仕組みを作る・管理する、サポート人員の教育などもスコープだからです。

ですから、この記事は、サポート視点で書いている部分が少なからず出てきます。
ただし、できるだけ、サポート側の都合を一方的に押し付けるようなことは、書かないようにするつもりです。
（もし、そう感じられる部分があったら、遠慮なく教えてください！）

それは、問題がサポートにきちんと伝わり、速やかに適切な回答を得られる（サポート視点では”回答できる”）ことは、質問するユーザーにとっても、対応するサポートにとっても、メリットがあるからです。
やや使い古された言葉で言えば、Win-Winの関係、ということですね！

ちょっと長い文章になるかもしれませんが、参考にしていただければ幸いです。

質問する上でのTips

本題の、サポートに質問する上でのTipsや、こうすると良いですよ、って話を書いていきます。

1. 具体的に書く

細かいノウハウはありますが、ここが一番重要です。

これは実際に、ちらほらある問い合わせ内容なのですが、

助けてください。

困ってます。

動きません。

「問い合わせ本文、これだけ……？」
みたいなケースが、本当にあります。

そうすると、サポート担当者は「どう困っていますか？」「何が動きませんか？」等、確認のための返答をします。いわゆる「ヒアリング」です。

質問する方がそれで良ければともかく、サポートに問い合わせをするということは、何かしら困っていると思います。その問題ができるだけ早く解消されるほうが、問い合わせをする人にとっても、メリットは大きいのです。
そうであれば、きちんと情報を付加したほうが、やりとりの回数を減らすことで、早期の解決が図れます。

この場合に、重要な情報は、製品のトラブルであれば、

どの製品・サービスで
いつ（日時） ← Webサービスへの問い合わせでは重要です
どのような環境で（ソフトウェアならOS、あとはWebサービスならブラウザ名など）
どのような操作をしようとして
どうなったか（エラーメッセージ等があればそれも）
求める結果はどのようなものか

あたりを明確にしておくと、かなり話が早いです。

あるいは、製品の仕様や、使い方に関する問い合わせなら、

どの製品・サービスで
どのような使い方をしたいのか
その上で、具体的に何が知りたいのか

という感じでしょうか。

目的も重要です

どちらのケースでも【本来の目的が何か】は、重要になってくることがあります。
たとえば”ログインできない”とかなら、とりあえずログインできるようにするのが目的だろうということは、推測がつくので、そこまで重要視する必要はありません。

しかし、製品やサービスによっては、「目的のために、より良い回答や使い方」を提案できる可能性があります。
たとえば、

ダウンロードできるレポートの集計範囲が月次しか表示できません

という質問だけだと、

ダウンロードできるレポートの集計範囲が月次しか表示できません

申し訳ありませんが仕様です。

で終わってしまいます。
ところが、目的がきちんと記載されていると、

日時の稼働状況が見たいのですが、ダウンロードできるレポートの集計範囲が月次しか表示できません

ダウンロードできるレポートは月次集計のみですが、設定オプションから当日の稼働状況をメールで通知する機能があります。

というように、回避策（workaround）が提示できるケースがあります。

これ以外にも、「そのような使い方は、システムが不安定になるリスクがあるので、～～という別の方法をとってほしい」のように、ユーザーが不利益を被るリスクを回避できる情報が得られることもあります。
ですから、サポートに問い合わせをするとき、どのような目的・背景で問い合わせをしているのかを、共有しておくことで、よりBestに近い回答が得られる可能性を高めることができます。

2. わかる範囲で切り分けをする

たとえば、使用しているWebサービスで、何か変な動作をしているとしましょう。
その時に、可能であれば、質問する前に、

別のPCで試してみる
同じPCの別のブラウザで試してみる
別のネットワーク環境から試してみる
（同じサービスのユーザーが身近にいれば）その人のアカウントでも再現するか試してみる

これらを試してみて、その結果も書いてみてください。
結果が最初の問い合わせの際に記載されていると、かなり早期に精度の高い回答が得られる可能性が上がります。

これは、「複数の環境にまたがっているのか、特定の環境に依存するのか」「すべてのユーザーで発生するのか、ユーザー固有の問題か」がわかっていると、サポート担当者が類似事例・既知の問題などを絞りやすくなるからです。

このように書くと、「その情報が欲しいのは、サポート担当者側の都合でしょ？」と思われるかもしれません。確かに、サポート担当者の都合とも言えます。

ですが、どのような経緯をたどるにしろ、サポートを行う上では、これらの調査は大抵の場合は必須になります。
ですので、切り分けがされていない質問が来た場合、上記のような質問をして、ユーザーの回答を待つ、ということになります。

つまり、切り分けなしの質問が来ると、1往復分、質問と回答の手間やリードタイムが発生します。
これは、サポート担当者にとってもメリットがありませんが、ユーザーにとってもメリットがないはずです。解決まで余分に時間がかかるので。
そう、誰も得しないのであれば、あえて切り分けをせずに、いきなり質問する意味はないですよね！

とはいえ、これは「できれば」ですし、十分な切り分けができていなければ、結局は、「切り分けのための、やりとり1往復」が必要になることはあります。完璧を期す必要はありません。
ただ、問い合わせをする際、過去に問い合わせをしたときに、どのような「切り分け」があったかを意識すると、必要な粒度や、試すべき内容が、だんだんわかるようになるのではないでしょうか。

3. 画面コピーなどがあれば添付する

特にソフトウェア・Webサービスでは、エラーが出ている画面の情報は、状況を把握する上で、非常に重要です。

Windows PCなら

Windowsキー + PrintScreenキー

Mac OSなら

Shiftキー＋ ⌘(Command) キー＋ 3 (数字の3)キー

Linuxデスクトップなら

Shiftキー＋ PrintScreenキー

これで現在の画面キャプチャーをファイルとして保存できます。何かあった時、すぐに押せるよう癖をつけておくと、トラブルが起きたときに役に立ちます。

職場のPCなどで、個人情報や機密情報を扱っている場合、画面キャプチャーをそのままカスタマーサポートに送ると、情報漏洩になってしまうことがあります。
そのような画像を送る場合、マスキング（塗りつぶしなど）を、適宜、行ってください。

実際にあった（笑えない）話ですが、Excelファイルのシート上に画面キャプチャーを張り付け、その上に四角形シェイプを載せて、マスキングしたつもりで送ってしまった、というセキュリティ事故事例があります。
Excelファイルのシェイプを消したら、当然、全部見えてしまいます。ちゃんと画像を加工してマスキングしましょう。

4. ログがあればログも送る

Webサービスだとあまり関係ないですが、PCやサーバー上で動くアプリケーションの場合、最初にログを送っておくだけで、かなり話が早く進むケースは多いです。
ログの保存場所や、採取方法はアプリケーションによっても全然違うので、個別の情報は書きません（書けません）が。

むしろ、ある程度熟練したサポート担当者だったり、「よくある事象」だと、質問の内容に不足があっても、ログを見ただけで、担当者が正解にたどり着いてしまう、なんてこともあります。

5. （おまけ）サポート担当者と仲良くなる

大抵のカスタマーサポートやテクニカルサポートでは、内部のルールがあり、サポートはそこから逸脱することはできません。（やってはいけません）
ですが、裏を返せば、そのルールの範囲内での裁量があります。

そして、サポート担当者も人間です。
理想を言えば、聖人君子のように、すべてのユーザー・顧客に、最善を尽くすべき……とは言えますが、実際には、限られたリソース（仕事の時間など）の中で、やりくりをしているので、限界はあります。

そこで、サポート担当者を「喜ばせる」方法を知っていると、サポート担当者側も、「この人には何とか尽くしてあげたい」と思ったりします。
これは断じて 「サポート担当者にへつらってください」ということではありません。 お互いに、手間にならない範囲で、話をスムーズにする工夫をすると、気持ちよく仕事ができる、という方向の話です。

①確認に時間がかかりそうなときは伝える

ログの取得や、画面キャプチャの送信などは、組織や現場のルールで、許可が必要なことがあります。
それで時間がかかってしまうのは、仕方がないことです。

ただ、サポート担当者というのは、だいたいどこでも、「回答までの日数」や「返事を出すまでの時間」を管理されています。ユーザーからの質問が来ていて、回答までの時間が長くなると、システムから催促のメールが来たり、上司から確認されたり等が起きます。

これは、回答をせずに放置してしまう、という事態を防ぐための仕組みなので、仕方ないものです。回答がまったく来ないのは、ユーザーにとってとても困った状況です。

そういう環境で仕事をする中で、ユーザーさんからの「確認しますが、少し時間をください。目安は●●日ぐらいです」といった情報が事前にあると、担当者はそれまで（割と）気楽に待てます。
たとえ上司から「この案件、なんで更新してないの？」と言われても、「ユーザーさんが待ってくれと言ってるからです、●●日が目安になっています」と答えられます。
それが長すぎる期間でなければ、上司さんも「あ、そう。ならいいや」で、だいたい終わります。

この会話ができないと、サポート担当者は、上記の「返事を出すまでの時間」を維持するため、「ログまだですか！画面キャプチャーまだですか！！」と、延々と催促し続けることになります。
上司からも「はやくこれ解決しなさいよ、お客さんともっとコミュニケーションとって」なんて指摘されます。

これは、サポート担当者にとってもストレスですが、受け取るユーザーさんにとっても、嬉しいことはないでしょう？

ですので、時間がかかりそうなときは、目安を先に伝えておくと、サポート担当者が喜びます。

②回答が得られたら「クローズで」と伝える

たいていの（体感ですが、おそらく95%以上の）カスタマーサポートは、問い合わせを「チケット」とか「ケース」とか「イシュー」という単位で管理しています。呼び方は色々ですが、中身は同じなので、ここでは「チケット」と書きます。

通常、ユーザーから最初に問い合わせを受けた時点で、1つの「チケット」が作られます。
あとは、その「チケット」に対して、ユーザーに状況確認などの質問をしたり、何を調べたかの記録を内部向けに残したり、回答したりします。

そして最終的に、「話がこれ以上進まない」状態になると、チケットは「クローズ」されます。「終了する」「終了される」等、言い方は色々ありますが、これも同じです。

「話がこれ以上進まない」は、ポジティブな方向性では「ユーザーに回答して満足が得られた」が理想です。
ただ、それ以外にも「できないと回答し、それ以上進めようがない」とか、「再現できないので」とか、そういった不完全燃焼的な理由で、致し方なくクローズになることもあります。あるいは「ユーザーに状況確認を行ったけれども、一定期間返答がない」等もですね。
ほかには、「それはサポート範囲ではない」「他社製品に由来する問題だとわかった」等の場合も、クローズの理由になるでしょう。

「チケットをクローズしてよい基準」というのは、会社によってかなり違います。ただし、100％ロジカルに判断可能な基準、というのは作れません。

ですから、担当者は結構な割合で、「これでお客様は満足したのかな？別の情報が必要かな？」と考えていることが多いです。
もしかしたら、これを読んでいる方で、サポートに問い合わせて、回答を得られた後、「回答しましたけどどうでしたか？ご不明点とかありませんか？」みたいなメールを受け取ったことがある人、居るのではないでしょうか。
これは、上に書いた「お客様は満足したのかな？」とサポート担当者が悩んでいる合図です。

そこで、回答に満足したら（あるいは満足はできなくても、この話はこれでいいや、仕方ないね、となったら）「本件はクローズでお願いします」みたいに返信に付け加えると、サポート担当者はとても喜びます。

これはサポートをやったことがある人しかわからない感覚だとは思いますが、一般の人が考えているよりも、数段喜びます。そして、そこそこの確率で、「この人はいい人だった」「話を進めやすい人だった」というpositiveな記憶が残ります。
そうすると、次に同じ担当者が当たったときに、「あ、この人には親切に対応しなきゃ」ってなります。本当です。（絶対ではないですが）

「本件はクローズしてください」
→次回以降のサポートで丁寧に対応してもらえるかもしれない魔法の言葉

ということです。

③満足度アンケートは満点からの減点法で

サポートに問い合わせて、チケットがクローズされた後、「担当者の対応はどうでしたか？」的なアンケートが飛んでくることが多いと思います。
これの結果って、サポート担当者にとっては、結構、死活問題です。特に外資系のIT企業（≒海外企業のWebサービスやアプリケーション）のサポートの場合、個々の担当者の評価の平均は、その担当者の業績評価に割としっかり繋がってたりします。つまりお給料やボーナスの上下につながります。
また、全体の平均値は、サポート部署のマネージャーの評価や、サポート部署の予算にも影響します。つまり全体的に、極めて重要な指標なのです。

ところで、このアンケート。だいたい5段階とか10段階の数値などで評価することが多いと思うのですが。サポートに携わる人間として、お願いします。

特に問題がなければ、満点をつけてあげてください。

大切なことなので2回書きました。

というのも、このアンケートですが、アメリカ的な文化で作られています。具体的には「特に問題なければ最高点、問題があればそこから減点」という方式を想定されています。
つまり、担当者の評価平均の目標値は、最高点の8掛け～9掛けか、もう少し高いぐらいが設定されていることが多いです。
たとえば5段階評価だと、平均4.5とかそれくらいが目標値、4切ったらかなり不味い、なんて感じです。

残念ながら（？）多くの外資系企業では、ここで、日本で比較的多い発想……「問題ないから5段階で3」みたいなのは、意識されていません。
すなわち「特に問題ないので5段階で3にします」なんて評価があった場合、評価をつけた側は悪意とかなくても、サポート担当者のメンタルは曇ります。濁ります。 ~~そんな暇なく首が飛ぶこともあります。（雇用関連の法制上、あまりないとはいえ……）~~

そうするともう、負のすれ違いです。

繰り返しますが、サポート担当者も人間です。
「頑張ったのにマイナス評価つけてくる人に、次はきちんと対応しようと思うか」というと……。建前で言えば、それはもちろん、きちんと対応すべきですが。
やはりモチベーションには影響しますし、「社内ルール的にOKな範囲で、手間をかけて便宜を」とは、ちょっと考えなくなってしまうのも、致し方なしです。

逆に、特に問題なければ5をつけてくれる人だ、とわかっていると。
「この人のためにはきちんとやって、きちんと評価して貰おう。やれることはやってあげよう」という、プラスのモチベーションが沸きます。

というのが、サポート側の視点なのです。

もちろん、サポート担当者に瑕疵があれば、きちんと減点してあげてください。それは正当な評価です。
具体的にどう悪かったのか、コメントなどを記載する場所があれば、書いてあげるだけで、サポート担当者は糧にします。 ~~まれに逆恨みするダメな担当担当者もいるかもしれませんが。~~

合言葉は、