この文章は実践ソフトウェアエンジニアリング第9版アドベントカレンダーの6日目です。 "実践ソフトウェアエンジニアリング第9版"(原著: Software Engineering: A Practitioner's Approach 9th edition) が2021年12月1日にオーム社より発刊されました。これを記念して、翻訳者による感想や解説などの本書にまつわる文章をアドベントカレンダー形式でお届けします。

5日目では翻訳における日本語の難しさが語られました。今回も英日翻訳の話になります。私が英語の本を日本語に訳したのは本書が初めてです。翻訳中に学んだことを細々と記していたのですが、本書の出版を機にそれらをまとめることにしました。 5日目とは別の切り口とし、以下の構成で記します。

第一に語彙
英和辞書ではなく英英辞書を使う
参考文献を読まないと意味がわからないことがある
機械翻訳は答え合わせの材料
定番の訳があるか調べる
レビューでは直す理由を直感を超えて書き下す

第一に語彙

原著に出てくる単語はこの分野の論文、規格文書と比べて難しく感じました。論文と規格文書では平易な語彙が選ばれているのかもしれない、ネイティブが手加減せずに書いた普通の語彙がこのくらいなのかもしれない、とも思わされました。例えばこんな単語が出てきます。いずれも、Weblio では英検準1級以上の単語とされています。

もう少し易しく思えるものを選ぶとこうです。易しく思えるといっても、本書を読む前は知らない単語でした。どこかで出会った覚えはあるのですが意味はわかりませんでした。いずれも、Weblio では英検3級～2級の単語とされています。

特に名詞と動詞を知らないと文の意味が全くわかりません。それに比べれば形容詞と副詞は知らなくても文の意味を理解できる場合が多いです。形容詞と副詞を除いても文として成立するからです。しかし、形容詞と副詞が重要な意味を担っているがゆえに誤解し、後から誤解に気づいた場合が何度もあった覚えがあります。

私は前職で集中的な英語の研修を受けた際に Words are more important than grammar in both understanding and expression. と教わり、英語に触れるたびにそれを思い出すのですが、今回の翻訳でもずっとそれが頭に残っていました。

英和辞書ではなく英英辞書を使う

英日翻訳のプロセスは、(1)英文の読解→(2)意味の理解→(3)日本語への翻訳というものです。 (2)は前の文章との意味的つながりを考えたり、自身の経験と対応づけたり、光景を浮かべたり、といったものです。 (2)では英語と日本語のどちらも使うことができますが、日本語を使わないことにしました。それは、

原文の意味を理解し、意味を損なわない訳文を書くため
英語を理解する能力を上げるため

という理由です。 英語のまま意味を理解できれば、(1)読解と(2)意味の理解を同時にできますが、日本語を使うと(1)と(2)は分かれて遅くなります。

だから、知らない単語を調べるときに英和辞書ではなく英英辞書を使うことにしました。 Cambridge Dictionary では知らない単語を記録することができます。この機能を使って、知らない単語が出てくるたびに記録していきました。

また、英和辞書には英単語ごとに複数の訳が載っていますが、そのどれでもない訳語を使うことはよくあります。典型的なのは discuss で、Weblioでは「論じる」「論議する」「話し合う」「検討する」「討論する」「検討する」という訳語が出てきます。本書では As we discussed in Chapter 1, といった他の記述箇所を参照する文節が多く登場しますが、ほとんどの箇所では「述べた」と訳されています。ほかの案としては、「説明する」「解説する」「後述する」「前述した」が考えられますが、いずれも英和辞書を見ても出てこない訳語です。

参考文献を読まないと意味がわからないことがある

原著のアクセシビリティテストを扱う節で以下の文があります。

As a profession, virtual environment development has not done a good job of providing access systems with rich graphical interfaces that rely heavily on touch interactions [Dia14].

virtual environment を「仮想環境」と解釈しようとすると文の意味がわかりません。前後の文を見ても、Vitrual Reality の話も、Virtual Machine の話も出てこないからです。ここで、Dia14 という参考文献を読むと、その内容は、高齢者向けのUIを持つホームアプリと電話アプリをデフォルトAndroidアプリと比較する話でした。よって、virtual environment とは高齢者向けの代替アプリを指すことがわかります。つまり、ここでの virtual の訳は「仮想」でも「実質的な」でもなく「代替」となります。

このように、参考文献を読まないと意味のわからない文には、少ないですが何箇所か出会いました。訳文の工夫だけでそれを補えない箇所には訳注を付けています。

機械翻訳は答え合わせの材料

ここ数年で DeepL と Google Translator に代表される機械翻訳の質が向上しました。英文を入力すると、そこそこ自然に感じる日本語が出力されます。

私は本書の翻訳作業で DeepL を使いました。といっても、最初から DeepL を使うことはなく、自身で訳文を作った後に使っています。先のプロセスでいえば、(1)英文の読解→(2)意味の理解→(3)日本語への翻訳→(4)DeepL の訳文との比較、という順番です。その理由も英和辞書を使わない理由と同じで

原文の意味を理解し、意味を損なわない訳文を書くため
英語を理解する能力を上げるため

というものです。さきほど語彙の節で述べたように、知らない単語を除いて文意を誤解することがあります。知らない形容詞と副詞を除いて文意が理解できたつもりになると、知らない単語があったということを忘れ、辞書で調べないことがあります。 DeepL は、その忘れを思い出し、誤解を解くのに役立ちました。

そして、母語が日本語である人々にとって自然に感じる訳文を出せるという DeepL の強みに頼って、自分では思いつかなかった表現を覚えられることも DeepL の利点です。

ただし、DeepL の英日翻訳も人が訳すと同様に誤訳がありますので、比較材料にとどめるのが良いと思います。比較して意味に違いがあれば、どちらかが（どちらも）間違っている可能性が高いということです。どちらが間違っているのか DeepL は教えてくれません。

定番の訳があるか調べる

初めてその分野の文献を翻訳する場合は翻訳者が訳語を考えますが、本書ではそうでない箇所が多く、既存の翻訳文献に定番の訳があるかを確認することが必要になります。これには語学力ではなく、内容の知識と調査能力が求められます。

わかりやすい例としては、テスト駆動開発、継続的インテグレーション、教師あり学習、といったものがあり、多くの文献で同一の訳語が使われています。ガートナーのライフサイクルにおける「幻滅期」や「過度な期待のピーク期」というのも、公式的に提供された定番の訳にあたります。

そういう迷わずに済む場合ばかりではありません。その分野に関する既存の翻訳文献が存在するものの、定番といえるほどの文献数がなく、既存の翻訳よりも適した訳が考えられる場合がありました。例えば、オブジェクト指向におけるCKメトリクスと呼ばれている6種については、演習で学ぶソフトウェアメトリクスの基礎という訳書で扱われていますが、この訳よりも助詞を減らして名詞に近くした訳としています。

既存の翻訳文献がありそうで見つからなかった場合もありました。技術のイノベーションライフサイクルを示す BRETAM sequence という図があります。最初はガートナーのライフサイクルと同様に定番の訳が存在すると想定したのですが、BRETAM sequence でググったり参考文献を参照した和文を調べようとしても出てこなかったので、「黎明期」「模倣期」「理論化期」という訳語をあてました。

レビューでは直す理由を直感を超えて書き下す

本書は共訳書です。10名ほどの共訳者がいます。互いに訳文をレビューすることによって、その意味が伝わるか、意味が原文通りかを確かめ、より良い訳案を出しました。語句、文法、技術的内容に起因する間違いを正すのであれば比較的簡単です。ただ、翻訳のレビューにおいては、間違いではないものの良くない、自分ならこう訳す、と直感的に思える訳文に出会うことがたびたびありました。そして、直す理由を直感を超えて書き下さないと、レビューの相手に伝わりません。ただの好みであれば直す材料にはなりません。 なので、指摘の発端は直感だとしても、できるだけ論理的、客観的に理由を伝えるようにしました。

間違い、間違いではない、という言葉を使いましたが、両者は明確に区別できるものではなく、連続的な良し悪しという方が正確です。以下に実例を示します。

これは技術的な慣用に基づく語句の問題で、わかりやすい方です。
これは英単語のニュアンスの問題で、わかりやすい方です。辞書ではこうなっている、と伝えると客観性が増します。
よいの方がよい。
これは原文の意味を考えると原文に無い前置きを付加すると意味が伝わりやすい例です。伝わりやすさと原文への忠実さは相反することがあります。
構造が難しい文に対するレビューコメントも難しく、長くなります。

ということを書くのは大変です。 「ここは不自然です」と書くだけなら5秒で終わりますが、その理由と修正案を書こうとすると10分かかります。

最後は日本語の能力

英日翻訳で最後につくるものはもちろん日本語の文です。誰が訳しても、機械翻訳に任せても大して結果が変わらない文もあれば、前後の文脈や意味を考慮して構造を工夫したり、類義語や文語/口語の表現を取り入れるといった創造性が試される文もあります。辞書も DeepL も、そうした創造性を発揮するための方法や知識を直接的には授けてくれません。訳者の一人は日本語の作文と英日翻訳の本を読んだようですが私は読みませんでした。次に訳書を出す機会があれば学んでおこうと思います。