機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

*[本]「ソフトウェアアーキテクチャメトリクス」: アーキテクチャ品質を改善する10のアドバイス

昨年の夏頃に @snoozer05 さんこと島田さんがX(旧Twitter)でソフトウェアアーキテクチャに関する翻訳書籍の原稿レビュアーを募集しているのを偶然お見かけしました。ここ最近ソフトウェアアーキテクチャに興味があって、いろいろと書籍を読み漁っていたこともあり、これは良い機会だと直感してすぐにエントリーしました。その後、こちらのレビューに参加させていただけることになりました。

ちなみに原著はこちらの書籍(Software Architecture Metrics)です。

そして、今年の2024年1月24日についに翻訳書が発売されました👏👏👏

www.oreilly.co.jp

以上の経緯から、今回やったこと、感じたことなどを書き留めておくことにします。

期間と実績

約1ヶ月強という比較的短い期間の平日の仕事終わりの時間と週末の空き時間を使って翻訳レビューの作業をしました。〆切のレビュー期限までに書籍全体100%を網羅することができず申し訳なかったです。最終レビュー実績は6割超(188/308ページ)でした。大変お粗末様でした🙇 

作業の内容

いろいろやり方を考えたのですが、今回はGoogle翻訳とDeepLに適切な長さの原著の英文をそれぞれ入力して翻訳文を比較したり、ツール翻訳文を書籍の翻訳案と見比べて分かりにくい点がないかなどをチェックしました。翻訳ツールへの入力の工夫としては、入力する英文をいくつかのパターンに区切って翻訳させて、より確からしい意味を模索するなどしました。気付いた点は、作業用GithubリポジトリにIssueチケットとして起票して翻訳者へお伝えしました。チケット粒度は特に明確なルールはなかったのですが、私は章や節などある程度の単位ことにチケットを起票して、分かりにくいと思った理由と英文を箇条書きで翻訳文と併記しました。また、より分かりやすいと思える翻訳文のアイデアを思いついた箇所は、翻訳文案も併記してお伝えするようにしました。

感じたこと

今回の作業で感じたことは、昨今ではGoogle翻訳やDeepLなどの優れた翻訳ツールがあって本当に助かるなぁ、ということでした。とはいえ、自分が理解するためだけなら、翻訳文の日本語が多少変でも良いと思うのですが、書籍としてできるだけ分かりやすく、なるべく日本語として不自然でなく、原著の意図を汲み取りながら、数百ページの長文を翻訳するのは、やはり大変な労力が必要だなと改めて感じました。況や今日のような便利な翻訳ツールがなかった頃、大量の翻訳をやられていた @a_konno さん達のような先達の苦労は如何ばかりだったかと思うと本当に頭が上がりません。

さいごに

一昨年の2022年には 自分が寄稿した書籍を技術書典13で自ら販売するという機会 を得ましたが、商用本の翻訳レビューのお手伝いは初めての経験でした。実際にやってみると便利な翻訳ツールが整っている今日でも、思った以上に大変な作業でしたが、前述したように先達の苦労を少しだけ窺い知れたことや、技術書の内容を先んじて読んで理解を深めることができたという点において貴重な機会でした。そして謝辞に名前を入れていただけたのが嬉しかったです。ご献本いただきありがとうございました🙇