実務翻訳雑記帳

特許・技術・法務系の和英翻訳ノート

キーボード

翻訳していると、一日中キーボードを使うので、自分に合った製品が見つかると、作業効率は上がるし疲れなくなるし、ということなので、ここは妥協せずに、いろいろ試してみる必要があります。

好みが別れるのですが、ノートパソコンとかに慣れてて、キーストロークが浅めの方がいいという人でなければ、静電容量無接点方式を試してみるといいと思います。

機械的なスイッチングが気にならないし、入力できたかミスタイプしたかが、画面を見ないでもわりとはっきりわかる気がするので、特に紙原稿見ながら英訳する場合のように、画面を見ないでタイプする時間が長い作業では、効率がだいぶ違います。

まぁ、最近は紙原稿で作業することが、なくなってきましたけどね。

サイズが標準的なのは、東プレので、キー間隔もゆったりしてます。キーの割付も標準的なので、多くの人に問題なく使えるかと。

ただ、私にとっては、ちょっと押下感が柔らかすぎるのと、キー間隔が広すぎるので、PFUHHKBが好きです。

HHKBは、コンパクトで、とても手に馴染むのですが、ファンクションキーなどがFnキーとの組み合わせ入力になるので、ちょっとクセがあるといえるでしょう。

慣れてしまえば何も問題ないんですが、使いにくいと感じる人も多いようです。

あと、HHKBの英語配列は、エンターキーも近くて理想的なのですが、カーソルキーが独立してなくて、Fnキーとの組み合わせになるので、カーソルキーを多用する人は、注意が必要です。

英語版も持ってて、Fnキーの組み合わせもストレス感じないんですけど、やはり、本来は、EmacsVim使いの人向けなんでしょうね。カーソルキー要らんのですから。

すべての作業をEmacsVimで完結できるという人以外は、日本語配列の方が無難でしょうね。

それと、HHKBには、無刻印モデルがあるのですが、これはあまりおすすめしません。

というのは、フツウにブラインドタッチしてる人でも、両手がホームポジションにないときに、ちょっと片手を伸ばしてキー入力するというシチュエーション、あると思うんです。

そんなとき、やっぱり刻印に頼るんですよ。達人は別ですけど。

私も、両手がホームポジションにあるときには、キートップなんか全く見ないので、無刻印でいいかなと思ったんですけど、座るまでもなく、ちょっと立ったまま片手で入力とか、意外とやるんですよね。そんなとき、やはりキートップを無自覚に見てます。

メカ式のキーボードが好きな友人は、よくキーボード買い替えてますけど、私のHHKBは8年半以上、かなり酷使してるのに、全く問題なく使えます。

たまに、キートップ外して掃除したり、メンテはしますけど。


関係ないですが、英訳の場合、キーボード使わずに音声入力する翻訳者もいます。リチャード・ウォーカーさんの記事を読んで驚愕しました。

英訳のほうがキー入力ははるかに簡単ですが、キー入力自体が不要になるなんてねぇ…。

日本語は、今のところは、漢字変換などで、キーが必要なのかな。

 

いずれキーボードという道具がなくなるのかもしれませんが、そのときには、翻訳という仕事自体、なくなっているかもしませんね。

(いろんな意味で)ポリグロットの猪浦先生は、通訳よりも翻訳のほうが残るのではと予想していらっしゃるのが、意外でした。私は逆のように思っていたので。

専門性と正確性が、最後には重要になってくるということですね。

いろいろ心配しても将来はわからないので、各分野の専門性を高めていくことが、さしあたって大事かなと思っています。

翻訳チェック

「好きなことで生きていく」というほどには翻訳が好きでもなく、関係各位に申し訳ないのですが、それでも、この仕事をしてて、嫌だなぁと思うことはほとんどないです。

特に、フリーランスになってからは、自分の好きなペースで好きな音楽や動画を聞き流しながらやってるので、遊んでるようで申し訳ないぐらい。長時間やっててもあまり疲れません。

ただ、どうしても苦手なのは、翻訳チェックです。リズミカルに英語を打ち込む翻訳作業は、軽快で楽しいですが、チェックは神経も使いますし、まるで仕事してるみたい…。

チェックで自分のミスをどれだけ正確に特定できるか、というのはプロの力量の試金石。私はあまり自信ないんですが、それでも、気合を入れて頑張っています。

もちろん、気合だけでなく、皆さん、様々なチェックツールを作ったり、工夫されてますよね。

私も、正規表現で、ピリオド後にスペース2つ入ってるか、とか、ピリオド入れ忘れて改行してないかとか、やりそうなパターンは事前に潰しておきます。もちろん、スペルチェックも入念にやります。

それでも、最終的には、一文ごとに日英対照していくしかありません。

最近では、セキュリティの観点から、プリントアウトに制限を課すクライアントさんもいるので、チェックもやりにくくなってきました。

以前は、原文を左側に置き、チェック箇所の直下に定規をおいて、右側に訳文を置いて、終わったところにペンでスラッシュを入れていく、という感じでやっていたものです。

 

大量の案件の場合、やはり翻訳メモリが便利かなと思います。

翻訳メモリの画面上で、セグメントごとに日英対照できると、チェックしやすいですね。

それと、翻訳メモリだと、翻訳作業中に、1セグメント訳し終えて、そのセグメントをすぐにチェック、という流れが、自然にできるのがいいです。全部終えたところで最初からチェックすれば、その時点で、2度目のチェックをすることになるわけです。

チェックで修正する場合にも、翻訳メモリであれば、フィルタをかけて類似箇所を並べ、一気に修正していくということが簡単にできます。誤訳修正だけでなく、表現に統一感が出ます。

翻訳よりも、チェックの工程で、翻訳メモリが有用だと感じるぐらいです。

用紙をむやみに使わなくなるのもいいですね。最近では、大量にプリントするのがちょっと嫌だなぁと思うようになりました。

書籍も電子版の方が検索楽だし、ずいぶんやり方が変わってきたものです。

そのうち、「プリンタもってませんけど…」とか、「3Dプリンタならあるんですけど…」とかいう若手翻訳者に会いそうな予感が…

Wordとどう付き合うか

翻訳メモリを使わないのであれば、翻訳作業は、Wordでやるのが標準的だと思います。でも、Wordって、しくみが複雑だし、いちいちおせっかいなので、できれば使いたくないんですよね。

原稿の受領や訳文の納品時には、どうしてもWordファイルを使うことになるんですけど…。

いっそのこと、『エンジニアのためのWord再入門講座』なんかを読んで、Wordをよく理解してから使ってみようかと思ったこともありますが、やっぱり好きになれません。

新田順也さんとかは、Wordのマクロを徹底的に使いこなしていて、これはこれで凄いと思います。

他には、Wordのオートコレクト機能を活用する人もいます。オートコレクトは、本来、ダイナミックにスペルミス訂正してくれる機能ですが、それを入力支援に利用するのですね。

たとえば、"@tpi"と入力して、"the present invention"に変換させるといった感じです。これを利用するためには、"@tpi"→"the present invention"というペアを、予め登録しておく必要があるんですが…。

興味のある方は、倉増一先生のサイト(トランスプライム)の「オートコレクトを徹底的に活用する」を見てみるといいと思います。

こういったことは、テキストエディタスニペット機能でもできます。

私の場合、EmEditorスニペットを入力支援に使うことがあります。スニペットは、プログラマーがコードを書くときの入力支援に使われるものですが、これを訳文の入力に利用するわけです。

用語集をスニペットとして取り込むための簡単なスクリプトを書いて、登録しやすいようにしています。

 

テキストエディタで作業すると、上付/下付文字の処理ができないのがちょっと困りますね。訳文完成後、Wordに貼り付けた後に、手作業で置換するか、自動化するならWordマクロを書く必要があります。

Wordでの処理をできるだけ減らしたければ、WSH (Windows Script Host) で、JScriptVBScriptを使うという手もあります。これなら、外部からWordファイルを処理できます。

クジラ飛行机さんの『仕事がはかどるJavaScript活用術─Word/Excelで自動処理して効率アップ』なんかが、参考になります。

そこまでWordを嫌わなくてもとも思うのですが、仕事は気持ちよくやりたいですからね。

可算名詞と不可算名詞

大学の第二外国語とかで、ドイツ語やフランス語やると、名詞に性があったり、格変化があったりで驚きます。英語にもないわけではないですが、かなり希薄になってますよね。

でも、単数複数の別はしっかりありますし、そもそも、可算名詞と不可算名詞の区別が難しいです。

日本語が母言語の人なら、翻訳は、まず英日の方向から始めることになると思います。私も最初は英日から始めました。当時は、『リーダース』と『リーダース・プラス』が便利で、かなり万能な辞書と思って、愛用していました。

それが、日英を少しずつ手がけるようになると、リーダースには可算名詞と不可算名詞の区別が載ってなくて、困りました。

インプット中心でオベンキョーしてるときには、可算・不可算、あまり意識しないんですけど、実際に作文してみると、冠詞をどうするかでつまずきます。当然のことながら、冠詞を正しく使うには、大前提として、名詞の可算・不可算をはっきりさせなければなりません。

そうすると、『ジーニアス英和大辞典』などの、可算・不可算が載っている辞書に手が伸びるようになります。

こうして、可算・不可算の別が気になりだすと、英文を読んでいるときにも、そういう視点で読むので、いままで見落としていたその角度の情報が、どんどん入ってくるようになります。

逆に言うと、それが気にならないうちは、多読しても身につきにくいということかもしれません。

新たな角度で英語と向き合ううちに、学習者としての視野がほんの少しだけ広くなり、日本語と英語とで、世界の切り取り方が違うということに気づいてきます。

 

英英辞典でも、ネイティブ・スピーカー用の辞書は、可算・不可算の別が載ってません。本来は、辞書で定義するようなものじゃなくて、用法的な状況によって、可算・不可算が自然に決まってくる、といった意識がはたらいてるのでしょうか。

それでも、学習者用の英英辞典には、可算・不可算の別を載せてくれているので、Merriam-Webster Learner's Dictionaryとか、重宝しています。スマホアプリ、Web版、紙の冊子の3通りを、何かというと引いてます。

 

特許翻訳では、information, data, equipmentなんかが、よく使う不可算名詞だと思います。

日本語で明細書を書くときに、情報、データなど、どれも普通に数えられる感覚で書くと思うので、その個数が問題になる場合、
a piece of information
a data item
というように、いろいろ工夫することになります。

dataは、もともとはdatumの複数形なわけですが、技術系の文書だと不可算扱いが多いです。なので、a data itemとか、場合によってはa piece of dataと表現したりすることに…。

装置のequipmentも不可算なので、用語が選べるのであれば、apparatusやdeviceを、可算扱いで使うことが多いです。

英訳をやりだすと、このあたりが気になってしかたがなくなります。

たまには、特許技術者の仕事もするのですが、日本語で日本語明細書を起案するときにも、日本語の用語を決める段階で、既に、頭のどこかで、英訳されると不可算名詞で面倒だなぁとか、余計なことを考えてしまいます。

そのぐらい思いつめないと可算・不可算とか単数複数とか、世界の切り取り方の違う言語は身につかないかな、とは思います。

 

英語の視点で世界が切り分けられるようになり、英語が正確に読み解けるようになってはじめて、ほんとうの意味での英日翻訳のスタートラインに立つのでしょうね。

なので、駆け出しの頃のなんちゃって英日、そしてハードルの高かった日英を経て、最終的には、本当に高品質の英日をきっちりできるようになりたいなぁと、思うこの頃です。

翻訳作業の実際(翻訳メモリ)

翻訳メモリというのは、原文と訳文とのペアを文単位で記録しておき、以後の翻訳に再利用しようとするものです。

新たに訳そうとする箇所が、既に訳したところと類似しているときには、対応する訳文を引っ張ってきて、それを修正する方式で、訳文を完成させます。

ソフトウェアのローカリゼーション分野から普及が始まり、特許翻訳でも、特に日英分野で、Trados指定されることが増えてきました。某大手特許事務所がTrados導入してから、普及が加速しています。

和訳の場合、日本語は漢字と仮名のどちらを使うかとか、送り仮名をどうするかなど、表記の揺れがかなりあります。なので、参照すべき翻訳メモリに表記の揺れがあると、それを再利用する際にも、手間がかかって大変です。

共同通信の『記者ハンドブック』をガイドラインとして絶対視する人も多いですが、必ずしも実務翻訳全般に徹底しているわけではありません。個人的には、違和感を覚える箇所も多いです。

そんなこともあって、和訳案件は敬遠しがちで…。

翻訳メモリは、英訳に使った方がストレスなく効率的と思います。

同じ表現を含む箇所をフィルタリングしたりする機能は、使ってみるとかなり便利です。大規模案件の表現の統一が楽になります。

それと、文などのセグメント単位で対訳表示できるので、翻訳後のチェックもやりやすいですね。

翻訳メモリを使いこなしている人は、メモリを蓄積して品質上のメンテナンスにも手間をかけるらしいです。

私は今のところ、翻訳メモリに完全に依存するやり方にはしていないので、ひとつの案件の範囲内で、表現が統一できればいいかな、という感覚で、案件単位と割り切って使います。なので、メモリのメンテナンスとかはしないです。

製品としては、Tradosがデファクト・スタンダードなので、これから導入する人は、Tradosということになるのでしょうね。

私もTradosで作業していたこともあるのですが、どうも複雑で好きになれません。あと、オレたちのやり方に合わせろと言わんばかりの上から目線の会社の姿勢に、マイクロソフト的な気味の悪さがあって、できればおつきあいしたくない文化です。

いきなりTrados買う勇気がない人は、Memsourceを試してみるといいんじゃないかな。無料で十分使えるし、なによりもシンプルなのがいいです。

Memsourceは、クラウド式の翻訳メモリで、メモリや用語集はクラウドで管理して、実際に作業するエディタは、PCにダウンロードしてもいいし、Webエディタを使うこともできます。

これで、ある程度まとまった分量を訳してみると、どんなところが便利なのか、実感が湧くと思います。

ただし、セキュリティにうるさい取引先だと、クラウドにデータを置くことを許さないことも多いので、勉強ならともかく、実案件にはMemsourceを使えないことも多いです。

Memsourceでなじんだら、結局はTrados買って、あの複雑な代物に取り組むということになるのかな。

私は今のところ、Trados案件打診されても、「Trados嫌です~」とかわがまま言って、Wordでフツウに納品したりしてますけど、あれはその後どんなふうに管理されてるんだろう…。

海外では、Wordfast使ってる人もいますが、個人的には、フリーソフトOmegaTが好きです。

フォーカスしてるセグメントのテキストファイルを吐き出してくれたりするので、使い慣れたテキストエディタを併用することもできます。スクリプト書く人なら、いろいろチューニングする楽しみもありますよ。

翻訳メモリは、プロジェクト全体をマネジメントする視点からも、有用な技術なのですが、クラウド化の方向は、この流れに親和的です。各社単位で、サーバーやセキュリティを完全にまかなうよりも、外注したほうが楽ですし、コストも安くなるでしょう。

Tradosは、先行者の強みもあるけど、逆に、それが足枷となって、新しい流れに取り残されるかもですね。

末端の翻訳者としては、だんだん管理がキツくなりそうで、ちょっと嫌なんですけど、この流れを止めることはできなさそうです。