Summary
本日発売された、ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則の英語版から日本語版への翻訳レビューに参加した際の経験を簡単にまとめました。
誰かの挑戦を後押しすることに繋がると嬉しいです。
Who
わたしは、合同会社DMM.comで同人事業のエンジニアリングマネジメントに携わっています。
英語が特別に得意な訳では無く、翻訳のレビューに携わった経験は以下2つのみでした。
What
無償のボランティア(*)として、Balancing Coupling in Software Designの英語版から日本語版への翻訳レビューに参加させて頂きました。
*：書籍の実物をご恵贈は頂いております。
Why & How
Xのタイムラインに以下のポストが流れてきました。
島田さんとはスタッフエンジニアの道でご一緒させて頂いたことがあったため、はてなブログ記事に記載のGoogleフォームからポスト投稿された当日に応募しました。
翻訳レビュー
翻訳者の島田さんから期待されていたことは「用語や表現などが想定対象読者層にとって、理解できるものであるかを確かめたい。読者が読んでいて引っかかった、理解しづらかった点を明らかにしたい」という観点でした。
最終的にはGitHubのIssueに起票していく形ですが、文章のチェック方法は自由なため、以下の形で工夫しました。
- 指定された期間内に余裕を持って完了できるように、数ページ実際にレビューし自身のレビュースピード（Issue起票含む）を測った上で全体量を見積もり、1日のペース配分を逆算し計画する
- 馴染みの薄い日本語だった場合に別の候補を探す
- あえて漢字ではなく平仮名を用いている場合、表現が統一されているか文書内検索してみる
- URLリンクとなっている箇所は、リンク切れやリンク先の誤りが無いか実際にアクセスしてみる
- 誤字脱字は自身が気になってしまうので、集中力を切らさないことを意識しつつもIssue起票はする
また、指摘コメントを書く際には以下の点に気をつけました。
- 敬意と礼儀を重んじる（断定しすぎたり強い主張は控える）
- 自らが誤って解釈したり読み違えていないか改めて確認する
- どの箇所に対する指摘なのかが一目で分かりやすい表現にする
- 感想も積極的にフィードバックする（激励の意味も込めて）
Fun
すでに翻訳が完了した書籍を見るだけでは分からない、翻訳者の苦労（どの部分で翻訳を悩んだか、候補はあったが不採用にしたなど）が分かった事、他のレビューアの観点/指摘をリアルタイムで拝見できたことが楽しかったです。
Done
訳注を含め全ページをレビュー。6/10〜7/19までの間で、合計レビュー時間が約28時間、合計30件ほどIssue起票させて頂きました。
特に印象深いのは、P32のCharles Perrowの大規模な事故の原因分析の箇所への訳注として失敗学会の付記を提案させて頂いたことです。
原書はどうしても引用されるエピソードが米国由来のものになるため、日本語へのローカライズの意味で日本国内の類似例が提示される意義はあると感じています。
Learn
似た用語の漢字は誤変換しやすい。
Appendix
翻訳者の島田さんが本書について記事を書かれています。ご参考まで。
https://snoozer05.hatenablog.jp/entry/2025/10/16/073759