エンジニア的翻訳術

2021/6/26に開催されたScrum Festのアジャイル札幌LTの資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. エンジニア的翻訳術 株式会社アトラクタ 吉羽龍太郎 @ryuzee
2. @ryuzee
3. 思えばそれなりの数の書籍の翻訳をしてきました ご購入頂いた皆様、お世話になった出版社の方に感謝です Coming Soon ↑まだ持っていない本があれば是非お買い求めください!! 3
4. 書籍の翻訳でよく受ける質問 ✤ Q. 書籍の翻訳って儲かりますか？ ✤ A. みなさん書籍を買ってください ✤ Q. 英語のスキルって相当必要ですか？ ✤ A. 日本語のスキルの方がよっぽど重要です ✤ Q. 翻訳はどのように進めますか？ ✤ A. このあと自分の翻訳のやり方について話します 4
5. 翻訳書の出版の流れ（多少異なることもある） ✤ 翻訳する書籍の候補を見つける（出版社側から「この本どうですか？」と言われることもある） ✤ 出版社側で企画を通す ✤ おおよそのスケジュールを決める ✤ 作業準備をする ✤ ひたすら翻訳する ✤ 内部レビューをする ✤ 外部レビューをする ✤ 初校の原稿を納入し、出版社側で組版をする ✤ 組版後の初校を確認し、出版社側に修正を依頼する ✤ 出版社側で修正を取り込み2校を作成するので、確認する（3校くらいまで行うこともある） ✤ 入稿前の最終チェックをして、出版社に連絡 5
6. 翻訳書の出版プロジェクトの特徴 ✤ スコープ固定 ✤ 翻訳しなければいけない分量は決まっている ✤ 売上固定 ✤ 契約で印税率や初版部数が決まっている（増刷分を除く） ✤ スケジュール固定 ✤ 多少は調整の余地はあるが開始時点でおおよそのスケジュールは決まっている ✤ 品質固定 ✤ 翻訳の出版物として満たすべき一定の品質は決まっている 6
7. なんか失敗しやすいプロジェクトに見える…… 7
8. QCDS固定のなかでどう闘うか？ ✤ QCDSをうまく満たせるようにプロジェクトマネジメントをしていく必要がある ✤ QCDSが固定なので、Howの部分で工夫していくことになる ✤ Howの工夫はエンジニアの本領 ✤ 「怠惰」 全体の手間を減らすために手間を惜しまない ✤ 「短気」 今後起こりうる問題を想定して対応しておく ✤ 「傲慢」 品質の維持につとめる 8
9. 翻訳でもシフトレフト Capers Jones, Applied Software Measurement: Global Analysis of Productivity and Quality 組版してからたくさん直すのは無理筋(PDFに赤入れとか面倒すぎる) => 早期から継続的な品質確保 9
10. で、どうやっているか？
11. 1. テキストファイル ✤ 「実は、英文を読む回数よりも、日本語訳を読んで書き換える回数が圧倒的に多い」 ✤ 何度も何度も書き換えるのに向いているのは、テキストファイル ✤ 自分の場合は、Re:VIEWを愛用 ✤ 慣れたエディタ（vim） ✤ さまざまなツール(grepなどのコマンドや自作スクリプト)の組み合わせが可能 ✤ Google Docsは共同作業には向いていてもテキスト編集が弱すぎ（自分には無理） 11
12. 2. バージョン管理 ✤ 「実は、英文を読む回数よりも、日本語訳を読んで書き換える回数が圧倒的に多い」 ✤ あとからどういう変更をしたのか確認したいこともある ✤ やっぱり翻訳を戻したいこともある ✤ つまり、バージョンを管理する ✤ GitHubを利用 ✤ 大規模な修正のときは、ブランチを切ったりすることも ✤ 草が生えると精神的に安定する 12
13. 3. Issue管理 ✤ プロジェクトなので色んな種類の課題がでてくる ✤ 表記ゆれ、誤訳、ちょっと何言ってるか分からない…… ✤ 翻訳で気になる箇所があっても、いますぐ対案がない ✤ ふつーに見える化して対処していく ✤ レビューのときもIssueに登録してもらう ✤ コミットログと紐付けてクローズしていく 13
14. 4. 継続的インテグレーション ✤ 実際の組版のレイアウトに近い形で出力する ✤ 原稿はテキストだけど、PDFやHTMLで出力する ✤ テキストを読んだときと頭の働きが変わるので、問題や違和感に気づける ✤ レビューのときもこれを使う ✤ 今はGitHub Actionsのなかでコンテナを起動してビルドし、Dropboxに配信している ✤ レビューもしやすくなる 14
15. 5. 静的解析 ✤ 原稿のなかに適切じゃない記述が混入しないように、品質を維持し続ける ✤ 品質を後から上げるのは面倒くさいので、最初から確保する ✤ よくある例 ✤ 表記ゆれ（例: 気づく/気付く、第1回/第一回……） ✤ 長い文章（例： 140文字を超えるような長い文章） ✤ あいまいな修飾（例: 「大きな黒い目の大間のマグロ」） ✤ 機種依存文字 ✤ JustRight!とかtext-lintとか自作ツールとかとかの活用 15
16. 6. 生産的な環境 ✤ 作業を進めやすい環境を用意する ✤ 速いPC、複数のディスプレイ、疲れない椅子 とフットレストなどなど ✤ 手元に類書や関連書籍を用意しておく ✤ 環境はどんどんチューニング 16
17. 7. チーム開発 ✤ 翻訳が本業なのではなく、本業は別にある ✤ 1日(8時間くらい)で1人が進められる翻訳の量は2500〜3000ワード ✤ 1冊の本はおおよそ60,000〜120,000ワードなので、1人でやるのは辛い ✤ そこで翻訳チームで取り組むことになる ✤ 機能しているチームで仕事をするとうまくいきやすいのは翻訳も同じ ✤ 共通理解が多く、ツールの使い方も習熟しているので、非同期でどんどん進む ✤ チームが大きくなるとオーバーヘッドが大きくなるので3-4人がやりやすい 17
18. エンジニア的翻訳術とは？ ✤ エンジニア的翻訳術とは ✤ 書籍の翻訳にエンジニアリングプラクティスを用いること ✤ 書籍の翻訳をチームで行うこと ✤ アジャイルが好きなエンジニアならみんなできるはず！！ ✤ 世の中に広まるといい本はたくさんあるので、みんなも翻訳してくれるといいな ✤ 相談に乗りますので、お気軽にお声がけください 18

Comment

No comments...