実務翻訳雑記帳

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

特許翻訳と特許法

特許法を知らないと、特許翻訳はできないかというと、それほどのこともないと思います。知らないでやっている人も多いです。

それでいいかどうかは、別ですけど、需給やコストの制約がありますから、業界の隅々までベスト・プラクティスというわけにはいかないのが現実です。

私の場合、翻訳よりもまず、特許技術者として明細書を書いたり中間処理したりというところからはじめたので、重要な条文は、なんとなく門前の小僧でわかるようになりました。

ですが、そもそも法律を勉強したことがなかったので、その知識は深まっていきません。

当時勤務していた事務所で、特許法の本を読んでみても、あまりよくわかりません。いつまでたっても、現場のノウハウ的な視点から離れることなく、日々の業務に追われていました。

その後、仕事にもある程度慣れて、少し余裕ができたときに、自分のやっていることがよくわかっていないことが気になってきました。それで、ちゃんと勉強しようかなと思うようになったわけです。

まず、大学の一年生が教養課程でやるような法学の入門書を買って、これが面白くなかったらやめようと思ったのですが、意外にもそれが面白い。

それで、調子に乗って、民法を勉強することにしました。特許権の成立には、行政機関が関与するものの、特許権自体は私権なので、民法の財産法が大前提となるのです。

やってみると、民法がとてもおもしろかったのが意外でした。とにかく、民法には、おそろしく頭のいい先生がいて、読んで面白い本がたくさんあります。

さらに、民事訴訟法も勉強してみました。特許法をみるとわかるのですが、手続き面で、民事訴訟法が多く準用されているのです。

そのうえで、行政法も勉強してみると、特許庁(長官)、審査官、審判官というプレーヤーの位置づけや動きについても、見通しがよくなりました。

私は、法学が面白くなったので、趣味のように勉強してしまったのですが、資格試験を目指す方は、こんなふうに勉強してはいけません。

資格試験の勉強が心底嫌いなので、試験対策に適しているかどうかという視点ではなく、純粋に理解しやすい本を選んで楽しく勉強しました。


特許翻訳をしている方が、特許制度や特許法に興味を持った場合、ここまで範囲を広げて勉強することは現実的ではありません。それでも、一冊だけ読んでみようかと思われる方には、

高林龍『標準特許法 第5版』

をおすすめします。

著者が元判事なので、特許法に張り付いた視点からではなくて、民事法や行政法にバランスよく目を配りながら、広い視野でわかりやすく解説されています。

弁理士試験対策なら、もっと新しい本や、適した本があるのかもしれません。ですが、特許制度について法学的にしっかりした立場から理解したいのであれば、この本は最適だと思います。

実際の特許を参照した具体的記述もありますので、読んで面白いと思います。細部にとらわれず、早いペースで通読することに注意すれば、楽しく読めることでしょう。


さらに、深みにハマろうという方には、次に重要なのが民法です。

これも、各種資格試験を目指していないのであれば、

米倉明『プレップ民法

をおすすめします。

これは、入門書だからすすめるというのではなく、本当によく書けている本だからです。膨大な民法財産法を、具体的でシンプルなケースを想定しながら、一筆書きで、サラッと書ききった、天才の仕事。

私は、民法がとてもおもしろくなって、かなり多くの著者の本を読み込んだのですが、勉強がだいぶ進んだ後に、『プレップ民法』を読んで驚愕しました。最初にこれを読んでおけばよかったと思ったものです。

理系も文系もさまざまな分野を勉強しましたが、こんなに良くできた入門者向けの本は他にないと思います。


このあたりから、完全に趣味の領域ですが、次にやるなら民事訴訟法です。ただし、これは、独学がかなり難しいと感じました。

理系の本の場合、アタリマエですが、1章で勉強したことを前提に、2章、3章と積み上げていくようになってます。

つまり、今読んでいるページよりも前が、読者にとっての既知情報、それより後が未知情報ということになっているはず。

それが、多くの民訴の本では、その切り分けの意識が希薄な気がしてしまうのです。

これを、「民事訴訟法学は円環的なのである」とかもったいぶって書く先生もいます。でも、あらゆる学問体系は、円環的なはず。

円環構造を、そのままで初学者に提示するのは、先生のアタマが悪いのか、法学部生の頭が良すぎるか、どちらかです。

民法だって円環的ですが、内田『民法』だって、大村『基本民法』だって、我妻時代の体系書と違って、既知情報と未知情報をキッチリ仕分けて書いてくれてますから。

私の読んだ中では、唯一の例外的良書が、

林屋礼二『新民事訴訟法概要』

です。現在入手困難ですが、図書館などで読める方は試してみて下さい。今までわからなかったのがバカらしくなるほど、すっきりわかります。民訴だって、やればできるのです。こうやって円環を解きほぐすのだと。

細かくなりすぎますが、入手できるものの中では、

裁判所職員総合研修所『民事訴訟法概説』

というのが、学者が書いた本よりもわかりやすいと思います。読むのは大変ですけど。


さらに、行政法にまで手を広げようとするなら、

稲葉・人見・村上・前田『行政法 第3版 (LEGAL QUEST)』(有斐閣

とかが良いと思います。一冊にまとまっていて、内容もすっきりと読みやすいので。

憲法学とか、もうイデオロギー的で大変ですが、行政法学はおもしろいですよ。美濃部達吉も、佐々木惣一も、行政法の専門家でした。ここに根ざさない憲法学は、政治的パンフレットに過ぎないと思うぐらいです。


法学には、刑事訴訟法とか、もっと面白い分野もありますが、特許法に関連があるところでは、知財法という意味では著作権法がありますし、独占禁止法も意外に関係が深いのです。

独禁法は、あまり勉強してないので、これからやろうかなぁと思っています。

 

これだけむやみに勉強したなら、おそらく、法令翻訳するための基礎知識がついたのではないでしょうか。中間処理だけでなく、特許裁判関係の翻訳が視野に入ってきますね。

キーボード

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

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

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

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

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

ただ、私にとっては、ちょっと押下感が柔らかすぎるのと、キー間隔が広すぎるので、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は、先行者の強みもあるけど、逆に、それが足枷となって、新しい流れに取り残されるかもですね。

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

翻訳作業の実際(用語一括置換+並べ替え)

翻訳作業の手順は、翻訳者によって様々だと思いますが、最近は、Tradosなどの翻訳メモリが急速に普及していますね。

ソフトウェア系のローカライズ翻訳などでは、Trados使わない人はいないのではないかな。

翻訳メモリについては、また書こうと思いますが、まずは、翻訳メモリ登場以前の典型的な作業手順を紹介してみます。

人によって、呼び方は様々ですが、仮に「用語一括置換+並べ替え」とでもいっておきましょう。

まず、重要な用語を対訳式の用語集にまとめておき、その用語集に基づいて、原稿データ中の該当用語を一括置換するのですね。

そして、バイリンガル的にごちゃごちゃになったデータを、並べ替えながら訳文を仕上げていくというものです。

特許翻訳では、水野麻子さんが、Wordマクロで一括置換するやり方を紹介してこられたので、この方式がかなり普及したと思います。

現在は、新田順也さんが、それを継承して、ぱらぱらなどのツールとしてまとめておられます。

Wordで作業するのが苦にならない人は、こうした手法が参考になるかと思います。

でも、Wordってイライラしませんか? やはり、テキストエディタで作業したいですよね。

Wordで支給された原稿ファイルを、テキストファイルに変換して、テキストエディタで「用語一括置換+並べ替え」して、最後にWordに貼り付けて納品という、キセル方式にすれば、できるだけWordをさわらずに済みます(笑)

テキストエディタで作業したい人は、Buckeyeさんの、SimplyTermsが、用語置換とかに有用です。

このSimplyTermsもずいぶん使わせてもらったのですが、私にとっては高機能すぎるのと、あと、特許用にちょっと別の機能を足したいということもあって、今では、自分で書いた簡単なスクリプトWSHJscript)で、作業するようになりましたが。

ちなみに、足した機能は、参照符号をキーにしたスニペットみたいなもので、需要があれば、また記事にしてもいいんですが…。

テキストエディタは、秀丸使ってる人が多いですね。とりあえず持ってはいますが、EmEditorを主として使ってます。ただ、有料のアップグレードが鬱陶しいので、最近では、EmEditor無料版とサクラエディタを組み合わせて使ってますが…。

用語並べ替え作業の際に、EmEditorキーバインドはとても便利で、無料版で試してみるといいと思います。Ctrl+Shift+上下カーソルで、行単位の並べ替えが凄くはかどるんですよ。

ちなみに、今後はAtomに移行してやろうかと、研究してるところです。

将来的には、やはり特許翻訳も翻訳メモリでの作業が要求されるようになると思いますが、私の場合、今のところ、案件の技術内容がよくわかっていて、7,000 words以下程度であれば、「用語一括置換+並べ替え」が手っ取り早いかな、といった感覚です。

内容が難しかったり、分量が多い場合は、翻訳メモリのフィルタ機能があると助かりますね。表現の統一やチェックも、やりやすいですし。

皆さんは、どんなふうに作業してらっしゃるんでしょうか。日頃、独りで作業してるので、他の翻訳者さんの作業手順とか、できれば参考にしたいです。

EmacsVim使いの人もいるのかなぁ…。オレはマウスやカーソルキーなんか触らないゾ、とかいう人の話も聞いてみたい。