結城です。

ここまで、OSSへのフィードバックをやってみようとした時に躓きがちなポイントについて、フィードバックするトピックの見つけ方、報告に盛り込むとよい内容、その情報の送り届け先の選び方の知見をそれぞれ述べてきました。

ところで、それらの技術的な内容以前のハードルとして、言語の壁という物もあります。実際にOSS Gateワークショップでも、フィードバック内容をまとめた後、英語でそれを書き直すという段階で手こずっておられる方がかなり多い印象があります。

ITエンジニア向けに「こういう英語表現を覚えよう」という情報を紹介する記事は時々見かけます。ですが、ワークショップでビギナー参加者の方が英語を書くのに苦労している様子を実際に見ている印象では、必要なのはそういった記事で紹介される「実際の現場でよく使われる単語や熟語の情報」ではなく、「実際の現場で英文を書く時に行われる考え方の解説」の方であるように筆者には感じられました。

そこで今度は、OSSへのフィードバックを英語でやる時の考え方に焦点を当てて解説してみます。対象読者は、英語に苦手意識のある方、中学高校の英語の授業で英作文はした事があるけれども自分でゼロから何かを説明する英文を書いた事はない方、といったレベル感を想定しています。

「日本語の文章を英語に変換する」のではなく、「同じ事を説明する英語の文章を作る」という考え方をしよう

英作文に不慣れな人は、まず「日本語の文章」を考えて、それを「対応する内容の英語の文章」に変換するものだ、と考えがちなのではないでしょうか。

いきなり言ってしまうのですが、それは無理なので、潔く諦めてしまいましょう。

例えば有名な話ですが、外出先から帰宅した人が在宅していた人に言う「ただいま」や、それに応えての「おかえりなさい」は、英語に翻訳しようがないと言われています。そもそも欧米には「帰宅した時に挨拶を交わす」文化が無いため、そういう言葉どころか概念が無いのだそうです。この例を一つとってみても、「日本語で書いた文章をきっちり英語に変換しきる」という事は根本的には不可能だという事が分かるのではないでしょうか。

ではどうするのかといえば、「伝えたい内容、対象」そのものの方に立ち返って、それを表現する英語の文章を考える、という事になります。

例えば、ここに1本のペンがあるとします。その状態を英語で表すには、どんな文章が考えられるでしょうか？

• This is a pen.（これは一体何であるか？という点に着目）

• There is a pen.（どこにあるか？という点に着目）

• I have a pen. / This is my pen.（誰の物か？という点に着目）

「これはペンです」という日本語の文章を先に与えられていれば、「This is～」という文しか思いつかないかもしれません。しかし事実の方に焦点を当てると、色々な角度から表現できるという事が分かるのではないでしょうか。

「すでに書いてしまった日本語の文章」に囚われないで、「目の前にある物」や「目の前で起こっている事実」の方を意識するという事を、常に心がけるようにしてみて下さい。まずはそれが最初のステップです。

平易に言い換えてみよう

この事を考える上で参考になる物として、「やさしい日本語」（※リンク先はPDF）があります。

やさしい日本語とは、

• 海外からの旅行者がよく訪れる観光施設や、移民者が手続きに来る市区町村の役所などにおいて、日本語が不得手な人が読む事を想定して

• 複雑な表現や難しい単語をなるべく使わずに、平易な単語や単純な文の書き方を心がけて

書かれた日本語の文章の事を言います。日本語ネイティブスピーカーではない人だけでなく、子供や高齢者、障害者など幅広い層にとってもメリットがあるという事で、近年注目されてきているそうです。

「やさしい日本語」を書くためには、同じ物事をより平易な表現で言い換える必要があります。例えば、

訪日観光客で洛中・洛外は連日溢れかえっており、史跡や寺社仏閣が観光資源として有効に機能していて、誇らしい。

という文章は、

• 多少ニュアンスは変わったとしても各単語を平易な表現に言い換える。

  • 訪日観光客→他の国から来た人達

  • 洛中・洛外→京都の町

  • 連日溢れかえり→毎日たくさんいる

  • 史跡や寺社仏閣→古い建物、お寺、神社など

  • 観光資源として機能→見どころになる

• 接続された文を短い文に切り分ける。

• リズム感や格好良さを優先していたトリッキーな語順を整理する。

• 省略された主語（行為の主体）を補う。

といった加工をする事で、

京都の町には毎日、たくさんの人達が他の国から来る。

古い建物、お寺、神社などが見どころになっている。

私はとてもうれしい。

のように言い換えられるでしょう。

英語が不得意な人は、英語の文法にも単語力にも自信が無い事が多いと思います。しかしその一方で、日本語はそれなりに使えるという自信が（無意識にでも）あるはずです。そのため、自分の持てる限りの日本語力を駆使して考えた日本語の文章には、難しい単語や言い回しが無意識のうちに入ってしまいがちです。日本語力と英語力の間にギャップがあるために、日本語の方で選んだ単語や表現に対応する英語の言い方が分からなくて、手が止まってしまう……これこそが「英語になると途端になにも書けなくなる」事の正体です。

なので、日本語の文章を英語に訳せる自信が無い場合、その前段階のワンクッションとして、まずは自分が書いた文章を「やさしい日本語」に書き直すようにしてみて下さい。そうすればきっと、次のステップにもスムーズに進めるようになるでしょう。

「SVOの平叙文」で考えよう

英語の話に戻ります。

中学高校までの英語の授業では様々な文法や単語を教わりますが、こと「OSSへのフィードバック」という場面で言うと、実際に使う知識はその中のごく一部です。特に文章の形は、基本的にS（subject：主語）-V（verb：動詞）-O（object：目的語）の形式で書くと考えていいです。これは「私は○○をした」「あなたは××である」のような単純な文章、いわゆる平叙文という形式です。

日本人が英文を書くと受動態（受け身の形、主語が何々されるという文）が多くなりがちだ、とよく言われます。それは、こなれた日本語の表現では主語が省略されがちで、主語が省略された文章をそのまま直訳すると、必然として受動態にせざるを得ないからです。

ですが、「誰が」何をしたのか、「誰が」どうなったのか、という事を省略しないようにすれば、文章は自然とSVOの文型になります。

「誰が」を書いたら主語が「I（私は）」「You（あなたは）」ばかりになってしまう？　それは、「主語は人間だ」という無意識の思い込みがあるからです。英語では、物でも現象でも概念でも普通に主語になります。主語をどう書くかに迷ったら、一旦あらゆる物事を擬人化してみて下さい。

例えば、

Firefoxの法人向けポリシー設定で、検索候補の表示を無効化するSearchSuggestEnabledをfalseに設定しても、単独のWeb検索バーでは検索候補が表示され続けてしまう。

という不具合を報告したいとします¹。これはどう言い換えられるでしょうか。

日本語での省略された主語は「私が（～を設定した）」ですね。しかし、ここには「Firefox」や「SearchSuggestEnabledという設定項目」、「その設定の値がfalseである状態」、「単独のWeb検索バーというUI部品」「検索候補」といった登場人物達がいます。ということでこれらを主語にしてみると、例えば以下のような表現ができます。

• 「設定の値がfalseである状態」を擬人化して主語にする：

• SearchSuggestEnabled=false does not hide search suggestions on the search bar.

（SearchSuggestEnabled=falseという状態が、検索バーの検索候補を隠してくれない）

• 「検索候補」を擬人化して主語にする：

• Search suggestions on the search bar are visible with SearchSuggestEnabled=false.

（SearchSuggestEnabled=falseという設定の時に、検索バーで検索候補が見える）

どうでしょう。このくらいの英文なら、自分にも書けるような気がしてきませんか？　これに

• There is an enterprise policy SearchSuggestEnabled.

（～という法人向けポリシー設定があります。）

• The location bar shows search suggestions. The web search bar also.

（ロケーションバーは検索候補を表示します。Web検索バーも同様。）

などの文を添えれば、上述の例で報告したかった内容は言い表せたと言っていいでしょう。

いかがでしょうか。長く複雑な構造の文章で表されていた内容であっても、一文一文を細かくぶつ切りにして、それぞれに主語を与えてSVOの形で書き直してみれば、こんな要領の平易な英語の文章で表現できるのです。

ソフトウェア開発の場面であれば、「モジュール名」「メソッド名」「変数名」「ソースコード中の行番号で示した行」などなど、他にも色々な物が「登場人物」になり得ます。皆さんも、名前が付いている物は片っ端から主語にしてみて下さい。

ありふれた動詞や形容詞を使おう

文章をぶつ切りにしてSVOの文型に揃える事には、同時に、使う動詞や形容詞を辞書から見つけやすくなるという効果もあります。というのも、和英辞書で動詞や形容詞を調べると例文は大抵「誰々が何々をする」のようなSVOの文の形になっているからです。辞書で見つけた例文をそのまま使える、これは大きな利点です。

また、先の例で使った動詞が

• show（表示する）

• hide（隠す）

• are visible（～が見える状態である）

という、教科書に出てきたりプログラムやCSSの中で見かけたりするような、特に難しくない・ありふれた単語だったという点に気が付いたでしょうか？　「やさしい日本語」において、難しい単語を使わず平易な単語を使うように言い換える、多少の細かいニュアンスをそぎ落としてでも端的に意味が通じる言葉を選ぶという事を説明しましたが、英語でも同じ事が言えます。言いたい事に厳密に当てはまる難しい英単語は、おおむね意味合いが通じる平易な単語で代用できるのです。平易な動詞や形容詞でも、主語を変えると意外と広い意味で使える、というのもSVOの文型を使う事の利点です。

筆者はこういう場面で使われやすい英単語をもう少し知っているので、実際にはこのような場面では状況に応じて

• appear（出現する、表れる）

• append / add（追加する）

• disappear（消える）

• deactivate / disable（無効化する）

のような単語を使うと思います。ですが、こういった単語を知らなくても、先の平易な単語でも言いたいことは通じます。より厳密な単語を覚えていくのは追々で問題ありません。他の人が書いている文章で「この単語、なんていう意味だろう？」と思ったらその場で調べて、自分が似たような場面に遭遇したら次から使ってみる、そんな感じで少しずつ語彙は増えていくので安心して下さい。

とはいえ、ソフトウェア開発の場面で特有の頻出単語という物は確かにあります。例えば以下のようなまとめの記事もありますので、暗記が得意なら、頻出単語をあらかじめ頭に入れておいてもいいでしょう。

• 海外エンジニアと使う頻出英単語・英文 50選

• Gitのコミットメッセージの書き方

困った時は箇条書きにしよう、文章以外の表現手段も使おう

報告に盛り込むべき内容の話において、不具合や要望を伝える時は

• steps to reproduce（再現手順）

• expected result（期待される結果）

• actual result（実際の結果）

を軸にすると上手く言いたい事を整理できる、という事を述べました。実際に報告を書く段階においては、このそれぞれを前述のようなぶつ切りのSVOの文型で書いていけばよいという事になります。

しかし、そうすると今度は文同士の繋がりをどうするかで悩む事になりがちです。確かに、ぶつ切りの文章は少々不格好なのは否めません。せめて順接²か逆接³かくらいは示しておきたい……いやそれだけじゃなくて因果関係も示したい……という風に考え始めて、またしても「日本語での表現の仕方は分かるが、英語での表現の仕方が分からないので、手が止まる」というドツボにはまり込んでしまうのは、よくある事です。

筆者は、そこで悩むくらいなら箇条書きで書いてしまう事をお勧めします。例えば対等な物を並べるなら、この項の冒頭のように序列無しの箇条書きにすればいいですし、順番や優先順位に意味がある場面では、項目の頭に数字を付けた序列付きの箇条書きにすればいいです。例えば「再現手順」は以下の要領で書けるでしょう。

1. ◯◯をする。

2. ××をする。

3. △△が◇◇になる。

これなら、受け取り手が順番を読み違える事は無いですし、「Repeat steps from 1 to 4.（1から4を繰り返す）」のように手順そのものを指し示す抽象的な書き方も容易にできます。また、箇条書きを階層化すると、

1. ◯◯をする。

   • ◎◎が出る。

2. ××をする。

   • ◎◎が消える。

3. △△が◇◇になるかどうか。

   • ◇◇になっていたら、4に進む。

   • ◇◇になっていなかったら、1に戻る。

というように、各項目に付随する補助的な情報だったり、条件ごとに変わる操作だったりと、各項目の因果関係や依存関係を含んだ複雑な情報もスッキリ表せます。

あるいは、ここまでやるならむしろフローチャートの図で情報を示してもいいかもしれません。そう、説明する方法は「英語の文章」でなくてもいいのです。スクリーンショットで示した方が早ければスクリーンショットに丸や矢印を描き込んだ物を添付してもいいですし、静止画では説明が難しければスクリーンキャストをYouTubeあたりにアップロードして伝えてもいいです。あるいは、プログラムやデータを実際に作れるのであれば、それを使って実行すれば必ず現象が再現するというテストケースを添付するのが一番いいです。

思い出してみて下さい。皆さんがしたい事は、「英語の文章を書く事」ではなかったはずです。本当にしたい事は「不具合を伝える事」や「要望を伝える事」の方ですよね。その手段として日本語が通じないから、別の手段として英語で説明しようとしてるだけです。「英語という手段で説明する事」自体に囚われてしまうと、本来の目的を見失ってしまいがちです。そんな時は画面から目を離して、落ち着いて深呼吸しましょう。そうすると、別のやり方を思いつけるかもしれません。とにかく自分に今使えるあらゆる手段を柔軟に使い分けて、どんな形ででも伝えたい事を伝える事が一番大切です。

もっと言うと、「OSSプロジェクトのイシュートラッカー」は美しい英文を披露する発表の場ではありません。OSSを公開して実際に障害報告を受ける側になっている筆者の実感としては、ぶっちゃけ、流暢な英語で芸術的に見事な文章をたらたらと書かれても、英語が不得手な筆者はかえって読むのに苦労するばかりで、全然嬉しくないです。それだったら箇条書きで書いてくれた方が、ずっと読みやすく・分かりやすくて助かります。

そう、これも忘れてしまいがちなのですが、OSSプロジェクトで既に英語で文章を書いている人だって必ずしも英語が得意とは限らないのです。OSSの開発者には中国人もいれば韓国人もいるし、ロシア人やインド人もいます。皆さんもどうかその事を心に留め置いて、「英語」にばかり固執しないようにして貰えると筆者は嬉しいです。

自信が無ければ英和翻訳にかけてみよう

話題がまた少し逸れました、英語の話に戻りましょう。

前述したような考え方に則って英語の文章を書いてみたけれど、ちゃんと書けているのか、本当に通じるのか、自信が無い……そんな時は、書いてみた英文を「英語→日本語」の機械翻訳にかけてみる事をお勧めします。

機械翻訳は、「日本語に熟達した人が書いたこなれた日本語の文章を、そのニュアンスを捉えた上で、こなれた英文に翻訳する」というような高度な翻訳は（まだ）こなせませんが、「平易な英文を、平易な日本語の文章に翻訳する」のには充分すぎるくらいに使えます。英和翻訳した結果の日本語の文章を読んでみて、言いたかった事がちゃんと言い表されていると思える結果になっているなら、その英文は人前に出して全然大丈夫です。

筆者も実際に、書いてみた英文の正しさに自信が無い時はGoogle翻訳で英和翻訳してみています。その結果を見ながら、単語の意味や前置詞の使い方を間違えている事に気が付いて手直しするという事も多々あります。

平易な文章の英和翻訳が実用になるなら、平易な文章の和英翻訳の結果も使えるのでは？ と思うかもしれませんが、筆者はそれは以下の3つの理由からお勧めしません。

• 前述しましたが、日本語に熟達した人が日本語で文章を書くと、どんなに気をつけていても、無意識のうちに主語や目的語の省略などを行ってしまいがちです。機械翻訳ではそのような「文章の中には含まれていない外部の情報」を推測する事が難しいために、誤訳が発生しやすいです。

• 和英翻訳された後の英文が自分自身の英語力を大きく超える物だった場合、その意味を自分で読み取る事すらできず、翻訳結果が正しいかどうかを自分では判断できないという事が起こります。

• サービス・ツールによっては、機械翻訳の結果の文章の使い道を利用規約で制限している場合があります。例えば、OSSは商用利用を禁止しませんが、翻訳結果の商用利用を禁止しているサービスで翻訳したテキストをOSSに含めてしまうと、利用規約に違反してしまいます。実際に、Web翻訳の結果をOSSに不用意に入れた人がいたために、その人が過去関わった全ての翻訳済みリソースについて権利面での妥当性を再確認せざるを得なくなったという事例があります。

近年、機械学習の発展のお陰か、みらい翻訳のように「こなれた日本語を入力しても、それなりにこなれた英語の文章に翻訳できる」⁴翻訳サービスが登場してきています。しかし、どれだけ翻訳精度が向上しても上に挙げた2つ目や3つ目の懸念点は解消されません。機械翻訳の結果はあくまで、最終的にOSSに含めるテキストや投稿する文章そのものではなく、それらを考えるための判断材料として使うに留める事を、筆者は強くお勧めします。

まとめ

以上、OSSへのフィードバックで避けて通れない「英語で文章を書く」という事について、テクニックよりは原理原則に焦点を当てて知見を紹介してみました。

実は、ここに書いたようなことは海外旅行などでも使える一般的な考え方です。実際に、悪魔英語　喋れる人だけが知っている禁断の法則という漫画にもおおむね似たような事が書かれていました。「学校である程度の英語教育を受けたにも関わらず、自分からは英語を話せない・書けない」という人にとっての処方箋は、だいたい似たような感じの所に落ち着くのかもしれません。

ここで述べた事を実践して書かれる英語は、はっきり言えば「たどたどしくて拙つたなくて不格好な、ヘタクソな英語」です。でも、それでいいんです。ネイティブスピーカーとリアルタイムで舌戦を繰り広げるとか、格式高い場でスピーチをするとか、そういう場面でもない限りは 「だいたい通じる下手な英語」で大抵は間に合います 。

確かに、海外に移住して「生活」するとか、「相手に隙があれば目ざとくそれを突いて、とにかく自分の利益を最大化しよう、という考え方をしている相手」との交渉といった場面になってくると、英語が下手だと相手からナメられたり足下を見られたりといった不利益を被る事もあるようです。ですがOSS開発の場では、筆者が知る限りは別にそんな事はありません。むしろ、インド人や中国人など英語ネイティブでない人が、めちゃくちゃな英語で普通にコミュニケーションしているという場面の方をよく目にします。世界中で見れば「英語のネイティブスピーカー」より「外国語として英語を使う非ネイティブスピーカー」の方が多いわけで、そういう意味では我々の方が多数派なのです。特別に自分が劣っているというわけではないので、安心して下さい⁵。

このあたりの事について、英語話者の視点から書かれた「酷い英語をもっとお願いします」という記事（※リンク先はその日本語訳）があります。英語話者の人にとっても、英語が壁となって有用な意見やフィードバックを得られない事は損失なので、英語の上手い下手なんて気にしないでガンガン伝えて欲しい、という感覚があるのです⁶。ですから皆さん、どうか物怖じしないで英語での報告に挑戦してみて下さい。

1. これは前の記事でも紹介した、実際に報告を行った事例です。実際の報告内容も併せて参照してみて下さい。 ↩

2. 後に続く文章が前の文章にそのまま続く事を示す接続。日本語なら「そして」「さらに」など、英語なら「and」「then」などがあたります。 ↩

3. 後に続く文章が前の文章を否定する接続。日本語なら「しかし」「なのに」、英語なら「but」「however」などがあたります。 ↩

4. 英語が得意で留学経験もあるような人が見ても、「なるほど確かにこう書けるな」と思えるレベルの翻訳結果が得られているようです。 ↩

5. かといって、上達しようという意識を全く持たなくてもよいという訳でもありません。自分の言いたい事を適切に表現できる英語力があった方が、説明や説得をよりスムーズに進められる事は間違いありませんから。 ↩

6. この対極の話として、努力で英語を身に付けられた人が「みんな英語にすればいいじゃん」とローカル言語への翻訳を否定する発言をした事例がありましたが、その事例ではプロジェクト運営者サイドからも改めて、英語だけが全てではないという事が述べられていました。 ↩