「Everyday Rails - RSpecによるRailsテスト入門」の舞台裏をお見せします

はじめに

みなさん、こんにちは。
昨日発売した「Everyday Rails - RSpecによるRailsテスト入門」の反響は予想以上で、早くも100名以上の方々に購入していただきました。
購入してくださったみなさん、本当にありがとうございます。心より感謝します。

「Everyday Rails - RSpecによるRailsテスト入門」って何？という方は、昨日公開したエントリをご覧下さい。

• RSpec初心者必読！「Everyday Rails - RSpecによるRailsテスト入門」を発売しました - give IT a try

また、電子書籍の購入はこちらからどうぞ。

Everyday Rails - RSpecによるRailsテスト入門 - Leanpub

この本は現時点ではまだ「ベータ版」で、これから「最後の仕上げ」が残っているのですが、思った以上にたくさんの方々が読んで下さっているので、読者サービスとしてちょっと早めに翻訳作業の舞台裏をお見せしたいと思います。

実際書いてみるとかなり長くなってしまったので、先に見出しだけ載せておきますね。

• プロジェクトの始まりについて
• プロジェクト管理について
  • 翻訳作業は実績に基づいて見積もりを立てた
  • ブログでマイルストーンを公表して、締め切りドリブンに拍車をかけた
  • 翻訳者チームで毎週Skypeミーティングを開いた
  • Trelloでタスクを管理した
  • メーリングリスト代わりにFacebookグループを使った
• 翻訳で使ったツールや苦労した点について
  • Leanpubの原稿管理はMarkdown + Dropbox
  • 今回はVimで原稿を書いた
  • いちおう用語辞書は作った
  • バージョン管理と課題管理にはBitbucketを使った
  • 翻訳の秘密兵器・・・？
  • 意味がわかってもきれいな日本語にするのが難しい
  • 当然、技術的なバックグラウンドも必要
• 翻訳者チームを悩ませたPDFの日本語フォント問題
• 翻訳だけでも140時間、さらにプラスアルファ
  • 時間の捻出について
• 正式版の公開に向けた今後の予定

それでは本編です。

プロジェクトの始まりについて

翻訳プロジェクトが始まったのは今から2ヶ月半ぐらい前、2013年11月の終わり頃でした。

「Everyday Rails Testing with RSpec、なかなか良い本だから日本のRailsプログラマにもたくさん読んでほしいな～」と思って、僕が作者のAaronさんに声をかけたのが始まりです。

しかし、Aaronさんから返ってきた答えは無情にも(?)「もうすでに翻訳に着手した人がいるよ」でした。

がーん。先を越されてしまった・・・！！！

ただ、「最近、彼から進捗を聞いてないので確認してみるよ」ということだったので返事を待っていたところ、「@blueplanet42っていう人だから二人で相談してどうするか決めてくれ」と言われました。

このとき@blueplanet42という名前を聞いてびっくり。以前東京でお会いしたことがあった人だったからです。(このイベントでお会いしました)

お互い面識があったので「じゃあ一緒にやりましょう」ということになり、翻訳プロジェクトがスタートしました。
(そもそも魚さん(@blueplanet42)は僕のブログを読んだのが翻訳を始めるきっかけになったそうです)

最初は二人で進めていたのですが、ちょっと進捗が良くなかったので、2013年の年末に僕がAkiさん(@spring_aki)を誘って3人体制になりました。
Akiさんは僕と一緒に毎月西脇.rb&東灘.rbの勉強会を開催しているRubyist仲間です。

こんな感じで3名の翻訳者チームができたのですが、全員翻訳は初めての素人だったので、まあなかなか大変な道のりでした。

プロジェクト管理について

この翻訳プロジェクトは自発的に始めたものなので特にいつまでに終わらせなければいけない、という締め切りはありません。
しかし、それに甘えてダラダラやっているとなかなか発売にたどり着けません。

そもそもRailsもRSpecも変化が激しいフレームワークなので、ダラダラやっていると発売時点ですでに情報が古い、という可能性も大です。
なので、特に締め切りがないと言えど、早めにリリースすることは重要だと考えました。

そこでとりあえず「2014年2月中に発売する！！」という目標を立てて、そこに向かってスケジュールを組むことにしました。
そしてそこから逆算でマイルストーンを決めました。

2013年12月の時点で決めたマイルストーンはこんな感じです。

• 2014/01/11 - 全体のラフな翻訳を終わらせる
• 2014/01/25 - 翻訳の質を上げる
• 2014/02/01 - 発売に向けたもろもろの準備を終わらせる
• 2014/02/03 - 最初の発売

こうやって振りかえるとほぼ予定通りに最初の発売(実績は2014/2/7)までこぎ着けることができたみたいです。

もちろん、「やってみたらあまりに非現実的なマイルストーンだった」ということになれば、ある程度柔軟に変更するつもりではいました。

翻訳作業は実績に基づいて見積もりを立てた

ソフトウェア開発とは異なり、翻訳は文量が予めわかっているので定量的な見積もりが立てやすい作業です。
そこで、一章分を翻訳して1センテンスあたりの平均翻訳時間を算出し、それを各章のセンテンス数にかけ算して見積もりを出しました。

以下は実際の作業(上のマイルストーンで言うところの「質を上げる」フェーズ)で使ったスプレッドシートです。

赤枠で囲ったところの左が見積もりで、右が実績です(F列とG列)。
見積もりが65.33時間、実績が65.01時間、ということで見積もりと実績がほぼ一致しました。(たぶん奇跡だと思いますが)

ちなみにピンクの行は「かなり長い章」、黄色い行は「ちょっと長い章」を表しています。

なお、この見積もりの立て方は、昔読んだスティーブ・マコネルの「ソフトウェア見積り」を参考にしています。

ソフトウェア見積り

　

ブログでマイルストーンを公表して、締め切りドリブンに拍車をかけた

自虐的と言えば自虐的なのですが、マイルストーンが見えた段階で自分のブログでそのマイルストーンを公表しました。
2014年2月7日にベータ版発売というのも、ある意味意図的に公表しました。
世間にやります！と言ってしまうと、やらざるを得なくなるからです。

• 2013/12/30 - Everyday Rails Testing with RSpecの翻訳プロジェクトを開始しました！
• 2014/01/09 - 「Everyday Rails Testing with RSpec 日本語版」の進捗と今後のスケジュール
• 2014/01/28 - Everyday Rails - RSpecによるRailsテスト入門（ベータ版）は2014年2月7日(金)に発売！！・・・するつもりです。

もちろん、これは締め切りを守るためだけでなく、本の発売を事前に宣伝する目的も含まれています。

翻訳者チームで毎週Skypeミーティングを開いた

僕は兵庫県西脇市、Akiさんは兵庫県神戸市、魚さんは神奈川県、ということで地理的に離れすぎているので、3人同時に会うことはできません。
そこでミーティングは毎回Skypeを使ってやりました。

僕が勤務しているソニックガーデンの「納品のない受託開発」では、毎週お客さんとSkypeミーティングをして先週分の実績と来週分の開発予定を決めるので、それに習ってここでも1週間分の実績と予定を確認し合うようにしました。

また、同じくソニックガーデンではKPTを使ったふりかえりをして、作業を改善しているので、毎週プロジェクトのKPTも話し合いました。

プロジェクトが予定通りに進んだ理由の一つは、こうやって毎週やるべきことを確認してマイルストーンから大きく遅れていないことを確認したり、何かプロジェクトを遅らせるような問題が発生していないか確認したりしていたことだと思います。

Trelloでタスクを管理した

ソニックガーデンの開発ではPivotal Trackerを使っているのですが、Pivotal Trackerだとちょっと重厚長大すぎるのと、プライベート(非公開)なプロジェクトを作るのにお金がかかるという理由で、今回はTrelloを使ってみることにしました。

無料だし、シンプルだし、こういうプロジェクトで使うには必要十分なタスク管理ツールだと思います。

　

メーリングリスト代わりにFacebookグループを使った

最初の数回はメールを使ってコミュニケーションをしていたのですが、翻訳者チームは3人なので毎回CCにメンバーを入れるのは面倒になり、プライベートなFacebookグループを使ってやりとりすることにしました。

Facebookグループの機能には多少不満な部分もありますが、それでもコミュニケーションツールとしては十分役に立ってくれたと思います。

同じ理由で作者のAaronさんとのやりとりもメールからFacebookグループに移行しました。
こちらは英語でやりとりするので、別のグループにしています。

プロジェクト管理やメンバー間のコミュニケーションで使ったツールや考え方はこんな感じです。

翻訳で使ったツールや苦労した点について

それではここからは翻訳作業そのものに関する裏話を紹介します。

Leanpubの原稿管理はMarkdown + Dropbox

まずLeanpubの仕組みですが、基本的にMarkdown形式のテキストファイル + Dropboxで原稿を管理します。

翻訳者メンバーとLeanpubが同じDropboxフォルダを共有するわけです。
なのでローカルで原稿を変更すると、自動的にLeanpub側もそれを受け取れます。

そして、Leanpubの管理者ページにアクセスして「Preview作成ボタン」をクリックすると、原稿ファイルからPDF、MOBI、EPUBのプレビュー版を作ってくれます。

プレビュー版のファイルもまたDropboxで共有されるので、翻訳者メンバーの元にプレビュー版が届きます。
そして、原稿がちゃんと電子書籍になってるかどうかを確認するわけです。

今回はVimで原稿を書いた

前述の通り、原稿はMarkdown形式のテキストファイルなので、僕はVimを使って原稿を書いていきました。
作業風景としてはこんな感じです。

が、あとで知ったのですが、「Google 翻訳者ツールキット」という翻訳者向けの無料のツールがあり、これを使うと単語の訳を自動的に統一してくれる等の便利機能が使えたみたいです。
ただ、翻訳作業の途中から導入するのは厳しそうだったのと、マークダウン形式にはどうも対応してなさそうだったため、今回は導入を見送りました。

いちおう用語辞書は作った

今回は翻訳者が3人いたので、翻訳者ごとに訳がバラバラするのはできるだけ避けたいと思い、用語辞書を作って共有するようにしました。
たとえば、「matcherはマッチャと訳す」「attributeは属性と訳す」といった感じです。

とはいえ、スプレッドシートで管理するだけではなかなか3人の認識を一致させることは難しく、最後の方は運用がうやむやになってしまった感があります。。。
こういうときこそ、前述のGoogle 翻訳者ツールキットみたいなツール(「翻訳メモリ」というそうです)で管理した方が効率が良さそうでした。

あと、RSpecについては「The RSpec Book」という既存の和書があるので、読者の混乱を避けるためにもRSpec関連の用語はこの本の訳に合わせるようにしました。

The RSpec Book (Professional Ruby Series)

　

バージョン管理と課題管理にはBitbucketを使った

途中まではDropboxオンリーで作業していたのですが、やはりバージョン管理しないと不安だよね、ということでGitを導入することになりました。
ただ、GitHubだとプライベートリポジトリが有料になってしまうのでどうしようかと思い、無料のBitbucketを利用しました。

Bitbucketは今回初めて使ったんですが、無料でプライベートなリポジトリが作れるのはいいですね。
普段はGitHubを使っているので、「やっぱりGitHubの方が・・・」と思うところが無きにしも非ずですが、まあ必要十分だと思います。

あと、内部レビューで上がってきた翻訳の不備の指摘もBitbucketの課題管理機能を使っています。
Redmine的な仕組みになっていて、こちらも無料で使えるなら「これで十分」という感じです。

　

翻訳の秘密兵器・・・？

翻訳は主に自分の英語力とネットの英語辞書を駆使しながら進めていくわけですが、それでもネイティブが使う英語というのはネットを調べてもよくわからないものがたくさんありました。

特に成語(イディオム)関係は難しいです。一つ一つの単語の意味はわかっても、それが成語になると全く予想の付かない意味になったりします。
たとえば「well-named variables can go a long way」という英文だと「go a long way」の意味がわかりません。goもlongもwayも知っているというのに！
「良い名前の変数は長い道を行くことができます」なんて直訳しても意味が通じないことは見て明らかです。

そんなときにとても頼りになったのが、西脇.rbのマイケル(@maikeruhorando)です。
彼は日本語がペラペラのイギリス人なので、どうしても意味がわからない部分は彼に尋ねました。

さすが英語ネイティブのイギリス人、僕が全然わからなった英文もすいすいと答えてくれます。
たとえばさっき出てきた「go a long way」は「効果的」という意味だそうです。
なるほど、だから「変数に良い名前を付けると効果的です」みたいな意味になるんですね！！

他にも前後の文脈とうまくつながらない部分の誤訳を修正してもらったり、彼には大変お世話になりました。
ほとんど4人目の翻訳メンバーと呼んでも差し支えないぐらいです。
彼なしでこの翻訳を完了させようと思うと、相当苦労していたと思います。

彼とは二回ほど近所のマクドナルドで夜遅くまで翻訳Q&A大会に付き合ってもらいました。
マイケル、本当にありがとう！！

意味がわかってもきれいな日本語にするのが難しい

そんなわけで、自分の英語力 + ネットの英語辞書 + マイケルのヘルプで、英文の意味はほぼつかめたんですが、今度は英語をわかりやすい日本語にするのが難しかったです。

前々から分かっていましたが、英語と日本語は全然文の構造や組み立て方が違うんですよね。
直訳すると全然意味が通じません。
長い一文をそのまま一文にしようとしても、英文をどんどん後ろから訳すような形になってしまって、できあがった日本語が意味不明になってしまいます。

たとえばこんな英文は訳すのがなかななか大変です。

For example, this modification to our contact factory uses the `after` callback to make sure that a new contact built with the factory will also have one each of the three phone types assigned to it.

単語だけ前から訳していくとこんな感じです。

たとえば / この変更は / 私たちの連絡先ファクトリへの / 使う / `after`コールバックを / ～を確実にするために / ～であるということ / 新しい連絡先も / そのファクトリで作られた / 持つ / それを / それぞれ / 3種類の電話番号 / それに割り当てられている

これは無理に一文にするとかえって日本語がわかりにくくなるパターンだと思ったので、ここはこんなふうに2文にわけて訳してみました。

　たとえば、連絡先のファクトリで`after`コールバックを使うように変更してみます。次のように、ファクトリで新しい連絡先を作った場合は3種類の電話番号も一緒に作成し、連絡先に関連付けることができます。

英語はまあまあ得意だし、こうやってブログの文章を書くのも得意だから和訳の日本語もそこそこ書けるんじゃないかと思いましたが、とんだ大間違いでした。

原文の意味を崩さないレベルで意訳したり、長い英文は日本語で複数の文に分割するなどして、読みやすい日本語に直したつもりですが、まだまだ気持ち悪いところは残っていると思います。
このあたりを正式版までに直していくつもりです。

あ、読者のみなさんも何かお気づきの点があればお気軽にフィードバックを書き込んでやって下さい。

• https://leanpub.com/everydayrailsrspec-jp/feedback

当然、技術的なバックグラウンドも必要

あと当然ですが、技術書であれば、それに関する技術的なバックグラウンドも必要になります。
僕はRailsもRSpecもそこそこ知っていたので、それなりに翻訳を進められましたが、たとえばPHPやPythonの技術書を翻訳して下さい、と頼まれたらさすがに無理だと思います。

翻訳作業そのものに関する裏話はこんな感じです。

翻訳者チームを悩ませたPDFの日本語フォント問題

あと、翻訳者チームで忘れられない裏話と言えば、PDFの日本語フォント問題です。

Leanpubはカナダのサービスですが、一応日本語にも対応してくれていました。
しかし、できあがったPDFのプレビューを見てみると、何かがおかしいことに気付きました。

英語版では太字や斜体になっている箇所が、日本語だと通常のレギュラーフォントになっていたのです。

これはPDFで使っている日本語フォントに太字や斜体が用意されていないことが原因でした。

この問題をLeanpubの人に相談したところ、「太字や斜体がある商用フリーな日本語フォントを探してほしい」と言われました。
で、ネットを探したのですが、なかなか良いフォントが見つかりません。

最初はMigMixというフォントを使ってみたのですが、ゴシック体のフォントで全体的にフォントのサイズが大きく、PDFで見たときにすごく文字同士や行間が詰まってしまい、かえって読みにくくなりました。

そこで明朝系のフリーフォントを探し始めたのですが、やはりなかなか見つかりません。
ヒラギノ明朝なら使えるかも、という噂を聞いたのですが、メーカーに問い合わせてみるとNGでした。

そこでダメ元で、Twitterで「フォントが見つからなくて困ってます」とツイートしたところ、とあるユーザーさんがリプライを返してくれました。

@jnchito あおぞら明朝というのはどうでしょうか？ http://t.co/mxWog2rgYX

— がんじゃ (@thc_oO) January 30, 2014

「あおぞら明朝？そんなフォントがあるのか！」ということで、急いでLeanpubに連絡し、このフォントを導入してもらいました。
そして導入が完了したのがベータ版発売の一日前、2014年2月6日のことでした。

この件ではなんと27回もLeanpubの人とメールでやりとりすることになりました。

いやあ、でも最終的にフォント問題が解決して良かったです。
最後まで辛抱強く付き合ってくれたLeanpubのScottさん、あおぞら明朝を教えてくれた@thc_oOさん、それにあおぞら明朝を作ってくれたbluskisさんには本当に感謝です！

翻訳だけでも140時間、さらにプラスアルファ

そんなこんなで、この一冊を公開するまでの道のりはかなり大変でした！
最初の方にお見せした見積もりと実績のスプレッドシートを見ると、ラフ翻訳 + 品質向上フェーズを合わせて、3人で約140時間かかりました。

この本一冊のセンテンスをカウントすると、だいたい1400センテンスなので、「140時間 x 60 ÷ 1400センテンス = 6分/センテンス」となり、1センテンスあたり約6分かかっていることになります。

たとえば、下のような文章は英文でいうと5センテンスぶんの和訳です。

　これにはいくつかの理由があると私は考えています。Rubyやwebフレームワークを使うのは人によっては新しい技術なのかもしれません。そこへさらに仕事を増やすのもまた新しい、というか余計な仕事と思われているのかもしれません。もしくは時間の制約が問題になっているかもしれません。テストを書く時間が増えることによって、顧客や上司から要求されている機能に費やす時間が減ってしまうからです。もしくはブラウザのリンクをクリックするのが"テスト"であるという習慣から、抜け出せなくなっているだけかもしれません。

1センテンスあたり約6分だとすると、この訳を考えるだけで合計30分ぐらいの時間がかかっているわけですね。読むだけなら1分もかからないというのに！
いやはや、翻訳の仕事は大変です。。。

実際は前述したPDF問題のやりとりや、Skypeミーティングの時間等々、あれこれと付随してきたタスクも加えると、さらに20～30時間ぐらいあったと思います。

時間の捻出について

それにしても、この140時間とプラスアルファという時間はどこから捻出したのでしょうか？
翻訳者チームは3人いるとはいえど、全員自分の仕事を持っています。

はい、これは空いた時間を見つけて翻訳関連のタスクに回すしかありません。。。
この翻訳作業はちょうど年末年始を挟んだので、この休み期間中に結構時間を使いました。

あと、僕の仕事は完全裁量労働制というか、通常業務に迷惑をかけなければ時間の使い方は自由なので、日によっては午前中翻訳して午後から仕事、みたいな日もありました。

とはいえ、プライベートの時間をかなり削ったのも確かです。
「妻や子どもたちにはちょっと淋しい思いをさせているなあ」と、後ろめたい気持ちを感じつつ翻訳をやっていたところもあるので、この本がたくさん売れたらちょっと家族旅行にでも連れて行ってやろうと思います。

さて、翻訳に関する裏話はだいたい以上です。

正式版の公開に向けた今後の予定

繰り返しになりますが、「Everyday Rails - RSpecによるRailsテスト入門」はこれで完成したわけではありません。
まだこれから以下のような作業をする予定です。

• 翻訳のさらなる品質アップ
• 日本語版の前書きや謝辞の作成
• 原著最新版への追従

特に翻訳の品質アップについては、何人か知り合いのエンジニアにレビューをお願いしているので、彼らからのフィードバックを翻訳に反映させていくつもりです。(レビュアーのみなさん、よろしくお願いします！)

また、原著がアップデートされたら翻訳版もアップデートしていくので、正式版が出れば完全に終了というわけではありません。
原著はRSpec 3.0への対応を予定しているので、そのうちまた翻訳が忙しくなる可能性もありますね。

まとめ

というわけで、「Everyday Rails - RSpecによるRailsテスト入門」のプロジェクト開始からベータ版発売までの道のりをざーっとまとめてみました。
始めた時は結構気軽な感じでしたが、実際にやってみると本当に大変でした。

でも、なんとか予定通りにベータ版を発売することができ、初日に100冊以上売れたというのは本当に嬉しかったです。
作者のAaronさんも前書きで書いていますが、「Leanpubから新しい読者が増えたことをメールで知らせてもらうたびに、私はとても喜んでいました。」というのは本当にその通りです(1冊売れるたびにLeanpubからお知らせメールが届きます)。

まあ、僕たちは大変でしたが、この翻訳本を出すことで「Railsでテストが書けるようになった！」「今までわからなかったことが理解できた！」と言ってもらえれば、僕たちも苦労の甲斐があったというものです。

僕たちがどうしてきたかは抜きにして、この「Everyday Rails - RSpecによるRailsテスト入門」を楽しんでもらえると嬉しいです。Enjoy！！

Everyday Rails - RSpecによるRailsテスト入門 - Leanpub

本書の内容や購入方法については僕のブログも参考にして下さい。

• RSpec初心者必読！「Everyday Rails - RSpecによるRailsテスト入門」を発売しました - give IT a try

参考文献

翻訳作業にあたってはネット上のいろいろな情報も参考にさせてもらいました。

翻訳は情熱だ！技術書を翻訳してわかった7つのこと
このブログが印象的だったので、藤原大さん(@daipresents)に連絡を取り、翻訳に関するアドバイスをたくさんいただきました。
藤原さんどうもありがとうございました。

C++ポケットリファレンスについて書ききれなかった、いくつかのこと - Faith and Brave - C++で遊ぼう
技術評論社の傳さん(@dentomo)とも面識があったので、編集の仕事についてちょっと質問をさせてもらいました。
傳さんが編集で携わったというこの本の裏話も、大変参考にさせてもらいました。どうもありがとうございました。
また、お会いしたことはありませんが、このブログを書かれたfaith_and_braveさんもどうもありがとうございました。

翻訳の工程
僕たちは翻訳に関しては完全に素人なので、こちらのサイトに載っていた翻訳プロセスを参考にさせてもらいました。

Google Translator Toolkitと翻訳メモリ(ノーカット版) : RubyWorld Conference 2013より
今回は使用しませんでしたが、Google翻訳者ツールキットの有用性についてはRuby on Railsチュートリアルの翻訳作業が参考になると思います。