私は、サンフランシスコに住んでいたことがあって、インフラの勉強していたのですが、当時勢いで応募したインターンに受かり、その後エンジニアとして働いていました。日本人はもちろん一人で、プリセールスからJava のコーディング、テスト、サポート、ドキュメントまでの一連を日本語にローカライズする仕事をしていたのですが、その時の試行錯誤で（失敗もしくは成功から）学んだことをログしていきたいと思います。
当時はほんといろんな面で初心者・経験なしだったので、当たり前のことを書いていたらすみません、、、
英語でサポートを求める時の Tips
当時のタスクの一つとして、QA がありました。仕様でない動作を見つけたら、バグ管理のシステムに入力し、担当の人に修正してもらい、修正を確認するというものです。
当時英語は問題なくできていたのですが、やはり「説明」となると急にハードルが上がりました。始めは、ほんと何にもQAに関する知識もなかったので、一生懸命状況を文章で説明しようとして、一つのチケットを出すのに２時間ぐらいかかりました。笑 特に、始めはインターンとして参加していたので、「書き方がすごく悪いと、こいつできないやつだと思われる」という恐怖心もありました。
その後何週間か経過して、他の人が出したチケットを管理システムから沢山あさって勉強しました。そうするうちに自分のテンプレート見たいなものが出来上がり、そこからだいぶ早くチケットが書けるようになったので、うろ覚えですがここに書いておきます。
その１：自分のしたい事と問題を簡潔に説明する
英語は、短くわかりやすくシンプルに説明することは非常に大事です。私は、なるべく自分で作ったテンプレートに当てはめて、自分のやろうとしている事と発生した問題を説明するようにしていました。
I tried to $自分のやりたい事 however $起こった問題.
自分のやりたい事の例
I tried to browse my upload history on History page....
「履歴のページからアップロード履歴を見ようとしましたが」
Browse を使うときは「どこで」"on ~" というのを忘れずに！I tried to change one of user's permissions from "User" to "Admin"...
「あるユーザーの権限をユーザーから管理者に変更しようとしたのですが」
Change を使うときは 「AからBに」というように、どのように変更したのかがわかるように "from A to B"を使います。I tried to upload a configuration file from my machine to /conf via SSH....
「設定ファイルをSSHを利用して自分のマシンから/confにアップロードしようと思ったのですが」
upload や download を使うときも From A to B、そしてどうやって転送したのかも解決のキーになります。
起こった問題の例
It's loading forever.
「ロード中から画面が変わらない」It seems like it's failing.
「どうやら失敗したようだ」
"It seems like" は非常に大事な表現です。自分の操作ミスか、バグなのかがわからないときは、よく使います。I got a following error message.
「下記のようなエラーメッセージが出ました」
これも便利です。自分で無理にエラーを説明しようとせずに、そのままエラーメッセージを貼り付けちゃいましょう。I am unable to save it.
「保存できません」
I am unable toも便利な表現です。動詞をくっつけるだけで完了です。
余裕があれば、"Could you please look into this?" とかつけるとよりいいイメージを与えると思います。
上はあくまでもテンプレートです。一行で説明できない時もあると思うので、必要に応じて増やしてもいいともいますが、「何がしたいのか」「何ができないのか」に集中して書くと良いと思います。
その２：環境を説明する
問題が起こった条件を説明する必要があります。条件は、文章にすると読みにくいので箇条書きにしていました。一例を書いておきます。
Environment
OS : macOS Sierra 10.12.6
Processor : 2.5GHz Intel Core i7
Memory : 16 GB 1600 MHz DDR3
File Size : 1GB
Browser: Chrome version: 59.0.3071.115（Official Build） （64 bit）
もし、チケットを出したい製品やサービスの公開されている Q&A コミュニティやサポートチケットがあれば、他の人がどういう風に質問しているかを一度見てみるのもいいと思います。そこからサポートを受けるのに必要な情報を見いだせることもあります。私は、結構こんなのいらないだろうっていうような情報まで書いていました。英語でサポートチケットを出すときは、時差もありますから、なるべく次の日までに解決につながる回答が得られるように必要な情報を始めのチケット起票の時にはっきり明記する必要がありました。
その３：起こった経緯を説明する
ここもやはり文章で説明しようとすると、and や then で繋がれた短い文章が連なってしまうし、時系列（過去形と過去完了とか過去進行形）を正しく使っていないとわかりにくいので、番号付き箇条書きにしていました。サポートの地域によっては、サポート担当も英語が第二外国語であることもあるので、番号付きの箇条書きだと間違いが少なかったです。
Procedure
#1 : Go to History page
#2 : Click on "Browse History"
#3 : The loading icon is shown more than 5 min.
もうお気づきだと思いますが、この方法だと全て現在形で大丈夫＆主語がいらないので簡単に伝えることができます。
もし、箇条書きの最後の文で、問題が伝わらない場合、以下の方法で自分が期待する動作を補足しておくとよりわかりやすいし、フィーチャーリクエストとして考えてくれるかもしれません。
Expected : My upload history to be shown immediately after clicking on "Browse History".
自分が試したことも補足として入れることができます。
What I've checked: looked into logs but it didn't seem to have any errors after clicking on "Browse History".
「ログを確認したが、「履歴を見る」のクリック後にエラーが起こったようには見えなかった」
もちろんスクリーンショットやログを添付するとよりわかりやすいと思います。
あまり自分で解決しようとしないこと。説明が増えると、よりわかりにくくなることもあります。
その４：最後に
最後にどんな助けが必要なのか一言足しておきます。
Could you tell me what is wrong here?
Is there any better way to do this?
Could you help me to resolve this issue?
Could you tell me how to do this?
Could you please help me out?
などです。
最後に "Thank you" とか "Cheers" とか "Looking forward to hearing from you" とかつけるのは、いくらサービスを買ってる側としてもマナーだと思います。こういう一言で、世の中はよくなるものだと思いますw
まとめ
少しは役に立つものだと嬉しいです。箇条書きは本当にわかりやすいし書きやすいので、慣れてくるとバンバン使っていました。サポートチケットを出す文章に時間をかけていると勿体無いので、あくまで簡潔に、エッセイのような英文を作らなくても、相手に要点が伝わればオッケーなのではと思います。