■ 私の翻訳のやり方

秋から半年かけて2冊の本の翻訳をしたので、そのやり方をまとめて書いてみる。翻訳本の宣伝はまた後日。

1. テキストデータ化する

まずは何はともあれテキストデータにする。 私は、テキストエディタと辞書ソフトを使って翻訳しているので、 テキストデータがなければ作業ができない。あまりよくない気もするけど、仕方ない。

元の原稿が最初からテキストデータであれば問題ないが、その他のフォーマットだと変換しなくてはいけない。HTMLなら簡単にできる。物理的な紙（原書）なら、OCRするのかなあ。よく知らないが、たぶんそうだろう。よくあるのがPDFで、割と面倒なのもPDFだ。PDFからテキストを抽出するツールはいろいろあるが、ちゃんと正確に抽出できるものは、たぶんない。そこそこうまくいくツールでも、アポストロフィーとかハイフネーションの扱いがうまくできない。が、抽出することが主な目的ではないので、そこらへんはざっと抽出するのでヨシとする。なお、ヘッダ・フッタ・ページ番号なんかは削除しておいたほうがよい。

2. ワード数を数えて工数を見積もる

スケジュールを把握するためにも、まずはワード数を数えたい。ツールはwcでよい。プログラムコードが含まれているものであれば、分量に応じてなんとなく調整すればよい。厳密な数値は必要ない。

で、ワード数を工数に変換する必要があるのだが、プロの翻訳家であれば、2,500～3,000ワード／日は翻訳できるという話を聞いた。なので、自分の場合は（他に仕事があるので）、1,500～2,000ワード／日で換算するようにしている。ページ数だと5ページくらいか。300ページの本だと60日（2か月）といった感じ。実際には校正があるので、その1.5～2倍（3か月～4か月）くらいかかる。経験的には、だいたい合ってる。

3. サイトラ（もどき）

通訳の方は、事前にサイトラと呼ばれる調査をするそうだ。分野が違えば、求められる語彙や背景知識が違ってくるからだ。日本語がわかっていても、知らない分野の話は理解できないのと同じだ。

自分は技術書しか訳さないので、語彙や背景知識がまるっきりわからないといったことはない。なので、日本語で関連図書を読んでから（『メタプログラミングRuby』の場合は、『はじめてのRuby』と『プログラミング言語Ruby』を読んだ）、とりあえず流し読みをするだけにしている。あと、頻出ワードの列挙というのをやっている。やるだけやって何をするわけでもないが、全然意味がわからない単語がよく使われている場合は、事前に意味を把握しておくと、あとの作業が楽になる。

通訳ができる人は、テープに下訳を吹き込むこともあるそうだ。

4. 作業用のファイルを準備する

ようやく本当の作業を開始。まず、抽出したテキストファイルが1ファイルになっていると思うので、これを章ごとに分割する。必ずしも分割する必要がないが、バージョン管理の面からも、分割したほうが扱いやすいだろう。私は、ReVIEWというツールを使っていることもあり、必ず分割することにしている。テキストがうまく抽出できていれば、章の前後に何かマークがあると思うので、これを頼りに自動分割できる。できなければ、手作業で分割する。ついでに画像も保存しておきたい。ファイルの準備ができたら git init してバージョン管理を始める（リモートレポジトリはgithubのプライベートレポジトリを使っている）。

5. 翻訳作業

パラグラフごとにひたすら翻訳。英日英日英日……のようにしていく。自分は、MacBookのVMWareでWindows XPが動いていて、そこでxyzzyとPDICを使って淡々と翻訳している。xyzzyを使っているのは、物理行移動ができるのと、PDICの連携が秀逸だからだ。辞書は英辞郎を使っている。例文検索をするときはアルクのサイトで検索している。それでもダメならググる。それでもダメなら英英辞書を泣きながら読む。あと、最近気付いたのだけど、Macの辞書が日本語のシソーラスとして使える。言い回しなどに悩んだときに便利。

どんなに頑張っても意味不明な文章は、著者に質問することになる*1。でも、最近はメールアドレスを公開してない人が多くて、連絡先がわからなかったりする。そんなときは、たいていtwitterは使っているので、ググってIDを探して、メンションで「メアド教えて」と言う。あるいは、今はFacebookという便利なものがあるので、名前を検索して、いきなりメッセージで質問を送る。返事が遅い人はいるけど、答えてくれない人はいない。

日本語の扱い方については、基本的に『日本語の作文技術』をよりどころにしている。完全に読み込んでいるわけではないので、ちゃんとできているわけではないが、主なポイントは参考にしている。読んだことのないひとは読んでみて欲しい。

普段は意識してないけど、あえて列挙するとこんな感じだろうか。絶対的なものではないので、ルールじゃなくて指針。バランス大事。

• 修飾は長い順にする
• 「あなたは」を省略する：日本語は主語を省くことが多い
• 「あなたの」を省略する：自明なので
• 無生物語を主語にしない：人を主語にする
• 受動態を避ける：能動態にする
• 否定形を避ける：反対にする
• 二重否定を避ける：肯定形にする
• 「～が、」を避ける
• 文のつながりが唐突なことが多いので、なめらかになるような接続詞を補完する（しかし・その結果・つまり）
• 主語の省略によるねじれを避ける。

（例）ログインすると、情報を表示します。
↓変だと思ったら、主語を補完する。
ユーザーがログインすると、システムが情報を表示します。（でも、冗長になっちゃう）
↓主語を統一するという手もある
ユーザー目線：ログインすると、情報が表示されます。（でも、受け身になっちゃう）
  or
システム目線：ログインされると、情報を表示します。（でも、無生物主語になっちゃう）

• 「〜だ。〜だ。」と語尾を連続させない。「〜だ。〜である。〜だ。」のように交互にする。

若い頃は山形浩生が大好きで（今も好きだけど）、話しかけるように書くのがいちばんだと思ってたんだけど、どうやら「目で読みやすい形」っていうのがあるらしいということに気付いた。つまり、声に出して読むと変だけど、目で見るとサラリと読める文字の並びというのがある。逆もしかり。例えば、ひらがながずっとつづくと、こえにだしてよむぶんにはもんだいないけれど、やっぱりよみにくいのだ。ほらネ。

それから、これは自分だけだと思うけど、日本語のボキャブラリーを増やすためにニコニコ大百科や同人用語の基礎知識をたまに読んでいる。他人にはオススメしない。

6. マークアップ

ひと通り翻訳ができたら、まず英文をコメントアウトする。それから、日本語のマークアップをする。章・節・箇条書き・引用・ノート・強調・プログラムコードなどなど。これができたら、ReVIEWというツールで、HTMLに変換する。ファイルを編集したらブラウザが自動リロードするようにしておけば、便利でよろしい。ただし、Chromeじゃないとリロード後の現在位置を保持してくれないっぽい。ChromeかわいいよChrome。HTMLにすると読みやすくなるので、校正がしやすくなる。

7. 校正（1回目）

あとはひたすらHTMLを見て校正をする。定期的に2種類の機械的な校正も行っている。まずは、JustRight!4を使う方法。そして、独自の校正ルールに違反した箇所を正規表現で抜き出す方法（単なるgrep。ルールは翻訳中に成長させている）。ここでも自動リロードを効かせておくとすぐに反映されるので便利。そういえば、先日「雑学王」で「ください」と「下さい」の違いがクイズになってたんだけど、おもいっきり逆に使っていた（恥）。既存のものは一括置換したんだけど、念の為に校正ルールにも「下さい。」を追加しておいた。こうすれば誤って追加しても気付くことができる。JustRight!がそれほど役に立たないっていう話かもしれないけど。

校正をするときには、できるだけ音読をしたい。音読をすれば、意味がわからないところや、翻訳調で不自然なところがよくわかる（とはいえ、上で言ったように、音読すると不自然だけど目で見るとサラリと読める場合もある）。音読を必要とするので、ファミレスなんかでは作業できない。

8. 校正（2回目）

2回目の校正は、全体の校正が終わってから、ReVIEWを使ってPDFを生成する。HTMLでも読みやすいけど、PDFになるとさらに読みやすい。ここがReVIEWを使っていて良かったと思うポイントだ。できたPDFをiPadに入れて、ファミレスなんかで校正する。校正にはiAnnotate PDFが便利だ。他にも便利なツールがあるかもしれないが、フリーハンドのツールが奥にあるGoodReaderよりは確実に使いやすい。

最近、近所のファミレスがつぶれたので、俺はもうダメかもしれんね。

なお、技術書の場合はこの段階でレビューをお願いすることが多い。TEXT・HTML・PDF・EPUB（ReVIEWはEPUBもイケるんだぜ？）を用意しておくと、読みやすいフォーマットで読んでいただけるので便利だそうだ。iPadでEPUBは最強という話も耳にした。iPhoneにPDFを入れて風呂や電車で読んでいたという人もいた。

9. 入稿

さて、校正が終わったら編集者に原稿を渡すわけだが、Dropboxで共有しておけば、戻しにも使えるので便利だと思う。フォーマットは、基本的にはHTMLで渡すのでよいと思う。テキストが必要であれば、HTMLからテキストに変換すればよいだろう。ReVIEWからはInDesign用のXMLが（微妙に）出力できるできるので、場合によってはこれを渡すと喜ばれるかもしれない。実際に喜ばれたこともある。

ちなみにオーム社の場合はフルオートなので、最終コミットしたらもう作業終了だ（ReVIEWじゃないけど）。

10. 原稿確認

最後に、DTP作業が終わった原稿を確認することになるが、紙に赤を入れるなんて面倒くさすぎるので、何らかの効率的な方法を採用したい。例えば、渡した原稿と修正点のdiffをDocDiffで作成して、HTMLで渡すなども考えられる。このへんは編集者とコミュニケーションして解決していただきたい。