ブログ

ryuzeeによるブログ記事。不定期更新

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）

技術書翻訳の進め方

みなさんこんにちは。@ryuzeeです。

これまで20冊近くの技術書を翻訳してきたので、そのノウハウをまとめて紹介したいと思います。これから技術書を翻訳する方の参考になれば幸いです。

以下では技術書出版までの時系列ごとに、どんなことをするのか、何に気をつけるべきかを説明します。

翻訳する書籍を選ぶ

まずはなんといっても書籍選びです。この時点で主に以下の2つのパターンがあります。

自分で書籍を見つける
出版社から特定の書籍の翻訳の相談を受ける

それぞれで進め方が変わります。

自分で書籍を見つける場合

自分自身でお気に入りの書籍を見つけて、それを翻訳するものです。初めて翻訳するときは、このパターンになることが多いのではないかと思います。

このときどう翻訳プロジェクトを立ち上げるかですが、いきなり著者に連絡して、翻訳させてほしいと言ってはいけません。通常、書籍は出版社が翻訳権を管理していおり、著者に連絡しても「いいねー」という話にしかなりません。翻訳書籍の出版を最終的に判断するのは、日本の出版社です。したがって、まずは簡単に企画書を書いて出版社に相談しましょう。

なお、翻訳書籍を出版するにあたって、日本の出版社は原著の翻訳権を取得します。ときには、邦訳がまだ出ていなくても、先に別の出版社が翻訳権を取得していて、翻訳プロジェクトが進行していることもあります。そのため、企画書を書く前に、すでに翻訳権が取られていないかを確認することもあります。

企画書を書く

翻訳書の出版において、出版社が気にするのは「一定の部数が売れるかどうか」です。長年に渡って読書人口が減っていることもあり、ある程度売れそうという確証がないと、出版には至りません。そこで、出版の判断の参考になるような企画書をまとめて、出版社に提出します。

企画書にはこんな内容を含めます。

書誌情報
この本のよい点
なぜ翻訳すべきと考えたのか
Amazon.comの★の数などの定量データ
想定読者層
類書や同じカテゴリの本がどれくらい売れていそうかの情報（Amazonとかのランキングでも構いません。出版社側では日本語書籍の売れ行きは取次データなどからある程度把握できます）

体裁はワードでもパワーポイントでもなんでも構いません。できあがったら出版社に送ります（出版社の編集の方を知り合いなどに紹介してもらうとよいと思います）。

企画書はあくまで企画なので、通ることもあれば通らないこともあります。通らなかった場合、どうしても出版したければ他の出版社に企画を持ち込んでも構いません。出版社によって、刊行の基準はさまざまなので、可能性はゼロではありません。ただし、当然の振る舞いとして、同時に複数の出版社に同じ企画を持ち込むような常識外れな真似はしてはいけません。

例外系

Leanpubなどで発売されている書籍の場合、出版社が特についておらず、著者本人がすべてを管理していることもあります（同人誌のような感じです）。このような書籍を電子媒体のみで刊行したいのであれば、著者本人とやりとりしても構いません。ただし、売上の報告や著作権料の支払いなどの事務手続きを自分でやらなければいけなくなるので、刊行後も非常に手間がかかります。お金のことで不義理をするのは非常によくないので、持続できるかをよく考えて取り組むことをお勧めします。

出版社から書籍を指定して翻訳を依頼された場合

2つめのパターンは、出版社から書籍を指定して翻訳を依頼された場合です。ぼくの場合は、過去に翻訳の経験が複数あるので、書籍を指定して翻訳の相談を受けることもあります。このとき、状況としては以下の2つがあります。

編集者の方が見つけて来た書籍の評価依頼から始めるケース
すでに書籍が決まっていて、翻訳者を探しているケース

1の場合は自分から提案するのと比較的似ていて、書籍を読んだ上で、その本が翻訳に値するかどうかを評価し、それを出版社に伝えます。伝えるときは、さきほど紹介した企画書に沿った内容で整理することが多いです。また、参考までに内容の一部や目次を部分的に翻訳することもあります。

2の場合はすでに企画は通っているので、提案書云々にならずに、翻訳作業の準備に入ります。

翻訳の準備をする

企画が通ったら翻訳作業の準備をします。

原稿をテキスト化する

翻訳作業をするにあたっては、マークダウンやReVIEWなどのテキスト形式のファイルで取り組むのがお勧めです。 Google Docsを使って実施している例を見かけたこともありますが、まったくお勧めしません。

テキスト化することにはさまざまなメリットがあります（最近の生成AIブームで、テキストデータが圧倒的に活躍している理由と似通っています）。

バージョン管理が容易
編集が軽い
検索性が高い
MacでもLinuxでもWindowsのWSLでも、テキストをさまざまな形で処理できる。たとえば文字数や行数などはwcコマンドを使えば一発です

書籍『達人プログラマー』でもテキストファイルの偉大さを説明しています。 原稿をテキスト化し、gitを使ってバージョン管理するのは必須です。

テキストはバカでかい大きな1ファイルにするのではなく、章単位などで分割します。章が少ない場合は節単位で分割することもありますが、全体性がわかりにくくなることも多いので、あまりお勧めしません。

分量を計測する

原稿をテキスト化したら、おおよその分量を計測しておきます。原著のボリュームにもよりますが、僕が取り組んだ書籍は80,000ワードから100,000ワードくらいの分量であることが多いです。分量がわかれば、おおよその作業期間の見積りも可能です。

一般的には1日8時間で翻訳できる分量は、2000ワードから3000ワードと言われています。本業を持っている人は平日の作業時間は2〜3時間、土日でそれぞれ5〜6時間くらいで見積もるとよいでしょう。そうすると、1週間あたり20時間くらいの作業ができる計算です。

したがって100,000ワードの書籍であれば、

100000 ÷ (2500 ÷ 8 * 20) = 16週間＝4か月

が原稿を翻訳して下訳にするのにかかる時間です。もちろん下訳から先も全体を見直したり、さまざまな作業があるので、プロジェクト期間の見積りは下訳の時間の倍くらいの時間を見込んでおくとよいでしょう。

なお、翻訳者が複数人いる場合は、それを踏まえて見積もります。期間も人数によって変動します。

翻訳者の人数は何人くらいまでか？

これは完全に個人的な経験によりますが、4人くらいまでが限界だと思います。人によって文章のクセは違います。語尾の選択の順番や、言い回しなどを始め、必ず違いが出てきます。そのようなクセは、翻訳の過程でどんどん修正するのですが、人数が増えれば増えるほど、そのコストが大きくなります。また、複数の翻訳者がいる場合でも、誰か1人は必ず全体の監督をしなければいけませんが、人数が増えるほど主体性が下がります（普通のソフトウェアプロダクトの開発と同じです）

定番の訳語を洗い出して辞書にする

翻訳では、なるべく既存の定訳を使うのが望ましいのと、翻訳による意図しない表記揺れを防ぐために、定番の語句を抽出して、辞書にします。テキストで翻訳するときは、翻訳結果をそのまま埋め込むのではなく、辞書参照のキーを埋めることで、一括で用語の訳を変更できるようにします。

ぼくの場合は、過去の翻訳のときからずっと同じ辞書に追記をして使っています。初めて翻訳をする場合は、まずはテキストの原稿から頻出用語を取り出して、辞書化しておくとよいでしょう。

また、出版社がさまざまなレギュレーションを作っていることもあります。担当の編集者にレギュレーションがあれば提供してくれるようにお願いしましょう。

CI/CD環境を作る

前述のとおり原稿はテキストファイルにして、gitでバージョン管理しますが、あわせて準備するのがCI/CD環境です。マークダウンやReVIEW形式などのフォーマットで記述した原稿がプッシュされるたびに、自動でさまざまな処理を行うようにしましょう。

html形式でビルドする
PDF形式でビルドする
lintをかけて、問題点を自動で洗い出す
所定の場所に配置する

ぼくの場合はReVIEWを使うことがほとんどですが、GitHub Actionsを使って、原稿がプッシュされるたびにhtmlとPDFにビルドし、Dropboxの所定の場所にAPI経由で配置しています。どのCIツールを使っても構いません。常時ビルドして配信できる仕掛けにしておくことが重要です（これがこのあとの工程にめちゃくちゃ効きます）。

翻訳する

環境の準備ができたら翻訳に入ります。全体の分量が決まっているので、当初建てたスケジュールを踏まえて、粛々と作業を進めます。精神衛生上は、翻訳プロジェクトが開始したら、前倒し気味で進めていき、あとに時間を残しておくのが安全です。とはいえ、人によっては追い込まれないとやる気がでないとか、危険ゾーンになってからが本当の勝負だとか、自分のペースがあるので、納期に間に合うように自己管理しながら作業を進めます。

翻訳のときは、必ず原文をテキストファイルに残しておきましょう。あとから必ず英語と日本語を対比しながら訳文を見直すことになるので、原文がないとかなり手間がかかります。もちろんビルドのときに英文が表示される必要はないので、原稿のフォーマットにあわせてコメントアウトすればOKです。

なお、最初の翻訳が通しで終わった時点（下訳）では、まだ全体の工程の10〜20%程度の進捗といったところです。

翻訳のテクニック

翻訳のテクニックを網羅的に解説するのは不可能なので、ぼくが気にしている点をいくつか抜粋して紹介します。

日本語として読んで不自然ではないこと。たとえば「彼（he）」「彼女（she）」「人々（people）」「より◯◯（more）」「異なる◯◯（different）」のような訳にしてしまうと、まったく自然ではないので、このような表現は使わないようにします
一文の長さが長すぎないこと。たとえ原文が一文でも適切な長さに分割します。すなわち一度で頭に入り、意味が分かる文章にすることを目指します
受動態を避ける。原文で受動態だったとしても、日本語訳でそのまま受動態にする必要はありません。日本語として自然であることを優先します
特定文末を連続させないようにする。「〜である。〜である。〜である」のように同じ語尾を続けると単調になるので、「〜である。〜だ。〜である」のように語尾を調節します
「することができる」のような冗長表現は避ける。この手の表現は単に「〜できる」で置き換えられます。
複数の用語から連なる重たい主語を避ける。重たい主語は理解しにくいのでうまく避けるようにします
あいまいな修飾関係を避ける。「大きな黒い目の大間のマグロ」のように連続させると「大きな」が「黒い目」にかかっているのか「マグロ」にかかっているのかわからなくなります
表記揺れがないこと。意外と「会議」「ミーティング」のような基本的な単語が、翻訳しているうちに無意識に揺れてしまうこともあります。また訳者が複数人いる場合は、この問題はかなりの頻度で発生するので、Just Right!などの表記揺れ検出ツールが必須です
カタカナをそのまま使いすぎないこと。カタカナが多いとルー語みたいになって読みにくくなるので、その点について考慮します。ただし固有名詞や、日本語に訳すと意味不明になる単語も多々あるので避けられないこともあります。たとえば拙訳『チームトポロジー』では「ストリームアラインドチーム」「コンプリケイテッドサブシステムチーム」などの訳語があります。わかりにくい単語ではあるのですが、これを日本語にしたときにしっくり来るものがなかったので意図的にそのままにしています。

セルフレビューする

下訳が揃ったら、訳者だけで全体をレビューして、修正していきます。翻訳は分量が多く、作業に時間をかけていることもあり、いくら気をつけていても質のばらつきがあります。たとえば、最初のほうとあとのほうでは雰囲気が違ったり、途中で特定の単語の訳が変わったり、本来辞書を参照すべきところを参照できていなかったり、表記揺れがあったりといったことが起こります。そもそも訳文自体がわかりにくいこともあります。さらに、複数人で翻訳する場合は、訳者ごとのクセやばらつきもあります。これらを解消し、訳者以外の人の目を通せる状態に持っていくのがセルフレビューの目的です。

内部レビューなしで外部レビューへと進めてしまうと、レビューの質が下がってしまうので、この段階で頑張っておきます。

セルフレビューが終わっても、まだ出版社に組版依頼はしないでください。外部レビューでさらに原稿に手が入るので、組版作業自体がムダになったり手戻りが発生したりしてしまいます。またInDesignなどを使った組版は、そもそも作業自体に時間がかかるので、待ち時間も増えてしまいます。組版依頼をするのは、「このまま原稿が組版されて出荷されても、まあ大丈夫」という段階になってからにすることをお勧めします。それまでのあいだはCI/CD環境でのビルドを活用しましょう。

外部レビューする

セルフレビューが終わったら、外部の人に原稿をレビューしてもらいます。訳者自身では気づかなかった問題を出してもらい、より読みやすい原稿にするのが目的です。外部レビューは、GitHubなどのオンラインツールを使って、レビューワーの人にチケットを切ってもらう形で行います。期間は1か月くらいが目安です。

レビューワーの集め方

外部のレビューワーを集めるときは、以下のような点を気をつけるとよいでしょう。

発売前原稿を一部の人に公開することになるので、事前に出版社から了解を取っておきましょう
人数は10〜15人くらいが目安です。外部の人はみんな本業を持っていて、忙しい時間を割いて協力してくれますが、最初から最後までレビューできるとは限りません。人によって見るポイントも違うので、ある程度の人数を集めるのが品質を向上させる上で重要です。個人的には5人とかではまったく不足していると考えています
レビューワーを募集するときは、Googleフォームなどを使って応募してもらう形と、直接声をかける形の2つがあります。両方を組み合わせても構いません。本の内容に応じて検討すればよいでしょう。Googleフォームなどで幅広く募集する場合は、訳者となんらかの面識がある方に限定しておくのが無難です。
募集の際は、名前、GitHubアカウント、DropboxやGoogle Driveでビルド済原稿を共有するためのアカウント、原稿の取り扱いについての合意などを取得します。
レビューワーが集まったら、収集したアカウント情報を各種ツールに設定します。

レビューの進め方

前述のとおりGitHubなどにチケットを切ってもらう形で進めます。ソフトウェア開発のときと同じで大きすぎるチケットはさまざまな内容が含まれてしまい、対応のヌケモレがでたり、なかなかクローズできなかったりするので、小さい単位でチケットを切ってもらうように、あらかじめチケットの切り方のガイドラインを用意しておきましょう。

ぼくの場合は、最大でも「章単位」での指摘とするようにお願いしています（原稿を章単位で分割しているからというのが理由の1つです）。自分がレビューの依頼をうけたときは、段落など、もう少し小さな単位で指摘することが多いです。

あとは、チケットが切られたらひたすら対応するだけです。 複数のレビューワーから同じ指摘を受けるとお互いに時間のムダなので、チケットが切られたらなるべく早く対応しましょう。 CI/CD環境を用意しておけば、常に最新のビルド済原稿を読めるようになるので、早く対応すればするほど、同じ指摘を受けなくて済むようになります。ぼくの場合はチケットのクローズまでの平均時間は1日以内です。

判断に悩むものはラベルを付けるなどして判別がつくようにしておきます。

レビュー期間が終わったら、最終チェックをして、原稿を出版社に渡し、編集者のチェックを経て組版してもらいます。

組版する

これは出版社側の作業です。レイアウトが最初から決まっているような書籍であれば2週間くらいで組版ができてくることもありますし、InDesignでゴリゴリにレイアウトするようなものだと2か月くらいかかることもあります。

この期間に書籍の正式タイトルを出版社と相談の上で決定することが多いですが、それ以外は訳者としてあまりやることはありません。

校正する

組版が出来上がったら訳者が再度内容をチェックして、修正を行います。この期間は2週間くらいのことが多いです。

出版社によって修正の指示の方法は違います。 GitHubで修正点をチケット化して伝えることもあれば、組版したPDFに赤入れすることもあります。PDFに赤入れするのはiPadを使って手書きで修正点を書き入れるか、PDFのコメント機能を使います。当然のことながら、PDFに赤入れするのはとてもめんどくさいので、できればチケットで伝えるように編集者と調整しておくとよいでしょう。

修正点を伝えたあと出版社側でその反映作業を行い、再度PDFが出てきます。必要に応じてさらにチェックして修正を行います。この繰り返しの回数は、出版社、書籍のボリューム、完成度などによって変わってきます。

最終的に、出版社が校了を宣言したら完成です。あとは印刷が終わって配本を残すのみです。

宣伝する

さて、原稿の作業が終わってほっとしているかもしれませんが、まだ大きな仕事があります。それが宣伝です。 新刊書籍は初速がとても重要なので、訳者として宣伝活動をします（どこまで情報を出してよいかは出版社と相談します）。たとえば以下のようなことをします。

ブログを書く
Xに刊行のお知らせの投稿をする
出版社と相談して、本を読んで紹介してくれそうな方への献本を手配する（あわせてレビューワーの方への献本を手配する）

この宣伝の過程で、コミュニティなどの勉強会から登壇依頼をもらうこともあるので、できるかぎり対応します。

また、発売後も書籍タイトルでエゴサーチして、適宜紹介するようにしましょう。

よくある質問

以下では本文で触れなかったもののよくもらう質問に答えていきます。

英語力はどれくらい必要ですか

英文を翻訳するので、当然ある程度の英語力は必要です。ただし日本人は高校までに相当の教育を受けているのでそんなに心配しなくてもいいかもしれません。英語を喋れる必要はありません。

なお、英語力以上に重要なのが、日本語力です。読みやすく理解しやすい日本語を書く能力は必須です。

出版社とはいつどんな契約をするのですか

出版社によって契約締結の時期は異なりますが、発売前までに契約を締結します（プロジェクト開始前に契約することもあれば、発売時期が決まるころに契約することもあります）。契約書には、単価または予価、初版部数、印税率、電子書籍の扱い、権利関係などの条項が含まれます。このあたりは出版社からの案内を待つとよいでしょう。