海外製品サポートに英語で問い合わせるときのコツ

こんにちは、hachi8833です。今回は英語で製品サポートにフィードバックするときのコツをご紹介します。みなさんもぜひ挑戦してみてください。ここでご紹介するテクニックは、通常のライティングはもちろん、Google翻訳などの機械翻訳を併用するときにも役に立ちます。

本記事は以下の3つを念頭に書かれています。

• 日本語から翻訳しません
• きれいな英語を目指しません
• 伝わる英語を目指します

英作文と聞いて怖気づく方も多いかと思いますが、ご心配なく。大半はコツを頼りに書けます。

むしろ日本語でフィードバックするときと同様の気配りが重要ですし、本記事では英語そのものより日本語のライティングに力点を置いています。

はじめに

サポート担当者が知りたいのは、ずばり「このフィードバックは採用していいのかどうか」と「誰に転送したらいいのか」です。これ以外にないと言ってよいでしょう。

サポート担当者がこの2つについて楽に判断できるように書いてあげるのが、究極のコツです。

その他の心がけについても以下にまとめました。

ポイント	説明
楽して書く	苦労するのは目的ではありません
大事なことを先に書く	細かなことは下の方に書きましょう
なるべく短く書く	残念ながら、たくさん書くほど最後までちゃんと読んでもらえません
相手を動かすように書く	サポート担当者が読んで行動を開始してくれることが重要です
英文で頑張りすぎない	少々間違っていようがサポート担当者は気にしません

参考: 英語でのフィードバック系文書作成の難易度

英語でのフィードバック系ライティングを思いつく範囲でおおざっぱに分類すると、以下のような感じになります。下に行くほど難易度が上がります。

難易度	種類
低	製品のバグ情報の報告
低	製品への機能追加リクエスト
中低	GitHub issueやStackoverflowへのコメント追加
中低	GitHub issueやStackoverflowのエントリ作成
中	GitHubなどへのプルリクエストやマージリクエスト
中高	仕様への提案・フィードバック（W3CやUnicodeコンソーシアムなど）
高	英語圏の特定顧客へのフィードバックや提案
超高	英語圏の特定顧客へのお詫び
超超高	英語圏の不特定多数の顧客へのお詫び

今回は難易度:低の「機能追加リクエスト」に絞ります。かつ、メールではなくフィードバックフォームで送ることを前提とします。

こうした製品フィードバックなら自分の英文をネットで他の人に見られることもないので、内気な方でも割と始めやすいと思います。

英文フィードバックを書いてみる

サンプルの日本語

ここでは、Slackの/remindの日付指定方法が英語式なので、英語がわからないと「前置詞はどれだったけ」といちいち思い出さなければならず、不便だから改善して欲しいというリクエストを出そうとしています。

以下は説明のために日本語で書いてみたフィードバックです。

件名: /remindにDatePickerを

お世話になっております。BPSのhachi8833と申します。Slackのことでお願いがございます。
英語がわからないと、/remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。

どうぞよろしくお願いします。

それではやってみましょう。

1. タイトル冒頭に「Request:」とか「Bug:」などと書くと親切

状態	文例
変更前	/remindにDatePickerを
変更後	リクエスト:/remindにDatePickerを
英文化	Request: DatePicker option for /remind

フィードバックフォームの構成にカテゴリの項目がなければ、タイトルの冒頭で「Request:」や「Bug:」フィードバックの種類を表すようにしましょう。カテゴリのチェックボックスなどがあっても、こうして書いてあげればサポート担当者が助かります。

日本語でフィードバックするときにも使える方法であり、英語の問題というよりも気配りの問題です。

なお、コロン「:」の後ろにはスペースを1つ置くのが普通ですが、なくてもだいたいわかります。

2. 前置きや名乗りは不要

状態	文例
変更前	お世話になっております。BPSのhachi8833と申します。Slackのことでお願いがございます。
変更後	【削除】
英文化	【不要】

こんな前書きは不要です。ざっくり削除して、上の「いきなり要件を書く」を実践しましょう。

• たとえばstackoverflow.comでは、誰もこのような前書きを書いていません
• 名前はフィードバックフォームに入力すれば済みます

3. 頼み事は最初の文に書く

英文に限りませんが、「概要を先に書く」「細かいことは後に書く」とすることでメッセージがうんと伝わりやすくなります。

英語がわからないと、/remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。

日本なら「時を表す前置詞が何だったっけなどと思い出さなければならず」といった程度の走り書きでも、勘のいいサポート担当者なら「あーなるほどね」と察してくれるかもしれません。察しのいい人に感謝です。

しかしフィードバックの冒頭で「あれが困る」「ここが困る」といきなりくどくど状況を説明したところで、たいてい「んー、要するに何が言いたいんですか？」（What do you want?）と聞き返される可能性が高いでしょう。

コツ: 「ここが困る」を「これが欲しい」に変えてみる

/remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければならず、

これは自分が困っている具体的な状況を伝える文ですが、果たしてこの文は必要でしょうか？たとえばですが、以下のようなDatePicker的なオプションで日付を指定できれば十分ではないでしょうか。

それなら「DatePickerを付けてください」と最初に書けば相手に即伝わります。もちろんそのためには、「DatePickerが使えればよい」ことにこちらが気づく必要があります。

状態	文例
変更前	英語がわからないと、/remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。
変更後	Datepickerを付けてください。 英語がわからないと、/remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。

このような感じで、「これが欲しい」を明確に伝える文を最初に置きましょう。

「ここが困る」という漠然としたリクエストで「そのぐらい察してくれよ」などと解決を相手に丸投げしても、期待したとおりの修正にならない可能性の方が高くなるでしょう。

4. 日本語の段階でなるべく簡単な文にしてみる

「Datepickerを付けてください」に続く2文目を、もっと簡単にできないでしょうか。

英語がわからないと、/remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。

上の文で本当に伝えたいのは、「remindオプションは日本人にとって不便だ」ということであり、特に「不便だ」の部分です。

「時を表す前置詞が何だったっけなどと思い出さなければならない」うんぬんは副次的な情報であり、慌てて伝える必要はありません。

この文をそうした観点から2つに分けてみましょう。

状態	文例
変更前	英語がわからないと、/remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。
変更後	英語がわからないと、/remindオプションが使いにくいです。 /remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければならないからです。

5. 接続詞を外し、単文に分割してみる

文章から接続詞を外して単文に書き換えると、ぐっと英文にしやすくなります。以下に例を挙げます。

becauseを外す

分割した2文目が「〜からです」で終わっていますが、これは要注意です。

日本人がよくやってしまう間違いで「結果を書かずにbecauseだけで文を書いてしまう」というのがあります。日本語では「〜だから。」「〜なので。」という断片的な書き方ができてしまいますが、英語のbecauseは「結果 because 原因.」のように全体が文になっていないと使えません。
また、「Because 原因, 結果」のようにbecauseを文頭に置くことも避けるのが普通です。
becauseの使い方に自信が持てないなら、使わない方が安心です。

実は「〜だから。」「〜なので。」という表現は、ほとんどの場合日本語の調子を整えるためのものでしかありません。やってみればわかると思いますが、こうしたbecauseっぽい表現は日本語の段階で削除しても全然問題ありません。

この「思い出さなければならないからです」は、思い切って単なる「思い出さなければなりません」に変えてみましょう。

状態	文例
変更前	英語がわからないと、/remindオプションが使いにくいです。 /remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければならないからです。
変更後	英語がわからないと、/remindオプションが使いにくいです。 /remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。

ifやwhenを外す

少しましになりましたが、まだまだ変えられそうです。

「英語がわからないと、」のままでは、ifとかwhenなどの条件節として書かなければならないような気がしてしまいますが、そんなことはありません。

「英語がわからないと、」を「英語がわからない人にとって」に大胆に書き換えてしまうテクニックがあります。これならifもwhenもいらなくなります。

状態	文例
変更前	英語がわからないと、/remindオプションが使いにくいです。 /remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。
変更前	/remindオプションは、英語がわからない人にとって不便です。 /remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。

付加情報を削除する

ここまで文を書き直してみると、「時を表す前置詞が何だったっけなどと〜」という後半の文が単なる付加情報でしかないことに気づくかもしれません。思い切って後半の文を削除してしまいましょう。

状態	文例
変更前	/remindオプションは、英語がわからない人にとって不便です。 /remindオプションを使うたびに時を表す前置詞が何だったっけなどと思い出さなければなりません。
変更後	/remindオプションは、英語がわからない人にとって不便です。

あきれるほどに日本文が簡単になりました。この段階で英語にしてもよいくらいです。

オプション: 無駄な副詞を削除する

以下は、余裕があるときにやってみる程度で構いません。

日本語の文章で、さして重要でもない副詞や副詞句で不必要に文章を飾ろうとしているのをよく見かけますが、英語の副詞は、本当に副詞として必要でなければ使いません。

これは英語が偉くて日本語がダメなどという話ではなく、英語は日本語ほど副詞で文を飾ろうとしないというだけのことです。
英語は英語で「形容詞&形容詞」のような形でゴテゴテと飾りがちですし、一方は不要としか思えないことが多々あります。

たとえば次の日本語の副詞/副詞句は、ただの念押しに使われていることがほとんどで、実はなくても何の問題もありません。

• しっかりと
• ちゃんと
• きちんと
• 積極的に
• 徹底的に

こうした無駄な副詞は日本語の段階でじゃんじゃん取っ払いましょう。

オプション: うまい名詞や形容詞に置き換える

そのうえで残った必要な副詞は、可能であれば形容詞や名詞に変えてみましょう。

原則: 日本語の副詞は、英語では形容詞や名詞にするとうまくはまりやすい傾向があります。

先の例で言うと、「英語がわからない人」は「非英語話者」（non-English speaker）とすると英作文がさらに簡単になります。

状態	文例
変更前	/remindオプションは、英語がわからない人にとって不便です。
変更前	/remindオプションは、非英語話者にとって不便です。

このレベルまで絞りに絞って単文にできれば、英語にする作業はとても簡単になります。
たとえGoogle翻訳のような機械翻訳にかけたとしても、おかしな訳になる可能性をうんと下げることができます。

6. コロンと箇条書きで楽々書ける

コロン「:」を使うと、文章がとても書きやすくなります。こんな便利な記号を使わない手はありません。

たとえば理由を書きたいとき、以下のように書く方がbecauseを使う複文よりもずっと楽ですし、意味がぼやけることもありません。

Reason: /remind option is difficult for non-native English speakers.

箇条書きも非常に便利です。箇条書きにすれば単文で済みますし、文章の接続で頭を悩ませずに済みます。コロンと箇条書きの合せ技を使えば以下のような感じに書けます。

Reason:

• English date/time style is unkind to non-native speakers
• More options are preferable for improving your products
• I love your products and expect the improvements

なお、箇条書き末尾にピリオドを付けるかどうかは、どちらかに統一しておけばOKです。

7. 画像やスクリーンショットで的確に伝える

よく言われることですが、言葉を尽くして説明するより、1枚の画像、1枚のスクショの方がはるかに的確に相手に伝わります。

ポイントは、見て欲しい箇所に印をつけることです。人間の認知は「どこにフォーカスするか」を探すのに最もエネルギーを使うので、お互いの時間と労力を節約するためにも、ぜひ印をつけるようにしましょう。

参考: 最近のMacのプレビュー.appで使える明暗ベースのハイライト機能（下図）は、赤で囲むよりも楽に該当箇所を見つけられるのでおすすめです。

参考: 「プレビュー」で PDF に注釈を付ける

8. 締めくくりは「Thank you,」で十分

英文メッセージの最後は「Thank you,」で締めくくれば十分です。

これは別に「ありがとう」と言いたいわけではなく、日本語の「よろしくお願いします」と同じような位置づけです。日本語でも二言目には「よろしく」が連発されますが、英語でも似たような事情で「Thank you,」が連発されています。

「Sincerely yours,」だの「Best Regards,」はお客様向けの相当改まった言い回しです。
「Best,」とか「Regards,」ならもう少し軽くなります。

なお、いずれの場合も最後はカンマ「,」にするのが習慣です。

参考: 最終的な英文

参考までに、さらに多くの修正を経た最終的な英文フィードバックを以下に示します。DatePickerか、さもなければstrftime(3)的なオプションでもよいと伝えています。

件名: Request: DatePicker option for /remind

I'd be glad if you would add a "DatePicker" widget or some other Unix-like date options such as strftime(3) to /remind.
Reason: current inline /remind options are English style and unkind to non-native English speakers.

strftime: http://man7.org/linux/man-pages/man3/strftime.3.html
Thank you,

「I'd be glad if you would〜」は、ある程度丁寧にお願いするときに便利な表現です。

まとめ

• タイトルに「Request:」とか「Bug:」などを示す
• 前置きは不要
• 「何をして欲しい」のかを最初の文で伝える
• 日本語の段階で文を簡単にする
• 接続詞や副詞句を外して、単文に分割してみる
• コロンと箇条書きを積極的に使おう
• 画像やスクリーンショットを効果的に使おう
• 最後は「Thank you,」で締めよう

当然ですが、英語圏のサービスや製品の提供元も常に適切なフィードバックを欲しがっています。製品やサービスが使いにくいと不満をこぼすばかりでなく、本当に簡単で構いませんので製品にフィードバックすれば、お互い幸せになれるでしょう。

初めてフィードバックするときは誰しもどきどきするものです。でもフィードバックして相手から返信をもらい、実際に期待どおりに機能が改良されたりバグが修正されたりすると、一気に楽しくなってくるものです。

慣れてくれば、本記事のような面倒なことをするよりも、GitHubのissueあたりから言い回しをいただいて書くほうが早いでしょう。

ぜひみなさんも、英文フィードバックにはまってみてください。

追伸: Google翻訳について

以下は私の個人的な見解です。

Google翻訳の品質が急上昇したことが各所で話題になっていますので若干補足します。

今回の品質改善は、主に「日本語としての見た目が自然・滑らかになった」ということであり、翻訳としての精度向上については別途検証が必要です。むしろ、日本語が自然になった分、意味が逆さだったりおかしかったりしても気づきにくくなってしまうリスクが高まるでしょう。

ごく簡単に見た限りでも、まだ1つの文が長いほど内容が不正確になりやすくなっています。また、長い文章では後ろに行くほど翻訳の質が落ちる傾向があります。一般ユーザーの多くは訳文の最初の方だけチェックして「品質が上がった」と盛り上がっている可能性が高いことは容易に想像がつくので、皆様は原文訳文を最後までしっかり読み込んでチェックするようにしましょう。

翻訳結果を自分でチェック・修正できないのであれば、闇雲に機械翻訳をかけただけで本番や納品物に使うのは当分危険と思われます。

特に、機械翻訳だけで翻訳したことを明示せずに黙ってドキュメントを公開すると、たとえ翻訳の品質が完璧だったとしても、後で何かのついでに発覚した場合にネットの炎上を招き、サービスや会社の信用を大きく傷つける可能性があります。むしろこちらに注意する必要があるでしょう。

こうした事情は自動車の無人運転技術とも似ています。人間が関与せずに完全に手放し運転できるようになるには、技術以外の運用や社会的な受け入れ体制の構築など多くの問題をクリアする必要があるでしょう。

逆に、たとえば本記事でご紹介したように日本語の段階で文を洗練させ、簡単にすることで、たとえ機械で翻訳した場合にも意味がぶれにくくなることが予想できます。前述の点に注意すれば、「運用でカバーする」のは非常によいアプローチだと思います。

機械翻訳に勝手に期待して痛い目を見るより、機械翻訳の特性を活かすために「機械翻訳にかかりやすい明快な日本語を普段から書く」ようにする方がずっとメリットが大きいと考えています。

個人的には、むしろ今後の日本語は機械翻訳に最適化する形で変化していくのではないかと予想しています。