blogこの広告は、90日以上更新していないブログに表示しています。2018-01-03技術系専門書(機械学習)の翻訳体験から学んだこと技術書(訳書)を出版社から初めて刊行したのですが、その過程で経験したことなどを共有することで誰かの役に立てて貰えれば、と言うのがこの記事の趣旨になります。Structures」を日本にも届けたい!"というプロジェクトもあり、こうした草の根の技術書の翻訳活動がもう少し日本にあってもいいのではと個人的に思っています。理系専門書に邦訳が必要なのかどうか(英語で読めばいいでしょ論)は立場が別れるところだとは思いますが、私は基本的に上記プロジェクト内の次の一文と同じ立場です。母国語でこのような入門書が読める、少なくともその選択肢があるのは望ましいことだと考えています。この記事も前の記事に引き続き、2017年に書きかけだった記事の供養です(投稿は2018年の年始)。年末にやりたかったのですが、年始になってしまいました。色んな人に何となく修正させても訳(の質)が単調に改善して収束していくとは限らない(振動する)GitHubで管理したのは良かったmasterマージ前に責任者がキチンとレビューすべきだった出版社への営業・版権を取るのは最初にやるべきだったまず最初に原著のLaTeXファイルをもらうべきだった原著を一文ぐらいずつコメントアウトして、その下に訳を書くのは良かったまず最初に専門用語辞書や簡単な規約をある程度固めて、スクリプトで自動でチェック出来るようにすべきだった自動チェックはfalse-positiveのトレードオフを考える必要があるLaTeX自動コンパイルは良かった総括どんな本を出版したの?これは主題とズレるので別記事に譲ります。こちらの記事をご参照ください。―基礎理論とアルゴリズム―」という本を刊行しました。Learning"の訳書になります。原著はLaTeXで書かれていて数式と擬似コードが多い一方、サンプルコードのようなものはないです。いう手順で翻訳したの?まずは、実際に私達が翻訳する際に踏んだ手順をほぼ時系列順で記述していきます。企画するもともとこの翻訳は強化学習の勉強会での輪読からスタートしています。洋書を読むなら翻訳しようということで気軽な気持ちで10人くらいでスタートしました。Szepesvari先生にメールでコンタクトを取って、原著の翻訳とそのフリーでのWeb公開について許可をいただきました。後で説明するように、最終的には出版社から出版するということで落ち着きます。翻訳を開始する最初は担当を一人5ページずつくらいで分担し、毎週の輪講までにOverleaf上に納品してもらっていました。この時点ではまだ担当者の理解度の都合もあり、クオリティも非常に低かったです。一通り埋まるまで2015年10月から2016年3月まで半年近くかかっています。一通り埋まってからはGitHub上に原稿を移して編集していきました。監訳をお願いする翻訳のクオリティの質を上げるためのモチベーションとして、ただ公開するだけでなく出版物にしようかという案が上がりました。この時点で訳者陣に博士学位持ちがいなかったので、内容・体裁の両方の面で問題があろうということで、監訳を出身研究室のツテで前田新一先生と小山雅典先生にお願いしました。前田先生は"これからの強化学習"や"深層学習本"にも寄稿されており関連分野に非常に詳しく、小山先生は数学博士で英語がほぼネイティブなので数式の多い洋書の翻訳にあたって心強かったです。出版社に営業する前田先生に出版社の営業の方を紹介して頂いて、メールで企画の営業をしました。最初に営業をした共立出版さんの方で企画が通り、刊行されることが決まりました(少しすったもんだはありましたが)。このあとで一度出版社に出向き、印税などの取り決めも口頭でおおよそ合意して、後日書類で契約しました。出版は決まりましたが、代わりにWeb上でのオープンでの公開は取りやめとなりました。洋書ではドラフトがpdfダウンロードできる専門書が多いですが、国内ではマーケットサイズの問題もあり、そうした試みは難しいそうです。版権を取るこれは私達がした作業ではないのですが、出版社の方で版権を取って頂きました。この作業を踏まないといくら翻訳しても日本で出版できません。このときになって初めて原著者・出版社の方から原著のLaTeXファイルをもらいました。実はこれまでは数式部分も訳者が手入力していて非常に効率が悪く、ミスも多かったです。これは完全に最初にやっておくべきでした。原稿を納品するいろいろすっ飛ばしますが、原稿を納品します。実は(ありがちですが)締め切りを丸1年近く伸ばしてしましました(2016年夏に納品予定が2017年夏に納品)。この過程では、もう一度輪講をして、最初とは別の担当者が確認・修正をする。上の原稿を小山先生に(主に英語を中心に)確認・修正してもらう。監訳のお二人と私の3人で原稿の読み合わせ・修正をする。3回)輪講メンバーを新規で増やしてもう一度読み直して確認する。訳書オリジナルの付録を執筆し、前田先生含め他の訳者に確認してもらう。いった工程があり、その途中で専門用語のチェックや送り仮名を揃えるなどの細かい作業も膨大にありました。した専門用語チェックや日本語の言葉遣いの問題はGitHub上でIssue管理して、RedPenを使っての自動チェックのCIを回したりしていました。専門用語についてはGoogleスプレッドシートに辞書を用意して対応が取れているか雑にスクリプトを書いてCIでチェックしていました。後に書くようにこのチェックを自動でCI回すのはfalse-positiveの問題があり、なかなか一筋縄ではありませんでした。辞書は最初のうちは(専門)用語の種類を少し多めに登録してしまいましたが、箇所によって柔軟に訳したくなるような用語もアラートがなってしまい面倒でした。出版社の編集の方に校正をしてもらう納品したら出版者の編集の方に校正をしてもらいました。プロということで、凄まじい速さで(ある程度)専門的な記述・一般的な記述含めて大量に直されました。CIを回していたりある程度細かくやっていたつもりだったのですが、やはりプロに校正をお願いしないと品質として最低ラインを満たさないように思います。Structures」を日本にも届けたい!"というプロジェクトでも、校正費用をクラウドファンディングしていたようです。(少額でも支援したかった。失念で叶わず)編集の方で判断がつかない点はやり取りをしながらになりますが、基本的にこちらはそんなに大変ではなく、待っていたら完成・刊行になります。教訓・反省(失敗・成功したなと思うこと、次にやるならどうするか)上記のような方法・手順で無事刊行に至りましたが、その過程での反省は多かったです。ここではその過程で得た教訓と反省、また逆にやってよかったことなどを記述していきます。いう方針で作業をしがちです。いった方針で作業すべきです。結局、時間をかけたからといってさして良くなるわけでもないので、締切については動かない"決め"が必要で、それまでに最大限努力するようにした方がいいです。後述の、「自動チェックを最初に初めて、いつでも最悪納品できるようにする」というのもこれと関連します。これはすごい普遍的な問題で、実行するのが非常に難しいというか、私は頭ではわかっていても正直すごく苦手ですし現に出来ていません(このブログ記事の投稿は2017年10月中を目指していましたが、結局2018年1月に投稿されました)。これは私だけでなく、苦手な人が世の中にはとても多いのではないかと思っています(皆さんは夏休みの宿題、ちゃんと終わっていましたか...?)。したらいいのか良くわかりません。ノウハウある方に教えて欲しいです。成功報酬として給料3ヶ月分くらい払っても知りたいです。https://twitter.com/jun_666_jun/status/947776153174994945人数がいたのに並列で作業できなかったのは良くなかった結局締め切り1年伸びてしまったのはこれも一つの要因かと思います。輪講していた都合もありますが、どうしても直列で作業しがちでした。ここはもっと並列にやることで効率的にできたかなと思っています。上記のような「締切守るの難しい問題」からドミノ倒しのように作業が遅延していくという問題もあったような気がします。分担を振って締め切りまでにやってもらったり色々したのですが、皆さん忙しいので結局いつまで経っても終わらなかったりします。結局少人数(3人くらい)でその場で読みながら気になった点を逐一修正していく、というミーティングを定期的に持つのが一番進みました。と3人でスカイプをしつつ読み合わせ・修正するミーティングを何回もしていました。年末年始など時間が取れるときに毎日スカイプでミーティングしながら進めたりしていました。監訳を除く訳者陣で輪講している際にも、気になる訳についてはその場で対訳を考えたりしていました(ただこれは人数が多いとすごい疲労しました。)色んな人に何となく修正させても訳(の質)が単調に改善して収束していくとは限らない(振動する)やはり訳者の好みもあるので、違う担当者が確認・修正するのを繰り返すと訳(の質)が振動したり(あるいはデグレしたり)といったことがありました。masterマージ前に最終的に責任持つ人のレビューをきちんとやるといった工程が本来は必要だったかなと思います。GitHubで管理したのは良かった人数が多かったので、GitHubで原稿を管理したのは非常に良かったです。これは一定以上の人数で作業するならマストだと思います。Overleaf等でもいいのですが、やはり修正者と修正意図はコミットログから確認したいところです。科学技術書の出版社の方でもGitHubがデフォルトになるといいんではないかと思ったりはします(例えば技評さんはGitHubがデフォルトと聞いています)。Gitに不慣れなメンバーがいると、Git自体の学習コストがそれなりに掛かるので、なかなか難しいところではあります。masterマージ前に責任者がキチンとレビューすべきだった当たり前なのですが、ここが少し疎かだったので、前述のようにデグレしたりといったことがあってしんどかったです。時間がなくてもmasterへのマージはきちんとレビューしてからにした方が良いです。PRの粒度を適当な小ささで抑えるのも重要です(当たり前の一般論ですが)。出版社への営業・版権を取るのは最初にやるべきだった結果論ですがこれは翻訳を始める前にしてもよかったかなと思います。大丈夫だと思いますが、版権ないと翻訳頑張っても結局出版できないので。最初に原著のLaTeXファイルをもらうべきだった前の項目とも関連しますが、これも大事です。すごい当たり前な気もしますが、最初は頭が回ってませんでした。原著を一文ぐらいずつコメントアウトして、その下に訳を書くのは良かった原著との対応が見やすくよかったです。専門用語訳などをスクリプトで自動でチェックする際にも役立ちました。最初に専門用語辞書や簡単な規約をある程度固めて、スクリプトで自動でチェック出来るようにすべきだった専門用語の辞書や簡単な規約は途中から導入したのですが、最初にすごく小さくでも仕組みを作ってCIの仕組みを作って、いつでも最悪納品できるようにしておいた方が良いと思いました。辞書を作るのと自動でスクリプトである程度チェックするのは必須で、さもないと専門用語の訳を途中で変えたときに一々抜け漏れを逐一チェックしないといけません。今回チェックしていた項目は色々ありましたが、例えば次のようなものをチェックしていました。RedPenの機能を使ったものもあれば、自分で雑にスクリプトを書いたものもあります。不適切な記号の確認(、。一文中のカンマの数を一定以下に一文の長さを一定以下にまたこれに関しては、出版社の中の規約のようなものも事前に編集の方に聞くべきだったなと思いました。(同じ社内でも詳しい人と詳しくない人がいると思うので、事前に詳しい人(例えば営業畑ではなく編集畑の方とか)を紹介してもらったりすべきでした)自動チェックはfalse-positiveのトレードオフを考える必要がある例えば今回、"system"の訳として、"システム"と訳す人と、"系"と訳す人が混在していました。"システム"という対応を辞書に登録してチェックしていました。スクリプトが誤検知を頻繁に起こします。"システム"の対応を辞書から外す文章中のいくつかの"system"は例外として登録するといったものが考えられます。"system"くらい訳が簡単そうなものなら1.を選択して辞書から外してもいい気はしますが、高い精度でのチェックを目指すなら、例外の登録を簡単にできるよう仕組みを作っておくことが大事です。アノテーションによるエラーの抑制また、どの程度のレベルのものなら辞書に登録するのか、自動でチェックをするのかといったしきい値を自分の中で設定しておく必要があるのではないかと思います。PDFアップロードを自動でするようにしていました。やり方はある気はしますが、リリースにpdfを上げるようにしていました。ブランチ毎に最新のpdfがリリースにアップロードされます。imageを利用してます。一応pdflatex版もあります。https://hub.docker.com/r/sotetsuk/pdflatex/大まかには次のような手順を踏みます。GitHubのトークンを生成リリースを作る(リリースのIDも調べる)werckerでアプリケーション・パイプラインを作る。翻訳して得た体験をもとにその教訓・反省などをまとめました。見直してみると、当たり前というか、マヌケに聞こえる話が多いような気もしますが、意外と当たり前のことをきちんとやるのが難しいものだったりします。皆さんも技術書の翻訳などを始める前に上記のようなポイントを踏まえて始めてみてはいかがでしょうか。誰かの参考になると嬉しいです。exampleについてはてなブログをはじめよう!sotetsukさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。